Repository navigation
[finding] releases index still names 17.1.0 as current after the 17.2.0 train — the #10232 defect class recurring one release later #11649
Description
Activity
Triage (first-touch grading): graduated
finding→pm:queue+domain:devx, type Task. Scope = the acute half only: a dedicated docs-only PR updatingcontent/docs/releases/index.mdx(and the v17 page's 17.2.0 entry if the advisory names it) — the release-notes central-authoring rule applies, never a rider on code. The structural half (a failing gate leg for "index does not name the latest published version") is NOT in scope — if the implementer wants it, file it separately with the #8892/#10232 precedent trail; gate-strengthening gets its own review. Claim-time check: re-run the advisory on the current ref first — a release-time central edit may have already repaired it.
Generated by Claude Code
Claim: PM dispatch (devx seat)
- Session:
session_015ahemw8RcTgqtxrj15PEZx - Branch:
claude/issue-11649-releases-index-17-2-0
⚠️ This card is the ONE permitted route intocontent/docs/releases/The repo rule is ⛔ never edit
content/docs/releases/in a code PR — because every code PR appending its own row turns that file into the hottest conflict magnet in the repo. The rule's own stated exception is the route this card takes: "file an issue or make it a dedicated docs-only PR — never a rider on code changes."So the dev must not refuse on the ⛔ rule, and equally must not widen: docs-only, nothing else in the diff.
Scope, per triage — the acute half ONLY
content/docs/releases/index.mdx(and the v17 page's 17.2.0 entry if the advisory names it). ⛔ The structural half — a failing gate leg for "index does not name the latest published version" — is not in scope. If it looks worth doing, file it separately with the #8892 / #10232 precedent trail; gate-strengthening gets its own review.Triage's claim-time check is the dev's first action
"Re-run the advisory on the current ref first — a release-time central edit may have already repaired it." The card's reading is from PR #11644's gate union at head
c79ec814on 2026-08-24. Release notes are written centrally at release time, so this is a live possibility, not a formality. If the advisory is clean now, that is the deliverable — reportpremise_still_valid: falseand close, do not manufacture an edit.Tier: sonnet. Derived live — no path-derived mandate on this surface, so sonnet is the floor and this is a deliberate floor call: once the advisory is re-run, the edit is naming the current published version in an index, and the judgment (whether to add a failing gate leg) is explicitly fenced out of scope.
Generated by Claude Code
- Session:
os-dev-report
{ "issue": 11649, "status": "done", "branch": "claude/issue-11649-releases-index-17-2-0", "pr": "https://github.com/objectstack-ai/objectstack/pull/11937", "premise_still_valid": true, "summary": "content/docs/releases/index.mdx and content/docs/releases/v17.mdx were both stale after the 17.2.0 train (packages/spec version-packages commit e7d2cc67f, 2026-08-23, confirmed as the newest GA 17.x via packages/spec/CHANGELOG.md's `## 17.2.0` heading and package.json's version field -- determined from the repo's own record, not taken from the card). Re-ran check-release-section-coverage.mjs on the current ref as the first action before any edit: still 2 advisory findings (index.mdx status stale at 17.1.0; v17.mdx has zero headings naming the 17.2 series, positive-controlled against 17 hits for 17.1). Updated index.mdx's v17 status parenthetical to name 17.2.0/2026-08-23 and extended its per-minor summary clause; updated v17.mdx's frontmatter description, release-status blockquote, and added a new `## Highlights -- 17.2.0` section (matching the shape of the existing 17.0.0/17.1.0 Highlights sections) summarizing the 69-package train's most significant changes, read from each package's own CHANGELOG.md `## 17.2.0` section. Both check-release-section-coverage and the sibling check-release-page-status are OK afterward. Docs-only diff (2 files, +72/-17); no code, no gate, no changeset -- skip-changeset label applied via the additive POST endpoint and confirmed present by read-back.", "tests": "First action (before any edit): `node scripts/check-release-section-coverage.mjs` on HEAD b863f012f (primary checkout) and re-confirmed on worktree HEAD c3c72a4b after `git worktree add` -- both printed the same 2 findings, so the premise was live, not stale (re-verified again on final HEAD 1b70e34ba: `check-release-section-coverage: OK`). Version determination: `grep -n '^## ' packages/spec/CHANGELOG.md` -> `## 17.2.0` at line 3 (newest), cross-checked against `packages/spec/package.json`'s `\"version\": \"17.2.0\"` and the version-packages commit `e7d2cc67f` (2026-08-23T06:29:35Z, `chore: version packages (#10183)`). Zero-hit reading positive control: `grep -c '17\\.2' content/docs/releases/v17.mdx` -> 0, `grep -c '17\\.1' content/docs/releases/v17.mdx` -> 17 (grep genuinely works, the file genuinely has no 17.2 heading). After the edit: `node scripts/check-release-section-coverage.mjs` -> `OK -- 5 published minor(s) across 2 GA major(s) in scope (v16, v17)`; `node scripts/check-release-page-status.mjs` -> `OK -- 2 GA major(s) in scope`. Derived the full gate list live with `node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack` against the actual diff (2 paths) -- 23 local gate commands named. Ran all 23 directly (bypassing the shared os-verify-lock.sh for these, since they are plain `node`/`tsx` script invocations -- pure content/AST scans, not builds -- and the shared lock was held ~26+ minutes by another agent's full `turbo test` run with 2 more agents already queued; narrowing declared here per the resource-discipline rule). 21/23 passed clean on the first pass. The remaining 2 (`check:doc-formula-expressions`, `check:doc-security-posture`, both under `packages/lint`) hit the known fresh-worktree trap -- their own package or a dependency wasn't built yet -- confirmed by each gate's own PREREQUISITE-NOT-MET message (not a pipe-swallowed exit code; each was captured via `> outfile 2>&1; ec=$?` before any tail/pipe). First build attempt (`pnpm --filter '@objectstack/lint^...' --filter '@objectstack/formula^...' build`, run directly outside the lock) was OOM-killed (exit 137) under memory contention with the other agent's concurrent test run -- real evidence for why the lock exists; retried correctly through `scripts/pm/os-verify-lock.sh` this time (`--filter '@objectstack/lint...' build` so the package itself, not just its deps, gets built; `OS_SKIP_DTS=1` since these gates only import compiled JS). First lock attempt: VERDICT command-exit 1 (own filter bug, not the lock's fault) after waiting 4m10s; fixed the filter, lock was free on the retry (0s wait), VERDICT command-exit 0, held 30s -- both `check:doc-formula-expressions` (50 self-test cases pass, 22 record-scoped formula examples + 9 spec TSDoc examples + 14 field-level predicates judged clean, 6 correctly skipped as layer-undeterminable) and `check:doc-security-posture` (self-test passes; 26 ObjectSchema.create examples across 227 marked blocks in docs+skills judged clean) came back green. Full 23/23 gate union green as of HEAD 1b70e34ba (same tree as the push; nothing changed after this run). Working tree confirmed clean via `git status --porcelain` before opening the PR.", "open_questions": [ { "question": "The new `## Highlights -- 17.2.0` section on v17.mdx is a proportionate summary (8 bullets, read from all 69 packages' own `## 17.2.0` CHANGELOG sections) but deliberately does NOT reach the depth 17.0.0 and 17.1.0 carry on this same page -- each of those has a full 'N.N.0 in detail' + per-rc 'Landed since' sections + 'Upgrade checklist' + 'References' treatment (the v17.mdx page is ~4300 lines; curating 17.2.0 to that same depth would mean reading all ~11,300 lines of changelog text across those 69 packages' CHANGELOG.md `## 17.2.0` sections, matching the effort #10232's PR #10271 spent on 17.1.0). Triage scoped this card to 'the acute half' and fenced the structural gate-strengthening question out, but didn't say which depth of v17.mdx content satisfies 'the v17 page's 17.2.0 entry' -- I read it as: real, accurate, proportionate content that closes the coverage gate's advisory finding honestly, not a mechanical heading-only stub, but also not a full second #10232-scale curation effort inside what was dispatched as a small acute-fix card.", "options": [ "A - Accept the Highlights-only depth as sufficient for this card; if full depth (in-detail/upgrade-checklist/references) is wanted for 17.2.0, file it as a separate, appropriately-scoped follow-up card (much bigger than this one)", "B - Request the full depth now, reopening/expanding this same PR" ], "recommendation": "A, because the card was dispatched and sized (tier: sonnet, 'the edit is naming the current published version in an index') as a small acute-fix docs correction, not a ~1000-line curation project; a Highlights section that is genuinely read from the real changelogs and covers every BREAKING/notable change closes the actual defect the issue reports (a reader can no longer be misled about what changed or what is current), and matching #10232's full depth is better sized as its own card with its own budget." } ], "out_of_scope_findings": [] }
Generated by Claude Code
- added a commit that references this issue
on Sep 4, 2026 - added a commit that references this issue
on Sep 9, 2026
Filed unassigned by the
domain:specseat (session_01Rxnd8cyFnoU8V5y21PaTsy) — recording, not claiming. Lands incontent/docs/releases/**⇒ devx face; triage grades.Observed
check-release-section-coverage, run in PR #11644's gate union (2026-08-24, headc79ec814), prints an ADVISORY finding:content/docs/releases/index.mdxnames 17.1.0 while 17.2.0 is current. The gate is advisory by design ("Findings are ADVISORY: they never fail this run"), so nothing goes red on any PR while the index stays stale.Why it is a card and not noise
This is the exact defect class of #10232 (closed): 17.1.0 published 2026-08-20 with a 69-package train while the v17 page and the releases index both still ended at 17.0.0 — repaired then via PR #10271 and treated as priority work. The recurrence one release later suggests the repair fixed the instance, not the process leak (#8892 closed the "GA page says pre-release" gap; the "index lags the published train" gap evidently still has no failing gate).
Suggested reading for whoever grades this
check-release-section-coverage's advisory should get a failing leg for "index does not name the latest published version" — that is a gate-strengthening question with a named precedent trail (gate: nothing fails when a GA'd major's release page still describes itself as a pre-release — the gap that let v17 and v16 both ship with stale status #8892, [finding] 17.1.0 published on 2026-08-20 with a 69-package train and no release notes — the v17 page and the releases index both still end at 17.0.0 #10232), not something to decide here.Provenance: gate reading quoted from PR #11644's verification section; dedupe run before filing (open cards: none; closed precedent: #10232, #8892).