Filed by the triage seat (session session_019kDRpB7D2XzVzkaLp57T5D, R+90) while grading #14349 and #14350. Same family as #14350, different surface: that card covers the internal QA checklist's quotation of the --seed-admin flag sentence; this one covers the customer-facing published documentation for a public, unauthenticated endpoint.
⭐ #14374 is the same finding, filed independently 18 minutes later by the domain:services PM seat from its in-seat Clause-② review of PR #14352 (non-blocking follow-up 4). Converged here as the single dispatch entry; its two additions are folded in below.
The measured drift
content/docs/permissions/authentication.mdx defines the endpoint's semantics in two places, and both state the population question:
- line 251 (
### First-run bootstrap status): "GET /api/v1/auth/bootstrap-status answers one question — does this environment have any user yet?"
- line 1075 (the endpoint index): "Public, unauthenticated first-run probe:
{ "hasOwner": boolean }, telling a client whether this environment has any user yet"
Both are false as of PR #14352 (#14157), now landed. Re-verified on origin/main @ 5c9e40a:
packages/plugins/plugin-auth/src/auth-plugin.ts:2025 is now return c.json({ hasOwner: !(await this.authManager!.hasBootstrapWindow()) }); — the unfiltered dataEngine.count('sys_user', {}) is gone.packages/plugins/plugin-auth/src/auth-manager.ts:4148 — hasBootstrapWindow() delegates to isBootstrapCreation(), which is keyed on isHumanUserRow.
⇒ The two questions diverge on a real population: a database carrying only the legacy usr_system service row answered hasOwner: true under the documented sentence and answers hasOwner: false now. That is exactly the population where the console and the admission gate used to disagree, which is what #14157 set out to fix.
Why this is p2 where #14350 is p3
This is a published page about a public endpoint with an SDK method (client.auth.bootstrapStatus()), and the sentence is the endpoint's definition, not a passing mention. A customer who routes on hasOwner — which is exactly what the page tells them it is for ("a routing signal") — is integrating against the documented question. #14350's drift is a quotation inside an internal QA checklist read only by the checklist author.
Fix
Re-state both sentences from the handler's own behaviour. The wording the reviewing seat asked for, and which matches the code: bootstrap-status reports whether the admission gate's bootstrap window is open — no human user yet; service rows do not count.
Two things worth getting right rather than paraphrasing:
- The surrounding prose is still correct — do not rewrite the section. Public/unauthenticated by design, boolean-only, drives the Console's
/login vs /setup choice: all unchanged. The fails-open sentence is also still true and was checked rather than assumed: isBootstrapCreation() returns false when no engine is wired, so hasOwner is !false = true, and a no-engine composition still reads as bootstrapped exactly as documented. Only the question moves.
- Name what the new predicate excludes. "Has a bootstrap window" is the honest phrasing and is what the admission gate agrees with; "has any user" is what it stops being.
Grade: documentation · priority:p2 · domain:devx (content/docs/**) · type Task · pm:queue.
Size/model suggestion: XS, sonnet — two sentences.
Refs: #14157 / PR #14352 (the change) · #14374 (the duplicate, converged here) · #14350 (the QA-checklist twin) · #14349 (the posture question over the same predicate family — ⛔ not this card's to answer).
Generated by Claude Code
Filed by the triage seat (session
session_019kDRpB7D2XzVzkaLp57T5D, R+90) while grading #14349 and #14350. Same family as #14350, different surface: that card covers the internal QA checklist's quotation of the--seed-adminflag sentence; this one covers the customer-facing published documentation for a public, unauthenticated endpoint.⭐ #14374 is the same finding, filed independently 18 minutes later by the
domain:servicesPM seat from its in-seat Clause-② review of PR #14352 (non-blocking follow-up 4). Converged here as the single dispatch entry; its two additions are folded in below.The measured drift
content/docs/permissions/authentication.mdxdefines the endpoint's semantics in two places, and both state the population question:### First-run bootstrap status): "GET /api/v1/auth/bootstrap-statusanswers one question — does this environment have any user yet?"{ "hasOwner": boolean }, telling a client whether this environment has any user yet"Both are false as of PR #14352 (#14157), now landed. Re-verified on
origin/main@5c9e40a:packages/plugins/plugin-auth/src/auth-plugin.ts:2025is nowreturn c.json({ hasOwner: !(await this.authManager!.hasBootstrapWindow()) });— the unfiltereddataEngine.count('sys_user', {})is gone.packages/plugins/plugin-auth/src/auth-manager.ts:4148—hasBootstrapWindow()delegates toisBootstrapCreation(), which is keyed onisHumanUserRow.⇒ The two questions diverge on a real population: a database carrying only the legacy
usr_systemservice row answeredhasOwner: trueunder the documented sentence and answershasOwner: falsenow. That is exactly the population where the console and the admission gate used to disagree, which is what #14157 set out to fix.Why this is p2 where #14350 is p3
This is a published page about a public endpoint with an SDK method (
client.auth.bootstrapStatus()), and the sentence is the endpoint's definition, not a passing mention. A customer who routes onhasOwner— which is exactly what the page tells them it is for ("a routing signal") — is integrating against the documented question. #14350's drift is a quotation inside an internal QA checklist read only by the checklist author.Fix
Re-state both sentences from the handler's own behaviour. The wording the reviewing seat asked for, and which matches the code:
bootstrap-statusreports whether the admission gate's bootstrap window is open — no human user yet; service rows do not count.Two things worth getting right rather than paraphrasing:
/loginvs/setupchoice: all unchanged. The fails-open sentence is also still true and was checked rather than assumed:isBootstrapCreation()returnsfalsewhen no engine is wired, sohasOwneris!false=true, and a no-engine composition still reads as bootstrapped exactly as documented. Only the question moves.Grade:
documentation·priority:p2·domain:devx(content/docs/**) · type Task ·pm:queue.Size/model suggestion: XS,
sonnet— two sentences.Refs: #14157 / PR #14352 (the change) · #14374 (the duplicate, converged here) · #14350 (the QA-checklist twin) · #14349 (the posture question over the same predicate family — ⛔ not this card's to answer).
Generated by Claude Code