CI Workflow Topology Grill Log

Context

• Source research: [[content/docs/project/research/ci-suite-reduction-and-npm-release-research-report]].
• Test-portfolio authority: [[content/docs/project/grilling/ci-test-suite-pruning-grill-status]] and [[content/docs/project/grilling/ci-test-suite-pruning-grill-log]].
• Prior release authority: [[content/docs/project/grilling/cache-release-diff-classification-grill-status]] and [[content/docs/project/grilling/turborepo-release-caching-grill-status]].
• User direction: copy the useful TanStack workflow shape so Harness does not replay the full suite across pull-request, main, and publication jobs.

Retained prior decisions

• Pull requests never publish production artifacts.
• Release mutations are never cacheable.
• Release intent is reviewed repository state; CI does not invent product versions.
• The release-impact classifier selects none, baseline, npm, or mixed and fails closed on unknown impact.
• Production stable is the only active public channel.
• Exact successful pull-request evidence currently gates publication because GitHub Free cannot enforce the intended private-repository merge rules.
• Failed publication reconciles completed external state before later versions proceed.

Supersession boundary

This grill may supersede workflow triggers, job fan-out, test scheduling, candidate evidence transport, and publication job contents. It does not silently change product release semantics, compatibility ranges, channel policy, credential ownership, or recovery ordering.

Round R1 Frontier

Q1 through Q3 are independent. They decide the authority boundary, pull-request shape, and release trigger before later questions define evidence transport and retained native scheduling.

Round R1 Responses

Q1

Prerequisites:

• none

Question: Is exact successful PR verification the sole test authority for publication?

Clarification requested:

• The user asked whether this means tests run only on PR commits.
• Precise proposed meaning: each new PR revision may start verification; superseded runs are cancelled; only the latest successful prospective merge tree becomes authority; main and publication do not rerun tests; a direct main commit without matching PR evidence cannot publish.
• Q1 remains unanswered until the user confirms this precise meaning.

Q2

Prerequisites:

• none

Question: What pull-request job topology is required?

Accepted answer:

• Use one pull-request workflow with classify, affected ci, affected package-smoke, affected browser-smoke, and one always-running required aggregate.
• package-smoke runs only when CLI, scaffold, contract, baseline, or release-owned inputs change.
• browser-smoke runs only when backoffice or browser-owned inputs change.
• Keep one stable required check name. An intentional skip is valid only when classify proves that the owned surface is unaffected.
• Cancel superseded pull-request runs.

Q3

Prerequisites:

• none

Question: Which event and version-intent mechanism starts publication?

Accepted answer:

• Keep the semantic release-impact classifier on every main push.
• Preserve reviewed repository release intent and the none, baseline, npm, and mixed outcomes.
• Do not adopt Changesets or require a manually created release tag for this delivery.
• Copy TanStack's separation between pull-request verification and publication, not its npm-only versioning mechanism.
• none stops after classification; another outcome starts the protected publication path.

Round R2 Frontier

Q1 remains open after clarification. Q4 and Q5 are now unblocked by Q2. Candidate evidence transport remains blocked by Q1.

Round R2 Responses

Q4

Prerequisites:

• Q2

Question: When do retained high-signal native safety witnesses run?

Accepted answer:

• Run a retained native safety witness on a pull request only when its owned production or native boundary changes.
• Do not keep a weekly full-suite backstop.
• A scheduled check is allowed only when it observes current external drift, such as a runtime, operating-system, filesystem, or provider behavior that cannot be established from the pull-request run.
• Low-signal tests do not move to a schedule; the CI Test Suite Pruning grill deletes them.

Q5

Prerequisites:

• Q2

Question: What happens when change classification is unknown or touches root control files?

Conditional response:

• The user accepted only if the proposed fail-unknown ownership rule matches TanStack.
• It does not match TanStack Query exactly. Query uses the Nx affected graph; root and shared inputs expand the affected set through Nx configuration.
• Q5 remains unanswered and must be re-pitched as a choice between a TanStack-like affected graph and a stricter Harness ownership error.

Q6

Prerequisites:

• Q2

Question: Should the pull-request package-smoke suite remain?

Accepted answer:

• No. Remove the pull-request package-smoke job and suite.
• This supersedes the package-smoke part of Q2. Q2 still owns classify, affected ci, affected browser-smoke, cancellation, and the stable aggregate.
• Whether publication retains one package-integrity step immediately before npm publish remains open in Q7.

Round R3 Frontier

Q1 remains open. Q5 is re-pitched with accurate TanStack behavior. Q7 is unblocked by Q3 and Q6. Candidate evidence transport still depends on Q1.

Round R3 Responses

Q1

Prerequisites:

• none

Question: Is exact successful PR verification the sole test authority for publication?

Accepted answer:

• Yes.
• Each new pull-request revision may start verification; a newer revision cancels the superseded run.
• Only the latest successful prospective merge tree becomes verification authority.
• main and publication do not rerun the pull-request test suite.
• A direct main commit without matching successful pull-request evidence cannot publish.

Q5

Prerequisites:

• Q2

Question: What happens when change classification is unknown or touches root control files?

Accepted answer:

• Use a TanStack-like affected dependency graph through Turbo rather than a custom unknown-path ownership error.
• Declare root and shared controls such as the lockfile, Turbo configuration, shared TypeScript configuration, and tool versions as global task inputs.
• A global-input change invalidates every relevant task through the dependency graph.
• Repository-level checks remain explicit for repository scripts and workflow changes.

Q7

Prerequisites:

• Q3
• Q6

Question: What package-integrity proof, if any, runs inside publication?

Accepted answer:

• Keep one minimal publication precondition after the CLI build and before npm publish.
• Run npm pack --json --dry-run.
• Verify that the package version matches reviewed release intent, both hi and hint binaries are declared, and required dist and bundled baseline files are present.
• Do not install the tarball, execute CLI commands, or run a package-smoke test suite.

Round R4 Frontier

Q8 and Q9 are unblocked. They decide lightweight candidate evidence and the final workflow/trigger split before concurrency and recovery can close.

Round R4 Responses

Q8

Prerequisites:

• Q1
• Q2

Question: What exact candidate evidence does the PR retain, and how does publication resolve it?

Clarification requested:

• The user asked why a JSON artifact is needed.
• GitHub records CI against a commit SHA. The prospective pull-request merge commit can have a different SHA from the final main commit even when both have the same Git tree.
• Candidate Evidence would carry the tested tree hash so publication can prove that the final main content is identical to the content that passed pull-request CI.
• Q8 remains unanswered until the user chooses this explicit receipt or another authority mechanism.

Q9

Prerequisites:

• Q1
• Q3
• Q7

Question: Which workflows and jobs remain on pull requests, main, and schedules?

Accepted answer:

• ci.yml runs on pull requests only, cancels superseded revisions, runs affected CI and affected browser proof, then produces one stable aggregate result.
• release.yml runs on main only. A read-only intent job verifies candidate authority and classifies none, baseline, npm, or mixed; a conditional protected publication job builds, checks package integrity, publishes, reconciles, and reads back without tests.
• external-drift.yml is scheduled or manual and contains only named witnesses of current external behavior.
• Remove behavior-contract triggers from main and weekly schedule, remove the pull-request release guard, and remove publication test matrices.
• Release runs are serialized and never cancelled.

Round R5 Frontier

Only Q8 remains open. Concurrency, failure recovery, and workflow ownership are already covered by accepted Q2, Q3, Q4, Q7, Q9, and prior release-recovery decisions.

Round R5 Response

Q8

Prerequisites:

• Q1
• Q2

Question: What exact candidate evidence does the PR retain, and how does publication resolve it?

Accepted answer:

• Retain one small Candidate Evidence JSON artifact from the successful pull-request aggregate job.
• The JSON contains schema version, repository, workflow run id, pull-request number, head commit, tested Git tree, and successful conclusion.
• Name the artifact with the tested tree hash and retain it for 14 days.
• It contains no tarball, build output, cache data, credentials, or secrets.
• Publication calculates the final main Git tree and accepts the newest valid same-repository successful candidate for that exact tree.
• Missing, expired, unsuccessful, fork-originated, or tree-mismatched evidence blocks publication before the protected mutation job.
• Delete this mechanism if an enforceable merge queue later tests the exact final commit.

Final Consistency Pass

• Verification Authority is one exact successful pull-request result for the tested Git tree.
• Candidate Evidence transports only that authority across differing PR and main commit SHAs; it does not transport a package or cached result.
• Affected Verification decides which retained tests run on the pull request; it does not weaken exact-tree publication authority.
• The Publication Workflow consumes Candidate Evidence, applies the existing release-impact classifier, performs release-specific package integrity, mutates external state, and reads it back without replaying tests.
• Existing stable-channel, compatibility, credential, and ordered-reconciliation decisions remain consistent with the simplified workflow topology.
• No glossary conflict remains. The frontier is empty and shared-understanding confirmation is pending.

Cross-domain reconciliation

The CI Test Suite Pruning grill later closed its retained portfolio and Turbo cache rules. Those decisions refine this topology as follows:

• Pruning Q4 and Q12 supersede topology Q4's broad "retained native" wording. No lower-level CLI native safety matrix remains. A scheduled workflow may contain only a named witness of external runtime, operating-system, filesystem, or provider drift that pull-request verification cannot establish.
• Pruning Q15 requires every deterministic repository check, including repository policy checks, to have an owning package or justified Turbo root task. Root scripts only delegate to turbo run; CI does not keep direct Bun, Vitest, or custom-suite preambles.
• Pruning Q14 and Q16 require identical trusted deterministic tasks to share one signed remote-cache namespace. Fork pull requests may restore default-branch GitHub Actions Turbo cache entries but may write only to an isolated pull-request cache scope.

One contradiction remains and reopens the frontier.

Q10

Prerequisites:

• Q6
• Q7

Question: Does any installed-tarball execution smoke remain?

Accepted answer:

• Delete pruning Q13's installed-tarball execution smoke.
• Keep the primary full-command suite against built dist in affected pull-request verification.
• Keep only the release-time npm pack --json --dry-run integrity precondition from topology Q7.
• Do not execute hi or hint from an installed tarball before publication.

Integrated consistency pass

• Affected Verification runs the retained capability-and-safety portfolio only on pull-request revisions.
• The Stable Aggregate Check emits Candidate Evidence only after every applicable affected proof succeeds.
• The Publication Workflow accepts only exact-tree Candidate Evidence, classifies release intent, builds, inspects package contents, mutates external state, reconciles, and reads back without test replay.
• No lower-level CLI native safety matrix or installed-tarball execution smoke remains in any workflow.
• Every deterministic retained repository check is a cacheable Turbo task with an explicit owner and correct trusted-versus-fork cache authority.
• The cross-domain frontier is empty. Shared-understanding confirmation is pending.

Shared-understanding confirmation

• The user confirmed the integrated workflow and retained-test model on 2026-08-14.
• All workflow-topology branches are closed at 100%.
• The accepted requirements are ready for specification compilation with the CI Test Suite Pruning grill.