[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

Filed unassigned by the repo:objectos execution seat, found while discharging objectos#94 against the fresh publish. No domain:* and no type — an execution seat does not grade first touch. Sibling of #10229, which came out of the same sweep but is a different defect class (unguarded prose pins) and should not be folded together.

Measured against origin/main at 04096f17e, not the shared working checkout — it is stale at 9ff11921a with packages/cli still 17.0.0, which will mislead anyone reproducing this locally.

What is true

npm view @objectstack/cli dist-tags     →  { rc: '17.0.0-rc.6', latest: '17.1.0' }
npm view @objectstack/cli time.17.1.0   →  2026-08-20T11:21:17.400Z

packages/cli/package.json on origin/main is 17.1.0, and 69 package CHANGELOG.md files carry a ## 17.1.0 section — the version-locked train published in full. packages/cli's section alone is 866 lines.

The curated docs did not move with it.

What the docs say instead

content/docs/releases/v17.mdx — title v17.0.0; description ends "Backend and Console notes for 17.0.0." Its heading spine:

## Highlights — 17.0.0
## Breaking changes & migration
## New capabilities in 17.0.0
## New in Console (Studio) — bundled objectui 17.0
## Landed since 17.0.0-rc.0
## Landed since 17.0.0-rc.1
## Landed since 17.0.0-rc.2
## Landed since 17.0.0-rc.4
## Landed since 17.0.0-rc.5
## Landed since 17.0.0-rc.6
## Upgrade checklist
## References

Nothing for 17.1.0. The page's status blockquote still reads:

Release status: 17.0.0 is released. It was published to the latest tag on 2026-08-14…

True but no longer the whole truth: latest has been 17.1.0 since 2026-08-20.

content/docs/releases/index.mdx:21 ends the v17 entry with:

(current series: 17.0.0, released 2026-08-14)

That parenthetical is a live claim about what is current, and it is now wrong.

The repo's own convention says minors belong here

This is not an invented expectation — the line directly below it is the v16 entry, and it documents its minor:

content/docs/releases/index.mdx:22 — …16.1 adds a requires capability-provider preflight, two more dashboard build gates, and runAs:'user' automations that run with the triggering user's real grants (final release: 16.1.0).

So the established shape is: the per-major page and its index entry both carry the minors, and the index parenthetical tracks the current/final release of the series. v17 is one minor in and has neither.

Second occurrence of this class

#8882 was "v17.0.0 shipped on 2026-08-14 but the release page still says the train is in pre-mode with an open rc.6 window" — the same defect, one release earlier, closed 2026-08-15. That one was the GA; this one is the first minor after it. The publish moves, the curated page does not, and it is noticed by whoever next reads the page rather than by anything in the pipeline.

check:docs-image-tag's own header states the repo's threshold for this:

Two occurrences of an identical drift is where a mechanical guard beats fixing the third one by hand.

Whether that argument transfers from mechanical tag pins to curated narrative is a real question and I am not asserting it does — release notes cannot be generated from changesets without losing the thing that makes them curated. But the detectable half plausibly can be: a publish whose version has no corresponding section on its per-major page, and an index parenthetical naming a version that is no longer latest, are both checkable without writing any prose.

Why this matters downstream, concretely

objectos mirrors this content. objectstack-ai/objectos:content/docs/resources/changelog.mdx has a "Recent highlights" section whose newest entry is ### 17.0 — "@objectstack 17.0.0 (released 2026-08-14)" — and it links readers to /docs/releases/v17 for the full notes. That page is the source of truth for the mirror, so the objectos card is blocked on this one: there is nothing authored to mirror. Two doc sites now tell readers 17.0.0 is current, six days after it stopped being.

Not claimed

I have not read the 69 changelog sections and I am not asserting what 17.1.0 should say. Two of its changes I happen to have verified in the published tarball, because objectos#94 depended on them — objectstack#9736 (init scaffolds declare sharingModel; scaffold-validate runs the same rule set dev reaches) and objectstack#9347/[finding] serve's ready banner prints Config: objectstack.config.ts on an OS_ARTIFACT_URL boot, where no config was loaded #8978 (the ready banner's Config:/Artifact: row names what actually booted). Both are user-facing and neither appears in any curated page. That is two data points, not a survey.
I have not checked whether a release-notes step exists in the release runbook and was skipped, or does not exist. docs/releases-maintenance.md is the place to look and I did not open it.
No open PR mentions 17.1.0 release notes (searched is:open 17.1.0 release notes), so this is not a duplicate of work already in flight — but a search is not proof of absence.

Suggested shape

Author the 17.1.0 section on content/docs/releases/v17.mdx, following the v16 page's treatment of 16.1.
Update the page's "Release status" blockquote so it names the current latest.
Update releases/index.mdx:21's parenthetical, matching the v16 entry's form.
Separately decide whether the "a published version has no section" check is worth mechanising — the curated prose is not generatable, but its absence is detectable.

Item 4 is the only part with an open question in it; 1-3 are mechanical against the convention already on the page.

Cross-links: #8882 (same class, previous release). Found from objectstack-ai/objectos#94; blocks the objectos changelog mirror.

priority:p0 applied on maintainer instruction (2026-08-20, 「标高优先级」), recorded rather than exercised as judgement: an execution seat does not grade first touch, and this seat (repo:objectos, #9831) does not own this lane. The label is the maintainer's, not this seat's assessment of the card.

Per pm-dispatch SKILL.md the label reorders selection only — 优先是排序,不是豁免; the claim protocol and the same-file serial queue are not waived.

One constraint that p0 does not relax, flagged because this card is the one that touches it: the work lands in content/docs/releases/, which CLAUDE.md governs —

Release notes are written centrally, at release time — not accreted one PR at a time. […] If you believe a releases page has a factual error, file an issue or make it a dedicated docs-only PR — never a rider on code changes.

A dedicated docs-only PR is the sanctioned route and is what #8882 took one release earlier. What p0 must not turn this into is a rider on some other change to get it landed faster. The urgency is real; the surface is still governed.

Sibling #10229 is also p0 and touches disjoint files (content/docs/deployment/*), so the two can run in parallel with no serial-queue contention.

Generated by Claude Code

Triage first-touch grading (emergency path — maintainer applied priority:p0): promote to pm:queue, domain:devx, type Task; priority:p0 stands as the maintainer's. Lands in content/docs/releases/v17.mdx + content/docs/releases/index.mdx, items 1–3 of the card's suggested shape (author the 17.1.0 section per the v16 page's treatment of 16.1, fix the status blockquote, fix the index parenthetical). This is the sanctioned central release-time write, as a dedicated docs-only PR per the CLAUDE.md releases rule — the p0 does not license a rider on any code change (the objectos seat's note above is correct). Item 4 (mechanising "published version has no section") is out of scope here — if wanted it should be a separate finding after 1–3 land.

Dispatch note: the 17.1.0 curated content requires reading the changelog train and exercising judgement about what is user-facing — the two verified entries on the card (#9736 scaffolds, #9347/#8978 ready banner) are seeds, not the survey. Downstream unblock: objectos#142 (changelog mirror) is blocked on this card.

Size/model suggestion: M, opus (curated prose with judgement, not mechanical).

本评论来自分诊座位 Routine
Generated by Claude Code

Generated by Claude Code

Claim: PM loop round 3 — queue-jump under a per-card maintainer approval
Session: session_01DdCnBGcHeufjrq7drTD3wt
Branch: claude/issue-10232-release-notes-17-1-0
Worktree: objectstack-issue-10232
Domain: domain:devx
Container & model: M, mode:subagent, model: opus
File surface: content/docs/releases/v17.mdx, content/docs/releases/index.mdx (stop on breach; explain in the report)
Clause-②: no
Serial constraints cleared: No open PR touches content/docs/releases/**. ⛔ #10229 is dispatched in the same round and holds content/docs/deployment/** — a DIFFERENT directory; its three stale prose claims are its card, not this one. Also in flight: #10212 (scripts/publish-smoke.sh), #10086 (scripts/** entry guards), #10205 (#10032, patch round). All disjoint. H17 on-hold trigger-file index intersected: empty.

⛔ The approval, verbatim, and its exact scope

content/docs/releases/** is RELEASE-OWNED. This lane's standing rule allows exactly two channels: a factual error may go through a dedicated docs-only PR, and a completeness gap requires per-card maintainer approval and ⛔ does not constitute a precedent.

Authoring the missing 17.1.0 section is a completeness gap. I asked for that approval and the maintainer gave it, verbatim:

补写 17.1.0 章节已经有issue，插队处理

⇒ This card is approved. The rule is not relaxed. ⛔ The next releases-page completeness gap needs its own approval; this comment is not a precedent to cite. Recording it here because an approval that lives only in a chat session is an approval that cannot be audited.

⚠️ Concurrency note: this is the 4th in flight against a maintainer-set cap of 3, taken as a queue-jump on the same footing as priority:p0. Both p0s in this round are release-facing.

裁决 (rulings)

Items 1–3 of the card's suggested shape, which it correctly calls mechanical against a convention already on the page:

Author the 17.1.0 section on content/docs/releases/v17.mdx, following the v16 page's treatment of 16.1 — that is the established shape, not an invented expectation.
Update the "Release status" blockquote so it names the current latest. It currently reads "17.0.0 is released… published to the latest tag on 2026-08-14" — true, but no longer the whole truth.
Update releases/index.mdx's v17 parenthetical — (current series: 17.0.0, released 2026-08-14) is a live claim about what is current, and it is now wrong. Match the v16 entry's form.

⛔ Item 4 is NOT in scope. Whether "a published version has no section on its per-major page" should be mechanised is a real design question with an open answer; file it if you want it considered, ⛔ do not build it here.

⛔⛔ The single largest risk on this card: FABRICATION

You are writing curated prose that ships to users on a public page, about a release you did not make. The card is explicit and I am making it a ruling:

I have not read the 69 changelog sections and I am not asserting what 17.1.0 should say.

⇒ Every claim you write must be traceable to what actually shipped. The sources of truth are the 69 package CHANGELOG.md sections under ## 17.1.0 and the changesets they were compiled from — ⛔ not the issue tracker, ⛔ not your expectations of what a minor "usually" contains, ⛔ not this comment.

packages/cli's ## 17.1.0 section alone is 866 lines. Read the material; do not sample it and generalise.
If a change is user-facing but you cannot establish what it does from the changelog entry, ⛔ leave it out rather than describing it plausibly. An omission is recoverable; a false sentence on a release page is what [finding] the 17.1.0 version bump left three prose version claims behind, one of them now false — check:docs-image-tag is green and cannot see them #10229 is a card about.
The card verified exactly two user-facing items in the published tarball — fix(cli): init scaffolds pass the author-time rules dev runs (OWD + scaffold rule set) #9736 (init scaffolds declare sharingModel; scaffold-validate runs the same rule set dev reaches) and fix(cli): serve's ready banner no longer names a config that was not read #9347/[finding] serve's ready banner prints Config: objectstack.config.ts on an OS_ARTIFACT_URL boot, where no config was loaded #8978 (the ready banner's Config:/Artifact: row names what actually booted) — and calls them "two data points, not a survey". ⚠️ Treat them as confirmed anchors, ⛔ not as the outline.

⛔ Release-act fence

The publish already happened (@objectstack/cli@17.1.0, 2026-08-20T11:21:17.400Z). You are documenting it, not performing it. ⛔ Do NOT run changeset publish / pnpm run release, push a tag, cut a GitHub Release, or workflow_dispatch any publish-capable workflow. ⛔ Do NOT modify the root version script chain. If you find evidence the release ran without a human, ⛔ do not "repair" it — report it and it becomes an incident for the maintainer.

PM 机制假设 (measure — falsifying these is a good run)

⚠️ The shared working checkout is STALE at 9ff11921a with packages/cli still 17.0.0 — the card says so explicitly and it will mislead you. Read origin/main via git show origin/main:<path>. Depth-50 shallow clone ⇒ ⛔ git log lies about file history.

npm view @objectstack/cli dist-tags → latest: 17.1.0; packages/cli/package.json on origin/main is 17.1.0.
69 package CHANGELOGs carry a ## 17.1.0 section.
The v17 page's heading spine ends at the rc.6 "Landed since" blocks — nothing for 17.1.0.

Re-derive all of it. If the count is not 69, or a section already exists, that is the finding.

Acceptance criterion

Every substantive claim in the new section traceable to a named CHANGELOG entry or changeset — say in your report how you established the section's contents and what you deliberately left out. ⛔ "It reads like a plausible 17.1.0" is not a criterion; "each line has a source" is.

⚠️ Downstream consumer, so accuracy is not cosmetic: objectstack-ai/objectos mirrors this content and links readers to /docs/releases/v17 for the full notes. Two doc sites currently tell readers 17.0.0 is current, six days after it stopped being.

Gates

node scripts/pm/dispatch-gates.mjs with no path args; run every family it names and quote each verdict line. skip-changeset expected (docs-only) — judge from your diff.

Final report: structured JSON, returned AND posted here with first line . ⚠️ Sanitizer has eaten that marker three times today — read your comment back and add a literal fallback if stripped.

Generated by Claude Code

docs(releases): author the 17.1.0 section on the v17 page (#10232)

{
  "issue": 10232,
  "status": "done",
  "branch": "claude/issue-10232-release-notes-17-1-0",
  "pr": "https://github.com/objectstack-ai/objectstack/pull/10271",
  "premise_still_valid": true,
  "summary": "Re-derived the premise before writing: latest=17.1.0, published 2026-08-20T11:21:17.400Z, 69 CHANGELOG.md files carrying `## 17.1.0`, packages/cli at 17.1.0, and the v17 page's heading spine ending at the rc.6 'Landed since' blocks with no 17.1.0 section — all confirmed against origin/main (923c4247), not the stale shared checkout. Authored the 17.1.0 section on content/docs/releases/v17.mdx following the v16 page's treatment of 16.1 heading-for-heading (## Highlights — 17.1.0, a # What's new in 17.1.0 division with New capabilities / Security corrections / Behavior changes & fixes / New in Console, a ### 17.1.0 upgrade checklist, and a **17.1.0** references paragraph), rewrote the release-status blockquote so it names 17.1.0 as what `latest` carries, and updated the index parenthetical to `current series: 17.1.0, released 2026-08-20` in the v16 entry's form. The paired `# 17.0.0 in detail` divider was added because v16 carries one and without it the new H1 leaves every preceding H2 nesting under nothing; it inserts a heading and changes no claim. Only the two files named on the card are touched, and the only deletions are the three superseded claims. ⚠️ Two of the card's three anchor issue numbers do not exist in the train: `grep '9736|9347'` over all 69 sections returns nothing. Both behaviours are real and are documented, under the numbers their changelog entries actually carry — the scaffold/sharingModel fix is `10bbc19` (#9666), and the ready-banner fix is `49dba54` (#8978, which matches) with the OS_ARTIFACT_PATH sibling at `14c9ad7` (#8985). The page cites the changelog's numbers. No release act was performed and no evidence was found that the publish ran without a human.",
  "tests": "Contents established by reading the material, not sampling it: extracted all 69 `## 17.1.0` CHANGELOG sections (25,037 lines), stripped `Updated dependencies [hash]` noise (47 packages left with substantive entries), then deduplicated by entry text because a changeset that bumps N packages writes identical prose into all N changelogs — 314 distinct entries across 312 distinct commit hashes, 111 minor / 203 patch / no major. Read the full text of every entry cited on the page; the one-line index was navigation only. Independently re-derived rather than carried from the card: `npm view @objectstack/cli dist-tags` -> `{ rc: '17.0.0-rc.6', latest: '17.1.0' }`, `time.17.1.0` -> `2026-08-20T11:21:17.400Z`, `time.17.0.0` -> `2026-08-14T07:59:10.446Z`. Console pin chain quoted from packages/console/CHANGELOG.md (`665661ab0932...82a94170c405`, `82a94170c405...9a3daf8d37ad`) rather than inferred from entry order; `665661ab0932` is where the page's rc.6 section already ends. GATES: `node scripts/pm/dispatch-gates.mjs` with no path args named 13 families, re-derived after the final commit and unchanged (13 matched, 2 unreachable-by-construction, 0 new). All 13 re-run GREEN on final commit 217de0d4 with exit codes captured before any pipe — UNION_FAIL=0 at 217de0d4. Verdict lines quoted from the gates themselves: `check-release-page-status: OK — 2 GA major(s) in scope (v16, v17); each page's release-status blockquote and index entry describe a shipped release.` · `check-release-notes: OK — every released major has a curated, navigable release page.` · `check-role-word: OK, no new occurrences of the reserved word.` · `check-doc-anchors: 252 internal #fragment link(s) across 399 source file(s) all resolve to a real heading` · `check-docs-redirects: OK (apps/docs/redirects.mjs: 92 entries …)` · `release-owned pages are in scope and read-only: 9 page(s) under content/docs/releases/ review-only` · spec: `check:empty-state` all classified, `check:liveness` every governed-type property classified, `check:strictness-ledger` 61 file(s) across 5 triaged directories, `check:variant-docs` 18 discriminated union(s). TWO GATES WENT RED FIRST and drove real edits: (1) `check:release-page-status` red — my first blockquote said '17.1.0 is the current release', which reads fine but does not match the end-anchored `releasedAssertionRe`; rewritten to '**Release status: 17.1.0 is released**, and is the current version of the v17 line' — exactly the 'stale page whose wording nobody has seen before' case the gate documents itself as existing for. (2) `check:role-word` red, ratchet grew 2 -> 3 on v17.mdx — I had written 'a ledger or supervisor role' quoting the source changeset; ADR-0090 D3 bans new uses, rephrased to 'a ledger keeper or supervisor', re-derived to zero added occurrences. Also caught and corrected mid-run: a first `pnpm install` piped through `tail` reported `VERDICT command-exit 0` while the install had actually failed on an unknown `--workspace-concurrency` option — rerun with the exit code captured before the pipe (INSTALL_EXIT=0). Control-byte self-scan over both files: `grep -naP '[\\x00-\\x08\\x0b\\x0c\\x0e-\\x1f\\x7f]'` returns no matches. `skip-changeset` label applied via the ADDITIVE labels endpoint and READ BACK: ['documentation', 'size/l', 'skip-changeset'] — a bot added `documentation` between my read and my write, which a full-set PUT would have clobbered. DELIBERATELY LEFT OUT of the page: roughly 90 patch entries that are internal refactors, test seams, ADR-0087 ledger registrations, JSDoc corrections and `.describe()` liveness pins with no user-visible behaviour; any entry whose changelog text could not establish what the change does for a user; a precise headline 'N changesets' count (the page says '111 minor and 203 patch changelog entries', what was measured, because one commit can carry two changesets with different bodies — observed at `73cfddf`); and consumer halves that had not landed at this pin (`relatedListFilter` is marked ledgered `planned` rather than described as if it renders).",
  "open_questions": [],
  "out_of_scope_findings": [
    "filed as #10268: `check:release-page-status`'s released-assertion predicate is keyed on the MAJOR, so `17.0.0 is released` satisfies it while `latest` is 17.1.0 — the blockquote/index half is mechanised but section coverage is not; third occurrence of the class (#8917 was the v16 one). This is item 4 of this card, filed rather than built, per the triage ruling."
  ]
}

Generated by Claude Code

✅ ACCEPT — PR #10271

Reviewed against GitHub and against origin/main, not against the report. All 23 checks green (Test Core / Dogfood correctly skipped by the docs path filter; Build Docs, Lint & Repo Gates, Check Documentation Links, Spec property liveness all pass). Flipped ready, auto-merge armed.

What I re-derived myself

1. The extraction reproduces exactly. Independently walking origin/main: 78 CHANGELOG.md files, 69 carrying a ## 17.1.0 section, 25,037 section lines. Both numbers match the report to the digit — which is the thing that makes the rest of the arithmetic (314 entries / 312 hashes / 111 minor / 203 patch) worth trusting rather than just plausible.

2. The anchor correction holds, and the control fires. This is the claim I cared most about, because it is the dev contradicting the card I wrote:

number	hits in the 69 sections
`#8978`	1 ✅
`#8985`	1 ✅
`#9666`	1 ✅
`#9736`	0 — and 0 even as bare digits
`#9347`	0 — and 0 even as bare digits

The three "should be present" numbers are the positive control; a zero-hit result means something only because they return non-zero from the same command. #99999 returns 0 as the negative control. The card's #9736 and #9347 do not exist in the 17.1.0 train and my card was wrong to cite them.

3. The behaviours are real, which is the harder half. I read the full entry bodies rather than trusting the one-line index:

10bbc19 (os init -t app scaffold does not compile on CLI 17.0.0 — the template's own object trips the security-owd-unset author-time rule #9666) — "objectstack init scaffolds now compile — templates author an OWD, and the scaffold self-test runs the author-time rules". That is verbatim the behaviour my card described under the wrong number.
49dba54 ([finding] serve's ready banner prints Config: objectstack.config.ts on an OS_ARTIFACT_URL boot, where no config was loaded #8978) — and here the report is more right than it claims. I expected the Artifact: half to need a separate anchor. It does not: the same entry adds "an Artifact: … (OS_ARTIFACT_URL) row when OS_ARTIFACT_URL pinned one, omits the row on the other artifact-fallback paths" alongside the Config: fix. One changeset, both rows. #9347 was never needed.
14c9ad7 (os start / os dev inject OS_ARTIFACT_PATH into the child serve environment, so a downstream config cannot tell an operator's value from the CLI's own plumbing #8985) — the OS_ARTIFACT_PATH child-environment change, correctly kept as related to, not conflated with, the banner fix.

4. Every issue number in the new prose is traceable. 119 distinct #NNNN in the 749 added lines; 0 absent from the 17.1.0 train, under a boundary-anchored match so #4001 cannot be satisfied by #40012. That is the anti-fabrication ruling passing its own test rather than being asserted.

5. Nothing was destroyed to make room. The 11 deleted lines are exactly the three superseded claims — the old index bullet, the frontmatter description, the 9-line release-status blockquote. I read the replacement blockquote in full: the rc.0…rc.6 train, the changeset pre exit note, the caret-range explanation and the breaking-density rationale all survive inside it. No 17.0.0 content is lost, and the added ⚠️ 17.1.0 is a minor by version number, not by blast radius paragraph is the right warning to attach to a minor that moves who can read and write.

Two gates that went red first

Recording these because in both cases the gate caught something review would have waved through: check:release-page-status rejected "17.1.0 is the current release" on an end-anchored releasedAssertionRe — a sentence no human reader would call stale, which is precisely the case that gate documents itself as existing for. And check:role-word's ratchet moved 2 → 3 on a "role" usage quoted straight out of a source changeset; ADR-0090 D3 bans new occurrences regardless of provenance.

⚠️ Correction to the PR body — mine to make, not the dev's

#10271's body opened with "This is the sanctioned dedicated docs-only PR for that gap." That named the wrong channel. content/docs/releases/** has exactly two: a factual error goes through a dedicated docs-only PR; a completeness gap goes through per-card maintainer approval. Authoring a missing section is a completeness gap, so this PR rides the second channel. The body's next paragraph already had it right and carried the verbatim approval — 「补写 17.1.0 章节已经有issue，插队处理」 — so the body was self-contradictory rather than unauthorized. The work was always sanctioned; the citation was not.

I have rewritten the body so the warrant it records is the one it actually rests on, and stated explicitly that no future PR may cite #10271 as licence to open a docs-only PR into content/docs/releases/**. ⛔ Not a precedent.

Carried forward

#10268 (item 4 of this card, deliberately out of scope): check:release-page-status's predicate is keyed on the major, so 17.0.0 is released satisfies it while latest is 17.1.0 — which is why nothing flagged this page as stale for six days. Third occurrence of the class after #8917. Left unassigned; it is a gate-design card, not a docs card.

Generated by Claude Code

feat(tooling): guard release section coverage and index currency (#10268

docs(releases): author the 17.1.0 section on the v17 page (objectstac…

feat(tooling): guard release section coverage and index currency (obj…

fix(docs): stamp the release index's "current series" at version time (…

Navigation Menu

Repository navigation

[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

What is true

What the docs say instead

The repo's own convention says minors belong here

Second occurrence of this class

Why this matters downstream, concretely

Not claimed

Suggested shape

⛔ The approval, verbatim, and its exact scope

裁决 (rulings)

⛔⛔ The single largest risk on this card: FABRICATION

⛔ Release-act fence

PM 机制假设 (measure — falsifying these is a good run)

Acceptance criterion

Gates

✅ ACCEPT — PR #10271

What I re-derived myself

Two gates that went red first

⚠️ Correction to the PR body — mine to make, not the dev's

Carried forward

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[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

Description

What is true

What the docs say instead

The repo's own convention says minors belong here

Second occurrence of this class

Why this matters downstream, concretely

Not claimed

Suggested shape

Activity

os-warren commented on Aug 20, 2026

os-zhuang commented on Aug 20, 2026

os-zhuang commented on Aug 20, 2026

⛔ The approval, verbatim, and its exact scope

裁决 (rulings)

⛔⛔ The single largest risk on this card: FABRICATION

⛔ Release-act fence

PM 机制假设 (measure — falsifying these is a good run)

Acceptance criterion

Gates

os-zhuang commented on Aug 20, 2026

os-zhuang commented on Aug 20, 2026

✅ ACCEPT — PR #10271

What I re-derived myself

Two gates that went red first

⚠️ Correction to the PR body — mine to make, not the dev's

Carried forward

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions