Story

[BLOCKING] Execute skill steps in declared order. NEVER skip, reorder, or merge steps without explicit user approval. [BLOCKING] Before each step or sub-skill call, update task tracking: set in_progress when step starts, set completed when step ends. [BLOCKING] Every completed/skipped step MUST include brief evidence or explicit skip reason. [BLOCKING] If Task tools are unavailable, create and maintain an equivalent step-by-step plan tracker with the same status transitions.

Quick Summary

Goal: Produce sprint-ready, INVEST-valid user stories — tech-agnostic, testable GWT criteria, evidence-cited estimates, dependency-mapped — by breaking Product Backlog Items into implementable stories via vertical slicing and SPIDR splitting, so a team with zero codebase knowledge can implement on any stack.

Summary:

• Main steps (the pipeline): (1) read PBI + active plan, load domain context — module, entities, BR-IDs; (2) identify VERTICAL end-to-end slices; (3) SPIDR-split anything SP >8 (MUST) / >5 (SHOULD) until INVEST-valid; (4) write each story with min 3 GWT scenarios + 1 authorization scenario; (5) estimate bottom-up (Blast-Radius pre-pass → phase-hours → days; SP DERIVED) and emit full estimate frontmatter; (6) emit Story Dependencies table (no orphans); (7) run MANDATORY AskUserQuestion validation; (8) save to team-artifacts/pbis/stories/{YYMMDD}-ba-story-{slug}.md; (9) suggest /spec [mode=tests] next.
• Slice VERTICALLY (thin end-to-end), NEVER horizontally (backend/frontend split) — apply SPIDR (Spike/Paths/Interfaces/Data/Rules) until each story is INVEST-valid — why: horizontal slices delay deliverable user value.
• Every story is tech-agnostic + rebuild-from-scratch + demoable (AI-SDD M1-M5 and M7): no framework/class/file names in prose, carry the inherited FR-/BR- logical ID plus a [Source: namespace/service/id] abstract anchor (NEVER file:line), and every criterion states an outcome a stakeholder could SEE — reject and rework on any STOP condition.
• Min 3 GIVEN/WHEN/THEN scenarios (happy + edge + error) PLUS a mandatory authorization scenario per story; every criterion has exactly ONE observable interpretation.
• Estimate bottom-up (phase-hours → days × productivity factor; SP DERIVED, never the driver) with explicit test_count and Blast-Radius pass; emit full man_days_* / risk_* / blast_radius / estimate_reasoning frontmatter — why: SP-first anchors to a guess, downstream /prioritize+/plan read these fields.
• Story Dependencies table is mandatory (no orphan stories) and the AskUserQuestion validation interview runs before handoff — NEVER auto-decide slicing/scope/effort.

MANDATORY IMPORTANT MUST ATTENTION Plan ToDo Task to READ the following project-specific reference docs:

• project-structure-reference.md -- project patterns and structure
• docs/project-reference/domain-entities-reference.md — Domain entity catalog, relationships, cross-service sync (read when task involves business entities/models)
• docs/specs/ — Test specifications by module (read existing TCs for related features; include test story/acceptance criteria for new stories)

If file not found, search for: project documentation, coding standards, architecture docs.

Workflow:

1. Read PBI — Load PBI artifact, acceptance criteria, and domain context
2. Vertical Slice — Identify end-to-end slices of functionality
3. SPIDR Split — Apply Spike/Paths/Interfaces/Data/Rules splitting if effort >5
4. Write Stories — INVEST-validated stories with min 3 GIVEN/WHEN/THEN scenarios each
5. Validate — Interview user to confirm slicing, acceptance criteria, and effort estimates

Key Rules:

• Slice VERTICALLY (thin end-to-end); NEVER horizontally (backend/frontend split) — why: a horizontal slice ships no user-visible value on its own.
• SP >8 MUST ATTENTION be split; >5 SHOULD be split — apply SPIDR until each story is INVEST-valid.
• Every story MUST ATTENTION carry story_points, complexity, man_days_traditional, man_days_ai — plus the risk_* / blast_radius / estimate_reasoning fields /prioritize and /plan read downstream.
• SP is DERIVED from bottom-up phase-hours → days × productivity factor — NEVER the driver.
• Min 3 GIVEN/WHEN/THEN scenarios (happy + edge + error) PLUS a mandatory authorization scenario; each criterion has exactly ONE observable interpretation.
• Tech-agnostic prose ONLY — no framework/class/file names; anchor with [Source: namespace/service/id], NEVER file:line.
• Story Dependencies table is mandatory — NEVER leave an orphan story.
• Run the AskUserQuestion validation interview before handoff — NEVER auto-decide slicing, scope, or effort.

Frontend/UI Context (if applicable)

When the task involves frontend or UI changes, read:

• Component patterns: docs/project-reference/frontend-patterns-reference.md
• Styling/BEM guide: docs/project-reference/scss-styling-guide.md
• Design system tokens: docs/project-reference/design-system/README.md

Greenfield Mode

Auto-detected: no existing codebase (no discovered source directories, no manifest files, no populated project-config.json) → greenfield mode switches on automatically. Planning artifacts (docs/, plans/, .claude/) do NOT count — the repository needs actual code directories with content.

When greenfield is detected:

1. Generate foundation PBIs instead of feature stories: infrastructure setup, project scaffold, CI/CD pipeline, first feature vertical slice

2. Dependency ordering: infrastructure stories BEFORE feature stories

3. Skip the project-structure-reference.md read — it will not exist

4. Include setup stories: dev environment, build tooling, deployment pipeline, monitoring

5. Priority order: infra → scaffold → first feature → remaining features

6. [CRITICAL] Architecture Scaffolding Story: FIRST story = "Architecture Scaffolding" — every OOP/SOLID base abstract class, generic interface, and infrastructure abstraction the chosen stack needs. AI self-investigates which base classes the project requires; every feature story depends on it — why: features built on an unscaffolded foundation encode the wrong abstractions permanently.

7. Scaffolding acceptance criteria: base classes compile/type-check, DI/IoC registrations resolve, smoke test passes

8. UI System Foundation Story: If the project has a frontend, generate a "UI System Foundation" story (Sprint 0) with these sub-stories:

   Sub-Story	SP	Priority	Depends On
   "Set up design token system"	2-3	Must Have	Architecture Scaffolding
   "Create base layout and responsive grid"	2-3	Must Have	Design tokens
   "Create core UI components (loading, error, empty, toast, button, input)"	3-5	Must Have	Design tokens + layout

Dependency rule: All UI feature stories MUST ATTENTION depend on "UI System Foundation" stories.

• Each story needs happy path, edge case, and error scenario (minimum)
• Use correct project domain vocabulary when available (check project docs for terminology)

Be skeptical. Apply critical thinking, sequential thinking. Every claim needs traced proof, confidence percentages (Idea should be more than 80%).

User Story Creation

Break Product Backlog Items into implementable user stories using vertical slicing and SPIDR patterns.

Step 0: Locate Active Plan (if in workflow)

If running within a workflow (big-feature, greenfield-init, etc.):

1. Search for active plan — Glob plans/*/plan.md sorted by modification time, or check TaskList for plan context
2. Read plan.md — understand project scope, architecture decisions, domain model, implementation plan
3. Read existing research — {plan-dir}/research/*.md and {plan-dir}/phase-*.md for domain model, tech stack, architecture
4. Read docs/project-reference/domain-entities-reference.md (if exists) — understand existing domain entities for accurate story scoping
5. Use plan context to inform story slicing (architecture decisions affect how stories are split)

When to Use

• PBI ready for story breakdown
• Feature needs vertical slicing
• Creating sprint-ready work items
• Story too large (effort >8)

Quick Reference

Workflow

1. Read PBI artifact and acceptance criteria
2. Load domain context (if project module detected)
3. Identify vertical slices (end-to-end functionality)
4. Apply SPIDR splitting if stories too large
5. Apply INVEST criteria to each story
6. Create user stories with GIVEN/WHEN/THEN (min 3 scenarios)
7. Save to team-artifacts/pbis/stories/
8. Validate stories (MANDATORY) - Interview user to confirm slicing, acceptance criteria, and effort
9. Suggest next: /spec [mode=tests] or /design-spec

Output

• Path: team-artifacts/pbis/stories/{YYMMDD}-us-{pbi-slug}.md
• Format: Single file with all stories (use ## headers per story)

Artifact Path (canonical convention) — Command /story → base path team-artifacts/pbis/stories/, role token ba, type story. General filename pattern: {YYMMDD}-{role}-{type}-{slug}.md → e.g. 260119-ba-story-invoice-approval.md. Slug = lowercased basename, non-alphanumeric → -, trimmed, max 50 chars.

Project Domain Context Loading

When slicing domain-related PBIs, automatically load business context.

Step 1: Detect Module

From PBI frontmatter:

1. Check module field
2. If missing, detect module from docs/specs/ directory names

Step 2: Load Feature Context

Glob("docs/specs/{module}/*.md")

1. Read module README (first 200 lines)
2. Identify related feature from related_features list
3. Extract existing business rules (BR-{MOD}-XXX)
4. Note entity names from feature docs

Step 3: Apply Domain Vocabulary

Read docs/project-config.json modules[] and docs/specs/ to detect domain vocabulary per module. Use entity names from feature docs — avoid ambiguous synonyms.

Step 4: Include in Story

## Domain Context

**Module:** {detected module}
**Feature:** {related feature}
**Entities:** {Entity1}, {Entity2}
**Business Rules:** BR-{MOD}-XXX (from feature docs)

INVEST Criteria

SPIDR Splitting Checklist

When to apply: Story SP >8 MUST ATTENTION split. SP >5 SHOULD split. SP 13 = SHOULD split into 2-3 stories. SP 21 = MUST ATTENTION split (epic-level).

Splitting Examples

Paths: "User can pay by card OR PayPal" → Story A: Card payment, Story B: PayPal payment

Data: "Import CSV, Excel, JSON" → Story A: CSV import, Story B: Excel import, Story C: JSON import

Rules: "Different approval flows by amount" → Story A: <$1000 auto-approve, Story B: >$1000 manager approval

Size Validation

SP 1-5:   ✅ Good size
SP 6-8:   ⚠️ Consider splitting (apply SPIDR)
SP 13:    ❌ SHOULD split into 2-3 stories
SP 21:    ❌ MUST ATTENTION split — epic-level, not sprint-ready

Scenario Templates

Minimum 3 scenarios per story:

1. Happy Path (Positive)

Scenario: User successfully {completes action}
  Given {user has required permissions/state}
  And {required data exists}
  When user {performs valid action}
  Then {primary expected outcome}
  And {secondary verification if needed}

2. Edge Case (Boundary)

Scenario: System handles {boundary condition}
  Given {edge state: empty list, max items, zero value}
  When user {attempts action at boundary}
  Then {appropriate handling: pagination, warning, default}

3. Error Case (Negative)

Scenario: System prevents {invalid action}
  Given {precondition}
  When user {provides invalid input OR unauthorized action}
  Then error message "{specific error message}"
  And {system remains in valid state}
  And {no partial changes saved}

4. Authorization (MANDATORY per story)

Scenario: Unauthorized user cannot {perform action}
  Given user has role {unauthorized role}
  When user attempts to {action}
  Then system rejects with "Forbidden" or "Unauthorized"
  And no data is modified

Additional Scenario Types

Performance: Response time under load Concurrency: Simultaneous user actions Integration: External service unavailable

AI-SDD Mandate Gate (M1-M5 and M7) — BLOCKING

See .claude/skills/shared/sdd-artifact-contract.md → "AI-SDD Mandates (M1-M7)" for BLOCKING criteria. Every generated story MUST satisfy M1-M5 and M7:

• Separate intent from implementation (M1/M2): The story narrative and acceptance criteria stay tech-agnostic — describe observable business behavior, no framework/product/language/design-pattern names, no source identifiers. Keep optional hints in ## Technical Notes and source references in evidence carriers as stack-portable abstract anchors ([Source: namespace/service/id], never file:line). Prose follows docs/project-reference/spec-principles.md §3.
• Logical Requirement ID (M3): Each story carries a logical requirement ID (FR-/BR-) inherited from its parent PBI as the PRIMARY citation spine; keep the [Source: namespace/service/id] abstract anchor as a SECONDARY, stack-portable carrier — KEEP it, never remove it and never replace it with file:line (physical coordinates live only in the provenance sidecar).
• Testable GWT/EARS criteria (M4): Every Given/When/Then or EARS criterion has ONE valid interpretation, observable completion states, and named failure modes — no vague phrasing ("fast", "user-friendly", "handle appropriately") and no implementation details.
• Rebuild-from-scratch (M5): A team with zero codebase knowledge can implement identical behavior on ANY stack from the story alone.
• Business-visibility (M7): Apply the demo test to each criterion's BODY: "what would a stakeholder SEE change?" — no answer → FAIL as TECHNICAL-ONLY and drop it from the story. Every GIVEN = a state a user could arrange; every WHEN = an action a user could take; every THEN = an outcome a user could see. FAIL a WHEN that is an invocation (a handler runs, a consumer receives, a job fires, data syncs) or a THEN asserting schema/type/nullability/call-count. Judge the BODY, never the story's title or ID. Never derive the story or scenario count from an architecture inventory (handlers, consumers, jobs) — that count moves when the system is re-architected though no business behavior changed, falsifying M5.

M1 governs vocabulary; M7 governs subject matter. A technical story in impeccably tech-free prose satisfies M1 while violating M7 — "the system correctly synchronizes the record" names no framework and is still a technical case in a business costume. That gap is the most common way business specs rot. Ask what a user could SEE, not which words were used.

[STOP — rework before emitting] Reject and rework a story when ANY of these failure conditions holds:

1. Tech-specific prose — narrative/criteria name a framework, product, language type, or design-pattern class.
2. Source code reference in prose — a class/method name, file path, or namespace appears outside an evidence carrier.
3. Missing logical ID or evidence — no FR-/BR- ID, OR a requirement/rule with no [Source: namespace/service/id] abstract-anchor evidence (or explicit TBD (pre-implementation) marker).
4. Vague acceptance criteria — non-testable, non-observable, or more than one valid interpretation.
5. Not implementable from the artifact alone — a reader would have to read source or guess a rule, limit, role, or failure mode.
6. Not demoable (M7) — a criterion's body fails the demo test: its WHEN is an invocation, or its THEN asserts schema/type/nullability/call-count, or no stakeholder-visible change answers "what would they SEE?" — it is TECHNICAL-ONLY and belongs to the technical tree, not this story.

Story Artifact Template

---
id: US-{YYMMDD}-{NNN}
parent_pbi: '{PBI-ID}'
title: '{Brief story title}'
persona: '{User persona}'
priority: P1 | P2 | P3
story_points: 1 | 2 | 3 | 5 | 8 | 13
complexity: Low | Medium | High | Very High
man_days_traditional: '{ Xd (Yd code + Zd test) — from SP table }'
man_days_ai: '{ Xd (Yd code + Zd test) — from SP table with AI }'
sprint: 0 | 1 | 2 | ...
status: draft | ready | in_progress | done
module: '{ServiceA | ServiceB | ServiceC | ServiceD}'
---

# User Stories for {PBI Title}

## Story 1: {Title}

**As a** {user role}
**I want** {goal}
**So that** {benefit}

### Acceptance Criteria

#### Scenario 1: {Happy path title}

```gherkin
Given {context}
When {action}
Then {outcome}
```

#### Scenario 2: {Edge case title}

```gherkin
Given {edge state}
When {action}
Then {handling}
```

#### Scenario 3: {Error case title}

```gherkin
Given {context}
When {invalid action}
Then error "{message}"
```

---

## Story 2: {Title}

{Repeat structure...}

---

## Out of Scope

- {Explicitly excluded items}

## Story Dependencies

| Story    | Depends On | Type         | Reason                            |
| -------- | ---------- | ------------ | --------------------------------- |
| US-{NNN} | -          | independent  | First slice, no dependencies      |
| US-{NNN} | US-{NNN}   | must-after   | Needs entity/API from prior story |
| US-{NNN} | US-{NNN}   | can-parallel | Independent feature slice         |
| US-{NNN} | US-{NNN}   | blocked-by   | Requires external service/infra   |

## Domain Context

**Module:** {module}
**Related Feature:** {feature doc path}
**Entities:** {Entity1}, {Entity2}
**Requirement IDs (M3 — inherited from PBI):** {FR-XXX / BR-XXX — primary citation spine}
**Business Rules:** {BR-XXX references}
**Evidence (secondary, stack-portable):** {`[Source: namespace/service/id]` abstract anchor per requirement, or `TBD (pre-implementation)`}

## UI Wireframe

### Layout

{ASCII wireframe showing this story's UI slice — see UI wireframe protocol}

### Components

- **{ComponentName}** — {behavior for this story} _(tier: common | domain-shared | page/app)_

> Classify per **Component Hierarchy** in `UI wireframe protocol` — search existing libs before proposing new components.

### Interaction Flow

1. User {action} on {component}
2. System {response/feedback}
3. UI updates to show {result}

### States

| State   | Behavior                   |
| ------- | -------------------------- |
| Default | {what user sees initially} |
| Loading | {spinner/skeleton}         |
| Empty   | {empty state message}      |
| Error   | {error handling}           |

> If backend-only: `## UI Wireframe` → `N/A — Backend-only change. No UI affected.`

## Technical Notes

- {Implementation hints if needed}

## Validation Summary

**Validated:** {date}

### Confirmed

- {decision}: {user choice}

### Action Items

- [ ] {follow-up if any}

Sprint 0 / Foundation Stories (Production Readiness)

When the PBI includes a "Production Readiness Concerns" table with "Required" items, automatically generate Sprint 0 / foundation stories for each concern:

Rules

• Foundation stories MUST ATTENTION be completed before feature stories begin
• Mark as sprint: 0 or sprint: foundation in story metadata
• Each foundation story references the specific protocol section for implementation guidance
• If PBI concern = "Existing", skip story generation (already set up)
• If PBI concern = "No", skip story generation (explicitly opted out)

Anti-Patterns to Avoid

Key Rules

• Every story set MUST ATTENTION include a Story Dependencies table — with types: must-after, can-parallel, blocked-by, independent. This enables /prioritize and /plan to respect implementation ordering.
• SPIDR splits MUST ATTENTION include dependency chains — When splitting a story, declare which split stories depend on others.
• No orphan stories — Every story must appear in the dependency table, even if independent.

Quality Checklist

Before completing user stories:

• Each story follows "As a... I want... So that..." format
• SPIDR splitting applied (effort ≤8, prefer ≤5)
• At least 3 scenarios per story: happy, edge, error
• All scenarios use GIVEN/WHEN/THEN format
• Effort estimated in Fibonacci (1, 2, 3, 5, 8)
• Stories independent (can develop in any order)
• Out of scope explicitly listed
• Story Dependencies table included with all stories listed
• Dependency types correct (must-after, can-parallel, blocked-by, independent)
• Parent PBI linked in frontmatter
• Domain vocabulary used correctly (if the project)
• Authorization scenario included per story (unauthorized access rejection)
• Seed data story included if PBI has seed data requirements
• Data migration story included if PBI has schema changes
• Validation interview completed

Validation Step (MANDATORY)

After creating user stories, validate with user.

Question Categories

Process

1. Generate 2-4 questions focused on slicing quality, scenarios, and dependencies
2. Use AskUserQuestion tool to interview
3. Document in story artifact under ## Validation Summary
4. Update stories based on answers (split if needed)

This step is NOT optional.

Related

MANDATORY: Systematic Task Breakdown for Stories

MANDATORY IMPORTANT MUST ATTENTION break down ALL stories into small, systematic todo tasks using TaskCreate BEFORE starting implementation. Each story MUST ATTENTION have its own set of tasks that cover:

1. Read & understand story — Load story artifact, acceptance criteria, domain context
2. Identify vertical slice layers — Backend entity/command/query, frontend component/store/API, integration points
3. Create implementation subtasks per layer — One task per file or logical unit (entity, command handler, DTO, component, service, test)
4. Include spec tasks — Each story MUST ATTENTION have corresponding test specifications (unit, integration, or E2E as appropriate)
5. Include validation task — Verify story against acceptance criteria GIVEN/WHEN/THEN after implementation
6. Include review task — Final quality check per story

Task Naming Convention

[Story US-{ID}] {Layer}: {Description}

Example for a "Create Invoice" story:

[Story US-001] Entity: Create Invoice entity with validation rules
[Story US-001] Command: CreateInvoiceCommand + Handler
[Story US-001] DTO: InvoiceDto with mapping
[Story US-001] API: POST /api/invoices endpoint
[Story US-001] Component: InvoiceCreateFormComponent
[Story US-001] Store: InvoiceVmStore with create action
[Story US-001] Test: Integration test for CreateInvoiceCommand
[Story US-001] Test: E2E test for invoice creation flow
[Story US-001] Review: Verify against AC scenarios

Why: Without systematic task breakdown, stories become monolithic — missed edge cases, incomplete specs, context loss during implementation.

Next Steps

MANDATORY IMPORTANT MUST ATTENTION — NO EXCEPTIONS after completing this skill, you MUST ATTENTION use AskUserQuestion to present these options. Do NOT skip because the task seems "simple" or "obvious" — the user decides:

• "/spec [mode=tests] (Recommended)" — Generate test specifications from stories
• "/pbi-mockup" — Generate HTML mockup report from PBI and stories
• "/plan-validate" — If stories need validation against plan
• "Skip, continue manually" — user decides

[IMPORTANT] Use TaskCreate to break ALL work into small tasks BEFORE starting — including tasks for each file read. This prevents context loss from long files. For simple tasks, AI MUST ATTENTION ask user whether to skip.

External Memory: For complex or lengthy work (research, analysis, scan, review), write intermediate findings and final results to a report file in plans/reports/ — prevents context loss and serves as deliverable.

Evidence Gate: MANDATORY IMPORTANT MUST ATTENTION — every claim, finding, and recommendation requires file:line proof or traced evidence with confidence percentage (>80% to act, <80% must verify first).

Estimation Framework — Bottom-up first; SP DERIVED; output min-max range when likely ≥3d. Stack-agnostic. Baseline: 3-5yr dev, 6 productive hrs/day. AI estimate assumes Claude Code + project context.

Method:

1. Blast Radius pass (below) — drives code AND test cost
2. Decompose phases → hours/phase → bottom_up_hours = Σ phase_hours
3. likely_days = ceil(bottom_up_hours / 6) × productivity_factor
4. Sum Risk Margin (base + add-ons) → max_days = likely_days × (1 + margin)
5. min_days = likely_days × 0.9
6. Output as range when likely_days ≥3; single point allowed <3 (still record margin)
7. man_days_ai = same range × AI speedup
8. story_points DERIVED from likely_days via SP-Days — NEVER driver. Disagreement >50% → trust bottom-up

Productivity factor: 0.8 strong scaffolding+codegen+AI hooks · 1.0 mature default · 1.2 weak patterns · 1.5 greenfield

Cost Driver Heuristic (apply BEFORE work-type row):

• UI dominates in CRUD/business apps — 1.5-3x backend (states, validation, responsive, a11y, polish)
• Backend dominates ONLY: multi-aggregate invariants, cross-service contracts, schema migrations, heavy query/perf, new event flows

Reuse-vs-Create axis (PRIMARY lever, per layer):

UI tier	Cost
Reuse component on existing screen	0.1-0.3d
Add control/column to existing screen	0.3-0.8d
Compose components into NEW screen	1-2d
NEW screen, custom layout/states/validation	2-4d
NEW shared/common component (themed, tested)	3-6d+

Backend tier	Cost
Reuse query/handler from new place	0.1-0.3d
Small update existing handler/entity	0.3-0.8d
NEW query on existing repo/model	0.5-1d
NEW command/handler on existing aggregate (additive)	1-2d
NEW aggregate/entity (repo, validation, events)	2-4d
NEW cross-service contract OR schema migration	2-4d each
Multi-aggregate invariant / heavy domain rule	3-5d

Rule: Sum tiers across UI+backend+tests, apply productivity factor. Reuse short-circuits tiers — call out.

Test-Scope drivers (compute test_count EXPLICITLY — "+tests" hand-wave is #1 failure):

Driver	Count
Happy-path journeys	1 per story / AC main flow
State-machine transitions	reachable transitions × allowed actors
Multi-entity state combos	state(A) × state(B) — REACHABLE only, not Cartesian
Authorization matrix	(owner, non-owner, elevated, unauth) × each mutation
Validation rules	1 per required field / boundary / format / cross-field
UI states (per new screen/dialog)	happy, loading, empty, error, partial — present only
Negative paths / invariants	1 per violatable business rule

Test tier (Trad, incl. setup+assert+flake)	Cost
1-5 cases, fixtures reused	0.3-0.5d
6-12 cases, 1 new fixture	0.5-1d
13-25 cases, multi-entity setup	1-2d
26-50 cases OR new state-machine coverage	2-3d
>50 cases OR full E2E journey	3-5d

Test multipliers: new fixture/seed harness +0.5d · cross-service/bus assertion +0.3d each · UI E2E ×1.5 · each new role +1-2 cases

Blast Radius (mandatory pre-pass — affects code AND test):

1. Files/components directly modified — count
2. Of those, "complex" (>500 LOC, multi-handler, central, frequently-modified) — count
3. Downstream consumers (callers, event subscribers, cross-service) — list
4. Shared/common code touched (multi-app blast) — yes/no
5. Regression scope — areas needing re-test

Rule: Complex touch → add risk_factors. Each downstream consumer → +1-3 regression cases. Blast >5 areas OR >2 complex → re-evaluate SPLIT before estimating.

Risk Margin (drives max bound):

likely_days	Base margin
<1d trivial	+10%
1-2d small additive	+20%
3-4d real feature	+35%
5-7d large	+50%
8-10d very large	+75%
>10d	+100% AND flag SHOULD SPLIT

Risk-factor add-ons (additive — enumerate in risk_factors):

Factor	+margin
touches-complex-existing-feature (>500 LOC, multi-handler, central)	+20%
cross-service-contract change	+25%
schema-migration-on-populated-data	+25%
new-tech-or-unfamiliar-pattern	+30%
regression-fan-out (≥3 downstream areas re-test)	+20%
performance-or-latency-critical	+20%
concurrency-race-event-ordering	+25%
shared-common-code (multi-consumer/multi-app)	+25%
unclear-requirements-or-design	+30%

Collapse rule: total margin >100% → STOP, split (padding past 2x is dishonesty). Margin <15% on likely_days ≥5 → under-estimated, widen.

Work-Type Caps (hard ceilings on likely_days):

Work type	Max SP	Max likely
Single field / config flag / style fix	1	0.5d
Add property to existing model + bind to existing UI	2	1d
Additive endpoint + minor UI control (button/menu/column), reuses fixtures	3	2-3d
Additive endpoint + NEW UI surface OR additive multi-layer + new domain rule + 2+ test files	5	3-5d
NEW model/aggregate OR migration OR cross-module contract OR heavy test (>1.5d) OR NEW UI + non-trivial backend	8	5-7d
NEW UI surface + (NEW aggregate OR migration OR cross-service contract)	13	SHOULD split
Cross-service contract + migration combined	13	SHOULD split
Beyond	21	MUST split

SP→Days (validation only): 1=0.5d/0.25d · 2=1d/0.35d · 3=2d/0.65d · 5=4d/1.0d · 8=6d/1.5d · 13=10d/2.0d (Trad/AI likely) AI speedup: SP 1≈2x · 2-3≈3x · 5-8≈4x · 13+≈5x. AI cost = (code_gen × 1.3) + (test_gen × 1.3) (30% review overhead).

MANDATORY frontmatter:

story_points: <n>
complexity: low | medium | high | critical
man_days_traditional: '<min>-<max>d' # range when likely ≥3d; '<N>d' when <3d
man_days_ai: '<min>-<max>d'
risk_margin_pct: <n> # base + add-ons
risk_factors: [touches-complex-existing-feature, regression-fan-out] # closed-list from add-ons; [] if none
blast_radius:
    touched_areas: <n>
    complex_touched: <n>
    downstream_consumers: [list or count]
    shared_common_code: yes | no
estimate_scope_included: [code, integration-tests, frontend, i18n, docs]
estimate_scope_excluded: [unit-tests, e2e, perf, deployment, code-review-rounds]
estimate_reasoning: |
    5-7 lines covering:
    (a) UI tier — row applied
    (b) Backend tier — row applied
    (c) Test scope — case breakdown by driver, file count, fixtures, tier row
    (d) Cost driver — dominant tier + why
    (e) Blast radius — touched, complex, regression scope
    (f) Risk factors — list driving margin; why not larger/smaller
    Example: "UI: compose Form/Table/Dialog → NEW screen (~1.5d). Backend: NEW command on existing aggregate,
    reuses validation+repo (~1d). Tests: 4 transitions × 2 actors + 3 validation + 2 UI states = 13 cases,
    1 new fixture → tier 13-25 ~1.5d. Driver: UI composition + new states. Blast: 4 areas, 1 complex.
    Risk: base 35% + touches-complex +20% = 55% → max 3.9d → range 2.5-4d."

Sanity self-check:

• likely_days ≥3d and single-point? → reject, must be range
• Margin <15% on likely_days ≥5d? → under-estimated, widen
• Margin >100%? → STOP, split instead of buffer
• Complex existing feature touched, no regression budget in (c)? → reject
• Blast >5 areas OR >2 complex, no split discussion? → reject
• Purely additive on existing model AND existing UI? → cap SP 3 unless tests >1.5d
• NEW UI surface (page/complex form/dashboard)? → SP 5+ even if backend one endpoint
• Backend cross-service / migration / multi-aggregate? → SP 8+ regardless of UI
• bottom_up_hours / 6 vs SP-Days disagreement >50%? → trust bottom-up, downgrade SP
• Without tests, SP drops ≥1 bucket? → tests dominate; state explicitly
• Reasoning called out UI vs backend vs blast vs risk factors? → if missing, add

UI System Context — For ANY task touching .ts, .html, .scss, or .css files:

MUST ATTENTION READ before implementing:

1. docs/project-reference/frontend-patterns-reference.md — component base classes, stores, forms
2. docs/project-reference/scss-styling-guide.md — BEM methodology, SCSS variables, mixins, responsive
3. docs/project-reference/design-system/README.md — design tokens, component inventory, icons

Reference docs/project-config.json for project-specific paths.

UI Wireframe — Process visual design input (Figma URLs, screenshots, wireframes) via appropriate tool BEFORE creating wireframes. Use box-drawing ASCII characters for spatial layout. Classify every component into exactly ONE tier: Common (cross-app reusable) / Domain-Shared (cross-domain) / Page (single-page). Duplicate UI code = wrong tier. Search existing component libraries before creating new (>=80% match = reuse). Detail level varies by skill (idea=rough, story=full decomposition).

Critical Thinking Mindset — Apply critical thinking, sequential thinking. Every claim needs traced proof,

…(truncated)