Story Statement
As a developer
I want pair-capability-verify-quality integrated with the tier gate matrix — resolving the item/PR classification tags and running locally exactly the checks the CI gate will run for that tier
So that local verification mirrors CI: no surprise reds at the gate, no over-checking on green work
Where: developer machine (skill invocation, standalone or composed by implement/review) — output mirrors the CI gate verdict
Epic Context
Parent Epic: CI/CD gates tag-driven #210
Status: Refined
Priority: P0 (Must-Have)
Status Workflow
- Refined: Story is detailed, estimated, and ready for development
- In Progress: Story is actively being developed
- Done: Story delivered and accepted
Acceptance Criteria
Functional Requirements
Given-When-Then Format:
-
Given a story/PR tagged risk:green
When verify-quality runs
Then it executes install+lint+type+build only and reports the same check set the CI gate would run
-
Given a tag risk:yellow or risk:red
When verify-quality runs
Then the check set widens per the KB gate matrix (unit from 🟡; integration+E2E on 🔴), identical to CI
-
Given no classification tags resolvable
When verify-quality runs
Then it applies the fail-safe (full 🔴 set) and says so explicitly in the report
-
Given any check fails locally
When the run completes
Then the verdict is red with the failing command output surfaced, matching what CI would block on
Business Rules
- verify-quality contains NO classification criteria: it reads tags and the KB gate matrix (D18) — same single source as the pipeline
- Gate command overrides come from way-of-working adoption (existing behavior preserved); the matrix decides WHICH gates, adoption decides HOW they run
- Checks already passing are skipped (existing idempotency preserved)
Edge Cases and Error Handling
- Tags on story but not yet on PR (pre-publish): resolve from the story card
- Suite required by tier but absent locally: explicit "suite missing — CI will fail" warning, not a silent pass
- Matrix/KB not found: fall back to running all adopted gates (current behavior) with a notice
Definition of Done Checklist
Development Completion
Quality Assurance
Story Sizing and Sprint Readiness
Refined Story Points
Final Story Points: 3 (M)
Confidence Level: High
Sizing Justification: confirmed M(3) — existing skill extended with tag resolution + matrix lookup; matrix and tag mechanics delivered by the sibling pipeline story
Sprint Capacity Validation
Sprint Fit Assessment: yes
Total Effort Assessment: fits — Yes
Dependencies and Coordination
Story Dependencies
Prerequisite Stories: tier-aware pipeline story (gate matrix in KB, tag-resolution convention); #233 (tags exist)
Dependent Stories: #206 (publish-pr invokes verify-quality as gate before opening the PR)
Validation and Testing Strategy
Acceptance Testing Approach
Testing Methods: fixture repo, runs at each tier + untagged; diff the executed check list against the pipeline job set for the same tier
Test Data Requirements: tagged sample story/PR per tier
Notes and Additional Context
Refinement Session Insights: parity with CI is the whole value — the matrix must be read from the same KB source, never duplicated
Documentation Links: R8.1 · Spec G9 · D18, D21
Technical Analysis
Implementation Approach
Technical Strategy: extend verify-quality with a resolution step (tags from PR, else story card, else fail-safe red) + matrix lookup from the KB gate-matrix doc; execute the resolved check set via the adoption-declared gate commands; report verdict in gate order with per-check status
Key Components: verify-quality SKILL.md (resolution + matrix phases); shared gate-matrix reference (same doc as pipeline)
Integration Points: classification tags (#233), way-of-working gate commands, publish-pr (#206), review (#228 verdict line)
Technical Risks and Mitigation
| Risk |
Impact |
Probability |
Mitigation Strategy |
| Matrix duplication between skill and pipeline |
High |
Medium |
single KB doc referenced by both; grep check in review |
| Local env lacks CI parity (services, browsers) |
Medium |
Medium |
explicit "suite missing" warnings instead of skips |
Task Breakdown
Checklist
Dependency Graph
T1 → T2 → T3 → T4
AC Coverage
| Task |
AC1 |
AC2 |
AC3 |
AC4 |
| T1 |
✓ |
✓ |
✓ |
|
| T2 |
✓ |
✓ |
|
|
| T3 |
|
|
✓ |
✓ |
| T4 |
✓ |
✓ |
✓ |
✓ |
Story Statement
As a developer
I want
pair-capability-verify-qualityintegrated with the tier gate matrix — resolving the item/PR classification tags and running locally exactly the checks the CI gate will run for that tierSo that local verification mirrors CI: no surprise reds at the gate, no over-checking on green work
Where: developer machine (skill invocation, standalone or composed by implement/review) — output mirrors the CI gate verdict
Epic Context
Parent Epic: CI/CD gates tag-driven #210
Status: Refined
Priority: P0 (Must-Have)
Status Workflow
Acceptance Criteria
Functional Requirements
Given-When-Then Format:
Given a story/PR tagged
risk:greenWhen verify-quality runs
Then it executes install+lint+type+build only and reports the same check set the CI gate would run
Given a tag
risk:yelloworrisk:redWhen verify-quality runs
Then the check set widens per the KB gate matrix (unit from 🟡; integration+E2E on 🔴), identical to CI
Given no classification tags resolvable
When verify-quality runs
Then it applies the fail-safe (full 🔴 set) and says so explicitly in the report
Given any check fails locally
When the run completes
Then the verdict is red with the failing command output surfaced, matching what CI would block on
Business Rules
Edge Cases and Error Handling
Definition of Done Checklist
Development Completion
apps/website) verify-quality page updated with tier behaviorapps/pair-cli) updated where install/update/distribution is touchedQuality Assurance
Story Sizing and Sprint Readiness
Refined Story Points
Final Story Points: 3 (M)
Confidence Level: High
Sizing Justification: confirmed M(3) — existing skill extended with tag resolution + matrix lookup; matrix and tag mechanics delivered by the sibling pipeline story
Sprint Capacity Validation
Sprint Fit Assessment: yes
Total Effort Assessment: fits — Yes
Dependencies and Coordination
Story Dependencies
Prerequisite Stories: tier-aware pipeline story (gate matrix in KB, tag-resolution convention); #233 (tags exist)
Dependent Stories: #206 (publish-pr invokes verify-quality as gate before opening the PR)
Validation and Testing Strategy
Acceptance Testing Approach
Testing Methods: fixture repo, runs at each tier + untagged; diff the executed check list against the pipeline job set for the same tier
Test Data Requirements: tagged sample story/PR per tier
Notes and Additional Context
Refinement Session Insights: parity with CI is the whole value — the matrix must be read from the same KB source, never duplicated
Documentation Links: R8.1 · Spec G9 · D18, D21
Technical Analysis
Implementation Approach
Technical Strategy: extend verify-quality with a resolution step (tags from PR, else story card, else fail-safe red) + matrix lookup from the KB gate-matrix doc; execute the resolved check set via the adoption-declared gate commands; report verdict in gate order with per-check status
Key Components: verify-quality SKILL.md (resolution + matrix phases); shared gate-matrix reference (same doc as pipeline)
Integration Points: classification tags (#233), way-of-working gate commands, publish-pr (#206), review (#228 verdict line)
Technical Risks and Mitigation
Task Breakdown
Checklist
Dependency Graph
T1 → T2 → T3 → T4
AC Coverage