Continuous integration

Forge-owned GitHub workflows use native path filters and independent project checks. The approved workflow design supersedes the earlier shared-selector and legacy no-op implementation.

Required checks and migration

Repository quality is the sole proposed required CI context. Seven independent jobs run root formatting, code lint, Markdown lint, spelling, documentation, repository TypeScript and tooling tests in parallel on every PR and main push. The final Repository quality job requires every result to succeed; failures, cancellations and unexpected skips cannot turn into a passing gate. Each check installs its locked dependencies in its own runner. Package runtime tests and builds belong to their own workflows. npm run test:contracts excludes the cross-package model test; npm run test:root retains it for local and GitLab use. npm run typecheck:root also retains integration types for local and GitLab use; Repository quality uses direct npx tsc --noEmit.

No branch protection, environment or publication settings have been changed. The historical 27 contexts and exact proposed removal map are in the migration map. The branch removes their legacy producer jobs; the functioning workflow/protection pair on main stays in place until a coordinated, separately approved transition. Missing legacy checks on this branch are expected until that transition and can prevent merging.

1. Review the complete workflow change and inspect hosted project checks and artifacts, including failed validation and non-production schedule/manual runs.
2. Obtain separate approval to replace the exact 27 old requirements with Repository quality, removing any old summary requirements if present.
3. Coordinate settings and workflow merge so missing legacy results do not strand PRs. Preserve unrelated review, security, environment and publication protections.
4. Roll back by restoring the matching historical workflows and required-context settings together. No automated settings synchronization is installed.

Project-specific checks must be reviewed before merge; an optional failed check will not itself enforce branch protection. Native filters have GitHub path limits and require explicit updates for new shared inputs. Unknown paths have no custom broad fallback; weekly/manual validation provides a backstop.

Check execution

See the YAML for each complete input list. Published upstream source edits do not fan out to downstream consumers: consumers validate when their manifests/locks change. The CLI also validates template edits because it bundles that source. Integration source changes run their own workflow; ordinary upstream package edits do not select it. The focused CMS serialization check retains metadata/body, delimiter, failure-preservation and retry coverage. The separately known failing CMS ordering probe is not enabled and serialization success does not prove it. GitLab uses native change rules for the same project ownership. Scheduled and web pipelines run broad validation; a weekly schedule must be configured separately.

Runtime and evidence strategy

Content Model and Markdownlint run source tests and type checks on all four supported Linux Node lanes independently of one build and publishable-file inspection. They do not transport or unpack package tarballs between jobs. Browser runtime lanes restore native assets from the inspected package instead of installing Rust. Create Forge’s four Linux Node lanes and Node 26 macOS lane consume one packed CLI for distinct behavior scenarios and a default generated build. Consumers install committed registry locks; no unpublished upstream source is substituted.

Template validates an isolated canonical starter through scripts/test-template.ts. Its primary runtime publishes source and build archives, reused by static quality, build validation, browser/accessibility and Lighthouse jobs. Customization runs with npm run test:template:customization. Normal static checks run on the canonical template; the former negative-fixture tool self-tests have been retired. Generated workflow scans and generated-output tests belong to Create Forge.

Website source checks gate one production build. Build validation, all three browser projects and Lighthouse download that same immutable website-build artifact. Only main pushes upload the Pages artifact and deploy after every quality, artifact, browser and budget check passes. Deployed smoke follows deployment with its existing timeout and URL guard. PRs, schedules and manual runs do not deploy or publish. Browser evidence and hidden Lighthouse reports retain seven-day retention.

Generated consumer CI keeps its existing cadence and provider builders: Chromium/axe on PRs and ordinary pushes, full browsers weekly/manually, Lighthouse on pushes and weekly/manual runs. Generated YAML remains consumer-owned after bootstrap.

Earlier verification evidence is historical. Local graph/contracts and syntax/security checks do not establish hosted execution, native toolchain success, deployment, or repository-settings migration for this revision.

Security reporting and release gates

Security analysis stays separate from project correctness checks:

• CodeQL uploads source analysis results to GitHub code scanning;
• Zizmor uploads workflow analysis results to code scanning and fails Workflow security when it finds an insecure workflow;
• Dependabot alerts use the repository dependency graph as the canonical view of vulnerable npm dependencies;
• dependency review fails on newly introduced high or critical vulnerabilities, matching generated consumer CI; branch protection controls merge enforcement.

Normal project, generator, website and generated consumer CI do not run dependency vulnerability audit jobs. The unused-code audit remains a correctness check.

Package publication does not run dependency vulnerability audits; Dependabot and dependency review handle dependency findings. Repository checkpoint releases require the documented root, template, and website audits to pass.

Both policies reject high and critical vulnerabilities. An exception must name the exact GitHub Security Advisory ID, explain why the affected path is safe for Forge’s use, include an expiry date, and link upstream tracking when available. Do not allowlist package names or severity classes. Expired entries must be removed or re-evaluated in a dedicated pull request.

Run the repository audit locally with:

npm run audit

Run the template and website policies explicitly with:

npm run audit --prefix templates/default
npm run audit --prefix website

The normal quality commands deliberately exclude vulnerability audits because quality is a pull-request correctness gate. Dependabot treats /website as an independent npm ecosystem and submits reviewable lockfile updates without regenerating owned website source.

Negative verification

When changing job dependencies or artifact behavior, use a temporary review branch to prove the failure path. An intentionally invalid workflow must fail Workflow syntax; a Zizmor finding must fail Workflow security and upload to code scanning. A Lighthouse run that omits .lighthouseci must make its upload contract fail. Remove the deliberate defect before merging and link both workflow runs in the tracking issue.

Generated project CI

Create-forge internally uses TypeScript builders and provider-specific rendering to bootstrap consumer YAML. Generated sites own that YAML and edit it directly. See CI providers for generation, dependency pins and GitHub/GitLab support. Generated stable Project results reject selection/prerequisite failures and accept only intentional unaffected or PR-Lighthouse skips. Nested-site routing uses its repository-relative directory; shared workflow/setup inputs also select validation. See generated CI for details.

Native GitLab validation

Forge maintains .gitlab-ci.yml and project-owned includes under .gitlab/ci/ as ordinary native YAML. Repository formatting, code/Markdown lint, spelling, documentation, types and tooling tests run independently. Content Model, Markdownlint, Browser Formatter, Create Forge, Template, Website and model/CMS integration have their own change rules and explicit shared inputs.

The custom impact selector, selection job and generated child pipeline have been removed. GitLab evaluates native change rules for merge requests and default-branch pushes. Schedule/web rules admit broad validation before change rules are evaluated. Mixed changes select the applicable projects without published upstream source triggering downstream packages.

Content Model and Markdownlint test source on minimum/latest Node 22, Node 24 and Node 26 Linux lanes, alongside one build/publishable-file inspection. Create Forge uses one inspected CLI tarball for its Linux scenarios and packed smoke. Template owns isolated starter quality, runtime/build, full browser/accessibility, Lighthouse and customization validation. Browser Formatter retains native reproducibility, package browsers and native asset reuse across runtime lanes. Model/CMS integration has its own tooling triggers and broad scheduled/manual runs.

GitHub remains the primary provider, including macOS validation, CodeQL, dependency review, workflow scans, mirror synchronization and release automation. GitLab uses Linux container runners. Its website deployment and smoke jobs remain disabled; no project schedule/manual run publishes or deploys. Server-side CI Lint and a configured runner are still needed to verify the native pipeline on the mirror. This change does not configure schedules or alter repository settings.

Native job dependencies preserve build-artifact ownership without waiting for unrelated project work. The former strategy: mirror child-pipeline version requirement no longer applies. Generated consumer YAML remains separate from this Forge-owned workflow translation.

Native CI reporting

GitLab receives JUnit results from Vitest and Playwright, including failed runs. Node compatibility lanes add the runtime to Vitest case identifiers so results remain distinct. Website unit coverage uses Cobertura for merge request coverage annotations, and Oxlint emits Code Quality JSON with repository-relative paths. Generated GitLab CI includes the same reports for consumer projects. HTML coverage, browser reports and traces remain downloadable artifacts.

Disposable generator consumers publish JUnit results but do not publish coverage annotations or Code Quality findings against Forge source: their files belong to the bootstrapped project rather than this repository. Their coverage remains a downloadable artifact. Formatting, CSS/Markdown linting and Lighthouse still report through job logs and their existing artifacts.

GitHub uses the built-in Vitest GitHub Actions reporter for failure annotations and test summaries, explicit Oxlint GitHub annotations, and Playwright’s GitHub reporter. Coverage HTML remains an artifact; GitHub does not consume GitLab’s Cobertura report declarations. No additional reporting action, service or write permission is required.

GitLab Lighthouse jobs select Playwright Chromium with CHROME_PATH and set these flags to support root execution and limited shared memory in Node containers:

LHCI_COLLECT__SETTINGS__CHROME_FLAGS: --no-sandbox --disable-dev-shm-usage --disable-gpu

These settings are scoped to the audit jobs, including generated consumer pipelines.

Consumer deployment environments

Create-forge accepts bootstrap-only deployment inputs for a named native Pages environment and source branch. Validation runs on the configured branches; deployment is owned by the primary CI. Consumers edit the resulting native YAML without keeping Forge configuration. See the initializer’s deployment options for the JSON input and target limitations. This does not change Forge’s own website deployment or internal workflow ownership.