The note said a plugin MCP tool needs this Mac "awake, connected and carrying
the right Python", and called sleep a state that would occur routinely. Two
things were wrong with that.
This operator's Mac does not sleep, so the named instance does not apply. And
there is no wider population to generalise to: build-brief lines 3 and 22 scope
the whole system to a single operator searching for their own job, and jobbsok
is not in the marketplace catalog. A worry about "most other users" is a worry
about people this project does not have.
The dependency itself is real; only the instance was wrong. The one that
survives a never-sleeping Mac is Cowork opened from somewhere else: the bridge
is named remote-devices and the server is a child of Claude.app on THIS Mac, so
a session started on a phone or a second laptop may or may not reach it. That
was not measured, and the note now says so in both directions rather than
guessing.
Stated precisely rather than darkly, because an overstated risk gets discounted
and takes the real one with it. The degradation branch now has two named
triggers instead of one vague one.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
All four bullets answered by the operator in a live Cowork session. The step's
Verify goes from exit 1 to exit 0, which is the whole point of having written
it as a `test` rather than a count-and-eyeball: it was red for a reason and is
now green for a reason.
- Sesjonsmodus: sky
- Host-MCP: ja
- python3: ja 3.11.15
- CLAUDE_PLUGIN_ROOT: ja
Host-MCP is `ja` on both halves of the rule, not just the first. The connector
was listed AND `probe_ping` returned `probe-tools 0.0.1, python 3.14.0 @
/usr/local/bin/python3` -- a macOS path and the host interpreter, against the
sandbox's 3.11.15 [GCC 13.3.0]. The call crossed from the cloud session to this
Mac. That was the prediction stated before the call, so the test could have
falsified it.
Consequence recorded alongside the capability, because it is a cost: a
plugin-declared MCP tool in Cowork needs this machine awake, connected and
carrying the right Python. A cloud session elsewhere reaches nothing. The
degradation branch is therefore also the answer to "this Mac is asleep" -- a
routine state, not an exceptional one.
Run 2 of the two-run record was dropped rather than quietly skipped. It was
designed on the expectation that the off run would fail; it did not, and the
default configuration already gives a working host-side server. Confirming that
local mode also works has low value against its cost, so it is deferred with
the reason stated and named as the first thing to try if the cloud path breaks.
One negative result worth keeping: an individual tools/call does NOT reach
main.log. `grep -c probe_ping main.log` returned 0 both before and after a
successful call. The check script already refused to read that absence as an
answer; this records why that caution was correct.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Recorded here rather than as extra bullets: the four are gated on a count of
exactly four and Step 31 adds a fifth, so a sixth would break the Verify.
Checked both ways -- the live file still counts 0, a fully answered copy still
counts exactly 4.
O1. Host-side MCP reaches a cloud session through localMcpBridge. research/03
dimension 4 quoted Anthropic saying local MCP servers do not run in cloud
sessions, and flagged as unverified whether they still spawn on this Mac.
They do: main.log records Connecting / negotiated 2025-11-25 / Connected
(1 tools) / announcing, and ps shows the server as a child of Claude.app on
the host Python 3.14. The session addresses it as
mcp__remote-devices__plugin_jobbsok-probe_probe-tools__probe_ping. So
"host-side server" and "cloud session" are not exclusive here.
O2. Sandbox and host are two different interpreters: 3.11.15 [GCC 13.3.0] Linux
inside, 3.14.0 macOS outside, with CLAUDE_PLUGIN_ROOT resolving under
/root/.claude/plugins/synced/. That is also what answers the session-mode
question -- measured from the paths, not read off a settings screen. It
matters for M3: guard_ingest.py cannot import the guard in the sandbox, so
it belongs on the host side of the bridge that O1 shows is reachable.
O3. Cowork's built-in browser rendered a Finn job ad in full, with the operator
logged in after signing in by hand inside that browser. That is the brief's
invariant by a shorter route -- no credential handling, manual auth, an
already-authenticated browser. It raises an M3 question about what
Playwright over CDP still adds; the question is recorded, not decided.
Two limits are stated rather than glossed: login persistence across
sessions was not measured, and the built-in browser leaves no host-side
trace, so unlike O1 and O2 the operator's observation is the only
instrument.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Cowork exposes session location as a toggle ("Only on this computer"), which
the probe's four bullets cannot express: each holds one value, and the file was
written as if session mode were a property of the machine to be discovered
rather than a setting that can be flipped.
So the probe is now run twice, off then on, into a two-run table in the Results
section, with a second table saying how to read the pair. The three outcomes are
all useful and lead somewhere different -- the toggle is the lever (and then it
belongs in README and in every Verifiser i Cowork step, not a footnote); host
MCP is dead whatever the setting (degradation branch, and jobbsok-tools is not
built on an assumption); or host MCP runs even in cloud mode, which contradicts
the documentation and is exactly what research/03 dimension 4 flagged as
unverified.
Off is run first because it is the current default and a fresh install returns
to it -- one click away from being lost for free.
Section A now says to probe both sides of the setting rather than just read it,
and carries an honesty marker: that this toggle controls session location is an
inference from its label and subtitle, not something any documentation read so
far names by that string. The probe settles it.
The four bullets, the allowed answers and the Verify command are untouched.
Checked rather than assumed: on a fully answered copy the verify regex still
matches exactly 4 lines and exits 0 -- for the `lokal VM`/`ja` filling and for
the `sky`/`nei` one -- so the added tables cannot become false positives. The
live file still exits 1, as it must while the probe is open.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Addendum to plan Step 1, which stays open: the four bullets are still
`ubesvart` and the step's Verify still exits 1. Nothing measured changed.
The previous instruction was one sentence -- "upload via Customize -> Plugins,
run probe-versjon, check whether probe-tools appears" -- which assumed the
reader already knew where each of those lives and what counts as an answer.
The walkthrough now lives in the file the answers get written into, rather than
in a chat message that scrolls away.
Every UI path and caveat is sourced from research/03, not invented: the
install-from-file and drag-into-chat routes, connectors appearing under the
plugin's connectors page rather than as skills, the stale-cache issue (#69020)
that makes the 0.0.1 version check load-bearing, and the upload-does-not-
survive-relaunch report (#65426).
Two distinctions are called out because getting them wrong would produce a
confident wrong answer:
- `- python3:` measures the SANDBOX interpreter, not the host's. Cowork runs
shell commands in the VM or in the cloud. It is still the right thing to
measure, but it says nothing about the virtualenv Step 2 built.
- `- Host-MCP:` does run on the host, since local MCP servers were moved out
of the sandbox in May 2026. A `ja` there is what decision 7 rests on, so it
requires both that the connector is listed and that probe_ping answers --
"present but mute" is recorded as nei with a note, because absent and mute
point at different causes.
Section A is ordered first on purpose: cloud sessions are documented not to run
local MCP servers, so `sky` plus a `ja` on Host-MCP would contradict the
documentation and is a more interesting result than either answer alone.
The verify command in section F was executed as written from the rendered
document, not just pasted in: exit 1, as it must be while the probe is open.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Plan Step 1. Builds the probe vehicle and the checklist; does NOT answer it.
The four questions all require the operator in a live Cowork session on this
Mac, and that is a fact about the measurement rather than a caveat: measured
2026-09-04, the session mode is not readable from disk (cowork_settings.json
carries only extraKnownMarketplaces; the desktop config carries
coworkNetworkMode and a trusted-folder list, neither states where a session
runs), and the other three each need a plugin installed in a live session.
The step's Verify is therefore RED on purpose and stays red until the operator
answers:
test "$(grep -cE '...' docs/cowork-probe.md)" = 4 -> exit 1 (0 of 4 matched)
Validated in both directions: a fully answered copy exits 0, a copy with three
of four answered exits 1. The gate can pass, so its failure means something.
Probe vehicle: jobbsok-probe, exactly four files under
tests/fixtures/cowork-probe/ -- manifest, skills/probe-versjon/SKILL.md,
.mcp.json declaring the stdio server probe-tools, and probe_tools.py (standard
library only). Smoke-tested from Claude Code: initialize handshake completes,
tools/list returns probe_ping, tools/call returns an interpreter version, an
unknown tool name is rejected. What is NOT verified is whether Cowork ever
starts it -- that is the question.
Archive is built from an explicit four-file include list, never zip -r over the
repo root; verified to contain no .git, STATE.md, .venv or .claude/ entry.
The degradation branch for each possible nei is written down now, before any
answer is known, so it is not decided under pressure later.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Operatoerbeslutning (b): revider planen foer M1. Ordre
20260904T135502Z-687411640-from-.claude, ti punkter, alle utfoert i
plan.md og brief.md under .claude/projects/ (local-only, gitignored) --
denne seksjonen i revisjonsrapporten er den sporede baereren.
Gater ved levering, kjoert 2026-09-04:
- plan-validator.mjs --strict: valid, 56 steg, 0 errors/warnings
- brief-validator.mjs: valid, 0 errors/warnings
- oekt 2s gate-script (33 grep-kriterier): PASS=33 FAIL=0
- grep -c 'Pass 2' plan.md: 6
- de tolv "Foreldet tekst"-greppene: PASS=12 FAIL=0
Ingen kode skrevet, ingen M1-steg utfoert. 56 steg inn, 56 steg ut.
Tre avvik fra ordreteksten, begrunnet i rapporten: --check i 5 av 6
Cowork-steg (steg 16 er M1, sak_status.py finnes foerst i steg 17);
det tolvte scriptet i avviksnoten er jobbsok_tools.py, ikke
kandidat_schema.py (som allerede sto der); Pass 2-seksjonen staar sist
i fila, der trekplan.md anviser, med peker fra planhodet.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Measures the two planning sessions and plan.md against docs/build-brief.md:
step traceability (0 of 56 unanchored, 15 derived), blocker closure (5 of 9
closed in step text, 4 partial), review-count discrepancies, dedup false
negative reproduced (Jaccard 0.236/0.404 vs 0.7), session token and cost
profile, and whether /trekplan --brief docs/build-brief.md is a valid input
(it is not: FM_MISSING). Recommendation: revise the listed steps first, then
M1 GO. No change to plan.md.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
