@zigrivers/scaffold 2.1.2 → 2.38.0

package/pipeline/planning/implementation-tasks.md

@@ -1,57 +0,0 @@
----
-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.

package/pipeline/planning/review-tasks.md

@@ -1,38 +0,0 @@
----
-name: review-tasks
-description: Review implementation tasks for coverage and feasibility
-phase: "planning"
-order: 26
-dependencies: [implementation-tasks]
-outputs: [docs/reviews/review-tasks.md]
-conditional: null
-knowledge-base: [review-methodology, review-implementation-tasks]
----
-
-## Purpose
-Review implementation tasks targeting task-specific failure modes: architecture
-coverage gaps, missing dependencies, tasks too large or too vague for agents,
-critical path inaccuracy, and invalid parallelization assumptions.
-
-## Inputs
-- docs/implementation-tasks.md (required) — tasks to review
-- docs/system-architecture.md (required) — for coverage checking
-- docs/domain-models/ (required) — for completeness
-
-## Expected Outputs
-- docs/reviews/review-tasks.md — findings and resolution log
-- docs/implementation-tasks.md — updated with fixes
-
-## Quality Criteria
-- Architecture coverage verified (every component has tasks)
-- Dependency graph is valid DAG
-- No task is too large for a single agent session
-- Critical path is accurate
-- Parallelization assumptions are valid
-
-## Methodology Scaling
-- **deep**: Full multi-pass review. **mvp**: Coverage check only.
-- **custom:depth(1-5)**: Scale passes with depth.
-
-## Mode Detection
-Re-review mode if previous review exists.

package/pipeline/quality/testing-strategy.md

@@ -1,42 +0,0 @@
----
-name: testing-strategy
-description: Define testing and quality strategy across all layers
-phase: "quality"
-order: 19
-dependencies: [review-architecture]
-outputs: [docs/testing-strategy.md]
-conditional: null
-knowledge-base: [testing-strategy]
----
-
-## Purpose
-Define the testing strategy: test pyramid, coverage goals per layer, testing
-patterns, quality gates, and performance testing approach. This tells agents
-how to test the code they write.
-
-## Inputs
-- docs/system-architecture.md (required) — layers to test
-- docs/domain-models/ (required) — business rules to verify
-- docs/adrs/ (required) — testing technology choices
-- docs/api-contracts.md (optional) — API test scenarios
-- docs/database-schema.md (optional) — data layer test scenarios
-
-## Expected Outputs
-- docs/testing-strategy.md — testing approach with coverage goals and patterns
-
-## Quality Criteria
-- Test pyramid defined with coverage targets per layer
-- Testing patterns specified for each layer (unit, integration, e2e)
-- Quality gates defined (what must pass before merge)
-- Edge cases from domain invariants are test scenarios
-- Performance testing approach for critical paths
-
-## Methodology Scaling
-- **deep**: Comprehensive strategy. Test matrix by layer and component. Specific
-  test patterns per architecture pattern. Performance benchmarks. CI integration.
-  Test data strategy. Mutation testing approach.
-- **mvp**: Test pyramid overview. Key testing patterns. What must pass before deploy.
-- **custom:depth(1-5)**: Scale detail with depth.
-
-## Mode Detection
-Update mode if strategy exists.