devendra-skill-package 1.0.2

package/.github/skills/test-case-validator/docs/FAQ.md

@@ -0,0 +1,88 @@
+# FAQ / Design Rationale
+
+## Why does Rule 16 (Gated-Behavior Wiring) exist as its own rule instead of living inside Rule 1?
+
+This came directly from running v1 of this skill (a single traceability-
+focused prompt) against a real, well-tested React module. Every one of five
+separate requirements had a passing, mapped test case — Rule 1 would have
+reported 100% traceability for all five. But in every one of those five
+cases, the test covered the *underlying logic* (a pure function, a
+component given the condition as a direct prop, a Redux slice's state
+transition) and nothing covered the *actual wiring* — the screen's
+`useEffect` or click handler that reads the real feature flag or deep-link
+signal and triggers the behavior in production.
+
+The distinction matters because these are different failure modes with
+different fixes. A Rule 1 gap means "write a test." A Rule 16 gap means
+"the test that exists gives false confidence — write a *different* test,
+at a different point in the code, or the passing suite is lying to you
+about whether the feature actually works." Folding this into Rule 1 as a
+sub-bullet buried the second, more dangerous failure mode behind a
+technically-true "covered" status. Giving it a separate rule and a separate
+report section (Section 17) makes it impossible to miss.
+
+## Why is a "Near Duplicate" not treated as a duplicate for scoring purposes?
+
+Because layered testing — a unit test proving a formula is correct, plus a
+component test proving the UI renders that formula's output correctly — is
+not redundant. It's two different failure modes being independently
+guarded: a formula bug and a rendering bug. A validator that penalizes this
+pattern would push teams toward *removing* legitimate coverage to improve
+their score, which is the opposite of what a QA audit should incentivize.
+Rule 8 explicitly separates this case out and the Quality Score's
+Duplicates fraction (`QUALITY_SCORING.md`) only counts Exact Duplicates
+against it.
+
+## Why does the skill require a Suggested Test Case on every observation, but forbid writing the test case itself?
+
+Two different jobs, two different skills. This skill's job is *diagnosis*:
+find the gap, prove it with evidence, say what's missing precisely enough
+that someone could act on it. Writing the actual test (with real fixtures,
+real assertions, wired into the actual test runner) requires understanding
+the codebase's specific patterns, mocking conventions, and existing test
+utilities — that's authoring, and it's a different scope of work (this
+repository's `tdd-spec-generator` skill is closer to that job). Keeping the
+line here means this skill stays fast and cheap to run repeatedly as an
+audit, rather than becoming a slow, code-writing task every time.
+
+## Why is a separate BRD not required?
+
+Because plenty of real engineering organizations — including spec-driven
+ones — don't produce one. A single `spec.md` containing user stories,
+functional requirements, and success criteria is a complete, legitimate
+requirements source. Treating its absence as an error (v1's behavior) meant
+the skill was unusable for an entire category of real projects for a
+process reason, not a quality reason. Combined Spec Mode
+(`CONFIGURATION.md`) fixes this without lowering the bar: every check that
+would have applied to a separate BRD still applies to the combined
+document — it's just not being asked for twice.
+
+## Why do project profiles exist instead of one universal checklist?
+
+Because a universal checklist that includes Database Coverage, Localization,
+and Browser Compatibility for a project that has none of those things
+produces a report whose 0%-across-the-board sections train the reader to
+stop trusting the tool's severity signal — real gaps get lost in noise from
+fake ones. The Applicability Matrix (`CONFIGURATION.md`) is the fix: mark
+what genuinely doesn't apply as `N/A` with a stated reason, so every
+remaining "Missing" in the report is real and worth acting on.
+
+## How is Severity assigned consistently across such different kinds of findings?
+
+Via the rubric in `prompts/10-observation-report.md` step 3: severity is
+anchored to *risk tier* (itself evidence-based, per Rule 10) plus whether
+the finding is a security/financial/compliance concern, a Wiring Gap on a
+risky gate, or a recurring pattern across multiple requirements. It is
+never assigned by how the finding "feels" while writing the report — if two
+auditors ran this skill against the same inputs, they should assign the
+same severity to the same finding, because the rubric is evidence-based,
+not impression-based.
+
+## What if the same skill run needs to validate multiple features at once?
+
+Run the pipeline once per feature/module and produce one report per feature
+— don't try to force multiple unrelated feature's requirements into one
+RTM. If there's a genuine cross-feature concern (a shared component tested
+once but consumed by three features, each with their own spec), note the
+shared test case's mapping to all three in each feature's own RTM row,
+rather than merging the features' reports together.

package/.github/skills/test-case-validator/docs/VERSIONING.md

@@ -0,0 +1,55 @@
+# Versioning Policy
+
+This skill follows semantic versioning. The version lives in two places that
+must always agree: `SKILL.md`'s frontmatter `metadata.version` and
+`config/default.config.yaml`'s `skill.version`.
+
+## MAJOR (x.0.0)
+
+A change that would produce a structurally different report for the same
+inputs, or that changes a non-negotiable behavior in `SYSTEM_PROMPT.md`.
+Examples: restructuring the report's section order or count, changing what
+"PASS" means, removing or renumbering an existing rule, changing the
+canonical data model in `TRACEABILITY_ENGINE.md` §1 in a way that breaks
+old extraction output.
+
+The 1.0.0 → 2.0.0 change (see `CHANGELOG.md`) qualifies: it changed report
+structure (added Section 17), added a new required pipeline step (Rule 16,
+Rule 17), and changed default behavior for missing `BRD_INPUT` from
+"required" to "Combined Spec Mode."
+
+## MINOR (x.y.0)
+
+A new capability that doesn't change existing behavior for existing inputs.
+Examples: a new project profile, a new supported input format, a new
+optional configuration field with a backward-compatible default, a new
+`examples/` entry.
+
+## PATCH (x.y.z)
+
+A clarification, a bug fix in a formula (e.g. a coverage-percentage
+denominator was wrong), a wording fix, a corrected example — anything that
+doesn't change the report's shape or the skill's documented behavior, only
+brings the actual behavior in line with what was already documented.
+
+## Changing `config/default.config.yaml`'s Defaults
+
+Changing a *default* value (e.g. `pass_threshold` from 95 to 90) is a MINOR
+bump if it's additive/backward compatible (existing configs still work,
+they just get a different default when they don't override it) — but
+document it prominently in `CHANGELOG.md` since it silently changes every
+future report's PASS/FAIL line for anyone not pinning their own
+`CONFIG_OVERRIDE_INPUT`.
+
+## Deprecating a Rule
+
+Per `EXTENDING.md`, rules are never renumbered or removed outright. To
+deprecate:
+
+1. Mark the rule in `VALIDATION_RULES.md` with a `**Deprecated as of
+   vX.Y.0** — superseded by Rule N` note at the top of its section, but
+   leave the rule's content in place for historical reference.
+2. Stop invoking it from `SKILL.md`'s Execution Steps.
+3. Note the deprecation and its replacement in `CHANGELOG.md`.
+4. This is a MAJOR bump if any report the rule used to appear in changes
+   shape as a result (it usually does).

package/.github/skills/test-case-validator/examples/example-1-manual-qa-ecommerce/input-brd.md

@@ -0,0 +1,43 @@
+# Business Requirement Document — Checkout Module
+
+## RQ-10 — Discount Code Calculation
+
+The system MUST calculate the discounted total as:
+
+```
+discountedTotal = subtotal - (subtotal * discountPercent / 100)
+```
+
+Discount codes are percentage-based only in this release (no flat-amount
+codes). `discountPercent` is an integer between 1 and 100 inclusive. A code
+with `discountPercent` outside this range is invalid and MUST be rejected
+before the calculation runs.
+
+## RQ-11 — Discount Code Eligibility
+
+A discount code is valid only if all of the following hold:
+- It exists in the active codes table.
+- Its expiry date is on or after today.
+- It has not already been redeemed by this account (single-use codes only
+  in this release).
+
+## RQ-12 — Payment Failure Handling
+
+On any payment gateway failure, the order MUST NOT be created, and the
+cart's contents MUST be preserved so the shopper can retry without
+re-adding items. The specific failure reason (insufficient funds, card
+declined, network timeout) MUST be surfaced to the shopper per RQ-13.
+
+## RQ-13 — Payment Failure Messaging
+
+| Failure Reason | Message Shown |
+|---|---|
+| Insufficient funds | "Your payment was declined due to insufficient funds." |
+| Card declined (other) | "Your card was declined. Please try a different payment method." |
+| Network timeout (>15s) | "We couldn't confirm your payment. Please try again." |
+
+## RQ-14 — Audit Logging
+
+Every discount-code application attempt (successful or rejected) MUST be
+logged with: account ID, code, timestamp, and outcome, for fraud-monitoring
+purposes.

package/.github/skills/test-case-validator/examples/example-1-manual-qa-ecommerce/input-test-cases.csv

@@ -0,0 +1,9 @@
+Test Case ID,Title,Module,Requirement ID,User Story,Preconditions,Test Data,Steps,Expected Result,Priority,Severity,Test Type,Automation Candidate,Owner,Status
+TC-001,Apply valid 10% discount code,Checkout,RQ-10,US-01,Cart subtotal is 1000,"code=SAVE10, discountPercent=10",Add code SAVE10 and apply,Total shows 900,High,High,Positive,Yes,QA-1,Ready
+TC-002,Apply invalid discount code,Checkout,RQ-11,US-01,Cart subtotal is 1000,code=FAKE20 (not in active codes table),Add code FAKE20 and apply,Error shown; total remains 1000,High,Medium,Negative,Yes,QA-1,Ready
+TC-003,Remove an applied discount code,Checkout,US-01,US-01,Code SAVE10 already applied,code=SAVE10,Tap remove on the applied code,Total reverts to 1000,Medium,Low,Positive,Yes,QA-1,Ready
+TC-004,Discount boundary - minimum percent,Checkout,RQ-10,,Cart subtotal is 1000,discountPercent=1,Apply a code with discountPercent=1,Total shows 990,Medium,Low,Boundary,Yes,QA-2,Ready
+TC-005,Discount boundary - maximum percent,Checkout,RQ-10,,Cart subtotal is 1000,discountPercent=100,Apply a code with discountPercent=100,Total shows 0,Medium,Low,Boundary,Yes,QA-2,Ready
+TC-006,Apply code not in active codes table,Checkout,RQ-11,US-01,Cart subtotal is 1000,code=FAKE20 (not in active codes table),Add code FAKE20 and apply,Error shown; total remains 1000,High,Medium,Negative,Yes,QA-2,Ready
+TC-007,Payment fails due to insufficient funds,Checkout,RQ-12; RQ-13,US-02,Cart has items; payment method has insufficient funds,payment_method=test_card_insufficient_funds,Submit payment,"""Your payment was declined due to insufficient funds."" shown; order not created; cart preserved",High,High,Negative,Yes,QA-3,Ready
+TC-008,Discount code expired,Checkout,RQ-11,US-01,Code EXPIRED5 exists with expiry date in the past,code=EXPIRED5,Add code EXPIRED5 and apply,Error shown; total remains unchanged,Medium,Medium,Negative,Yes,QA-2,Ready

package/.github/skills/test-case-validator/examples/example-1-manual-qa-ecommerce/input-user-story.md

@@ -0,0 +1,29 @@
+# User Story — Checkout Discount Application
+
+**US-01**: As a shopper, I want a valid discount code applied to my cart
+total at checkout, so that I pay the discounted price before confirming my
+order.
+
+Priority: P1
+
+**Acceptance Criteria**:
+1. Given a cart with a subtotal of ₹1,000 and a valid 10%-off code, when the
+   code is applied, then the displayed total is ₹900.
+2. Given an invalid or expired discount code, when the shopper attempts to
+   apply it, then an error message is shown and the total remains
+   unchanged.
+3. Given a valid discount code already applied, when the shopper removes
+   it, then the total reverts to the original subtotal.
+
+**US-02**: As a shopper, I want to see a clear error if my payment fails, so
+that I understand whether to retry or use a different payment method.
+
+Priority: P2
+
+**Acceptance Criteria**:
+1. Given a payment attempt that fails due to insufficient funds, when the
+   failure response is received, then a specific "insufficient funds"
+   message is shown.
+2. Given a payment attempt that fails due to a network timeout, when no
+   response is received within 15 seconds, then a generic "please try
+   again" message is shown and the order is not created.

package/.github/skills/test-case-validator/examples/example-1-manual-qa-ecommerce/output-report.md

@@ -0,0 +1,303 @@
+# Test Case Validation Report — Checkout Discount & Payment Failure
+
+Generated: 2026-07-08 · Project Profile: `manual_qa` (explicit) · BRD Mode: Separate BRD
+
+## 1. Executive Summary
+
+This validates 8 manually-authored test cases against 5 BRD requirements
+(RQ-10–RQ-14) and 2 user stories (US-01, US-02, 5 acceptance criteria total).
+**Headline finding**: the discount-calculation formula (RQ-10) is correctly
+implemented and verified by its tests, but audit logging (RQ-14) — called
+out in the BRD specifically for fraud monitoring — has zero test coverage,
+and the payment-failure path (RQ-12/13) is only one-third tested against its
+own documented failure-reason table.
+
+**Scope**
+
+| Category | Applicable? | Reason if N/A |
+|---|---|---|
+| All Rule 2–11 categories | Applicable | `manual_qa` profile disables no categories |
+
+**Configuration used**: Project Profile `manual_qa` (explicit) · BRD Mode:
+Separate BRD · Scoring weights: default.
+
+## 2. Requirement Traceability Matrix
+
+| Requirement ID | Requirement | User Story | Mapped Test Cases | Status | Observation |
+|---|---|---|---|---|---|
+| RQ-10 | Discount calculation formula | US-01 | TC-001 (T1), TC-004 (T1), TC-005 (T1) | Partial | Formula-verified and correct (see §12), but only 3 tests against a High-risk minimum of 5 (see §16) |
+| RQ-11 | Discount eligibility (3 conditions) | US-01 | TC-002/TC-006 (T1, duplicate), TC-008 (T1) | Partial | 2 of 3 eligibility conditions tested (not-in-table, expired); "already redeemed by this account" is untested |
+| RQ-12 | Payment failure — no order created, cart preserved | US-02 | TC-007 (T1) | Partial | Only the insufficient-funds path is tested; card-declined-other and network-timeout paths are not |
+| RQ-13 | Payment failure messaging (3 reasons) | US-02 | TC-007 (T1) | Partial | Only 1 of 3 documented messages verified |
+| RQ-14 | Audit logging of discount attempts | — | None | **Missing** | Zero test cases reference RQ-14 — orphan requirement |
+| US-01-AC1 | Valid code → discounted total | US-01 | TC-001 (T1) | Full | — |
+| US-01-AC2 | Invalid/expired code → error, total unchanged | US-01 | TC-002/TC-006 (T1), TC-008 (T1) | Full | Covered, though TC-002/TC-006 are an exact duplicate (see §14) |
+| US-01-AC3 | Remove applied code → total reverts | US-01 | TC-003 (T1) | Full | — |
+| US-02-AC1 | Insufficient-funds failure message | US-02 | TC-007 (T1) | Full | — |
+| US-02-AC2 | Network-timeout (15s) failure message | US-02 | None | **Missing** | Orphan acceptance criterion |
+
+No orphan test cases found — every one of TC-001–TC-008 maps to at least one
+requirement.
+
+## 3. User Story Validation
+
+| Story | Priority | ACs Covered | Status |
+|---|---|---|---|
+| US-01 — Discount code application | P1 | 3/3 | Full |
+| US-02 — Payment failure messaging | P2 | 1/2 | Partial |
+
+## 4. BRD Validation
+
+| Requirement | Status | Note |
+|---|---|---|
+| RQ-10 | Partial | See §2 |
+| RQ-11 | Partial | See §2 |
+| RQ-12 | Partial | See §2 |
+| RQ-13 | Partial | See §2 |
+| RQ-14 | Missing | See §2 |
+
+## 5. Acceptance Criteria Validation
+
+| AC | Positive | Negative | Boundary | Business Rule | Status |
+|---|---|---|---|---|---|
+| US-01-AC1 | ✓ TC-001 | — (n/a, this AC is the positive path) | ✓ TC-004/TC-005 (via RQ-10) | ✓ formula verified | Full |
+| US-01-AC2 | n/a | ✓ TC-002/006, TC-008 | — | — | Full |
+| US-01-AC3 | ✓ TC-003 | — | — | — | Full |
+| US-02-AC1 | n/a | ✓ TC-007 | — | — | Full |
+| US-02-AC2 | n/a | ✗ none | — | — | **Missing** |
+
+## 6. Frontend Coverage Report
+
+| Category | Status | Evidence |
+|---|---|---|
+| Error Message display | Full | TC-002, TC-007, TC-008 all assert specific message text |
+| Field Validation | Missing | No test case exercises the discount-code input field itself (empty/whitespace/max-length) |
+| Loading State | Missing | Payment-in-flight state not tested |
+| Success Message | Partial | Discounted total is asserted (TC-001) but no explicit "code applied" confirmation UI is tested |
+| Others (Navigation, Accessibility, Responsive, Theme, etc.) | Missing | Not referenced anywhere in the provided test cases |
+
+## 7. Backend Coverage Report
+
+| Category | Status | Evidence |
+|---|---|---|
+| Business Logic / Calculations | Full | TC-001, TC-004, TC-005 |
+| Data Validation | Partial | Code-existence and expiry checked; single-use/already-redeemed not checked |
+| API/Payment Gateway Failure Handling | Partial | Only insufficient-funds path (TC-007) |
+| Audit Trail / Logging | Missing | RQ-14 — see §2 |
+| Retry / Timeout | Missing | Network-timeout path (US-02-AC2) untested |
+
+## 8. Functional Coverage Report
+
+| Dimension | Status |
+|---|---|
+| Positive | Full |
+| Negative | Partial — payment-failure negative paths incomplete |
+| Boundary | Full — RQ-10's 1% and 100% boundaries both tested |
+| Business Rule | Partial — see §12 |
+
+## 9. API Coverage
+
+Not applicable as a distinct section beyond §7 — this example has no
+separately-documented API contract (the BRD describes payment-gateway
+behavior at the business-rule level, not as an API spec). If a future
+version of this BRD adds explicit request/response contracts, re-run this
+section against them directly.
+
+## 10. Database Coverage
+
+| Category | Status | Evidence |
+|---|---|---|
+| Discount code redemption record (single-use enforcement) | Missing | No test verifies a redeemed code is marked as such / rejected on reuse |
+| Audit log persistence (RQ-14) | Missing | See §2 |
+
+## 11. Security Coverage
+
+No explicit security requirements in this BRD beyond fraud-monitoring
+(RQ-14, untested) and single-use code enforcement (RQ-11, partially
+untested). Both are flagged in the Observation Report as High severity —
+fraud-prevention controls with no verification are a security-relevant gap
+even though the BRD doesn't use the word "security."
+
+## 12. Business Rule Coverage
+
+| Rule | Source | Test Evidence | Formula/Logic Match? | Status |
+|---|---|---|---|---|
+| RQ-10 discount formula | BRD RQ-10 | TC-001 (1000, 10% → 900), TC-004 (1000, 1% → 990), TC-005 (1000, 100% → 0) | **Yes** — `1000 - (1000*10/100) = 900` ✓; `1000 - (1000*1/100) = 990` ✓; `1000 - (1000*100/100) = 0` ✓ | Full |
+| RQ-11 eligibility (3 conditions) | BRD RQ-11 | TC-002/006 (not in table), TC-008 (expired) | Partially — 2 of 3 conditions have test evidence; "already redeemed" has none | Partial |
+| RQ-12 no-order-on-failure + cart preservation | BRD RQ-12 | TC-007 | Yes, for the one path tested | Partial |
+| RQ-13 message mapping (3 reasons) | BRD RQ-13 | TC-007 (insufficient funds only) | Yes, for the one path tested | Partial |
+| RQ-14 audit logging | BRD RQ-14 | None | Not verifiable — no test exists | Missing |
+
+## 13. Missing Scenario Report
+
+| Category | Applicable? | Present? | Affected Requirement(s) | Note |
+|---|---|---|---|---|
+| Timeout | Yes | No | RQ-12, RQ-13, US-02-AC2 | Network-timeout failure path entirely untested |
+| Duplicate Data | Yes | No | RQ-11 | "Already redeemed by this account" condition untested |
+| Max/Min Length, Special Characters | Yes | No | RQ-11 (code format) | No test exercises malformed/oversized discount-code input |
+| Audit/Logging verification | Yes | No | RQ-14 | See §2, §12 |
+| Concurrent Users | Yes | No | RQ-11 | A single-use code redeemed by two concurrent requests is not tested (race condition on "already redeemed") |
+
+## 14. Duplicate Test Case Report
+
+| Test Case A | Test Case B | Classification | Recommendation |
+|---|---|---|---|
+| TC-002 | TC-006 | **Exact Duplicate** — identical requirement (RQ-11), identical test data (`FAKE20`), identical steps and expected result | Remove one. Recommend keeping TC-002 (created earlier, same owner as the rest of the US-01 set) and retiring TC-006, or repurposing TC-006 to instead cover the untested "already redeemed" condition from RQ-11 |
+| TC-004 | TC-005 | Partial Duplicate — same requirement and shape, different boundary values (1% vs. 100%) | Legitimate boundary-pair testing, not redundant — no action needed |
+
+## 15. Test Case Quality Report
+
+| Test Case ID | Issue | Impact |
+|---|---|---|
+| TC-003 | `Requirement ID` field left blank; only mapped via the `User Story` column | Minor — traceability still resolves via US-01, but breaks any tooling that filters strictly by Requirement ID |
+| TC-007 | `Requirement ID` field lists two IDs (`RQ-12; RQ-13`) in a format inconsistent with every other row's single-ID convention | Cosmetic, but worth standardizing (e.g. a dedicated multi-ID delimiter convention) before this suite grows |
+
+## 16. Risk Coverage Report
+
+| Requirement/Feature | Risk Tier (+ why) | Test Count | Meets Minimum (5)? | Gap |
+|---|---|---|---|---|
+| RQ-10 (money calculation) | High — direct monetary calculation | 3 | No | Add 2 more: a discount applied to a non-round subtotal (rounding behavior undocumented — flag this as an open question too), and a code with `discountPercent` outside 1–100 to confirm rejection |
+| RQ-11 (eligibility, fraud-adjacent) | High — guards a single-use, potentially-abusable code | 3 (2 distinct + 1 duplicate) | No | Add "already redeemed" and a concurrent-redemption test |
+| RQ-12/RQ-13 (payment failure) | High — irreversible action (order creation) + direct financial impact | 1 | No | Add card-declined-other and network-timeout scenarios |
+| RQ-14 (audit logging) | High — explicit fraud-monitoring purpose stated in BRD | 0 | No | See §2 Observation |
+
+## 17. Gated-Behavior Wiring Report
+
+Not applicable in this example — this BRD/User Story pair describes no
+feature-flag-, role-, or deep-link-gated behavior. (Discount-code validity
+is a data-driven eligibility check, not a conditional feature toggle, so
+Rule 16 does not apply here. See Example 2 for a worked Rule 16 finding.)
+
+## 18. Observation Report
+
+### RQ-14 (Audit Logging) has zero test coverage
+**Severity**: High
+**Evidence**: BRD RQ-14 states every discount-code attempt "MUST be logged
+... for fraud-monitoring purposes." No test case in the provided suite (TC-
+001 through TC-008) references RQ-14.
+**Affected Requirement(s)**: RQ-14
+**Affected Test Case(s)**: None — orphan requirement
+**Impact**: A fraud-monitoring control explicitly called out in the BRD
+could ship unverified; if the logging call is ever accidentally removed or
+broken, nothing in this suite would catch it.
+**Recommendation**: Add a test asserting a log entry is written on both a
+successful and a rejected discount-code attempt, including account ID,
+code, timestamp, and outcome.
+**Suggested Test Case**: "Given a shopper applies an invalid discount code,
+when the rejection is processed, then an audit log entry is written with
+outcome=rejected, the account ID, the code, and a timestamp." Mirror for the
+successful case with outcome=applied.
+
+### Payment-failure path is two-thirds untested against its own documented table
+**Severity**: High
+**Evidence**: BRD RQ-13 documents 3 distinct failure messages (insufficient
+funds, card declined, network timeout). Only TC-007 exists, covering
+insufficient funds only.
+**Affected Requirement(s)**: RQ-12, RQ-13, US-02-AC2
+**Affected Test Case(s)**: TC-007 (partial)
+**Impact**: A shopper whose card is declined for a reason other than
+insufficient funds, or whose payment times out, may see the wrong message
+or no message at all — this is a support-ticket generator in production
+even though it wouldn't crash anything.
+**Recommendation**: Add the two missing failure-reason test cases before
+this ships.
+**Suggested Test Case**: "Given a payment attempt that times out after 15
+seconds with no gateway response, when the timeout is reached, then 'We
+couldn't confirm your payment. Please try again.' is shown and no order is
+created."
+
+### RQ-11's "already redeemed" eligibility condition is untested
+**Severity**: Medium
+**Evidence**: BRD RQ-11 lists three eligibility conditions; only "exists in
+active codes table" (TC-002/006) and "expiry date" (TC-008) have test
+evidence.
+**Affected Requirement(s)**: RQ-11
+**Affected Test Case(s)**: TC-002, TC-006, TC-008 (all partial toward RQ-11)
+**Impact**: A single-use code could potentially be reapplied by the same
+account if this condition has a bug — direct financial/fraud exposure.
+**Recommendation**: Add the missing condition test; consider also a
+concurrent-redemption race-condition test given RQ-11's single-use intent.
+**Suggested Test Case**: "Given code SAVE10 was already redeemed by this
+account, when the shopper attempts to apply it again, then it is rejected
+as already-used."
+
+### TC-002 and TC-006 are an exact duplicate
+**Severity**: Low
+**Evidence**: See §14.
+**Affected Requirement(s)**: RQ-11
+**Affected Test Case(s)**: TC-002, TC-006
+**Impact**: Maintenance overhead only — no functional risk.
+**Recommendation**: Retire TC-006 or repurpose it for the "already
+redeemed" gap above, which needs a test case anyway.
+**Suggested Test Case**: N/A (this observation recommends removing/
+repurposing, not adding).
+
+## 19. Recommendations
+
+1. **Add the audit-logging test (RQ-14)** — highest severity, currently zero
+   coverage of an explicitly-stated fraud control.
+2. **Complete the payment-failure test set (RQ-12/13)** — two of three
+   documented failure paths are unverified.
+3. **Add the "already redeemed" and concurrent-redemption tests (RQ-11)** —
+   closes a fraud-adjacent gap and meets the High-risk minimum.
+4. **Repurpose TC-006** into the "already redeemed" test from #3 instead of
+   leaving it as a duplicate.
+5. **Standardize the `Requirement ID` field convention** (single ID per row,
+   or a documented multi-ID delimiter) — low effort, prevents future
+   traceability tooling issues.
+
+## 20. Overall Quality Score
+
+| Category | Weight | Fraction | Points |
+|---|---|---|---|
+| Requirement Traceability | 25 | 0.60 | 15 |
+| Coverage | 20 | 0.65 | 13 |
+| Acceptance Criteria | 15 | 0.80 | 12 |
+| Frontend Coverage | 10 | 0.40 | 4 |
+| Backend Coverage | 10 | 0.80 | 8 |
+| Business Rules | 10 | 0.50 | 5 |
+| Quality | 5 | 0.75 | 4 |
+| Duplicates | 5 | 0.875 | 4 |
+| **Total** | | | **65** |
+
+## Final Summary
+
+TEST CASE VALIDATION SUMMARY
+
+Project Profile: manual_qa
+BRD Mode: Separate BRD
+
+Total Requirements: 5
+Covered Requirements: 4 (0 Full + 4 Partial)
+Missing Requirements: 1
+
+Total User Stories: 2
+Covered User Stories: 2 (1 Full + 1 Partial)
+
+Total Acceptance Criteria: 5
+Covered Acceptance Criteria: 4
+
+Total Test Cases: 8
+
+Requirement Coverage: 60%
+Acceptance Criteria Coverage: 80%
+Frontend Coverage: 40%
+Backend Coverage: 80%
+Functional Coverage: ~70%
+Negative Coverage: 60%
+Boundary Coverage: 100%
+Business Rule Coverage: 50%
+API Coverage: N/A — no separately-documented API contract in this example
+Database Coverage: 0%
+Security Coverage: Low (2 High-severity gaps: RQ-14, RQ-11 redemption reuse)
+Automation Coverage: 100% (all 8 marked "Automation Candidate: Yes")
+
+Duplicate Test Cases: 1 exact, 1 partial (legitimate boundary pair)
+
+Missing Scenarios: 5 categories (see Section 13)
+
+Gated-Behavior Wiring Gaps: N/A — no gated behavior in this example
+
+Overall Quality Score: 65/100
+
+Status: **FAIL**

package/.github/skills/test-case-validator/examples/example-2-automated-frontend-suite/input-spec.md

@@ -0,0 +1,43 @@
+# Feature Specification: Beta Features Toggle
+
+**Status**: Draft — no separate BRD exists for this feature; this document
+is the sole source of requirements (Combined Spec Mode applies).
+
+## User Scenarios & Testing
+
+### User Story 1 - Enable Beta Features (Priority: P2)
+
+As a user, I want to enable beta features from Settings, so I can access
+early functionality including a Beta Dashboard.
+
+**Acceptance Scenarios**:
+
+1. **Given** the Beta Features toggle is off, **When** I turn it on,
+   **Then** my preference is persisted and the Home screen shows a Beta
+   Dashboard entry card.
+2. **Given** the toggle is on, **When** I turn it off, **Then** the entry
+   card disappears from Home and my preference is persisted as off.
+3. **Given** the beta-features flag is off, **When** I navigate directly to
+   the Beta Dashboard route via a deep link, **Then** I am redirected to
+   Home instead of seeing the Beta Dashboard.
+
+## Requirements
+
+### Functional Requirements
+
+- **FR-001**: The Settings screen MUST render a "Beta Features" toggle,
+  defaulting to off for users who have never set a preference.
+- **FR-002**: Toggling "Beta Features" MUST persist the new preference
+  value immediately.
+- **FR-003**: The Home screen MUST show a Beta Dashboard entry card only
+  when the beta-features preference is true, and MUST hide it otherwise.
+  Tapping the entry card MUST navigate to the Beta Dashboard route.
+- **FR-004**: Direct navigation to the Beta Dashboard route (e.g. via a deep
+  link) MUST redirect to Home when the beta-features preference is false.
+
+## Success Criteria
+
+- **SC-001**: A user who has never touched the toggle sees no Beta
+  Dashboard entry card on Home.
+- **SC-002**: Toggling on and reloading the app (simulated preference
+  persistence) still shows the entry card.

package/.github/skills/test-case-validator/examples/example-2-automated-frontend-suite/input-test-files-index.md

@@ -0,0 +1,56 @@
+# Test Case Input — Automated Suite Index
+
+`TEST_CASE_INPUT`: `src/features/{settings,home,beta-dashboard}/**/*.test.{ts,tsx}`
+
+This represents the automated test source the skill parses per
+`prompts/03-extraction-test-cases.md` §B. In a real run, the skill reads the
+actual files; this index is the flattened summary used to keep this example
+readable.
+
+```
+src/features/settings/domain/services/betaFeaturePreference.test.ts
+  describe('betaFeaturePreference')
+    it('persists true when toggled on (FR-002)')
+    it('persists false when toggled off (FR-002)')
+    it('defaults to false when no preference has ever been set (FR-001)')
+
+src/features/settings/presentation/components/BetaFeatureToggle.test.tsx
+  describe('BetaFeatureToggle')
+    it('renders as off by default')
+    it('calls onToggle with the new value when clicked')
+
+src/features/home/presentation/components/BetaDashboardEntryCard.test.tsx
+  describe('BetaDashboardEntryCard')
+    it('renders the entry card label')
+    it('calls onClick when tapped')
+
+src/features/home/presentation/screens/HomeScreen.test.tsx
+  describe('HomeScreen')
+    it('shows the standard home content')
+    it('shows the refresh button')
+    // note: no test in this file sets the real beta-features preference
+    // true/false and asserts the entry card's presence/absence
+
+src/features/beta-dashboard/presentation/routes/betaDashboardGuard.test.ts
+  describe('betaDashboardGuard')
+    it('redirects to home when the beta-features preference is false (FR-004)')
+    it('allows access when the beta-features preference is true (FR-004)')
+```
+
+## Notes for the Extraction Step
+
+- `betaFeaturePreference.test.ts`'s three tests carry explicit `(FR-NNN)`
+  tags → **Tier 1** mapping.
+- `BetaFeatureToggle.test.tsx` and `BetaDashboardEntryCard.test.tsx` have no
+  inline tags, but live in the module structurally implied by FR-001/FR-003
+  → **Tier 2** structural mapping, `confirmed`.
+- `HomeScreen.test.tsx`'s two tests ("standard home content," "refresh
+  button") are **pre-existing Home-screen tests unrelated to this feature**
+  — they do not mention beta features, toggles, or the entry card at all.
+  The extraction step correctly excludes them from this feature's RTM
+  rather than flagging them as orphans; they simply belong to a different,
+  out-of-scope requirement set. This distinction matters: not every test in
+  a shared file is automatically "in scope" for the feature being audited.
+- `betaDashboardGuard.test.ts`'s two tests are the actual **integration-level**
+  evidence for FR-004 — they exercise the real route guard reading the real
+  preference value, not a mocked/injected condition.