Skip to content

docs(spec): step-18 entries, the exportOptions TSDoc and the stored-shapes row say a stored page's next save meets the component-props gate at the metadata save door - #23800

Merged
objectstack-fleet[bot] merged 2 commits into
mainfrom
claude/issue-23789-save-path-sentences
Oct 16, 2026
Merged

objectstack-fleet[bot] merged 2 commits into
mainfrom
claude/issue-23789-save-path-sentences

Conversation

@objectstack-fleet

Copy link
Copy Markdown
Contributor

Fixes #23789
Clause-②: no

Text only. No accept set, export or generated artifact moves.

Why

validateComponentProps and validateComponentTypes run on surfaces: CLI_AND_RUNTIME with runtimeTypes: ['page'] (packages/lint/src/authoring-rules.ts, read on main at b485122). The runtime-publish surface is the metadata write path's publish gate: an active saveMetaItem and the draft-to-active promotion. So the metadata save door judges a page component's properties. The read path does not: the entries' own comments say so ("the gate judges writes, never the read path, so only the next save of a page with a finding is refused"). The sentences below said the save path does not parse properties. That was false. Each rewrite keeps the load half and corrects the save half, in the wording PR #23418 used for its 24 entries: a stored page still loads, because a page component's properties is not parsed on the metadata load path, and the next save of the page meets the component-props gate at the metadata save door.

Sites: old sentence → new sentence

Shipped text: step-18 reason strings (printed by os migrate meta and the upgrade guide)

Entry Old New
18.ui-page-action-row-operation-declared A page's properties is not parsed on the metadata save or load path; os validate's props gate parses it against these same rows and reports the refusal at the row's operation or onSuccess. The component-props gate parses a page's properties against these same rows and reports the refusal at the row's operation or onSuccess on os validate, os build and os lint. A stored page still loads, because a page component's properties is not parsed on the metadata load path, and the next save of the page meets the component-props gate at the metadata save door.
18.ui-object-block-grouping-config-typed properties on a page component is not parsed on the save path, so a stored page keeps loading and renders as it does today; the component-props gate reports such a value as a component-props-invalid error at the offending path on os validate, os build and os lint, … properties on a page component is not parsed on the metadata load path, so a stored page keeps loading and renders as it does today, and the next save of the page meets the component-props gate at the metadata save door. The gate reports such a value as a component-props-invalid error at the offending path on os validate, os build and os lint and at that save door, …
18.element-text-variant-heading-subheading-retired a stored page replays the rewrite at rehydration; a page component's properties is not parsed on the save path, and the component-props gate reports an old spelling as a component-props-invalid error, carrying the prescription, on os validate, os build and os lint. a stored page replays the rewrite at rehydration and still loads, because a page component's properties is not parsed on the metadata load path, and the next save of the page meets the component-props gate at the metadata save door. The gate reports an old spelling as a component-props-invalid error, carrying the prescription, on os validate, os build and os lint and at that save door.

Shipped text: .d.ts TSDoc

Site Old New
packages/spec/src/ui/component.zod.ts, exportOptions Read by the component-props gate (refused as an error); a stored page still saves and loads, because page-component properties is not parsed on the metadata save or load path Read by the component-props gate (refused as an error) on os validate, os build and os lint and at the metadata save door. A stored page still loads, because page-component properties is not parsed on the metadata load path, and its next save meets the component-props gate at the save door

Docs

Site Old New
content/docs/deployment/cli.mdx, stored-shapes table, refused-shape row a page still loads and saves while os validate, os build and os lint refuse the binding in source a page still loads, its next save is refused at the metadata save door (422), and os validate, os build and os lint refuse the binding in source

Code comments: 21 step-18 entry headers (not shipped text)

The same sentence in every header, one transform: … is not parsed on the metadata save or load path, so a stored page is never refused at load … → … is not parsed on the metadata load path, so a stored page is never refused at load (its next save meets the component-props gate at the metadata save door) …. Two headers said "never refused" with no "at load", which is also false since the save door gates. They now read "never refused at load (its next save …)". Only the paragraph holding the sentence is re-wrapped.

18.ui-action-group-menu-member-params-array-only, 18.ui-action-group-menu-members-typed, 18.ui-object-form-custom-fields-typed, 18.ui-object-form-fields-names-typed (was "never refused"), 18.ui-object-form-members-typed, 18.ui-object-form-sections-typed, 18.ui-object-gantt-markers-typed, 18.ui-object-grid-columns-typed, 18.ui-object-grid-export-options-closed, 18.ui-object-grid-kanban-calendar-list-members-typed, 18.ui-object-grid-row-members-typed, 18.ui-object-kanban-conditional-formatting-typed, 18.ui-object-map-gantt-tree-navigation-typed, 18.ui-object-master-detail-form-details-closed, 18.ui-object-metric-aggregate-trend-typed, 18.ui-object-metric-compare-to-typed, 18.ui-object-metric-drill-down-report-typed, 18.ui-object-metric-drill-down-typed, 18.ui-object-timeline-items-typed, 18.ui-object-timeline-mapping-typed (was "never refused"), 18.ui-record-line-items-props-closed.

The card counted eleven. The criterion grep finds more, because the sentence often breaks across comment lines (save or / load path), so the sweep matched the joined text.

Left alone, on purpose

Verification


Generated by Claude Code

…s row say a page's next save meets the component-props gate at the metadata save door

Since validateComponentProps / validateComponentTypes run on the
runtime-publish surface for `page`, the metadata save door judges a page
component's `properties`. Three shipped step-18 `reason` strings, the
`exportOptions` TSDoc, twenty-one step-18 entry header comments and the
stored-shapes table in deployment/cli.mdx still said the save path does not
parse it. The load half stays: a stored page still loads. Text only; no
accept set moves.

Claude-Session: https://claude.ai/code/session_01BYTVP3rWqkXqY8sfHuWGCD
Co-authored-by: Claude <noreply@anthropic.com>
@github-actions github-actions Bot added size/m documentation Improvements or additions to documentation protocol:ui tooling labels Oct 16, 2026
@github-actions

Copy link
Copy Markdown
Contributor

📓 Docs Drift Check

1 anchor(s) derived from 1 changed package(s); no hand-written page names any of them. ⚠️ 21 changed file(s) yielded no anchor (packages/spec/src/migrations/entries/semantic/18.ui-action-group-menu-member-params-array-only.ts, packages/spec/src/migrations/entries/semantic/18.ui-action-group-menu-members-typed.ts, packages/spec/src/migrations/entries/semantic/18.ui-object-form-custom-fields-typed.ts, …), so the pages documenting them are NOT COVERED by this run — this is not a clean bill of health for those files.

What this run could not see
  • 21 changed file(s) yielded no anchor (packages/spec/src/migrations/entries/semantic/18.ui-action-group-menu-member-params-array-only.ts, packages/spec/src/migrations/entries/semantic/18.ui-action-group-menu-members-typed.ts, packages/spec/src/migrations/entries/semantic/18.ui-object-form-custom-fields-typed.ts, …) — pages documenting those are invisible to this run
  • 1 name(s) were too generic to anchor anything (single lowercase words)
  • the SDK route bridge reached 54 of 206 client-bound route-ledger rows — the other 152 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 152: 0 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 55 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 97 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
  • a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.
  • a key NAME is not a key, so the hand re-read the line above prescribes can land on the wrong schema. The same spelling is authorable on one governed type and a [REMOVED] tombstone on another for each of active, aria, joins, objects, template, tools and version (censused on [finding] tools is a key on BOTH AgentSchema (tombstoned, dead) and SkillSchema (live, cloud-attested), so a name-based search attributes skill examples to the agent key — it produced a false stop-the-line alarm on PR #19059 #19093 over the liveness ledger's governed types, top-level keys); nothing in a search result distinguishes the two, so a grep hit on a LIVE example reads as evidence about the DEAD key. Measured on fix(spec): the agent.tools liveness row says dead — it claimed live on a key the schema tombstoned #19059: content/docs/ai/agents.mdx was reported as contradicting the agent.tools tombstone over its tools: example at :161, which is inside the defineSkill({ block opened at :155 — the page was already correct. Settle ownership by PARSING the value against both schemas, never by the name: that literal PASSES SkillSchema, and as an AgentSchema it FAILS at tools with the tombstone prescription. ⛔ These names are not the whole class — a key retired through a .strict() guidance map leaves no tombstone in the walked shape and none of them here (tool.category, live as AIToolDefinition.category).

Coarse fallback — 142 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 9d4fb3c306b09bdc87ce8423d052650f074cc115 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 5c991ca6c6d14b05a5abce1032d2aff1d5ded832 — the merge of head a4a378d24d5171e092de9f22b59830fb312aac10 into base 9d4fb3c306b09bdc87ce8423d052650f074cc115, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 5c991ca6c6d14b05a5abce1032d2aff1d5ded832 && git checkout 5c991ca6c6d14b05a5abce1032d2aff1d5ded832
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 9d4fb3c306b09bdc87ce8423d052650f074cc115 a4a378d24d5171e092de9f22b59830fb312aac10 && git checkout -B drift-repro 9d4fb3c306b09bdc87ce8423d052650f074cc115 && git merge --no-ff a4a378d24d5171e092de9f22b59830fb312aac10

node scripts/docs-audit/affected-docs.mjs --json 9d4fb3c306b09bdc87ce8423d052650f074cc115

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

@objectstack-fleet

Copy link
Copy Markdown
Contributor Author

席位核对 — ACCEPT · objectstack domain:spec seat 2 (#18549) · session session_01LFqdRsuM5nkqoJdHd5ztVk · 2026-10-16T03:56Z

This is the seat review of record for #23789 (claim 6207401131, report 6207706606), on head a4a378d24d5171e092de9f22b59830fb312aac10. The diff is text only, so per the claim this review is the PR's record.

  1. Form.
    • Draft to main. The first line is Fixes #23789; the second is Clause-②: no.
    • 27 files, +168/−132. One @objectstack/spec patch changeset. No accept set, export or generated artifact moves.
  2. What it says, read on the diff.
    • The three shipped reason strings: ui-page-action-row-operation-declared, ui-object-block-grouping-config-typed and element-text-variant-heading-subheading-retired.
    • The exportOptions TSDoc in component.zod.ts, which ships in the .d.ts.
    • The stored-shapes row of content/docs/deployment/cli.mdx.
    • 21 step-18 header comments.
    • Each now says what runs on main: a stored page still loads, because component properties is not parsed on the metadata load path. Its next save meets the component-props gate at the metadata save door, beside os validate, os build and os lint (authoring-rules.ts: CLI_AND_RUNTIME, runtimeTypes: ['page']).
    • The load half was true and stays. Only the save half changed.
  3. Surface held. PR feat(spec)!: delete checkPageComponentViewData; the component-props rule is the one judge of a page component's retired api data binding #23784's two entries and refused-shapes.* are untouched, and so is content/docs/releases/**.
  4. Gates.
    • CI on this head at this act: 39 check-runs, 27 success, 5 skip; Test Core 1–6 and Type Check · workspace are still running, and auto-merge waits on them.
    • Dev local: 104 derived families, all run. 4 are NOT-MEASURED: an unbuilt workspace or a shallow clone, none judging this diff. CI covers them.
    • Spec src/migrations + src/ui/component: 31 files / 1676 passed. Spec typecheck 0.
  5. Open questions (report 6207706606).
    • Q1, generated artifacts: A, none move. registry.ts is gitignored, and check:spec-changes / check:upgrade-guide are green.
    • Q2, the 17.7 release page: A, leave it. The page described 17.7 correctly; the gate moved to the save door in 18. The 18 upgrade text this PR fixes is where an upgrading reader looks. Release pages are release-owned.
  6. Accepted deviations.
    • The sweep covers 21 header comments rather than the card's 11, because the line grep under-counts sentences that break across lines. All 21 are inside the claim's declared family.
    • One --force-with-lease push corrected a commit message, on an unshared branch before the PR existed.
  7. Landing terms. Ready, then auto-merge. Fixes #23789 closes the card. feat(spec): a generic record:json record block — one record key as indented JSON behind a required, fail-closed requiredPermissions gate #23783 / feat(spec)!: retire page:header showStar — the follow star the reference console no longer draws #23781 edit component.zod.ts in other regions; whichever lands second merges main.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

documentation Improvements or additions to documentation protocol:ui size/m tooling

Projects

None yet

2 participants