Uh oh!
There was an error while loading. Please reload this page.
Close the #4115 any-erasure ledger: batch 8 measured not-burnable, zero re-exports - #6883
Conversation
…ts, not re-exports Batch 8/8 of the objectstack#4115 any-erasure ledger covered `JoinNode`, `NavigationItem`, `NavigationItemSchema` and `JoinedReportBlock`, all filed as "blocked on objectstack#4171 — re-export when the upstream erasure lifts". #4171 closed completed on 2026-07-30. Re-measuring in the BUILT dist at spec 17.2.0 (not in source, and not from the issue's state) finds none of the four is burnable, for three different reasons — none of them the one the ledger recorded: - `JoinNode`: the spec no longer exports the symbol at all (TS2305 from both `/ui` and `/data`); spec 17.0.0 retired the cluster. Nothing to bind to. - `NavigationItem`: upstream is precise now, but the three semantic blockers #3177 measured are untouched by #4171. - `NavigationItemSchema`: upstream is precise now too — and that is exactly what makes the burn-down dangerous, because the live blocker is runtime shape. Referencing the spec's schema would make `objectui validate` reject metadata this renderer accepts today. - `JoinedReportBlock`: still erased, to `unknown`, by a cause `#4171` never covered (a bare `z.ZodTypeAny`, not recursion). So the batch lands zero re-exports and converts the remaining debt into pins that name their own release condition: - `app.zod.ts` carried a reason that measurement has made FALSE — "the spec's is `z.ZodType<any>` and would validate nothing". Left alone, the next triage checks that claim, finds it false, and lands the regression this ledger exists to prevent. Replaced with the measured reason. - `JoinNode` absence is now pinned in the file that already owns "the spec does not own X", so a re-minted upstream name is caught. - The `JoinedReportBlock` pin no longer reads as pending on a closed issue. - `navigation-spec-parity.test.ts` gains the only mechanical guard for the CURRENT blocker: five pieces of metadata objectui accepts and the spec rejects, behind two positive controls. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013hfmP9hoMd3dJwTh85J4yB
…h 8 as declared dialects `check-spec-symbol-derivation.mjs` carries the ledger's enforceable half: a `DEBT` map keyed to objectstack#4115 whose `@object-ui/types` entry was exactly the three batch-8 symbols that still collide with a spec export, reported by the gate as "3 untriaged collisions". They are not untriaged — they are measured, and the measurement says they must NOT be burned down. That is what the guard's `ALLOW` registry is for: "a same-name symbol that is narrower or wider ON PURPOSE belongs here with that purpose written down". So the three move DEBT to ALLOW with their measured reasons and their release conditions named as pins, and the DEBT map empties. before: 13 declared dialects, 3 untriaged collisions in 1 packages after: 16 declared dialects, 0 untriaged collisions in 0 packages Also corrects the `FormField` ALLOW reason, which asserted "the spec's FormField type erases to `any` in its dist (objectstack#4171), so a re-export would delete typing outright". That is false now and `spec-derived-unions.test.ts` already pins it false (`_specFormFieldIsNoLongerAny`). It is the same defect class as the batch this PR closes — a spent `any`-erasure justification standing in for the real one — and the real reason (the two-layer split, guard header case 2c) is unaffected by precision. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013hfmP9hoMd3dJwTh85J4yB
✅ Console Performance Budget
The eager closure is every chunk the entry reaches through static imports — what the browser fetches and parses before the app renders. The entry chunk on its own is a small fraction of it. 📦 Bundle Size Report
Size Limits
|
os-sam
commented
Aug 30, 2026
Review — ACCEPTLanding is gated on the 4 test shards still running; everything below is the verdict on the The one question this PR actually turns onNot "are the four symbols burnable" — the measurement for that is thorough and I spot-checked
And the script's own header already names this as the designed resolution ( Human floor / governed surfaceClear on every axis. Zero re-exports, so no published type changes and nothing is widened. What makes this a good close rather than a tidy oneThe three The empty changeset is right: comments, tests and a repo script change nothing published. Two observations, neither blocking and neither needing a change:
Card state repairedThe ⭐ PM ACTION is done. #3162's title and body opened with 「当前被上游阻塞,勿提前动工」, Amending your declared file surface on the card before editing Generated by Claude Code |
Uh oh!
There was an error while loading. Please reload this page.
Fixes#3162
Batch 8/8 of the objectstack#4115 any-erasure ledger. It lands zero re-exports — the
measurement says none of the four symbols is burnable, and three of them for reasons that
have nothing to do with the blocker the card recorded.
The card's start signal, and what it actually measured
The card said to run
spec-derived-unions.test.tsfirst: its inverted tripwires(
_spec*IsStillAny) should fail compiling once objectstack#4171 landed. Measured onorigin/mainat a04d7c6, before any edit:found that
anywas never the only blocker for either symbol.pnpm --filter @object-ui/types run type-checkexits 0, andvitest run packages/types/reports
Test Files 73 passed,Tests 844 passed. Both tripwire files are genuinely inthe type-check program (confirmed with
--listFiles, 2 hits), so the green covers them.So the start signal did not fire, and the card's premise — "the only thing blocking these
four is objectstack#4171" — is falsified.
The four verdicts, measured in the BUILT dist
Not in source, and not from the fact that objectstack#4171 closed. Dist erasure is invisible
from either, which is the entire reason this ledger exists. Measured against
@objectstack/spec17.2.0:JoinNodeTS2305from both/uiand/data, against a control import that resolves. Spec 17.0.0 retired thequery.joinscluster. Nothing to bind to.NavigationItemIsAnyandIsUnknownbothfalse)NavigationItemSchemaz.ZodTypeover the union)JoinedReportBlockunknownz.ZodTypeAny. objectstack#4171 typed the recursive schemas and never touched this one.NavigationItemSchemais the dangerous one, and it is the case ZONE 1d of the dispatch warnsabout. Its upstream became precise, so the ledger's stated reason is spent — which reads as
"safe to bind now". It is not: this schema has a published consumer in
objectui validate,and referencing the spec's would make it reject navigation metadata this renderer accepts
today. Measured, with two positive controls that both accept:
pinned,defaultOpen, and a separator carryinglabelfailunrecognized_keysagainstthe spec's strict branches
visible: booleanfailsinvalid_union— andmenuItemToNavigationItemmanufacturesone when it inverts legacy
MenuItem.hiddenidfailstoo_smallWhat this PR changes
app.zod.tscarried a reason measurement has made FALSE — "the spec's isz.ZodTypeof any and would validate nothing". Left alone, the next triage checks thatclaim, finds it false, concludes "burn it down", and lands the exact regression this
ledger exists to prevent. Replaced with the measured reason.
JoinNodeabsence is now pinned, in the file that already owns "the spec does not ownX", so a re-minted upstream name is caught.
The
JoinedReportBlockpin no longer reads as pending on a closed issue, and recordsthat its erasure has a different cause than the one objectstack#4171 fixed.
navigation-spec-parity.test.tsgains the only mechanical guard for the CURRENTblocker — the five divergences above, behind two positive controls. Until now that
reason existed only as prose, and prose does not fail.
The machine-readable ledger is cleared.
check-spec-symbol-derivation.mjskeys aDEBTmap to objectstack#4115 whose@object-ui/typesentry was exactly these symbols.They were never untriaged — they are measured, so they move to the guard's
ALLOWregistry of declared deliberate dialects, each carrying its reason and its release
condition:
Bounded in-place fix, declared
scripts/check-spec-symbol-derivation.mjsis outside the file surface my claim commentdeclared; the surface was amended on the card before the edit, because clearing the ledger
is impossible from
packages/types/**alone.While in that file I also corrected the
FormFieldALLOW reason, which asserted the spec'sFormField "erases to
anyin its dist, so a re-export would delete typing outright".Evidence it is false:
spec-derived-unions.test.tsalready pins_specFormFieldIsNoLongerAny = false satisfies IsAny(SpecFormField). It is the same defectclass as the batch this PR closes — a spent
any-erasure justification standing in for thereal one — and the real reason (the two-layer split, guard header case 2c) is untouched by
precision. Same gate family, no new verification surface.
Verification
Union re-run after the final commit, at
2c3e93e, tree clean:pnpm exec vitest run packages/types/ scripts/__tests__/check-spec-symbol-derivation.test.ts—
Test Files 74 passed,Tests 885 passed(844 to 885; +7 new assertions here, the restis the added gate-script suite)
pnpm --filter @object-ui/types run type-check— lock verdictcommand-exit 0check:spec-symbols—spec symbol derivation: ... 16 declared dialects, 0 untriaged collisions in 0 packagescheck:control-bytes—OK (scanned 5736 tracked text file(s))check-changeset-no-major—No changeset declares a major bumperrors
Because I edited a gate script, its own suite is owed separately from the derived family: all
20 test files that name
check-spec-symbol-derivationran green (310 tests).Reverse-verified, both legs committed first, mutation confirmed on disk by hash change
plus grep of injected and removed text, restore proven byte-exact against the HEAD blob:
_specNavSchemaIsNoLongerAnytotrue satisfiesfails withTS1360at thatline — predicted red, observed red
pinnedcase makes the spec accept it: exactly 1 testfails, 14 pass — predicted red, observed red
Repo-wide scans are CI's run, not duplicated here.
Note for the maintainer
The card's own title and body still open with "currently blocked upstream, do not start"
(
当前被上游阻塞,勿提前动工). That has been false since 2026-07-30 and triage flagged it on2026-08-18 as having repelled claimants for 19 days; by now it is 40. Worth correcting so
the closing state of this ledger is not read as still-blocked.
Generated by Claude Code