docs(nav): `releases` sits in the Platform group but every release page declares itself written for app developers

[os-project-manager]

Restart-when: any PR touches the root content/docs/meta.json group layout

Observation recorded while implementing #8909 (see PR #8964). Not fixed there — that card's file surface is the new upgrading.mdx plus its own nav line, and this is a separate structural decision.

The mismatch

Root content/docs/meta.json places releases in the Platform group, beside kernel and protocol:

"---Platform---",
"deployment", "plugins", "kernel", "protocol", "releases"

But content/docs/releases/index.mdx states its own audience explicitly:

Each release page is written for third-party developers building apps, plugins, or clients on ObjectStack. It leads with breaking changes and migration steps...

And the content bears that out — the v17 upgrade checklist is 66 bullets about allowExport, sharedWith.type, RLS priority, and agent.tools[], all metadata-app authoring concerns, none of them kernel or protocol internals.

So the pages are shelved next to the two most internals-facing sections in the docs while being written for the audience that lives in Build.

Why it is only an observation

#8909's card names this mismatch and resolves it a different way — by putting the new upgrading.mdx door in Build rather than by moving releases. That door now exists and links every per-major checklist, so the acute discoverability problem is closed. What remains is the placement itself, which is a maintainer call about nav taxonomy, not an implementation detail:

• Leave it — release notes are arguably a platform-train artifact regardless of who reads them, and upgrading.mdx now provides the audience-appropriate entry point. Zero churn.
• Move releases into Build — matches the stated audience, but puts a growing per-version archive in the group app developers browse daily, and moves a section every existing inbound link points at.
• Something narrower — e.g. leave the section where it is and let the Build-group door remain the only app-developer-facing route in, which is the current post-docs: new content/docs/upgrading.mdx in the Build group — state both upgrade halves and give the per-major checklists a door #8909 state by default.

No behaviour is broken either way; this is discoverability and taxonomy. Recording it so the deployment-docs restructure round can grade it rather than having it noticed a fourth time. Note #8913 re-orders content/docs/deployment/meta.json, a different file, so it does not cover this.

---

Generated by Claude Code

[os-project-manager]

Triage first-touch grading (2026-08-16, triage seat Routine): hold — finding → pm:on-hold, type Task.

Reason. The acute discoverability problem this records is already closed by #8909's upgrading.mdx door (the card says so itself), so there is no measured business pull today: no reader is stranded, and the remaining question is pure nav taxonomy. Along the standing evaluation axes: zero pull ⇒ defer; moving releases breaks every inbound link into a section for zero functional gain (startup scope discipline says the zero-churn option wins by default); AI error-resistance is unaffected either way. This does not meet the decision-inbox bar — the options differ in shelving, not in product semantics or contract shape — so it is graded here rather than escalated.

Named restart conditions (any one re-opens the question; ⛔ no dispatch before then):

1. A PR touches the root content/docs/meta.json group layout (the trigger file for this card — domain:devx seat: pre-dispatch check for cards touching that file should name this card and treat the move as a declarable rider, per the opportunistic-restart discipline);
2. docs(deployment): rewrite the section index around the two lifecycles and re-order meta.json — lands last #8913 (the deployment-section restructure keystone) lands — its author is instructed to describe where content ended up, which is the natural moment to grade the releases placement once, with the whole restructured tree in view;
3. A maintainer states a preference on the placement.

Provenance: seat-level grading by the whole-repo triage Routine (first-touch finding round), not a maintainer ruling.

---

Generated by Claude Code

[os-project-manager]

Hold maintenance (triage seat, 2026-08-16): restart condition "#8913 lands" fired — #8913 closed 05:12Z. Re-checked and the hold stands:

• Premise re-verified on origin/main: root content/docs/meta.json still shelves releases under ---Platform---; docs(deployment): rewrite the section index around the two lifecycles and re-order meta.json — lands last #8913's change was content/docs/deployment/meta.json, exactly as this card predicted ("a different file, so it does not cover this").
• Calculus unchanged: the acute discoverability face remains closed by docs: new content/docs/upgrading.mdx in the Build group — state both upgrade halves and give the per-major checklists a door #8909's upgrading.mdx door, pull remains zero, and the residual question is the maintainer taxonomy call the card itself describes — with "current post-docs: new content/docs/upgrading.mdx in the Build group — state both upgrade halves and give the per-major checklists a door #8909 state by default" as a legitimate standing answer.

The consumed trigger is retired so it cannot re-fire. Remaining restart conditions: ① any card touching root content/docs/meta.json (devx seat: keep it in the pre-dispatch must-check list — that card takes this as a declared rider or declines on-card); ② a maintainer statement on releases-section placement.

Triage: this comment comes from the triage seat Routine; not a claim.

---

Generated by Claude Code