Add macOS host receipts for 9 token-efficiency components + jcodemunch-mcp (issue #276) - #392

Scope

• Records use receipts on mac-coordinator-64gb-20260925 (macOS arm64) for nine
  token-efficiency-profile components this host previously had none for (rtk, serena, repomix,
  headroom, toon, ccusage, markitdown, mcporter, context-mode), plus jcodemunch-mcp, a
  token-efficiency-adjacent code-navigation alternative that is not itself a token-efficiency-profile
  member (adoption/manifest.json's token-efficiency profile does not list it;
  docs/token-efficiency-stack.md names jCodeMunch as outside the profile). rtk already has a
  macOS receipt on a different host (macos-m5pro-20260924); this PR adds the second Mac's receipt
  for it, not the first macOS receipt for rtk overall. Two other token-efficiency-profile members,
  codex and claude-code, still have no receipt on this host and remain out of scope here.
• Adds one E2E artifact README for a bounded readiness-audit child/worker run; reports coverage,
  MCP_AUTO_OPEN_ENABLED and pin/config findings from issue [mac-coordinator] other: report and apply the token-efficiency coverage check (#264) on mac-coordinator-64gb-20260925 #276.
• Post-review fixes (second update): six of the ten receipts and the E2E README were corrected
  after independent review found overstated claims, an unscoped command, or a privacy leak in the
  first recording. Every one of those six was recorded as a new, superseding generation (-2); no
  receipt file was hand-edited or removed for that round, per this repository's append-only evidence
  policy (docs/contributing-evidence.md step 3, "a receipt is never overwritten"). See
  Post-review supersedes, below, for what changed and why.
  One of those six, ccusage, is withdrawn outright in the third update instead of staying superseded
  -- see the next bullet.
• Privacy fix (third update): both ccusage generations recorded on this host are withdrawn --
  removed from this branch together with their manifests/evidence.json entries, because neither
  was ever merged to main -- and replaced with one fresh receipt at the same
  host/component/stage/date that never prints token totals, cost figures or which models were used
  (only ccusage's exit code, the parsed row count, field names, and two internal-consistency
  booleans). See Privacy fix, below, for what leaked and why.
• Rereview fixes (fourth update): an independent rereview found two more generation-1 receipts
  on this branch leaking the same way ccusage's did (jcodemunch-mcp, mcporter) and one receipt
  (ccusage) that, though private, had no check able to catch ccusage itself misreading the logs.
  This update withdraws the two newly found leaking families outright (same rule as the privacy
  fix), supersedes ccusage with a generation that adds a synthetic-fixture positive control, fixes
  a stale wording nit in the headroom receipt (generation 3), and corrects two statements this body
  itself made that were false at the third update's head. See
  Fourth update, below.
• Fifth update: a review of the fourth update's own changes found the fresh mcporter receipt
  it recorded still carried one stale, now-dangling sentence forward from generation 2 (a
  reference to the withdrawn generation 1's output, which no longer exists). Fixed the same
  wording-only way as headroom's generation 3: mcporter generation 2, commands unchanged. See
  Fifth update, below.
• Sixth update: a second, independent Opus re-review found the fourth/fifth updates' mcporter
  and ccusage fixes still had two problems. First, both the unsuffixed mcporter file and
  mcporter-2 quoted this host's real MCP server names in prose while explaining generation 1's
  withdrawal (the same class of leak generation 1 was withdrawn for), and mcporter-2 falsely
  claimed that withdrawn output "no longer exists anywhere in this repository." Second, the
  mcporter and ccusage families' reused -2 (and, for mcporter, unsuffixed) ids made their own
  history text self-contradictory: neither file said host_receipts.py had reassigned a freed
  suffix to an unrelated new recording. Fixed with two more superseding generations (mcporter -3,
  ccusage -3); no receipt file was hand-edited. See
  Sixth update, below.
• Round 3 (GPT-6): a cross-family review (gpt-6-astra) returned needs_changes at 506a524f. Fixed by withdrawing and cleanly re-recording the whole mcporter family, adding retained sanitized verifier evidence for the E2E README's tally, and superseding rtk to assert its printed config comparison. See Round 3 (GPT-6), below.
• Base commit at PR open: 50b9579f6722ddb0d751b81956c102046581c21b. Before the second update,
  origin/main (then at 5f3a7c21…) was merged into this branch with git merge (no conflicts in
  manifests/evidence.json; re-registered and re-derived through the documented --write commands),
  producing merge commit a4116d26093b16319c004933d02055930540edb9. Before the third update,
  origin/main had moved again (2 more commits: GPT-6 family tiering, an OmniRoute Codex profile);
  git merge origin/main auto-resolved manifests/evidence.json textually, but per the hot-file
  protocol that auto-merge was discarded for origin/main's own copy, this branch's 18 files were
  re-registered, and the two --write commands re-ran -- folded into merge commit
  e08a9b8c7fd99f6e07b897c9edbc3fd8dee4ec85. Before this fourth update, origin/main had moved yet
  again (2 more commits: an OmniRoute account-pool decision record, a landscape-sweep OmniRoute
  gateway commit); the same hot-file protocol was followed again, folded into merge commit
  024531521d5acb717960190cbe66f04f83ecbfd7. The fifth update's own fix commit sits directly on top
  of the fourth update's, no merge needed at that point; origin/main moved once more immediately
  afterward (one unrelated commit, a LongMemEval v4 driver under blueprints/memory-stack/, no path
  this PR owns), so the hot-file protocol was followed a third time -- origin/main's own
  manifests/evidence.json taken, this branch's 18 non-generated files re-registered, both --write
  commands re-run, folded into merge commit 8519f66d40c7dd9f4a307b2b251474f3ba53bc41 with
  git commit --amend. That was this branch's tip through the fifth update. Before this sixth
  update, origin/main had moved once more (one commit, token-layer routing/receipt-errata fixes
  from the 2026-09-27 verdict wave, 5b72d41c…, Token layer gaps: routing rules, recipe limits and E1/E2 receipt errata from the 2026-09-27 verdict wave #401); git merge origin/main --no-edit
  auto-merged manifests/evidence.json cleanly, but per the hot-file protocol that auto-merge was
  discarded regardless -- origin/main's own copy was taken, this branch's 20 non-generated files
  (the 18 above, plus this update's own two new receipts, recorded first) were re-registered, and
  both --write commands re-ran. Unlike earlier updates, this was not folded into the merge
  commit with --amend: the merge's parent, 8519f66d, was already pushed by the fifth update, so
  amending anything built on top of it would need a force-push. Instead the merge
  (8e40cacb3ef350f75e4099ed777d58647b1c7db5) stands on its own, and this update's fix (new
  receipts plus the re-registration) is its own ordinary commit on top,
  506a524fab8cf2b7409006118f79a7b11ee6a4f8, pushed normally (fast-forward from 8519f66d). This branch's tip was 506a524fab8cf2b7409006118f79a7b11ee6a4f8 through the GPT-6 review. Before the Round 3 (GPT-6) fix, origin/main had moved twice more (landscape-sweep worker isolation + repository-check fix, Claude harness settings); git merge origin/main --no-edit auto-merged manifests/evidence.json cleanly, but per the hot-file protocol that auto-merge was discarded regardless -- origin/main's own copy was taken, this branch's 20 non-generated files (17 unchanged, plus this update's re-recorded mcporter, rtk generation 3 and the new verifier-verdicts.json, recorded/added first) were re-registered, and both --write commands re-ran, folded into the merge commit with git commit --amend. This branch's current tip is 87b1b6158743ef390999954d91a9372f40c7bb0d; see Round 3 (GPT-6), below, for the full fix.
• Lane: lane:foundation
• Owned paths touched: evidence/hosts/mac-coordinator-64gb-20260925/,
  evidence/artifacts/mac-child-worker-e2e-20260927/, and the shared hot files
  manifests/evidence.json, catalogs/landscape/component-evidence-matrix.json,
  docs/component-evidence-matrix.md (regenerated only through their --write commands, per
  docs/lanes.md's hot-file protocol; no hand edits).

SOTA sources

This PR adds no new component and changes no pin; it records host evidence for components already
adopted at their current pins in manifests/stack.json / adoption/pins-macos-arm64.json, following
the recording process in docs/contributing-evidence.md (scripts/host_receipts.py record). Each
receipt's own commands and tool_versions cite the exact upstream release exercised:

The receipt commands and evidence-class boundaries (fixture workload vs. real host data) follow the
existing receipts this PR mirrors: evidence/hosts/nativestack-5975wx-20260925/* and
evidence/hosts/macos-m5pro-20260924/*-rtk-*.

Evidence-class table

Every receipt's evidence_class reasoning (why fixture-scale workloads are local_integration even
where the underlying tool ran for real) is spelled out in that receipt's own limitations[].

Post-review supersedes (generation 2)

An independent review of the first recording found problems in six of the ten new receipts. Each was
fixed by a new generation recorded with scripts/host_receipts.py record --supersedes <generation-1 id>. As recorded in this second update, generation 1 was kept, byte-identical, in every case --
that stopped being true starting with the third update (ccusage) and is also no longer true for two
more components as of the fourth update (jcodemunch-mcp, mcporter); see
Privacy fix and
Fourth update, below, for
which generation-1 files were later withdrawn and why. This sentence originally claimed to describe
the state at every later head too; it did not, and is corrected here rather than deleted so the
history stays legible.

markitdown and serena were reviewed and kept at generation 1 with no change (findings elsewhere in
this table cover their pin/scope caveats). repomix and toon had no findings against them.

Note on catalog_revision: as recorded in this second update, five generation-2 receipts
(context-mode, mcporter, rtk, jcodemunch-mcp, headroom) recorded this branch's own second-update
merge commit (a4116d26…, this branch's HEAD at record time) as their catalog_revision, not an
origin/main sha -- generation 1's receipts record 1aa9776…, which was on main. A supersede must
be recorded where generation 1 already exists, i.e. on this branch, so a branch-local
catalog_revision here is structural, not an error; host_receipts.py validate accepts it. That is
no longer the complete picture at this (fifth) update's head: jcodemunch-mcp no longer has any file
recording a4116d26… (both generations were withdrawn in the fourth update, and the fresh
generation-1 file that replaces it records the fourth update's own merge commit,
024531521d5acb717960190cbe66f04f83ecbfd7, instead); context-mode and rtk are unchanged and still
have a generation 2 recording a4116d26…; headroom has three generations -- generation 1 records
1aa9776…, generation 2 still records a4116d26…, and the fourth update's generation 3 records
024531521d5acb717960190cbe66f04f83ecbfd7. ccusage's generation 1 (the third update's fresh receipt)
records the third update's own merge commit, e08a9b8c…; its fourth-update generation 2 records
024531521d5acb717960190cbe66f04f83ecbfd7. mcporter no longer has any file recording a4116d26…
either: its fourth-update fresh generation 1 records 024531521d… (like jcodemunch-mcp's), and this
fifth update's generation 2 records 29eeab76b0e2bea8ba488c4f510cc8b2d86de613 (the fourth update's
own final merge-plus-fix commit, HEAD at that record time). All of these are branch-local,
structural, non-main commits for the same reason as above, and host_receipts.py validate accepts
every one of them.

Privacy fix (third update)

Generation 1 of the ccusage receipt (recorded in the first update, superseded in the second) printed
this host's real grand-total token count in the clear -- a real token total -- inside its own
command output, and both generations printed the list of Claude models this host actually used.
Generation 2's command output withheld the count, but its own limitations text restated that same
number in prose, and its command output still printed the model list: the same two leaks, still
published, one of them in a second place.

Neither generation was ever merged to main -- both existed only on this branch/PR -- so both are
withdrawn outright rather than superseded a third time: removed from this branch together with their
manifests/evidence.json files[] entries. Both carried only a self review, so no independent
review is lost by the removal. (Correction to Findings #6, below, from the second update: that
finding said generation 1 "cannot be un-published by this PR" and that its total "remains in this
branch's committed history" with no removal path; withdrawing an unmerged, self-reviewed-only receipt
turned out to be in scope after all.)

Where the withdrawn total can still be read, corrected (fourth update): an earlier version of
this paragraph said the value "remains recoverable from this branch's own earlier pushed commits
(3167e31c and before) until this PR is squash-merged and the branch deleted." A rereview found that
understated both where and for how long. Where: the value is not only in 3167e31c and earlier
-- it is also in e08a9b8c, the amended third-update merge commit itself, which is a parent of the
pushed head 16f53071 (and of every later head, including this update's). The git rm of both
leaking files happened after that merge commit was created and amended, so e08a9b8c's own tree
still holds both withdrawn ccusage files. For how long: a squash merge followed by deleting the
branch does not remove any of this from GitHub. GitHub keeps a pull request's commits reachable
through refs/pull/392/head and through the PR's own Commits tab regardless of the branch's state or
the merge method, so 3167e31c, e08a9b8c and every other pre-withdrawal commit on this PR stay
fetchable after merge and after branch deletion. Removing them takes a history rewrite (force-push)
of this branch plus a GitHub Support request to purge the PR's cached views and refs -- that is a
decision for the repository owner, weighing the exposure against rewriting a reviewed branch's
history, and this PR does not do it. The value was never on main and this PR does not put it there.
Checked, not merely assumed, this update: gh api reads (read-only) of this PR's issue comments (1),
review comments (0), reviews (0), and its GraphQL userContentEdits (4 prior description edits) all
came back clean of any bare 9-11-digit number and of any claude-opus-*/claude-haiku-* string --
the only prose match anywhere is claude-sonnet-5, the recorder's own model name, not a usage-model
leak. So the leak's only remaining public surface is the raw commit content itself (3167e31c and
e08a9b8c's trees, reachable via refs/pull/392/head and the Commits tab), not this PR's
description, its edit history, or any comment or review on it.

A single fresh receipt is recorded at the same host/component/stage/date
(mac-coordinator-64gb-20260925--ccusage--use--20260927.json; a new file, not an edit of either
withdrawn generation). Its command still runs the real offline daily report over this host's own
Claude Code logs, not a fixture, but publishes only: ccusage's own process exit code, the parsed row
count, the sorted field names present in a daily row and in the totals object (schema, never
values), and two internal-consistency booleans computed from the real per-category token values
without ever printing them. No token totals, no per-day or grand totals, no cost figures and no list
of models used appear anywhere in this receipt -- narrower than the Linux precedent
(nativestack-5975wx-20260925), which does publish the days-with-rows and the model list.

Checked every other receipt and artifact this branch touches for the same kind of leak:

• The two real numbers above and the model-mix strings do not appear anywhere else this branch added
  (git grep across every file this branch's diff against origin/main touches, and against this PR
  body's own text).
• evidence/artifacts/mac-child-worker-e2e-20260927/{receipt.json,README.md} publishes real
  per-child/per-model provider token counters (input/output/cache-read/cache-creation tokens). This
  matches an established, already-merged repository pattern for workflow child-usage measurement --
  for example evidence/artifacts/token-e2e-ultracode-20260925/receipt.json and
  evidence/artifacts/token-e2e-ultracode-laptop-20260926/receipt.json, both already on main -- and
  it carries no cost field; the README already declines to sum a combined total
  (docs/token-practice.md's "count once" rule). Left unchanged as a different, already-accepted
  evidence class from ccusage's account-level aggregation.

New head after this update: 16f53071ad65fd6bcae7bce85f4987411c017b3a.

Local commands run

$ uv run --no-project --python 3.13 python scripts/adoption_status.py --profile token-efficiency --client-wiring --pinned-versions --repo-root <checkout> --json
status=prerequisites_missing (platform.supported=false only), profile=prerequisites_present (13/13)
pinned_versions_match=false (codex, ai-memory mismatched; context-mode, socraticode unchecked -- no exec probe; 10 others matched)
client_wiring.complete=true (see Coverage, below, for the corrected per-scope detail)
exit 2 (adoption_status.py's documented exit for prerequisites_missing; see Coverage, below)

$ python3 scripts/host_receipts.py validate
{"receipts": 183, "status": "passed"}

$ python3 scripts/component_matrix.py --write && python3 scripts/component_matrix.py --check
{"flip_rule_violations": 0, "rows": 32, "status": "written"}
{"rows": 32, "status": "checked"}

$ python3 scripts/new_host_grand_list.py --write && python3 scripts/new_host_grand_list.py --check
{"status": "written", "layers": 32, "winners": 66}
{"status": "passed", "layers": 32, "winners": 66}

$ python3 scripts/validate.py
{"components": 69, "hashed_files": 7268, "profiles": 4, "receipts": 159, "status": "passed"}
Integrity and scope checks only; no live provider or GPU execution.

$ git diff --check
(no output, exit 0)

$ git diff --stat origin/main...HEAD
21 files changed, 1739 insertions(+), 27 deletions(-)
(as recorded in this second update only -- includes both commits: the original 10 receipts + E2E
artifact, and this update's 6 generation-2 receipts + the corrected README + their manifest/matrix
registrations; every generation-1 receipt file was present unchanged alongside its generation-2
successor **at this point**. That stopped being true in later updates -- see
[Fourth update](#fourth-update-two-more-withdrawals-a-positive-control-and-corrections), below, for
the current, accurate `git diff --stat origin/main...HEAD`.)

$ gitleaks dir evidence/hosts/mac-coordinator-64gb-20260925 --no-banner --redact
no leaks found

$ gitleaks dir evidence/artifacts/mac-child-worker-e2e-20260927 --no-banner --redact
no leaks found

This (third) update's own commands:

$ git merge origin/main --no-edit
Auto-merging manifests/evidence.json
Merge made by the 'ort' strategy.
(manifests/evidence.json then replaced with origin/main's own copy per the hot-file protocol; this
branch's 18 files re-registered with host_receipts.py's register_file; both --write commands re-run;
folded into the merge commit with `git commit --amend`)

$ git rm evidence/hosts/mac-coordinator-64gb-20260925/mac-coordinator-64gb-20260925--ccusage--use--20260927.json evidence/hosts/mac-coordinator-64gb-20260925/mac-coordinator-64gb-20260925--ccusage--use--20260927-2.json
(both withdrawn generations removed; their manifests/evidence.json entries dropped by the same edit)

$ python3 scripts/host_receipts.py record --host-id mac-coordinator-64gb-20260925 \
  --platform-id macos-arm64 --component-id ccusage --stage use --evidence-class native_proven \
  --layer-ref foundation/token-efficiency --second-physical-machine \
  --hardware-profile-ref mac-coordinator-64gb-20260925 --model claude-sonnet-5 \
  --cmd <version/pin check, unchanged from generation 1> \
  --cmd <counts-free daily-report check: exit code, row count, field names, consistency booleans> \
  --claim "..." --limitation "..." [x6]
evidence/hosts/mac-coordinator-64gb-20260925/mac-coordinator-64gb-20260925--ccusage--use--20260927.json

$ python3 scripts/component_matrix.py --write && python3 scripts/component_matrix.py --check
{"flip_rule_violations": 0, "rows": 32, "status": "written"}
{"rows": 32, "status": "checked"}

$ python3 scripts/new_host_grand_list.py --write && python3 scripts/new_host_grand_list.py --check
{"status": "written", "layers": 32, "winners": 66}
{"status": "passed", "layers": 32, "winners": 66}

$ python3 scripts/host_receipts.py validate
{"receipts": 182, "status": "passed"}

$ python3 scripts/validate.py
{"components": 69, "hashed_files": 7271, "profiles": 4, "receipts": 159, "status": "passed"}
Integrity and scope checks only; no live provider or GPU execution.

$ git diff --check
(no output, exit 0)

$ gitleaks dir evidence/hosts/mac-coordinator-64gb-20260925 --no-banner --redact
no leaks found

$ gitleaks dir evidence/artifacts/mac-child-worker-e2e-20260927 --no-banner --redact
no leaks found

Value-free client-config check (second update): the five paths a plugin, hook or MCP server
registration on this host could write were checked by mtime against the mcporter generation-1 run's
own observed_at_utc (2026-09-27T07:19:50Z); all five present paths predate it and none postdate it:

Fourth update: two more withdrawals, a positive control, and corrections

An independent rereview of the third update (two lenses: an evidence lens and a security lens) found
four should_fix items, confirmed and fixed here, plus cheap nits.

1. Two more generation-1 receipts leaked the same way ccusage's did, and were still kept at HEAD.
   jcodemunch-mcp generation 1 printed the tool's unmasked repo identifier, whose last 8 hex
   characters are a truncated sha1 of this host's absolute checkout path -- combined with the printed
   basename (this worktree's own name), that narrows an offline guess of the parent directory and
   username. mcporter generation 1 published this host's live MCP client configuration: server names,
   tool counts and source config files from ~/.claude.json / ~/.codex/config.toml. Both components
   already had a generation 2 that fixed the leak (masking the hash suffix; an isolated scratch
   mcporter.json), but generation 1 itself was never withdrawn, so the leak stayed published. Fix:
   the same rule already used for ccusage -- an unmerged branch may drop a leaking receipt generation
   together with its manifests/evidence.json entry. Both generations of each family are withdrawn
   (generation 2 carried no leak of its own; it is removed only so its supersedes link never points
   at a deleted receipt), and each component is re-recorded as one fresh, clean generation 1 that
   reruns generation 2's already-fixed commands live (read from the JSON and re-executed, not
   retyped) and carries its claim and remaining limitations forward, with the first limitation
   rewritten to describe the withdrawal. Both families verified leak-free by direct substring search
   of the new files for the unmasked hash suffix and the live-inventory strings, and by gitleaks dir
   over the whole evidence directory (clean).

2. The ccusage receipt had no check that could catch ccusage misreading the logs. Its real-host
   command's two booleans compare ccusage's own report fields against each other (per-day and grand
   totals against their own category fields) -- internal arithmetic, not an independently known
   answer. A misread that shifted a token count without breaking that internal arithmetic would still
   pass. Fix: superseded with a generation 2 that adds a synthetic, made-up four-row fixture (mirroring
   nativestack-5975wx-20260925's ccusage receipt: two UTC days, one message repeated with the same
   ids to exercise deduplication) written under a scratch CLAUDE_CONFIG_DIR, and asserts the parsed
   per-day and grand totals equal the hand-computed values exactly, that --since keeps only the
   later day, and that an empty projects directory reports zero rows and zero tokens. The real-host
   command is otherwise unchanged and stays count-only: no token totals, costs or model mix are
   printed, retained or asserted anywhere in either command. The real-host command also now prints a
   one-line SUMMARY with all four decision-relevant booleans first, so they survive the 400-character
   excerpt cap regardless of the verbose field-name dump that follows (the same gap the rtk -2
   generation fixed for its own excerpt). Recorded with --supersedes, not a withdrawal, since
   generation 1 carries no leak. The fixture half is local_integration evidence (an owned synthetic
   fixture) inside a receipt whose overall evidence_class stays native_proven because of its
   real-host half, matching the Linux precedent's own shape.

3. headroom generation 2's limitation text was stale. It said this host's configured headroom MCP
   entry "is separately exercised" by the mcporter receipt; that was never true (mcporter always
   called headroom through an ad-hoc/scratch bridge, never this host's live config) and is more
   obviously stale now that the mcporter receipt has been fully withdrawn and re-recorded. Fix:
   generation 3, commands unchanged (re-run and still pass), with that one limitation sentence
   corrected.

4. Two statements in this PR body were false at head 16f53071. "Generation 1 is kept,
   byte-identical, in every case" (Post-review supersedes section) and the second update's
   git diff --stat note both stopped being accurate once ccusage's generation 1 was withdrawn in the
   third update, and are now also inaccurate for jcodemunch-mcp and mcporter. Both statements are kept
   in place, above, but labeled as describing the second update's state only, with a pointer to this
   section. The current, accurate stat against this update's own head:

   $ git diff --stat origin/main...HEAD
   20 files changed, 1679 insertions(+), 27 deletions(-)
   

   (15 receipt files under evidence/hosts/mac-coordinator-64gb-20260925/, the 2 E2E artifact files,
   manifests/evidence.json, and the 2 generated matrix files. jcodemunch-mcp and mcporter each
   contribute one file, not two: their leaking generation 1 and its generation 2 are both gone,
   replaced by one fresh file. ccusage contributes two: its third-update generation 1, unchanged, and
   this update's new generation 2. headroom contributes three: generations 1, 2 and 3. Every other
   component (context-mode, markitdown, repomix, rtk, serena, toon) is unchanged from the third
   update.)

5. This PR body understated where the withdrawn ccusage total can still be read, and for how long.
   See
   Where the withdrawn total can still be read, corrected
   in the Privacy fix section, above, and the updated Findings Qualify native recovery and a pinned local GPU workflow #6, below, for the correction: the
   value is also in e08a9b8c (not only 3167e31c and earlier), and neither a squash merge nor
   deleting the branch removes it from GitHub's refs/pull/392/head or the PR's Commits tab -- purging
   it needs a force-push of this branch plus a GitHub Support request, which is the repository owner's
   decision, not done here.

Nits also fixed: "a specific 10-digit number" reworded to "a real token total" (Findings #6 and
the Privacy fix section, above -- the order of magnitude of a real usage figure is itself worth not
publishing); "see Coverage, above" corrected to "see Coverage, below" (Coverage starts well below that
line, not above it).

Nits considered and left open (not cheap/safe enough to fold into this update, or someone else's
call): the rtk receipts' commands do not set RTK_TELEMETRY_DISABLED=1 / RTK_DB_PATH the way
scripts/native_token_ci.py does, so replaying them from a plain shell could write to this host's
real rtk telemetry/history -- fixing this means changing rtk's actual commands, which is a functional
change, not a wording nit, and rtk is outside this update's two confirmed leaks; the context-mode
receipt's retained excerpt keeps a workflow/subagent id from this recording session's own transcript,
which the original rereview called optional/low-sensitivity.

Local commands run for this update (from this branch's checkout, ecosystem bin first on PATH):

$ git merge origin/main --no-edit
(auto-merged cleanly this time; manifests/evidence.json still replaced with origin/main's own copy
per the hot-file protocol regardless, this branch's 17 non-generated files re-registered with
host_receipts.py's register_file, both --write commands re-run, folded into merge commit
024531521d5acb717960190cbe66f04f83ecbfd7 with `git commit --amend`)

$ git rm evidence/hosts/mac-coordinator-64gb-20260925/mac-coordinator-64gb-20260925--jcodemunch-mcp--use--20260927.json evidence/hosts/mac-coordinator-64gb-20260925/mac-coordinator-64gb-20260925--jcodemunch-mcp--use--20260927-2.json evidence/hosts/mac-coordinator-64gb-20260925/mac-coordinator-64gb-20260925--mcporter--use--20260927.json evidence/hosts/mac-coordinator-64gb-20260925/mac-coordinator-64gb-20260925--mcporter--use--20260927-2.json
(all four withdrawn generations removed; their manifests/evidence.json entries dropped by the same edit)

$ python3 scripts/host_receipts.py record ... --component-id jcodemunch-mcp ... [generation 2's exact commands, claim; --limitation rewritten for the withdrawal]
evidence/hosts/mac-coordinator-64gb-20260925/mac-coordinator-64gb-20260925--jcodemunch-mcp--use--20260927.json

$ python3 scripts/host_receipts.py record ... --component-id mcporter --layer-ref foundation/mcp-surfaces ... [generation 2's exact commands, claim; --limitation rewritten for the withdrawal]
evidence/hosts/mac-coordinator-64gb-20260925/mac-coordinator-64gb-20260925--mcporter--use--20260927.json

$ python3 scripts/host_receipts.py record ... --component-id ccusage --layer-ref foundation/token-efficiency --supersedes mac-coordinator-64gb-20260925--ccusage--use--20260927 ... [version check, new fixture-control command, real-host command with SUMMARY line added]
evidence/hosts/mac-coordinator-64gb-20260925/mac-coordinator-64gb-20260925--ccusage--use--20260927-2.json

$ python3 scripts/host_receipts.py record ... --component-id headroom --layer-ref foundation/token-efficiency --supersedes mac-coordinator-64gb-20260925--headroom--use--20260927-2 ... [generation 2's exact commands, claim; one limitation sentence corrected]
evidence/hosts/mac-coordinator-64gb-20260925/mac-coordinator-64gb-20260925--headroom--use--20260927-3.json

$ python3 scripts/host_receipts.py validate
{"receipts": 182, "status": "passed"}

$ python3 scripts/component_matrix.py --write && python3 scripts/component_matrix.py --check
{"flip_rule_violations": 0, "rows": 32, "status": "written"}
{"rows": 32, "status": "checked"}

$ python3 scripts/new_host_grand_list.py --write && python3 scripts/new_host_grand_list.py --check
{"status": "written", "layers": 32, "winners": 66}
{"status": "passed", "layers": 32, "winners": 66}

$ python3 scripts/validate.py
{"components": 69, "hashed_files": 7309, "profiles": 4, "receipts": 159, "status": "passed"}
Integrity and scope checks only; no live provider or GPU execution.

$ git diff --check
(no output, exit 0)

$ gitleaks dir evidence/hosts/mac-coordinator-64gb-20260925 --no-banner --redact
no leaks found

New head after this update: 29eeab76b0e2bea8ba488c4f510cc8b2d86de613.

Fifth update: one more dangling reference, caught by review

A review of the fourth update's own changes found that the fresh mcporter receipt (recorded that
update to replace both withdrawn leaking generations) carried generation 2's second limitation
forward verbatim: "this host's other real configured MCP servers (named in generation 1's
now-superseded output) were deliberately not touched by this generation." Generation 1 was
withdrawn outright in the fourth update, not superseded, and no such output exists anywhere in
this repository any more -- the same class of stale cross-reference already fixed for headroom's
generation 3 earlier in the fourth update, just missed for mcporter at the time. Fixed the same
way: mcporter generation 2 (commands rerun live, unchanged, still pass), only that one limitation
sentence corrected. jcodemunch-mcp's carried-over limitations were checked individually and carry
no equivalent stale reference.

This makes two statements elsewhere in this body stale in turn, the same way finding 4 (fourth
update) described for two earlier statements: the fourth update's "current, accurate"
git diff --stat (now one file larger) and its "jcodemunch-mcp and mcporter each have exactly one
generation again" (no longer true for mcporter). Both are left in place, above, labeled as
describing the fourth update's state, with the corrected figures here:

$ git diff --stat origin/main...HEAD
21 files changed, 1754 insertions(+), 27 deletions(-)

(mcporter now contributes two files again -- the fourth update's fresh generation 1, plus this
generation 2 -- for the same structural reason ccusage and headroom do: a wording-only fix is
recorded as a new generation, never a hand edit.)

Local commands run:

$ python3 scripts/host_receipts.py record --host-id mac-coordinator-64gb-20260925 \
  --platform-id macos-arm64 --component-id mcporter --stage use --evidence-class native_proven \
  --layer-ref foundation/mcp-surfaces --second-physical-machine \
  --hardware-profile-ref mac-coordinator-64gb-20260925 --model claude-sonnet-5 \
  --supersedes mac-coordinator-64gb-20260925--mcporter--use--20260927 \
  --cmd <generation 1's exact version/pin check, unchanged> \
  --cmd <generation 1's exact isolated-scratch-config list/call check, unchanged> \
  --claim "..." --limitation "..." [x6, one sentence corrected]
evidence/hosts/mac-coordinator-64gb-20260925/mac-coordinator-64gb-20260925--mcporter--use--20260927-2.json

$ python3 scripts/host_receipts.py validate
{"receipts": 183, "status": "passed"}

$ python3 scripts/component_matrix.py --write && python3 scripts/component_matrix.py --check
{"flip_rule_violations": 0, "rows": 32, "status": "written"}
{"rows": 32, "status": "checked"}

$ python3 scripts/new_host_grand_list.py --write && python3 scripts/new_host_grand_list.py --check
{"status": "written", "layers": 32, "winners": 66}
{"status": "passed", "layers": 32, "winners": 66}

$ python3 scripts/validate.py
{"components": 69, "hashed_files": 7310, "profiles": 4, "receipts": 159, "status": "passed"}
Integrity and scope checks only; no live provider or GPU execution.

$ git diff --check
(no output, exit 0)

New head right after the mcporter fix: 10a50c31cff33e438de5059c872f653374c0a1e6. origin/main
then moved once more (see the Scope section's "Base commit at PR open" bullet for the hot-file-protocol
re-merge that followed); this branch's current tip is 8519f66d40c7dd9f4a307b2b251474f3ba53bc41,
verified with the same five commands again after the re-merge (host_receipts.py validate: 183
receipts, passed; component_matrix.py --check / new_host_grand_list.py --check: unchanged, 32
rows/layers, 66 winners, 0 flip-rule violations; validate.py: 7338 hashed files, passed;
git diff --check: clean).

Sixth update: a second rereview's prose-leak and id-reuse corrections

A second, independent Opus re-review of the fourth/fifth updates' mcporter and ccusage fixes
found three remaining problems, all in receipt text, none in commands or results:

1. The prose explaining generation 1's withdrawal still leaked it. Both the unsuffixed
   mcporter file and mcporter-2 named this host's real MCP server names in describing why
   generation 1's bare mcporter list leaked them -- the same class of leak generation 1 was
   withdrawn for in the fourth update. Fixed in the new generation by naming no server anywhere:
   it says only that generation 1 printed the list, and points to where that list remains
   readable instead of repeating it -- unedited, in this family's unsuffixed and -2 files,
   still present in this branch's tree at every commit including this one (this repository's
   append-only evidence policy keeps older generations on disk; only a family's latest generation
   counts as a host's evidence); and, as raw command output rather than prose, at every commit in
   this branch's own history before 29eeab76 and in GitHub's copy of this pull request,
   regardless of the branch's later state, until the repository owner purges it (a force-push
   rewrite of this branch plus a GitHub Support request -- a decision for the owner, not made
   here). This corrects the Checklist's "even after the branch tip stopped publishing it"
   claim, below: that is true for the withdrawn ccusage total/model list and the jcodemunch-mcp
   repo-id hash, but not, until this correction, for mcporter -- the branch tip has kept
   publishing the server-name leak in prose all along, in the two files this update leaves
   unedited.
2. mcporter-2 misstated what remains. It said the withdrawn generation 1's output "no longer
   exists anywhere in this repository." It does -- see point 1, above.
3. Reused ids made both families' receipts contradict themselves.
   scripts/host_receipts.py's next_free_superseding_id assigns the lowest free -N suffix, so
   once a generation is withdrawn (its file deleted), a later recording at the same
   host/component/stage/date can land on that same freed id. mcporter-2 carried the unsuffixed
   file's sentence forward verbatim, so read as mcporter-2's own text it said its own id "was
   removed together with its evidence.json entry" -- true only of the different, original file
   that once held -2 -- and it called its own next limitation already corrected when that
   sentence carried the false claim from point 2. It also labeled its catalog_revision
   "post-merge," although this branch is an open, unmerged pull request. Separately, ccusage's
   unchanged unsuffixed file describes the leak of the original, withdrawn -2 (deleted in the
   third update, commit 16f53071) in its own second limitation; that -2 id was later
   reassigned by next_free_superseding_id to the clean, fixture-adding generation from the
   fourth update, and neither file said the id had been reused. Fixed by stating the reuse
   plainly, and dropping "post-merge," in both new generations' text.

Two new, superseding generations, each with the same host, platform, commands, claim, evidence
class, layer-refs and --second-physical-machine as the -2 it supersedes -- only the affected
limitations entries change:

• mac-coordinator-64gb-20260925--mcporter--use--20260927-3 (supersedes -2; limitations[0] and
  [1] rewritten, four unchanged)
• mac-coordinator-64gb-20260925--ccusage--use--20260927-3 (supersedes -2; limitations[0] and
  [3] rewritten, four unchanged)

No receipt file was hand-edited or removed; git diff confirms no existing evidence/hosts/ file
changed. Both new generations' commands were rehearsed live before recording, then recorded
immediately after: mcporter's rehearsal matched the -2 generation's own result exactly
(list_rc=0 call_rc=0 stats_keys_ok=True new_pids=[] config_files_unchanged=yes); ccusage's fixture
half matched exactly (exact_match=True since_narrows=True empty_dir_zero=True) and its real-host
half stayed internally consistent (per_day_ok=True grand_ok=True has_cost=False).

origin/main had moved once more since the fifth update (one commit, token-layer routing and
receipt-errata fixes from the 2026-09-27 verdict wave, 5b72d41c, #401); merged with git merge origin/main --no-edit (8e40cacb3ef350f75e4099ed777d58647b1c7db5, auto-merged
manifests/evidence.json cleanly). Per the hot-file protocol that auto-merge was discarded
regardless: origin/main's own manifests/evidence.json was taken and this branch's 20
non-generated files (18 pre-existing, plus this update's own two new receipts, recorded first so
catalog_revision reflects the merged tree) were re-registered with host_receipts.py's
register_file, then both --write commands re-ran (new-host-grand-list unchanged: 32 layers,
66 winners). This update's fix is its own commit on top of the merge, not folded into it with
--amend, since the merge's parent (8519f66d) was already pushed by the fifth update.

$ git merge origin/main --no-edit
Auto-merging manifests/evidence.json
Merge made by the 'ort' strategy.

$ python3 scripts/host_receipts.py record --host-id mac-coordinator-64gb-20260925 \
  --platform-id macos-arm64 --component-id mcporter --stage use --evidence-class native_proven \
  --layer-ref foundation/mcp-surfaces --second-physical-machine \
  --hardware-profile-ref mac-coordinator-64gb-20260925 --model claude-sonnet-5 \
  --supersedes mac-coordinator-64gb-20260925--mcporter--use--20260927-2 \
  --cmd <generation 2's exact commands, unchanged> --claim "..." --limitation "..." [x6, 2 rewritten]
evidence/hosts/mac-coordinator-64gb-20260925/mac-coordinator-64gb-20260925--mcporter--use--20260927-3.json

$ python3 scripts/host_receipts.py record --host-id mac-coordinator-64gb-20260925 \
  --platform-id macos-arm64 --component-id ccusage --stage use --evidence-class native_proven \
  --layer-ref foundation/token-efficiency --second-physical-machine \
  --hardware-profile-ref mac-coordinator-64gb-20260925 --model claude-sonnet-5 \
  --supersedes mac-coordinator-64gb-20260925--ccusage--use--20260927-2 \
  --cmd <generation 2's exact commands, unchanged> --claim "..." --limitation "..." [x6, 2 rewritten]
evidence/hosts/mac-coordinator-64gb-20260925/mac-coordinator-64gb-20260925--ccusage--use--20260927-3.json

$ git checkout origin/main -- manifests/evidence.json
$ python3 -c 'import sys; from pathlib import Path; sys.path.insert(0, "scripts"); import host_receipts
for p in sys.argv[1:]: host_receipts.register_file(Path("."), p)' <this branch's 20 files>

$ python3 scripts/component_matrix.py --write && python3 scripts/component_matrix.py --check
{"flip_rule_violations": 0, "rows": 32, "status": "written"}
{"rows": 32, "status": "checked"}

$ python3 scripts/new_host_grand_list.py --write && python3 scripts/new_host_grand_list.py --check
{"status": "written", "layers": 32, "winners": 66}
{"status": "passed", "layers": 32, "winners": 66}

$ python3 scripts/host_receipts.py validate
{"receipts": 185, "status": "passed"}

$ python3 scripts/validate.py
{"components": 69, "hashed_files": 7342, "profiles": 4, "receipts": 159, "status": "passed"}
Integrity and scope checks only; no live provider or GPU execution.

$ git diff --check
(no output, exit 0)

$ grep -n 'openaiDeveloperDocs\|node_repl\|socraticode\|/Users/\|post-merge' <the two new receipt files>
(no output on either file; exit 1 -- no hits)

New head after this update: 506a524fab8cf2b7409006118f79a7b11ee6a4f8.

Round 3 (GPT-6)

GPT-6 cross-family review at 506a524fab8cf2b7409006118f79a7b11ee6a4f8 (verdict needs_changes).
Three findings, mapped to fixes:

1. Medium -- active configuration remains published (mcporter unsuffixed:43, -2:43). At
   506a524f, the mcporter family had three files on disk: the unsuffixed file and -2 (recorded
   in the fourth/fifth updates; both fresh recordings, not the original leaking file, but each
   retold in prose why a still-earlier recording -- deleted before commit
   29eeab76b0e2bea8ba488c4f510cc8b2d86de613, still readable in this branch's history before it --
   had leaked, and that retelling itself named this host's real MCP server names), and -3 (sixth
   update; described the same history only in the abstract, naming no server). GPT-6 confirmed only
   the unsuffixed file and -2 name servers; -3 does not. Owner-delegated decision, accepted by
   GPT-6: withdraw the whole family -- all three files, together with their
   manifests/evidence.json entries -- and record one fresh generation with -3's exact commands
   and arguments, --supersedes omitted. Fixed: all three withdrawn; one new receipt recorded at
   the freed unsuffixed id (the third time this family has occupied that slot); its limitations name
   no server anywhere, state plainly that the unsuffixed file and -2 are what leaked and why, that
   -3 is withdrawn only for supersede-chain integrity, and that all three withdrawn files remain
   readable, byte-for-byte, in this branch's git history before this update's commit (still no
   purge -- the owner's standing decision, which GPT-6's review also found no reason to override:
   "I found no credential or direct identity requiring a purge in the reviewed PR history"). headroom's
   own generation-3 cross-reference to "the mcporter receipt" is prose-only, names no id and no
   server, and needed no change.
   • New receipt:
     evidence/hosts/mac-coordinator-64gb-20260925/mac-coordinator-64gb-20260925--mcporter--use--20260927.json
     (a fourth recording at this id across the PR's history; no supersedes field, since every
     prior generation in the family was removed first).
2. Medium -- E2E verdict tally lacked retained evidence (README.md:40).
   mac-child-worker-e2e-20260927/README.md's 88/83/4/1/0 verifier tally, and the
   workflow-status deduction that depends on it (Finding 5, above), had no retained verifier
   evidence backing them. Option (a): recovered the verify phase's own output from this session's
   readiness-audit workflow journal (run wf_a6b18951-948, verify child a3829f24d409b7123 --
   confirmed against receipt.json's transcript_dir and every reader/verifier agent_id),
   sanitized it to a new file, evidence/artifacts/mac-child-worker-e2e-20260927/verifier-verdicts.json
   (per claim: a positional id, its verdict, and a short cited-source label; a claim_source_note
   distinguishing this repository's tracked files from this run's own synthetic
   issue-382.md/issue-276.md input fixtures; an id_note stating the ids are positional, not
   carried from the raw output), registered it, and updated the README to cite it. A recount script
   confirms the README's tally matches the file's own verdicts[] array exactly: 83 confirmed, 4
   corrected, 1 unverifiable, 0 refuted, 88 total.
3. Low -- RTK comparison observed but not asserted (rtk -2:69). Command 2 printed the
   host-config-vs-fixture comparison (equals_fixture=...) but gated its own exit code only on the
   five probe mismatches, so a diverging host config would still exit 0. Rehearsed a fix locally,
   including a negative control against a deliberately mismatched fixture (confirmed the unfixed
   logic would exit 0 regardless, and the fixed logic correctly exits 1), then recorded a
   superseding generation with the same host/platform/component/stage/evidence-class/
   --second-physical-machine/model/layer-ref/--component-version 0.50.0 --allow-unbound-version
   as -2; only command 2 changed (it now also asserts eq_bool = "True"), commands 1 and 3-6 are
   unchanged and rerun live.
   • New receipt:
     evidence/hosts/mac-coordinator-64gb-20260925/mac-coordinator-64gb-20260925--rtk--use--20260927-3.json
     (supersedes -2).

Also merged origin/main (2 more commits: landscape-sweep worker isolation + repository-check fix
548341209f9ad3034649615521312092ff5ac92b, Claude harness settings
d022295a14ac8c4aeb00e7191b93740e6c6a4851) per the hot-file protocol: took origin/main's
manifests/evidence.json, re-registered this branch's 20 files with host_receipts.py's
register_file (the family's 3 removed mcporter generations are no longer registered; the new
mcporter and rtk-3 files, verifier-verdicts.json and the updated README are), and re-ran both
--write commands.

Full re-verification at this update's head: host_receipts.py validate (184 receipts, passed --
net -1 from 185: -3 mcporter generations, +1 fresh mcporter, +1 rtk generation 3), validate.py
(7343 hashed files, passed), component_matrix.py --check / new_host_grand_list.py --check
(unchanged: 32 rows/layers, 66 winners, 0 flip-rule violations), git diff --check (clean).
Grepped evidence/hosts/mac-coordinator-64gb-20260925/ and
evidence/artifacts/mac-child-worker-e2e-20260927/ for openaiDeveloperDocs, node_repl,
socraticode and /Users/: no hits in any file this branch added or changed. One hit remains,
outside this branch's diff: mac-coordinator-64gb-20260925--socraticode--use--20260925.json, a
pre-existing, already-merged receipt from #253 (commit 8c7b7f3b, on main before this branch
existed), where the word is that receipt's own component under test
("component_id": "socraticode"), not the configuration-disclosure pattern this check targets --
flagged here so the reviewer doesn't rediscover it.

Corrections to earlier sections, left in place per this PR body's own append-only convention:

• The Checklist's secrets bullet, below: "this branch's own unsuffixed and -2 mcporter files kept
  publishing it in prose... and those two unedited files still carry the quoted names today" was
  accurate as of the sixth update; as of this update, both files are withdrawn along with -3, and
  the fresh replacement names no server. The withdrawn content remains readable pre-this-commit, per
  the paragraph above.
• The Evidence-class table and Post-review-supersedes table's mcporter/rtk path references, below,
  are updated in place to the current file names (this PR's evidence itself stays append-only; the
  historical narrative describing what each past generation said is left as-is).

New head after this update: 87b1b6158743ef390999954d91a9372f40c7bb0d.

Decision record

None new; this PR follows the existing recording process in docs/contributing-evidence.md and the
staged single-writer sequencing in issue #276 / #383.

Host evidence

• python3 scripts/host_receipts.py validate passes for every new/changed receipt (185 total
  after the sixth update's mcporter and ccusage generation 3 (+2 from the fifth update's 183);
  183 total after the fifth update's mcporter generation 2; 182 from the third update through
  the fourth one, unchanged in count: jcodemunch-mcp and mcporter each had their leaking
  generation 1 and its generation 2 withdrawn (-4) and replaced one-for-one by one fresh
  generation 1 (+2), and ccusage and headroom each gained one new generation (+2) -- net zero;
  183 before the third update's ccusage withdrawal removed 2 files and added 1 fresh one back,
  so 183 then was the same number for an unrelated reason). Round 3 (GPT-6) brings the total to 184: the mcporter family's 3 generations (unsuffixed, -2, -3) are withdrawn and replaced by 1 fresh recording (net -2), and rtk gains a generation 3 (+1) -- see Round 3 (GPT-6), below.
• Independent review is recorded (scripts/host_receipts.py review) or explicitly requested in
  this PR: review was explicitly requested and performed on the first recording (see Post-review
  supersedes, above, and Review, below); every receipt here still carries only a self review of
  its own generation so far, pending the Opus/GPT-6 passes named under Review.
• No platform_status change is made from a host receipt alone: this PR touches no
  catalogs/landscape/*.json winners[].platform_status field, and
  component_matrix.py --write reports flip_rule_violations: 0. Of the ten
  components this PR adds receipts for, as of the sixth (current) update: context-mode and rtk
  each still have a generation-1 + generation-2 pair, unchanged since the second update; headroom
  has three generations (1, 2 and 3, the fourth update's wording-only fix); ccusage has three
  generations -- generation 1 is the third update's fresh, counts-free recording (neither
  original generation is generation 1; both were withdrawn in the third update), generation 2 is
  the fourth update's fixture-control addition, and this sixth update adds generation 3, a
  wording-only fix stating plainly that generation 2's own id was reused from a different,
  withdrawn file; mcporter has three generations for a parallel reason -- its original generation
  1 and its generation 2 were both withdrawn in the fourth update and replaced by one fresh
  generation 1, the fifth update added its own generation 2 (a wording-only fix, a dangling
  reference to the withdrawn generation 1), and this sixth update adds generation 3 (wording-only:
  no longer quotes generation 1's leaked server names in prose, states that generation 2's own id
  was reused, and stops calling its catalog_revision "post-merge"); jcodemunch-mcp has exactly one
  generation (same fourth-update withdrawal and replacement as mcporter, with no later fix needed
  -- its carried-over limitations were checked individually and none referenced the withdrawn
  generation, and this sixth update's rereview found no equivalent leak-in-prose in its text).
  markitdown, repomix, serena and toon are unchanged single-generation receipts. Five
  components are native_proven (rtk, serena,
  jcodemunch-mcp, ccusage, mcporter) and five are local_integration (repomix, headroom, toon,
  markitdown, context-mode). context-mode's generation 1 recorded result: fail; only
  generation 2 counts as this host's evidence for it, and only each component's latest
  generation counts as this host's evidence for it in general (docs/contributing-evidence.md:
  only the latest generation speaks for a host/component/stage/date).

Host request: #276

Coverage and configuration (issue #276)

• Ran fresh in this session, from this branch's checkout, with the ecosystem bin first on PATH:
  uv run --no-project --python 3.13 python scripts/adoption_status.py --profile token-efficiency --client-wiring --pinned-versions --repo-root <checkout> --json. status prerequisites_missing
  -- only because platform.supported is false (the manifest declares linux-x86_64
  supported, not macos-arm64); the token-efficiency profile itself reports
  prerequisites_present, 13/13 commands present.
• client_wiring.complete: true, through the documented either-scope rule
  (docs/token-efficiency-stack.md's "Coverage check": every Codex server named in either the user
  or the project config.toml). The actual per-scope values from this run, corrected from an earlier
  draft of this PR body that misstated the project scope as all-true:
  • claude.rtk_hook: true; claude.context_mode_plugin_enabled: true.
  • codex.mcp_servers_present (this host's real, user-scope ~/.codex/config.toml): {"serena": true, "socraticode": true, "ai-memory": true}.
  • project.codex_mcp_servers_present (this worktree's .codex/config.toml, which does not exist):
    {"serena": false, "socraticode": false, "ai-memory": false} -- read_client_file reads an
    absent file as {}, so every project-scope server reads false here. complete is still true
    because the rule accepts either scope, and the user scope supplies all three.
  • This matches the complete: true this host's [mac-coordinator] other: Stage 1 client layer on the 64 GB Mac (no service changes) #382 (Stage 1 client layer) step already reported;
    this run reconfirms it live from the current checkout rather than repeating that report.
• pinned_versions_match: false: codex (pinned 0.155.1, resolves 0.158.0-alpha.2.1) and
  ai-memory (pinned 2.3.2, resolves 2.4.0) mismatch; context-mode and socraticode are
  unchecked (no exec-type version probe for either in adoption/pins-macos-arm64.json); the other
  ten checked components (claude-code, rtk, repomix, headroom, toon, ccusage, qmd,
  markitdown, serena, mcporter) match their pins. This criterion was not run in the PR's
  original coverage check; it is now.
• MCP_AUTO_OPEN_ENABLED: configured false in both required places (value-free booleans) --
  Claude Code's user settings.json env.MCP_AUTO_OPEN_ENABLED and Codex's
  config.toml [shell_environment_policy.set].

Findings (not fixed by this PR, except where noted)

1. mise's rtk 0.49.0 still resolves first on a plain shell PATH. With the ecosystem bin
   prepended, rtk --version is 0.50.0 (the pin); on a plain PATH (mise shims only, no ecosystem
   bin), command -v rtk resolves ~/.local/share/mise/shims/rtk (recorded in the rtk receipt's own
   commands; that shim itself reports rtk 0.49.0).
2. Pin drift, confirmed live on this host:
   • codex: pinned 0.155.1 (adoption/pins-macos-arm64.json); this host's codex on PATH is
     codex-cli 0.158.0-alpha.2.1 (the ChatGPT-bundled build).
   • ai-memory: pinned 2.3.2 (macOS) vs. 2.4.1 (Linux); this host's production build reports
     2.4.0.
   • mcporter: manifests/stack.json shows 0.14.1 (qualified on the Linux workstation, issue
     [mac-coordinator] other: report and apply the token-efficiency coverage check (#264) on mac-coordinator-64gb-20260925 #276/Pin ai-memory 2.4.1 and mcporter 0.14.1 on Linux; workstation SOTA refresh record (headroom 0.39.0 qualified, not switched) #307), but this host's macOS pin and actual install are 0.13.13 -- the mcporter receipt
     binds to the landscape winner pin (0.13.13, matching what's installed), not stack.json's
     newer value.
   • rtk: this host's install and both receipt generations run 0.50.0
     (adoption/pins-macos-arm64.json and manifests/stack.json's pin for the v2026.09.26.2
     release), but catalogs/landscape/foundation.json's foundation/token-efficiency winner pin is
     still the earlier 0.49.0. Both generations record --component-version 0.50.0 --allow-unbound-version, so neither counts toward that winner's macOS status.
   • markitdown: this host's install is 0.1.8 (adoption/pins-macos-arm64.json and
     manifests/stack.json), but foundation/document-retrieval's winner pin is still 0.1.7. The
     receipt records --component-version 0.1.8 --allow-unbound-version, so it adds no countable
     macOS evidence for that winner either.
     None of these are re-pinned here; re-pinning needs Mac-native qualification evidence (for rtk and
     markitdown) or upstream/version-selection review (for codex, ai-memory and mcporter), not this PR.
3. codebase-memory-mcp has no macOS pin in adoption/pins-macos-arm64.json (one of the six
   token-efficiency-adjacent E2E tools the issue lists as macOS-unpinned); no receipt for it is
   recorded here.
4. Codex's RTK instructions are inlined, not hook-enforced, and reference an unqualified rtk.
   This host's ~/.codex/AGENTS.md carries an RTK instruction block generated by a scratch-home
   rtk init -g --codex and copied in (its own header comment identifies it as inlined from RTK.md at
   rtk 0.50.0, with no live @RTK.md reference for Codex to re-expand). Its text tells the model to
   run rtk proxy <cmd> as a bare command; rtk init --codex's own --help text confirms this path
   is "no Claude hook patching" -- Codex gets instructions, never an automatic rewrite -- and a bare
   rtk on this host's plain PATH resolves the older 0.49.0 (finding 1), not the pinned 0.50.0.
5. The mac-child-worker-e2e README overstated its result (fixed in this update). It said the run
   "produces a verified result" and called the 1 unverifiable verdict "not a failure of this run."
   Per examples/claude-native/workflows/readiness-audit.js, a run with any unverifiable verdict
   returns an overall status of unverified or incomplete, never complete; that returned
   status was not saved alongside receipt.json (which only carries child-usage bookkeeping). The
   README now states this and no longer calls the result "verified."
6. ccusage generation 1 published this host's real usage total -- resolved in the third update by
   withdrawal, not superseding; a fourth-update rereview corrected how this finding described the
   remaining exposure. Generation 1 printed this host's real grand-total token count in the clear;
   generation 2 (this finding's original fix) withheld it from its own command output but restated
   the same number in its limitations prose, and both generations printed the list of models used.
   Since neither generation was ever merged to main, both were removed from this branch together
   with their manifests/evidence.json entries, and a single fresh receipt (now itself superseded by
   a fourth-update generation 2 that adds a positive control -- see
   Fourth update, below)
   publishes only ccusage's exit code, row count, field names and internal-consistency booleans. The
   real total no longer appears in this branch's current tip's working tree, but it is still publicly
   reachable: it is in this branch's earlier pushed commits (3167e31c and before, and in
   e08a9b8c, the amended merge commit that still held both leaking files when it was created) and in
   this PR's Commits tab / refs/pull/392/head on GitHub. Neither a squash merge nor deleting the
   branch removes either; see
   Where the withdrawn total can still be read, corrected, above, for the
   full correction and what removing it would take. It was never on main and this PR does not put
   it there.

Review

An Opus same-host independent review follows this PR (each receipt currently carries only its self
review, including every receipt this fourth update touched or added). The workstation
(nativestack-5975wx-20260925) runs the GPT-6 cross-family review per issue #276's coordination note;
merge waits for that review, not just CI. Please target this PR's current head,
506a524fab8cf2b7409006118f79a7b11ee6a4f8 (updated by the sixth update; it was
8519f66d40c7dd9f4a307b2b251474f3ba53bc41 through the fifth), not an earlier one, and when
reviewing the ccusage receipt family confirm observed_at_utc and catalog_revision on the exact
file being reviewed (generation 1 still records the third update's e08a9b8c…; generation 2
records the fourth update's 024531521d…; generation 3, added in the sixth update, records this
update's own merge commit, 8e40cacb3ef350f75e4099ed777d58647b1c7db5) before appending a review,
since host_receipts.py review binds by file path only -- the same caution applies to mcporter's
generation 2 (added in the fifth update, records 29eeab76…) and generation 3 (added in the sixth
update, also records 8e40cacb…). Round 3 update: please target this PR's current head, 87b1b6158743ef390999954d91a9372f40c7bb0d, not 506a524f. mcporter is a single file again (no generation suffix, no supersedes field); the file-path-binding caution above no longer applies to it. rtk now has a generation 3 (…--rtk--use--20260927-3.json, supersedes -2); the ccusage guidance above is unchanged (ccusage was not touched by Round 3).

Checklist

• New/changed GitHub Actions are pinned to a full commit SHA with a version comment (no floating
  tags) -- n/a, no workflow files changed.
• New/changed workflows declare top-level permissions: contents: read -- n/a, no workflow files
  changed.
• No secrets are printed, logged or committed; no new required secret was added without a
  documented owner. gitleaks ran clean on the evidence directory both before and after the
  third update and again after this fourth update (see Local commands above and in the Fourth
  update section); the sixth update's own pre-commit gitleaks hook also ran clean, and its two
  new receipts were separately grepped for openaiDeveloperDocs, node_repl, socraticode,
  /Users/ and the literal string post-merge -- no hits (see Sixth update, above).
  Generation 1's ccusage token total (Findings Qualify native recovery and a pinned local GPU workflow #6) was a real usage figure, not
  a secret or credential; both generations that carried or restated it were withdrawn in the
  third update -- see Privacy fix. This update withdrew two more
  leaking generation-1 receipts (jcodemunch-mcp, mcporter), each together with its non-leaking
  generation 2 (four files total, removed only so no supersedes link points at a deleted
  receipt) under the same rule -- see
  Fourth update. Every
  withdrawn leak (the ccusage total and model list, the jcodemunch-mcp unmasked repo id, the
  mcporter live client inventory) remains readable in this branch's earlier pushed commits and in
  GitHub's copy of this PR's history even after the branch tip stopped publishing it. Corrected
  by the sixth update: that "stopped publishing it" was true for the ccusage total/model list
  and the jcodemunch-mcp repo id, but not, until the sixth update, for the mcporter server list --
  this branch's own unsuffixed and -2 mcporter files kept publishing it in prose (quoting it
  while explaining generation 1's withdrawal) even after generation 1 itself stopped; the sixth
  update's new mcporter generation 3 names no server, and those two unedited files still carry the
  quoted names today (kept, per this repository's append-only policy). This sentence is corrected
  here rather than deleted so the history stays legible; see
  Sixth update, above, for
  the full fix, and the Privacy fix section, above, for what removing any of this from GitHub
  would take and whose decision that is. Round 3 correction: as of this update, the unsuffixed and -2 mcporter files described in this bullet are themselves withdrawn (together with -3), and the fresh replacement names no server anywhere; see Round 3 (GPT-6), above, for the full fix and where the withdrawn prose remains readable.
• No new paid hosting, subscription or billing surface was introduced.
• Peer-owned untracked files and worktrees were preserved (not deleted, moved or overwritten):
  only this worktree was touched; manifests/evidence.json and the two generated
  component-evidence-matrix files were resynced against origin/main and re-derived with their
  own --write commands, never hand-merged.

🤖 Generated with Claude Code

https://claude.ai/code/session_017d27CMzkbLezdLv7vAStPu