Agentic AI Atlasby a5c.ai
OverviewWikiGraphFor AgentsEdgesSearchWorkspace
/
GitHubDocsDiscord
iiRecord
Agentic AI Atlas · Staging deploy regressions after the Phase-0 / Phase-1 merges (publish.yml)
page:docs-specs-platform-gaps-phase1-staging-deploy-regressionsa5c.ai
Search record views/
Record · tabs

Available views

II.Record viewspp. 1 - 1
overviewarticlejsongraph
II.
Page JSON

page:docs-specs-platform-gaps-phase1-staging-deploy-regressions

Structured · live

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

Inspect the normalized record payload exactly as the atlas UI reads it.

File · wiki/docs/specs/platform-gaps/phase1/staging-deploy-regressions.mdCluster · wiki
Record JSON
{
  "id": "page:docs-specs-platform-gaps-phase1-staging-deploy-regressions",
  "_kind": "Page",
  "_file": "wiki/docs/specs/platform-gaps/phase1/staging-deploy-regressions.md",
  "_cluster": "wiki",
  "attributes": {
    "nodeKind": "Page",
    "sourcePath": "docs/specs/platform-gaps/phase1/staging-deploy-regressions.md",
    "sourceKind": "repo-docs",
    "title": "Staging deploy regressions after the Phase-0 / Phase-1 merges (publish.yml)",
    "displayName": "Staging deploy regressions after the Phase-0 / Phase-1 merges (publish.yml)",
    "slug": "docs/specs/platform-gaps/phase1/staging-deploy-regressions",
    "articlePath": "wiki/docs/specs/platform-gaps/phase1/staging-deploy-regressions.md",
    "article": "\n# Staging deploy regressions after the Phase-0 / Phase-1 merges (publish.yml)\n\nExecuted 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.\n\nThe 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.\n\n## Evidence\n\n| Run | Commit | Result |\n|---|---|---|\n| [36334258277](https://github.com/a5c-ai/fabric/actions/runs/36334258277) (2026-09-27) | `515877d67` | last green: both jobs pass |\n| publish.yml on the Phase-0 merge (2026-09-29) | `531975433` | \"Deploy Kradle To GKE\" first red (adapters-agent image build) |\n| publish.yml on the Phase-1 merge | `0ab764e5c` | \"Validate Adapter Surfaces\" first red (codecs vitest) |\n| [37193729973](https://github.com/a5c-ai/fabric/actions/runs/37193729973), [37196048317](https://github.com/a5c-ai/fabric/actions/runs/37196048317) | `dc0364001` | same two reds; all other jobs green |\n\nPer-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.\n\n## Regression 1 — `Deploy Kradle To GKE :: Build and push adapters-agent image`\n\n### Symptom\n\nInside `docker buildx build --file packages/adapters/cli/Dockerfile .`, step `RUN npm ci --force`:\n\n```\nnpm warn ERESOLVE overriding peer dependency\nnpm warn   peer vitest@\">=5.0.0 <6.0.0\" from @effect/vitest@4.0.0-rc.115\nnpm warn Conflicting peer dependency: vitest@5.0.3\nnpm error code EUSAGE\nnpm error `npm ci` can only install packages when your package.json and package-lock.json ... are in sync.\nnpm error Missing: search-insights@2.17.3 from lock file\nnpm error Missing: @anthropic-ai/sdk@0.131.0 from lock file\nnpm error Missing: standardwebhooks@1.1.1 from lock file\nnpm error Missing: @stablelib/base64@1.0.1 from lock file\nnpm error Missing: fast-sha256@1.3.0 from lock file\n```\n\n### Root cause\n\n`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.\n\nA 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.\n\nReproduced locally (Windows, node v22.22.0 / npm 10.9.4, clean worktree of `dc0364001`, no `node_modules`):\n\n| Command | Result |\n|---|---|\n| `npm ci --force --dry-run` | EUSAGE, identical five \"Missing: … from lock file\" lines |\n| `npm ci --force --dry-run` with `node_modules` present | same EUSAGE (the host's `nm-*` cache hit is not what saves it; the env var is) |\n| `npm ci --legacy-peer-deps --ignore-scripts --dry-run` | exit 0 |\n| `docker build --target build -f <unfixed Dockerfile> .` | fails at `RUN npm ci --force` with the CI error verbatim |\n| `docker build -f packages/adapters/cli/Dockerfile .` (fixed) | `RUN npm ci --legacy-peer-deps` → `added 3239 packages` with `effect@4.0.0-rc.115 ✔` (patch-package postinstall ran inside the image), the nine-workspace critical-path build and both `node --check`s pass, final image `adapters-agent:after` (3.8 GB) produced |\n\n### Fix\n\n`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.\n\nThe 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.\n\n### Why PR CI missed it\n\n`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.\n\n### \"Artifact not found for name: build-all-dist\" / \"Kradle deploy missing required configuration\"\n\nPre-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.\n\n## Regression 2 — `Validate Adapter Surfaces :: adapters package tests`\n\n### Symptom\n\n```\nFAIL packages/adapters/codecs/tests/base-adapter-install.test.ts\n  > AgentMuxRemoteAdapter transport-agnostic overrides\n  > detectInstallation probes plain `adapters --version` via the spawner\nAssertionError: expected false to be true\n```\n\n### Root cause\n\nWP-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.\n\n### Fix\n\n- `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.\n- `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`.\n\nRunning 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:\n\n- `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+/`.\n- `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'`.\n\n`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.\n\nLocal 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.\n\n### Why PR CI missed it\n\n`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.\n\n### \"No adapter registered for agent \\\"claude\\\"\" / \"RunOptions.prompt is required and non-empty\"\n\nPre-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).\n\n## Other push-only commands checked\n\n`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).\n\n## Runs after merge\n\n__POST_MERGE__\n",
    "documents": []
  },
  "outgoingEdges": [],
  "incomingEdges": [
    {
      "from": "page:docs",
      "to": "page:docs-specs-platform-gaps-phase1-staging-deploy-regressions",
      "kind": "contains_page"
    }
  ]
}

Shortcuts

Back to overview
Open graph tab