Grilling
CI Workflow Topology Grill Status
CI Workflow Topology Grill Status
Branch Dashboard
| Branch | Completion | Locked direction | Still open |
|---|---|---|---|
| Verification authority | 100% | Only the latest successful prospective merge tree is test authority; main and publication do not rerun tests. | none |
| Pull-request topology | 100% | One workflow owns affected ci, affected browser-smoke, cancellation, aggregate result, and Candidate Evidence; Turbo owns selection. | none |
| Release orchestration | 100% | release.yml runs read-only intent then conditional protected publication on main; no tests; releases serialize without cancellation. | none |
| Evidence transport | 100% | Candidate Evidence is a 14-day JSON receipt binding a successful same-repository PR run to the tested Git tree; no package crosses the boundary. | none |
| External-drift scheduling | 100% | No CLI native safety suite remains; schedules contain only named external-drift witnesses that PR verification cannot establish. | none |
| Package integrity | 100% | No package execution suite remains; publication keeps only the minimal npm pack --json --dry-run precondition. | none |
| Turbo graph and cache | 100% | Every deterministic retained check is package-owned and cacheable in Turbo; trusted and fork cache writes preserve separate authority. | none |
| Failure and retry | 100% | Failed publication reconciles existing state before later releases; release runs serialize and never cancel. | none |
Current Round
- Round: R6
- Current frontier: empty
- Shared-understanding confirmation: confirmed
| Question id | Prerequisites | Question | State |
|---|---|---|---|
| Q1 | none | Is exact successful PR verification the sole test authority for publication? | answered |
| Q2 | none | What pull-request job topology is required? | answered |
| Q3 | none | Which event and version-intent mechanism starts publication? | answered |
| Q4 | Q2 | When do retained high-signal native safety witnesses run? | answered |
| Q5 | Q2 | What happens when change classification is unknown or touches root control files? | answered |
| Q6 | Q2 | Should the pull-request package-smoke suite remain? | answered |
| Q7 | Q3, Q6 | What package-integrity proof, if any, runs inside publication? | answered |
| Q8 | Q1, Q2 | What exact candidate evidence does the PR retain, and how does publication resolve it? | answered |
| Q9 | Q1, Q3, Q7 | Which workflows and jobs remain on pull requests, main, and schedules? | answered |
| Q10 | Q6, Q7 | Does any installed-tarball execution smoke remain? | answered |
Working Direction
pull request
ci affected lint, types, and behavioral tests
browser-smoke only for backoffice/browser changes
candidate 14-day JSON receipt for exact tested tree
main or reviewed release intent
release-classifier none | baseline | npm | mixed
publication build/package-specific proof, publish, reconcile, read back
no replay of PR test suitesGlossary
Terms
- Verification Authority: Exact successful pull-request evidence for one commit tree that publication may trust without rerunning the same tests.
- Affected Verification: Validation selected from the changed workspace dependency graph plus explicit safety fallbacks.
- Publication Workflow: Protected mutation path that consumes reviewed release intent and exact verification evidence, then publishes and reconciles external state.
- Candidate Evidence: Immutable JSON receipt binding a successful same-repository pull-request run to its exact tested Git tree.
- Stable Aggregate Check: One required check name that reports the result of every applicable pull-request proof, including intentional path-based skips.
Relationships
- One source tree has at most one accepted Verification Authority record per workflow contract.
- Affected Verification and any applicable browser proof contribute to the Stable Aggregate Check.
- The Publication Workflow consumes Candidate Evidence for the exact release tree.
- The release-impact classifier chooses which product mutation the Publication Workflow performs.
Axioms
- Pull requests never publish production artifacts.
- Release mutations are never cacheable.
- Unknown release impact fails closed.
- A skipped path-specific proof is valid only when the change classifier proves that its owned surface is unaffected.
- Publication must never treat a green result from another tree as authority.
- Superseded pull-request runs are cancelled.
- The stable aggregate check always runs even when owned path-specific proofs are skipped.
- A
nonerelease classification performs no product mutation. - Tests execute only for pull-request revisions; publication trusts only exact matching successful evidence.
- Turbo's affected graph and declared global inputs own change selection.
- Publication performs a package-integrity precondition, not a package test suite.
- Publication does not execute an installed tarball.
- Pull-request verification,
mainrelease intent, and external-drift witnesses live in separate workflows. mainand scheduled workflows never replay the pull-request suite.- Release runs serialize and never cancel.
- Every deterministic retained check is an owning package's cacheable Turbo task; root scripts only delegate to
turbo run. - Trusted internal pull requests,
main, and release verification share one signed remote-cache namespace when task inputs are identical. - Fork pull requests may restore default-branch GitHub Actions Turbo cache entries but may write only to an isolated pull-request cache scope.
- CLI symlink, race, permission, rollback, and interrupted-write tests do not survive as "native witnesses" under another workflow name.
Flagged Ambiguities
- "Copy TanStack" may mean copy Changesets, or only copy the separation between PR verification and release publication. Q3 resolves this.
- "Run tests once" means once per pull-request revision. Cache reuse remains a separate mechanism.
- "Affected" means Turbo dependency selection plus declared global inputs and explicit repository-level tasks.
- "Package smoke" includes installed-tarball execution and is removed from every lane. Publication retains only package-integrity inspection.
- Candidate Evidence is not a package artifact. Its proposed JSON form is a small receipt that binds a successful PR run to the tested Git tree.
- PR and
maincommit SHAs may differ while their Git trees are identical. Candidate Evidence binds publication authority to the tree rather than assuming SHA equality.
Parked Branches
- Beta, canary, and npm staged publication remain parked.
- GitHub billing recovery and the next paid Actions attempt are external execution gates, not workflow-design decisions.
- Concrete test deletions remain owned by the integrated CI Test Suite Pruning requirements.