Skip to content

pair-capability-verify-quality integrated with the gate matrix (local = CI) #259

Description

@rucka

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:

  1. 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

  2. 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

  3. Given no classification tags resolvable
    When verify-quality runs
    Then it applies the fail-safe (full 🔴 set) and says so explicitly in the report

  4. 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

  • All acceptance criteria implemented and verified
  • Skill follows authoring conventions; composition unchanged for callers (implement, review)
  • Code review completed and approved
  • Documentation updated — docs site (apps/website) verify-quality page updated with tier behavior
  • CLI (apps/pair-cli) updated where install/update/distribution is touched

Quality Assurance

  • Local-vs-CI parity verified per tier on a fixture repo (same check set, same verdict)
  • Fail-safe and missing-suite paths exercised

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

  • T1 — Tag/tier resolution (PR → story → fail-safe) in verify-quality
  • T2 — Gate-matrix lookup + check-set selection (skip-passing preserved)
  • T3 — Report format: tier, check set, per-check verdict, CI-parity note
  • T4 — Fixture parity tests per tier + docs site + distribution

Dependency Graph

T1 → T2 → T3 → T4

AC Coverage

Task AC1 AC2 AC3 AC4
T1
T2
T3
T4

Metadata

Metadata

Assignees

No one assigned

    Labels

    user storyWork item representing a user story

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions