Files
amare/openspec/changes/complete-foundation-parity/specs/quality-gates/spec.md
manoel freitas 9dd6fcf409 docs: sync OpenSpec archives and propose foundation parity
Archive completed public-site and production-provider changes into main specs, remove duplicate active changes, and add complete-foundation-parity so Phase 0 staging and remaining foundation gaps block Phase 2 cleanly.

Co-authored-by: Cursor <cursoragent@cursor.com>
2026-08-01 21:55:04 -03:00

1.8 KiB

ADDED Requirements

Requirement: Quality gate includes npm dependency audit

The system SHALL run an npm audit as part of the quality/static gate according to the project policy (SPEC §12.6, §13.9). Audit failure MUST block merge unless an explicit, documented exception exists.

Scenario: Vulnerable dependency fails static gate

  • WHEN npm audit reports a policy-violating vulnerability in production dependencies
  • THEN the static/quality gate MUST fail and block merge

Scenario: Developer runs quality locally with audit

  • WHEN a developer runs composer quality (or the documented npm audit step it requires)
  • THEN the npm audit MUST execute as part of the gate sequence

Requirement: Domain and Application maintain minimum coverage

The CI unit gate SHALL measure code coverage for App\Domain and App\Application and MUST fail when either namespace falls below 80% (SPEC §13.7). Views, migrations, generated code, and framework code MUST NOT be required to meet this threshold.

Scenario: Coverage drop below threshold blocks merge

  • WHEN Domain or Application coverage is below 80% on the unit CI job
  • THEN the job MUST fail

Scenario: Coverage ignores non-domain layers

  • WHEN coverage is computed for the gate
  • THEN Blade views and migrations MUST NOT be counted toward the Domain/Application threshold

Requirement: Staging deploy job runs only after blocking CI jobs

When deploying from main, the staging deploy workflow MUST require the five blocking CI jobs (static, unit, feature, browser, container) to succeed before building/pushing the image and triggering Dokploy (SPEC §14.1, §14.3).

Scenario: Failed browser job prevents staging deploy

  • WHEN the browser CI job fails on main
  • THEN the staging deploy workflow MUST NOT promote a new image