@zigrivers/scaffold 2.1.0

package/methodology/custom-defaults.yml

@@ -0,0 +1,43 @@
+# methodology/custom-defaults.yml
+name: Custom
+description: Choose which steps to include and how deep to go
+default_depth: 3
+
+# All steps enabled by default at depth 3 — user overrides individual steps
+steps:
+  create-prd: { enabled: true }
+  review-prd: { enabled: true }
+  innovate-prd: { enabled: false }
+  user-stories: { enabled: true }
+  review-user-stories: { enabled: true }
+  innovate-user-stories: { enabled: false }
+  domain-modeling: { enabled: true }
+  review-domain-modeling: { enabled: true }
+  adrs: { enabled: true }
+  review-adrs: { enabled: true }
+  system-architecture: { enabled: true }
+  review-architecture: { enabled: true }
+  database-schema: { enabled: true, conditional: "if-needed" }
+  review-database: { enabled: true, conditional: "if-needed" }
+  api-contracts: { enabled: true, conditional: "if-needed" }
+  review-api: { enabled: true, conditional: "if-needed" }
+  ux-spec: { enabled: true, conditional: "if-needed" }
+  review-ux: { enabled: true, conditional: "if-needed" }
+  testing-strategy: { enabled: true }
+  review-testing: { enabled: true }
+  operations: { enabled: true }
+  review-operations: { enabled: true }
+  security: { enabled: true }
+  review-security: { enabled: true }
+  implementation-tasks: { enabled: true }
+  review-tasks: { enabled: true }
+  cross-phase-consistency: { enabled: true }
+  traceability-matrix: { enabled: true }
+  decision-completeness: { enabled: true }
+  critical-path-walkthrough: { enabled: true }
+  implementability-dry-run: { enabled: true }
+  dependency-graph-validation: { enabled: true }
+  scope-creep-check: { enabled: true }
+  apply-fixes-and-freeze: { enabled: true }
+  developer-onboarding-guide: { enabled: true }
+  implementation-playbook: { enabled: true }

package/methodology/deep.yml

@@ -0,0 +1,42 @@
+# methodology/deep.yml
+name: Deep Domain Modeling
+description: Comprehensive documentation for complex systems — full analysis at every phase
+default_depth: 5
+
+steps:
+  create-prd: { enabled: true }
+  review-prd: { enabled: true }
+  innovate-prd: { enabled: true, conditional: "if-needed" }
+  user-stories: { enabled: true }
+  review-user-stories: { enabled: true }
+  innovate-user-stories: { enabled: true, conditional: "if-needed" }
+  domain-modeling: { enabled: true }
+  review-domain-modeling: { enabled: true }
+  adrs: { enabled: true }
+  review-adrs: { enabled: true }
+  system-architecture: { enabled: true }
+  review-architecture: { enabled: true }
+  database-schema: { enabled: true, conditional: "if-needed" }
+  review-database: { enabled: true, conditional: "if-needed" }
+  api-contracts: { enabled: true, conditional: "if-needed" }
+  review-api: { enabled: true, conditional: "if-needed" }
+  ux-spec: { enabled: true, conditional: "if-needed" }
+  review-ux: { enabled: true, conditional: "if-needed" }
+  testing-strategy: { enabled: true }
+  review-testing: { enabled: true }
+  operations: { enabled: true }
+  review-operations: { enabled: true }
+  security: { enabled: true }
+  review-security: { enabled: true }
+  implementation-tasks: { enabled: true }
+  review-tasks: { enabled: true }
+  cross-phase-consistency: { enabled: true }
+  traceability-matrix: { enabled: true }
+  decision-completeness: { enabled: true }
+  critical-path-walkthrough: { enabled: true }
+  implementability-dry-run: { enabled: true }
+  dependency-graph-validation: { enabled: true }
+  scope-creep-check: { enabled: true }
+  apply-fixes-and-freeze: { enabled: true }
+  developer-onboarding-guide: { enabled: true }
+  implementation-playbook: { enabled: true }

package/methodology/mvp.yml

@@ -0,0 +1,42 @@
+# methodology/mvp.yml
+name: MVP
+description: Get to code fast with minimal ceremony
+default_depth: 1
+
+steps:
+  create-prd: { enabled: true }
+  review-prd: { enabled: true }
+  innovate-prd: { enabled: false }
+  user-stories: { enabled: true }
+  review-user-stories: { enabled: true }
+  innovate-user-stories: { enabled: false }
+  domain-modeling: { enabled: false }
+  review-domain-modeling: { enabled: false }
+  adrs: { enabled: false }
+  review-adrs: { enabled: false }
+  system-architecture: { enabled: false }
+  review-architecture: { enabled: false }
+  database-schema: { enabled: false }
+  review-database: { enabled: false }
+  api-contracts: { enabled: false }
+  review-api: { enabled: false }
+  ux-spec: { enabled: false }
+  review-ux: { enabled: false }
+  testing-strategy: { enabled: true }
+  review-testing: { enabled: false }
+  operations: { enabled: false }
+  review-operations: { enabled: false }
+  security: { enabled: false }
+  review-security: { enabled: false }
+  implementation-tasks: { enabled: true }
+  review-tasks: { enabled: false }
+  cross-phase-consistency: { enabled: false }
+  traceability-matrix: { enabled: false }
+  decision-completeness: { enabled: false }
+  critical-path-walkthrough: { enabled: false }
+  implementability-dry-run: { enabled: false }
+  dependency-graph-validation: { enabled: false }
+  scope-creep-check: { enabled: false }
+  apply-fixes-and-freeze: { enabled: false }
+  developer-onboarding-guide: { enabled: false }
+  implementation-playbook: { enabled: true }

package/package.json

@@ -0,0 +1,58 @@
+{
+  "name": "@zigrivers/scaffold",
+  "version": "2.1.0",
+  "description": "AI-powered software project scaffolding pipeline",
+  "type": "module",
+  "keywords": ["scaffold", "ai", "claude", "codex", "pipeline", "prompts", "meta-prompts"],
+  "license": "MIT",
+  "repository": {
+    "type": "git",
+    "url": "https://github.com/zigrivers/scaffold.git"
+  },
+  "publishConfig": {
+    "access": "public",
+    "registry": "https://registry.npmjs.org"
+  },
+  "files": [
+    "dist/",
+    "pipeline/",
+    "knowledge/",
+    "methodology/",
+    "README.md",
+    "LICENSE"
+  ],
+  "engines": {
+    "node": ">=18"
+  },
+  "bin": {
+    "scaffold": "dist/index.js"
+  },
+  "scripts": {
+    "build": "tsc && cp src/core/knowledge/knowledge-update-template.md dist/core/knowledge/knowledge-update-template.md",
+    "test": "vitest run",
+    "test:coverage": "vitest run --coverage",
+    "test:e2e": "vitest run --config vitest.e2e.config.ts",
+    "test:bench": "vitest bench",
+    "lint": "eslint src/ tests/",
+    "type-check": "tsc --noEmit",
+    "check": "npm run lint && npm run type-check && npm test",
+    "prepublish": "bash scripts/prepublish.sh"
+  },
+  "dependencies": {
+    "@inquirer/prompts": "^7.4.0",
+    "js-yaml": "^4.1.0",
+    "yargs": "^17.7.2",
+    "zod": "^3.24.0"
+  },
+  "devDependencies": {
+    "@eslint/js": "^9.21.0",
+    "@types/js-yaml": "^4.0.9",
+    "@types/node": "^22.13.0",
+    "@types/yargs": "^17.0.33",
+    "@vitest/coverage-v8": "^3.0.7",
+    "eslint": "^9.21.0",
+    "typescript": "^5.8.2",
+    "typescript-eslint": "^8.26.0",
+    "vitest": "^3.0.7"
+  }
+}

package/pipeline/architecture/review-architecture.md

@@ -0,0 +1,44 @@
+---
+name: review-architecture
+description: Review system architecture for completeness and downstream readiness
+phase: "architecture"
+order: 12
+dependencies: [system-architecture]
+outputs: [docs/reviews/review-architecture.md]
+conditional: null
+knowledge-base: [review-methodology, review-system-architecture]
+---
+
+## Purpose
+Multi-pass review of the system architecture targeting architecture-specific
+failure modes: domain coverage gaps, ADR constraint violations, data flow
+orphans, module structure issues, state inconsistencies, diagram/prose drift,
+and downstream readiness.
+
+## Inputs
+- docs/system-architecture.md (required) — architecture to review
+- docs/domain-models/ (required) — for coverage checking
+- docs/adrs/ (required) — for constraint compliance
+- docs/prd.md (required) — for requirement tracing
+
+## Expected Outputs
+- docs/reviews/review-architecture.md — findings and resolution log
+- docs/system-architecture.md — updated with fixes
+
+## Quality Criteria
+- All architecture-specific review passes executed
+- Domain model coverage verified (every model maps to a component)
+- ADR constraint compliance verified
+- Data flow completeness verified (no orphaned components)
+- Module structure validated for practical concerns
+- Downstream readiness confirmed (specification, quality, and planning steps can proceed)
+
+## Methodology Scaling
+- **deep**: All 10 review passes (coverage, constraints, data flows, module
+  structure, state consistency, diagram integrity, extension points,
+  invariants, downstream readiness, internal consistency).
+- **mvp**: Domain coverage and ADR compliance checks only.
+- **custom:depth(1-5)**: Scale number of passes with depth.
+
+## Mode Detection
+Re-review mode if previous review exists.

package/pipeline/architecture/system-architecture.md

@@ -0,0 +1,45 @@
+---
+name: system-architecture
+description: Design and document system architecture
+phase: "architecture"
+order: 11
+dependencies: [review-adrs]
+outputs: [docs/system-architecture.md]
+conditional: null
+knowledge-base: [system-architecture]
+---
+
+## Purpose
+Design and document the system architecture, translating domain models and ADR
+decisions into a concrete component structure, data flows, and module
+organization. Project directory structure and module organization are defined here.
+
+## Inputs
+- docs/domain-models/ (required) — domain models from modeling phase
+- docs/adrs/ (required) — architecture decisions from decisions phase
+- docs/prd.md (required) — requirements driving architecture
+
+## Expected Outputs
+- docs/system-architecture.md — architecture document with component design,
+  data flows, module structure, and extension points
+
+## Quality Criteria
+- Every domain model lands in a component or module
+- Every ADR constraint is respected in the architecture
+- All components appear in at least one data flow diagram
+- Extension points are both documented and designed (not just listed)
+- Project directory structure is defined with file-level granularity
+
+## Methodology Scaling
+- **deep**: Full architecture document. Component diagrams, data flow diagrams,
+  module structure with file-level detail, state management design, extension
+  point inventory, deployment topology.
+- **mvp**: High-level component overview. Key data flows. Enough structure for
+  an agent to start building without ambiguity.
+- **custom:depth(1-5)**: Depth 1-2: MVP-style. Depth 3: add component diagrams
+  and module boundaries. Depth 4-5: full architecture approach.
+
+## Mode Detection
+If outputs already exist, operate in update mode: read existing content, diff
+against current project state and new ADRs, propose targeted updates rather
+than regenerating.

package/pipeline/decisions/adrs.md

@@ -0,0 +1,45 @@
+---
+name: adrs
+description: Document architecture decisions as ADRs
+phase: "decisions"
+order: 9
+dependencies: [review-domain-modeling]
+outputs: [docs/adrs/]
+conditional: null
+knowledge-base: [adr-craft]
+---
+
+## Purpose
+Identify and document all significant architecture decisions. Each decision gets
+its own ADR with context, options considered, decision made, and consequences.
+Technology selection (language, framework, database, infrastructure) is a key
+ADR category — tech stack decisions are documented here.
+
+## Inputs
+- docs/domain-models/ (required) — domain structure driving architecture choices
+- docs/prd.md (required) — requirements and constraints
+
+## Expected Outputs
+- docs/adrs/ — one ADR file per decision (ADR-NNN-title.md format)
+- docs/adrs/index.md — decision log overview
+
+## Quality Criteria
+- Every significant decision has an ADR (technology, patterns, trade-offs)
+- Each ADR documents alternatives considered with pros/cons
+- Decisions trace to PRD requirements or domain model constraints
+- No ADR contradicts another without explicit acknowledgment
+- Technology selections include team expertise and maintenance considerations
+
+## Methodology Scaling
+- **deep**: Comprehensive ADR set. 3+ alternatives per decision with detailed
+  evaluation. Risk assessment for each decision. Cross-references between
+  related ADRs. Supersession tracking.
+- **mvp**: Core technology choices only (language, framework, database, hosting).
+  Brief rationale. Single-paragraph ADRs.
+- **custom:depth(1-5)**: Depth 1-2: core tech choices. Depth 3: add pattern
+  and integration decisions. Depth 4-5: full evaluation with risk assessment.
+
+## Mode Detection
+If docs/adrs/ exists, operate in update mode: review existing ADRs against
+current domain models and requirements. Add new ADRs for undocumented decisions.
+Supersede ADRs whose context has changed.

package/pipeline/decisions/review-adrs.md

@@ -0,0 +1,39 @@
+---
+name: review-adrs
+description: Review ADRs for completeness, consistency, and decision quality
+phase: "decisions"
+order: 10
+dependencies: [adrs]
+outputs: [docs/reviews/review-adrs.md]
+conditional: null
+knowledge-base: [review-methodology, review-adr]
+---
+
+## Purpose
+Multi-pass review of ADRs targeting ADR-specific failure modes: contradictory
+decisions, missing rationale, implied-but-unrecorded decisions, and unresolved
+trade-offs.
+
+## Inputs
+- docs/adrs/ (required) — ADRs to review
+- docs/domain-models/ (required) — for coverage checking
+- docs/prd.md (required) — for requirement tracing
+
+## Expected Outputs
+- docs/reviews/review-adrs.md — findings and resolution log
+- docs/adrs/ — updated with fixes
+
+## Quality Criteria
+- All ADR-specific review passes executed
+- Every finding categorized by severity
+- Missing decisions identified and documented
+- Contradictions resolved
+- Downstream readiness confirmed (architecture phase can proceed)
+
+## Methodology Scaling
+- **deep**: All review passes. Full findings report. Fixes applied and re-validated.
+- **mvp**: Quick consistency check for contradictions only.
+- **custom:depth(1-5)**: Scale number of review passes with depth.
+
+## Mode Detection
+Re-review mode if previous review exists. Check which findings were addressed.

package/pipeline/finalization/apply-fixes-and-freeze.md

@@ -0,0 +1,39 @@
+---
+name: apply-fixes-and-freeze
+description: Apply validation findings and freeze documentation
+phase: "finalization"
+order: 34
+dependencies: [cross-phase-consistency, traceability-matrix, decision-completeness, critical-path-walkthrough, implementability-dry-run, dependency-graph-validation, scope-creep-check]
+outputs: [docs/validation/fix-log.md]
+conditional: null
+knowledge-base: [apply-fixes-and-freeze]
+---
+
+## Purpose
+Review all validation phase findings, create a prioritized fix plan, apply fixes
+to the relevant documents, and mark the documentation as frozen (ready for
+implementation). After this step, documents should not change unless a specific
+issue is discovered during implementation.
+
+## Inputs
+- docs/validation/*.md (required) — all validation findings
+- All phase output artifacts (to apply fixes to)
+
+## Expected Outputs
+- docs/validation/fix-log.md — log of all fixes applied
+- Updated phase artifacts with fixes applied
+- Freeze marker added to each document (tracking comment)
+
+## Quality Criteria
+- All P0 and P1 validation findings addressed
+- P2 findings addressed or explicitly deferred with rationale
+- Fix log documents what changed and why
+- All documents pass a final consistency check after fixes
+
+## Methodology Scaling
+- **deep**: All findings addressed. Full fix log. Final consistency check.
+- **mvp**: P0 findings only. Brief fix log.
+- **custom:depth(1-5)**: Scale with depth.
+
+## Mode Detection
+Not applicable — this step runs once after validation.

package/pipeline/finalization/developer-onboarding-guide.md

@@ -0,0 +1,36 @@
+---
+name: developer-onboarding-guide
+description: Create a guide for developers (human or AI) joining the project
+phase: "finalization"
+order: 35
+dependencies: [apply-fixes-and-freeze]
+outputs: [docs/onboarding-guide.md]
+conditional: null
+knowledge-base: [developer-onboarding]
+---
+
+## Purpose
+Create a comprehensive onboarding guide that gives any developer (human or AI
+agent) everything they need to understand the project and start contributing.
+This is the "start here" document.
+
+## Inputs
+- All frozen phase artifacts
+
+## Expected Outputs
+- docs/onboarding-guide.md — developer onboarding guide
+
+## Quality Criteria
+- Covers: project purpose, architecture overview, key patterns, where to find what
+- A new developer can set up and run the project following this guide
+- Key architectural decisions are summarized (with pointers to ADRs)
+- Development workflow is clear (branch, code, test, PR)
+
+## Methodology Scaling
+- **deep**: Comprehensive guide. Architecture walkthrough, key pattern explanations,
+  common tasks with examples, troubleshooting section.
+- **mvp**: Quick start. Setup instructions, key files, how to run tests.
+- **custom:depth(1-5)**: Scale detail with depth.
+
+## Mode Detection
+Update mode if guide exists.

package/pipeline/finalization/implementation-playbook.md

@@ -0,0 +1,45 @@
+---
+name: implementation-playbook
+description: Create the playbook that AI agents follow during implementation
+phase: "finalization"
+order: 36
+dependencies: [developer-onboarding-guide]
+outputs: [docs/implementation-playbook.md]
+conditional: null
+knowledge-base: [implementation-playbook]
+---
+
+## Purpose
+Create the implementation playbook — the operational document that AI agents
+reference during implementation. Defines task ordering, context requirements
+per task, coding standards, git workflow (branching/PR strategy), handoff
+format between agents, and success criteria.
+
+## Inputs
+- docs/implementation-tasks.md (required) — tasks to sequence
+- docs/system-architecture.md (required) — architecture context
+- docs/testing-strategy.md (required) — testing requirements
+- All other frozen artifacts
+
+## Expected Outputs
+- docs/implementation-playbook.md — agent implementation playbook
+
+## Quality Criteria
+- Task execution order is clear and respects dependencies
+- Each task has context requirements (which docs to read before starting)
+- Coding standards are defined (naming, patterns, error handling)
+- Git workflow is defined (branching strategy, commit format, PR process)
+- Success criteria per task (how to know it's done)
+- Handoff format between agents (what to communicate when passing work)
+- Quality gates are defined (what must pass before a task is complete)
+
+## Methodology Scaling
+- **deep**: Full playbook. Detailed coding standards, git workflow with
+  examples, per-task context briefs, inter-agent communication protocol,
+  rollback procedures for failed tasks.
+- **mvp**: Task order, basic coding conventions, commit format, "run tests
+  before marking done."
+- **custom:depth(1-5)**: Scale detail with depth.
+
+## Mode Detection
+Update mode if playbook exists.

package/pipeline/modeling/domain-modeling.md

@@ -0,0 +1,57 @@
+---
+name: domain-modeling
+description: Deep domain modeling across all identified project domains
+phase: "modeling"
+order: 7
+dependencies: [review-user-stories]
+outputs: [docs/domain-models/]
+conditional: null
+knowledge-base: [domain-modeling]
+---
+
+## Purpose
+Identify and model all domains in the project. For each domain, define entities,
+value objects, aggregates, domain events, invariants, and bounded context
+boundaries. Establish the ubiquitous language that all subsequent phases use.
+Use user stories and their acceptance criteria to discover entities, events,
+and aggregate boundaries. User actions reveal the domain model.
+
+## Inputs
+- docs/prd.md (required) — requirements defining the problem space
+- docs/reviews/pre-review-prd.md (optional) — review findings for context
+- docs/prd-innovation.md (optional) — innovation findings and approved enhancements
+- docs/user-stories.md (required) — user stories with acceptance criteria for domain discovery
+
+## Expected Outputs
+- docs/domain-models/ — one file per domain, each containing:
+  - Entity definitions with attributes and relationships
+  - Value objects and their validation rules
+  - Aggregate boundaries and roots
+  - Domain events and their triggers
+  - Invariants (business rules that must always hold)
+  - Bounded context boundary and its interfaces to other contexts
+- docs/domain-models/index.md — overview of all domains and their relationships
+
+## Quality Criteria
+- Every PRD feature maps to at least one domain
+- Entity relationships are explicit (not implied)
+- Aggregate boundaries are justified (why this grouping?)
+- Domain events cover all state transitions
+- Invariants are testable assertions, not vague rules
+- Ubiquitous language is consistent across all domain models
+- Cross-domain relationships are documented at context boundaries
+
+## Methodology Scaling
+- **deep**: Full DDD tactical patterns. Detailed entity specs with TypeScript-style
+  interfaces. Domain event flows with sequence diagrams. Context maps showing
+  relationships between bounded contexts. Separate file per domain.
+- **mvp**: Key entities and their relationships in a single file. Core business
+  rules listed. Enough to inform architecture decisions.
+- **custom:depth(1-5)**: Depth 1-2: single-file entity overview. Depth 3: separate
+  files per domain with entities and events. Depth 4-5: full DDD approach with
+  context maps and detailed invariants.
+
+## Mode Detection
+If docs/domain-models/ exists, operate in update mode: read existing models,
+identify changes needed based on updated PRD or new understanding. Preserve
+existing decisions unless explicitly revisiting them.

package/pipeline/modeling/review-domain-modeling.md

@@ -0,0 +1,41 @@
+---
+name: review-domain-modeling
+description: Review domain models for completeness, consistency, and downstream readiness
+phase: "modeling"
+order: 8
+dependencies: [domain-modeling]
+outputs: [docs/reviews/review-domain-modeling.md]
+conditional: null
+knowledge-base: [review-methodology, review-domain-modeling]
+---
+
+## Purpose
+Deep multi-pass review of the domain models, targeting the specific failure modes
+of domain modeling artifacts. Identify issues, create a fix plan, execute fixes,
+and re-validate.
+
+## Inputs
+- docs/domain-models/ (required) — domain models to review
+- docs/prd.md (required) — source requirements for coverage checking
+
+## Expected Outputs
+- docs/reviews/review-domain-modeling.md — review findings, fix plan, and resolution log
+- docs/domain-models/ — updated with fixes
+
+## Quality Criteria
+- All review passes executed with findings documented
+- Every finding categorized by severity (P0-P3)
+- Fix plan created for P0 and P1 findings
+- Fixes applied and re-validated
+- Downstream readiness confirmed (decisions phase can proceed)
+
+## Methodology Scaling
+- **deep**: All review passes from the knowledge base. Full findings report
+  with severity categorization. Fixes applied and re-validated.
+- **mvp**: Quick consistency check. Focus on blocking issues only.
+- **custom:depth(1-5)**: Depth 1-2: blocking issues only. Depth 3: add coverage
+  and consistency passes. Depth 4-5: full multi-pass review.
+
+## Mode Detection
+If docs/reviews/review-domain-modeling.md exists, this is a re-review. Read previous
+findings, check which were addressed, run review passes again on updated models.

package/pipeline/planning/implementation-tasks.md

@@ -0,0 +1,57 @@
+---
+name: implementation-tasks
+description: Break architecture into implementable tasks with dependencies
+phase: "planning"
+order: 25
+dependencies: [testing-strategy, operations, security]
+outputs: [docs/implementation-tasks.md]
+conditional: null
+knowledge-base: [task-decomposition]
+---
+
+## Purpose
+Decompose user stories and system architecture into concrete, implementable
+tasks suitable for AI agents. Each task should be independently executable,
+have clear inputs/outputs, and be small enough for a single agent session.
+The primary mapping is Story → Task(s), with PRD as the traceability root.
+
+## Inputs
+- docs/system-architecture.md (required) — components to implement
+- docs/domain-models/ (required) — domain logic to implement
+- docs/adrs/ (required) — technology constraints
+- docs/prd.md (required) — features to trace tasks back to
+- docs/user-stories.md (required) — stories to derive tasks from
+- docs/testing-strategy.md (required) — testing requirements to incorporate into tasks
+- docs/operations-runbook.md (optional) — ops requirements to incorporate into tasks
+- docs/security-review.md (optional) — security requirements to incorporate into tasks
+- docs/database-schema.md (optional) — data layer tasks
+- docs/api-contracts.md (optional) — API implementation tasks
+- docs/ux-spec.md (optional) — frontend tasks
+
+## Expected Outputs
+- docs/implementation-tasks.md — task list with dependencies, sizing, and
+  assignment recommendations
+
+## Quality Criteria
+- Every architecture component has implementation tasks
+- Task dependencies form a valid DAG (no cycles)
+- Each task is scoped for a single agent session (not too large, not too small)
+- Tasks include acceptance criteria (how to know it's done)
+- Tasks incorporate testing requirements from the testing strategy
+- Tasks incorporate security controls from the security review where applicable
+- Tasks incorporate operational requirements (monitoring, deployment) where applicable
+- Critical path is identified
+- Parallelization opportunities are marked
+- Every user story maps to at least one task
+
+## Methodology Scaling
+- **deep**: Detailed task breakdown with story-to-task tracing. Dependency graph.
+  Sizing estimates. Parallelization plan. Agent context requirements per task.
+  Phased delivery milestones.
+- **mvp**: Ordered task list with brief descriptions. Key dependencies noted.
+  Enough to start working sequentially.
+- **custom:depth(1-5)**: Depth 1-2: ordered list. Depth 3: add dependencies
+  and sizing. Depth 4-5: full breakdown with parallelization.
+
+## Mode Detection
+Update mode if tasks exist. Re-derive from updated architecture.