@guilhermefsousa/open-spec-kit 0.0.6 → 0.0.7

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@guilhermefsousa/open-spec-kit",
-  "version": "0.0.6",
+  "version": "0.0.7",
   "description": "CLI para spec-driven development com suporte a Claude Code e GitHub Copilot",
   "type": "module",
   "bin": {

package/templates/agents/agents/spec-hub.agent.md

@@ -84,13 +84,16 @@ specs/NNN-nome/
   links.md                   ← PRs + link da feature page
   audit-report.md            ← resultado do self-review do /spec
   conformance-report.json    ← validação pós-implementação do /dev
+  conformance-history.log    ← histórico de validações (append por run)
+  openapi.yaml               ← stub OpenAPI 3.0 (opcional, se REST endpoints)
 ```
 
 ## Validation checklist
 
 - [ ] Brief máx 1 página
 - [ ] Todo cenário tem Given/When/Then
-- [ ] Cenários de falha cobertos
+- [ ] Cenários de falha cobertos (401, 403, input validation 400)
+- [ ] Cenários de NFR cobertos (se PRD tem Requisitos Não-Funcionais)
 - [ ] Tasks agrupadas por repo (per projects.yml)
 - [ ] Dependências explícitas
 - [ ] Cada task = 1 PR

package/templates/agents/rules/hub_structure.instructions.md

@@ -24,7 +24,8 @@ applyTo: '**/*.md'
 
 1. Created: spec directory with brief + scenarios + contracts + tasks
 2. In progress: tasks are checked off, links.md tracks PRs
-3. Done: all tasks checked, spec directory stays (it IS the history)
+3. Post-merge sync: if implementation diverged intentionally from spec, /dev updates contracts.md and scenarios.md to match reality (Phase D.1.5)
+4. Done: all tasks checked, spec directory stays (it IS the history)
 
 Specs are NOT archived or moved. The spec directory with checked tasks IS the record.
 
@@ -39,6 +40,8 @@ Specs are NOT archived or moved. The spec directory with checked tasks IS the re
 | PR tracking | `specs/<spec>/links.md` |
 | Spec quality audit | `specs/<spec>/audit-report.md` |
 | Implementation conformance | `specs/<spec>/conformance-report.json` |
+| Conformance history | `specs/<spec>/conformance-history.log` |
+| OpenAPI stub (optional) | `specs/<spec>/openapi.yaml` |
 | Architecture overview | `docs/architecture.md` |
 | Architecture decisions | `docs/decisions/ADR-NNN.md` |
 | Lessons learned | `docs/lessons/NNN-title.md` |

package/templates/agents/rules/ownership.instructions.md

@@ -6,7 +6,7 @@ applyTo: '**/*.md'
 
 # Rule: Artifact Ownership (RACI)
 
-Every artifact in this project has exactly **one Owner** (creates it) and at most **one Updater** (can modify it after creation). Other skills may **Read** or **Validate**, but never **Write**.
+Every artifact in this project has exactly **one Owner** (creates it) and one or more designated **Updaters** (can modify it after creation under specific conditions). Other skills may **Read** or **Validate**, but never **Write**.
 
 This rule exists to prevent the "duplicate responsibility" anti-pattern where multiple skills update the same artifact with no clear authority, causing drift and conflicts.
 
@@ -16,12 +16,8 @@ This rule exists to prevent the "duplicate responsibility" anti-pattern where mu
 |----------|----------------|---------|---------|------------|
 | Demandas/ labels | /setup | — | /discovery | — |
 | Visão do Produto | /setup | — | all | — |
-| **Glossário** | /setup | **/discovery** (adds domain terms found in PRD analysis, exit gate), **/dev** (post-merge only — adds terms that emerged during implementation and weren't in the PRD) | /spec | /spec (read-only validate — if terms are missing, stop and ask dev to re-run /discovery) |
-
-> **Glossário conflict rule**: if /dev (post-merge) needs to update a term that /discovery defined, /dev's update wins — it reflects implemented reality. /dev adds a note: "Atualizado pós-merge: {reason}". If /dev adds a term that already exists with a different definition, update the definition to match implementation.
-| DD (Design Document) | /spec (via `design-doc` agent, fallback: MCP direct) | /dev (via `design-doc` agent, fallback: MCP direct) | — | — |
-
-> **DD update coordination**: /spec updates the DD FIRST (during spec phase), /dev updates AFTER MERGE (during Phase D). If /dev needs to change something /spec wrote, /dev overwrites with implemented reality (code is source of truth post-merge). No locking needed — the sequential workflow prevents simultaneous updates.
+| Glossário | /setup | /discovery (exit gate), /dev (post-merge only) | /spec | /spec (read-only validate) |
+| DD (Design Document) | /spec (via `design-doc` agent) | /dev (post-merge, via `design-doc` agent) | — | — |
 | Domínio/Regras | /setup | /dev (post-merge only) | /discovery, /spec | — |
 | Domínio/Fluxos | /setup | /dev (post-merge only) | /discovery | — |
 | Domínio/Tabelas | /setup | — | /discovery | — |
@@ -31,28 +27,35 @@ This rule exists to prevent the "duplicate responsibility" anti-pattern where mu
 | Feature labels | each skill at its transition | — | all | — |
 | Arquivados/ | /setup | — | — | — |
 
+**Glossário conflict rule**: if /dev (post-merge) needs to update a term that /discovery defined, /dev's update wins — it reflects implemented reality. /dev adds a note: "Atualizado pós-merge: {reason}".
+
+**DD update coordination**: /spec updates the DD FIRST (during spec phase), /dev updates AFTER MERGE (during Phase D). If /dev needs to change something /spec wrote, /dev overwrites with implemented reality (code is source of truth post-merge). No locking needed — the sequential workflow prevents simultaneous updates.
+
 ## Local Artifacts
 
 | Artifact | Owner (creates) | Updater | Readers | Validators |
 |----------|----------------|---------|---------|------------|
 | `projects.yml` | /setup | /spec (adds planned repos), /dev (repo URLs + status) | all | — |
-| `docs/architecture.md` | /setup | /discovery (resolves decisions), /dev (adds decisions discovered during implementation — post-merge only) | /spec, /dev | /spec (validates no blockers) |
+| `docs/architecture.md` | /setup | /discovery (resolves decisions), /dev (adds resolved decisions post-merge) | /spec, /dev | /spec (validates no blockers) |
 | `docs/lessons/` | /dev | /dev | all | — |
 | `docs/decisions/` | manual / spec-agent | — | all | — |
+| `docs/pending-confluence-updates.md` | any skill (on MCP failure) | any skill (on retry) | all | — |
 | `specs/NNN/brief.md` | /spec | — | /dev | — |
-| `specs/NNN/scenarios.md` | /spec | — | /dev | — |
-| `specs/NNN/contracts.md` | /spec | — | /dev | — |
+| `specs/NNN/scenarios.md` | /spec | /dev (post-merge sync D.1.5 — only if conformance report shows intentional divergence) | /dev | — |
+| `specs/NNN/contracts.md` | /spec | /dev (post-merge sync D.1.5 — only if conformance report shows intentional divergence) | /dev | — |
 | `specs/NNN/tasks.md` | /spec | — | /dev | — |
 | `specs/NNN/links.md` | /spec (template) | /dev (MR links) | — | — |
 | `specs/NNN/audit-report.md` | /spec (self-review) | — | /dev (reads before Phase B, blocks if ❌) | — |
+| `specs/NNN/openapi.yaml` | /spec (optional, if REST endpoints) | /dev (may extend) | — | — |
 | `specs/NNN/conformance-report.json` | /dev (Phase C.3) | /dev (overwrites per run) | CI Guard | — |
 | `specs/NNN/conformance-history.log` | /dev (Phase C.3) | /dev (appends per run) | — | — |
+| `CHANGELOG.md` (impl repo) | /dev (Phase D.4.5) | /dev | all | — |
 
-> **Conformance versioning**: `conformance-report.json` is overwritten on each /dev run. To preserve history, /dev appends a summary line to `specs/NNN/conformance-history.log`: `{timestamp} | {result} | {matching}/{total} endpoints | {matching}/{total} fields`
+**Conformance versioning**: `conformance-report.json` is overwritten on each /dev run. To preserve history, /dev appends a summary line to `specs/NNN/conformance-history.log`: `{timestamp} | {result} | {matching}/{total} endpoints | {matching}/{total} fields`
 
 ## Key Rules
 
-1. **One Writer per artifact** — if two skills both write to the same artifact, one of them is wrong. The matrix above is the source of truth.
+1. **One Owner per artifact** — each artifact has exactly one Owner that creates it. Updaters are explicitly designated in the matrix above with conditions (e.g., "post-merge only"). If a skill writes to an artifact where it is not listed as Owner or Updater, it is wrong.
 
 2. **Validate ≠ Update** — /spec validates the Glossário (checks all terms are present) but does NOT add terms. If terms are missing, it stops and asks the dev to re-run /discovery.
 
@@ -118,7 +121,7 @@ The `docs/architecture.md` "Decisões em Aberto" table uses this schema:
 
 Status values: `aberta`, `resolvida — [decisão tomada]`
 
-Only /discovery updates this column (exit gate). /spec validates that no `aberta` decision blocks /dev.
+/discovery updates this column during its exit gate. /dev may also add resolved decisions post-merge (Phase D.4) when new decisions are discovered during implementation. /spec validates that no `aberta` decision blocks /dev.
 
 ## links.md PR Table Format
 

package/templates/agents/skills/dev-orchestrator/SKILL.md

@@ -58,7 +58,7 @@ Read from `projects.yml` → `agents` section:
 
 | Role | Config key | If null or missing |
 |------|-----------|-------------------|
-| Security scan | `agents.security` | Skip scan, add note to MR: "Security scan manual necessario" |
+| Security scan | `agents.security` | Skip scan, add note to MR: "Security scan manual necessário" |
 | Code review | `agents.code_review` | Skip pre-review, notify dev |
 | Design document | `agents.design_doc` | Update DD directly no Confluence (read → append → update) |
 
@@ -75,12 +75,12 @@ Read from `projects.yml` → `agents` section:
    - Dependencies between groups
    - Parallelizable groups (marked `[P]`)
    - Execution order
-3. **Check if repos exist** — for each repo referenced in tasks.md:
+4. **Check if repos exist** — for each repo referenced in tasks.md:
    - Look up the repo in `projects.yml`
    - If `status: active` and `url` is filled → repo exists, skip
    - If `status: planned` and `url` is null → **create the repo** (see Phase A.1 below)
    - If the repo is NOT declared in projects.yml → stop and ask the dev
-4. Create GitLab/GitHub Issues (1 per task) via API or terminal:
+5. Create GitLab/GitHub Issues (1 per task) via API or terminal:
    - Title: `[NNN] task description`
    - Labels: `spec`, `NNN-feature-name`
    - Assign to the repo's issue board
@@ -256,6 +256,12 @@ The orchestrator extracts response type field names from contracts.md and asks t
 
 This artifact enables CI Guard (see below) and provides audit trail for compliance.
 
+Also append a summary line to `specs/NNN-name/conformance-history.log` (create if it doesn't exist):
+```
+{timestamp} | {result} | {matching}/{total} endpoints | {matching}/{total} fields
+```
+This preserves history across multiple /dev runs.
+
 C.4. **Run extension hooks** (if any)
 
 If the spec repo has a `hooks/pre-merge/` directory with executable scripts, run each one in alphabetical order. Each script receives two arguments: `<spec-dir>` and `<repo-dir>`.
@@ -350,10 +356,10 @@ D.3. **Update living docs on Confluence** (via MCP):
 D.4. **Post-implementation discoveries:**
 
 If implementation revealed:
-- a) A SURPRISE (unexpected behavior, edge case) → save to `docs/lessons/NNN-title.md` (template below)
+- a) A SURPRISE (unexpected behavior, edge case) → save to `docs/lessons/NNN-title.md` with template below
 - b) A NEW ARCHITECTURE DECISION (chose a pattern, discovered a constraint) → add to `docs/architecture.md` "Decisões em Aberto" table with Status: `resolvida — [decisão tomada durante implementação de {SIGLA}-NNN]`. This ensures architecture.md reflects decisions made during /dev, not just during /discovery.
 
-If something surprised during implementation → generate `docs/lessons/NNN-title.md` with template:
+Lessons template:
     ```
     ## O que aconteceu
     [description]
@@ -424,6 +430,7 @@ E.3. Validate the API (orchestrator does via curl):
    - Health check (`GET /health` → 200)
    - Minimum flow: register → login → 1 authenticated CRUD operation
    - Verify CORS (front origin must be accepted)
+   - If the spec has NFR scenarios (performance targets): run a basic load smoke test against the critical endpoint (e.g., `hey -n 100 -c 10 {url}` or equivalent) and verify the p95 response time meets the target. If load testing tooling is not available, log: "NFR validation manual necessária — tooling de load test não disponível."
 
 E.4. Validate the frontend (orchestrator checks):
    - Build passes (stack agent executes the build)
@@ -571,6 +578,9 @@ BUNDLE_SIZE=$(du -sk "$2/dist/assets/" | cut -f1)
 
 ## Validation checklist
 
+- [ ] Audit-report.md read and evaluated (no ❌ items)
+- [ ] Repos auto-created if `status: planned` (Phase A.1)
+- [ ] Feature label changed to `em-dev` on Confluence
 - [ ] Correct coding agent selected per stack
 - [ ] VCS Issues created (1 per task)
 - [ ] Tests generated before implementation (TDD)
@@ -578,7 +588,7 @@ BUNDLE_SIZE=$(du -sk "$2/dist/assets/" | cut -f1)
 - [ ] All tests pass
 - [ ] **Commit GREEN** (`feat(NNN): all tests pass [GREEN]`) done after all tests pass
 - [ ] Conformance check passed (endpoints + response fields match contracts.md)
-- [ ] Conformance report saved (`specs/NNN/conformance-report.json`)
+- [ ] Conformance report saved (`specs/NNN/conformance-report.json`) + history appended to `conformance-history.log`
 - [ ] Extension hooks passed (if any in `hooks/pre-merge/`)
 - [ ] Security scan passed
 - [ ] MR created with spec references
@@ -586,6 +596,9 @@ BUNDLE_SIZE=$(du -sk "$2/dist/assets/" | cut -f1)
 - [ ] MR rejected loop handled (if applicable — fix, re-test, re-check conformance)
 - [ ] links.md updated with MR links
 - [ ] Living docs updated on Confluence (DD, Dominio, Glossario)
+- [ ] Spec synced with implementation if intentional divergences (Phase D.1.5)
+- [ ] Architecture.md updated with new decisions if discovered during implementation (Phase D.4)
+- [ ] CHANGELOG.md updated in main repo (Phase D.4.5)
 - [ ] Feature label → `done` on Confluence
 - [ ] Lessons saved if applicable
 - [ ] GChat notifications sent at each transition

package/templates/agents/skills/discovery/SKILL.md

@@ -53,7 +53,7 @@ If NO argument was passed (user ran `/discovery` without a feature name):
    ```
 6. **Suggest execution order**: analyze the dependency graph from all features' "Depende de" fields and suggest the order that minimizes blocked time. This is a SUGGESTION — the dev chooses the final order.
 7. Ask: "Qual feature deseja trabalhar?"
-7. Proceed with the chosen feature.
+8. Proceed with the chosen feature.
 
 If argument WAS passed (e.g., `/discovery TFB-001`):
 - Locate the corresponding feature page and proceed normally.
@@ -73,7 +73,7 @@ Read these files FIRST:
 ### 1. Compile all information
 
 From Confluence (via MCP), read:
-- The feature page in `Features/` (demand extracted by /setup)
+- The feature page in `Features/` (demand extracted by /setup). Read the metadata table — especially the "Seções do PO" field, which tells you exactly which PO document sections are relevant for this feature. Use this to focus your gap analysis.
 - `Dominio/` — business rules, flows, reference tables, integrations
 - `Visao do Produto` — product scope and success metrics
 - Previous Q&A rounds on the feature page (if any)
@@ -186,6 +186,8 @@ Covered / Partial / Missing.
 
 **Special rule — PERFORMANCE**: this category can NEVER be marked as "Covered" without at least one question about: data limits (how many records per entity?), response SLA (max acceptable response time per endpoint), or expected throughput (requests/second, concurrent users). If the PO demand does not mention performance, ASK — absence of a performance requirement does not mean "no requirement", it means "undocumented implicit requirement".
 
+**Special rule — TECHNOLOGY**: this category can NEVER be marked as "Covered" without verifying: (1) all repos in projects.yml have a stack declared, (2) the declared stack supports all feature requirements (WebSocket, background jobs, full-text search, etc.), (3) the auth mechanism is defined. Absence of technology constraints does not mean the stack is fine — it means the constraint is implicit.
+
 For each category marked Partial or Missing, generate a candidate question.
 
 **Prioritize:** Impact (High/Medium/Low) x Blocks spec? (Yes/No).
@@ -277,7 +279,7 @@ After documenting technical decisions, **return to step 6** and re-evaluate: if
 
 **IF no gaps remain (or all answered):**
 
-Generate the PRD on the feature page in Confluence:
+Generate the PRD on the feature page in Confluence. **IMPORTANT: APPEND the PRD section BELOW the existing metadata table and Escopo section created by /setup — do NOT replace or remove them.**
 
 ```
 ## PRD

package/templates/agents/skills/setup-project/SKILL.md

@@ -165,7 +165,7 @@ Must contain these sections:
 - **Premissas**: assumptions stated in the PO docs (copy them, don't summarize)
 - **Escopo da v1**: what's in
 - **Fora de escopo**: what's explicitly out
-- **Riscos e dependencias criticas**: external systems without defined contracts, teams/knowledge dependencies, technical unknowns. If PO docs mention integration with an external system but no contract or API is defined, register as risk. If PO mentions a technology the team has no experience with, register as risk. If no risks identified, write "Nenhum risco critico identificado nos documentos do PO."
+- **Riscos e dependências críticas**: external systems without defined contracts, teams/knowledge dependencies, technical unknowns. If PO docs mention integration with an external system but no contract or API is defined, register as risk. If PO mentions a technology the team has no experience with, register as risk. If no risks identified, write "Nenhum risco crítico identificado nos documentos do PO."
 - **Metricas de sucesso**: if the PO defined metrics, use them. If not, write "Metricas de negocio — A CONFIRMAR. Nao definidas pelo PO." Do NOT invent metrics. Do NOT use functional test criteria as metrics.
 - **Restricoes**: mandatory tech, environment, compliance constraints
 
@@ -381,7 +381,7 @@ In the local spec repo:
 | # | Decisao | Impacto | Bloqueia | Status |
 |---|---------|---------|----------|--------|
 | 1 | Worker separado ou parte da API? | Alto — define repos e CI | /spec | aberta |
-| 2 | Valores do enum de Status | Medio — afeta model e validacao | /dev | aberta |
+| 2 | Valores do enum de Status | Médio — afeta model e validação | /dev | aberta |
 ```
 
 Status values: `aberta`, `resolvida — [decisão tomada]`. The /discovery updates this column when resolving decisions (exit gate).
@@ -410,7 +410,7 @@ Before closing the loop, the agent MUST do a self-review:
 3. **Fix any gaps found** by updating the pages
 4. **Report** what was added/fixed in the self-review
 5. **Feature coverage**: for EACH numbered section or distinct capability in the PO documents, verify it is covered by at least one feature page. If uncovered → create a feature or add the scope to an existing one. Report: "Cobertura de features: {N}/{total} seções do PO cobertas."
-6. **Cross-cutting check**: if PO/architecture docs mention auth keywords (SSO, JWT, roles, LGPD) → verify a feature covers auth implementation. If they mention automation keywords (SLA, automático, scheduled) → verify a feature covers it. If missing → create the dedicated feature.
+6. **Cross-cutting check**: if PO/architecture docs mention auth keywords (SSO, JWT, OAuth, roles, permissões, autorização, autenticação, LGPD, rate limit) → verify a feature covers auth implementation. If they mention automation keywords (automático, SLA, prazo, timeout, scheduled, job, cron, fechamento automático) → verify a feature covers it. If missing → create the dedicated feature. Use the same trigger keywords from Phase B.
 
 ### 6. Close the loop
 
@@ -487,10 +487,13 @@ The output is considered good when:
 ### Spec repo updated
 - [ ] projects.yml filled with all detected repos (status: planned, not commented)
 - [ ] docs/architecture.md draft with Mermaid diagrams (flowchart, erDiagram) and open decisions table
+- [ ] `docs/lessons/` and `docs/decisions/` directories created
 
 ### Quality gates
 - [ ] Self-review performed (re-read PRD vs. output)
+- [ ] Figma context read and incorporated (if configured)
 - [ ] No business context was invented
 - [ ] All ambiguities marked "A CONFIRMAR" with explanation
 - [ ] Unreadable attachments listed as "NAO PROCESSADO"
 - [ ] Demand label changed to `processado` (verified)
+- [ ] GChat notification sent (if webhook configured)

package/templates/agents/skills/specifying-features/SKILL.md

@@ -70,7 +70,7 @@ If `projects.yml` has `figma.file_url` and Figma MCP is available:
 ### 1. Read PRD from Confluence
 
 From Confluence (via MCP), read the approved PRD on the feature page.
-Extract: requirements, decisions, scope, out of scope, assumptions.
+Extract: requirements, decisions, scope, out of scope, assumptions, and NFRs (if the PRD has a "Requisitos Não-Funcionais" section).
 
 ### 2. Identify features in the PRD
 
@@ -139,6 +139,7 @@ Numbering is sequential: find the highest existing number in `specs/` and increm
   - Default pagination (no params → uses defaults)
   - Last page (partial results)
   - Invalid page values (page ≤ 0, pageSize > max) — expected: 400 or clamped to defaults
+- **NFR scenarios (if PRD has "Requisitos Não-Funcionais")**: for each measurable NFR target (e.g., "GET /bills < 200ms p95"), create at least one CT-NNN-XX scenario with a concrete Given/When/Then. Example: `Given 50 concurrent users, When GET /api/v1/bills with filters, Then p95 response time < 200ms`. If the NFR is not measurable in a test (e.g., "99.9% uptime"), include it in brief.md under "Restrições" instead. Add NFR-related tasks to tasks.md (e.g., "add response time middleware", "configure rate limiting").
 - **No unresolved markers (MANDATORY)**: specs MUST NOT contain any of these markers anywhere — including inside code blocks and code examples:
   `MOCKADO`, `TODO`, `A CONFIRMAR`, `TBD`, `FIXME`, `PLACEHOLDER`, `TKTK`
   If any assumption is not validated, go back to /discovery to resolve it.
@@ -165,9 +166,9 @@ Numbering is sequential: find the highest existing number in `specs/` and increm
    | UpdatedAt | DateTime | Sim | Data de última atualização |
    ```
 5. **Error codes**: every error code specific to this feature, as constants/enum
-5. **Validation rules** (as a top-level `##` section, NOT nested inside a per-stack section): every field validation (required, format, max length, valid values)
-6. **Response examples**: at least one success example and one error example per endpoint, with HTTP status code
-7. **Shared types**: if this feature DEFINES types that other features will reuse (ex: ErrorResponse, PaginatedResponse), mark them in a `## Tipos compartilhados` section. If this feature USES types from another feature, REFERENCE them ("Ver contracts.md da feature NNN") — do NOT copy the full definition. If extending a type, define only the extension.
+6. **Validation rules** (as a top-level `##` section, NOT nested inside a per-stack section): every field validation (required, format, max length, valid values)
+7. **Response examples**: at least one success example and one error example per endpoint, with HTTP status code
+8. **Shared types**: if this feature DEFINES types that other features will reuse (ex: ErrorResponse, PaginatedResponse), mark them in a `## Tipos compartilhados` section. If this feature USES types from another feature, REFERENCE them ("Ver contracts.md da feature NNN") — do NOT copy the full definition. If extending a type, define only the extension.
 
 Additional structural rule: **editável entities MUST have both `CriadoEm` and `AtualizadoEm` fields**. If an entity can be modified via PUT/PATCH, it needs `AtualizadoEm` for auditability.
 
@@ -229,7 +230,7 @@ This is a STUB — /dev may extend it during implementation. Mark as draft: `inf
 
 If the feature has no REST endpoints (e.g., worker-only feature), skip this step.
 
-
+### 4. Self-review and audit
 
 Before generating the DD or closing the loop, run ALL checks below. Fix any failures, then generate the audit report.
 
@@ -242,9 +243,11 @@ Before generating the DD or closing the loop, run ALL checks below. Fix any fail
    - Response type defined
    - At least one success example and one error example
    - Error codes cover all failure scenarios
-4. **Auth consistency**: if feature has authenticated endpoints, confirm a CT for "sem token → 401" exists
-5. **Pagination consistency**: if any endpoint returns lists, confirm pagination scenarios exist
-6. **Cross-feature types**: if contracts.md defines a type that already exists in another feature's contracts.md, replace with a reference
+4. **Auth consistency**: if feature has authenticated endpoints, confirm CTs exist for: "sem token → 401", "role errado → 403"
+5. **Input validation**: for each endpoint accepting user input, confirm at least one CT for "input malformado → 400" exists
+6. **Pagination consistency**: if any endpoint returns lists, confirm pagination scenarios exist
+7. **Cross-feature types**: if contracts.md defines a type that already exists in another feature's contracts.md, replace with a reference
+8. **NFR coverage**: if the PRD has a "Requisitos Não-Funcionais" section, confirm each measurable NFR has at least one CT scenario. Non-measurable NFRs should appear in brief.md "Restrições"
 
 If ANY check fails, fix the spec files BEFORE proceeding. Report what was fixed.
 
@@ -258,9 +261,11 @@ If ANY check fails, fix the spec files BEFORE proceeding. Report what was fixed.
 | 1 | REQ → Scenarios | ✅ 12/12 | All REQs have ≥1 scenario |
 | 2 | RN → Scenarios | ✅ 8/8 | All RNs have ≥1 scenario |
 | 3 | Endpoints → Contracts | ✅ 6/6 | All endpoints have request/response/errors |
-| 4 | Auth (401 scenario) | ✅ 1/1 | CT-NNN-XX covers |
-| 5 | Pagination scenarios | ✅ 2/2 | CT-NNN-XX, CT-NNN-YY |
-| 6 | Cross-feature types | ✅ OK | References only, no redefinitions |
+| 4 | Auth (401 + 403 scenarios) | ✅ 2/2 | CT-NNN-XX (401), CT-NNN-YY (403) |
+| 5 | Input validation (400 scenarios) | ✅ 3/3 | One per input endpoint |
+| 6 | Pagination scenarios | ✅ 2/2 | CT-NNN-XX, CT-NNN-YY |
+| 7 | Cross-feature types | ✅ OK | References only, no redefinitions |
+| 8 | NFR coverage | ✅ 2/2 | Each measurable NFR has CT scenario |
 
 **Generated**: YYYY-MM-DD
 **Fixed during review**: (list what was added/corrected, or "none")
@@ -372,8 +377,10 @@ If a Confluence operation fails mid-flow (updating DD, changing labels, reading
 - [ ] Every scenario has Given/When/Then
 - [ ] Happy path covered for every endpoint/behavior
 - [ ] Failure scenarios covered (validation errors, not found, ownership)
-- [ ] Auth scenario (401 without token) present if feature has authenticated endpoints
+- [ ] Auth scenarios (401 without token + 403 wrong role) present if feature has authenticated endpoints
+- [ ] Input validation scenarios (malformed input → 400) present for each endpoint accepting user input
 - [ ] Pagination scenarios present if any endpoint returns paginated lists
+- [ ] NFR scenarios present if PRD has "Requisitos Não-Funcionais" section (each measurable target has a CT)
 - [ ] Edge cases covered (boundary values, empty results, duplicates)
 
 ### Contracts quality
@@ -389,9 +396,17 @@ If a Confluence operation fails mid-flow (updating DD, changing labels, reading
 - [ ] Each task = 1 PR
 - [ ] links.md has correct Confluence page link
 
+### Artifacts
+- [ ] `audit-report.md` generated with all checks passing
+- [ ] `openapi.yaml` generated (if feature has REST endpoints)
+- [ ] Figma freshness check performed (if configured)
+
 ### Integration
 - [ ] DD updated on Confluence
+- [ ] Glossary validated on Confluence (all PRD terms present)
+- [ ] All open decisions in architecture.md resolved (no blockers for /dev)
 - [ ] Feature label updated on Confluence → `em-spec`
+- [ ] All spec files committed and pushed
 - [ ] GChat notification sent
 - [ ] Lessons from docs/lessons/ applied