Story

Codex compatibility note:

• Invoke repository skills with $skill-name in Codex; this mirrored copy rewrites legacy Claude /skill-name references.
• Task tracker mandate: BEFORE executing any workflow or skill step, create/update task tracking for all steps and keep it synchronized as progress changes.
• User-question prompts mean to ask the user directly in Codex.
• Ignore Claude-specific mode-switch instructions when they appear.
• Strict execution contract: when a user explicitly invokes a skill, execute that skill protocol as written.
• Subagent authorization: when a skill is user-invoked or AI-detected and its protocol requires subagents, that skill activation authorizes use of the required spawn_agent subagent(s) for that task.
• Do not skip, reorder, or merge protocol steps unless the user explicitly approves the deviation first.
• For workflow skills, execute each listed child-skill step explicitly and report step-by-step evidence.
• If a required step/tool cannot run in this environment, stop and ask the user before adapting.

Codex Project-Reference Loading (No Hooks)

Codex uses static project-reference loading instead of runtime-injected project docs. When coding, planning, debugging, testing, or reviewing, open project docs explicitly using this routing.

Always read:

• docs/project-config.json (project-specific paths, commands, modules, and workflow/test settings)
• docs/project-reference/docs-index-reference.md (routes to the full docs/project-reference/* catalog)
• docs/project-reference/lessons.md (always-on guardrails and anti-patterns)

Missing/stale context route: If docs/project-config.json, the docs index, lessons.md, CLAUDE.md, AGENTS.md, or any task-required reference doc is missing or stale, auto-run $project-init or the narrow setup route ($project-config, $docs-init, $scan-all, $scan --target=<key>, $claude-md-init) before ordinary project-specific work. If Codex mirrors or AGENTS.md are missing/stale, ask the user to run $sync-codex; do not auto-run it.

Situation-based docs:

• Project structure/architecture/tech-stack/deployment/setup (any layer — backend, frontend, or infra): project-structure-reference.md
• Backend/CQRS/API/domain/entity changes: backend-patterns-reference.md, domain-entities-reference.md
• Frontend/UI/styling/design-system: frontend-patterns-reference.md, scss-styling-guide.md, design-system/README.md
• Spec authoring, docs/specs/ pathing, or TC format: feature-spec-reference.md, spec-system-reference.md, spec-principles.md
• Behavior/public-contract changes or spec-test-code sync: workflow-spec-test-code-cycle-reference.md plus the spec docs above
• Derived spec indexes/ERDs/reimplementation guides: spec-system-reference.md and source Feature Specs under docs/specs/
• Integration test implementation/review: integration-test-reference.md
• E2E test implementation/review: e2e-test-reference.md
• Code review/audit work: code-review-rules.md plus domain docs above based on changed files

Do not read all docs blindly. Start from docs-index-reference.md, then open only relevant files for the task.

[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 ask the user directly 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 ask the user directly 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 ask the user directly 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 the current task list 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 ask the user directly 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 task tracking 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 ask the user directly 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 task tracking 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

…(truncated)