CI coverage and ownership baseline

This is the pre-migration baseline for spec 367 and ticket 371, observed October 22, 2026. Source baseline: 9661fd7. This document records observations separately from proposed routing. Forge maintains its native workflows; generated consumers own their emitted YAML after bootstrap. No repository settings, deployments, reference repositories, or pipelines were changed to collect evidence.

Evidence and protection

Read-only GitHub REST requests inspected branches/main/protection, rulesets, environments, each environment’s deployment-branch-policies, and Actions runs/jobs. No repository rulesets were returned. Main enforces protections for administrators; strict up-to-date checks, signatures, force pushes, branch deletion, linear history, and conversation resolution are disabled. There are 27 required GitHub Actions contexts (application ID 15368), listed in the migration table below. The native Rust job is a build prerequisite but is not itself a required context. Website, CodeQL, and workflow-scanning contexts are not in this required-check list.

All three environments allow administrator bypass. Environment secret values were not requested. GitLab CI Lint, mirror runner execution, GitLab branch protection, and reference-site protections were not inspected; native YAML and local contract tests cannot establish those live facts. Consumer protections are repository settings and cannot be inferred from generated YAML.

Responsibility and trigger matrix

The detailed job/command/artifact inventory follows later in this document. All root npm checks use the root lock; website and generated consumers install their own committed lock. Permissions start empty unless noted, and jobs request only their documented scopes.

There is no broad scheduled package/generator/website validation today. Security, automation, external links and dependency-update schedules cover different responsibilities. Default proposal: one weekly broad validation of all lanes, with manual dispatch for diagnosis; retain post-deployment smoke. Daily fresh installs remain outside this spec and depend on the separate lockfile experiment.

Consumption graph and proposed routing

Candidate overlays are intentional test setup, not release dependencies. Preserve the isolated website boundary (ADR 0007), independent versions (ADR 0006), and frontmatter package boundary (ADR 0008). The root lock changing does not modify website’s lock, but shared root checks still use that lock. Website checks consume docs at build time; a docs-only policy that skips every website check is unsound.

Cost observations

Times below are observed UTC job durations, including setup but excluding time waiting for prerequisites. Elapsed workflow time includes orchestration/queue time. Samples are successful runs, not statistical medians, billed minutes, or a controlled before/after benchmark. Different runs can have different changes.

The first two workflows alone submit 28 jobs for every PR before security, native and website selection. A website main push adds deployment and smoke; a PR skips those two jobs. A 40-run recent sample included many cancelled main pushes; do not treat cancellation time as the cost of a successful run. The older project run 39713028851 spans about 7.5 hours because it was updated later; created-to-updated elapsed is unreliable as runner cost. Re-measure with job start/end times and identical change classes.

Overlap to remove carefully: project packages CLI while generator separately packages CLI; root static checks and independent site static checks overlap file surfaces; generator scenarios and five consumer lanes repeat installs/builds intentionally across runtime/OS; root native quality and native reproducibility repeat Rust work for different contracts. Browser accessibility tests already use axe; Lighthouse’s accessibility score overlaps automated accessibility but also checks performance/SEO/best-practice budgets. Build validation checks files/metadata without browser interaction; smoke catches deployed base paths, assets and mobile layout after deployment, which local build/browser success cannot prove.

Existing optimization is retained: one canonical generated source and production build feeds downstream consumer quality/browser/Lighthouse/build validation, with per-runtime builds reserved for compatibility. The CMS native-save probes use focused Chromium and real serialization rather than a complete repeated multi-browser CMS editing suite. They still verify save ordering/convergence; formatter serialization probes additionally protect callback failures and unchanged input. No CMS protection is removed here.

Delivered-test disposition

Decisions below guide the consumer slice; no tests are removed by this inventory. Paths are relative to templates/default. Mixed files require splitting assertions, not deleting their durable protection.

tests/preview.ts is support code, not an assertion suite. Preserve it wherever retained tests need it. Routes/names/colors are replaceable examples; security, accessibility, content preservation and generic CMS editing-to-build checks remain obligations. Document optional example patterns rather than shipping assertions about a consumer’s choice of content. Native CMS probes and packed generator end-to-end tests stay Forge-owned even when consumer examples move.

Required-check migration and rollback proposal

This is a proposal, not an applied protection change. Three always-created summaries keep the required surface small while reporting explicit success for unaffected work. The routing selector must be a prerequisite whose failure/cancellation cannot be interpreted as an unaffected lane.

Native verification must feed the project summary when selected. Security and automation keep their responsibilities; their routing must not disappear accidentally behind package selection. Final names may be coordinated by the workflow slice, but the operator must record the exact resulting map.

Deploy code first with both old checks and summaries observable. Collect real PR evidence for success, unaffected lanes and failures before requesting authorization to change required contexts. Change settings only after all new names exist; keep the previous context list for rollback. Do not remove old job contexts while they remain required: skipped entire workflows can leave branch protection waiting forever. If migration fails, restore the original workflow graph and 27 contexts together. Disable selective routing or dispatch broad validation while diagnosing; never turn a missing result into success. Preserve exact release-commit validation, inspected tarball handoff, immutable tags, provenance and environment approval. No mirror production publishing or PR deployment may be introduced.

Representative change and failure matrix

Provider-native negative execution remains required evidence for downstream work; static YAML checks prove structure only. Record before/after job counts and timings for comparable representative changes, separately from coverage decisions and authorized branch-protection migration.

Workflow job inventory at baseline

Job IDs below are the stable dependency pointers; matrix names expand at execution. Commands are listed by their public npm entry points or step purpose where shell orchestration is involved. The linked source retains complete shell bodies, guards and action pins. Artifact names/paths identify the existing handoffs; they are not interchangeable with a fresh build from another commit.

Repository Automation Validation

Source: automation.yml.

Browser Oxfmt Package

Source: browser-oxfmt.yml.

External Documentation Links

Source: documentation.yml.

Generator CI Validation

Historical source: generator.yml.

Sync GitLab

Source: gitlab-sync.yml.

Browser Oxfmt Engine Updates

Source: oxfmt-upgrades.yml.

Package Release

Source: package-release.yml.

Peer Compatibility Updates

Source: peer-upgrades.yml.

Project Continuous Integration

Source: project.yml.

Security Analysis

Source: security.yml.

Published Template Synchronization

Source: template-sync.yml.

Forge Website Continuous Integration

Source: website.yml.

GitLab native jobs

Root pipeline rules and include scopes are described above; all includes run under the same pipeline. Images select independent Node versions; no GitHub token permissions apply. GitLab CI job-token access and protected variables are server settings whose live state was not inspected.

Source: generator.yml.

Source: project.yml.

Source: website.yml.

Generated provider inventory

The bootstrap authors github.ts, github-extra.ts, gitlab.ts and model.ts are the authoritative source. The default generated GitHub set is project.yml, automation.yml, security.yml; a prefix names them for nested sites. GitLab emits .gitlab-ci.yml, or a prefixed include under .gitlab/ci. Consumer YAML has no continuing generator requirement.

Schedules use bootstrap-derived minutes to avoid identical timing across repositories. Primary GitHub cannot deploy GitLab Pages and primary GitLab cannot deploy GitHub Pages. Cloudflare uses locked Wrangler, environment secrets and account/project validation. Root/nested directory, selected Node major, provider, source branch and multiple deployment environment combinations are validated through existing packed-CLI scenarios and provider contracts. Generated workflow live protections and successful provider execution remain unavailable until inspected in each consumer; emitted structure alone is insufficient.

During rollout retain every existing required job name above, reporting a successful no-op for unaffected work. Add summaries alongside those contexts; the proposed migration table does not authorize renaming or removing required jobs before the owner approves a protection change.