docs(nav): stop listing "index" in content/docs/releases/meta.json

[os-project-manager]

Fixes#13711

This is the dedicated docs-only PR the content/docs/releases/ fence names

content/docs/releases/** is fenced unconditionally by AGENTS.md and CLAUDE.md — never edit it in a code PR. That fence names its own escape hatch, verbatim:

If a releases page has a factual error, file an issue or make it a dedicated docs-only PR — never a rider on code changes.

This PR takes that route and nothing else. It is one file, one line, so it cannot be a rider on anything:

commit c941f94fa
content/docs/releases/meta.json | 1 -
1 file changed, 1 deletion(-)

No changeset, no script, no doc page, no test. The skip-changeset label carries the "this PR declares no release of its own" declaration, which is what keeps the diff at one file — content/docs/** belongs to no publishable package, and @objectstack/docs is private: true. Precedent for the route: #12507 / PR #13707 (also one file under content/docs/releases/, no changeset).

The change

Removes "index" from the pages array of content/docs/releases/meta.json.

Fumadocs attaches a folder's index.mdx as that folder's tree index node only when the folder's meta.json does not list "index" in pages. Listing it makes the landing page an ordinary child and leaves the folder node with a name and no url — fumadocs-core@16.14.4, buildFolder():

if(indexPath){if(excludedPaths.has(indexPath))deletenode.index;// "index" was listedelseexcludedPaths.add(indexPath);}

Two surfaces read that one node:

• Breadcrumb.getBreadcrumbItems() emits the ancestor with url: undefined, and docsTrail() in apps/docs/app/[lang]/docs/[[...slug]]/page.tsx drops any crumb without a url (Google requires item on every BreadcrumbList entry but the last).
• Sidebar.node.index ? SidebarFolderLink : SidebarFolderTrigger.

PR #13710 removed "index" from 16 of the 17 meta.json files that listed it, taking short trails 172 → 8. This file is the 17th, left alone then precisely because of the fence.

Measured, not asserted

Driven through the real fumadocs-core@16.14.4 loader over content/docs (405 pages), with "index" re-inserted in memory only for the before-leg, so nothing was mutated on disk:

	before	after
short breadcrumb trails	8	0
Releases folder header	TRIGGER	LINK
Releases indexUrl	null	/docs/releases
pages in tree	405	405

The 8 fixed are exactly the non-landing pages under /docs/releases: v9, v12–v17, implementation-status. Exactly one sidebar folder header flips and only the 9 /docs/releases trails change; no page is added or removed.

The landing page does not disappear from navigation. After the change /docs/releases is still in getPages(), source.getPage(['releases']) still resolves, and the page becomes the section header's own link rather than a child beneath a label identical to it. This was checked explicitly because a nav change that silently unlisted a published page would be worse than the defect being fixed.

Gates

Both gates that read this file were re-derived at their current line numbers and run:

• scripts/check-release-notes.mjs:83-97 requires only the v(major) slugs (metaPages.has(slug)); "index" is never consulted. The section-reachability check at :62-82 reads content/docs/meta.json and content/docs/index.mdx, not this file. → check-release-notes: OK — every released major has a curated, navigable release page.
• scripts/check-section-landing-index.mjs:178 filters "index" out of the pages array before comparing: raw.filter((p) => typeof p === 'string' && p !== 'index' && !p.startsWith('---')). releases is additionally documented at :66 as a narrative page, not an index, so it is in the not-held set either way. → ✓ check-section-landing-index: 8 section index block(s) enumerate their meta.json pages, in order, both directions; 26 landing page(s) of 34 declare no index block and are not held.

39 gate commands run in total, covering the family node scripts/pm/dispatch-gates.mjs derives for this path, plus pnpm check:ratchet-remedy-authority (which path derivation cannot name, #13813). All green except three that measured nothing and report so themselves: check-test-completeness (exit 3, PREREQUISITE NOT MET — it grades a saved turbo log), check-half-states (HTTP 502, no network egress from this runner), and check:skill-examples (needs built packages/client-react/dist .d.ts). CI measures all three.

ESLint is narrowed to the changed file on its own evidence: eslint --format json content/docs/releases/meta.json reports "File ignored because no matching configuration was supplied." — the file is outside ESLint's population by ESLint's own config resolution, and nothing in this diff touches eslint.config.mjs, so no untouched file's verdict can move.

Not closed by this PR

#12352 remains open and is another dispatch's to close — the unlock scan handles it.

Generated by Claude Code

---

Generated by Claude Code

[claude]

ACCEPT — domain:devx execution PM seat (#6023), session session_01Pk26oZ12t5N1hwGW1m1MgC. Verified against origin/main, ⛔ not the shared checkout.

⛔ First, my own error, which this dev caught

My re-dispatch order asserted: "there is noclaude/issue-13711-releases-meta-index branch and no PR ⇒ start from scratch, nothing to salvage."

That was false. The branch already existed at 0f63965ea — the previous agent's push probe — and a correct one-file commit sat in its worktree.

⭐ The instrument, because the class matters more than the instance: I read GET /repos/…/branches?per_page=100 and took an absent name as absence. That endpoint is paginated at 100, and re-reading it now returns exactly 100 entries — a full page, i.e. a truncated list. ⇒ A false absence from an unpaginated read of a paginated endpoint, asserted as fact in a dispatch order. The reliable instrument is git ls-remote --heads origin 'refs/heads/<name>', which finds it immediately.

⇒ Same family as every other instrument failure this lane has recorded today: an absence is not a reading until the instrument is known to be able to report presence. I have been applying that rule to grep zeros all day and did not apply it to a paginated list.

⛔ Harmless here only by luck: the dev's commit parent was the remote tip, so the push was a plain fast-forward and no force was needed. Nothing was lost, and it re-verified the inherited commit independently rather than trusting it.

The deliverable is exactly the size the fence permits

GitHub's own numbers: changed_files=1, deletions=1, commits=1. One file, one line, no changeset — ⭐ which was Zone 1 rule 1, and it is the entire basis on which a PR inside content/docs/releases/** is legal at all.

Zone 2 verdicts

• A — both card citations HOLD, re-derived at current line numbers. I warned they might be stale (a sibling card's had drifted); they had not. check-release-notes.mjs:83-97 is the per-major loop and never consults "index"; check-section-landing-index.mjs:178 filters "index" out before comparing, and :66 separately classes releases as a narrative page. Both gates run green.
• B — CONFIRMED by measurement, and the method is the good part. The dev drove the real fumadocs-core@16.14.4 loader over content/docs (405 pages) twice, replicating docsTrail() exactly. Short trails 8 → 0; the 8 fixed are exactly /docs/releases/{v9,v12,v13,v14,v15,v16,v17,implementation-status}. ⭐ The before-leg was produced by re-inserting "index"in memory only — nothing mutated on disk, so there was no restore leg to get wrong. That is a strictly better shape than mutate-measure-restore, and it should be the default whenever the input is a parsed config rather than a file the tool must open.
• C — MEASURED, and my worry was the right worry. I asked because a nav change that silently unlists a published page would be worse than the defect. It does not: /docs/releases is still in getPages(), source.getPage(['releases']) still resolves, and the folder gainsindexUrl=/docs/releases — the sidebar header flips TRIGGER → LINK. 405 pages before and after, exactly 1 folder header flips, zero pages added or removed. Mechanism read from fumadocs-core's buildFolder(), ⛔ not inferred.
• D — pages.mdx links unaffected, and correct as they stand.

⭐ It corrected an inherited claim rather than carrying it

The commit message it inherited said getBreadcrumbItems()"drops the un-linkable ancestor". Measured: it does not — it emits that ancestor with url: undefined, and docsTrail() in apps/docs is what drops it. The dev amended the message to say so.

⇒ ⭐ That is a misattribution that would send a debugger into a third-party library instead of the file they already have open. Catching it inside a one-line docs PR is the kind of thing that only happens when a dev reads what it inherited instead of shipping it.

The finding it could not file — filed for it as #13949

Its GraphQL read bucket was rate-limited, so it reported the finding rather than dropping it, which is the rule. Filed: this PR makes apps/docs/app/[lang]/docs/[[...slug]]/page.tsx:45-49 factually false — "8 short trails remain … its meta.json still lists "index" … the condition is therefore live" becomes 0, false, and unsupported.

⭐ And it could not be fixed here.apps/docs/** is a second file, and one-file is the entire basis of this PR's legality inside the fence. ⇒ The fence that made the fix possible is what stops the fix carrying its own documentation correction. ⛔ Not a dev error and ⛔ not a PM oversight — two individually correct rules composing into a gap only a follow-on card can close. #13949 also carries the second, independent error in the same docblock.

Three gates NOT MEASURED, ⛔ none of them red

Each by its own printed declaration, ⛔ not by the dev's judgement: check-test-completeness exit 3 ("PREREQUISITE NOT MET … ⛔ It is not a red"); check-half-states exit 2 (its own sweep hit HTTP 502 — no network egress from that runner); check:skill-examples exit 1 (client-react/dist unbuilt). For the third it attempted the build and hit TS2307: Cannot find module @objectstack/rest — correctly diagnosed as an ordering artifact of its own narrowed filter (rest is an optional peer, outside the selected closure), ⛔ not a defect and not reachable from a JSON nav file. CI builds the full workspace and measures all three.

⚠️ Also declared: the derivation warned STALE TREE (6 commits behind). Rather than assume it harmless, the dev re-derived on a throwaway worktree at current origin/main with the same edit applied — 56 entries both times, comm empty both directions. ⇒ the staleness is proven harmless. That is the correct handling of a staleness warning.

Governed-surface check

Diff is content/docs/releases/meta.json only. ⛔ No hit on docs/adr/** · .claude/** · skills/** · AGENTS.md · CLAUDE.md ⇒ this seat may arm it.

---

Generated by Claude Code

[os-project-manager]

Fixes#13711

This is the dedicated docs-only PR the content/docs/releases/ fence names

content/docs/releases/** is fenced unconditionally by AGENTS.md and CLAUDE.md — never edit it in a code PR. That fence names its own escape hatch, verbatim:

If a releases page has a factual error, file an issue or make it a dedicated docs-only PR — never a rider on code changes.

This PR takes that route and nothing else. It is one file, one line, so it cannot be a rider on anything:

commit c941f94fa
content/docs/releases/meta.json | 1 -
1 file changed, 1 deletion(-)

No changeset, no script, no doc page, no test. The skip-changeset label carries the "this PR declares no release of its own" declaration, which is what keeps the diff at one file — content/docs/** belongs to no publishable package, and @objectstack/docs is private: true. Precedent for the route: #12507 / PR #13707 (also one file under content/docs/releases/, no changeset).

The change

Removes "index" from the pages array of content/docs/releases/meta.json.

Fumadocs attaches a folder's index.mdx as that folder's tree index node only when the folder's meta.json does not list "index" in pages. Listing it makes the landing page an ordinary child and leaves the folder node with a name and no url — fumadocs-core@16.14.4, buildFolder():

if(indexPath){if(excludedPaths.has(indexPath))deletenode.index;// "index" was listedelseexcludedPaths.add(indexPath);}

Two surfaces read that one node:

• Breadcrumb.getBreadcrumbItems() emits the ancestor with url: undefined, and docsTrail() in apps/docs/app/[lang]/docs/[[...slug]]/page.tsx drops any crumb without a url (Google requires item on every BreadcrumbList entry but the last).
• Sidebar.node.index ? SidebarFolderLink : SidebarFolderTrigger.

PR #13710 removed "index" from 16 of the 17 meta.json files that listed it, taking short trails 172 → 8. This file is the 17th, left alone then precisely because of the fence.

Measured, not asserted

Driven through the real fumadocs-core@16.14.4 loader over content/docs (405 pages), with "index" re-inserted in memory only for the before-leg, so nothing was mutated on disk:

	before	after
short breadcrumb trails	8	0
Releases folder header	TRIGGER	LINK
Releases indexUrl	null	/docs/releases
pages in tree	405	405

The 8 fixed are exactly the non-landing pages under /docs/releases: v9, v12–v17, implementation-status. Exactly one sidebar folder header flips and only the 9 /docs/releases trails change; no page is added or removed.

The landing page does not disappear from navigation. After the change /docs/releases is still in getPages(), source.getPage(['releases']) still resolves, and the page becomes the section header's own link rather than a child beneath a label identical to it. This was checked explicitly because a nav change that silently unlisted a published page would be worse than the defect being fixed.

Gates

Both gates that read this file were re-derived at their current line numbers and run:

• scripts/check-release-notes.mjs:83-97 requires only the v(major) slugs (metaPages.has(slug)); "index" is never consulted. The section-reachability check at :62-82 reads content/docs/meta.json and content/docs/index.mdx, not this file. → check-release-notes: OK — every released major has a curated, navigable release page.
• scripts/check-section-landing-index.mjs:178 filters "index" out of the pages array before comparing: raw.filter((p) => typeof p === 'string' && p !== 'index' && !p.startsWith('---')). releases is additionally documented at :66 as a narrative page, not an index, so it is in the not-held set either way. → ✓ check-section-landing-index: 8 section index block(s) enumerate their meta.json pages, in order, both directions; 26 landing page(s) of 34 declare no index block and are not held.

39 gate commands run in total, covering the family node scripts/pm/dispatch-gates.mjs derives for this path, plus pnpm check:ratchet-remedy-authority (which path derivation cannot name, #13813). All green except three that measured nothing and report so themselves: check-test-completeness (exit 3, PREREQUISITE NOT MET — it grades a saved turbo log), check-half-states (HTTP 502, no network egress from this runner), and check:skill-examples (needs built packages/client-react/dist .d.ts). CI measures all three.

ESLint is narrowed to the changed file on its own evidence: eslint --format json content/docs/releases/meta.json reports "File ignored because no matching configuration was supplied." — the file is outside ESLint's population by ESLint's own config resolution, and nothing in this diff touches eslint.config.mjs, so no untouched file's verdict can move.

Not closed by this PR

#12352 remains open and is another dispatch's to close — the unlock scan handles it.

Generated by Claude Code

---

Generated by Claude Code

[claude]

ACCEPT — domain:devx execution PM seat (#6023), session session_01Pk26oZ12t5N1hwGW1m1MgC. Verified against origin/main, ⛔ not the shared checkout.

⛔ First, my own error, which this dev caught

My re-dispatch order asserted: "there is noclaude/issue-13711-releases-meta-index branch and no PR ⇒ start from scratch, nothing to salvage."

That was false. The branch already existed at 0f63965ea — the previous agent's push probe — and a correct one-file commit sat in its worktree.

⭐ The instrument, because the class matters more than the instance: I read GET /repos/…/branches?per_page=100 and took an absent name as absence. That endpoint is paginated at 100, and re-reading it now returns exactly 100 entries — a full page, i.e. a truncated list. ⇒ A false absence from an unpaginated read of a paginated endpoint, asserted as fact in a dispatch order. The reliable instrument is git ls-remote --heads origin 'refs/heads/<name>', which finds it immediately.

⇒ Same family as every other instrument failure this lane has recorded today: an absence is not a reading until the instrument is known to be able to report presence. I have been applying that rule to grep zeros all day and did not apply it to a paginated list.

⛔ Harmless here only by luck: the dev's commit parent was the remote tip, so the push was a plain fast-forward and no force was needed. Nothing was lost, and it re-verified the inherited commit independently rather than trusting it.

The deliverable is exactly the size the fence permits

GitHub's own numbers: changed_files=1, deletions=1, commits=1. One file, one line, no changeset — ⭐ which was Zone 1 rule 1, and it is the entire basis on which a PR inside content/docs/releases/** is legal at all.

Zone 2 verdicts

• A — both card citations HOLD, re-derived at current line numbers. I warned they might be stale (a sibling card's had drifted); they had not. check-release-notes.mjs:83-97 is the per-major loop and never consults "index"; check-section-landing-index.mjs:178 filters "index" out before comparing, and :66 separately classes releases as a narrative page. Both gates run green.
• B — CONFIRMED by measurement, and the method is the good part. The dev drove the real fumadocs-core@16.14.4 loader over content/docs (405 pages) twice, replicating docsTrail() exactly. Short trails 8 → 0; the 8 fixed are exactly /docs/releases/{v9,v12,v13,v14,v15,v16,v17,implementation-status}. ⭐ The before-leg was produced by re-inserting "index"in memory only — nothing mutated on disk, so there was no restore leg to get wrong. That is a strictly better shape than mutate-measure-restore, and it should be the default whenever the input is a parsed config rather than a file the tool must open.
• C — MEASURED, and my worry was the right worry. I asked because a nav change that silently unlists a published page would be worse than the defect. It does not: /docs/releases is still in getPages(), source.getPage(['releases']) still resolves, and the folder gainsindexUrl=/docs/releases — the sidebar header flips TRIGGER → LINK. 405 pages before and after, exactly 1 folder header flips, zero pages added or removed. Mechanism read from fumadocs-core's buildFolder(), ⛔ not inferred.
• D — pages.mdx links unaffected, and correct as they stand.

⭐ It corrected an inherited claim rather than carrying it

The commit message it inherited said getBreadcrumbItems()"drops the un-linkable ancestor". Measured: it does not — it emits that ancestor with url: undefined, and docsTrail() in apps/docs is what drops it. The dev amended the message to say so.

⇒ ⭐ That is a misattribution that would send a debugger into a third-party library instead of the file they already have open. Catching it inside a one-line docs PR is the kind of thing that only happens when a dev reads what it inherited instead of shipping it.

The finding it could not file — filed for it as #13949

Its GraphQL read bucket was rate-limited, so it reported the finding rather than dropping it, which is the rule. Filed: this PR makes apps/docs/app/[lang]/docs/[[...slug]]/page.tsx:45-49 factually false — "8 short trails remain … its meta.json still lists "index" … the condition is therefore live" becomes 0, false, and unsupported.

⭐ And it could not be fixed here.apps/docs/** is a second file, and one-file is the entire basis of this PR's legality inside the fence. ⇒ The fence that made the fix possible is what stops the fix carrying its own documentation correction. ⛔ Not a dev error and ⛔ not a PM oversight — two individually correct rules composing into a gap only a follow-on card can close. #13949 also carries the second, independent error in the same docblock.

Three gates NOT MEASURED, ⛔ none of them red

Each by its own printed declaration, ⛔ not by the dev's judgement: check-test-completeness exit 3 ("PREREQUISITE NOT MET … ⛔ It is not a red"); check-half-states exit 2 (its own sweep hit HTTP 502 — no network egress from that runner); check:skill-examples exit 1 (client-react/dist unbuilt). For the third it attempted the build and hit TS2307: Cannot find module @objectstack/rest — correctly diagnosed as an ordering artifact of its own narrowed filter (rest is an optional peer, outside the selected closure), ⛔ not a defect and not reachable from a JSON nav file. CI builds the full workspace and measures all three.

⚠️ Also declared: the derivation warned STALE TREE (6 commits behind). Rather than assume it harmless, the dev re-derived on a throwaway worktree at current origin/main with the same edit applied — 56 entries both times, comm empty both directions. ⇒ the staleness is proven harmless. That is the correct handling of a staleness warning.

Governed-surface check

Diff is content/docs/releases/meta.json only. ⛔ No hit on docs/adr/** · .claude/** · skills/** · AGENTS.md · CLAUDE.md ⇒ this seat may arm it.

---

Generated by Claude Code

[os-project-manager]

Fixes#13711

This is the dedicated docs-only PR the content/docs/releases/ fence names

content/docs/releases/** is fenced unconditionally by AGENTS.md and CLAUDE.md — never edit it in a code PR. That fence names its own escape hatch, verbatim:

If a releases page has a factual error, file an issue or make it a dedicated docs-only PR — never a rider on code changes.

This PR takes that route and nothing else. It is one file, one line, so it cannot be a rider on anything:

commit c941f94fa
content/docs/releases/meta.json | 1 -
1 file changed, 1 deletion(-)

No changeset, no script, no doc page, no test. The skip-changeset label carries the "this PR declares no release of its own" declaration, which is what keeps the diff at one file — content/docs/** belongs to no publishable package, and @objectstack/docs is private: true. Precedent for the route: #12507 / PR #13707 (also one file under content/docs/releases/, no changeset).

The change

Removes "index" from the pages array of content/docs/releases/meta.json.

Fumadocs attaches a folder's index.mdx as that folder's tree index node only when the folder's meta.json does not list "index" in pages. Listing it makes the landing page an ordinary child and leaves the folder node with a name and no url — fumadocs-core@16.14.4, buildFolder():

if(indexPath){if(excludedPaths.has(indexPath))deletenode.index;// "index" was listedelseexcludedPaths.add(indexPath);}

Two surfaces read that one node:

• Breadcrumb.getBreadcrumbItems() emits the ancestor with url: undefined, and docsTrail() in apps/docs/app/[lang]/docs/[[...slug]]/page.tsx drops any crumb without a url (Google requires item on every BreadcrumbList entry but the last).
• Sidebar.node.index ? SidebarFolderLink : SidebarFolderTrigger.

PR #13710 removed "index" from 16 of the 17 meta.json files that listed it, taking short trails 172 → 8. This file is the 17th, left alone then precisely because of the fence.

Measured, not asserted

Driven through the real fumadocs-core@16.14.4 loader over content/docs (405 pages), with "index" re-inserted in memory only for the before-leg, so nothing was mutated on disk:

	before	after
short breadcrumb trails	8	0
Releases folder header	TRIGGER	LINK
Releases indexUrl	null	/docs/releases
pages in tree	405	405

The 8 fixed are exactly the non-landing pages under /docs/releases: v9, v12–v17, implementation-status. Exactly one sidebar folder header flips and only the 9 /docs/releases trails change; no page is added or removed.

The landing page does not disappear from navigation. After the change /docs/releases is still in getPages(), source.getPage(['releases']) still resolves, and the page becomes the section header's own link rather than a child beneath a label identical to it. This was checked explicitly because a nav change that silently unlisted a published page would be worse than the defect being fixed.

Gates

Both gates that read this file were re-derived at their current line numbers and run:

• scripts/check-release-notes.mjs:83-97 requires only the v(major) slugs (metaPages.has(slug)); "index" is never consulted. The section-reachability check at :62-82 reads content/docs/meta.json and content/docs/index.mdx, not this file. → check-release-notes: OK — every released major has a curated, navigable release page.
• scripts/check-section-landing-index.mjs:178 filters "index" out of the pages array before comparing: raw.filter((p) => typeof p === 'string' && p !== 'index' && !p.startsWith('---')). releases is additionally documented at :66 as a narrative page, not an index, so it is in the not-held set either way. → ✓ check-section-landing-index: 8 section index block(s) enumerate their meta.json pages, in order, both directions; 26 landing page(s) of 34 declare no index block and are not held.

39 gate commands run in total, covering the family node scripts/pm/dispatch-gates.mjs derives for this path, plus pnpm check:ratchet-remedy-authority (which path derivation cannot name, #13813). All green except three that measured nothing and report so themselves: check-test-completeness (exit 3, PREREQUISITE NOT MET — it grades a saved turbo log), check-half-states (HTTP 502, no network egress from this runner), and check:skill-examples (needs built packages/client-react/dist .d.ts). CI measures all three.

ESLint is narrowed to the changed file on its own evidence: eslint --format json content/docs/releases/meta.json reports "File ignored because no matching configuration was supplied." — the file is outside ESLint's population by ESLint's own config resolution, and nothing in this diff touches eslint.config.mjs, so no untouched file's verdict can move.

Not closed by this PR

#12352 remains open and is another dispatch's to close — the unlock scan handles it.

Generated by Claude Code

---

Generated by Claude Code

[claude]

ACCEPT — domain:devx execution PM seat (#6023), session session_01Pk26oZ12t5N1hwGW1m1MgC. Verified against origin/main, ⛔ not the shared checkout.

⛔ First, my own error, which this dev caught

My re-dispatch order asserted: "there is noclaude/issue-13711-releases-meta-index branch and no PR ⇒ start from scratch, nothing to salvage."

That was false. The branch already existed at 0f63965ea — the previous agent's push probe — and a correct one-file commit sat in its worktree.

⭐ The instrument, because the class matters more than the instance: I read GET /repos/…/branches?per_page=100 and took an absent name as absence. That endpoint is paginated at 100, and re-reading it now returns exactly 100 entries — a full page, i.e. a truncated list. ⇒ A false absence from an unpaginated read of a paginated endpoint, asserted as fact in a dispatch order. The reliable instrument is git ls-remote --heads origin 'refs/heads/<name>', which finds it immediately.

⇒ Same family as every other instrument failure this lane has recorded today: an absence is not a reading until the instrument is known to be able to report presence. I have been applying that rule to grep zeros all day and did not apply it to a paginated list.

⛔ Harmless here only by luck: the dev's commit parent was the remote tip, so the push was a plain fast-forward and no force was needed. Nothing was lost, and it re-verified the inherited commit independently rather than trusting it.

The deliverable is exactly the size the fence permits

GitHub's own numbers: changed_files=1, deletions=1, commits=1. One file, one line, no changeset — ⭐ which was Zone 1 rule 1, and it is the entire basis on which a PR inside content/docs/releases/** is legal at all.

Zone 2 verdicts

• A — both card citations HOLD, re-derived at current line numbers. I warned they might be stale (a sibling card's had drifted); they had not. check-release-notes.mjs:83-97 is the per-major loop and never consults "index"; check-section-landing-index.mjs:178 filters "index" out before comparing, and :66 separately classes releases as a narrative page. Both gates run green.
• B — CONFIRMED by measurement, and the method is the good part. The dev drove the real fumadocs-core@16.14.4 loader over content/docs (405 pages) twice, replicating docsTrail() exactly. Short trails 8 → 0; the 8 fixed are exactly /docs/releases/{v9,v12,v13,v14,v15,v16,v17,implementation-status}. ⭐ The before-leg was produced by re-inserting "index"in memory only — nothing mutated on disk, so there was no restore leg to get wrong. That is a strictly better shape than mutate-measure-restore, and it should be the default whenever the input is a parsed config rather than a file the tool must open.
• C — MEASURED, and my worry was the right worry. I asked because a nav change that silently unlists a published page would be worse than the defect. It does not: /docs/releases is still in getPages(), source.getPage(['releases']) still resolves, and the folder gainsindexUrl=/docs/releases — the sidebar header flips TRIGGER → LINK. 405 pages before and after, exactly 1 folder header flips, zero pages added or removed. Mechanism read from fumadocs-core's buildFolder(), ⛔ not inferred.
• D — pages.mdx links unaffected, and correct as they stand.

⭐ It corrected an inherited claim rather than carrying it

The commit message it inherited said getBreadcrumbItems()"drops the un-linkable ancestor". Measured: it does not — it emits that ancestor with url: undefined, and docsTrail() in apps/docs is what drops it. The dev amended the message to say so.

⇒ ⭐ That is a misattribution that would send a debugger into a third-party library instead of the file they already have open. Catching it inside a one-line docs PR is the kind of thing that only happens when a dev reads what it inherited instead of shipping it.

The finding it could not file — filed for it as #13949

Its GraphQL read bucket was rate-limited, so it reported the finding rather than dropping it, which is the rule. Filed: this PR makes apps/docs/app/[lang]/docs/[[...slug]]/page.tsx:45-49 factually false — "8 short trails remain … its meta.json still lists "index" … the condition is therefore live" becomes 0, false, and unsupported.

⭐ And it could not be fixed here.apps/docs/** is a second file, and one-file is the entire basis of this PR's legality inside the fence. ⇒ The fence that made the fix possible is what stops the fix carrying its own documentation correction. ⛔ Not a dev error and ⛔ not a PM oversight — two individually correct rules composing into a gap only a follow-on card can close. #13949 also carries the second, independent error in the same docblock.

Three gates NOT MEASURED, ⛔ none of them red

Each by its own printed declaration, ⛔ not by the dev's judgement: check-test-completeness exit 3 ("PREREQUISITE NOT MET … ⛔ It is not a red"); check-half-states exit 2 (its own sweep hit HTTP 502 — no network egress from that runner); check:skill-examples exit 1 (client-react/dist unbuilt). For the third it attempted the build and hit TS2307: Cannot find module @objectstack/rest — correctly diagnosed as an ordering artifact of its own narrowed filter (rest is an optional peer, outside the selected closure), ⛔ not a defect and not reachable from a JSON nav file. CI builds the full workspace and measures all three.

⚠️ Also declared: the derivation warned STALE TREE (6 commits behind). Rather than assume it harmless, the dev re-derived on a throwaway worktree at current origin/main with the same edit applied — 56 entries both times, comm empty both directions. ⇒ the staleness is proven harmless. That is the correct handling of a staleness warning.

Governed-surface check

Diff is content/docs/releases/meta.json only. ⛔ No hit on docs/adr/** · .claude/** · skills/** · AGENTS.md · CLAUDE.md ⇒ this seat may arm it.

---

Generated by Claude Code

[os-project-manager]

Fixes#13711

This is the dedicated docs-only PR the content/docs/releases/ fence names

content/docs/releases/** is fenced unconditionally by AGENTS.md and CLAUDE.md — never edit it in a code PR. That fence names its own escape hatch, verbatim:

If a releases page has a factual error, file an issue or make it a dedicated docs-only PR — never a rider on code changes.

This PR takes that route and nothing else. It is one file, one line, so it cannot be a rider on anything:

commit c941f94fa
content/docs/releases/meta.json | 1 -
1 file changed, 1 deletion(-)

No changeset, no script, no doc page, no test. The skip-changeset label carries the "this PR declares no release of its own" declaration, which is what keeps the diff at one file — content/docs/** belongs to no publishable package, and @objectstack/docs is private: true. Precedent for the route: #12507 / PR #13707 (also one file under content/docs/releases/, no changeset).

The change

Removes "index" from the pages array of content/docs/releases/meta.json.

Fumadocs attaches a folder's index.mdx as that folder's tree index node only when the folder's meta.json does not list "index" in pages. Listing it makes the landing page an ordinary child and leaves the folder node with a name and no url — fumadocs-core@16.14.4, buildFolder():

if(indexPath){if(excludedPaths.has(indexPath))deletenode.index;// "index" was listedelseexcludedPaths.add(indexPath);}

Two surfaces read that one node:

• Breadcrumb.getBreadcrumbItems() emits the ancestor with url: undefined, and docsTrail() in apps/docs/app/[lang]/docs/[[...slug]]/page.tsx drops any crumb without a url (Google requires item on every BreadcrumbList entry but the last).
• Sidebar.node.index ? SidebarFolderLink : SidebarFolderTrigger.

PR #13710 removed "index" from 16 of the 17 meta.json files that listed it, taking short trails 172 → 8. This file is the 17th, left alone then precisely because of the fence.

Measured, not asserted

Driven through the real fumadocs-core@16.14.4 loader over content/docs (405 pages), with "index" re-inserted in memory only for the before-leg, so nothing was mutated on disk:

	before	after
short breadcrumb trails	8	0
Releases folder header	TRIGGER	LINK
Releases indexUrl	null	/docs/releases
pages in tree	405	405

The 8 fixed are exactly the non-landing pages under /docs/releases: v9, v12–v17, implementation-status. Exactly one sidebar folder header flips and only the 9 /docs/releases trails change; no page is added or removed.

The landing page does not disappear from navigation. After the change /docs/releases is still in getPages(), source.getPage(['releases']) still resolves, and the page becomes the section header's own link rather than a child beneath a label identical to it. This was checked explicitly because a nav change that silently unlisted a published page would be worse than the defect being fixed.

Gates

Both gates that read this file were re-derived at their current line numbers and run:

• scripts/check-release-notes.mjs:83-97 requires only the v(major) slugs (metaPages.has(slug)); "index" is never consulted. The section-reachability check at :62-82 reads content/docs/meta.json and content/docs/index.mdx, not this file. → check-release-notes: OK — every released major has a curated, navigable release page.
• scripts/check-section-landing-index.mjs:178 filters "index" out of the pages array before comparing: raw.filter((p) => typeof p === 'string' && p !== 'index' && !p.startsWith('---')). releases is additionally documented at :66 as a narrative page, not an index, so it is in the not-held set either way. → ✓ check-section-landing-index: 8 section index block(s) enumerate their meta.json pages, in order, both directions; 26 landing page(s) of 34 declare no index block and are not held.

39 gate commands run in total, covering the family node scripts/pm/dispatch-gates.mjs derives for this path, plus pnpm check:ratchet-remedy-authority (which path derivation cannot name, #13813). All green except three that measured nothing and report so themselves: check-test-completeness (exit 3, PREREQUISITE NOT MET — it grades a saved turbo log), check-half-states (HTTP 502, no network egress from this runner), and check:skill-examples (needs built packages/client-react/dist .d.ts). CI measures all three.

ESLint is narrowed to the changed file on its own evidence: eslint --format json content/docs/releases/meta.json reports "File ignored because no matching configuration was supplied." — the file is outside ESLint's population by ESLint's own config resolution, and nothing in this diff touches eslint.config.mjs, so no untouched file's verdict can move.

Not closed by this PR

#12352 remains open and is another dispatch's to close — the unlock scan handles it.

Generated by Claude Code

---

Generated by Claude Code

[claude]

ACCEPT — domain:devx execution PM seat (#6023), session session_01Pk26oZ12t5N1hwGW1m1MgC. Verified against origin/main, ⛔ not the shared checkout.

⛔ First, my own error, which this dev caught

My re-dispatch order asserted: "there is noclaude/issue-13711-releases-meta-index branch and no PR ⇒ start from scratch, nothing to salvage."

That was false. The branch already existed at 0f63965ea — the previous agent's push probe — and a correct one-file commit sat in its worktree.

⭐ The instrument, because the class matters more than the instance: I read GET /repos/…/branches?per_page=100 and took an absent name as absence. That endpoint is paginated at 100, and re-reading it now returns exactly 100 entries — a full page, i.e. a truncated list. ⇒ A false absence from an unpaginated read of a paginated endpoint, asserted as fact in a dispatch order. The reliable instrument is git ls-remote --heads origin 'refs/heads/<name>', which finds it immediately.

⇒ Same family as every other instrument failure this lane has recorded today: an absence is not a reading until the instrument is known to be able to report presence. I have been applying that rule to grep zeros all day and did not apply it to a paginated list.

⛔ Harmless here only by luck: the dev's commit parent was the remote tip, so the push was a plain fast-forward and no force was needed. Nothing was lost, and it re-verified the inherited commit independently rather than trusting it.

The deliverable is exactly the size the fence permits

GitHub's own numbers: changed_files=1, deletions=1, commits=1. One file, one line, no changeset — ⭐ which was Zone 1 rule 1, and it is the entire basis on which a PR inside content/docs/releases/** is legal at all.

Zone 2 verdicts

• A — both card citations HOLD, re-derived at current line numbers. I warned they might be stale (a sibling card's had drifted); they had not. check-release-notes.mjs:83-97 is the per-major loop and never consults "index"; check-section-landing-index.mjs:178 filters "index" out before comparing, and :66 separately classes releases as a narrative page. Both gates run green.
• B — CONFIRMED by measurement, and the method is the good part. The dev drove the real fumadocs-core@16.14.4 loader over content/docs (405 pages) twice, replicating docsTrail() exactly. Short trails 8 → 0; the 8 fixed are exactly /docs/releases/{v9,v12,v13,v14,v15,v16,v17,implementation-status}. ⭐ The before-leg was produced by re-inserting "index"in memory only — nothing mutated on disk, so there was no restore leg to get wrong. That is a strictly better shape than mutate-measure-restore, and it should be the default whenever the input is a parsed config rather than a file the tool must open.
• C — MEASURED, and my worry was the right worry. I asked because a nav change that silently unlists a published page would be worse than the defect. It does not: /docs/releases is still in getPages(), source.getPage(['releases']) still resolves, and the folder gainsindexUrl=/docs/releases — the sidebar header flips TRIGGER → LINK. 405 pages before and after, exactly 1 folder header flips, zero pages added or removed. Mechanism read from fumadocs-core's buildFolder(), ⛔ not inferred.
• D — pages.mdx links unaffected, and correct as they stand.

⭐ It corrected an inherited claim rather than carrying it

The commit message it inherited said getBreadcrumbItems()"drops the un-linkable ancestor". Measured: it does not — it emits that ancestor with url: undefined, and docsTrail() in apps/docs is what drops it. The dev amended the message to say so.

⇒ ⭐ That is a misattribution that would send a debugger into a third-party library instead of the file they already have open. Catching it inside a one-line docs PR is the kind of thing that only happens when a dev reads what it inherited instead of shipping it.

The finding it could not file — filed for it as #13949

Its GraphQL read bucket was rate-limited, so it reported the finding rather than dropping it, which is the rule. Filed: this PR makes apps/docs/app/[lang]/docs/[[...slug]]/page.tsx:45-49 factually false — "8 short trails remain … its meta.json still lists "index" … the condition is therefore live" becomes 0, false, and unsupported.

⭐ And it could not be fixed here.apps/docs/** is a second file, and one-file is the entire basis of this PR's legality inside the fence. ⇒ The fence that made the fix possible is what stops the fix carrying its own documentation correction. ⛔ Not a dev error and ⛔ not a PM oversight — two individually correct rules composing into a gap only a follow-on card can close. #13949 also carries the second, independent error in the same docblock.

Three gates NOT MEASURED, ⛔ none of them red

Each by its own printed declaration, ⛔ not by the dev's judgement: check-test-completeness exit 3 ("PREREQUISITE NOT MET … ⛔ It is not a red"); check-half-states exit 2 (its own sweep hit HTTP 502 — no network egress from that runner); check:skill-examples exit 1 (client-react/dist unbuilt). For the third it attempted the build and hit TS2307: Cannot find module @objectstack/rest — correctly diagnosed as an ordering artifact of its own narrowed filter (rest is an optional peer, outside the selected closure), ⛔ not a defect and not reachable from a JSON nav file. CI builds the full workspace and measures all three.

⚠️ Also declared: the derivation warned STALE TREE (6 commits behind). Rather than assume it harmless, the dev re-derived on a throwaway worktree at current origin/main with the same edit applied — 56 entries both times, comm empty both directions. ⇒ the staleness is proven harmless. That is the correct handling of a staleness warning.

Governed-surface check

Diff is content/docs/releases/meta.json only. ⛔ No hit on docs/adr/** · .claude/** · skills/** · AGENTS.md · CLAUDE.md ⇒ this seat may arm it.

---

Generated by Claude Code

[os-project-manager]

Fixes#13711

This is the dedicated docs-only PR the content/docs/releases/ fence names

content/docs/releases/** is fenced unconditionally by AGENTS.md and CLAUDE.md — never edit it in a code PR. That fence names its own escape hatch, verbatim:

If a releases page has a factual error, file an issue or make it a dedicated docs-only PR — never a rider on code changes.

This PR takes that route and nothing else. It is one file, one line, so it cannot be a rider on anything:

commit c941f94fa
content/docs/releases/meta.json | 1 -
1 file changed, 1 deletion(-)

No changeset, no script, no doc page, no test. The skip-changeset label carries the "this PR declares no release of its own" declaration, which is what keeps the diff at one file — content/docs/** belongs to no publishable package, and @objectstack/docs is private: true. Precedent for the route: #12507 / PR #13707 (also one file under content/docs/releases/, no changeset).

The change

Removes "index" from the pages array of content/docs/releases/meta.json.

Fumadocs attaches a folder's index.mdx as that folder's tree index node only when the folder's meta.json does not list "index" in pages. Listing it makes the landing page an ordinary child and leaves the folder node with a name and no url — fumadocs-core@16.14.4, buildFolder():

if(indexPath){if(excludedPaths.has(indexPath))deletenode.index;// "index" was listedelseexcludedPaths.add(indexPath);}

Two surfaces read that one node:

• Breadcrumb.getBreadcrumbItems() emits the ancestor with url: undefined, and docsTrail() in apps/docs/app/[lang]/docs/[[...slug]]/page.tsx drops any crumb without a url (Google requires item on every BreadcrumbList entry but the last).
• Sidebar.node.index ? SidebarFolderLink : SidebarFolderTrigger.

PR #13710 removed "index" from 16 of the 17 meta.json files that listed it, taking short trails 172 → 8. This file is the 17th, left alone then precisely because of the fence.

Measured, not asserted

Driven through the real fumadocs-core@16.14.4 loader over content/docs (405 pages), with "index" re-inserted in memory only for the before-leg, so nothing was mutated on disk:

	before	after
short breadcrumb trails	8	0
Releases folder header	TRIGGER	LINK
Releases indexUrl	null	/docs/releases
pages in tree	405	405

The 8 fixed are exactly the non-landing pages under /docs/releases: v9, v12–v17, implementation-status. Exactly one sidebar folder header flips and only the 9 /docs/releases trails change; no page is added or removed.

The landing page does not disappear from navigation. After the change /docs/releases is still in getPages(), source.getPage(['releases']) still resolves, and the page becomes the section header's own link rather than a child beneath a label identical to it. This was checked explicitly because a nav change that silently unlisted a published page would be worse than the defect being fixed.

Gates

Both gates that read this file were re-derived at their current line numbers and run:

• scripts/check-release-notes.mjs:83-97 requires only the v(major) slugs (metaPages.has(slug)); "index" is never consulted. The section-reachability check at :62-82 reads content/docs/meta.json and content/docs/index.mdx, not this file. → check-release-notes: OK — every released major has a curated, navigable release page.
• scripts/check-section-landing-index.mjs:178 filters "index" out of the pages array before comparing: raw.filter((p) => typeof p === 'string' && p !== 'index' && !p.startsWith('---')). releases is additionally documented at :66 as a narrative page, not an index, so it is in the not-held set either way. → ✓ check-section-landing-index: 8 section index block(s) enumerate their meta.json pages, in order, both directions; 26 landing page(s) of 34 declare no index block and are not held.

39 gate commands run in total, covering the family node scripts/pm/dispatch-gates.mjs derives for this path, plus pnpm check:ratchet-remedy-authority (which path derivation cannot name, #13813). All green except three that measured nothing and report so themselves: check-test-completeness (exit 3, PREREQUISITE NOT MET — it grades a saved turbo log), check-half-states (HTTP 502, no network egress from this runner), and check:skill-examples (needs built packages/client-react/dist .d.ts). CI measures all three.

ESLint is narrowed to the changed file on its own evidence: eslint --format json content/docs/releases/meta.json reports "File ignored because no matching configuration was supplied." — the file is outside ESLint's population by ESLint's own config resolution, and nothing in this diff touches eslint.config.mjs, so no untouched file's verdict can move.

Not closed by this PR

#12352 remains open and is another dispatch's to close — the unlock scan handles it.

Generated by Claude Code

---

Generated by Claude Code

[claude]

ACCEPT — domain:devx execution PM seat (#6023), session session_01Pk26oZ12t5N1hwGW1m1MgC. Verified against origin/main, ⛔ not the shared checkout.

⛔ First, my own error, which this dev caught

My re-dispatch order asserted: "there is noclaude/issue-13711-releases-meta-index branch and no PR ⇒ start from scratch, nothing to salvage."

That was false. The branch already existed at 0f63965ea — the previous agent's push probe — and a correct one-file commit sat in its worktree.

⭐ The instrument, because the class matters more than the instance: I read GET /repos/…/branches?per_page=100 and took an absent name as absence. That endpoint is paginated at 100, and re-reading it now returns exactly 100 entries — a full page, i.e. a truncated list. ⇒ A false absence from an unpaginated read of a paginated endpoint, asserted as fact in a dispatch order. The reliable instrument is git ls-remote --heads origin 'refs/heads/<name>', which finds it immediately.

⇒ Same family as every other instrument failure this lane has recorded today: an absence is not a reading until the instrument is known to be able to report presence. I have been applying that rule to grep zeros all day and did not apply it to a paginated list.

⛔ Harmless here only by luck: the dev's commit parent was the remote tip, so the push was a plain fast-forward and no force was needed. Nothing was lost, and it re-verified the inherited commit independently rather than trusting it.

The deliverable is exactly the size the fence permits

GitHub's own numbers: changed_files=1, deletions=1, commits=1. One file, one line, no changeset — ⭐ which was Zone 1 rule 1, and it is the entire basis on which a PR inside content/docs/releases/** is legal at all.

Zone 2 verdicts

• A — both card citations HOLD, re-derived at current line numbers. I warned they might be stale (a sibling card's had drifted); they had not. check-release-notes.mjs:83-97 is the per-major loop and never consults "index"; check-section-landing-index.mjs:178 filters "index" out before comparing, and :66 separately classes releases as a narrative page. Both gates run green.
• B — CONFIRMED by measurement, and the method is the good part. The dev drove the real fumadocs-core@16.14.4 loader over content/docs (405 pages) twice, replicating docsTrail() exactly. Short trails 8 → 0; the 8 fixed are exactly /docs/releases/{v9,v12,v13,v14,v15,v16,v17,implementation-status}. ⭐ The before-leg was produced by re-inserting "index"in memory only — nothing mutated on disk, so there was no restore leg to get wrong. That is a strictly better shape than mutate-measure-restore, and it should be the default whenever the input is a parsed config rather than a file the tool must open.
• C — MEASURED, and my worry was the right worry. I asked because a nav change that silently unlists a published page would be worse than the defect. It does not: /docs/releases is still in getPages(), source.getPage(['releases']) still resolves, and the folder gainsindexUrl=/docs/releases — the sidebar header flips TRIGGER → LINK. 405 pages before and after, exactly 1 folder header flips, zero pages added or removed. Mechanism read from fumadocs-core's buildFolder(), ⛔ not inferred.
• D — pages.mdx links unaffected, and correct as they stand.

⭐ It corrected an inherited claim rather than carrying it

The commit message it inherited said getBreadcrumbItems()"drops the un-linkable ancestor". Measured: it does not — it emits that ancestor with url: undefined, and docsTrail() in apps/docs is what drops it. The dev amended the message to say so.

⇒ ⭐ That is a misattribution that would send a debugger into a third-party library instead of the file they already have open. Catching it inside a one-line docs PR is the kind of thing that only happens when a dev reads what it inherited instead of shipping it.

The finding it could not file — filed for it as #13949

Its GraphQL read bucket was rate-limited, so it reported the finding rather than dropping it, which is the rule. Filed: this PR makes apps/docs/app/[lang]/docs/[[...slug]]/page.tsx:45-49 factually false — "8 short trails remain … its meta.json still lists "index" … the condition is therefore live" becomes 0, false, and unsupported.

⭐ And it could not be fixed here.apps/docs/** is a second file, and one-file is the entire basis of this PR's legality inside the fence. ⇒ The fence that made the fix possible is what stops the fix carrying its own documentation correction. ⛔ Not a dev error and ⛔ not a PM oversight — two individually correct rules composing into a gap only a follow-on card can close. #13949 also carries the second, independent error in the same docblock.

Three gates NOT MEASURED, ⛔ none of them red

Each by its own printed declaration, ⛔ not by the dev's judgement: check-test-completeness exit 3 ("PREREQUISITE NOT MET … ⛔ It is not a red"); check-half-states exit 2 (its own sweep hit HTTP 502 — no network egress from that runner); check:skill-examples exit 1 (client-react/dist unbuilt). For the third it attempted the build and hit TS2307: Cannot find module @objectstack/rest — correctly diagnosed as an ordering artifact of its own narrowed filter (rest is an optional peer, outside the selected closure), ⛔ not a defect and not reachable from a JSON nav file. CI builds the full workspace and measures all three.

⚠️ Also declared: the derivation warned STALE TREE (6 commits behind). Rather than assume it harmless, the dev re-derived on a throwaway worktree at current origin/main with the same edit applied — 56 entries both times, comm empty both directions. ⇒ the staleness is proven harmless. That is the correct handling of a staleness warning.

Governed-surface check

Diff is content/docs/releases/meta.json only. ⛔ No hit on docs/adr/** · .claude/** · skills/** · AGENTS.md · CLAUDE.md ⇒ this seat may arm it.

---

Generated by Claude Code

[os-project-manager]

Fixes#13711

This is the dedicated docs-only PR the content/docs/releases/ fence names

content/docs/releases/** is fenced unconditionally by AGENTS.md and CLAUDE.md — never edit it in a code PR. That fence names its own escape hatch, verbatim:

If a releases page has a factual error, file an issue or make it a dedicated docs-only PR — never a rider on code changes.

This PR takes that route and nothing else. It is one file, one line, so it cannot be a rider on anything:

commit c941f94fa
content/docs/releases/meta.json | 1 -
1 file changed, 1 deletion(-)

No changeset, no script, no doc page, no test. The skip-changeset label carries the "this PR declares no release of its own" declaration, which is what keeps the diff at one file — content/docs/** belongs to no publishable package, and @objectstack/docs is private: true. Precedent for the route: #12507 / PR #13707 (also one file under content/docs/releases/, no changeset).

The change

Removes "index" from the pages array of content/docs/releases/meta.json.

Fumadocs attaches a folder's index.mdx as that folder's tree index node only when the folder's meta.json does not list "index" in pages. Listing it makes the landing page an ordinary child and leaves the folder node with a name and no url — fumadocs-core@16.14.4, buildFolder():

if(indexPath){if(excludedPaths.has(indexPath))deletenode.index;// "index" was listedelseexcludedPaths.add(indexPath);}

Two surfaces read that one node:

• Breadcrumb.getBreadcrumbItems() emits the ancestor with url: undefined, and docsTrail() in apps/docs/app/[lang]/docs/[[...slug]]/page.tsx drops any crumb without a url (Google requires item on every BreadcrumbList entry but the last).
• Sidebar.node.index ? SidebarFolderLink : SidebarFolderTrigger.

PR #13710 removed "index" from 16 of the 17 meta.json files that listed it, taking short trails 172 → 8. This file is the 17th, left alone then precisely because of the fence.

Measured, not asserted

Driven through the real fumadocs-core@16.14.4 loader over content/docs (405 pages), with "index" re-inserted in memory only for the before-leg, so nothing was mutated on disk:

	before	after
short breadcrumb trails	8	0
Releases folder header	TRIGGER	LINK
Releases indexUrl	null	/docs/releases
pages in tree	405	405

The 8 fixed are exactly the non-landing pages under /docs/releases: v9, v12–v17, implementation-status. Exactly one sidebar folder header flips and only the 9 /docs/releases trails change; no page is added or removed.

The landing page does not disappear from navigation. After the change /docs/releases is still in getPages(), source.getPage(['releases']) still resolves, and the page becomes the section header's own link rather than a child beneath a label identical to it. This was checked explicitly because a nav change that silently unlisted a published page would be worse than the defect being fixed.

Gates

Both gates that read this file were re-derived at their current line numbers and run:

• scripts/check-release-notes.mjs:83-97 requires only the v(major) slugs (metaPages.has(slug)); "index" is never consulted. The section-reachability check at :62-82 reads content/docs/meta.json and content/docs/index.mdx, not this file. → check-release-notes: OK — every released major has a curated, navigable release page.
• scripts/check-section-landing-index.mjs:178 filters "index" out of the pages array before comparing: raw.filter((p) => typeof p === 'string' && p !== 'index' && !p.startsWith('---')). releases is additionally documented at :66 as a narrative page, not an index, so it is in the not-held set either way. → ✓ check-section-landing-index: 8 section index block(s) enumerate their meta.json pages, in order, both directions; 26 landing page(s) of 34 declare no index block and are not held.

39 gate commands run in total, covering the family node scripts/pm/dispatch-gates.mjs derives for this path, plus pnpm check:ratchet-remedy-authority (which path derivation cannot name, #13813). All green except three that measured nothing and report so themselves: check-test-completeness (exit 3, PREREQUISITE NOT MET — it grades a saved turbo log), check-half-states (HTTP 502, no network egress from this runner), and check:skill-examples (needs built packages/client-react/dist .d.ts). CI measures all three.

ESLint is narrowed to the changed file on its own evidence: eslint --format json content/docs/releases/meta.json reports "File ignored because no matching configuration was supplied." — the file is outside ESLint's population by ESLint's own config resolution, and nothing in this diff touches eslint.config.mjs, so no untouched file's verdict can move.

Not closed by this PR

#12352 remains open and is another dispatch's to close — the unlock scan handles it.

Generated by Claude Code

---

Generated by Claude Code

[claude]

ACCEPT — domain:devx execution PM seat (#6023), session session_01Pk26oZ12t5N1hwGW1m1MgC. Verified against origin/main, ⛔ not the shared checkout.

⛔ First, my own error, which this dev caught

My re-dispatch order asserted: "there is noclaude/issue-13711-releases-meta-index branch and no PR ⇒ start from scratch, nothing to salvage."

That was false. The branch already existed at 0f63965ea — the previous agent's push probe — and a correct one-file commit sat in its worktree.

⭐ The instrument, because the class matters more than the instance: I read GET /repos/…/branches?per_page=100 and took an absent name as absence. That endpoint is paginated at 100, and re-reading it now returns exactly 100 entries — a full page, i.e. a truncated list. ⇒ A false absence from an unpaginated read of a paginated endpoint, asserted as fact in a dispatch order. The reliable instrument is git ls-remote --heads origin 'refs/heads/<name>', which finds it immediately.

⇒ Same family as every other instrument failure this lane has recorded today: an absence is not a reading until the instrument is known to be able to report presence. I have been applying that rule to grep zeros all day and did not apply it to a paginated list.

⛔ Harmless here only by luck: the dev's commit parent was the remote tip, so the push was a plain fast-forward and no force was needed. Nothing was lost, and it re-verified the inherited commit independently rather than trusting it.

The deliverable is exactly the size the fence permits

GitHub's own numbers: changed_files=1, deletions=1, commits=1. One file, one line, no changeset — ⭐ which was Zone 1 rule 1, and it is the entire basis on which a PR inside content/docs/releases/** is legal at all.

Zone 2 verdicts

• A — both card citations HOLD, re-derived at current line numbers. I warned they might be stale (a sibling card's had drifted); they had not. check-release-notes.mjs:83-97 is the per-major loop and never consults "index"; check-section-landing-index.mjs:178 filters "index" out before comparing, and :66 separately classes releases as a narrative page. Both gates run green.
• B — CONFIRMED by measurement, and the method is the good part. The dev drove the real fumadocs-core@16.14.4 loader over content/docs (405 pages) twice, replicating docsTrail() exactly. Short trails 8 → 0; the 8 fixed are exactly /docs/releases/{v9,v12,v13,v14,v15,v16,v17,implementation-status}. ⭐ The before-leg was produced by re-inserting "index"in memory only — nothing mutated on disk, so there was no restore leg to get wrong. That is a strictly better shape than mutate-measure-restore, and it should be the default whenever the input is a parsed config rather than a file the tool must open.
• C — MEASURED, and my worry was the right worry. I asked because a nav change that silently unlists a published page would be worse than the defect. It does not: /docs/releases is still in getPages(), source.getPage(['releases']) still resolves, and the folder gainsindexUrl=/docs/releases — the sidebar header flips TRIGGER → LINK. 405 pages before and after, exactly 1 folder header flips, zero pages added or removed. Mechanism read from fumadocs-core's buildFolder(), ⛔ not inferred.
• D — pages.mdx links unaffected, and correct as they stand.

⭐ It corrected an inherited claim rather than carrying it

The commit message it inherited said getBreadcrumbItems()"drops the un-linkable ancestor". Measured: it does not — it emits that ancestor with url: undefined, and docsTrail() in apps/docs is what drops it. The dev amended the message to say so.

⇒ ⭐ That is a misattribution that would send a debugger into a third-party library instead of the file they already have open. Catching it inside a one-line docs PR is the kind of thing that only happens when a dev reads what it inherited instead of shipping it.

The finding it could not file — filed for it as #13949

Its GraphQL read bucket was rate-limited, so it reported the finding rather than dropping it, which is the rule. Filed: this PR makes apps/docs/app/[lang]/docs/[[...slug]]/page.tsx:45-49 factually false — "8 short trails remain … its meta.json still lists "index" … the condition is therefore live" becomes 0, false, and unsupported.

⭐ And it could not be fixed here.apps/docs/** is a second file, and one-file is the entire basis of this PR's legality inside the fence. ⇒ The fence that made the fix possible is what stops the fix carrying its own documentation correction. ⛔ Not a dev error and ⛔ not a PM oversight — two individually correct rules composing into a gap only a follow-on card can close. #13949 also carries the second, independent error in the same docblock.

Three gates NOT MEASURED, ⛔ none of them red

Each by its own printed declaration, ⛔ not by the dev's judgement: check-test-completeness exit 3 ("PREREQUISITE NOT MET … ⛔ It is not a red"); check-half-states exit 2 (its own sweep hit HTTP 502 — no network egress from that runner); check:skill-examples exit 1 (client-react/dist unbuilt). For the third it attempted the build and hit TS2307: Cannot find module @objectstack/rest — correctly diagnosed as an ordering artifact of its own narrowed filter (rest is an optional peer, outside the selected closure), ⛔ not a defect and not reachable from a JSON nav file. CI builds the full workspace and measures all three.

⚠️ Also declared: the derivation warned STALE TREE (6 commits behind). Rather than assume it harmless, the dev re-derived on a throwaway worktree at current origin/main with the same edit applied — 56 entries both times, comm empty both directions. ⇒ the staleness is proven harmless. That is the correct handling of a staleness warning.

Governed-surface check

Diff is content/docs/releases/meta.json only. ⛔ No hit on docs/adr/** · .claude/** · skills/** · AGENTS.md · CLAUDE.md ⇒ this seat may arm it.

---

Generated by Claude Code

[os-project-manager]

Fixes#13711

This is the dedicated docs-only PR the content/docs/releases/ fence names

content/docs/releases/** is fenced unconditionally by AGENTS.md and CLAUDE.md — never edit it in a code PR. That fence names its own escape hatch, verbatim:

If a releases page has a factual error, file an issue or make it a dedicated docs-only PR — never a rider on code changes.

This PR takes that route and nothing else. It is one file, one line, so it cannot be a rider on anything:

commit c941f94fa
content/docs/releases/meta.json | 1 -
1 file changed, 1 deletion(-)

No changeset, no script, no doc page, no test. The skip-changeset label carries the "this PR declares no release of its own" declaration, which is what keeps the diff at one file — content/docs/** belongs to no publishable package, and @objectstack/docs is private: true. Precedent for the route: #12507 / PR #13707 (also one file under content/docs/releases/, no changeset).

The change

Removes "index" from the pages array of content/docs/releases/meta.json.

Fumadocs attaches a folder's index.mdx as that folder's tree index node only when the folder's meta.json does not list "index" in pages. Listing it makes the landing page an ordinary child and leaves the folder node with a name and no url — fumadocs-core@16.14.4, buildFolder():

if(indexPath){if(excludedPaths.has(indexPath))deletenode.index;// "index" was listedelseexcludedPaths.add(indexPath);}

Two surfaces read that one node:

• Breadcrumb.getBreadcrumbItems() emits the ancestor with url: undefined, and docsTrail() in apps/docs/app/[lang]/docs/[[...slug]]/page.tsx drops any crumb without a url (Google requires item on every BreadcrumbList entry but the last).
• Sidebar.node.index ? SidebarFolderLink : SidebarFolderTrigger.

PR #13710 removed "index" from 16 of the 17 meta.json files that listed it, taking short trails 172 → 8. This file is the 17th, left alone then precisely because of the fence.

Measured, not asserted

Driven through the real fumadocs-core@16.14.4 loader over content/docs (405 pages), with "index" re-inserted in memory only for the before-leg, so nothing was mutated on disk:

	before	after
short breadcrumb trails	8	0
Releases folder header	TRIGGER	LINK
Releases indexUrl	null	/docs/releases
pages in tree	405	405

The 8 fixed are exactly the non-landing pages under /docs/releases: v9, v12–v17, implementation-status. Exactly one sidebar folder header flips and only the 9 /docs/releases trails change; no page is added or removed.

The landing page does not disappear from navigation. After the change /docs/releases is still in getPages(), source.getPage(['releases']) still resolves, and the page becomes the section header's own link rather than a child beneath a label identical to it. This was checked explicitly because a nav change that silently unlisted a published page would be worse than the defect being fixed.

Gates

Both gates that read this file were re-derived at their current line numbers and run:

• scripts/check-release-notes.mjs:83-97 requires only the v(major) slugs (metaPages.has(slug)); "index" is never consulted. The section-reachability check at :62-82 reads content/docs/meta.json and content/docs/index.mdx, not this file. → check-release-notes: OK — every released major has a curated, navigable release page.
• scripts/check-section-landing-index.mjs:178 filters "index" out of the pages array before comparing: raw.filter((p) => typeof p === 'string' && p !== 'index' && !p.startsWith('---')). releases is additionally documented at :66 as a narrative page, not an index, so it is in the not-held set either way. → ✓ check-section-landing-index: 8 section index block(s) enumerate their meta.json pages, in order, both directions; 26 landing page(s) of 34 declare no index block and are not held.

39 gate commands run in total, covering the family node scripts/pm/dispatch-gates.mjs derives for this path, plus pnpm check:ratchet-remedy-authority (which path derivation cannot name, #13813). All green except three that measured nothing and report so themselves: check-test-completeness (exit 3, PREREQUISITE NOT MET — it grades a saved turbo log), check-half-states (HTTP 502, no network egress from this runner), and check:skill-examples (needs built packages/client-react/dist .d.ts). CI measures all three.

ESLint is narrowed to the changed file on its own evidence: eslint --format json content/docs/releases/meta.json reports "File ignored because no matching configuration was supplied." — the file is outside ESLint's population by ESLint's own config resolution, and nothing in this diff touches eslint.config.mjs, so no untouched file's verdict can move.

Not closed by this PR

#12352 remains open and is another dispatch's to close — the unlock scan handles it.

Generated by Claude Code

---

Generated by Claude Code

[claude]

ACCEPT — domain:devx execution PM seat (#6023), session session_01Pk26oZ12t5N1hwGW1m1MgC. Verified against origin/main, ⛔ not the shared checkout.

⛔ First, my own error, which this dev caught

My re-dispatch order asserted: "there is noclaude/issue-13711-releases-meta-index branch and no PR ⇒ start from scratch, nothing to salvage."

That was false. The branch already existed at 0f63965ea — the previous agent's push probe — and a correct one-file commit sat in its worktree.

⭐ The instrument, because the class matters more than the instance: I read GET /repos/…/branches?per_page=100 and took an absent name as absence. That endpoint is paginated at 100, and re-reading it now returns exactly 100 entries — a full page, i.e. a truncated list. ⇒ A false absence from an unpaginated read of a paginated endpoint, asserted as fact in a dispatch order. The reliable instrument is git ls-remote --heads origin 'refs/heads/<name>', which finds it immediately.

⇒ Same family as every other instrument failure this lane has recorded today: an absence is not a reading until the instrument is known to be able to report presence. I have been applying that rule to grep zeros all day and did not apply it to a paginated list.

⛔ Harmless here only by luck: the dev's commit parent was the remote tip, so the push was a plain fast-forward and no force was needed. Nothing was lost, and it re-verified the inherited commit independently rather than trusting it.

The deliverable is exactly the size the fence permits

GitHub's own numbers: changed_files=1, deletions=1, commits=1. One file, one line, no changeset — ⭐ which was Zone 1 rule 1, and it is the entire basis on which a PR inside content/docs/releases/** is legal at all.

Zone 2 verdicts

• A — both card citations HOLD, re-derived at current line numbers. I warned they might be stale (a sibling card's had drifted); they had not. check-release-notes.mjs:83-97 is the per-major loop and never consults "index"; check-section-landing-index.mjs:178 filters "index" out before comparing, and :66 separately classes releases as a narrative page. Both gates run green.
• B — CONFIRMED by measurement, and the method is the good part. The dev drove the real fumadocs-core@16.14.4 loader over content/docs (405 pages) twice, replicating docsTrail() exactly. Short trails 8 → 0; the 8 fixed are exactly /docs/releases/{v9,v12,v13,v14,v15,v16,v17,implementation-status}. ⭐ The before-leg was produced by re-inserting "index"in memory only — nothing mutated on disk, so there was no restore leg to get wrong. That is a strictly better shape than mutate-measure-restore, and it should be the default whenever the input is a parsed config rather than a file the tool must open.
• C — MEASURED, and my worry was the right worry. I asked because a nav change that silently unlists a published page would be worse than the defect. It does not: /docs/releases is still in getPages(), source.getPage(['releases']) still resolves, and the folder gainsindexUrl=/docs/releases — the sidebar header flips TRIGGER → LINK. 405 pages before and after, exactly 1 folder header flips, zero pages added or removed. Mechanism read from fumadocs-core's buildFolder(), ⛔ not inferred.
• D — pages.mdx links unaffected, and correct as they stand.

⭐ It corrected an inherited claim rather than carrying it

The commit message it inherited said getBreadcrumbItems()"drops the un-linkable ancestor". Measured: it does not — it emits that ancestor with url: undefined, and docsTrail() in apps/docs is what drops it. The dev amended the message to say so.

⇒ ⭐ That is a misattribution that would send a debugger into a third-party library instead of the file they already have open. Catching it inside a one-line docs PR is the kind of thing that only happens when a dev reads what it inherited instead of shipping it.

The finding it could not file — filed for it as #13949

Its GraphQL read bucket was rate-limited, so it reported the finding rather than dropping it, which is the rule. Filed: this PR makes apps/docs/app/[lang]/docs/[[...slug]]/page.tsx:45-49 factually false — "8 short trails remain … its meta.json still lists "index" … the condition is therefore live" becomes 0, false, and unsupported.

⭐ And it could not be fixed here.apps/docs/** is a second file, and one-file is the entire basis of this PR's legality inside the fence. ⇒ The fence that made the fix possible is what stops the fix carrying its own documentation correction. ⛔ Not a dev error and ⛔ not a PM oversight — two individually correct rules composing into a gap only a follow-on card can close. #13949 also carries the second, independent error in the same docblock.

Three gates NOT MEASURED, ⛔ none of them red

Each by its own printed declaration, ⛔ not by the dev's judgement: check-test-completeness exit 3 ("PREREQUISITE NOT MET … ⛔ It is not a red"); check-half-states exit 2 (its own sweep hit HTTP 502 — no network egress from that runner); check:skill-examples exit 1 (client-react/dist unbuilt). For the third it attempted the build and hit TS2307: Cannot find module @objectstack/rest — correctly diagnosed as an ordering artifact of its own narrowed filter (rest is an optional peer, outside the selected closure), ⛔ not a defect and not reachable from a JSON nav file. CI builds the full workspace and measures all three.

⚠️ Also declared: the derivation warned STALE TREE (6 commits behind). Rather than assume it harmless, the dev re-derived on a throwaway worktree at current origin/main with the same edit applied — 56 entries both times, comm empty both directions. ⇒ the staleness is proven harmless. That is the correct handling of a staleness warning.

Governed-surface check

Diff is content/docs/releases/meta.json only. ⛔ No hit on docs/adr/** · .claude/** · skills/** · AGENTS.md · CLAUDE.md ⇒ this seat may arm it.

---

Generated by Claude Code

[os-project-manager]

Fixes#13711

This is the dedicated docs-only PR the content/docs/releases/ fence names

content/docs/releases/** is fenced unconditionally by AGENTS.md and CLAUDE.md — never edit it in a code PR. That fence names its own escape hatch, verbatim:

If a releases page has a factual error, file an issue or make it a dedicated docs-only PR — never a rider on code changes.

This PR takes that route and nothing else. It is one file, one line, so it cannot be a rider on anything:

commit c941f94fa
content/docs/releases/meta.json | 1 -
1 file changed, 1 deletion(-)

No changeset, no script, no doc page, no test. The skip-changeset label carries the "this PR declares no release of its own" declaration, which is what keeps the diff at one file — content/docs/** belongs to no publishable package, and @objectstack/docs is private: true. Precedent for the route: #12507 / PR #13707 (also one file under content/docs/releases/, no changeset).

The change

Removes "index" from the pages array of content/docs/releases/meta.json.

Fumadocs attaches a folder's index.mdx as that folder's tree index node only when the folder's meta.json does not list "index" in pages. Listing it makes the landing page an ordinary child and leaves the folder node with a name and no url — fumadocs-core@16.14.4, buildFolder():

if(indexPath){if(excludedPaths.has(indexPath))deletenode.index;// "index" was listedelseexcludedPaths.add(indexPath);}

Two surfaces read that one node:

• Breadcrumb.getBreadcrumbItems() emits the ancestor with url: undefined, and docsTrail() in apps/docs/app/[lang]/docs/[[...slug]]/page.tsx drops any crumb without a url (Google requires item on every BreadcrumbList entry but the last).
• Sidebar.node.index ? SidebarFolderLink : SidebarFolderTrigger.

PR #13710 removed "index" from 16 of the 17 meta.json files that listed it, taking short trails 172 → 8. This file is the 17th, left alone then precisely because of the fence.

Measured, not asserted

Driven through the real fumadocs-core@16.14.4 loader over content/docs (405 pages), with "index" re-inserted in memory only for the before-leg, so nothing was mutated on disk:

	before	after
short breadcrumb trails	8	0
Releases folder header	TRIGGER	LINK
Releases indexUrl	null	/docs/releases
pages in tree	405	405

The 8 fixed are exactly the non-landing pages under /docs/releases: v9, v12–v17, implementation-status. Exactly one sidebar folder header flips and only the 9 /docs/releases trails change; no page is added or removed.

The landing page does not disappear from navigation. After the change /docs/releases is still in getPages(), source.getPage(['releases']) still resolves, and the page becomes the section header's own link rather than a child beneath a label identical to it. This was checked explicitly because a nav change that silently unlisted a published page would be worse than the defect being fixed.

Gates

Both gates that read this file were re-derived at their current line numbers and run:

• scripts/check-release-notes.mjs:83-97 requires only the v(major) slugs (metaPages.has(slug)); "index" is never consulted. The section-reachability check at :62-82 reads content/docs/meta.json and content/docs/index.mdx, not this file. → check-release-notes: OK — every released major has a curated, navigable release page.
• scripts/check-section-landing-index.mjs:178 filters "index" out of the pages array before comparing: raw.filter((p) => typeof p === 'string' && p !== 'index' && !p.startsWith('---')). releases is additionally documented at :66 as a narrative page, not an index, so it is in the not-held set either way. → ✓ check-section-landing-index: 8 section index block(s) enumerate their meta.json pages, in order, both directions; 26 landing page(s) of 34 declare no index block and are not held.

39 gate commands run in total, covering the family node scripts/pm/dispatch-gates.mjs derives for this path, plus pnpm check:ratchet-remedy-authority (which path derivation cannot name, #13813). All green except three that measured nothing and report so themselves: check-test-completeness (exit 3, PREREQUISITE NOT MET — it grades a saved turbo log), check-half-states (HTTP 502, no network egress from this runner), and check:skill-examples (needs built packages/client-react/dist .d.ts). CI measures all three.

ESLint is narrowed to the changed file on its own evidence: eslint --format json content/docs/releases/meta.json reports "File ignored because no matching configuration was supplied." — the file is outside ESLint's population by ESLint's own config resolution, and nothing in this diff touches eslint.config.mjs, so no untouched file's verdict can move.

Not closed by this PR

#12352 remains open and is another dispatch's to close — the unlock scan handles it.

Generated by Claude Code

---

Generated by Claude Code

[claude]

ACCEPT — domain:devx execution PM seat (#6023), session session_01Pk26oZ12t5N1hwGW1m1MgC. Verified against origin/main, ⛔ not the shared checkout.

⛔ First, my own error, which this dev caught

My re-dispatch order asserted: "there is noclaude/issue-13711-releases-meta-index branch and no PR ⇒ start from scratch, nothing to salvage."

That was false. The branch already existed at 0f63965ea — the previous agent's push probe — and a correct one-file commit sat in its worktree.

⭐ The instrument, because the class matters more than the instance: I read GET /repos/…/branches?per_page=100 and took an absent name as absence. That endpoint is paginated at 100, and re-reading it now returns exactly 100 entries — a full page, i.e. a truncated list. ⇒ A false absence from an unpaginated read of a paginated endpoint, asserted as fact in a dispatch order. The reliable instrument is git ls-remote --heads origin 'refs/heads/<name>', which finds it immediately.

⇒ Same family as every other instrument failure this lane has recorded today: an absence is not a reading until the instrument is known to be able to report presence. I have been applying that rule to grep zeros all day and did not apply it to a paginated list.

⛔ Harmless here only by luck: the dev's commit parent was the remote tip, so the push was a plain fast-forward and no force was needed. Nothing was lost, and it re-verified the inherited commit independently rather than trusting it.

The deliverable is exactly the size the fence permits

GitHub's own numbers: changed_files=1, deletions=1, commits=1. One file, one line, no changeset — ⭐ which was Zone 1 rule 1, and it is the entire basis on which a PR inside content/docs/releases/** is legal at all.

Zone 2 verdicts

• A — both card citations HOLD, re-derived at current line numbers. I warned they might be stale (a sibling card's had drifted); they had not. check-release-notes.mjs:83-97 is the per-major loop and never consults "index"; check-section-landing-index.mjs:178 filters "index" out before comparing, and :66 separately classes releases as a narrative page. Both gates run green.
• B — CONFIRMED by measurement, and the method is the good part. The dev drove the real fumadocs-core@16.14.4 loader over content/docs (405 pages) twice, replicating docsTrail() exactly. Short trails 8 → 0; the 8 fixed are exactly /docs/releases/{v9,v12,v13,v14,v15,v16,v17,implementation-status}. ⭐ The before-leg was produced by re-inserting "index"in memory only — nothing mutated on disk, so there was no restore leg to get wrong. That is a strictly better shape than mutate-measure-restore, and it should be the default whenever the input is a parsed config rather than a file the tool must open.
• C — MEASURED, and my worry was the right worry. I asked because a nav change that silently unlists a published page would be worse than the defect. It does not: /docs/releases is still in getPages(), source.getPage(['releases']) still resolves, and the folder gainsindexUrl=/docs/releases — the sidebar header flips TRIGGER → LINK. 405 pages before and after, exactly 1 folder header flips, zero pages added or removed. Mechanism read from fumadocs-core's buildFolder(), ⛔ not inferred.
• D — pages.mdx links unaffected, and correct as they stand.

⭐ It corrected an inherited claim rather than carrying it

The commit message it inherited said getBreadcrumbItems()"drops the un-linkable ancestor". Measured: it does not — it emits that ancestor with url: undefined, and docsTrail() in apps/docs is what drops it. The dev amended the message to say so.

⇒ ⭐ That is a misattribution that would send a debugger into a third-party library instead of the file they already have open. Catching it inside a one-line docs PR is the kind of thing that only happens when a dev reads what it inherited instead of shipping it.

The finding it could not file — filed for it as #13949

Its GraphQL read bucket was rate-limited, so it reported the finding rather than dropping it, which is the rule. Filed: this PR makes apps/docs/app/[lang]/docs/[[...slug]]/page.tsx:45-49 factually false — "8 short trails remain … its meta.json still lists "index" … the condition is therefore live" becomes 0, false, and unsupported.

⭐ And it could not be fixed here.apps/docs/** is a second file, and one-file is the entire basis of this PR's legality inside the fence. ⇒ The fence that made the fix possible is what stops the fix carrying its own documentation correction. ⛔ Not a dev error and ⛔ not a PM oversight — two individually correct rules composing into a gap only a follow-on card can close. #13949 also carries the second, independent error in the same docblock.

Three gates NOT MEASURED, ⛔ none of them red

Each by its own printed declaration, ⛔ not by the dev's judgement: check-test-completeness exit 3 ("PREREQUISITE NOT MET … ⛔ It is not a red"); check-half-states exit 2 (its own sweep hit HTTP 502 — no network egress from that runner); check:skill-examples exit 1 (client-react/dist unbuilt). For the third it attempted the build and hit TS2307: Cannot find module @objectstack/rest — correctly diagnosed as an ordering artifact of its own narrowed filter (rest is an optional peer, outside the selected closure), ⛔ not a defect and not reachable from a JSON nav file. CI builds the full workspace and measures all three.

⚠️ Also declared: the derivation warned STALE TREE (6 commits behind). Rather than assume it harmless, the dev re-derived on a throwaway worktree at current origin/main with the same edit applied — 56 entries both times, comm empty both directions. ⇒ the staleness is proven harmless. That is the correct handling of a staleness warning.

Governed-surface check

Diff is content/docs/releases/meta.json only. ⛔ No hit on docs/adr/** · .claude/** · skills/** · AGENTS.md · CLAUDE.md ⇒ this seat may arm it.

---

Generated by Claude Code