qfai 1.2.2 → 1.2.4

package/README.md

@@ -62,8 +62,8 @@ QFAI includes a small set of custom prompts (stored under `.qfai/assistant/promp
 - **qfai-require**: Produce `require.md` in the requirements directory from your idea or discussion output.
 - **qfai-spec**: Produce `.qfai/specs/*` and `.qfai/contracts/*` from the requirements, including traceability scaffolding.
   - Includes a preflight step that bootstraps missing `qfai.config.yaml` and `assistant/steering/*` when run directly after init.
-- **qfai-atdd**: Implement acceptance tests (ATDD) driven by specs/scenarios.
-- **qfai-tdd-red**: Implement fast tests first (unit/component/integration).
+- **qfai-atdd**: Implement acceptance tests (E2E/API/Integration) and drive Scenario Coverage to 100% using a Coverage Ledger.
+- **qfai-tdd-red**: Implement fast tests first (unit/component) and drive Unit/Component Scenario Coverage to 100% using a Coverage Ledger.
 - **qfai-tdd-green**: Implement production code to make the tests pass.
 - **qfai-tdd-refactor**: Refactor safely after tests are green.
 - **qfai-verify**: Run/interpret the local quality gates and produce a PR-ready summary.
@@ -137,6 +137,7 @@ Operational notes.
 - Each custom prompt must output in the user’s language (absolute requirement).
 - Except `qfai-discuss`, each prompt must analyze the project context (architecture, tech stack, test framework, repo structure) before generating artifacts or code.
 - Prompts should delegate work to multiple role-based sub-agents (Planner, Architect, Contract Designer, QA, Code Reviewer, etc.) to emulate a real delivery flow.
+- /qfai-atdd and /qfai-tdd-red must maintain a Coverage Ledger and do not declare completion until missing=0 (exceptions documented).
 
 ## Configuration
 
@@ -161,6 +162,7 @@ validation:
     testFileGlobs:
       - "src/**/*.test.ts"
       - "tests/**/*.spec.ts"
+      - "features/**/*.feature"
     testFileExcludeGlobs:
       - "**/fixtures/**"
     scMustHaveTest: true
@@ -227,6 +229,11 @@ QFAI uses a small, opinionated set of artifacts to reduce ambiguity and prevent
 
 Traceability is validated across these artifacts, so code changes remain grounded in the specs and the tests prove compliance.
 
+Traceability evidence can be provided in two ways:
+
+- `QFAI:SC-XXXX-XXXX` annotations inside test code
+- `@SC-XXXX-XXXX` tags inside `.feature` files (Cucumber-style acceptance tests)
+
 ### Test strategy tags (optional)
 
 You can annotate scenarios with lightweight test strategy metadata to keep the test pyramid/trophy healthy.
@@ -235,6 +242,8 @@ These tags are opt-in and only produce warnings, so you can roll them out gradua
 - Layer tags: `@layer-unit`, `@layer-component`, `@layer-integration`, `@layer-api`, `@layer-e2e`
 - Size tags: `@size-s`, `@size-m`, `@size-l`
 
+Traceability enforcement is layer-aware: once any SC in a layer has test evidence, coverage for that layer becomes mandatory; layers without evidence are deferred until tests exist.
+
 ## Continuous integration (GitHub Actions)
 
 (GitHub Actions)

package/assets/init/.qfai/assistant/agents/code-reviewer.md

@@ -9,6 +9,7 @@
 - Findings with severity
 - Suggested fixes
 - Residual risks and testing gaps
+- Layer-scope drift check (ATDD vs TDD)
 
 ## Non-goals
 
@@ -20,6 +21,7 @@
 
 - Follow `.qfai/assistant/instructions/*` and `.qfai/assistant/steering/*`
 - Keep outputs specific and testable
+- Flag layer drift (e.g., unit/component tests created during ATDD)
 - If evidence is missing, mark TBD and ask targeted questions
 
 ## Output format

package/assets/init/.qfai/assistant/agents/coverage-planner.md

@@ -3,11 +3,13 @@
 ## Mission
 
 - Enumerate cases using coverage techniques and provide saturation evidence.
+- Build Coverage Ledger entries for Scenario Coverage (done/missing/exception).
 
 ## Deliverables
 
 - Case Catalogue with required fields
 - Saturation stop-rule evidence
+- Coverage Ledger entries with status per SC
 - Notes on missing coverage or ambiguity
 
 ## Non-goals
@@ -22,6 +24,7 @@
   security abuse, concurrency/idempotency/retry, and ops/observability coverage
 - Do not use numeric targets; coverage must be proven by methods + saturation
 - Contracts-first: cases must map to existing contracts only
+- Do not declare completion until Coverage Ledger shows missing=0 (exceptions documented)
 - If evidence is insufficient, request rework and document risks
 
 ## Output format

package/assets/init/.qfai/assistant/agents/planner.md

@@ -2,12 +2,13 @@
 
 ## Mission
 
-- Create a phased plan with tests and risk controls.
+- Create a phased plan with tests, coverage ledger steps, and risk controls.
 
 ## Deliverables
 
 - Step-by-step plan
 - Test strategy
+- Coverage Ledger plan and exception register
 - Risk and mitigation notes
 
 ## Non-goals

package/assets/init/.qfai/assistant/agents/qa-engineer.md

@@ -3,12 +3,14 @@
 ## Mission
 
 - Identify edge cases and validation criteria for quality.
+- Audit Coverage Ledger completeness (missing=0 or exceptions).
 
 ## Deliverables
 
 - QA checklist
 - Failure-case coverage
 - Suggested regression tests
+- Coverage Ledger audit findings
 
 ## Non-goals
 
@@ -20,6 +22,7 @@
 
 - Follow `.qfai/assistant/instructions/*` and `.qfai/assistant/steering/*`
 - Keep outputs specific and testable
+- Do not fix missing coverage yourself; request rework when ledger is incomplete
 - If evidence is missing, mark TBD and ask targeted questions
 
 ## Output format

package/assets/init/.qfai/assistant/agents/qa-gatekeeper.md

@@ -3,11 +3,13 @@
 ## Mission
 
 - Act as the final quality gate and approve only with strong evidence.
+- Block approval unless Coverage Ledger is complete.
 
 ## Deliverables
 
 - Gate decision with evidence summary
 - Blocking issues and required rework list
+- Coverage Ledger audit decision
 
 ## Non-goals
 
@@ -20,6 +22,7 @@
 - Assume upstream artifacts have gaps; demand proof of coverage
 - Contracts-first: traceability must map to existing contracts only
 - Do not claim coverage by counts; use coverage techniques + saturation evidence
+- Require missing=0 (or explicit exceptions) in the Coverage Ledger before approval
 - If evidence is insufficient, stop the process and request rework
 
 ## Output format

package/assets/init/.qfai/assistant/agents/qa-lead.md

@@ -3,11 +3,13 @@
 ## Mission
 
 - Enforce test quality and completeness as the highest priority.
+- Block approval unless Coverage Ledger is complete.
 
 ## Deliverables
 
 - Review findings with strict acceptance criteria
 - Escalation notes and required rework items
+- Coverage Ledger audit decision
 
 ## Non-goals
 
@@ -20,6 +22,7 @@
 - Assume upstream artifacts have gaps; review for missing cases
 - Contracts-first: traceability must map to existing contracts only
 - Do not claim coverage by counts; use coverage techniques + saturation evidence
+- Require missing=0 (or explicit exceptions) in the Coverage Ledger before approval
 - If evidence is insufficient, block approval and request rework
 
 ## Output format

package/assets/init/.qfai/assistant/agents/qa-reviewer.md

@@ -3,11 +3,13 @@
 ## Mission
 
 - Validate coverage, traceability, and contracts-first adherence.
+- Audit Coverage Ledger completeness (missing=0 or exceptions).
 
 ## Deliverables
 
 - Review findings on missing cases and traceability gaps
 - Recommendations for additional tests or scenarios
+- Coverage Ledger audit findings
 
 ## Non-goals
 
@@ -20,6 +22,7 @@
 - Assume upstream artifacts have gaps; review for missing cases
 - Contracts-first: traceability must map to existing contracts only
 - Do not claim coverage by counts; use coverage techniques + saturation evidence
+- Require missing=0 (or explicit exceptions) in the Coverage Ledger before approval
 - If evidence is insufficient, request rework and document risks
 
 ## Output format

package/assets/init/.qfai/assistant/agents/test-engineer.md

@@ -9,6 +9,7 @@
 - New or updated tests
 - Test data setup
 - Coverage notes
+- Coverage Ledger updates (done/missing/exception)
 
 ## Non-goals
 
@@ -20,6 +21,7 @@
 
 - Follow `.qfai/assistant/instructions/*` and `.qfai/assistant/steering/*`
 - Keep outputs specific and testable
+- Always add SC evidence and update the Coverage Ledger
 - If evidence is missing, mark TBD and ask targeted questions
 
 ## Output format

package/assets/init/.qfai/assistant/agents/unit-test-scope-enforcer.md

@@ -9,6 +9,7 @@
 - Scope compliance review (ALLOWLIST vs DENYLIST)
 - Traceability check on tests to SPEC/BR/SC
 - Blocking issues and required follow-up actions
+- Coverage Ledger completeness check (unit/component)
 
 ## Non-goals
 
@@ -22,6 +23,7 @@
 - If the required test surface is missing, stop and request qfai-implement
 - Ensure tests are deterministic and independent
 - Require evidence of test commands and repo gate commands
+- Require missing=0 (or explicit exceptions) in the Coverage Ledger
 
 ## Output format
 

package/assets/init/.qfai/assistant/prompts/qfai-atdd.md

@@ -22,13 +22,32 @@ mode: execution-focused
 
 Turn `.qfai/specs/spec-XXXX/scenario.feature` into **runnable acceptance tests** (E2E/API/Integration) in this repository (terminal + CI).
 
+## Scope (ATDD only)
+
+- In scope: E2E, API, Integration.
+- Out of scope: Unit and Component (use `/qfai-tdd-red`).
+
 ## Success Criteria (Definition of Done)
 
+- Scenario Coverage is 100% for ATDD layers (E2E/API/Integration).
+- An ATDD Coverage Ledger exists with `missing=0` and explicit exceptions.
 - Acceptance tests exist and are runnable via documented commands.
 - Tests are stable (no flakiness) and diagnostic (failures explain why).
 - Existing acceptance automation (if any) is reused; no new framework is added without approval.
+- QFAI validate passes for ATDD layers (layer-aware traceability).
 - Quality checks (lint/typecheck/tests) pass in the repo’s standard way.
 
+## ATDD Coverage Ledger (mandatory)
+
+Create a ledger that lists every Scenario (SC) in ATDD scope:
+
+- Inputs: `.qfai/specs/**/scenario.feature`
+- Scope: `@layer-e2e`, `@layer-api`, `@layer-integration`
+- Columns: SC ID / spec pack / layer / size / test file / run command / status (`done|missing|exception`)
+- Rule: **`missing=0` is required before completion.**
+
+If a test is not automatable right now, record it as `exception` with a clear reason and a follow-up plan.
+
 ## Non‑Negotiable Principles (QFAI Articles)
 
 These principles are inspired by “constitution / articles” patterns used by other agent frameworks, but tailored to QFAI.
@@ -208,8 +227,11 @@ If acceptance/E2E automation exists:
 
 If none exists:
 
-- Propose Cucumber as the default option and explain pros/cons and posture fit.
-- Ask explicitly: "Do you allow adding Cucumber and related dependencies?"
+- Propose defaults by layer:
+  - E2E: Playwright Test
+  - Integration: Cucumber
+  - API: language-default test runner (project standard if any)
+- Ask explicitly before adding any new dependencies or runners.
 - Proceed only if the user approves. If not approved, stop and report.
 
 ## Step 2.5 — Implement Cucumber only when approved
@@ -229,15 +251,12 @@ Rules:
 - Keep step definitions reusable but not overly generic.
 - Ensure each scenario asserts observable behavior.
 
-### SC annotation rule (mandatory)
+### SC evidence rule (mandatory)
 
-Every test function/block MUST include a traceability annotation:
+Every test MUST provide traceability evidence using **one** of the following:
 
-```
-QFAI:SC-XXXX
-```
-
-Where `SC-XXXX` matches the scenario tag in `scenario.feature`.
+- Code-based tests: `QFAI:SC-XXXX-XXXX` annotation in the test file
+- Cucumber feature tests: `@SC-XXXX-XXXX` tag on the Scenario
 
 Example (TypeScript/JavaScript):
 
@@ -293,13 +312,15 @@ Provide:
 
 **Before declaring tests complete, you MUST verify:**
 
-1. Run QFAI validation:
+1. ATDD Coverage Ledger shows `missing=0` for E2E/API/Integration (exceptions documented).
+
+2. Run QFAI validation:
 
    ```bash
    qfai validate --fail-on error
    ```
 
-2. Run repository standard gates (discover from package.json/CI/docs):
+3. Run repository standard gates (discover from package.json/CI/docs):
    - format check
    - lint
    - typecheck
@@ -308,7 +329,7 @@ Provide:
 
    Record the exact commands and results.
 
-3. All gates must PASS.
+4. All gates must PASS.
 
 If you cannot run these commands (environment limitation):
 

package/assets/init/.qfai/assistant/prompts/qfai-spec.md

@@ -31,8 +31,9 @@ This prompt is intentionally strict. If you cannot satisfy the strict rules, you
 - `scenario.feature` MAY contain multiple `Scenario:` / `Scenario Outline:` blocks.
   - Recommended: **1-3 scenarios per spec pack**. If you need more, split into additional spec packs (e.g., `spec-0002`, `spec-0003`, ...).
   - SC tags must be **unique within the file** (no duplicate SC across scenarios).
-- `spec.md` MUST contain **exactly 1** Business Requirement in the form: `[BR-0001-0001][P0] ...`
-  - If you need 2+ BRs, split into additional spec packs.
+- Each Scenario MUST include exactly one layer tag and one size tag (`@layer-*`, `@size-*`).
+- `spec.md` MUST keep Business Requirements atomic: **1 BR = 1 rule** in the form: `[BR-0001-0001][P0] ...`
+  - Keep BR count under a small cap (default max 5). If you need more, split into additional spec packs.
 - `spec.md` MUST define **one primary feature slice** (one "thing" to implement). Do not define multiple features.
 
 ### Contracts First (Order of Work)
@@ -75,7 +76,7 @@ The following order is mandatory and must not be parallelized or rearranged:
 
 - A new directory exists: `.qfai/specs/spec-XXXX/` (or an existing one is updated).
 - These files exist and are coherent:
-  - `spec.md` (SDD spec; atomic slice; 1 BR)
+  - `spec.md` (SDD spec; atomic slice; BRs are 1-rule each, within the cap)
   - `case-catalogue.md` (coverage techniques + saturation evidence)
   - `delta.md` (Decision Log; includes candidates + rejected + deferred)
   - `scenario.feature` (ATDD skeleton; multiple scenarios allowed; SC tags must be unique)
@@ -337,6 +338,7 @@ These constraints ensure spec packs align with QFAI's validate rules and prevent
 - `scenario.feature` MAY contain multiple `Scenario:` / `Scenario Outline:` blocks.
 - Recommended: **1-3 scenarios per spec pack**. If you need more, **split into separate spec packs** (`spec-0002`, `spec-0003`, ...).
 - SC tags must be **unique within the file** (no duplicate SC across scenarios).
+- Each Scenario MUST include exactly one layer tag and one size tag (`@layer-*`, `@size-*`).
 
 Violation: If you exceed the recommended scenario count or duplicate SC tags, STOP and split/fix before continuing.
 
@@ -344,7 +346,8 @@ Violation: If you exceed the recommended scenario count or duplicate SC tags, ST
 
 A spec pack is **too large** if ANY of these are true:
 
-- BR lines exceed **1** (max 1; one slice = one BR)
+- BR lines exceed the cap (default max 5)
+- Any BR bundles multiple rules (use separate BRs instead)
 - **Two or more user roles** appear as the subject (e.g., admin AND regular user)
 - **Two or more primary user actions (When)** exist (e.g., register AND delete)
 - **Multiple external interface groups** are mixed (e.g., 2+ API endpoint families in one spec)
@@ -353,7 +356,7 @@ Split rule (simple):
 
 - Separate by user action (register / update / delete / etc.).
 - Error flows also require their own spec pack if they add scenarios.
-- If you need 2+ BRs, STOP and create additional spec packs.
+- If BR count exceeds the cap or a BR contains multiple rules, split into additional spec packs.
 
 ### (C) ID format (machine-verifiable)
 
@@ -388,7 +391,8 @@ Before finalizing the spec pack, verify:
 
 - [ ] Scenario count is within the recommended range (1-3), or the pack is split
 - [ ] SC tags are unique within `scenario.feature`
-- [ ] BR lines = 1 (exactly one BR per spec pack)
+- [ ] Each Scenario has exactly one layer tag and one size tag
+- [ ] BRs are 1-rule each and within the cap (default max 5)
 - [ ] `case-catalogue.md` exists with coverage + saturation evidence
 - [ ] `traceability-matrix.md` exists and links AC <-> BR <-> CASE <-> Examples
 - [ ] All referenced `.qfai/contracts/**` files exist (missing = 0)
@@ -603,6 +607,7 @@ Create a minimal but correct Gherkin skeleton aligned with acceptance criteria.
 - Recommended: **1-3 scenarios per spec pack**. If you need more, split into separate spec packs.
 - Feature must include exactly one `@SPEC-0001` tag.
 - Each Scenario must include exactly one `@SC-0001-0001` tag and at least one `@BR-0001-0001` tag.
+- Each Scenario must include exactly one `@layer-*` tag and one `@size-*` tag.
 - SC tags must be unique across scenarios in the file.
 
 Template:
@@ -615,7 +620,7 @@ Feature: <Feature name>
   Background:
     Given <common preconditions>
 
-  @SC-0001-0001 @BR-0001-0001
+  @SC-0001-0001 @BR-0001-0001 @layer-api @size-s
   Scenario: <scenario name>
     Given <specific precondition>
     When <user action>

package/assets/init/.qfai/assistant/prompts/qfai-tdd-green.md

@@ -33,10 +33,16 @@ Implement production code according to **spec + contracts + scenario** so the RE
 
 - Implementation matches the spec and contracts.
 - TDD tests pass (and ATDD tests pass when applicable).
+- Unit/Component Coverage Ledger shows `missing=0` (exceptions documented).
 - Repo quality gates pass (lint/type/build/pack as applicable).
 - Verification evidence is recorded (commands + results).
 - Program is runnable; runtime evidence is recorded and meets project-type expectations.
 
+## Coverage Ledger continuity
+
+- Review the Unit/Component Coverage Ledger from `/qfai-tdd-red`.
+- Do not declare completion until `missing=0` and exceptions are documented.
+
 ## Non‑Negotiable Principles (QFAI Articles)
 
 These principles are inspired by “constitution / articles” patterns used by other agent frameworks, but tailored to QFAI.
@@ -300,15 +306,17 @@ Iterate until all gates pass, prioritizing:
 
 **Before declaring implementation complete, you MUST verify:**
 
-1. Runtime evidence commands executed and outcomes recorded.
+1. Unit/Component Coverage Ledger shows `missing=0` (exceptions documented).
+
+2. Runtime evidence commands executed and outcomes recorded.
 
-2. Run QFAI validation:
+3. Run QFAI validation:
 
    ```bash
    qfai validate --fail-on error
    ```
 
-3. Run repository standard gates (discover from package.json/CI/docs):
+4. Run repository standard gates (discover from package.json/CI/docs):
    - format check
    - lint
    - typecheck
@@ -317,7 +325,7 @@ Iterate until all gates pass, prioritizing:
 
    Record the exact commands and results.
 
-4. All gates must PASS.
+5. All gates must PASS.
 
 If you cannot run these commands (environment limitation):
 

package/assets/init/.qfai/assistant/prompts/qfai-tdd-red.md

@@ -8,7 +8,7 @@ QFAI Prompt Body (SSOT)
 
 id: qfai-tdd-red
 title: QFAI TDD Red (Test-first)
-description: "Implement fast tests first (unit/component/integration) and stop at RED."
+description: "Implement fast tests first (unit/component) and stop at RED."
 argument-hint: "<spec-id> [--auto]"
 allowed-tools: [Read, Glob, Write, TodoWrite, Task, Bash]
 roles: [UnitTestScopeEnforcer, TestEngineer, QAEngineer, CodeReviewer]
@@ -20,7 +20,12 @@ mode: test-first
 
 ## Purpose
 
-Implement **fast tests** (unit/component/integration) that enforce the spec and provide fast feedback.
+Implement **fast tests** (unit/component) that enforce the spec and provide fast feedback.
+
+## Scope (TDD Red only)
+
+- In scope: Unit and Component tests.
+- Out of scope: E2E/API/Integration (use `/qfai-atdd`).
 
 ## Scope Guardrails (tests-only)
 
@@ -68,14 +73,26 @@ If tests cannot proceed because implementation is missing:
 
 ## Success Criteria (Definition of Done)
 
-- Unit tests exist, are deterministic, and runnable in CI.
-- Completion is based on executing the unit test suite and recording evidence.
+- Unit/Component tests exist, are deterministic, and runnable in CI.
+- Coverage Ledger for Unit/Component shows `missing=0` (exceptions documented).
+- Completion is based on executing the unit/component test suite and recording evidence.
 - Tests cover core logic and key edge cases derived from spec/scenario.
-- Tests fail meaningfully (actionable errors).
+- Tests fail meaningfully and the failing state is observed (RED evidence).
 - All changes stay within the ALLOWLIST.
 - Any production-code change includes an explicit exception rationale.
 - Repository verification commands PASS unless you are stopped at RED due to missing implementation.
 
+## TDD Coverage Ledger (Unit/Component)
+
+Create a ledger that lists every Scenario (SC) in Unit/Component scope:
+
+- Inputs: `.qfai/specs/**/scenario.feature`
+- Scope: `@layer-unit`, `@layer-component`
+- Columns: SC ID / layer / target unit or component / test file / status (`done|missing|exception`)
+- Rule: **`missing=0` is required before completion.**
+
+If a test is not automatable right now, record it as `exception` with a clear reason and a follow-up plan.
+
 ## Non‑Negotiable Principles (QFAI Articles)
 
 These principles are inspired by “constitution / articles” patterns used by other agent frameworks, but tailored to QFAI.
@@ -146,11 +163,12 @@ Simulate roles by running the same sequence yourself:
 
 1. Identify the target scope from SPEC/BR/AC/CASE/Scenario.
 2. Identify existing test framework and conventions; follow them.
-3. Implement unit tests:
+3. Build the Unit/Component Coverage Ledger and list missing items.
+4. Implement unit/component tests:
    - prioritize edge/error cases and invariants derived from CASE catalogue
    - ensure tests are deterministic and independent
-4. Run unit tests.
-5. Run repository verification commands and record evidence.
+5. Run unit/component tests.
+6. Run repository verification commands and record evidence.
 
 ## Step 0 — Load Context (always)
 

package/assets/init/.qfai/assistant/prompts/qfai-tdd-refactor.md

@@ -33,9 +33,15 @@ Refactor the codebase **without behavior change** after tests are green, preserv
 
 - Behavior remains unchanged and matches the spec and contracts.
 - TDD/ATDD tests remain green after refactor.
+- Unit/Component Coverage Ledger remains `missing=0` (exceptions documented).
 - Repo quality gates pass (lint/type/build/pack as applicable).
 - Verification evidence is recorded (commands + results).
 
+## Coverage Ledger continuity
+
+- Review the Unit/Component Coverage Ledger from `/qfai-tdd-red`.
+- Do not declare completion if the ledger regresses (missing must remain 0).
+
 ## Non‑Negotiable Principles (QFAI Articles)
 
 These principles are inspired by “constitution / articles” patterns used by other agent frameworks, but tailored to QFAI.
@@ -299,15 +305,17 @@ Iterate until all gates pass, prioritizing:
 
 **Before declaring implementation complete, you MUST verify:**
 
-1. Runtime evidence commands executed and outcomes recorded.
+1. Unit/Component Coverage Ledger shows `missing=0` (exceptions documented).
+
+2. Runtime evidence commands executed and outcomes recorded.
 
-2. Run QFAI validation:
+3. Run QFAI validation:
 
    ```bash
    qfai validate --fail-on error
    ```
 
-3. Run repository standard gates (discover from package.json/CI/docs):
+4. Run repository standard gates (discover from package.json/CI/docs):
    - format check
    - lint
    - typecheck
@@ -316,7 +324,7 @@ Iterate until all gates pass, prioritizing:
 
    Record the exact commands and results.
 
-4. All gates must PASS.
+5. All gates must PASS.
 
 If you cannot run these commands (environment limitation):
 

package/assets/init/root/qfai.config.yaml

@@ -9,6 +9,11 @@ validation:
   failOn: error
   require:
     specSections: []
+  testStrategy:
+    requireLayerTags: false
+    requireSizeTags: false
+    maxE2eScenarioRatio: null
+    maxE2eScenarioCount: null
   traceability:
     brMustHaveSc: true
     scMustHaveTest: true
@@ -17,6 +22,7 @@ validation:
       - tests/**/*.spec.ts
       - src/**/*.test.ts
       - src/**/*.spec.ts
+      - features/**/*.feature
     testFileExcludeGlobs: []
     scNoTestSeverity: error
     orphanContractsPolicy: error