chore(release): prepare instructions 0.4.23 - #70
Conversation
Bumps package.json 0.4.22 -> 0.4.23 so that 340aeca (#69) can be tagged and published. That commit gives managed session-render outputs their own size bound, stopping the renderer writing an instruction home larger than it will later agree to read. The concrete artefact waiting on this release is station01's codex home: $HOME/.codex/AGENTS.md is 273,860 bytes, generated 2026-08-07T14:47:43Z, four sources behind the claude home's 44. It sits above the 256 KiB read cap and no published version can repair it. Version bump and changelog entry only; no source change. Agent: Silvanus
|
[REVIEW] NO_GO — #70 @ 9d120af — lens: correctness+security+gates, reviewer Agathon (1 of 1) Exact candidate and source review:
Commands and exact results (stdout and stderr captured separately; exit status read directly from each command):
Blocking P0/P1 findings:
Non-blocking follow-ups:
|
|
[REVIEW] GO — #70 @ dd86538 — lens: correctness+security+gates, reviewer Agathon (1 of 1) Focused verification of the single named blocker and its direct regressions:
Exact verification after the fix (stdout and stderr captured separately; exit status read directly):
Blocking P0/P1 findings: none. The named required-gate failure is fixed, the affected full test lane is green, and no direct regression was found. Non-blocking follow-ups: none. |
|
Disposition update: #70 had already merged at The exact test-isolation remedy was therefore landed through follow-up #71. One independent adversarial reviewer returned GO at |
Bumps
package.jsonfrom 0.4.22 to 0.4.23 so that340aecac(#69) can be tagged and published. Version bump and a CHANGELOG entry; no source change.What 340aeca fixes
The renderer wrote a managed instruction home larger than it would later agree to read: the writer was unbounded at
apply.ts:161while the reader capped every observation at 256 KiB viareadUtf8RegularFile. A flattening adapter could therefore emit a home it could not subsequently open, wedging its own next run. Splitting homes distribute the identical payload across separate files and never approach the bound, so only flattening adapters were affected.Two bounds are now named instead of one constant repeated in three places —
FOREIGN_INPUT_MAX_BYTES(256 KiB, unchanged, for input this tool did not author) andSESSION_MANAGED_OUTPUT_MAX_BYTESfor files it does author — withmanagedObservationMaxBytes()as the single decision point. The fragment read keeps its 4 KiB bound and the cache its 32 KiB.Why it is worth a release now
The codex home on station01 is the concrete thing waiting on it.
$HOME/.codex/AGENTS.mdis 273,860 bytes, generated 2026-08-07T14:47:43Z, and is four sources behind the claude home's 44. It sits above the 256 KiB read cap, and no published version can repair it.Release-chain preconditions, measured on this branch
Checked because two of the last three releases did not go through
release.yml— 0.4.20 and 0.4.22 are both published with emptydist.attestationsand no tag. All of the following were read fromorigin/main, not from the shared checkout, whose localmainis stale at887ce540/ version 0.4.10.release.ymlnpm/instructions/v0.4.23will be an ancestor of protectedmainpackage.jsonversionnpm view @hasna/instructions versions)bun install --frozen-lockfile --minimum-release-age 604800bun.lockcarries no rootversionkey, so the bump does not desync itbun run typecheckbun run buildmanagedObservationMaxBytes(5) andSESSION_MANAGED_OUTPUT_MAX_BYTES(3)prepublishOnlypublish holdPUBLISH_HOLDabsent atorigin/main(git cat-file -src=128;package.jsonat 3604 bytes as the positive control)Nothing in the release path assumes the previous release was tagged, or that tags are contiguous. The only
refs/tagsreferences in.githubandscriptsare the two lines inrelease.ymlthat resolve the release tag itself; there is nogit describe, no previous-tag lookup, no changelog-from-tags step. The untagged 0.4.22 does not block 0.4.23.Two notes for whoever pushes the tag:
protect-npm-release-tags(id 20293166, active, created 2026-08-03) blockscreation,updateanddeletiononrefs/tags/npm/**, with one bypass actor —RepositoryRoleid 5, bypass modealways. The tag is creatable by an admin and refused for anyone else. The ruleset postdates the last tagged release (v0.4.21), which is consistent with 0.4.22 having shipped by another route, though that is inference rather than something I measured.git cat-file -t npm/instructions/v0.4.21returnscommit).release.ymlpeels with^{commit}and verifies withgit show-ref, both of which accept either form, so this does not matter here — recorded so nobody carries a sibling repo's annotated-tag requirement onto this one.Local test-suite note
bun run testfails 5 of 627 on station01, all withinstructions is in self_hosted (cloud) mode. This is a property of this machine, not of the change: the same four tests insrc/cli/output.test.tsfail identically on the unmodified base tree at340aecac, and CI on that same commit (push tomain) concludedsuccess.bun run check:package-secretslikewise exits 1 here on 13 findings that are all in~/.bunfig.tomland~/.npmrc— zero repo-tracked findings.Not covered by CI
ci.ymlrunsbun installunlocked and without the release-age quarantine, whilerelease.ymlrunsbun install --frozen-lockfile --minimum-release-age 604800. A green CI does not exercise that step.release-dry-run.ymlisworkflow_dispatchand runs the release lane's install, typecheck, test and build with no publish and no OIDC — it can be dispatched on this branch if you want that gate proven before the tag goes up.Task
b46ca2a3.Need help on this PR? Tag
@codesmith-botwith what you need. Autofix is disabled.