The Three Quality Gates

Quality gates are recorded in the spec header, in the fields Definition Gate, Plan Gate and Delivery Gate. A skill sets a gate only with the evidence that gate requires; a later gate never stays approved on top of an invalidated earlier one.

| Campo | Valor |
| --- | --- |
| Status | Implementing |
| Definition Gate | Passed |
| Plan Gate | Passed |
| Delivery Gate | In Progress |

Values seen in the flow: Pending (not evaluated), Passed, Failed (the last check did not pass) and, for the Delivery Gate while work is underway, In Progress.

1. Definition Gate (closes Act I)

Owner: $fireskill-04-validate. Result READY sets Definition Gate: Passed and Status: Defined; NOT READY sets Failed and keeps Draft.

What it requires:

1. Format: Formato: Specsfy/2.0, the three acts in order, slug equal to the directory, package with only spec.md and optional research/.
2. Coverage: at least three distinct AC for the whole feature and for each US, FR and NFR, counted only when the AC declares the ID in **Cobre**.
3. Scenarios: Gherkin Given/When/Then in the spec, associated with requirements.
4. Interface (when Interface para pessoas: Sim): section 10 with stack, screens, information flow, menus, forms and actions, composition, components, states and accessibility. A CRUD must declare PageHeader, UTable, the ID column, edit and delete.
5. Data and context: a change of stack or persistence must be in the Definition of Done for .fireskills/STACK.md or .fireskills/DATABASE.md.
6. Structural validator: node fireskills/skills/fireskill-04-validate/scripts/validate_spec.mjs specs/<state>/<NNNN>-<slug>/spec.md (with --allow-draft while still Draft).

bun run fireskill validate is a quick linter you may run too, but it is not this gate. See Step 4.

2. Plan Gate (closes Act II)

Owners: $fireskill-05-tasks and $fireskill-06-tdd-bdd. Plan Gate: Passed sets Status: Planned.

1. Atomic tasks in section 14 with the six-item checklist (PREP, EXECUTE, VERIFY, VISUAL, EVIDENCE, IMPROVE).
2. One [TEST] [TDD] task per AC; every [CODE] task depends on its TDD predecessor.
3. Executable Vitest cases, each with its own // SPECSFY: marker, at least three per feature/US/FR/NFR.
4. A valid RED observed: the tests fail because the behavior is missing, not because of syntax or environment.
5. A [CODE] [MIGRATION] task for every schema change.
6. validate_tasks.mjs (and validate_interface_tasks.mjs for screens) pass without --allow-draft.

3. Delivery Gate (closes Act III)

Owner: $fireskill-07-implement, with the final acceptance by $fireskill-04-validate. Delivery Gate: Passed sets Status: Reviewing; the acceptance then moves the spec to completed with Status: Complete.

1. All tasks of section 14 checked, with evidence for each.
2. Whole suite green: bun run test (repository root).
3. Types clean: in apps/app, bun run typecheck and bunx vue-tsc --noEmit -p server/tsconfig.json.
4. Traceability: every AC, FR, NFR and Definition of Done item has current evidence; no open tasks, placeholders or skipped tests.
5. VISUAL done for every task with a screen.
6. Context monitor without PENDING, and build_documentation.mjs --check passing.
7. For each [MIGRATION]: the file, the command that applied it to the test database and the state query.
8. For changes in apps/functions or layers, a real sst deploy is the check that matters. It needs your explicit authorization; the flow does not run it on its own.

Invalidation

• A change of requirements, scenarios, scope, data, security or interface sends the spec back to Draft: all three gates become Pending.
• A change only of tasks, solution or test strategy sends it back to Defined: Definition Gate stays Passed; Plan Gate and Delivery Gate become Pending.

These moves are made by $fireskill-update-spec. See Late changes.