Story Statement (DRAFT — not refined)
As a team adopting pair
We want operational, process-level documentation of how the delivery workflow changes once classification, tags, and automation are in play — beyond the conceptual/reference pages that already exist
So that developers and adopters understand the new day-to-day flow (risk-driven), not only the underlying model
Why (the gap)
The concept/reference docs already exist and are good — reference/quality-model.mdx (classify, risk-matrix.md, tag projection, tiers) and the skills catalog (classify, publish-pr). What is MISSING is the operational "how the process changes" layer:
- Classification in the flow — the matrix now appears in refinement (from story context) and in review (from the diff, never lowered); how this changes what a developer sees and does per story.
- Automatic tags — what gets tagged, when, how to enable tag projection (
tech/risk-matrix.md), and what downstream consumes the tags.
- Automations — tag-driven workflows, automation-eligibility as a filter over classification tags, the supervised automation loop; how opt-in automation behaves on tagged issues.
- Risk management — tier → review effort/SLA, tier → which pre-merge gates run, fail-safe red for untagged PRs (the risk-proportional process).
- End-to-end changed developer journey — refine → classify → publish-pr → tiered pre-merge gates → tiered review → tag-driven automation.
- Adopter migration/onboarding — how an existing project turns this on (ties to the consolidated migration-flow gap).
Related (for refinement — not dependencies yet)
Classification #208 · CI gates #210 · Supervised automation #212 · publish-pr (#206) · quality model #221 · migration/versioning #214 · dogfood migration #262. Much of this can only be fully written once those capabilities are wired.
Status
Todo — NOT refined. Placeholder created deliberately unrefined; to be analyzed/refined after the current implementation waves complete.
Notes (for refinement)
- Refine with grilling — refine this story via
/pair-process-refine-story with the /pair-capability-grill sync phase (systematic AI↔human alignment), not a quick pass. The scope is broad and cross-cutting; the grill is where we pin down which guides/pages and which audience.
- Sourcing the operational content — for the "how the process changes" material, work back from the specs that drove the waves: the requirement-triage documents and their binding decisions (D1–D39 + addenda) that defined classification, tags, gates, automation, and risk tiers. Those specs carry the concrete use cases / scenarios to describe in the guides — extract the day-to-day workflows from there rather than inventing them.
Story Statement (DRAFT — not refined)
As a team adopting pair
We want operational, process-level documentation of how the delivery workflow changes once classification, tags, and automation are in play — beyond the conceptual/reference pages that already exist
So that developers and adopters understand the new day-to-day flow (risk-driven), not only the underlying model
Why (the gap)
The concept/reference docs already exist and are good —
reference/quality-model.mdx(classify,risk-matrix.md, tag projection, tiers) and the skills catalog (classify, publish-pr). What is MISSING is the operational "how the process changes" layer:tech/risk-matrix.md), and what downstream consumes the tags.Related (for refinement — not dependencies yet)
Classification #208 · CI gates #210 · Supervised automation #212 · publish-pr (#206) · quality model #221 · migration/versioning #214 · dogfood migration #262. Much of this can only be fully written once those capabilities are wired.
Status
Todo — NOT refined. Placeholder created deliberately unrefined; to be analyzed/refined after the current implementation waves complete.
Notes (for refinement)
/pair-process-refine-storywith the/pair-capability-grillsync phase (systematic AI↔human alignment), not a quick pass. The scope is broad and cross-cutting; the grill is where we pin down which guides/pages and which audience.