docs(console): README describes the real Console resolution, not a removed npm fallback

[claude]

Fixes#11262

packages/console/README.md is in this package's files array, so it is the page
npm renders for @objectstack/console. It described a resolution mechanism the CLI
no longer performs.

The stale claim

At origin/main (base 1fa05a6), packages/console/README.md:31-35:

The framework CLI's resolveConsolePath() (in packages/cli/src/utils/console.ts)
prefers @objectstack/console and falls back to @object-ui/console when
present — so cloud's Docker overlay (which cp -rs its build over
node_modules/@object-ui/console) keeps working.

What the code actually does

Read from packages/cli/src/utils/console.ts at the same base — unchanged by this
PR, and deliberately so:

Strategy	Line	Name it accepts
1 · require.resolve('@objectstack/console/package.json'), from the app and from the CLI itself	:194-204	pkg.name === CONSOLE_PACKAGE only
2 · direct <cwd>/node_modules/@objectstack/console	:214-221	pkg.name === CONSOLE_PACKAGE only
3 · sibling-repo dev fallback, ../objectui/apps/console	:233-250	CONSOLE_PACKAGEor@object-ui/console

CONSOLE_PACKAGE is '@objectstack/console' (:48). So:

1. There is no node_modules fallback to the @object-ui/console npm package.
   Both npm-facing strategies reject any resolved package.json not named
   @objectstack/console. The function's own header says the legacy package "is no
   longer consulted" (:28-31).
2. The one surviving mention is not a package resolution. Strategy 3 reads the
   name field of a checked-out ../objectui/apps/consolesource tree — objectui
   still names that workspace package @object-ui/console. It is a source-checkout
   dev probe, and flattening it into "the CLI still falls back to @object-ui/console"
   would leave the README false in a new way.
3. The trailing consequence was the load-bearing half. Cloud and objectos Docker
   images overlay into @objectstack/console's dist/ — console.ts:19-22 states
   this from the framework side, and triage measured the same in the cloud repo
   (its Dockerfiles and extract-console-assets.mjs). The old sentence told an
   operator their overlay works by a mechanism that does not exist.

The change

packages/console/README.md:31-47 (was :31-35) — the paragraph is replaced with the
real resolution order, the source-checkout distinction stated explicitly, and the false
overlay consequence replaced by the actual overlay target.

⛔ The npm fallback is not restored in code. Its removal was deliberate; the README
was the stale side.

Deliberately left alone: the @object-ui/console rows in the comparison table
(:25-29) and the Updating steps (:41,45,47) describe the objectui package and its
build, which genuinely exist and are correctly described.

Changeset, not skip-changeset

A real patch changeset on @objectstack/console. README.md is in the package's
files array, so this text ships to npm — and the repo's own practice for a
published-README correction is a changeset, not the label: #10968, #10929 and #10816
were each a README-prose-only PR carrying .changeset/*.md.

Verification

Gate union re-run after the final commit, at c26f8957. All 13 green, each read
from the gate's own verdict line:

check:changeset-gate-self-tests ✓ 118 + 212 + 116 assertions over real temp git repos
check:objectui-changeset ✓ objectui-range --self-test: all checks passed
check:published-files ✓ 69 publishable package(s) of 78 declare a covering `files` whitelist
check:slot-lookup ✓ ratchet holds: 107 unswept site(s), none new; baseline verified against 1fa05a6
check:test-source-alias OK — 72 packages with tests scanned
check:type-source-resolution OK — 77 packages with a tsconfig.json scanned
check-adr-0087-registration ✓ this PR adds no declared-breaking changeset
check-changeset-no-major ✓ This diff introduces no `major` bump
check-ci-filter-parity OK: all 88 declared cross-package glob(s) covered
check-empty-changeset ✓ No empty-frontmatter changeset introduced by this diff
check-plugin-teardown-shape ✓ 63 Plugin implementation(s) across 4514 source(s)
check-affected-docs ✓ affected-docs self-test: 339 cases pass
check-nul-bytes OK (scanned 6334 text file(s); no raw ASCII control bytes)

Family list re-derived at the final head with
node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack (no paths passed —
the script takes its own change set from the merge base); it named the same 12 families,
all of which were run.

Repo-wide pnpm lint narrowing — measured, not assumed. This diff contributes
zero files to eslint's population, so a repo-wide run cannot move:

1. Population, read from eslint's own config:ESLint#calculateConfigForFile returns
   no rules for either changed file, and lintFiles reports File ignored because no matching configuration was supplied. Every files: block in eslint.config.mjs
   names only {ts,tsx,mts,cts,js,jsx,mjs,cjs}.
2. Count, from --format json: 2 results, 0 non-ignored, 0 errors.
3. Invariance for untouched files:eslint.config.mjs is not in this diff
   (git diff --name-only HEAD -- eslint.config.mjs → 0), and the diff adds no TS/JS,
   so no untouched file's configuration or program membership changes.

There is no prettier or markdownlint gate in this repo, so no formatter applies to
either file.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

Nothing in this diff resolved to a documentable surface (no symbol, route or SDK anchor derived from 1 changed package(s)), so this run has no opinion about the docs.

What this run could not see

• 1 changed file(s) yielded no anchor (packages/console/README.md) — pages documenting those are invisible to this run

Coarse fallback — 8 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 050d8d8685312ee6a0a77bd9036becf30750fd31 → packageMentionDocs.

[github-actions]

⛔ merge queue 构建失败 — 先分诊，再决定要不要重排

队列构建 32629872070 红了。队列跑的是全量套件（PR 侧 CI 只跑 affected 子集），
所以失败的测试可能在本 PR 没碰过的包里 —— 那不是重排能修的。每次盲目重排都会让排在后面的所有 PR 重建一轮。

失败的 job（日志抽取，best effort）：

• Test Core (5/6) — 失败步骤: Verify pnpm version

  AssertionError [ERR_ASSERTION]: The expression evaluated to a falsy value:
  

↳ 失败原因 是判读的关键：超时（Test timed out in … / Hook timed out in …）多半是负载/时序，不是本 PR 的回归；
断言（AssertionError: …）才指向真实的行为改变。两者的 FAIL 行长得一模一样，只有这一行能区分。

跨 PR 相同签名（24h，按失败测试文件聚合）：

• ⚠️本次没有可用的聚合签名（日志里没有能解析出测试文件名的 FAIL 行）—— 这不是「没有同签名的其他 PR」，是这一轮没测到。跨 PR 聚合本次不可用，请手工比对其他 PR 的同类评论。
• ⚠️ 24h 评论账本没读完（超过 5 页仍未读到窗口尽头），所以上面的「不同 PR 数」是下界，不是全量。

历史信号：

• 本 PR 过去 24h 无队列失败记录（首次）。
• 过去 24h 队列共有 71 个失败构建（不含本次）。

分诊清单：

1. 失败测试在本 PR 改动的包里 → 真回归，修 PR。
2. 失败测试与本 PR 无关 → 看上面的「跨 PR 相同签名」；已有汇总 issue ⇒ flaky/环境问题实锤，去那张 issue 上谈，修好前重排只会再烧一轮全队列。
3. 两者都不是 → 可能与同组 PR 语义冲突；等前面的 PR 落地或失败出队后再重排一次即可，不要连续重排。

---

Generated by Claude Code · merge-queue-triage workflow (#4859)

[os-zhuang]

Queue ejection triaged — infrastructure, not this diff. Re-queueing once.

domain:cli seat, session session_019siH5jDmk5hrayvfyojUqR. Dequeued 09:13:24Z, reason: CI_FAILURE, queue build 32629872070.

⛔ The triage bot's excerpt was misleading, and taking it at face value would have produced the wrong call

The bot reported "failed step: Verify pnpm version" alongside a bare AssertionError. That pairing does not make sense on its face: Verify pnpm version is literally

- name: Verify pnpm versionrun: pnpm --version

— it contains no assertion at all (ci.yml:294-295). So either the bot mis-paired a step name with an unrelated error, or something inside that command threw. Those two readings lead to opposite actions (re-queue vs. diagnose a real regression), so I read the job rather than guessing. The bot says its extraction is best-effort; this is what that looks like in practice.

The actual signature

! Corepack is about to download https://registry.npmjs.org/pnpm/-/pnpm-10.31.0.tgz
node:internal/assert/utils:77
AssertionError [ERR_ASSERTION]: The expression evaluated to a falsy value:
assert(!this.paused)
at Parser.finish (node:internal/deps/undici/undici:6165:9)
at TLSSocket.<anonymous> (node:internal/deps/undici/undici:6499:36)
at TLSSocket.emit (node:events:531:35)
Node.js v22.23.2 · Process completed with exit code 1

Corepack fetching pnpm 10.31.0 from the npm registry crashed Node's bundled undici HTTP parser on an internal assertion. Confirmed the job never reached the suite — the run's own guard printed "No test log — the test step did not get far enough to produce one."

Why this is a legitimate re-queue rather than a fix

Three readings, all from the log rather than from judgement:

1. The diff cannot reach it. This PR is packages/console/README.md + a changeset. Nothing in it influences whether Corepack's TLS download completes.
2. It died before any test body ran — checkout/toolchain setup. That is the explicitly named class where one re-run is warranted, as distinct from a test that ran and failed.
3. Not a "flake" hand-wave. The stack names a specific Node/undici defect on a network read, not a timing-sensitive test. ⭐ Worth keeping the distinction the triage template itself draws: a timeout suggests load, an AssertionError suggests real behaviour change — but that heuristic assumes the assertion comes from test code. Here it comes from Node's own HTTP parser, and the heuristic inverts.

⇒ Re-queued once, unmodified. ⛔ No commit pushed, ⛔ nothing skipped, disabled or quarantined, ⛔ no empty commit and no close/reopen to kick CI. If it ejects again on this same signature I will not re-queue a second time — that would make it a real blocker needing a fix, not a retry.

⚠️ Two things I am flagging rather than acting on

• No cross-PR aggregation was available this round. The bot states this explicitly, and it is not the same claim as "no other PR has this signature" — it says this round did not measure it. I am not reading absence of evidence as evidence of absence.
• 71 queue failures in the last 24h (the bot's own count, excluding this one). If a material share are this Corepack/undici signature, that is shared-infrastructure damage rather than 71 unlucky PRs — every ejection re-builds every PR behind it. Filed as a finding for triage to grade; ⛔ I am not adding this signature to the ledger myself (ledger entries are a human escalation) and ⛔ not proposing the fix.

---

Generated by Claude Code