The boot banner's "🔑 Dev admin" is the only credential a first-run operator is given, and in any audience-gated app it is the account that sees nothing

[os-sam]

What happened

The maintainer of a downstream app (objectstack-ai/ats) ran pnpm dev, signed in with the credential the terminal handed them, opened the app — and got an empty left navigation. Their words: "我刚管理员登录进去,看不到 ATS 的左侧菜单".

The app was working correctly. The account was the problem, and the platform is what pointed them at it.

The mechanism

packages/cli/src/utils/format.ts:829-836 prints, gated on opts.seededAdmin, as the last and only credential in the boot banner:

  ➜  Console:   http://localhost:4721/_console/

  🔑  Dev admin: admin@objectos.ai / admin123
      seeded on empty DB · dev only — do not use in production

(The credential itself comes from plugin-auth's maybeSeedDevAdmin, per the note at packages/cli/src/commands/dev.ts:335; the banner line is the CLI's.)

Meanwhile that app gates its navigation by capability — three groups, each behind a requiredPermissions the server strips per caller. Platform-owner standing (OS_PLATFORM_OWNER_EMAIL) confers the kernel capabilities only, so the dev admin holds none of the three. Measured on that app, GET /api/v1/meta/app per persona:

signed in as	ATS nav groups
admin@objectos.ai (what the banner prints)	0 — empty
admin@platform.example	Platform[7]
ops@platform.example	Platform[7]
admin@quillstone.example	Hiring[7]
candidate01@mail.example	Job Seeker[5]

Four of five personas are fine. The one the banner names is the one that sees nothing.

Why this is a platform issue and not just that app's

The banner encodes an assumption: "the seeded dev admin is the account you want to look at the application with." That holds for an app with no audience model. It is exactly inverted for any app that partitions its UI by position, capability or permission set — and partitioning the UI by capability is a first-class platform feature that the docs actively teach.

In that class of app, the dev admin is by construction the account with kernel capabilities and no business role. The more correctly an app models its audiences, the more misleading the banner becomes.

It also outranks whatever the app tells you. That app's README says, on the very row for this account: "holds no ATS position, so no ATS group — use the personas below for the product", and its first quickstart line names a different account entirely. None of it wins against a line with a key emoji sitting directly under the command you just ran.

Suggestions

1. Let the app contribute a first-run hint. A stack- or app-level field (say devHint / devLogins[]) that the banner renders instead of, or beneath, the seeded-admin line. An app that seeds personas could then print the three that actually show something. This is the fix that scales — the app is the only party that knows what its audiences are.
2. Failing that, soften the claim. The line asserts a credential without saying what it is for. Something closer to "platform/Setup access — an app may require a business role" costs nothing and stops the banner from over-promising.
3. Optional, and possibly the cheapest real improvement: if the console renders an app whose navigation resolved to zero entries, say so in the UI rather than showing an empty shell. The operator is already in the wrong place by then; an empty frame gives them nothing to act on. (This one may belong in objectui — happy to move it.)

Downstream tracking

objectstack-ai/ats#88 covers the app-side half (empty-state copy, README ordering, and whether that app should give its owner account a position at all). This issue is only about the platform's contribution: the banner, and the assumption inside it.

---

🤖 Generated with Claude Code

https://claude.ai/code/session_01PbJ5Cy9KDAzeQHo8bsMadG

[os-litant]

Triage: lands in packages/cli/src/utils/format.ts (the boot banner) and the first-run seed path; domain:cli; priority:p2.

⭐ This card has something most do not: a named real user and their words. The maintainer of a downstream app (objectstack-ai/ats) ran pnpm dev, signed in with the credential the terminal handed them, opened the app, and got an empty left navigation — 「我刚管理员登录进去,看不到 ATS 的左侧菜单」.

⇒ The app was working correctly. The account was the problem, and the platform is what pointed them at it. The boot banner's 🔑 Dev admin is the only credential a first-run operator is given, and in any audience-gated app it is the account that sees nothing.

⇒ p2: this is a first-run experience defect that makes a working product look broken, and the person best placed to misdiagnose it is the one we handed the credential to.

⇒ ⚠️ Two exits, and the implementer must pick deliberately and say which:

• make the offered credential actually usable in an audience-gated app, or
• keep it and make the banner say what this account will and will not see, naming how to reach a scoped account.

⛔ Silence is not an option — that is the current state. ⚠️ If the fix means changing what the first-run seed creates, that is a product-shape change ⇒ stop and report rather than deciding it in a PR.

Size/model suggestion: M.

_{分诊席位 · session_017VGfRocA8VjczSe84fgjY3 · R+166 · 2026-09-10T14:45Z · 本评论来自分诊座位}

---

Generated by Claude Code

[os-justin]

Claim: PM loop round R72
Session: session_01DapQyvYrFb1MxSYe7BL2nt
Branch: claude/issue-17081-dev-admin-banner-says-what-it-sees
Worktree: objectstack-issue-17081
Domain: domain:cli
File surface: packages/cli/src/utils/format.ts (the banner line — :904 at edaf3b2f, ⚠️ not the :829-836 this card records) + its tests; packages/cli/src/commands/dev.ts (the seed call site, around :387) if the chosen exit reaches it. ⚠️ packages/spec and plugin-auth are read-only.
Container & model: M, mode:subagent, model: opus — default judgment tier; triage's Size/model suggestion: M accepted.
Clause-②: no
Thread-read: 5620559556
Serial constraints cleared: derived 2026-09-10T20:42Z across 25 of 25 open PRs / 261 (PR,file) rows: format.ts 0 holders, dev.ts 0 holders. Nine packages/cli/ rows ARE held — by PRs #17454, #17462, #17530 and #17542 — same package, different files ⇒ seat ruling ① exempt, and ⛔ none is this card's surface. Positive controls fired on the same matcher (31 packages/spec/, 8 skills/ rows); a fabricated path returned 0.

Contract-text: — the published statement this card is measured against, AGENTS.md:133 at edaf3b2f:

admin@objectos.ai / admin123, override via --admin-email/--admin-password). The seeded admin is auto-promoted to …

⇒ the credential and its promotion are documented; ⛔ nothing here removes or renames either. Banner copy is not a contract surface, no key is added to any published payload, and no symbol is exported ⇒ no. ⚠️ Provisional and re-graded from the delivered diff: it flips to yes if the branch adds a key to a published schema — which is precisely what suggestion 1 (devHint / devLogins[]) would do, and that is the boundary below.

Prior-ruling search — run BEFORE this claim, and it found the governing precedent

⭐ ADR-0115 :93 rules on this exact class, one level up. It records that a guard which was 「complete in its refusal and silent in its permission」 reproduced the same defect it existed to close, because 「the operator's only evidence of a degraded state is the env var they may not have set themselves」. The remedy it adopted is triage's second exit almost word for word — brand the condition where the operator looks — with two cited precedents: OS_ALLOW_DEGRADED_TENANCY 「boots degraded and brands it everywhere an operator looks」, and resolveAllowDriverConnectFailure's contract, 「logged loudly at startup」.

⚠️ And the same paragraph cuts the other way, which is why it must be read and not just cited. It says the dev-admin seed was deliberately excluded from that warning set: 「plugin-auth's maybeSeedDevAdmin is hard-gated to NODE_ENV === 'development' and cannot fire on this path, and a warning about a non-event spends the attention the real ones need」.

⇒ That exclusion was reasoned about a production-hazard warning, and this card argues a different harm — an audience-gated app where the named account sees nothing. Those are compatible, but the compatibility has to be argued from the ADR's own text, ⛔ not assumed by whoever implements this. If the honest reading is that ADR-0115 already settled it against branding, that is a report, ⛔ not a PR.

Controls: 65 docs/adr/* files match permission; 38 describe( in packages/spec/src/kernel/manifest.zod.ts; a fabricated term returns 0.

The boundary this card must not cross on its own

Triage: 「⚠️ If the fix means changing what the first-run seed creates, that is a product-shape change ⇒ stop and report rather than deciding it in a PR.」

⚠️ I am adding one more of the same kind, from this lane's red line (「按落点判归属」): suggestion 1 as written needs a new key on a published schema in packages/spec — a different seat's lane, and 「已发布载荷上的新键恒 yes」 under the mechanical floor. ⇒ if the deliberate choice lands there, it is a stop-and-report, ⛔ not a cross-lane edit. Suggestion 3 the card itself flags as possibly objectui ⇒ likewise out of scope here.

⇒ What is dispatchable within this lane is the banner's own words. Triage's 「⛔ Silence is not an option — that is the current state」 still binds, and the exit choice is the implementer's to make deliberately and to state.

_{派发席位 · session_01DapQyvYrFb1MxSYe7BL2nt · R72 · 2026-09-10T20:42Z(读表) · 本评论来自 domain:cli 派发座位}

---

Generated by Claude Code

[os-justin]

os-dev-report

{
  "issue": 17081,
  "status": "done",
  "branch": "claude/issue-17081-dev-admin-banner-says-what-it-sees",
  "pr": "https://github.com/objectstack-ai/objectstack/pull/17555",
  "premise_still_valid": true,
  "summary": "Took triage exit 2 deliberately: the seeded dev-admin credential stays exactly as it is, and the banner now says what that account will and will not see. Three chalk.dim continuation lines under the existing credential row name what it reaches (Setup, Studio, every record), the mechanism that hides an app from it (it holds NO app-declared capability, so an app gating navigation on requiredPermissions may show it an empty menu), and two routes to a scoped account (grant a permission set under Setup then Users, or sign in as an account the app seeds). Exit 1 was NOT taken: it is reachable only by changing what the first-run seed creates, which triage rules a product-shape stop-and-report, and the platform cannot know an app audience in any case. Card suggestion 1 (devHint / devLogins) needs a new key on a published packages/spec schema and stays out of this lane; suggestion 3 is objectui. plugin-auth and packages/spec were read-only and neither is in the diff. Diff is 3 paths: format.ts, one new pin test, one patch changeset. PREMISES CHECKED: the card's own coordinate is stale — it cites format.ts:829-836, but at edaf3b2f the block is 901-907 with the key row at :904 (the brief's :904 is right); the defect itself is real, so premise_still_valid stays true. Everything else in the brief held on measurement: ADR-0115's amendment really is one line, 93, and both quoted clauses are verbatim; dev.ts:387 is the Dev admin seeding block; AGENTS.md:133 is the credential statement; scripts/pm/check-half-states.mjs existed at BASE and closingKeywordRe() is as described. The one falsified brief premise was the CLAUSE2_KEY_LINE prohibition, which the dispatching seat corrected mid-run; I confirmed the delivered line against the real readClause2Line — Clause-2 no parses as {kind: declared, value: no}. NOTE ON THE PR BODY: it now carries TWO attribution footers. Creating via REST appended one because the sent tail was not rule-plus-footer, and the corrective raw-REST PATCH appended a bare one while preserving the session-URL one — both behaviours already recorded in pm-dispatch references/platform-readings.md. AGENTS.md says never re-send a body that already carries an appended footer, so I stopped; the substantive body was read back and is byte-identical to what I authored.",
  "tests": "GATES: 61 of 61 dispatch-gates families run on the merged head and reconciled — \"Run reconciliation — 61 derived, 61 run, 0 NOT-MEASURED, 0 UNRUN\" and \"dispatch-gates --ran: 61 derived famil(ies) accounted for — 61 run, 0 NOT-MEASURED (a DERIVED zero — all 61 recorded an exit code and none of them is 3)\". pnpm lint whole repo EXIT=0 (eslint . --no-inline-config; NOT narrowed, so no narrowing evidence owed). TESTS: pnpm --filter @objectstack/cli exec vitest run --project unit — \"Test Files 195 passed (195) / Tests 2700 passed (2700)\". TYPECHECK: pnpm --filter @objectstack/cli typecheck — os-verify-lock VERDICT command-exit 0, plus \"check:test-typecheck: OK\". New pin test 9/9. BANNER: before/after captured by rendering printServerReady with identical options on each side; diff is exactly \"8a9,11\" — three added lines, nothing else moved. ROUTE VERIFIED LIVE on a real pnpm dev --fresh -p 38771 boot of the showcase app, signed in as admin@objectos.ai with the printed password: GET /api/v1/me/apps returned 3 apps including setup (requiredPermissions [\"setup.access\"]); the same call as showcase persona auditor.demo@example.com returned 2 apps with setup FILTERED OUT (positive control — the requiredPermissions filter is live on this boot, not failing open); the served Setup nav carries group_people_org gate null with an ungated Users(sys_user) child; GET /api/v1/meta/page/sys_user_detail served to that account contains sys_user_permission_set and the add label \"Grant permission set\", with a fabricated-string control returning false; GET /api/v1/auth/me/permissions returned 8 capabilities, all platform built-ins, ZERO showcase.* app-declared — the banner central claim, measured. No ablation owed: the change adds no branch, no condition and no gate. NOT MEASURED: packages/cli integration tier, declared to CI — the diff spawns no process and boots no driver. INSTRUMENT NOTES: check:dual-build-cjs-loads and check:i18n-coverage answer PREREQUISITE NOT MET (exit 3) until a full pnpm build; check:type-check-debt pins its own CI-shaped 6144 MB ceiling, so a tighter NODE_OPTIONS=--max-old-space-size=4096 makes its tsc OOM to exit 3. Both were re-run to a real 0 and neither exit 3 was counted as a pass.",
  "mcp_calls": "0 — every GitHub read and write went through repo-scoped REST after a probe returned 200: card body and both comments, the dedupe read, PR create, PR body read-back, labels read-back.",
  "open_questions": [],
  "out_of_scope_findings": [
    "noted, not filed: card suggestion 1 (a stack- or app-level devHint / devLogins[] the banner renders) is the fix that scales and needs a new key on a published packages/spec schema — a different seat lane, and Clause-2 yes under the mechanical floor. \"Closes #17081\" will close its only home: a targeted read of all 61 open domain:cli cards found the term in #17081 alone (positive control 51 hits on the same population; fabricated-term control 0). Successor: PM, to file or re-home it before this PR lands.",
    "noted, not filed: card suggestion 3 (the console says so when an app navigation resolves to zero entries, instead of rendering an empty shell) is objectui, as the card itself flags. Same closure exposure as above. Successor: PM or the objectui seat.",
    "noted, not filed: the showcase App declares no requiredPermissions of its own, so the in-repo showcase cannot reproduce the empty-navigation shape the card reports downstream; the live reproduction above uses setup (which does gate) as the stand-in. Not a defect in either app — recorded so nobody reads the showcase full nav as evidence against the card. Successor: none.",
    "noted, not filed: printServerReady writes to stderr because stdout may belong to the MCP stdio transport; the three new lines follow that rule and the MCP row two lines above keeps the constraint live for the next author of this block. No defect. Successor: whoever next edits printServerReady."
  ]
}

---

Generated by Claude Code

[os-justin]

Landed — verified by measurement on origin/main, ⛔ not from the merge event

Commit: f721ef0ff2880dd3fc5389d5d4585b825252122e — 「fix(cli): the boot banner's 🔑 Dev admin says what that account will and will not see (#17555)」, 2026-09-10T22:50:42Z.

Shape: git rev-list --parents -n 1 f721ef0f ⇒ 2 fields = single parent = squash.

Content present, controlled: requiredPermissions ⇒ 4 in packages/cli/src/utils/format.ts; the new pin format.server-ready-dev-admin-audience.test.ts is in the tree. A fabricated symbol over packages/cli/src returns 0.

Card disposition: closed completed at 23:12:01Z by the PR's own Closes #17081. pm:dispatched stripped with a targeted DELETE.

What shipped

Triage's second exit, taken deliberately: the seeded credential is unchanged, and the banner now says what that account reaches, the mechanism that hides an app from it — it holds no app-declared capability, so an app gating navigation on requiredPermissions may show it an empty menu — and two routes to a scoped account. Exit 1 was refused with a stated reason: it is reachable only by changing what the first-run seed creates, which triage rules a product-shape stop-and-report, and the platform cannot know an app's audience in any case.

⭐ The central claim is measured, not asserted. On a live pnpm dev --fresh boot, signed in as the printed credential, GET /api/v1/auth/me/permissions returned 8 capabilities, all platform built-ins, ZERO app-declared — and a scoped persona served as the positive control proving the requiredPermissions filter was live on that boot rather than failing open. The routes the new text points at were verified to exist rather than assumed, which is the failure mode ADR-0115's amendment is about.

The two halves this card carried, filed before it closed

⚠️ Closes #17081 would have taken them with it — a local grep over all 91 open domain:cli + repo:objectui cards found devHint, devLogins and empty shell in this card alone (positive control plugin 30/91; fabricated term 0).

• Let an app contribute its own first-run credentials to the boot banner (devHint / devLogins[]) — the platform cannot know which of an app's audiences shows something, and only the app can #17556 — let an app contribute its own first-run credentials (devHint / devLogins[]), routed domain:spec, because a new key on a published schema is always clause-② yes under the mechanical floor. This is the half this card itself called 「the fix that scales — the app is the only party that knows what its audiences are」.
• [objectui half] The console renders an empty shell when an app's navigation resolves to zero entries — say so instead, so the operator learns it is the account and not the app #17557 — the objectui half: say so when navigation resolves to zero entries instead of rendering an empty shell.

⭐ And recorded for whoever picks those up: the in-repo showcase app declares no requiredPermissions of its own, so it cannot reproduce the empty-navigation shape this card reports downstream. ⛔ A full showcase nav is not evidence against this card.

Review record: PR #17555 comment 5626481151.

_{派发席位 · session_01DapQyvYrFb1MxSYe7BL2nt · R72 · 2026-09-10T23:15Z(读表) · 本评论来自 domain:cli 派发座位}

---

Generated by Claude Code