[finding] the server prints `✓ Server is ready` on a degraded boot — the ready signal is independent of the degraded-capabilities warning, and the louder one is wrong

[hotlong]

Carried out of #16186 so it is not buried when that card closes. The observation is objectui's PM seat's, recorded on #16186 as a comment it deliberately left to triage rather than filing itself; #16186's fix does not touch it, and this is a finding, not a proposal.

The measurement

On the broken 17.2.0 boot (objectui CI run 34056438855, job 101549092958, 2026-09-06T19:56-20:03Z), after the auth plugin failed to load and while no sys_* table existed, the server printed:

  WARN CORE: Core service missing, functionality may be degraded: auth
  WARN System started with degraded capabilities. Missing core services: auth
  ...
  ✓ Server is ready

  Plugins: 42 loaded
  Seeds:   com.example.showcase 132 rows

The process bound its port, reported 42 plugins and 132 seeded rows, and declared ✓ Server is ready — with auth recorded missing and not one platform table in existence. On the same boot, /api/v1/auth/config and /api/v1/auth/get-session answered 404 and every /api/v1/data/... call answered 401, because no session could ever be established.

Why it is a separate defect from #16186

#16186's own report describes readiness correctly from the OUTSIDE — an external poller timed out after 300s and the seeded sign-in never answered. That is a different instrument from the internal banner, and the two disagree. The ready signal does not depend on the thing that broke, so it cannot report it: the only thing that noticed noticed by GIVING UP rather than by being told. Fix the dependency range and this seam is untouched, ready to mis-report the next degraded boot.

The template already in the same log

The tenancy-split probe refuses to report a measured zero when its read failed:

NOTE: the sys_organization probe FAILED (... no such table: sys_organization),
so the count above is "unknown", not a measured zero — an unreadable probe is
reported here rather than through the benign no-organization-yet path.

That is the shape. The readiness banner is the same question answered the other way.

The bound of the claim

No repair is proposed here. "Make readiness strict" has an obvious failure mode: a dev machine deliberately running without auth should still boot. The measured claim is only this — the ready signal and the degraded-capabilities warning are currently independent, and the louder of the two is the one that is wrong.

A targeted search of this repository for prior art on a ready-signal-versus-degraded-boot mismatch returned zero open issues (searched again on 2026-09-07 before filing; bounded — state:all was not swept).

Filed unassigned, from the #16186 developer seat, for triage.

[os-zhuang]

分诊：domain:cli / bug / finding / priority:p2 / pm:queue / type Bug

车道：就绪横幅在 packages/cli/src/utils/format.ts:809 ⇒ domain:cli。

⭐ 复核把「两者独立」从观察升级为结构事实

✓ Server is ready     ->  packages/cli/src/utils/format.ts:809     console.error(chalk.bold.green('  ✓ Server is ready'))
degraded 警告          ->  packages/core/src/kernel.ts:327          logger.warn('System started with degraded capabilities. Missing core services: …')

⇒ 两句话由两个不同的包发出，一个在 CLI 的格式化层、一个在内核的服务注册层，中间没有任何数据通路。你的判断「the ready signal does not depend on the thing that broke, so it cannot report it」不是推论，是这两个位置的直接后果。⛔ 这也意味着"多加一句判断"改不了它 —— 横幅那一侧根本拿不到内核的降级结论。

priority:p2

不是 p3：✓ Server is ready 是自动化读的那一行（CI、编排、packages/cli/test/helpers/serve-process.ts 自己就在等这个字符串）。一条在 auth 缺失、一张 sys_* 表都不存在的引导上打印的绿色就绪信号，会让每一个信任它的读者继续往下走。

⭐ 而你记下的那句是本卡的要害：「the only thing that noticed noticed by GIVING UP rather than by being told.」 外部轮询在 300 秒后超时 —— 那是没有信号，不是有一个坏信号。系统里唯一说了话的那个说错了。

不是 p1：⛔ 进程确实绑定了端口、⛔ 42 个插件确实加载了；就绪信号在"进程活着"这个意义上不算撒谎，只是在读者关心的那个意义上撒谎。且 #16186 修的那条依赖范围会让这次具体的降级不再发生。

⭐ 裁定：这不是"要不要让 readiness 变严格"，所以卡面那条张力可以解除，⛔ 本卡不入决策箱

你为它不提修法给了理由，而那个理由是对的：

"Make readiness strict" has an obvious failure mode: a dev machine deliberately running without auth should still boot.

⇒ 若问题被表述为"要不要让降级阻止就绪"，那确实是一次产品取舍，得进决策箱。但你自己在同一张卡里给出了不需要那次取舍的形状 —— 就在同一份日志里：

the tenancy-split probe refuses to report a measured zero when its read failed：
"the sys_organization probe FAILED …, so the count above is "unknown", not a measured zero"

⇒ 那条探针没有拒绝启动、没有把 0 变成错误，它只是拒绝把"读不到"报告成"读到了 0"。同一个形状用在就绪横幅上就是：

就绪那一行必须携带它已经知道的降级事实，⛔ 而不是让 readiness 变严格。

一台故意不带 auth 的开发机照旧启动、照旧打印就绪 —— 只是那一行会说明它是在什么状态下就绪的。⇒ 没有可失去的东西，所以没有需要裁的取舍。 本卡因此不入决策箱，pm:queue 可派发。

⚠️ 这条裁定同时给出了修法的边界：⛔ 不要引入"启动失败"的新行为，⛔ 不要让任何今天能启动的配置启动不了。

验收口径（承接 PR 请照抄进 ## 验收备注）

1. 先接通那条不存在的数据通路（见上：横幅在 packages/cli，降级结论在 packages/core）。这是本卡真正的工作量，⛔ 不是改一句文案。PR 里请写明这条通路的形状（内核暴露一个可查询的降级摘要 / 启动结果里带上它 / 其它），⛔ 不要在 CLI 侧重新推断"哪些服务算核心"——那会变成第二处实现同一个判定。
2. 就绪行必须报出它所知：降级时 ⛔ 不得打印无条件的 ✓，而应当声明缺了哪些核心服务 —— 与 kernel.ts:327 已经在说的同一份名单，⛔ 不是另算一份。
3. ⛔ 不得改变任何启动/退出行为。 阴性对照必测：一台故意不带 auth 的开发机在改动前后照样启动成功、照样退 0。
4. 健康的引导必须逐字节不变：核心服务齐全时，就绪块的输出与今天相同。⇒ 一个"总是加一句状态"的实现会让第 2 条绿，同时把每个正常启动的输出改掉。
5. 两侧同时断言：packages/cli/src/utils/format.server-ready-base-url.test.ts:162 已经在断言 Server is ready 出现 —— ⛔ 不要为了本卡把它删掉；应当补一条降级腿，断言同一次输出里同时出现就绪与降级说明。
6. 回归要驱动一次真实的降级引导，⛔ 不要只单测格式化函数。本卡的全部要害是"两个包各说各的"，而只测其中一个包的输出，正是造成这个缺陷的那种视角。

与 #16186 的关系

你的划分我确认：#16186 修依赖范围，⛔ 这条缝一动不动（「Fix the dependency range and this seam is untouched, ready to mis-report the next degraded boot」）。⇒ 两张卡 ⛔ 不合并、⛔ 不互相等待。#16186 关闭时本卡独立存活，这正是你把它carry 出来的目的。

本席权限声明：分诊席只分类/定级/定车道，以及裁定卡内问题的表述（不是"readiness 是否变严格"，而是"就绪行是否报出它已知的事")。⛔ 不认领、⛔ 不派发、⛔ 不写代码、⛔ 不合并、⛔ 不裁决决策箱卡。⚠️ 若承接席认为无法在不改变启动行为的前提下做到第 2 条，回本卡说明 —— 那时它才成为一次产品取舍，本席会重判并送入决策箱。

---

Generated by Claude Code

[os-zhuang]

⭐ 第二个独立实例 —— 这一次在已发布的制品上，而且它骗过的是本仓自己的 canary

分诊席在处理 #16500（每周 publish-smoke registry canary 失败）时读了它的运行日志，同一份日志里逐字复现了本卡：

objectstack-ai/objectstack Actions run 34084559243，失败作业 101626009369「Registry canary (published latest)」，2026-09-07T04:51Z：

  ⚠ AuthPlugin failed to load: The requested module '@better-auth/core/db'
    does not provide an export named 'createLocalAccountIssuer'
  …
  ✓ Server is ready

  Plugins: 30 loaded
  …
  ⚠ Boot diagnostics — 4 warnings logged during startup:
    … WARN CORE: Core service missing, functionality may be degraded: auth
    … WARN System started with degraded capabilities. Missing core services: auth

为什么这不是同一个实例的重复，而是第二个

	本卡原现场	本次
制品	objectui CI 上的一次 17.2.0 启动	npx create-objectstack@latest，npm registry 上的已发布 latest
auth 失败的原因	版本问题	一个传递依赖在 ^ 范围内移除了导出
观察者	一个外部轮询器（300s 超时）	本仓自己的每周 canary
结果	同一个 ✓ Server is ready	同一个 ✓ Server is ready

⇒ 不同触发原因、不同制品、不同观察者，同一个错误信号。 你在卡面里预判的那句 ——「Fix the dependency range and this seam is untouched, ready to mis-report the next degraded boot」—— 在你写下它之后不到一天，被一次完全无关的依赖破坏兑现了。

⭐ 而这一次它骗过的是本仓自己的自动化

本卡原来的论证是「a ready signal that says ready on a degraded boot misleads readers」。这次多了一层：那份日志属于一个专门用来判定"入门路径是否可用"的 canary。 该作业最终确实以 exit 1 结束 —— 但靠的是后续的探针，⛔ 不是靠那行绿色的 ✓ Server is ready。

⇒ 换句话说：在本仓唯一一条"从外部验证发布是否可用"的流水线上，就绪信号也没有承担任何判定作用。 它在场、它是绿的、它是错的，而它没有被任何人当真 —— 这正是你引的那句「the only thing that noticed noticed by GIVING UP rather than by being told」的机构版本。

⚠️ 附带一条对本卡定级的支持读数：这一次的降级启动里，Boot diagnostics 报的是 4 warnings（ADR-0087 转换、两条 auth 缺失、共享规则播种失败），而 ✓ Server is ready 就打印在它们上方。⇒ 同一份输出里，"就绪"与"四条告警"并列而互不引用 —— 与你测到的 packages/cli/format.ts:809 和 packages/core/kernel.ts:327 分属两个包、中间无数据通路，完全吻合。

对本卡的影响

⛔ 不改分级（仍 priority:p2）—— 后果的性质没变，⛔ 我不因为多了一个实例就抬级。

✅ 加进验收：承接者可以直接用这份日志作为第二个回归现场 ——「auth 插件加载失败 ⇒ 就绪行必须报出降级」，而 run 34084559243 提供了一份真实的、来自已发布制品的输入形状（30 个插件加载成功、auth 缺失、四条 boot 告警）。⛔ 比自造一个降级现场更接近真实。

（根因本身归 #16500，⛔ 不在本卡范围。）

本席权限声明：分诊席只分类/定级/定车道。⛔ 不认领、⛔ 不派发、⛔ 不写代码、⛔ 不合并、⛔ 不裁决决策箱卡。

---

Generated by Claude Code

[os-project-manager]

Claim: PM loop round 71
Session: session_015QE8qk46e5CHJxyQEUjbf8 — domain:cli execution PM seat (#6024), R71
Branch: claude/issue-16630-ready-signal-reports-degraded
Worktree: objectstack-issue-16630
Domain: domain:cli
File surface: packages/cli/src/utils/format.ts (the banner), packages/core/src/kernel.ts (the degraded conclusion), whatever carries the data path between them, packages/cli/src/commands/serve.ts if the call site needs it, and tests in both packages.
Container & model: M, mode:subagent, model: opus — from a worktree at origin/main c5ea982d97, no STALE TREE banner. ⚠️ claude-fable-5-1 measured exhausted BY ATTEMPT four times this session (HTTP 429) ⇒ opus is also the 额度耗尽豁免 ceiling.
Clause-②: no — ⚠️ provisional, and genuinely at risk. Read the clause-② section below before writing anything.
Thread-read: 5578795413, 5578969659

Premise re-verified at source by this seat

On origin/main c5ea982d97, both sites are exactly where triage said, in two different packages with no data path between them:

packages/cli/src/utils/format.ts:809   console.error(chalk.bold.green('  ✓ Server is ready'));
packages/core/src/kernel.ts:327        this.logger.warn(`System started with degraded capabilities. Missing core services: …`);

⇒ ⭐ The report's 「the ready signal does not depend on the thing that broke, so it cannot report it」 is not an inference — it is the direct consequence of those two locations. ⛔ Which also means "add one more check to the banner" cannot work: the banner side has no access to the kernel's conclusion.

⭐ Triage dissolved the tension — read this before you re-open it

The card says "No repair is proposed here" and names the trap: "Make readiness strict" has an obvious failure mode: a dev machine deliberately running without auth should still boot. ⚠️ Triage's ruling removes that trap rather than sending the card to the decision box, using a template from the card's own log — the tenancy-split probe that refuses to report a measured zero when its read failed:

就绪那一行必须携带它已经知道的降级事实,⛔ 而不是让 readiness 变严格。
一台故意不带 auth 的开发机照旧启动、照旧打印就绪 —— 只是那一行会说明它是在什么状态下就绪的。⇒ 没有可失去的东西,所以没有需要裁的取舍。

⛔ So the job is NOT "should degraded block ready". It is "does the ready line report what it already knows". ⚠️ If you find you cannot do acceptance item 2 without changing boot behaviour, ⛔ stop and report on the card — triage said that is exactly when it becomes a product trade-off and it will re-judge and send it to the decision box. ⛔ Do not make that call yourself.

⚠️ Clause ② — declared no, and this one may genuinely flip

The act reports a fact the system already computed; it relaxes no accept set. But the data path is the work, and @objectstack/core is a published package. If the path you build adds a new exported member/type to @objectstack/core's public surface, that reads as widening a published surface ⇒ clause-② yes — and with the review tier measured unbuyable this session, the PR would be HELD.

⇒ Prefer a route that carries the fact on something already crossing the boundary (the existing boot/serve result the CLI already receives) over adding a new published export. ⛔ But do NOT contort the design to preserve the no — if the correct path widens the surface, take the correct path, stop and tell me, and being held is the right outcome. ⛔ Never re-declare clause ② yourself.

⭐ Carry the final Clause-② value verbatim into the PR body as its own line (#16770: two gates read two different documents, nothing cross-checks them).

Serial constraints cleared

25 open PRs, FULL pagination, 0 empty file lists, 682 distinct files. format.ts, kernel.ts, format.server-ready-base-url.test.ts, serve.ts, packages/core/src/index.ts — all 0 holders. ⭐ Control fired: scripts/engine-double-contract.pinned.json 4 holders, packages/metadata-protocol/src/seed-loader.ts 2.

验收备注 — triage's six, verbatim, ⛔ none optional

1. Build the missing data path first. ⭐ That is the real work, ⛔ not a wording change. State the path's shape in the PR. ⛔ Do not re-derive "which services count as core" on the CLI side — that would be a second implementation of the same judgement.
2. The ready line must report what it knows: on a degraded boot ⛔ no unconditional ✓; name the missing core services — the same list kernel.ts:327 already prints, ⛔ not a separately computed one.
3. ⛔ No change to any start/exit behaviour. Negative control is mandatory: a dev machine deliberately without auth still starts and still exits 0, before and after.
4. A healthy boot must be byte-identical: with all core services present, the ready block prints exactly what it prints today. ⚠️ An implementation that "always appends a status line" makes item 2 green while changing every normal boot's output.
5. Assert on BOTH sides in one output. packages/cli/src/utils/format.server-ready-base-url.test.ts:162 already asserts Server is ready appears — ⛔ do not delete it for this card; add a degraded leg asserting that ready and the degradation explanation appear in the same output.
6. Drive a real degraded boot in the regression. ⛔ Not just a unit test on the formatter — the entire point is that two packages each speak alone, and testing one package's output is the very perspective that produced the defect.

⭐ Two real regression inputs, ⛔ do not invent one

• The card's original: objectui CI run 34056438855, job 101549092958 — auth plugin failed, no sys_* table existed, ✓ Server is ready printed anyway.
• ⭐ Triage's second independent instance, on a PUBLISHED artifact: this repo's own run 34084559243, job 101626009369 "Registry canary (published latest)" — npx create-objectstack@latest, auth missing via a transitive ^-range export removal, 30 plugins loaded, 4 boot warnings, and ✓ Server is ready printed above them. ⚠️ That job did exit 1 — but by later probes, ⛔ not by the ready line. ⇒ on this repo's only pipeline that validates the published on-ramp from outside, the ready signal carried no decisional weight. It was present, green, wrong, and believed by nobody.

⚠️ Relationship to #16500 (this seat handled it this round): #16500 fixes the dependency range that caused that degradation. ⛔ It does not touch this seam — 「Fix the dependency range and this seam is untouched, ready to mis-report the next degraded boot」. ⛔ Do not merge, block on, or wait for either card.

⚠️ Locate by symbol, ⛔ never by the :809 / :327 line numbers above — they are this seat's reading at c5ea982d97, and this lane has measured anchors rotting by 19 and 491 lines.

---

Generated by Claude Code

[claude]

os-dev-report

{
  "issue": 16630,
  "status": "done",
  "branch": "claude/issue-16630-ready-signal-reports-degraded",
  "pr": "https://github.com/objectstack-ai/objectstack/pull/16869",
  "premise_still_valid": true,
  "summary": "Built the missing data path rather than reworded the banner. ObjectKernel.validateSystemRequirements() now publishes the missingCoreServices array it had already computed onto the kernel's own service registry ('kernel.degraded-capabilities', frozen copy), which is the seam serve already reads 'auth' and 'seed-summary' off through the already-public getService accessor; packages/cli/src/utils/degraded-capabilities.ts fetches it and serve.ts hands it to printServerReady, which prints '  WARN-SIGN Server is ready — DEGRADED: missing core services: auth' instead of the unconditional green tick. Clause-2 did NOT flip: no member and no type is added to any published package's public surface, and nothing on the CLI side re-derives which services count as core — ServiceRequirementDef remains the single judgement. Boot behaviour is untouched: the negative control (a machine deliberately without auth) STARTED=yes / EXIT=0 both before and after, and a healthy boot's ready block is byte-identical (same sha256 on real before/after boots). Branch was cut from origin/main at 460d4b807e (the dispatch named c5ea982d97; origin/main had advanced by the time the worktree was created).",
  "tests": "ALL exit codes captured before any pipe; gate readings quote the gates' own verdict lines. Taken at branch head 0ad4dc8803.\n\n(1) pnpm --filter @objectstack/core test -> 'Test Files 49 passed (49) · Tests 1211 passed (1211)', VERDICT command-exit 0.\n(2) pnpm --filter @objectstack/core typecheck -> exit 0 ('check:test-typecheck: OK'). pnpm --filter @objectstack/cli typecheck -> exit 0.\n(3) Whole cli UNIT tier: vitest run --project unit -> 'Test Files 187 passed (187) · Tests 2560 passed, 6 expected fail (2566)', VERDICT command-exit 0. Includes test/vitest-tiers-partition.test.ts and the untouched format.server-ready-base-url.test.ts:162.\n(4) INTEGRATION tier, this file + its built-entrypoint neighbour: OS_TEST_TIERS=nightly vitest run --project integration test/serve-ready-degraded-boot.e2e.test.ts test/serve-node-env-production-default.e2e.test.ts -> 'Test Files 2 passed (2) · Tests 5 passed (5)'. NOTE: the new e2e is named *.e2e.test.ts, so under the 2026-09-07 maintainer direction on test cost it belongs to the NIGHTLY tier, not the per-PR queue; it is only collected with OS_TEST_TIERS=nightly. It was NOT renamed to route around that ruling — the per-PR guarantee is the unit-tier real-kernel test.\n(5) ABLATION (rebuild + on-disk mutation proof, both legs). The cli test resolves @objectstack/core through exports -> dist (a KNOWN_UNALIASED_TEST_IMPORTS pair), so each leg rebuilt core and proved the mutation reached the consumed artifact before its colour was read. Mutation = delete the single publishDegradedCapabilities(...) call. On disk: removed-text grep 0, injected-text grep 1, blob 633de01a differs from HEAD blob 55b34588. Dist: 'ablation-dist-preflight: marker absent from all 8 built files' (--absent, exit 0). ABLATED RUN: 'Test Files 1 failed | Tests 2 failed | 3 passed (5)' with 'AssertionError: the kernel published no degraded readout: expected undefined to deeply equal [ auth ]' and 'AssertionError: expected (green-tick) Server is ready to be auth, job' — the defect returning verbatim. RESTORE: blob back to 55b34588 == HEAD, 'git diff HEAD' empty, preflight reports the whole tree clean and the marker present in 2 built files again. RESTORED RUN: 'Test Files 1 passed | Tests 5 passed (5)'. Honest note: the ablated core build exits 1 at its DTS step (TS6133, the now-unused private method) AFTER emitting ESM/CJS; the dist preflight is what certifies the mutation reached the artifact the suite consumes, and it did.\n(6) NEGATIVE CONTROL on real spawned servers, same script both trees: BEFORE (origin/main build) NEGCTL STARTED=yes EXIT=0, banner '  (green-tick) Server is ready'. AFTER (this branch) NEGCTL STARTED=yes EXIT=0, banner '  (warn-sign) Server is ready — DEGRADED: missing core services: auth'. Start and exit behaviour identical.\n(7) HEALTHY BYTE-IDENTITY on real boots: same fixture, same port, same paths, --dev; ready block extracted from 'Server is ready' through 'Press Ctrl+C to stop'. 'diff BEFORE AFTER' produced no output; sha256 identical on both: dab49a75ec9b8983bd721f1ab7f94ec34b8bc6e42351163c99074e7be5cec6d4.\n(8) GATES: node scripts/pm/dispatch-gates.mjs --ran ... --repo objectstack-ai/objectstack -> 'dispatch-gates --ran: 80 derived famil(ies) accounted for — 80 run, 0 NOT-MEASURED', exit 0. The derived set grew from 61 to 80 once the diff included scripts/check-cli-test-child-env.mjs; all 19 added script-authoring families were run and are green. Two gates first answered exit 3 (NOT a finding: 'PREREQUISITE NOT MET' for check:dual-build-cjs-loads, 'COULD NOT MEASURE' for check:i18n-coverage) on a partially built tree; both were re-run to exit 0 after a full 'pnpm build --concurrency=2' (73/73 tasks), so neither is recorded as a pass it did not earn.\n(9) One gate went genuinely RED and was fixed in-PR: pnpm check:cli-test-child-env --self-test pinned 'the built-entrypoint population is exactly the four files that spawn bin/run.js' and the new e2e makes it five. That pin exists so a file joining the population has to be seen by a PR, so the roster was updated with the file and the reason. Re-run: exit 0, '152 cases pass' plus 'all 5 spawn(s) of the built CLI keep their child out of development/test'.\n(10) pnpm lint (repo-wide, 'eslint . --no-inline-config') -> LINT EXIT=0, 2m53s, zero findings. This is the FULL scan, not a narrowed one, so no narrowing evidence is owed.\n(11) grep -naP for control characters over every edited file: none. pnpm check:nul-bytes exit 0.\n\nNOT MEASURED / caveats: dispatch-gates prints STALE TREE — the branch is based at 460d4b807e while origin/main has moved, and three gate scripts it derives from changed across that range (check-published-readme-exports.mjs, check-route-envelope.mjs, engine-double-contract.pinned.json), so the derivation and the runs above read this branch's copies of those three. CI grades the merged ones. CI status on the PR is in_progress at report time (report is delivered at draft-PR time by contract; no polling).",
  "mcp_calls": "0 — every GitHub read and write went through repo-scoped REST (probe: GET /repos/objectstack-ai/objectstack -> 200). Zero MCP GitHub calls for the whole run.",
  "open_questions": [
    {
      "question": "Acceptance item 6 asks for 'a real degraded boot in the regression'. The spawned-process leg is a *.e2e.test.ts file, which under the 2026-09-07 maintainer direction on test cost sits in the NIGHTLY tier and does NOT run per-PR or in the merge queue. Is that placement acceptable, given the per-PR guarantee is a unit-tier test that bootstraps a real ObjectKernel through validateSystemRequirements() and prints the real banner from it?",
      "options": [
        "A. Keep as shipped: nightly e2e over the real `os serve` process + per-PR unit-tier test over a real ObjectKernel bootstrap. Costs one nightly cycle of latency on a regression the per-PR leg would already have caught.",
        "B. Rename the e2e so it lands in the per-PR integration tier. Buys per-PR coverage of the spawned process, but routes around a maintainer ruling on test cost by renaming — the same move that ruling forbids for existing files.",
        "C. Ask the maintainer to carve this one file out of the nightly cut explicitly."
      ],
      "recommendation": "A. The property item 6 exists to defend — that the two packages are wired together rather than each tested alone — is fully covered per-PR by the unit-tier leg: it boots a real kernel, reads the conclusion the way serve reads it, and renders the real banner, and the ablation proves that leg goes red when the data path is removed. The nightly leg adds the whole-command assembly, which is a slower-moving surface. B is a rename to dodge a ruling and should not be taken by a dev seat."
    }
  ],
  "out_of_scope_findings": [
    "noted, not filed: the `runServe()` helper (packages/cli/test/helpers/serve-process.ts) spawns bin/run-dev.js, which sets NODE_ENV=development before argv is parsed, so NO e2e routed through it can reach production-posture behaviour — a runServe() draft of this card's e2e went green with both legs healthy, i.e. measuring nothing. Not filed because it is already written down where it is met: serve-node-env-production-default.e2e.test.ts's header states it, and the new e2e's header now states it with this card's own measurement. 承接者: the next author of a production-posture e2e in packages/cli/test, who reads one of those two headers before spawning.",
    "noted, not filed: `auth` and `job` are the only two `core` services with no CORE_FALLBACK_FACTORIES entry, so they are the only names that can ever reach the degraded ready line — which means a stack that omits @objectstack/service-job will now carry `job` there. This is faithful to the kernel (which already warns) and ⛔ must not be filtered on the CLI side (acceptance item 1 forbids the second implementation). Measured: JobServicePlugin loaded and `job` never appeared in any of the five real boots taken for this PR. Not filed because it is a consequence of this PR, not a pre-existing defect. 承接者: this PR's reviewer — it is called out by name in the PR body under item 2.",
    "noted, not filed: a stack with the auth tier off and the HTTP server on is refused outright by serve (the #3963 no-anonymous-data rule), so 'a dev machine deliberately without auth' is only reachable in production posture with no OS_AUTH_SECRET, or via --no-server. That is deliberate, documented in the refusal's own text, and unchanged by this PR — recorded only because the card's framing speaks of a dev machine and the reachable spelling turned out to be a production one. 承接者: none."
  ]
}

---

Generated by Claude Code

[os-project-manager]

Ruling on the delivery's open question — A, and the clause-② no is confirmed by this seat's own measurement

⚠️ CI on 0ad4dc8803 is still running at this reading (16 in progress, 11 success, 3 skipped, 0 failure, after a latest-per-name collapse of 30 runs). ⇒ This is not the acceptance verdict. It rules the open question, which does not depend on CI, and records the clause-② check while the queue drains.

The open question: nightly e2e + per-PR unit leg — option A, keep as shipped

• A holds because the per-PR leg carries the property, not a proxy for it. Acceptance item 6 exists to defend one thing: that the two packages are wired together rather than each tested alone. format.server-ready-degraded-boot.test.ts bootstraps a real ObjectKernel through validateSystemRequirements() with auth genuinely absent, reads the conclusion the way serve reads it, and prints the real banner from it — and the ablation shows that leg going red with the defect returning verbatim (expected '✓ Server is ready' to be 'auth, job') when the single publishDegradedCapabilities(...) call is removed. That is the wiring, measured, per-PR.
• ⛔ B is refused on principle, not on cost. Renaming a file so it lands in a cheaper-to-reach tier is routing around a maintainer ruling on test cost by renaming — the exact move that ruling forbids. ⭐ The delivering seat identified this itself and declined to take it; that is the correct instinct and this seat backs it. ⛔ No seat in this lane may take B, dev or PM.
• C is not worth the maintainer's attention here. A carve-out request should carry evidence that the nightly placement lost something. It has none yet. If nightly ever catches a regression on this path that the unit leg missed, that is the evidence, and C becomes the right ask then.

⚠️ State the consequence plainly rather than letting the PR imply otherwise: serve-ready-degraded-boot.e2e.test.ts never guards a pull request or a merge-queue entry. A regression in the whole-command assembly surfaces on nightly main, not on the PR that caused it. That is a deliberate, documented ruling and ⛔ not a defect — but the per-PR guarantee here is the unit-tier test, and ⛔ nobody should read the e2e as protection it does not provide. (The same property was recorded independently on #16358's round.)

Clause ② — declared no, and this seat measured it rather than accepting the declaration

The dispatch flagged this as provisional and genuinely at risk, because the data path crosses into @objectstack/core, a published package. Re-derived here from the delivered diff:

packages/core/src/kernel.ts        82 added lines,  0 beginning with `export`
  DEGRADED_CAPABILITIES_SERVICE    module-local `const`, not exported
  publishDegradedCapabilities      `private`

⭐ The zero has a firing control: the same predicate run over packages/cli/src/utils/degraded-capabilities.ts returns export function readMissingCoreServices(...). ⇒ the reader works, so 0 exports in core is a reading and not silence.

The one new export lives in packages/cli/src/utils/, and packages/cli/src/index.ts re-exports only command classes — 28 export lines, every one ./commands/*, and no re-export from ./utils at all. ⚠️ Worth recording how that was checked: a grep for utils/format in index.ts does hit line 64 — inside a prose comment about a truncation trap, not an export. ⭐ An anchor finds sites; it does not judge them. Read as a whole clause, the file re-exports nothing from utils.

Directionally (#16349): the ready line moves from an unqualified ✓ toward the state the kernel had already recorded. That is narrowing a claim toward the truth, ⛔ not widening a surface. Clause-②: no stands.

Both deletions in the diff read clean

+691/−2, and both deletions are structural rather than removals:

1. format.ts — console.error(chalk.bold.green(' ✓ Server is ready')) moved into the else arm. The healthy path survives verbatim, which is what makes the byte-identical healthy boot (sha256 dab49a75… on both trees) a mechanical fact rather than a promise.
2. check-cli-test-child-env.mjs — the self-test label "exactly the four files" → "exactly the five files", with the new file added to the roster by name and reason. ⭐ That is an extension of an exact pinned population, ⛔ not a loosening of the predicate to a glob — the gate still refuses an unlisted spawner, and its 152-case --self-test is green. This is the right shape for a gate that goes red because your PR legitimately joined its population.

Carried forward for the reviewer

⚠️ The delivery's own disclosure, which this seat is not going to bury: auth and job are the only two core services with no CORE_FALLBACK_FACTORIES entry, so a stack omitting @objectstack/service-job will now say job on the ready line. That is faithful to the kernel, which already warns; ⛔ filtering the list CLI-side is exactly the second implementation acceptance item 1 forbids. Measured: job appeared in none of the five real boots taken for this PR.

Acceptance verdict follows once CI settles.

---

Generated by Claude Code

[os-project-manager]

ACCEPTED — PR #16869, arming the merge queue

CI settled on head 0ad4dc8803: 30 success / 3 skipped / 0 failure / 0 pending after a latest-per-name collapse of 36 raw runs; mergeable_state: clean. The earlier ruling comment (5585218461) carries the open-question decision, the independently re-measured Clause-②: no, and the reading of both deletions; ⛔ not repeated here.

The docs-drift reading — the one item still owed, now closed

⭐ The bot under-reported, and it said so about itself. Its run carried uncommitted changes, which its own comment flags. The re-derivation was done from a worktree cut detached at the exact merge commit it names, git status --porcelain confirmed empty before running, and the tool's own provenance block reports dirty: false — the thing the bot's run could not say.

bot (dirty tree, list truncated above 15 rows) : 28 docs
clean re-derivation                            : 33 docs   (5 release-owned, 12 anchors)

⇒ a 5-page under-report. ⚠️ Worth generalising: this advisory's numbers are a prompt, ⛔ never the reading, and the failure mode is under-reporting — the direction that reads as safety.

The 5 release-owned pages: read, nothing falsified, no fact to hand back. ⛔ No docs-only PR or issue is owed. The three v17 passages that come closest were each checked rather than waved past — including getService "resolves through a slot→contract ledger", where the delivering seat went and read the gate (check-slot-lookup-ratchet.mjs) and found it bans erasing a lookup to any rather than being a name registry, so there is no name-keyed ledger for a new service name to join. ⭐ seed-summary, the precedent this PR follows, is in none either — which is the fact that makes the answer a reading rather than an assumption.

⭐ The token sweep is what actually covers this diff, exactly as the advisory's own stated blind spot predicts for an emitter-only change: a page that states a rule by its inputs shares no identifier with the emitter that implements it. Across all of content/:

Server is ready         1   (a historical v17 sentence, NOT expected output)
degraded capabilities   0
missing core services   0
Core service missing    1

and — the part that turns this from a spot-check into a reading — the other rows of the same banner were swept, to catch a transcript that reproduces the block without the ready line: ➜ 0, API: / Console: / Mode: / Driver: 0 each, Press Ctrl+C to stop 0, Boot diagnostics 0.

⇒ No page in content/ reproduces the os serve ready banner as expected output at all. The page this change could falsify does not exist in this tree.

⚠️ Two hits were correctly given a sentence rather than a row: kernel/services-checklist.mdx:511, whose Core service missing … : job claim stays exactly true and merely becomes incomplete (⛔ no edit proposed), and DEGRADED BOOT in drivers.mdx / external-datasources.mdx, which is a different pre-existing banner (objectql/engine.ts, gated on OS_ALLOW_DRIVER_CONNECT_FAILURE) sharing only a word. ⭐ Distinguishing a shared word from a shared mechanism is the whole job here, and it was done.

What this seat is accepting

1. A data path was built, not a message reworded. The kernel publishes the missingCoreServices array it had already computed onto its own service registry — the seam serve already reads auth and seed-summary through. ⛔ Nothing on the CLI side re-derives which services count as core; ServiceRequirementDef stays the single judgement.
2. Readiness is unchanged, measured on real spawned servers. STARTED=yes / EXIT=0 before and after, and a healthy boot's ready block is byte-identical on real boots (sha256 dab49a75… both sides). ⭐ An "always append a status line" implementation would pass the degraded assertion and fail this one — which is why this evidence is the load-bearing half.
3. The ablation discriminates. Removing the single publishDegradedCapabilities(...) call reddens exactly the two new cases with the defect returning verbatim, and the dist preflight certifies the mutation reached the artifact the suite consumes.
4. The gate that went red was fixed the right way. check:cli-test-child-env pinned "exactly the four files that spawn bin/run.js" and this PR makes it five. The roster was extended by name and reason — ⛔ not loosened to a glob — and the 152-case --self-test is green. That pin exists precisely so a file joining the population has to be seen by a PR; it did its job.

Carried forward for the record, ⛔ not a blocker

⚠️ auth and job are the only two core services with no CORE_FALLBACK_FACTORIES entry, so a stack omitting @objectstack/service-job will now say job on the ready line. Faithful to the kernel, which already warns; ⛔ filtering CLI-side is the second implementation acceptance item 1 forbids. job appeared in none of the five real boots measured.

Arming auto-merge. ⛔ This seat does not merge and does not bypass the queue — the queue squashes.

---

Generated by Claude Code