docs(qa): 18.0 sweep round 10 — the walled boot's release attribution, two comma-range citations, the console-dist fact re-measured (#24788)

Refs #24579
Clause-②: no

Round 10 of the 18.0 release sweep's wave anchor (#24579), claim
`6284039882`. One PR in three bounded parts, checklist ledger only: 8
items in 3 area files, each with one `revision` bump and one `history`
row, plus one sentence of `RUNNER.md`, which carries no revision. No
product code, test, pin, objectui spec or changeset text changed.

Base `795ff708d8`, which was `origin/main` when the worktree was made.
The edits are commit `9a85df9a8c`. `origin/main` then moved to
`74f78159af` (#24777, one dogfood test file, disjoint from this PR) and
is merged in at `8bfefd50f5`, the head this PR opens on. The history
rows' `ref` is written as a placeholder and filled with this PR's number
in one later commit that changes only those 8 strings.

## Part (a): "Console dist not found" (#24615, body line 170)
re-measured, nothing recorded

#24615 wrote: "A scratch app copy booted from /tmp prints 'Console dist
not found at packages/console/dist' because the path is resolved
relative to cwd." At this base the cause it names does not hold, so
`RUNNER.md` gets no new entry.

| reading at `795ff708d8` | result |
|:--|:--|
| where the path is resolved |
`packages/cli/src/utils/console.ts#resolveConsolePath`. `os serve` calls
it in its UI-portals block with `onDrift` only, so `cwd` defaults to
`process.cwd()`, not the served app's root. |
| its candidates, in order | (1) `@objectstack/console/package.json`
resolved from the cwd's `package.json` AND from the CLI's own module
location; (2) the cwd's `node_modules/@objectstack/console`; (3)
`../objectui/apps/console` and `../../objectui/apps/console` from the
cwd. Pass 1 takes the first candidate with `dist/index.html`; pass 2
takes the first candidate. |
| where the message is printed | `formatConsoleDistMissingWarning` (same
file), via `describeConsoleDistMissing`. The path is
`path.relative(buildRoot, dist)`, where `findConsoleBuildRoot` returns
the nearest manifest above the console package that declares
`objectui:build`. That is the root of the framework checkout the CLI
belongs to, not the cwd. |
| changed since #24615's base `ba4afcc239`? | No. `git log
ba4afcc..795ff70 -- packages/cli/src/utils/console.ts` is empty.
In `serve.ts` the only change is PR #24667's deletion of the walled
refusal (+1 / −48 lines). |
| probe M1: the real function at this base, no console built anywhere |
From `examples/app-showcase` and from a scratch directory outside the
tree, both resolve this checkout's `packages/console` through the
CLI-own leg, and both print the same line: `⚠ Console dist not found at
packages/console/dist — pnpm build does not produce it. Build it with
pnpm objectui:build in` (this checkout's root). |
| probe M2: a model sibling `objectui/apps/console` with a built `dist`
| It is found only from a cwd whose `../objectui` or `../../objectui`
points at it. This is the one cwd-relative leg, and the canonical
in-tree boot (cwd `examples/app-showcase`) does not reach a sibling
checkout through it either. |
| probe M3: a model checkout whose `packages/console/dist` exists (a
byte-identical copy of `console.ts`) | From the scratch cwd it resolves
that console with `hasDist: true`. With the dist removed (the control),
it prints the same "at packages/console/dist" line, naming that model
checkout's root. |
| verdict | The cause does not hold. The printed path is relative to the
booting checkout's root, and the leg that reaches it does not depend on
the cwd. A scratch copy that prints the line was booted by a CLI whose
checkout has no built console, and an in-tree boot of that checkout
prints the same line. A browser item booted from a scratch copy
therefore needs nothing an in-tree boot does not: `pnpm objectui:build`
in that checkout, the remedy the warning itself names. "Harmless for
API-only items" holds: such a boot mounts a 503 responder on
`/_console/` that names the remedy, and the API is unaffected. |

The probes run the source function with the same argument the boot
passes (`onDrift`, no `cwd`), through tsx's own CLI entry. The
`node_modules/.bin/tsx` shim puts the workspace store on `NODE_PATH`,
and that alone made the cwd leg resolve from outside the tree. A real
`os serve` boot from a scratch copy was not run: NOT MEASURED, because
the source function is what that boot calls and the CLI closure build is
outside this checklist-only card.

## Part (b): `access-security.platform-owner-email-anchor` `source[5]`
and `source[7]`

These are the two comma ranges round 9 left (its report `6283532816`,
`out_of_scope_findings[0]`), because PR #24667 held the item at the
time.

| field | at the authoring commit `45397edf53` | was | now | shared
resolver at `795ff708d8` |
|:--|:--|:--|:--|:--|
| `source[5]` | `env.ts` line 200 = `export function
resolvePlatformOwnerEmail()` |
`packages/types/src/env.ts#PLATFORM_OWNER_EMAIL_ENV,200
(PLATFORM_OWNER_EMAIL_ENV / resolvePlatformOwnerEmail)` |
`packages/types/src/env.ts#PLATFORM_OWNER_EMAIL_ENV +
packages/types/src/env.ts#resolvePlatformOwnerEmail (the variable's
name, and its live per-call read)` | both `declaration`
(`resolvePlatformOwnerEmail` is live: `platform-admin.ts` calls it) |
| `source[7]` | `admin-routes.ts` line 261 = `export const
DATASOURCE_ADMIN_CAPABILITY = 'manage_platform_settings';` |
`packages/services/service-datasource/src/admin-routes.ts#manage_platform_settings,261
(the manage_platform_settings-floor probe)` |
`packages/services/service-datasource/src/admin-routes.ts#DATASOURCE_ADMIN_CAPABILITY
(the manage_platform_settings-floor probe)` | `declaration` (the old
`#manage_platform_settings` resolved only as a `literal`) |

The gate's extractor read the old strings as
`env.ts#PLATFORM_OWNER_EMAIL_ENV` and
`admin-routes.ts#manage_platform_settings`, and ignored `,200` and
`,261`. That is why no gate caught the residue. Only `source[5]` and
`source[7]` moved: #24465 (queued) re-authors other fields of this item.

## Part (c): the walled boot's release attribution

**Measurement.** Is `serve.ts#walledPostureRefusal` present in each
published `@objectstack/cli` 18.0.0 prerelease? Each was read in its npm
tarball (`npm pack`, then a grep of `package/dist`) and at its version
tag. The repo is not shallow.

| version | npm publish time | tag commit | `walledPostureRefusal` in
`serve.ts` at the tag | dist files with `is not supported in 18.0
(NOT_IMPLEMENTED)` | `ae6bd1a6` an ancestor of the tag |
|:--|:--|:--|:--|:--|:--|
| `18.0.0-next.0` | 2026-10-13T08:29Z | `d889448b93` | 0 | 0 | exit 1 |
| `18.0.0-next.1` | 2026-10-14T11:59Z | `0c52e43075` | 0 | 0 | exit 1 |
| `18.0.0-next.2` | 2026-10-16T03:06Z | `e5136ff10f` | 0 | 0 | exit 1 |
| `18.0.0-next.3` | 2026-10-17T09:10Z | `2c9bf9430a` | 0 | 0 | exit 1 |
| `18.0.0-next.4` | never published (not in `npm view @objectstack/cli
versions`, no tag) | — | — | — | — |
| `18.0.0-next.5` | 2026-10-19T11:06Z | `820fd5aef0` | 2 | 1 (2 files
carry the symbol) | exit 0 |
| `18.0.0` | not published; ruling record `6282882793` item 1: only
after steps 4 to 7 merge | — | — | — | — |

- On `main` the refusal lived from `ae6bd1a696` (#24480,
2026-10-19T06:49Z) to `fc34d000fc` (PR #24667, 2026-10-20T03:59Z), by
`git log -S walledPostureRefusal origin/main --
packages/cli/src/commands/serve.ts`. At this base `serve.ts` holds 0
occurrences.
- Control leg for every exit 1: the `@objectstack/cli@17.7.0` tag commit
`4e4e881427` (2026-10-06, older than both commits tested) answers exit 0
against all five tags.
- `fc34d000fc` is an ancestor of none of the five tags (exit 1 ×5, with
the same control), so nothing has been published since step 4.
- **PM hypothesis 2 is falsified:** only `next.5` carries the refusal,
and there is no `next.4`. "Every 18.0.0 prerelease" would be wrong.

**Edits.** Hypothesis 3 is also falsified: the eight places use three
phrasings, so there are three rewrites. Each rewrite changes only the
attribution, and #24580 stays the change's reference.

| place | was | now |
|:--|:--|:--|
| `RUNNER.md`, entry "A walled boot is a fixture of its own" | "18.0
refused a walled posture at boot; 18.x step 4 (#24580) removed that
refusal, so" | "18.0.0 boots a walled posture: under ruling record
6282882793 on the v18 epic it is published only after 18.x step 4
(#24580) has merged, and step 4 deleted the boot refusal
(`walledPostureRefusal()` in `packages/cli/src/commands/serve.ts`). Of
the builds published so far, only the `18.0.0-next.5` prerelease carries
that refusal, as `main` did from `ae6bd1a6` until step 4: `next.0` to
`next.3` predate it, and no `next.4` was published. So on 18.0.0" |
| the six items below, one `fixtures.knownGaps` line each
(byte-identical sentence) | "Since 18.x step 4 (#24580) os serve — and
os dev / os start, which boot through it — boots
OS_TENANCY_POSTURE=group\|isolated (and the legacy
OS_MULTI_ORG_ENABLED=true): the 18.0 refusal (serve.ts
walledPostureRefusal) is deleted." | "On 18.0.0 os serve — and os dev /
os start, which boot through it — boots
OS_TENANCY_POSTURE=group\|isolated (and the legacy
OS_MULTI_ORG_ENABLED=true): 18.x step 4 (#24580) deleted the walled boot
refusal (serve.ts walledPostureRefusal) before 18.0.0, and of the
published prereleases only 18.0.0-next.5 carries it." |
| `attachments-storage.chunked-upload-integrity` `fixtures.knownGaps[0]`
| "Since 18.x step 4 (#24580) a walled boot provisioned per" | "On
18.0.0, where 18.x step 4 (#24580) has deleted the walled boot refusal
that of the published prereleases only 18.0.0-next.5 carries, a walled
boot provisioned per" |

The chunked-upload line never said 18.0 refused. It dated the walled
boot only "Since 18.x step 4", so it told neither runner which release
it is on. That is why it was not left alone.

| item | field | revision |
|:--|:--|:--|
| `access-security.walled-environment-metadata-operator-only` |
`fixtures.knownGaps[0]` | 3 → 4 |
| `access-security.activation-write-operator-gate` |
`fixtures.knownGaps[0]` | 6 → 7 |
| `access-security.grant-table-write-contract` | `fixtures.knownGaps[0]`
| 4 → 5 |
| `access-security.parent-and-organization-write-guards` |
`fixtures.knownGaps[0]` | 3 → 4 |
| `access-security.no-active-org-session-semantics` |
`fixtures.knownGaps[2]` | 4 → 5 |
| `platform-core.settings-organization-isolation-and-platform-rung` |
`fixtures.knownGaps[0]` | 3 → 4 |
| `attachments-storage.chunked-upload-integrity` |
`fixtures.knownGaps[0]` | 5 → 6 |
| `access-security.platform-owner-email-anchor` (part b) | `source[5]`,
`source[7]` | 5 → 6 |

**How the edits were made.** The area files went through round 9's
span-recording editor (`r9-edit.mjs`, md5
`e1385d0fbc102efb2a9507dad5133089`), extended with a `replace` op that
asserts its prior text occurs exactly once in the leaf. It re-parses
each file and asserts four things: the new document equals the old one
with the declared ops applied; every other item and top-level key is
value-equal; the changed leaf paths are the declared field plus
`revision` plus one new `history` row; and the text outside the edited
items is byte-identical. Its reported changed paths matched the
declarations for all 8 items. The `RUNNER.md` edit asserted that its one
replaced line occurs exactly once and that the text on either side is
byte-identical. The control-byte scan of the 4 files reads 0.

## Left alone, and why

- `platform-core.v18-boot-refusals`, `areas/cli.json` and every "18.0
supports fresh installs only" sentence: PR #24681 (steps 5 and 6, open)
edits them, and the claim excludes them.
- `platform-owner-email-anchor`'s other fields, its walled `steps[0]`
parenthetical included: #24465 re-authors them. That parenthetical names
no release; it says a walled posture boots once provisioned, which
holds.
- The old attribution in `history` rows (revisions written by #24687 and
PR #24667 on these items): history is append-only, and each new row
records the correction.
- `RUNNER.md`'s "A stock `single` boot holds exactly one organization"
entry: it names no release.
- Part (a): no entry, for the reason in its table.

## Gates

- Derived with `node scripts/pm/dispatch-gates.mjs --commands --repo
objectstack-ai/objectstack`, no paths (4 paths against merge base
`795ff708d`): 13 families, the same list at `9a85df9a8c` and at
`8bfefd50f5`. All 13 ran on `9a85df9a8c`, each exit code captured before
any pipe, and all exited 0. They are re-run on the final head (after the
`ref` fill), and those readings go in the card's report. The 13:
`check-ci-filter-parity`, `check-closing-keyword-parity` (and its
`--self-test`), `check-comment-mask-corpus`,
`check:doc-formula-expressions`, `check:cross-package-test-inputs`,
`check:doc-authoring`, `check:driver-memory-census`,
`check:gitlink-declared`, `check:nul-bytes`, `check:platform-checklist`,
`check:refd-timer-probe` and `check:watch-hint-literal`.
- `check:doc-formula-expressions` first exited 3 (PREREQUISITE NOT MET:
`@objectstack/formula` unbuilt). After `os-verify-lock.sh -c 'pnpm exec
turbo run build --concurrency=2 --filter=@objectstack/formula
--filter=@objectstack/lint'` (VERDICT command-exit 0) it exited 0.
- `--ran`: "13 derived famil(ies) accounted for — 13 run, 0
NOT-MEASURED".
- `check:platform-checklist` runs in no per-PR CI, so this reading is
its evidence:
- at `795ff708d8`: "OK — 16 areas, 328 items", "line citations: 0
survive across 21 swept documents", "symbol anchors: 942/952 resolved",
10 on the residual, 18 file floors held;
- at `9a85df9a8c`: the same, with "symbol anchors: 943/953 resolved".
The one new anchor is `env.ts#resolvePlatformOwnerEmail`.
- `git merge-tree --write-tree HEAD b5010d9` (PR #24681's head,
fetched from `pull/24681/head`): exit 0 at `9a85df9a8c` (tree
`8476465619`), and exit 0 again at `8bfefd50f5` (tree `12cf869ead`). No
path here is routed to the `os-regen` driver. #24681 touches
`platform-core.json` (item `v18-boot-refusals`) and `cli.json`, which
are item-disjoint from this PR.

## Acceptance notes

- #24615's line 170 attributes the warning to the cwd. Part (a) measures
that the same warning comes from an unbuilt console in the booting
checkout. This is a correction to a QA record's explanation, noted here
and on the card, not filed.
- No changeset: `docs/qa/**` ships in no package. The root package is
private, and no published manifest's `files[]` names `docs/qa` (control:
73 published manifests name `dist`). So the PR carries `skip-changeset`.

---
_Generated by [Claude
Code](https://claude.ai/code/session_01FM29ZqLTrnPNXxijioZwMp)_

---------

Co-authored-by: Claude <noreply@anthropic.com>

Author: objectstack-fleet[bot]

docs/qa/platform-checklist/RUNNER.md

@@ -458,7 +458,12 @@ contradicts it, and correct it here when it does.
 
 - **A walled boot is a fixture of its own: `os serve` boots `group` and `isolated` once the
   walled prerequisites are provisioned, and the stock showcase provisions none of them.**
-  18.0 refused a walled posture at boot; 18.x step 4 (#24580) removed that refusal, so
+  18.0.0 boots a walled posture: under ruling record 6282882793 on the v18 epic it is
+  published only after 18.x step 4 (#24580) has merged, and step 4 deleted the boot refusal
+  (`walledPostureRefusal()` in `packages/cli/src/commands/serve.ts`). Of the builds published
+  so far, only the `18.0.0-next.5` prerelease carries that refusal, as `main` did from
+  `ae6bd1a6` until step 4: `next.0` to `next.3` predate it, and no `next.4` was published.
+  So on 18.0.0
   `OS_TENANCY_POSTURE=group` or `isolated` (or the legacy `OS_MULTI_ORG_ENABLED=true`, which
   `resolveTenancyPosture()` in `packages/types/src/env.ts` reads as `isolated`) boots through
   `os serve`, and so `os dev` and `os start`. Each prerequisite below refuses the boot with a