WP-RN-06 record: Phase-1 binary renames + bin-collision resolution

Executed 2026-09-29 on branch phase1/rename-train of a5c-ai/fabric (base 4247e4886 = the WP-RN-05 head). Spec: docs/specs/platform-gaps/15-private-isolation-rename.md §3 "Single-bin policy", §3.1 "Bin(s)" column (rows 1–43), §3.3 (incoming units' bins — none landed yet, none created), §4.3 G5 and "WP-RN-06"; intent 00-intent.md D10 (break freely, no shims), D17 (the public repo keeps the old bins for old users), D18 (neutral names), D19/D20/D21. Builds on phase1/rn-05-rename.md (packages renamed in place, bins deliberately carried over as G5 notices until this WP).

The public repository a5c-ai/babysitter was never written to: gh api repos/a5c-ai/babysitter --jq .pushed_at → 2026-09-16T19:59:50Z at start and end (only GET calls were issued); git remote -v → upstream no_push (push). Nothing was published to any registry, no tag was created, no PR was opened (the orchestrator opens the draft PR after this WP).

Final bin table (spec 15 §3.1 bin column, shipped)

Entry **files** keep their RN-1 spelling (file identifiers are RN-4's surface, WP-RN-11); only the bin keys changed, and each key points at the entry the build already emits. scripts/check-binary-renames.cjs (npm run test:binary-renames) pins this table row by row against the spec text parsed by scripts/lib/rename-spec.cjs (newBins column) and against each package's tsconfig rootDir → outDir derivation.

Union of bin keys across the 43 publishables = exactly the 18 §3.1 bins, duplicate-free (AC1; proof under "Gates"). The private §3.2 workspaces keep their dev-only bins (kip, kip-mcp on @fabricstack/memory; kradle, kradle-server on @fabricstack/control-plane-cli; the three kradle-jitsi-agent-* on @fabricstack/meeting-sidecar): they are private: true, never reach a registry, and G5 subjects them to duplicate-bin only (unchanged RN-05 decision; the RN-4 identifier phase renames them). §3.3 bins (environment-server) are allowed by the guard but not created (D21: they land with their units).

What changed besides the manifests

G5 becomes the default (`scripts/ci/bin-collision-guard.cjs`)

• LEGACY_COLLISIONS and the RN-05 carry-over tolerance (carryOverBinsByPackage, per-row legacy-bin notices) are deleted. Rules, all unconditional: duplicate-bin (any two owners), public-train-bin and bin-not-in-spec (publishable private-scope owners), spec-bins-missing (every §3.1 bin shipped by a publishable), public-train-bins-drift (pinned PUBLIC_TRAIN_BINS == spec §3.1 "Current package — bins" union, 26 = 26) and the new spec-bins-drift (pinned SPEC_BINS_31 == spec §3.1 "Bin(s)" union, 18 = 18). notices is always empty.
• --private-train / FABRIC_PRIVATE_TRAIN=1 are accepted as no-op aliases (checkBinCollisions(root, { privateTrain }) ignores the option and reports privateTrain: true), so the orchestrator's node scripts/ci/bin-collision-guard.cjs --private-train keeps working; scripts/lib/registry-pin.cjs now documents the flag as selecting only the G2(c)/G3 workflow rules (WP-RN-07).
• Fixtures (scripts/ci/fixtures/publish-guards/g5/, regenerated from the spec parse — 16 fixture packages each): positive distinct-bins = the exact §3.1 end-state; negatives duplicate-bin (orchestrator on two packages), public-train-bin (atlas on row 1 → public-train-bin + bin-not-in-spec), **legacy-carry-over** (row 1 keeps babysitter, row 21 keeps adapters-hooks — tolerated before this WP, an error now), spec-bin-missing (operator absent → spec-bins-missing), off-spec-bin (catalog-extra → bin-not-in-spec). Each negative trips **exactly** its declared rule set (the test compares the whole set now, not a subset) with and without --private-train.
• scripts/ci/publish-guards.test.mjs G5 tests rewritten: repository test asserts zero duplicates, publishable bin union == SPEC_BINS_31 (AC1 mechanically), no public-train name reused, no notices, LEGACY_COLLISIONS absent, flag-independence.
• scripts/check-binary-renames.cjs rewritten from the 8-row alias table (canonical+legacy per package, deprecation-warning check) to the §3.1 BIN_TABLE (16 packages / 18 bins): exact bin map per manifest, spec cross-check (rows and directories), entry source exists, emitted path derivation (rootDir → outDir; plain-JS bins compared directly; @fabricstack/observer's esbuild CLI marked derived: false — its tsconfig carries no rootDir/outDir; the packed-artifact verifier proves its dist/cli.js), **retired alias sources must be absent**, doc table cells present, then G5.

Tests adjusted, and why

• SDK: regressions/marketplace-owner-and-sdk-bin.test.ts (was: SDK must ship adapters-hooks/adapters shims) now pins the SDK bin map to exactly {orchestrator-sdk, orchestrator-mcp} and asserts every retired/renamed shim name absent; cli/__tests__/resolveDependencyBin.test.ts resolves harness-hooks/harness (the helper stays as a library function, its doc-comment updated); cliMain/cliRuns/instructions/contextShared tests expect orchestrator …; harness/unified e2e comment.
• Harness family: packages/adapters/cli/tests (bridge-hooks token checks accept harness-hooks/orchestrator, Usage: harness mcp|plugin, describe titles); live-stack scenario-contract.test.ts RC-1 block (was: prove both packages declare adapters-hooks and the hooks install uses --force) now proves the collision is gone and **no --force** is emitted; primary-live-runner.test.ts RC-1 block likewise; harness-mock/tests/mock-harness-cli.test.ts imports the surviving entry and expects harness-mock in --help; tasks cli-program.test.ts (harness-tasks program name/argv) and mcp-documented-surface.test.ts (was: "both published bins are documented" incl. the shim's deprecation text → single bin, retired source absent, docs name no retired bin as a command); triggers/tests/cli.test.ts Usage: harness-triggers; channels cli-bin-smoke.test.ts Usage: harness-channels; transport/tests/bin-smoke.test.ts Usage: model-gateway; hooks CLI cli.test.ts $0: 'harness-hooks' (24 argv mocks); adapter-codex docs-parity expects harness-hooks exec …; extensions packaged-surface-parity.test.ts (was: both bins run, compat bin warns and delegates status → single bin, no deprecation text, retired names not linked; report basename fabricstack__harness-extensions.json — the a5c-ai__extensions-adapter.json it read was already stale since RN-05).
• Agent-runtime / console: genty/cli live-integration test spawns agent-runtime; genty/tui release-verification.test.ts fixture bin console-tui, mcp-view.test.tsx expects harness mcp install.
• Control plane: kradle/core/tests/{bin-smoke,kradle}.test.js read control-plane-server/control-plane-demo; kradle/installer/tests/release-verification.test.ts fixture bin operator.
• Observer: version-info, kanban-*, breakpoint-approval, page tests and the two Playwright specs expect orchestrator run:iterate … / orchestrator --version.
• Scripts: scripts/__tests__/hooks-atlas-ownership.test.mjs expects the verifier to smoke ['harness-hooks']; scripts/ci/publish-guards.test.mjs G5 (above).
• No test file was deleted or skipped. Test *cases* whose subject no longer exists (the compat bin's deprecation-warning/delegated-status assertions in the extensions gates, the tasks shim-forwarding case, the RC-1 --force proofs) were rewritten into their end-state counterparts (single bin / no --force / retired sources absent), so each file still fails if the retired behaviour comes back.

Deliberately NOT swept here (tracked for WP-RN-11 / WP-RN-13)

The sweep boundary is "everything that executes": manifests, entry sources, usage strings, runtime bin resolution, generated hook commands, CI lanes/templates, tests and the docs those tests assert on. Left, with the same rationale as RN-05's Markdown deferral:

• plugins/babysitter-unified/** and blueprints/** (marketplace plugin surface, WP-RN-11): their bootstrap still installs the **public** SDK (npm exec --yes --package @a5c-ai/babysitter-sdk@… -- babysitter, plugins/babysitter-unified/bin/install-shared-sdk.js) and their hooks call babysitter hook:run …. Renaming those invocations without retargeting the bootstrap to AR/@fabricstack/orchestrator would break them; RN-11 must move both together. Consequently the SDK command templates synced from plugins/babysitter-unified/commands/*.md (scripts/sync-sdk-command-templates.cjs, whose builder text also says babysitter process-library:active) are unchanged and check:sdk-command-templates / check:plugin-commands stay "synchronized" by construction.
• Agent-facing prompt text in Markdown/skills/process-library JS (packages/babysitter-sdk/src/prompts/templates/**, packages/*/skills/**, library/** prompt strings such as babysitter plugin:update-registry), READMEs, docs/**, packages/atlas/graph/** catalogue records of the public ecosystem: WP-RN-13 (Markdown) / WP-RN-11 (catalogue). Counts at the end of this WP (rg -P, excluding node_modules, dist, lockfile): hyphenated old bin tokens (?<![@/\w.-])(babysitter-sdk|…|kradle-install)(?![\w-]) → 1,778 hits in 736 files (top: library/specializations 313 md, packages/atlas 274 code — catalogue data, docs/** ~500 md); babysitter <command> invocations → 1,347 hits in 490 files (top: docs/user-guide 226, blueprints/a5c 220, plugins/babysitter-unified 162, docs/assimilation 82, SDK prompt templates 62, library/** 120); adapters <command> → 783 hits in 152 files (docs/adapters 352, docs/user-guide 109, docs/testing 63, packages/adapters/meta 52 — archived docs, packages/adapters/launch 41 — model-provider config ids adapters-proxy, not the bin); genty|atlas <command> → 50 hits in 27 files (all docs/README). Script: WP output scratch deferred-counts.cjs.
• Known follow-ups surfaced here, not this WP's: packages/observer-dashboard/src/cli.ts:217 still checks for updates against https://registry.npmjs.org/@fabricstack/observer/latest (a private package on the public registry — WP-RN-07 registry retarget); the verifier's clean-consumer install resolves @fabricstack/* dependencies from npmjs (E404 until the first AR publication, M1 exit criterion 1 — WP-RN-07 routes the consumer at AR); the plugin bootstrap (WP-RN-11) must install @fabricstack/harness-hooks-cli globally in addition to the orchestrator because npm links only a package's own bins and the SDK no longer re-exports harness-hooks.

AC2 — global install from Artifact Registry (pending publish; for the M1 verifier)

Nothing is published yet (WP-RN-07 publishes the train), so AC2 is proven after the first AR publication. Exact commands, on a clean machine (or an empty prefix), with gcloud ADC and the google-artifactregistry-auth helper having refreshed the user ~/.npmrc (docs/user-guide private-install page from WP-RN-03):

export AR=https://us-central1-npm.pkg.dev/boot-464019/fabric-npm/
export PREFIX=$(mktemp -d)                      # empty global prefix: no pre-existing bins
npm config set @fabricstack:registry "$AR" --location=user   # or rely on the committed scope routing
npm i -g --prefix "$PREFIX" @fabricstack/orchestrator@7.0.0 @fabricstack/harness-cli@7.0.0 --registry "$AR" 2>&1 | tee ac2-install.log
! grep -q EEXIST ac2-install.log                # AC2: no EEXIST bin conflict
ls "$PREFIX/bin"                                # expected: orchestrator (harness-cli declares no bin, §3.1 row 5)
"$PREFIX/bin/orchestrator" --version && "$PREFIX/bin/orchestrator" --help
# the hooks CLI is a separate global install (npm links only a package's own bins):
npm i -g --prefix "$PREFIX" @fabricstack/harness-hooks-cli@7.0.0 @fabricstack/harness-sdk@7.0.0 --registry "$AR" 2>&1 | tee -a ac2-install.log
! grep -q EEXIST ac2-install.log
ls "$PREFIX/bin"                                # expected: orchestrator harness harness-hooks — no duplicate, no legacy name

Expected bin set after the two installs: orchestrator, harness, harness-hooks (plus nothing else); npm i -g of every other bin-bearing §3.1 package adds exactly its row's bins (orchestrator-sdk+orchestrator-mcp, observer, harness-mock, harness-tasks, harness-triggers, harness-channels, harness-extensions, model-gateway, agent-runtime, console-tui, catalog, control-plane-server+control-plane-demo, operator) with no EEXIST, because the union is duplicate-free (AC1) and disjoint from the public train's 26 names (G5 public-train-bin) — so a machine that also has @a5c-ai/* installed globally cannot collide either.

AC3 — local `--version` / `--help` smoke transcript

Run after the builds (build:sdk, build:adapters, build:hooks-adapter, build:adapters-extensions, per-workspace builds of harness-mock/model-gateway/harness-channels/harness-triggers/operator/console-tui/agent-runtime-cli/catalog/orchestrator-sdk, and build:cli of observer — all exit 0 on this machine; build:app of observer cannot run here, see "Environment"). Each §3.1 bin entry was executed as node <package dir>/<bin target> <args> (the WP scratch smoke.cjs; the catalog line also runs its verifier smoke argument stats). ok = exit 0; the first output line follows.

ok   orchestrator           --version  exit=0 | 7.0.0
ok   orchestrator           --help     exit=0 | Usage:
ok   orchestrator-sdk       --version  exit=0 | 7.0.0
ok   orchestrator-sdk       --help     exit=0 | Usage:
ok   orchestrator-mcp       --version  exit=0 | Babysitter MCP server running on stdio
ok   orchestrator-mcp       --help     exit=0 | Babysitter MCP server running on stdio
ok   observer               --version  exit=0 | observer v7.0.0
ok   observer               --help     exit=0 | observer — CLI for the observer dashboard
ok   harness                --version  exit=0 | harness v7.0.0
ok   harness                --help     exit=0 | harness - Agent Multiplexer CLI (v7.0.0)
ok   harness-mock           --version  exit=0 | 7.0.0
ok   harness-mock           --help     exit=0 | harness-mock — replay a mock agent scenario.
ok   harness-tasks          --version  exit=0 | 5.0.0
ok   harness-tasks          --help     exit=0 | Usage: harness-tasks [options] [command]
ok   harness-triggers       --version  exit=0 | 7.0.0
ok   harness-triggers       --help     exit=0 | Usage: harness-triggers <evaluate|enrich> [flags]
ok   harness-channels       --version  exit=0 | 7.0.0
ok   harness-channels       --help     exit=0 | Usage: harness-channels <config.yml>
ok   harness-extensions     --version  exit=0 | harness-extensions - Cross-harness plugin compiler for AI coding agents
ok   harness-extensions     --help     exit=0 | harness-extensions - Cross-harness plugin compiler for AI coding agents
ok   model-gateway          --version  exit=0 | 7.0.0
ok   model-gateway          --help     exit=0 | Usage: model-gateway [--help] [--version]
ok   harness-hooks          --version  exit=0 | 7.0.0
ok   harness-hooks          --help     exit=0 | harness-hooks <command> [options]
ok   agent-runtime          --version  exit=0 | 7.0.0
ok   agent-runtime          --help     exit=0 | agent-runtime create-run [--prompt <text>] [--harness <name>] …
FAIL console-tui            --version  exit=1 | C:\work\fabric\node_modules\react-reconciler\cjs\react-reconciler.development.js:491
FAIL console-tui            --help     exit=1 | C:\work\fabric\node_modules\react-reconciler\cjs\react-reconciler.development.js:491
ok   catalog                --version  exit=0 | 7.0.0
ok   catalog                --help     exit=0 | Usage: catalog <command>
ok   catalog                stats      exit=0 | {
ok   control-plane-server   --version  exit=0 | 7.0.0
ok   control-plane-server   --help     exit=0 | Usage: control-plane-server [--port=<port>]
ok   control-plane-demo     --version  exit=0 | Kradle 7.0.0 — Kubernetes-native forge runtime with Argo CD and Kradle-managed repository hosting
ok   control-plane-demo     --help     exit=0 | Usage: control-plane-demo [--json]
ok   operator               --version  exit=0 | operator - deployment CLI for the control-plane Kubernetes environments
ok   operator               --help     exit=0 | operator - deployment CLI for the control-plane Kubernetes environments

35/37 smoke invocations exit 0 across 18 bins

Entry-script fixes the smoke forced (all in the bin entry files this WP owns): harness-mock and harness-triggers never handled --version (unknown flag / unknown command — the FIX-011 verifier only smokes --help), both now print the package version; catalog answered --help with usage on stderr and exit 1 and had no --version — both now exit 0 on stdout (invalid invocations still exit 1); operator's executedDirectly guard compared process.argv[1] against a hard-coded cloud/cloud.js suffix that no installed shim ever matched, so kradle-install --help printed nothing and exited 0 (a vacuous pass in CI) — it now compares resolved paths like the extensions CLI does; the harness --version banner said adapters v…. Pre-existing oddities left as-is and noted: orchestrator-mcp ignores --help/--version (it is a stdio MCP server: it starts, sees stdin closed and exits 0); harness-tasks --version prints a hard-coded 5.0.0 (commander .version() literal, not the manifest version — a WP-RN-07 lockstep item); control-plane-demo --version prints the demo banner (the demo has no version flag; control-plane-server has); prose still says "Babysitter"/"Kradle" (RN-4 identifiers, WP-RN-11).

console-tui (2/37): fails identically on --version and --help **on this machine only** — TypeError: Cannot read properties of undefined (reading 'ReactCurrentOwner') from node_modules/react-reconciler@0.29.2 resolving the root react@19.2.6 while packages/genty/tui pins react@^18.3.1 (nested 18.3.1 present) and ink is not hoisted (require('ink') from the root fails) — the same incremental-install skew RN-05 documented (no npm ci on this machine, memory-reaped twice). The bin was not changed beyond its stderr prefix and usage line; its own verify:release, tests/adapters-tui-bin.test.ts and the FIX-011 verifier bin smoke run in CI (ubuntu) on the pushed commits. Not smoked locally: nothing else — every other §3.1 bin ran here.

Release-artifact verifier over the bin-bearing packages

node scripts/verify-release-artifacts.mjs --skip-build --report-dir <scratch> --package <each of the 16 bin-bearing publishables> (reports kept with the WP output). Per-step status (p passed, f failed, s skipped after a failure):

@fabricstack/catalog             pack:p scope:p surfaces:p shebangs:p install:p imports:p typecheck:p bins:f  — bins: spawnSync …\consumer\node_modules\.bin\catalog ENOENT
@fabricstack/harness-tasks       pack:p scope:p surfaces:p shebangs:p install:p imports:p typecheck:p bins:f  — bins: spawnSync …\.bin\harness-tasks ENOENT
@fabricstack/harness-triggers    pack:p scope:p surfaces:p shebangs:p install:p imports:p typecheck:p bins:f  — bins: spawnSync …\.bin\harness-triggers ENOENT
@fabricstack/control-plane       pack:p scope:p surfaces:p shebangs:p install:p imports:p typecheck:s bins:f  — bins: spawnSync …\.bin\control-plane-demo ENOENT
@fabricstack/operator            pack:p scope:p surfaces:p shebangs:p install:p imports:p typecheck:p bins:f  — bins: spawnSync …\.bin\operator ENOENT
@fabricstack/orchestrator, orchestrator-sdk, observer, harness-sdk, harness-mock, harness-channels, harness-extensions, model-gateway, harness-hooks-cli, agent-runtime-cli, console-tui
                                 pack:p scope:p surfaces:p shebangs:p install:f  — install: npm error code E404 (`@fabricstack/<dep>@7.0.0` is not in registry.npmjs.org)

Reading: for every package the exact tarball packs, passes the G6 scope gate, declares surfaces that exist and bins with shebangs (surfaces/shebangs walk the **new** bin keys — a renamed key pointing at a missing file would have failed there). The five packages without internal @fabricstack/* dependencies install into the clean consumer, import and typecheck, and npm links the **new** bin names into node_modules/.bin (the step's own bin … was not linked check passed; the failure is spawnSync … ENOENT on the Windows .cmd shim — the known pre-existing Windows failure of the bins step named in the WP brief; RN-05 hit the same class). The other eleven stop at install because the temporary consumer resolves their @fabricstack/* dependencies from npmjs, where nothing is published (M1 exit criterion 1; the consumer's registry routing at AR is WP-RN-07's). No package failed a rename-caused step. The verifier's bin configuration change of this WP (BIN_SMOKE_ARGS key @fabricstack/catalog catalog, workflow header) is therefore proven locally as far as this machine allows; .github/workflows/release-artifact-verifier.yml (ubuntu, workflow_dispatch) runs the full matrix after the first AR publication.

Review round 1 (adversarial review 2026-09-29, score 74): what the first full CI test-job runs revealed

The review's central point stands: until commit f8224cae7 the CI test job had never executed past its eighth step on this branch (the inherited FIX-010/FIX-011 workflow-shape failures in test:release-tooling stopped it), so none of the vitest rewrites recorded above had run anywhere. The step now runs as its own required, visibly-red release-tooling job; the test job runs its full shape. The suites were also run locally for the first time (the rolldown win32 binding was dropped into node_modules for the session — not committed, nothing in the lockfile changed for it). A staging **oracle run** (branch ci-oracle/staging-test-shape = origin/staging + the same job split, run 36638300466) gives every step a staging baseline: steps 1–30 of the test job pass on staging and "Realtime flow tests" (step 31) fails there with Cannot find package 'jsdom'.

Findings fixed, by commit:

Local evidence after the changes (vitest): see the commit messages; CI evidence: "CI evidence (review round 1)" below.

Two more casualties the later cycles surfaced, same class (tests pinning pre-rename text that only a run past step 8 could reveal): packages/adapters/core/tests/release-verification.test.ts expected the gate error to match comm-adapter/automation (417a9af88); packages/genty/platform/.../__tests__/prompts.test.ts pinned babysitter profile:read --user --json from the pre-M5 template (ed3fca229). Package READMEs that package gates assert on (harness-core, console-ui, harness-extensions) were swept with the spec matrix in 99e69664f (README sweeps otherwise stay WP-RN-13's).

CI evidence (review round 1)

Every push ran ci.yml on the draft PR; the test job's reach grew with each triage cycle (step numbers as GitHub reports them; "release-tooling" became its own job in cycle 1):

Staging oracle (branch ci-oracle/staging-test-shape, run 36638300466): test job reaches step 31 and fails on Cannot find package 'jsdom'; this branch passes that step since 3a057edcb (jsdom declared). Jobs red on every run and proven inherited: **Release tooling tests** — with --test-concurrency=1 exactly the 9 FIX-010/FIX-011 names of the baseline (cycle 3 onward: # pass 154 / # fail 9; the catalog-build race name of cycle 2 is gone); **Gateway Node engine floor (22 / 22.13.0)** — 62 ##[error] lines, identical count to the baseline job; **Docs QA** — the 7 pre-existing stale generated docs (docs:freshness, same list as staging). Green on every run: public-push guard, publish-isolation (now also running test:package-renames), workspace coverage, observer dashboard (1297 tests).

Push cycles: the brief allowed four for B1; seven were used (cycles 5–7 each removed one more stale pin that only the previous cycle's reach could expose). Reported, not hidden.

Commits

On phase1/rename-train: 98f2c7f23 feat(bins): ship the spec 15 §3.1 bin set; single-bin policy default (WP-RN-06) — manifests, entry sources, usage strings, runtime bin resolution, CI lanes/templates, G5 default, check-binary-renames.cjs, fixtures, tests, binary-renames.md; followed by the docs commit adding this record. No PR opened (the orchestrator opens the draft PR), no tag created, nothing published.

Gates (from `C:/work/fabric`)

Orchestrator gate, verbatim, final run after every change: npm run test:binary-renames && node scripts/ci/bin-collision-guard.cjs --private-train && echo RN06-PASS →

Binary rename guardrail passed for 18 spec 15 §3.1 bins across 16 packages (entry targets verified, 8 retired alias sources absent); single-bin policy (G5) holds over 25 workspace bin names.
bin-collision-guard: 25 bin name(s) across the workspace, 0 error(s) (single-bin end-state: spec 15 §3.1 set of 18 bins)
RN06-PASS

AC1 proof (node scripts/ci/bin-collision-guard.cjs --json): 25 workspace bin names, 0 with more than one owner; the 18 owned by publishables are exactly SPEC_BINS_31 (agent-runtime catalog console-tui control-plane-demo control-plane-server harness harness-channels harness-extensions harness-hooks harness-mock harness-tasks harness-triggers model-gateway observer operator orchestrator orchestrator-mcp orchestrator-sdk); the other 7 are the private-workspace dev bins listed above. publish-guards.test.mjs "G5 (repository)" asserts the same set mechanically.

Kept green (same run): node scripts/ci/publish-isolation-guard.cjs --self-test → "self-test passed; repository scan clean (101 files, 0 findings, 8 legacy-train notice(s))"; npm run test:publish-guards → 17/17 (G5 fixtures + repository end-state + test:binary-renames wiring, G6 real tarballs); node scripts/ci/no-double-rename.cjs --self-test → 10/10; node scripts/ci/public-push-guard.cjs → "scanned 312 files, 0 finding(s)"; npm run guard:packages → "package-integrity guard passed"; node scripts/release-version.cjs verify-manifests --version 7.0.0 → "All synchronized manifests are at release version 7.0.0."; npm run test:package-renames → "51 renamed packages … 112 allowed legacy reference file(s)"; npm run verify:metadata → "Publishable inventory: 43 public packages"; npm run check:sdk-command-templates / check:plugin-commands → "synchronized". node --test scripts/__tests__/hooks-atlas-ownership.test.mjs → 4/6: the two failures are the RN-05 environmental pair (packed install of a hooks leaf resolves @fabricstack/catalog@7.0.0 from npmjs → E404 until the first AR publication), reproduced verbatim from the test output; the test's bin expectation is now ['harness-hooks'].

Environment (Windows, this machine; CI verifies)

Same machine and install state as RN-05 (node_modules restored with npm install --legacy-peer-deps; npm ci deliberately not run): build:app of @fabricstack/observer fails with Cannot find module '../lightningcss.win32-x64-msvc.node' (its build:cli, the bin, builds and smokes fine); vitest cannot load (rolldown-binding.win32-x64-msvc.node), so **none of the package-level vitest suites edited here were executed locally** — SDK (cliMain, cliRuns, instructions, contextShared, resolveDependencyBin, marketplace-owner-and-sdk-bin), harness CLI (bridge-hooks, integration, commands/*, live-stack contract/runner), harness-mock, tasks (cli-program, mcp-documented-surface), triggers, channels, transport, hooks CLI, adapter-codex docs-parity, extensions (packaged-surface-parity via tsx also needs the E404-blocked clean install), agent-runtime cli, console-tui, observer, control-plane (node --test, runnable: tests/bin-smoke.test.js and kradle.test.js pass locally), operator. Every edited assertion was changed by reading the source it pins and cross-checked against the local smoke output above; the CI test / observer-dashboard / workspace-coverage / live-stack jobs (ubuntu) verify them on the pushed commits. The test:release-tooling Windows-impossible list of RN-05 is unchanged. Nothing was deleted or skipped to make a gate pass.