Read-only conductor session, 2026-08-20, yonatangross/orchestkit

Conductor session: what moved, what was wrong, and how it was caught

This is a read-only conductor session run on 2026-08-20 against yonatangross/orchestkit. Nothing here is a plan or a proposal: every figure was verified during the session itself. Three views follow. The first covers Claude Code version adoption, which had been frozen for three weeks by a single JSON.parse call and was released across six versions in one watcher run. The second covers five pull requests, all with zero real red, and a worktree map that fell from 13 directories to 8 while three phantom registrations refused to prune. The third is about method: four confident claims that were overturned, four instruments that returned confident wrong answers, and two gates that printed OK while measuring nothing.

Session 2026-08-20 · yonatangross/orchestkit

CC adoption: frozen and unfrozen

One JSON.parse call held Claude Code version adoption still for three weeks. The snapshot ceiling sat at 2.1.231 while the machine was already running 2.1.237. Fixing the parse released six versions in a single watcher run, and back-filled six waves of features that had been sitting behind an empty array.

Before

2.1.231

snapshot ceiling

After

2.1.237

ceiling meets running

Gap closed

  • 2.1.232
  • 2.1.233
  • 2.1.234
  • 2.1.235
  • 2.1.236
  • 2.1.237

six new snapshots, floor stays 2.1.220

The ceiling, before and after

Floor 2.1.220 is the supported minimum. Everything from 2.1.232 up was invisible to the board until the parse was fixed. Hover or focus a tick for its state.

Select a version tick for detail.

Features per version, before vs after

Every version read 0 before. That is the whole point: a wave showing features: [] was not an empty release, it was a release nobody had triaged. Once triage actually ran, six of the eight filled in. Read this chart as proof of untriaged, not proof of empty.

Hover or focus a bar group for detail.

Two kinds of zero

Genuinely zero

  • 2.1.226 · 1 bullet · genuinely empty
  • 2.1.219 · 24 bullets · parse_failed, below floor 2.1.220

These two stay at 0 after triage, for two different and real reasons. 2.1.219 is below the support floor, so it is out of scope, not overlooked.

Zero only because triage never ran

  • 2.1.224 0 → 12
  • 2.1.223 0 → 12
  • 2.1.221 0 → 11
  • 2.1.229 0 → 7
  • 2.1.225 0 → 6
  • 2.1.222 0 → 6

Six waves. 54 features recovered from an array that a reader would have called empty.

Evidence: the "untriaged waves" claim was wrong, and here is what refuted it

Claim: cc-adoption-gaps.json waves are untriaged. Verdict: WRONG.

features: [] is a placeholder written by cc-release-watch.mjs:309 with the comment "filled in by triage". Proven by the watcher run back-filling 12/12/11/7/6/6 features once triage finally ran.

Root cause: one parse, three retry layers around it

scripts/cc-triage.mjs:318 called JSON.parse on model stdout. The model wrapped its array in a json code fence, JSON.parse threw on the backtick, and the retry re-rolled a BYTE-IDENTICAL prompt so it reproduced the same wrapper forever. Three retry layers, none of which touched the parse.

conductor-verified root cause, session 2026-08-20
  1. 1retrysame prompt, byte for byte
  2. 2retrysame prompt, byte for byte
  3. 3retrysame prompt, byte for byte
  4. !the parseuntouched by all three, so every retry re-entered it

A retry that does not change its input is not a retry, it is the same failure on a timer.

The watcher run that unfroze it

run id
32350918138
ref
fix/cc-watch-fence-parse
conclusion
success
started
2026-08-20T08:51:46Z

The ref is the load-bearing detail. Dispatching main instead of fix/cc-watch-fence-parse would have re-run the broken parser: same fence, same throw, same three no-op retries, and the model quota spent on a run that could not have succeeded. The fix has to be on the ref you dispatch, not merely written.

Related: PR #3580 on that branch shows head movement because the watcher committed snapshot 58519b412 back to the branch.

Pull requests and the worktree map

Five PRs, zero real red. The only NOT-PASS anywhere in the set is Enable auto-merge for Dependabot = skipped, which is the correct outcome on a non-Dependabot PR. Separately, 13 worktree directories were reduced to 8, three phantom registrations resisted pruning with EPERM, and one worktree must never be reaped.

Session 2026-08-20 on yonatangross/orchestkit. main at start 4fb82d5a3, origin/main now 5092fff91.

Panel A. Pull requests, before and after

realRed = 0 on all five PRs. Verified per PR, not aggregated from a single run.
Pull request state before and after, with check-run counts
PR Branch Before After Checks realRed Evidence

Check runs, before to after

Slope chart of check-run counts before and after per pull request 3570 rises from 1 to 44. 3571 falls from 43 to 40. 3581 and 3582 rise from 0 to 42. 3580 stays at 0 because CI is still re-running.

Counts are check-runs on the head commit, not distinct workflows.

The only NOT-PASS in the set

Enable auto-merge for Dependabot reports skipped. Skipped is the correct result on a non-Dependabot PR: the step is conditioned on the Dependabot author and none of these five PRs has it. No other check is anything but a pass across all 168 recorded check-runs in the after column.

Panel B. Worktrees, 13 directories to 8

13 → 8directories on disk
11 → 15registered in git
5orphans deleted
3still prunable, EPERM blocked

Directories fell while registrations rose. Those move independently: deleting an orphan directory does not remove its registration, and new work registered more worktrees than the cleanup removed.

Deleted orphans (5)

    Each had no .git file. See the instrument note below on why that matters.

    Still prunable (3)

    git worktree prune fails with EPERM on all three stale registrations, from a subagent and from the main session with the sandbox disabled. Synthetic stale registrations in the same directory prune cleanly in the same invocation.

    Worse: it exits rc=0 while deleting nothing. A caller checking only the exit code records a successful prune.

    Never reap: .worktrees/3322-sandbox-block

    It holds a gitignored settings.local.json (1886 B) that git status reports as clean. A reaper that gates deletion on clean status would destroy it and report success. Clean status is not the same question as "nothing here matters".

    Instrument defects that shaped these numbers
    git -C inside a non-worktree walks UP
    5 directories had no .git, so git -C reported the PARENT repo state as theirs: branch main, 467 ignored paths. All of it was the main tree.
    Credential helper stderr poisoned a SHA variable
    git ls-remote writes "failed to store" to stderr. Folding it in with 2>&1 made all 11 branches look present on origin when only 4 were.
    gh is dead, but not for the reason it looks
    A local MITM proxy intercepts everything (curl reports remote_ip 127.0.0.1). gh is Go, honours the proxy, then must verify its cert via macOS trustd which is blocked. Node has its own CA bundle: NODE_USE_ENV_PROXY=1 node works. gh auth status calling the token invalid is downstream of the same break.
    ork:debug-investigator cannot use pipes
    Refused on its first command: compound commands not permitted for read-only agents. It produced nothing and cost a whole recon lane.

    The PR Playground gate

    Required on every non-exempt PR. Two steps, and one trap that is the single most reusable operational fact of the session.

    1. 1
      Directory step. Requires docs/<head_ref with / as --> to exist with at least one .html file, in the merge ref. ci.yml:292
    2. 2
      Body step. Greps the PR body, case-insensitively, for the substring playground. ci.yml:318

    The trap: a body edit does NOT re-trigger CI

    ci.yml declares on: pull_request with no types:, so it defaults to opened, synchronize, reopened. Editing the body is none of those. The gate keeps reporting its last result on the old body, so the PR stays red after you fixed it.

    Always follow a body edit with an explicit re-run. Clearing this gate by editing a body without one leaves the failure in place while looking like you addressed it.

    Exemptions

    • bot authors
    • branch prefixes dependabot/, release-please, renovate/, chore/cc-snapshot-, ci/
    • fork PRs
    • an all-inert diff, per ci.yml:262

    This is why "PRs would be fine to open normally" was WRONG: PR Playground is a required body grep, and three fresh PRs would have landed instantly red.

    What was measured wrong, and how it was caught

    Four confident claims were overturned, four instruments returned confident wrong answers, and two gates printed OK while measuring nothing. This panel is about method. The single recurring failure is trusting an instrument's zero without asking what that instrument can structurally observe.

    4claims overturned
    4instrument defects
    2gates fail-open
    0 / 5EPIC D adopted

    1 Corrections: stated, then overturned

    Not softened. The value is that each one was caught by evidence, not avoided by caution.

    2 Instrument defects: confident wrong answers

    gh is dead, but not for the reason it looks

    A local MITM proxy intercepts everything (curl reports remote_ip 127.0.0.1). gh is Go, honours the proxy, then must verify its cert via macOS trustd, which is blocked. Node ships its own CA bundle, so NODE_USE_ENV_PROXY=1 node works. gh auth status calling the token invalid is downstream of the same break.

    Three symptoms that look unrelated, one cause. The table makes the shared root visible.

    Comparison of curl, gh and node by proxy awareness, CA store and resulting symptom
    ClientProxy awareCA storeSymptom
    curl yes system (macOS) reports remote_ip 127.0.0.1, which is what exposed the MITM proxy
    gh (Go) yes system, verified via trustd (blocked) appears dead; gh auth status reports the token invalid, which is downstream, not the cause
    node opt-in via NODE_USE_ENV_PROXY=1 own bundled CA works; the usable path while gh is broken

    Credential helper stderr poisoned a SHA variable

    git ls-remote writes "failed to store" to stderr. Folding it in with 2>&1 made all 11 branches look present on origin when only 4 were.

    4 of 11 actually on origin

    git -C inside a non-worktree walks UP

    5 directories had no .git, so git -C reported the PARENT repo state as theirs: branch main, 467 ignored paths. All of it was the main tree.

    5 directories, 467 ignored paths, all belonging to the parent

    ork:debug-investigator cannot use pipes

    Refused on its first command: compound commands not permitted for read-only agents. It produced nothing and cost a whole recon lane.

    0 output, 1 recon lane lost

    3 Fail-open: gates that reported success while measuring nothing

    mutation-gate.sh issue #3583

    Same command. Same tree. The only difference is the sandbox. Both exit 0. Both print OK.

    sandboxed vacuous green
    candidates
    13
    proven can fail
    0
    not provable
    0

    exit 0 OK

    unsandboxed real measurement
    candidates
    13
    proven can fail
    11
    not provable
    2

    exit 0 OK

    Identical exit code. Identical verdict string. One of these measured nothing.

    Cause. mktemp -d -t at mutation-gate.sh:116 is denied, RESULT_DIR becomes empty, workers write to /test-*.sh, and reduce reads nothing.

    And it emits advice

    Lower MUTATION_BASELINE to 0 to lock the gain in.

    Following that would zero a security ratchet on a measurement that never happened.

    git worktree prune

    Fails with EPERM on all 3 stale registrations, from a subagent AND from the main session with the sandbox disabled. Synthetic stale registrations in the same directory prune cleanly in the same invocation.

    Exits rc=0 while deleting nothing. A caller checking only the exit code records a successful prune.

    Shared lesson: a green exit code is not evidence that a check ran. Ask what an instrument can structurally observe before trusting its zero.

    4 EPIC D: 0 adopted of 5

    A prior triage doc claimed 3 of 5 done. That counted documentation prose as adoption.

    • adopted 0
    • partial 1
    • doc only 2
    • absent 2

    Measured on feat/3309-adopt-cc-settings (PR #3582): EPIC D measured 0 of 5 adopted; two had been closed on markdown alone.