Staging deploy regressions after the Phase-0 / Phase-1 merges (publish.yml)

Executed 2026-10-05 on branch fix/staging-deploy-regressions of a5c-ai/fabric (base dc0364001 = origin/staging after PR #5). Scope: the two jobs of .github/workflows/publish.yml (the **push-to-staging deploy pipeline**, not a PR check) that have been red since the rename train landed — "Deploy Kradle To GKE" and "Validate Adapter Surfaces". Fix-forward PR: https://github.com/a5c-ai/fabric/pull/7.

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). Nothing was published to any registry, no tag was created, no workflow was enabled/disabled, and the npm train workflows (publish-npm-private.yml and friends — PR #6's domain) were not touched.

Evidence

Per-job logs were pulled with gh api repos/a5c-ai/fabric/actions/jobs/<id>/logs (jobs 111418339409 / 111418569406 for the failing run, 108662310726 / 108662886244 for the last green run) and diffed line-by-line for the noise questions below.

Regression 1 — `Deploy Kradle To GKE :: Build and push adapters-agent image`

Symptom

Inside docker buildx build --file packages/adapters/cli/Dockerfile ., step RUN npm ci --force:

npm warn ERESOLVE overriding peer dependency
npm warn   peer vitest@">=5.0.0 <6.0.0" from @effect/vitest@4.0.0-rc.115
npm warn Conflicting peer dependency: vitest@5.0.3
npm error code EUSAGE
npm error `npm ci` can only install packages when your package.json and package-lock.json ... are in sync.
npm error Missing: search-insights@2.17.3 from lock file
npm error Missing: @anthropic-ai/sdk@0.131.0 from lock file
npm error Missing: standardwebhooks@1.1.1 from lock file
npm error Missing: @stablelib/base64@1.0.1 from lock file
npm error Missing: fast-sha256@1.3.0 from lock file

Root cause

package-lock.json is a **legacy-peer-deps lockfile**: every place that consumes it does so with legacy peer resolution — ci.yml runs npm ci --prefer-offline --legacy-peer-deps, and publish.yml sets NPM_CONFIG_LEGACY_PEER_DEPS: "true" at workflow level (line 33), so its host-side npm ci --force steps are legacy-peer-deps installs too. In legacy mode npm never auto-installs peer dependencies, so the lock has no entries for the peers of @docsearch/react (search-insights), @anthropic-ai/claude-agent-sdk (@anthropic-ai/sdk), etc. — grep '"node_modules/search-insights"' package-lock.json → 0 hits.

A Docker build does not inherit workflow env. The Dockerfile's RUN npm ci --force therefore runs with *non*-legacy peer resolution. That was harmless until WP-T3-32 (Phase 0, commit 5d16b830e) added @effect/vitest@4.0.0-rc.115, whose peer range vitest >=5 <6 conflicts with the repo's vitest@4.1.6. The invalid peer edge forces arborist to re-resolve the peer set during npm ci's lock-vs-ideal-tree validation, which now demands the five peer packages the lock never carried → EUSAGE. The host jobs never see this because the env var puts them in legacy mode; the image build is the only non-legacy npm ci in the pipeline.

Reproduced locally (Windows, node v22.22.0 / npm 10.9.4, clean worktree of dc0364001, no node_modules):

Fix

packages/adapters/cli/Dockerfile: RUN npm ci --force → RUN npm ci --legacy-peer-deps, with a comment explaining the contract. patches/ is in the build context (Dockerfile.dockerignore only excludes node_modules, .git, dist, caches), so the root postinstall: patch-package --error-on-fail keeps running inside the image exactly as on the host (effect@4.0.0-rc.115 ✔); no --ignore-scripts needed.

The host-side npm ci --force lines in publish.yml (lines 96, 232, 305, 399, 486, 546, 607, 899, 1313) are left as they are: they are correct under the workflow-level NPM_CONFIG_LEGACY_PEER_DEPS, they are exercised on every push, and changing nine install lines of a deploy pipeline that cannot be run locally is not a fix for anything that is broken.

Why PR CI missed it

ci.yml never builds the adapters-agent image; the Dockerfile is only built by publish.yml on push. The host-side installs in both workflows are legacy-peer-deps installs and pass.

"Artifact not found for name: build-all-dist" / "Kradle deploy missing required configuration"

Pre-existing and benign. "Deploy Kradle To GKE" has needs: [lint] only, so it starts before "Build All" has uploaded build-all-dist; the download step is continue-on-error: true and the next step prints "No build artifacts — kradle Dockerfiles build from source". The last green run (job 108662310726, lines 212/226) has the identical ##[error]Unable to download artifact(s): Artifact not found for name: build-all-dist and fallback message. The "missing required configuration" line is the *echo* of the step's script body inside the ##[group]Run … header (line 237 in the green run, 222 in the red one); the ::error:: itself was never emitted — the config check passed in both runs and the job went on to authenticate to GCP and build the kradle-controller image successfully.

Regression 2 — `Validate Adapter Surfaces :: adapters package tests`

Symptom

FAIL packages/adapters/codecs/tests/base-adapter-install.test.ts
  > AgentMuxRemoteAdapter transport-agnostic overrides
  > detectInstallation probes plain `adapters --version` via the spawner
AssertionError: expected false to be true

Root cause

WP-RN-06 (ed01994df, "runtime callers name the shipped bins") renamed the shipped bin adapters → harness and changed AgentMuxRemoteAdapter's default cliCommand to 'harness' (packages/adapters/codecs/src/adapters-remote-adapter.ts:46). It updated tests/adapters-remote-adapter.test.ts but not tests/base-adapter-install.test.ts, whose fake spawner still only answered adapters --version; detectInstallation() therefore saw exit code 1 and reported installed: false. The same source file also still reported path: 'adapters' and "adapters probe …" notes for a harness probe — a leftover of the same rename.

Fix

• packages/adapters/codecs/tests/base-adapter-install.test.ts: the test now answers and asserts harness --version (title, spawner match, calls[0].cmd), and additionally asserts res.path === 'harness'. No assertion was weakened; one was added.
• packages/adapters/codecs/src/adapters-remote-adapter.ts: detectInstallation() reports path: this.cliCommand and names the probed command in its notes instead of the hard-coded pre-rename adapters.

Running the *rest* of the step locally (it never got past codecs in CI, so nothing after it had been exercised on push since the rename) surfaced two more stale assertions of the same kind in the cli suite, fixed in the same commit:

• packages/adapters/cli/tests/commands-audit.test.ts:66 — --version is asserted against /adapters\s+v…/; the built CLI prints harness v7.0.0. Now /harness\s+v\d+\.\d+\.\d+/.
• packages/adapters/cli/tests/live-stack/primary-live-runner.test.ts:519 — expects the last recorded command of the credential-less run to be adapters; the runner (primary-live-runner.ts, already updated by the train) records harness. Now 'harness'.

packages/adapters/cli/tests/parse-args.test.ts:14 (result.command === 'adapters') is the adapters *subcommand* of the CLI, not the bin, and is correct as is.

Local run of the exact step command, node scripts/adapters-build.cjs test packages/adapters/codecs: before the fix 1 failed / 733 passed; after the fix **31 files, 735 tests passed**. The rest of the step was run the same way (observability, core, harness-mock, gateway, cli, sdk, channels, npm run test:unit --workspace=@fabricstack/harness-triggers) plus the two following steps (verify:release for harness-core and console-tui, model-gateway test + scorecard:migration): observability, harness-mock, gateway, sdk, channels, model-gateway test, scorecard:migration all green; cli green after the two assertion fixes below (commands-audit.test.ts + primary-live-runner.test.ts re-run via the step script: 2 files, 68 tests passed); core 982 passed with one Windows-only failure (pty-consumer.packaged.test.ts: spawnSync npm.cmd EINVAL, the same file passed in both CI runs); triggers test:unit 25/26 with one temp-dir ENOENT in dist-cli.smoke.test.ts and both verify:release scripts failing on Windows (spawnSync npm ENOENT, npm pack through a junctioned dist/) — those three are run on every PR by ci.yml on Linux and are green there.

Why PR CI missed it

ci.yml runs node scripts/adapters-build.cjs test packages/adapters/core only (line 652); the codecs/observability/harness-mock/gateway/cli/sdk/channels suites are exercised solely by publish.yml's "adapters package tests" step on push. The triggers unit tests, both verify:release scripts and the model-gateway suite *are* in ci.yml (lines 621, 636, 641, 886-887), so they were already covered on the PR.

"No adapter registered for agent \"claude\"" / "RunOptions.prompt is required and non-empty"

Pre-existing noise, not a defect: both are JSON error logs emitted by the negative-path tests packages/adapters/core/tests/client.test.ts:180 and :192 (the test asserts the AgentMuxError, the client logs it). The last green run's job 108662886244 has the identical two lines (921-922, version: 6.0.3); the red run has them at 940-941 (version: 7.0.0). The core suite itself passed in both runs (56 files, 985 tests).

Other push-only commands checked

grep over publish.yml for retired names: the only @a5c-ai/* workspace left is @a5c-ai/genty-web-app (lines 178, 438), which is still that package's real name (packages/genty/web-app/package.json); no npx adapters / bin/adapters / adapters launch invocations remain; the Dockerfile's prose mentions adapters launch … only as a description of the entrypoint wrapper. npm ci --force lines: see above. Guards run on the branch: node scripts/ci/public-push-guard.cjs (354 files, 0 findings), node scripts/ci/publish-isolation-guard.cjs --self-test (16/16, repository scan clean), js-yaml load of publish.yml (13 jobs), npm run guard:packages (passed).

Runs after merge

__POST_MERGE__