chore · playground · 2026-08-11

CC moved to 2.1.227. Nothing ork keys off moved with it.

CC updated mid-session. The release-watch pipeline had not picked it up (cc-adoption-gaps.json stops at 2.1.226, and no issue existed), so this was triaged from the shipped binaries rather than changelog bullets. Both are installed, so the comparison is a diff, not a reading.

The three surfaces ork's gates actually key off

surface2.1.2262.1.227
hook events named (hook_event_name:"X")3131, identical
additionalContext consumers documentedStop, SubagentStop (+PostToolBatch, imperative)identical
sandbox / workflow / permission settings keys2929, none added or removed
string table: 40,335,362 -> 40,944,719 bytes  (+~600KB)

So 2.1.227 is not an empty release. Something changed. Nothing in it touches ork's hook events, its additionalContext contract, or the settings keys ork reads.

Therefore: a latest_known-only bump

latest_known   2.1.226 -> 2.1.227
latest         2.1.220     frozen
supported_floor 2.1.220    frozen
drop_after     2.1.219     frozen

The manual_override does not expire until 2026-09-20, so floor and latest stay pinned by design and latest_known diverges from latest. This matches the 2026-08-05 (2.1.220 to 2.1.222) and 2026-08-08 (2.1.222 to 2.1.226) precedents recorded in that same field. Bumping latest_known is what clears the per-session adoption-lag nudge; it grants no new floor.

What this triage deliberately does NOT cover

Contract surface, not changelog bullets

Every prior bump in that field was triaged from the release's bullet list, often with an LLM extraction pass. This one was not: cc-triage.mjs requires a paid claude -p call and there was no snapshot to feed it. So CLI, UI, and model-only changes in 2.1.227 remain unreviewed. The surfaces compared here are exactly the ones the floor and ceiling gates read, which is why a latest_known bump is defensible on this evidence and a floor bump would not be.

The spec's provenance is left at 2.1.226 on purpose

spec/cc-output-keys.spec.yml still records cc_version: "2.1.226" / derived_at: "2026-08-08". Its header requires that every entry carry the binary string justifying it, and while the additionalContext set was re-checked against 2.1.227 here, the other fields were not re-derived. Restamping it would claim a re-derivation that did not happen, which is the exact discipline that file exists to enforce.

Gates

stamp-cc-support.mjs            1 mutation (LATEST_KNOWN_CC), CLAUDE.md untouched
tsc --noEmit                    exit 0
hook TS suite                   308 files ยท 7601 passed
validate-counts.sh              exit 0
test:manifests                  exit 0
test-cc-release-watch.sh        exit 0   (hand-maintained 2.1.x asserts)
test-cc-release-watch-step3.sh  exit 0
test-cc-triage.sh               exit 0

Those last three matter because cc-support.json's own comment warns that the CI installer pins, the 2.1.x assertions in test-cc-release-watch*.sh, and the changelog fixtures are NOT stamped and are hand-maintained on every bump. They pass unchanged, because a latest_known-only bump moves no floor for them to assert against.

Found alongside, filed to #3418. Re-measuring the additionalContext set on 2.1.227 confirmed it is identical to 2.1.226, which rules out a 2.1.226 artifact and sharpens that issue: spec/cc-output-keys.spec.yml lists 9 additionalContext events, and its own header says "an entry without evidence is not a contract, it is a guess", yet only 3 carry a quoted string naming their event. The other six rest on a generic field-list line that names none. PostCompact, the event #3321 reports as silently dropped, is one of the six.