chore(deps): move to the published cohort, and the one decision that blocks it

[drewstone]

Supersedes the diagnosis in #746, which named the wrong fix.

What actually breaks packed-cohort

The job does not install the published cohort. It checks out three sibling repos at pinned refs and packs those, then installs them beside @tangle-network/sandbox, which floats inside this repo's peer range:

repo	pinned ref on main	published today
agent-sdk	36b8e3ec — interface 0.43.1	0.46.1
agent-eval	cd4c3195 — v0.144.4	v0.144.6
agent-knowledge	b5c82eb9 — v7.0.11	v7.1.2

sandbox@0.19.3 binds its BACKEND_TYPE table to the canonical harness enum at import time, and prime only entered that enum in interface 0.45. So the job pairs a 0.43.1 enum with a 0.19.3 table and throws before any test runs. Every PR in this repo has carried that red check for a mismatch none of them introduced.

Repinning alone is not enough: the script also asserts this repo's declared dependency versions equal the packed ones (requires agent-knowledge@7.0.11, packed 7.1.2), so the catalog and the pins move together. Both are in this branch, along with the mechanical half of the interface migration — systemPrompt capability became { replace, append }, and prime joined the closed BackendType union.

Verified locally: with the new pins, the harness-enum failure is gone — the script advances past it to the dependency-equality assertion, which this branch also satisfies.

The one decision left — not mine to make silently

pnpm test is 2395 passed / 7 failed, and all seven are the same upstream change. @tangle-network/agent-profile-materialize@0.12.0 moved the codex and opencode system-prompt projection from an inline launch flag to a file the harness reads:

- developer_instructions="Native \"prompt\"\nsecond line\tend"
+ model_instructions_file=.codex/system-prompt.md

pi is unaffected and still projects natively, which is why the lab's own path never noticed.

The consequence is not cosmetic. src/candidate-execution/system-prompt.ts refuses a candidate whose launch is not the native executable, because an inline flag cannot be proven applied otherwise. With the projection relocated upstream, two refusals no longer fire:

• rejects a system prompt when the declared harness does not launch its native CLI
• refuses 'codex' launch args that would shadow the profile system prompt

Either upstream now delivers the prompt correctly for those launches and the guard is obsolete, or it does not and a system prompt is being silently dropped for a container-command launch — which is exactly the hazard the guard was written for. Deciding that requires knowing whether .codex/system-prompt.md is materialized into the workspace on that path.

I am not deleting a safety refusal to make a version bump green. Draft until the owner of candidate-execution/ says which it is; the branch is ready to finish the moment that is settled.

Closes nothing yet. #746 should be updated with this diagnosis or closed in favour of it.

[drewstone]

The one open decision is resolved — with execution, not judgment calls.

The prompt is NOT silently dropped, and the guard was NOT obsolete. Proven by running materialize 0.12.0 directly: a codex candidate's prompt bytes land in the digested plan at .codex/system-prompt.md (ownership: 'materializer') with the flag pair -c model_instructions_file=… — cwd-relative so the reference survives docker/jail remapping. The delivery is real; what the dep bump silently disabled was this repo's provability guard, which keyed on plan.systemPrompt — a field the materializer no longer sets for codex. The undefined early-return skipped every check, which is exactly why two refusal tests began resolving.

The hazard is unchanged: the flag is only meaningful to the native binary's argument parser. Handed to tools/codex or an arbitrary entrypoint it's inert argv and the sealed candidate would claim an active prompt that never applied. So the guard is restored, re-keyed on the lowered flag itself (90d4a3f5): same three refusals (candidate-entrypoint, non-native executable, shadowing args), and the conflict check learned the new key — a caller --config=model_instructions_file=… would re-point codex's instructions at foreign bytes after the plan's flag.

opencode: materialize now refuses a candidate system prompt outright (its only replacement control binds to the launch-selected agent, which a sealed plan can't guarantee). That's strictly better than this repo's old opencode.json mutation, which patched both built-in agents and hoped. Dead projection deleted; the refusal is pinned by a test; the capability returns upstream via a binds-aware materializeCandidateProfile.

Proof, all local:

• pnpm test: 2397 passed / 0 failed (was 2395/7)
• typecheck, lint, build clean
• node scripts/verify-packed-cohort.mjs with the new pins: Packed package cohort verified. — interface 0.46.1, eval 0.144.6, knowledge 7.1.2, runtime 90d4a3f5, including a real 6-pair/12-execution profile-improvement comparison through the packed archives. The check that has been red on every PR in this repo goes green with this branch.

Tests now pin BOTH halves of codex delivery — the exact flag pair AND the exact prompt bytes in the digested plan — plus the new shadow key, the opencode refusal, and the 30th materialization axis (appendSystemPrompt).