CI Verification and Publication Delivery Planning Research

Executive answer

The repository has useful release-authority and reconciliation seams, but its active workflow still implements the superseded verification model. Delivery must first establish one pull-request-only Turbo graph and a small Stable Aggregate Check. It can then reduce Candidate Evidence to exact-tree authority and make publication consume that evidence without test replay.

The accepted specification is the authority for product direction. This report records current implementation facts and planning implications. It does not reopen parked release channels, change release-impact meaning, or choose a different recovery model.

Research coverage

Two read-only lanes inspected commit 97ee7fe9:

1. GitHub workflow topology, Turbo ownership, cache trust, Candidate Evidence, and publication authority.
2. CLI public-process witnesses, Focused Tests, low-signal deletion candidates, Safety Invariants, and scheduled external drift.

The coordinator verified the immutable specification, canonical glossary, live Linear hierarchy, local Turbo 2.9.14 schema, and current official GitHub Actions and npm trusted-publishing guidance.

Current facts

Verification topology

• behavior-contract.yml runs the protected CLI portfolio for pull requests, main, and a weekly schedule. This conflicts with AC-011, AC-026, and AC-033.
• package.json directly starts root Bun suites before the repository runner. CI therefore bypasses singular Turbo ownership required by AC-016.
• turbo.json enables signed remote caching but does not declare repository-wide result controls as global inputs. The deterministic CLI build is explicitly uncached.
• Trusted internal pull-request jobs configure signed remote cache. Fork jobs omit signing credentials and cache setup. Forks cannot poison trusted artifacts, but the workflow does not yet prove safe default-branch restoration plus isolated fork writes.

Retained test portfolio

• The repository has no explicit capability-and-safety inventory that maps every retained witness to a named public capability, contract, or Safety Invariant.
• CLI coverage is predominantly in-process. Some tests spawn dist, but there is no deliberate one-primary-witness atlas for check, ensure, init, scaffold, update, operator, report, skills, tools, and upgrade, and no single product-wide hint parity smoke.
• Test-title inventories, exact-version fixtures, source-text assertions, duplicate update/release matrices, and lower-level native fault suites remain. The accepted pruning status classifies these as deletion candidates when they do not uniquely prove a public result.
• Release classification, exact-tree authority, convergence, and typed evidence decoding contain dense exported rules suitable for retained Focused Tests.

Candidate Evidence and publication

• Pull-request verification already retains a 14-day tree-named artifact. Its payload includes artifact identity, classification, intent, and package-related state beyond the minimal Candidate Evidence fields required by AC-020 and AC-021.
• run-release-candidate.mjs builds package identity with npm pack --json during candidate creation. Package integrity therefore occurs before publication and leaks into evidence transport.
• release.yml already validates same-repository pull-request artifacts, exact commit/tree identity, reviewed intent, OIDC authority, serialized mutation, reconciliation, and readback. It also runs focused Vitest work on pull requests and assembles artifacts before protected publication.
• Release-state convergence already blocks absent or invalid authority and resumes from the first incomplete external step. This recovery behavior is retained authority, not replacement scope.

External contract checks

• GitHub documents low-trust cache poisoning and recommends restore-only behavior for low-trust triggers. Pull-request caches are scoped to their merge ref and cannot overwrite the default-branch cache. Source: GitHub dependency caching reference.
• GitHub workflow artifacts can set retention-days; downloading from another run requires a token and run identifier. Source: GitHub workflow artifacts.
• npm trusted publishing binds repository, workflow filename, optional environment, and allowed operation; GitHub Actions needs id-token: write on a GitHub-hosted runner. Source: npm trusted publishing.
• Turbo 2.9.14 declares task inputs, outputs, environment identity, affected selection, and remote-cache signature verification in its installed schema. Source: node_modules/turbo/schema.json.

Planning implications

1. Establish the High-Signal Test inventory and public built-process witnesses before deleting the old portfolio. Pure deletion needs no RED/GREEN cycle; new public behavior and workflow behavior do.
2. Make deterministic package and root checks Turbo-owned, cacheable, and precisely identified. Use one affected pull-request entrypoint and preserve the Stable Aggregate Check even when graph selection skips a path-owned proof.
3. Separate named external-drift witnesses into their own scheduled/manual workflow. Remove main and schedule replay from the retained portfolio.
4. After the aggregate contract exists, reduce Candidate Evidence to repository, workflow run, pull request, head commit, tested tree, and successful conclusion. Keep builds, packages, caches, credentials, classification, and release intent out.
5. Move package inspection to the protected publication boundary with npm pack --json --dry-run. Preserve existing semantic classification, OIDC ownership, serialization, reconciliation, and readback.

Conflicts and uncertainty

• The earlier research report recommended retaining installed-tarball execution and lower-level native safety suites. The later accepted spec explicitly supersedes both recommendations. Delivery follows the spec.
• GitHub billing may prevent a paid Actions validation run. Local workflow, Turbo, security, and process evidence can still complete; the missing hosted run must remain an external execution gate.
• Named external-drift witnesses must correspond to behavior that pull-request verification cannot establish. Existing native and ambient partitions cannot be moved wholesale to schedules.
• Fork cache restoration depends on the selected GitHub/Turbo cache mechanism. The implementation must prove restore-only default-branch reuse and isolated pull-request writes without exposing the trusted signature key.

Proposed dependency shape

M12 public witnesses ─┐
M12 affected Turbo ───┼─> M13 exact-tree evidence ─> M14 publication
M12 named drift ──────┘             │
                                    └─> M13 trusted/fork cache reuse

The worker graph can parallelize the three M12 roots because their initial write scopes are disjoint. M13 authority depends on the Stable Aggregate Check contract. M14 publication depends on exact-tree evidence. Final convergence must prove that no retained portfolio runs outside pull requests and no publication path replays product verification.

Unresolved product decisions

None. The accepted specification closes the decisions needed for planning. Billing recovery and an explicitly authorized real release remain execution gates.