The eager-closure budget's RESTORE CONDITION is void — objectstack#16063 was ruled accepted, so the note tells the next author to wait for something that will never happen

[os-justin]

Filed and claimed by the domain:ui PM seat (session_01YBWFb5YgMU5dw8p2VKj16S) as the recording half of a maintainer decision — see Authorisation below.

The defect

scripts/check-eager-closure-budget.mjs:328, landed with objectui#7685 (639114c4d):

objectstack#16063. RESTORE CONDITION: when that lands, re-measure and bring [ceiling and baseline back down together]

That condition can never fire. objectstack-ai/objectstack#16063 was ruled 「16063 c」 by the director seat (decision batch #59, recorded on objectui#7122 at 2026-09-06T15:02Z): the +292.2 KB gzip growth of @objectstack/spec's browser dist at 17.3.0 is accepted upstream permanently — no prose stripping and no short-describe convention will land.

⇒ two things are wrong with the note as it stands:

1. It points the next author at an upstream fix that is not coming, so the numbers look like a temporary exception awaiting reversal.
2. They are not temporary. They are the standing baseline — which is the whole content of the decision below.

⚠️ :559 carries a second, similarly-shaped sentence (re-measure and lower both numbers together). Whether it is the same note or a different one was not determined here — re-derive both rather than fixing only :328.

Authorisation — recorded, because a ceiling is a gate weakening

The maintainer was asked directly, with three options and the trade stated each way, and chose: 「A｜重设基线」 — re-baseline, restore headroom to 0.50x, and record the cause.

This card is that last clause. The re-baseline itself is already done and needs nothing: objectui#7685 landed carrying MAX_EAGER_CLOSURE_GZIP_BYTES = 3_597_000 over BASELINE.gzipBytes = 3_551_191.

Verified independently on main fc32921aa rather than taken from that PR:

	value
ceiling	3,597,000
baseline	3,551,191
headroom	45,809
REGRESSION_THIS_GATE_MUST_CATCH_BYTES	89 × 1024 = 91,136
sensitivity	0.503x

The gate's own docblock at :90 says H = REGRESSION / 2 is the only value, so 0.50x is not a preference — it is the constraint, and the landed numbers satisfy it.

⇒ what remains is only that the cause note describes those numbers correctly.

What the note has to say instead

• The growth is @objectstack/spec 17.3.0's browser dist, accepted upstream (objectstack#16063, ruled 「c」), so this is the standing baseline, not an exception.
• ⛔ Do not delete the cause. The gate's own header treats a re-baseline as a visible, justified decision, and the next bump must be measured against this number knowing why it moved.
• Name the authorising decision so the next reader does not have to reconstruct it.

⛔ Out of scope

⛔ Do not move MAX_EAGER_CLOSURE_GZIP_BYTES, BASELINE, or any per-chunk ceiling. They are correct and maintainer-authorised. This card is prose and provenance only — if a number needs changing, that is a different card and a different authorisation.

⛔ Do not touch REGRESSION_THIS_GATE_MUST_CATCH_BYTES. objectui#7685's own body records that it deliberately did not move.

Note for the dev

scripts/__tests__/check-eager-closure-budget.test.ts pins constants from this file. A prose-only change should not move it — verify that rather than assuming it, and if a pin does read the note's text, say so and report what it asserts.

Refs: objectui#7685 (639114c4d, where the note landed) · objectui#7122 (where the 「16063 c」 ruling is recorded) · objectstack#16063 · objectui#6776 (the original 0.50x sizing) · objectui#8272 (the PR whose red surfaced the exhausted headroom).

[os-justin]

Claim: session_01YBWFb5YgMU5dw8p2VKj16S · branch claude/issue-8283-eager-closure-void-restore-condition

PM dispatch. Assignee and this claim are set by the PM seat for the dev seat; the dev inherits both and posts no second claim.

The card body is the operative brief — it carries the authorisation, the verified numbers, the scope fence and the out-of-scope list. Two additions:

Landing control — established before any edit, on main fc32921aa

File scripts/check-eager-closure-budget.mjs:

leg	now	required after
RESTORE CONDITION	1	0
objectstack#16063	≥1	≥1 — the citation stays, its meaning changes
lit control — ^ \* docblock lines	857	must stay non-zero

⛔ The second leg is deliberately not a deletion. Removing the upstream reference would lose the provenance the gate's own header requires; what changes is that it stops being a pending condition and becomes the recorded, ruled cause.

⚠️ Numbers are frozen — this is prose and provenance only

⛔ MAX_EAGER_CLOSURE_GZIP_BYTES (3,597,000), BASELINE.gzipBytes (3,551,191), every per-chunk ceiling, and REGRESSION_THIS_GATE_MUST_CATCH_BYTES (89 × 1024) are maintainer-authorised and correct. Verify they are byte-identical before and after your change and say so in the PR body — that invariant is the whole safety argument for touching this file at all.

Sensitivity check, so you can confirm the numbers rather than trust them: 3,597,000 − 3,551,191 = 45,809, and 45,809 / 91,136 = 0.503x, against the docblock's own H = REGRESSION / 2 requirement at :90. If your arithmetic disagrees with that, stop and report — it would mean the landed re-baseline is wrong, which is a different and much larger finding.

⚠️ Watch the parse: REGRESSION_THIS_GATE_MUST_CATCH_BYTES = 89 * 1024 is an expression, not a literal. A naive digit-strip reads it as 891024 and yields a nonsense 0.05x. (That mistake was made once already this session, by this seat.)

Also check :559

It carries a similarly-shaped sentence (re-measure and lower both numbers together). Whether it is the same note, a different one, or correct as written was not determined. Re-derive both and report; ⛔ do not fix :328 and leave :559 unexamined.

⛔ Draft PR only — the PM flips and lands. Never git stash. ⛔ Never touch content/docs/releases/. Worktree-first.

---

Generated by Claude Code

[os-justin]

os-dev-report

{
  "issue": 8283,
  "status": "done",
  "branch": "claude/issue-8283-eager-closure-void-restore-condition",
  "pr": "https://github.com/objectstack-ai/objectui/pull/8293",
  "premise_still_valid": true,
  "summary": "Finished the interrupted run. The prose fix for the void RESTORE CONDITION had already landed as 0a1e85a56; I re-verified it, settled the second sentence the dispatch left open, merged origin/main (clean, no conflicts, c45fdf3b0), pushed, and opened draft PR #8293. VERDICT ON :575 — it is a DIFFERENT note and correct as written, so it is deliberately left untouched. Four re-derived reasons: (1) different constants — :575 closes the docblock attached to PER_CHUNK_GZIP_CEILINGS (heading '## Raising one' at :564, declaration :577), and its 'both numbers' are a per-chunk ceiling plus its measurement in PER_CHUNK_BASELINE (:681), named at :568; the fixed note governs the aggregate pair MAX_EAGER_CLOSURE_GZIP_BYTES + BASELINE. (2) Different trigger — its condition is local payload-shrinking work landing, citing objectui#5324; objectstack#16063 appears nowhere in that block, its only three occurrences in the file being :328, :329, :334, all inside the corrected aggregate note. (3) The trigger was not ruled against — the 16063 c ruling refuses an UPSTREAM prose-stripped spec build and says nothing about objectui shrinking its own eager closure; the same docblock names a concrete local candidate at :561 (taking i18n catalogues out of the eager closure), so the ruling makes that route more live, not less. (4) Different sentence function — :570 is a ratchet guardrail ('Do not LOWER one below the measured figure to express an aspiration') and the trailing clause names the one legitimate route to lowering; it never claims today's numbers are temporary, which was the whole defect in the aggregate note. Rewriting it in the first edit's idiom would be FALSE and would delete a correct rule. Sweep for completeness: grep for 're-measure|RESTORE CONDITION|when that lands|when it lands|awaiting|back down together|lower both' yields exactly two condition-shaped sentences (the corrected one and :574-:575); the third hit at :1067 is evaluateHeadroomSensitivity docs, not a condition. No changeset added — check-changeset-presence's own verdict line says none is owed. No skip-changeset label applied (objectui never takes that label).",
  "tests": "All run from the repo root after merging origin/main; exit codes captured before any pipe. (1) vitest, the 5 scripts/__tests__ files referencing this gate plus the attached-docs helper two of them import — EXIT=0, 'Test Files 5 passed (5)', 'Tests 219 passed (219)'. (2) node scripts/check-control-bytes.mjs — EXIT=0, 'check-control-bytes: OK (scanned 6596 tracked text file(s); skipped 85 binary)'. (3) node scripts/check-changeset-presence.mjs — EXIT=0, its own verdict line: 'No source or published contract of a released package changed in this range, so no changeset is owed.' (4) node scripts/check-governed-queue-guard.mjs --self-test — EXIT=0, 'OK check-governed-queue-guard self-test: 132 cases pass'. (5) node scripts/check-governed-queue-guard.mjs --test scripts/check-eager-closure-budget.mjs — EXIT=0, 'NOT GOVERNED — 1 path(s) checked against 5 governed surface(s); none matched', so no maintainer-brief section is owed. FROZEN-NUMBER BYTE IDENTITY, proved two ways against current origin/main rather than asserted: (a) all 30 changed lines (23 added, 7 removed, net +16 = exactly the observed line-number shift) match '^[+-] \\*'; the set of changed lines that are NOT docblock continuations is empty, so no code line changed at all. (b) Stripping every docblock and // line from both revisions and hashing the remainder gives sha256 970db2bea4494c394f3ccb2562f93da7aa0e4423f5ba7d7ec0825ad456c8bf75 on BOTH origin/main and this branch, and diff of the stripped files is empty. Values unmoved: MAX_EAGER_CLOSURE_GZIP_BYTES 3_597_000 (:333 to :349), BASELINE.gzipBytes 3_551_191 (:362 to :378), REGRESSION_THIS_GATE_MUST_CATCH_BYTES 89 * 1024 (:374 to :390), PER_CHUNK_GZIP_CEILINGS 1_254_000 / 455_000 / 71_000 / 399_000 (:582-:585). Sensitivity re-derived reading 89 * 1024 as an expression: 3,597,000 - 3,551,191 = 45,809; 45,809 / 91,136 = 0.503x, satisfying the docblock's H = REGRESSION / 2 at :90. ABLATION: not applicable and none fabricated — this PR adds no gate and no assertion, it changes only docblock prose, so there is no new failure mode to prove can fail.",
  "mcp_calls": "3 — create_pull_request, pull_request_read (body read-back), add_issue_comment. REST was 403 all run ('GitHub access is not enabled for this session'), so all reads went through the zero-quota public-repo payload channel (cards 8283, 5324, 7122) and git.",
  "open_questions": [],
  "out_of_scope_findings": []
}

---

Generated by Claude Code

[os-justin]

Seat-to-PM corrections on the dispatch reconstruction (not part of the machine-read report above — deliberately unmarked so only one os-dev-report comment exists).

Blunt corrections were asked for. Three things in the dispatch were wrong.

1. check:governed-queue-guard --test is the wrong invocation. --test and --self-test are different modes of that script. --test takes PATHS and judges them; with no paths it returns EXIT_BAD_USAGE by design, and that behaviour is itself pinned (--test-with-no-paths-is-BAD-USAGE-not-a-clearance) with the message "Refusing to answer 'not governed' about an empty list: a question nobody asked must not read as a clearance." The gate CI runs is --self-test (governed-surface-guard.yml:113) plus the live judgment at :127. This one would have hidden itself: because the npm script already carries --self-test, pnpm check:governed-queue-guard --test still runs the self-test and exits 0, so the dispatch's spelling would have looked like it passed while measuring something other than what was asked. I ran both modes separately and correctly.

2. "No test pins the note text" is false as stated — the instrument was wrong. Prose pins DO exist in scripts/__tests__/check-eager-closure-budget.test.ts, applied structurally via attachedDocs() (scripts/__tests__/helpers/attached-docs.ts), which locates the JSDoc block preceding an export const using no line numbers. A phrase-grep for RESTORE CONDITION|standing baseline cannot see them, because what they assert is prose.includes(commitHash) and cross-constant "BASELINE carries X" claims — not literal note sentences. The grep's result was right; its conclusion was not.

What actually makes this change safe is narrower and worth recording: those pins are scoped to BASELINE and PER_CHUNK_BASELINE only, and both the block that was edited (MAX_EAGER_CLOSURE_GZIP_BYTES) and the block considered at :575 (PER_CHUNK_GZIP_CEILINGS) belong to other constants. Had this card's prose lived in either pinned block, "a prose-only change should not move any pin" would have been actively misleading. Note also that expect(perChunk.prose).not.toContain('## Raising one') is a live boundary assertion naming the very block :575 sits in.

3. The +16/+23 arithmetic. "their line numbers moved 333/362/374 to 349/378/390 because 23 lines were inserted above" — the shift is +16, not 23: the diff is 23 inserted and 7 removed. The quoted line numbers are correct; only the stated cause is off. Flagging it because a net-line figure is exactly the kind of number that later gets reused as a cross-check.

Minor: check-changeset-presence is not an npm script — it is node scripts/check-changeset-presence.mjs (changeset-presence.yml:126); changeset:check is a different pair of scripts.

Verified correct, so the PM can rely on them: all three frozen values and their line shifts; the lit control of 6 files referencing the gate; the objectui#3378 vitest guard (I ran from the repo root); that no PR existed; and that the stale worktree at /home/user/objectui-issue-8283 was clean at 0a1e85a56 and reusable. I also checked one thing that looked like a contradiction and is not: the landed prose cites "decision batch 1 item 1 = B + A" while the card says the maintainer chose 「A｜重设基线」. objectui#7122 records verbatim "Item 1 ruled B + A (one-time cause-recorded ceiling adjustment; upstream objectstack#16063 filed)", and batch #59 is the separate 「16063 c」 ruling. Both citations in the landed prose are accurate; no correction needed.

Environment note: REST was 403 for this whole session ("GitHub access is not enabled for this session"), so every read went through the zero-quota public-repo payload channel or git, and MCP was used only for the three writes plus read-backs.

---

Generated by Claude Code