fix(spec): translateView localizes a form view's sections through objects.OBJECT._sections.NAME

[objectstack-fleet]

Fixes #23632

Clause-②: no

What this does

translateView (and translateMetadataDocument('view', …), which dispatches to it) now localizes a served form view's sections. Each named section's label and description resolve through objects.OBJECT._sections.NAME.label / .description, on the same localeChain / pickData every other resolver in packages/spec/src/system/i18n-resolver.ts uses. No new export: the card's first option ("translateView covers a form view's sections").

• A missing key keeps the authored text, as the sibling resolvers do.
• A section with no name has no key and is returned as the same object. Its label is never slugged into a key: the slug-of-label fallback in the metadataForms.TYPE.sections walk belongs to a different namespace and a different rule, and the translation linter refuses that spelling for _sections.
• An explicit override beats the catalog (i18n: a published org overlay on a packaged view label is served to a zh-CN reader as the catalog translation (进行中), not the edit — the view twin of #20680 #20731, ADR-0029 D9.2a). Each section is found in packagedBase.config.sections by the name the bundle addresses it by, through the existing packagedPart finder (its key union gains 'sections'). The comparison is the existing valueOverridesPackagedBase, with no second copy. A section the base does not carry was authored after the fact and keeps its strings. With no base supplied, the catalog applies.
• Only authored copy is translated (see the decision note below).
• The object is the form's own binding (config.data.object) first, then the view's. That is the order the i18n extractor (walkObjectSections) and the translation linter (collectViewRecord) already use for form sections, so the key read here is the key they scaffold and accept.

config is rebuilt only when a def or a section actually moved. A view with no section translation keeps its config reference, as before.

Measured readings (dispatch Zone 2)

All against origin/main 534ca13eb (the branch base).

1. translateView never read sections: confirmed. From translateView to translateMetadataDocument, the base holds 0 occurrences of sections. The resolver's only other sections walk is resolveMetadataFormLabels (metadataForms.TYPE.sections). It is a different namespace with a slug-of-label fallback, so it is not the same rule and was not reused.
2. The key is declared. translation.zod.ts declares _sections (label, description) on ObjectTranslationDataSchema, and component.zod.ts declares section name as the _sections anchor (record:details and object-form sections). The form view's own FormSectionSchema.name (ui/view.zod.ts) says only "Stable section identifier for i18n lookup". Its TSDoc points at metadataForms.TYPE.sections.NAME, which see the acceptance notes below.
3. Where a served form view carries its sections: config.sections. getMetaItems({ type: 'view' }) filters every aggregated container out (metadata-protocol protocol.ts, "Never surface the aggregated … container"). So every element GET /forms/:slug scans is a ViewItem, and anonymousFormIntakeCandidates's config arm (viewKind === 'form') is the one that matches there: match.form === match.view.config. ListViewSchema refuses a sections key (unrecognized_keys, measured against the built package), so config.sections exists only on the form arm, and no viewKind gate is needed.
   • The call rest(public forms): GET /forms/:slug localizes the object schema but returns the form's section labels untranslated, so an anonymous zh-CN visitor reads English section titles (the producer behind objectui#12333) #23497 makes: translateMetadataDocument('view', match.view, bundle, { ...RestServer.translateOptionsFor(i18n, locale), packagedBase: this.packagedObjectBase(p, 'view', match.view.name) }). The route then serves the translated view's config as form, before its existing field strip. That is the same pair of arguments the object half of the same handler already passes.
4. Override rule: holds, with a stable identity. A section's packaged counterpart is found by name, the key the bundle addresses. A nameless section is never translated, so it needs no identity.
5. The metadataForms walk: a different rule, see 1.
6. Consumers (git grep -l "translateMetadataDocument\|translateView" -- packages ':!packages/spec'): the runtime callers are in packages/rest/src (meta-item-read-gate.ts, rest-server.ts). metadata-protocol/src/protocol.ts names translateView in a comment only. The rest are tests (objectql, platform-objects, plugin-approvals, service-i18n, cli). Readings are under Tests.

Decision: the catalog never adds a heading or a description

A section that authors no label stays without one, and the same holds for description, even when the bundle carries _sections.NAME.label. The card's pins do not decide this case, so here is the reason. The public form renderer (objectui FormPage) draws a heading only under sec.label &&, and its comment rules that "a translation cannot conjure a heading the author did not write". A label added here would draw a heading on the anonymous route only. The authenticated FormPage path would draw none for the same form. Pinned, and ablated below. The alternative is to overlay whatever the bundle carries, the way the view's own description is overlaid. That would be a one-line change if ruled otherwise.

Tests

• New packages/spec/src/system/i18n-resolver.form-sections.test.ts, 13 cases. The fixtures are spec-legal: the container passes ViewSchema.safeParse and each bundle object node passes ObjectTranslationDataSchema.safeParse. The served documents come from expandViewContainer. Cases: the card's three pins, the only-authored-copy rule, an inline locale-map heading, the form's own binding, the locale chain (BCP-47 ladder, declared fallback chain, default locale), config reference identity and no mutation, and four override-rule cases (unedited, edited per string, not in base, no base).
• Readings, all at head 4abffa0fb, each command run through scripts/pm/os-verify-lock.sh:
  • pnpm --filter @objectstack/spec exec vitest run --project local --maxWorkers=2: 680 files, 20769 passed, 1 todo.
  • pnpm --filter @objectstack/spec typecheck: exit 0. check:test-typecheck OK, and the new test file adds no signature to test-typecheck-debt.json.
  • pnpm --filter @objectstack/spec check:generated (after a real pnpm --filter @objectstack/spec build): all 14 artifacts up to date, check:api-surface included. So no export, parameter or type widens, and Clause-②: no holds as measured.
  • Consumer tests that read translated views, built against this head's dist (turbo run build --filter='@objectstack/rest^...'). The checks below ran per package, by file:
    • @objectstack/rest, 9 files, 166 passed: meta-view-container-i18n, meta-dashboard-view-i18n-explicit-override, meta-i18n-declared-fallback-chain, meta-plural-i18n, and the five public-form-* suites.
    • @objectstack/objectql, 2 files, 16 passed: protocol-packaged-view-base, engine-validation-locale-negotiation.
    • @objectstack/metadata-protocol, 2 files, 242 passed: protocol.graft-folded-form-sections, view-container-runtime-expansion. Its source has no runtime caller of translateView, only a comment.
    • @objectstack/platform-objects invite-user-action-copy, 34 passed. @objectstack/service-i18n authored-translations, 16 passed.
  • No consumer fixture asserted an untranslated section.

Gates

The local subset is node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack on this diff: 84 families. Each exit code was captured before any pipe, and the record was reconciled with --ran: 84 derived famil(ies) accounted for — 83 run, 1 NOT-MEASURED. 83 exit 0. The one NOT MEASURED is pnpm check:dual-build-cjs-loads, exit 3, PREREQUISITE NOT MET: it reads every package's dist/, and this worktree built only the closure of @objectstack/rest. CI runs it. Two families first answered exit 3 and gave their verdict, exit 0, once their prerequisites were met: check-plugin-teardown-shape --self-test after fetching its pinned fixture commit, and check:doc-formula-expressions / check:lean-entry-closure once their packages were built. The local-only check:dev-prereqs gives exit 0. Every family CI runs is read from this PR's check runs, not re-run here.

Not done before opening: origin/main is 7 commits past this branch's base. None of them touches a file in this diff or i18n-resolver.ts / view.zod.ts: the spec files they change are migration entries and api/protocol.zod.ts. This diff changes no generated artifact either. The PR's CI runs on the merge ref.

Ablation (one per rule, each restored and proven by blob hash == HEAD and an empty git diff HEAD)

The suite imports ./i18n-resolver relatively (source, not dist/), so no rebuild sits between mutation and run. Each mutation went through scripts/ablation-replace.mjs, whose anchor must hit exactly once.

mutation	result
translateFormSections returns its input (return changed ? next : sections; → return sections;)	8 failed / 5 passed. The 5 that stay green are the ones whose expectation is "unchanged".
object binding ignores config.data.object	2 failed (the retargeted-form case and the label-only-key case) / 11 passed
only-authored-copy guard removed	1 failed (never adds a heading or a description) / 12 passed

Acceptance notes (observations, not filed)

• FormSectionSchema.name TSDoc names the wrong namespace for an object-bound form view. It says a bundle targets the section via metadataForms.TYPE.sections.NAME. That holds for a metadata-editing form (defineForm({ schemaId })). The renderers, the extractor, the linter and now this resolver all address an object-bound form view's section under objects.OBJECT._sections.NAME. The .describe() string names no namespace. Doc drift outside this card's file surface. Carrier: none.
• Neither the extractor nor the linter walks a ViewItem record's config.sections. walkObjectSections and collectViewRecord read a view record's top-level sections, form and formViews, never config.sections of an authored { name, object, viewKind: 'form', config } record. No source producer of such a form record exists in this tree (git grep "viewKind: 'form'" over examples, packages/platform-objects, packages/plugins, apps: zero hits outside tests), so nothing reaches it. Read-only inference, not filed. Carrier: none.
• A localized /meta/view read now serves section copy translated. This is the intended reach. An editor that read a view with a locale and saved that body back would persist the translation. The view label and the bulk-action defs already have that exposure on the same read, so this widens it to one more key and does not change its kind.
• The other half of the card. GET /forms/:slug still serves form untranslated until rest(public forms): GET /forms/:slug localizes the object schema but returns the form's section labels untranslated, so an anonymous zh-CN visitor reads English section titles (the producer behind objectui#12333) #23497 makes the call above. rest(public forms): GET /forms/:slug localizes the object schema but returns the form's section labels untranslated, so an anonymous zh-CN visitor reads English section titles (the producer behind objectui#12333) #23497 is not addressed here.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/spec, touching 10 documentable anchor(s).

5 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/deployment/validating-metadata.mdx (via globalFilters (literal, a string literal in packagedPart))
• content/docs/protocol/objectui/actions.mdx (via bulkActionDefs (literal, a string literal in packagedPart))
• content/docs/ui/actions.mdx (via bulkActionDefs (literal, a string literal in packagedPart))
• content/docs/ui/dashboards.mdx (via globalFilters (literal, a string literal in packagedPart))
• content/docs/ui/views.mdx (via bulkActionDefs (literal, a string literal in packagedPart))

⛔ 3 release-owned page(s) also name something this change touched. These are read-only:

• content/docs/releases/v16.mdx (via globalFilters (literal, a string literal in packagedPart))
• content/docs/releases/v17/17-6.mdx (via globalFilters (literal, a string literal in packagedPart))
• content/docs/releases/v17/17-7.mdx (via bulkActionDefs (literal, a string literal in packagedPart))

content/docs/releases/ is RELEASE-OWNED (AGENTS.md "Documentation Guardrails"): release
notes are written centrally at release time, and a code PR that edits them is the exact PR
that guardrail exists to stop. They are still audited — read-only. If one of them is actually
wrong, file an issue or open a dedicated docs-only PR; do not edit it here.

What this run could not see

• 2 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 a869ea6362e2f44daeedc557b848493fd33f9020 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from d8d8141d05539494628fa1242284edad437c37a7 — the merge of head 4abffa0fb2204c52dad84c4f78f158267c0d3d6f into base a869ea6362e2f44daeedc557b848493fd33f9020, 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 d8d8141d05539494628fa1242284edad437c37a7 && git checkout d8d8141d05539494628fa1242284edad437c37a7
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin a869ea6362e2f44daeedc557b848493fd33f9020 4abffa0fb2204c52dad84c4f78f158267c0d3d6f && git checkout -B drift-repro a869ea6362e2f44daeedc557b848493fd33f9020 && git merge --no-ff 4abffa0fb2204c52dad84c4f78f158267c0d3d6f

node scripts/docs-audit/affected-docs.mjs --json a869ea6362e2f44daeedc557b848493fd33f9020

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

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs a869ea6362e2f44daeedc557b848493fd33f9020 → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[objectstack-fleet]

席位核对 · ACCEPT · PR #23749 @ 4abffa0fb2204c52dad84c4f78f158267c0d3d6f (#23632) · domain:spec seat 1 · os-elon-musk · session session_01HjR8RUwTPQ3TgbfKihmxp9 · 2026-10-16T00:05Z

Reviewer of record. Every item below was checked against GitHub and origin/main, not against the report (os-dev-report on #23632).

• Shape:
  • Draft, base main. The body's first line is Fixes #23632, then Clause-②: no, matching claim 6203660009. No closing keyword sits beside rest(public forms): GET /forms/:slug localizes the object schema but returns the form's section labels untranslated, so an anonymous zh-CN visitor reads English section titles (the producer behind objectui#12333) #23497.
  • 3 files, +365/−6, none governed. Assignee os-elon-musk.
• The diff, read:
  • translateFormSections overlays objects.OBJECT._sections.NAME.label / .description onto config.sections. lookupSectionText walks the module's own localeChain / pickData, with no copy elsewhere.
  • A section is keyed by its name only. A nameless section is returned as the same object.
  • The packaged counterpart is found by name through the existing packagedPart (its key union gains 'sections') and judged by the existing valueOverridesPackagedBase. There is no second comparison.
  • config is rebuilt only when a section moved.
  • FormSectionLike is module-private, and ViewLike's type is unchanged (comment only). With check:api-surface green after a real build, no export, parameter or type widens: Clause-②: no holds as measured.
• The card's three pins (zh-CN _sections translated, missing key keeps authored text, nameless section untouched) are in i18n-resolver.form-sections.test.ts, 13 cases, with spec-legal fixtures (ViewSchema / ObjectTranslationDataSchema safeParse green). Three ablations ran, each red as expected and restored by blob hash.
• The report's open question, the seat's call: A, as shipped. The catalog translates authored copy only and never adds a heading or a description. A server-side reading changes the language of the copy, not the shape of the form, and objectui's FormPage already draws a heading only where one was authored. Pinned and ablated.
• The rest(public forms): GET /forms/:slug localizes the object schema but returns the form's section labels untranslated, so an anonymous zh-CN visitor reads English section titles (the producer behind objectui#12333) #23497 handoff: the call the report names, translateMetadataDocument('view', match.view, …) with packagedBase, then serving the translated config as form, is that card's to make. ⛔ No packages/rest file here.
• Consumers (spec lane rule), real readings in the report:
  • @objectstack/rest: 9 files, 166 passed, including the five public-form-* suites;
  • @objectstack/objectql: 2 files, 16 passed;
  • @objectstack/metadata-protocol: 2 files, 242 passed;
  • @objectstack/platform-objects: 34 passed;
  • @objectstack/service-i18n: 16 passed.
  • No fixture asserted an untranslated section.
• Changeset, sentences checked against the diff: @objectstack/spec patch. The five bullets (missing key, nameless, authored-only, form binding first, override rule) each match a code path above. "No export, parameter or type changes" matches check:api-surface.
• Accepted deviations:
  • No pre-PR merge of main: the 7 newer commits touch no file in this diff. CI judges the merge ref.
  • The pre-restart background runs died with the container, and every cited reading was re-run in the foreground.
• Out of scope:
  • the FormSectionSchema.name TSDoc (view.zod.ts:3677-:3683) names metadataForms.TYPE.sections.NAME only: filed as spec(view): FormSectionSchema.name's TSDoc sends a form section's translations to metadataForms.TYPE.sections.NAME only; an object form view's section is keyed at objects.OBJECT._sections.NAME #23756;
  • the extractor and linter not reading an authored ViewItem form record's config.sections: no producer (0 non-test viewKind: 'form' records), so Acceptance notes only.
• CI on this head at this act: in progress (19 success, 6 skipped, 13 pending). Not yet read as green.
• Before the queue: a CONTRACT_REVIEW_TIER contract review (face packages/spec/src/**) by an isolated at-tier reviewer, and every check green on the head.

---

Generated by Claude Code

[objectstack-fleet]

Contract review

Rendered: 2026-10-16T00:24Z · check-runs on the head read at 2026-10-16T00:23Z

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: 4abffa0fb2204c52dad84c4f78f158267c0d3d6f
Local-runs: none
Scope: packages/spec/src/system/i18n-resolver.ts + packages/spec/src/system/translation.zod.ts (_sections), packages/spec/src/ui/view.zod.ts (FormSectionSchema, ViewItemSchema, expandViewContainerWithDiagnostics), packages/spec/src/ui/component.zod.ts (_sections anchors), packages/cli/src/utils/i18n-extract.ts (walkObjectSections, addSection), packages/lint/src/validate-translation-references.ts (collectViewRecord), packages/rest/src/meta-item-read-gate.ts (the three translateMetadataDocument / translateView call sites and projectViewTranslation), objectui apps/console/src/components/FormPage.tsx and packages/plugin-form/src/ObjectForm.tsx (the heading guards the decision note cites), and the diff's own i18n-resolver.form-sections.test.ts and .changeset/23632-form-section-labels.md as the pins and the semver carrier. The rest of the diff is the lane seat's ACCEPT at TIER_DEFAULT.

Inputs: card #23632 (body and every comment), PR #23749 (body, file list, the three-dot diff main...4abffa0fb — 3 files, +365/−6, merge base 534ca13eb), and the check-runs on the head. Cited code was read at the head sha through the contents API; the pre-PR local checkout (9bb93706f) was read only for files the diff does not touch. Nothing was built, run or re-run.

① Derived judgments

Public surface — unchanged, as claimed. FormSectionLike is a non-exported interface (its sibling BulkActionDefLike is exported; this one deliberately is not). packagedPart's key union gains 'sections' on a module-private function. ViewLike.config keeps its declared type (data?, bulkActionDefs?: unknown, and the string index signature): config.sections is read through the index signature that already existed, so the accept set of translateView / translateMetadataDocument('view', …) neither widens nor narrows. translateView's signature and the METADATA_DOCUMENT_TRANSLATORS map are untouched. Type Check · consumer gates, the lane that runs check:api-surface on the built declarations, is success on the head. Right.

Locale chain and override rule — one copy, not a second. lookupSectionText iterates localeChain(opts) and reads pickData(bundle, code)?.objects?.[object]?._sections?.[name]?.[attr], the exact shape of lookupViewText / lookupAppAttr; the default-locale short-circuit (#15711) and the declared fallbackChain (#14882) therefore apply unchanged, and the test's chain case pins all three legs. The override comparison is the existing valueOverridesPackagedBase through the existing packagedPart finder with its three answers (undefined → catalog applies; {} → authored after the fact; the packaged section otherwise). No new comparison, no handler-local chain. Right.

Key convention — the declared key, read where the extractor and the linter put it. translation.zod.ts declares objects.OBJECT._sections.NAME.label / .description on the object node (both optional strings, strictObject). The served form view carries its sections at config.sections: expandViewContainerWithDiagnostics emits { name, object, viewKind: 'form', label, config: cloneViewConfig(form) } for form and every formViews entry, and ViewItemSchema's form arm nests FormViewSchema under config — so config.sections is the one served address and the viewKind gate the PR omits is not needed. The binding order config.data.object → view object matches walkObjectSections (viewObjectName(view.form) ?? containerObject) and collectViewRecord (bindingOf(sub) ?? recordObject), read in both files; the retargeted-form pin exercises it. A nameless section has no key (component.zod.ts says the same twice: "a nameless section renders its authored label in every locale") and is returned by reference. Right.

Reach — as the docblock claims. The rest layer's three call sites (meta-item-read-gate.ts item read, list read and the #22614 container read) all pass packagedBase for view, and projectViewTranslation copies every changed config key back onto the container's form / formViews slot generically, so a localized container read receives translated sections too. translateObject's embedded-view overlay covers listViews only; an object document's embedded form.sections stays untranslated server-side — outside this card (a served form VIEW), and objectui resolves it client-side. Noted, not a defect.

One inaccurate sentence in the hunk, no behaviour behind it. translateFormSections's docblock opens "Three rules, each the one its sibling translators already follow"; the second rule ("Only authored copy is translated") is not one the siblings follow — resolveViewDescription returns the lookup, else view.description, and so ADDS a description the view never authored, and translateBulkActionDefs has no authored-copy guard at all. The rule is a new, narrower rule for sections (judged in ③). Carrier: a one-line docblock correction folded into #23756 beside the TSDoc drift, or a docs-only PR; it moves no surface, no gate and no behaviour, so it does not hold this record.

Config identity — config is rebuilt only when a def or a section moved, and the input view is never mutated; pinned by the reference-identity case. Right.

② Semver level

.changeset/23632-form-section-labels.md declares '@objectstack/spec': patch and carries Clause-②: no; the PR body carries the same line; the card's Claim: predicted no and asked the dev to measure the built declaration closure — the dev reports check:generated green after a real build, and Type Check · consumer gates confirms it on the head. The diff publishes a behaviour fix in a released package (a declared key with no exported reader; bug on the card) and adds no export, parameter or type, so patch with Clause-②: no is the level the diff publishes. Check Changeset is success. No breaking marker is owed. Right.

③ Boundary flags

The dev's open question — whether the catalog should add a heading or a description to a named section that authored none. Answered here; no escalation is needed: the shipped rule, translate authored copy only, holds. The server-side overlay changes the language of copy, not the shape of the form. FormPage.tsx serves both of its routes (/f/:slug → GET /api/v1/forms/:slug, and /forms/:name → GET /api/v1/meta/view/:name) through the same sec.label && guard, with a comment ruling that a translation cannot conjure a heading, so both FormPage routes keep one structure under this rule. Two corrections to the PR's rationale, neither changing the answer: ObjectForm.tsx (plugin-form, the record-edit path) resolves client-side with section.label || section.name and so already draws a heading for a named-unlabelled section, which no choice here affects; and walkObjectSections → addSection DOES scaffold _sections.NAME.label for a named section with no authored label, so a bundle may legitimately carry such a key — under the shipped rule the server-side read leaves it to the client-side readers. The one-line widening stays available by ruling. The PR body's "on the anonymous route alone" is imprecise — the authed /forms/:name read is translated by the same rest call sites, so a conjured label would have reached both FormPage routes; the conclusion stands.

Dev deviations, all accepted. §10 pre-PR pull not performed: main is 10 commits past the merge base (91 files) and none touches any file this review read; the queue rebuilds on the merge ref. Background runs lost to a container restart were re-run in the foreground. One fixture commit fetched for a self-test. Extra ablation rows beyond the one-per-rule minimum.

Out-of-scope findings. FormSectionSchema.name TSDoc names metadataForms.TYPE.sections.NAME — confirmed at the head; the card's ACCEPT comment names #23756 as its carrier. The same drift class sits on translation.zod.ts's _sections TSDoc ("Used by record:details" only, though three surfaces now read it for form sections) — fold into #23756. The extractor and linter never reading a ViewItem record's config.sections, with zero producers in the tree — agreed, read-only inference, no carrier.

Check-runs on the head at 2026-10-16T00:23Z: 40 runs, 39 completed (33 success, 6 skipped, 0 failure), 1 in progress — Test Core (4/6). Of the five required contexts, Lint & Repo Gates, TypeScript Type Check, Build Core and Governed Surface Queue Guard are success; the Test Core aggregate is pending on that one shard. Recorded as in progress; nothing is red. Landing waits on green (Multi-agent discipline §7).

Implemented-by: claude/issue-23632-form-section-labels
Reviewed-by: session_01HjR8RUwTPQ3TgbfKihmxp9

VERDICT: PASS

---

Generated by Claude Code