@curdx/flow 2.3.11 → 3.1.0

package/templates/design.md.tmpl

@@ -1,83 +0,0 @@
----
-spec: {{SPEC_NAME}}
-phase: design
-created: {{CREATED_DATE}}
-version: 1.0
-status: in_progress
-depends_on: requirements.md
----
-
-# Technical Design: {{SPEC_NAME}}
-
-> Conclusions from flow-architect. Sequential-thinking is invoked proportional to the genuine tradeoff surface — the chain lives in the thinking tool, not this document.
->
-> **Fill only the sections that carry real design information for this feature.** Well-known stack assemblies legitimately compress to a stack list + data model + a few real ADs. Delete sections whose honest answer would be "N/A" or "standard for this stack". A forced 13-section template is the bloat pattern this is designed to prevent.
-
----
-
-## Design Overview (one paragraph)
-
-<!-- One sentence summary of the approach. -->
-
-## Architecture Decisions
-
-<!-- Each real decision gets an AD-NN. If a decision is "obvious, no alternative worth listing," use one line and move on. -->
-
-### AD-01: ...
-- **Decision**: Use X
-- **Rationale**: ...
-- **Trade-off**: ... (omit if there is no genuine tradeoff)
-
-## Component Design
-
-<!-- Each component: responsibility, input type, output type, dependencies, error path. Skip if the feature is a single module with no internal boundaries worth naming. -->
-
-### Component: {{COMP_NAME}}
-- **Responsibility**: ...
-- **Input**: `interface Input { ... }`
-- **Output**: `interface Output { ... }`
-- **Dependencies**: ...
-- **Errors**: ...
-
-## Data Model (if the feature touches persistence or structured data)
-
-<!-- SQL schema, TypeScript types, or API payload shape. Delete if the feature has no meaningful data shape. -->
-
-## Architecture Diagram (include only when it clarifies; prose often suffices)
-
-```mermaid
-flowchart TB
-  ...
-```
-
-## State Machine (include only if the feature has non-trivial state transitions)
-
-## Error Path Design (include when error behavior is not obvious)
-
-| Scenario | System Response | User-visible |
-|-----|---------|---------|
-| ... | ... | ... |
-
-## API Contract (include only if this feature exposes or changes an API)
-
-```yaml
-...
-```
-
-## Test Matrix (brief — one line per layer)
-
-| Layer | Coverage | Tool |
-|---|-----|------|
-| ... | ... | ... |
-
-## Risks and Mitigations (include only if risks exist that aren't obvious from the ADs)
-
-## Defer to Implementation
-
-<!-- Decisions explicitly deferred to when the executor writes the code. -->
-
-- ...
-
----
-
-_Generated by flow-architect on {{CREATED_DATE}}._

package/templates/progress.md.tmpl

@@ -1,77 +0,0 @@
-# Progress Log: {{SPEC_NAME}}
-
-> Living document. The agent appends here every time a task is completed / a gotcha is discovered / a decision is made.
->
-> On resume after an interruption, the agent reads this file to rebuild context.
-
----
-
-## Reality Check (current actual state)
-
-<!-- At the start of each session, the agent reconciles: expected state vs actual state -->
-
-**Last updated**: {{CREATED_DATE}}
-
-- Current phase: research
-- Current task: N/A (tasks phase not yet entered)
-- Blockers: none
-
-## Reality Check (BEFORE)
-
-<!-- For fix/debug specs only: capture the original failure before changing code. -->
-
-**Goal type**: N/A
-**Reproduction command**: N/A
-**Failure observed**: N/A
-**Output**: N/A
-**Timestamp**: N/A
-
-## Reality Check (AFTER)
-
-<!-- For fix/debug specs only: rerun the same command after the fix and compare. -->
-
-**Command**: N/A
-**Result**: N/A
-**Comparison**: N/A
-**Verified**: N/A
-
-## Completed Tasks
-
-<!-- List of completed tasks -->
-
-_(not yet started)_
-
-## Learnings
-
-<!-- Things the agent discovered during execution that are worth remembering (useful for similar future situations) -->
-
-### Gotchas
-_(none)_
-
-### Patterns that worked
-_(none)_
-
-### Approaches that didn't work
-_(none)_
-
-## Decisions Made Here
-
-<!-- Technical decisions made within this spec (major decisions should be synced to .flow/STATE.md) -->
-
-_(none)_
-
-## Next Steps
-
-<!-- What to do next. Must be filled in before ending the session. -->
-
-- [ ] Enter the research phase: run `/curdx-flow:spec --phase=research`
-
-## Questions for User
-
-<!-- Questions that need user answers -->
-
-_(none)_
-
----
-
-_Spec initialized by `/curdx-flow:start` on {{CREATED_DATE}}._

package/templates/requirements.md.tmpl

@@ -1,76 +0,0 @@
----
-spec: {{SPEC_NAME}}
-phase: requirements
-created: {{CREATED_DATE}}
-version: 1.0
-status: in_progress
-depends_on: research.md
----
-
-# Requirements Spec: {{SPEC_NAME}}
-
-> **Recommended direction from research**: {{RESEARCH_CONCLUSION}}
->
-> **Fill only the sections that carry real information for this feature.** Delete or collapse any section whose honest content would be "N/A" or "same as usual". Padding sections with "TBD" is worse than omitting them.
-
----
-
-## User Stories
-
-### US-01: ...
-**As** [user role], **I want** [capability], **so that** [business value].
-
-**Acceptance criteria**:
-- AC-1.1: [verifiable behavior]
-- AC-1.2: ...
-
-<!-- Add more US-NN blocks only if the feature genuinely has multiple independent user flows. -->
-
-## Functional Requirements
-
-- **FR-01**: The system must ...
-- **FR-02**: ...
-
-## Non-Functional Requirements
-
-<!--
-Include ONLY the NFR categories that this feature is actually constrained by.
-For a small internal CRUD feature, "Performance / Security / Maintainability / Compatibility" as a four-bucket grid is usually padding.
-Delete categories that have no real requirement, or collapse into one line: "NFR: standard for this stack, no special constraints."
--->
-
-### Performance (if applicable)
-- **NFR-P-01**: ...
-
-### Security (if applicable)
-- **NFR-S-01**: ...
-
-<!-- Delete Maintainability / Compatibility sections unless they carry a real constraint. -->
-
-## Edge Cases and Error Handling
-
-<!-- Include rows only for scenarios that actually apply. -->
-
-| Scenario | Expected behavior |
-|-----|--------|
-| ... | ... |
-
-## Out of Scope
-
-- ✗ ...
-
-## Success Metrics (if the feature has measurable outcomes)
-
-<!-- Delete this section for internal tools or refactors with no user-visible metric. -->
-
-- Metric 1: ...
-
-## Open Questions
-
-<!-- Include only if there are genuinely unresolved questions. Delete when empty. -->
-
-1. ...
-
----
-
-_Generated by flow-product-designer on {{CREATED_DATE}}._

package/templates/research.md.tmpl

@@ -1,83 +0,0 @@
----
-spec: {{SPEC_NAME}}
-phase: research
-created: {{CREATED_DATE}}
-version: 1.0
-status: in_progress
----
-
-# Research Report: {{SPEC_NAME}}
-
-> **Goal**: {{SPEC_GOAL}}
->
-> **Fill only the sections that carry real information.** For a well-understood feature on a known stack, research legitimately compresses to: goal, one recommended direction, known constraints. Delete sections whose honest content would be "N/A" or "first time, nothing to fetch". Padding this document with "TBD" is worse than omitting sections.
-
----
-
-## Prior Experience (from claude-mem, if relevant)
-
-{{CLAUDE_MEM_FINDINGS}}
-
-<!-- Delete this section if there are no relevant prior observations. -->
-
-## Problem Understanding
-
-### Core Problem
-<!-- One sentence. What are we solving? -->
-
-### Explicit Assumptions
-<!-- Only real assumptions that matter. Don't list "assumption: we will write code." -->
-
-- Assumption 1: ...
-
-### Known Constraints
-<!-- Include only the constraints that actually shape the solution. -->
-
-- Tech stack: ...
-- Time budget: ...
-- (Compliance, team capability, etc — only if they constrain this feature)
-
-## Technical Solution Space
-
-<!--
-If one approach is clearly the right call for this stack, write only that approach with its rationale.
-Include alternative options ONLY when there is a genuine tradeoff a thoughtful engineer might disagree on.
-Do not invent Option B and Option C just to fill the template.
--->
-
-### Recommended Approach: ...
-- **Why**: ...
-- **Complexity**: ...
-- **Key APIs verified via context7**: ...
-
-### Alternative: ... (include only if a real alternative exists)
-
-## Existing Code Analysis (include only if the codebase has relevant prior work)
-
-### Reusable Modules
-- `path/to/module` — ...
-
-### New Modules Required
-- `path/to/new` — ...
-
-## Latest Documentation Summary
-
-<!-- Only include libraries whose API is version-sensitive AND used by this feature. Do not cite every library in the stack. -->
-
-### {{LIBRARY}}
-- Version: ...
-- Relevant APIs: ...
-- Gotchas: ...
-
-## Feasibility
-
-- **Verdict**: feasible / risky / not recommended
-- **Main risks**: (only if real risks exist)
-
-## Open Questions (delete if none)
-
-1. ...
-
----
-
-_Generated by flow-researcher on {{CREATED_DATE}}._

package/templates/tasks.md.tmpl

@@ -1,107 +0,0 @@
----
-spec: {{SPEC_NAME}}
-phase: tasks
-created: {{CREATED_DATE}}
-version: 1.0
-status: in_progress
-depends_on: design.md
----
-
-# Task Breakdown: {{SPEC_NAME}}
-
-> POC-First is an **orientation, not a mandate**. Use the phases below as an organizing idea and **delete phases that don't apply to this feature**. A bug-fix may be one task. A prototype may skip Phase 2 (refactor) and Phase 5 (evidence handoff). A library may skip the handoff phase entirely. Forcing all five phases for a small feature is the padding pattern this template is designed to prevent.
->
-> Each task includes whatever of `Do`, `Files`, `Done-when`, `Verify`, `Commit` is needed for the executor to finish it in a single sub-agent dispatch. Verify must be an automated command (no "manual test").
-
----
-
-## Marker Rules
-
-- `[ ]` TODO / `[x]` done
-- `[P]` parallel-safe (dispatch in parallel within the same wave)
-- `[VERIFY]` quality checkpoint (flow-verifier agent)
-- `[SEQUENTIAL]` must be serial (breaks the parallel group)
-- `VF` reality verification task for fix/debug specs (BEFORE failure → AFTER pass)
-
----
-
-## Split Rule
-
-If a task proves too broad or unsafe during execution, the executor must stop with `TASK_FAILED` and propose up to 3 smaller replacement tasks. The coordinator updates this file; executors do not invent and execute new tasks in the same turn.
-
----
-
-## Phase 1: Make It Work (POC)
-
-> Goal: end-to-end runnable. Hardcoding is acceptable; skip tests here.
-
-<!-- Add only the tasks this feature genuinely needs. Do not invent skeleton tasks to "round out" the phase. -->
-
-- [ ] **1.1** ...
-  - **Do**: ...
-  - **Files**: ...
-  - **Done when**: ...
-  - **Verify**: ...
-  - **Commit**: ...
-  - _Requirements_: FR-NN
-
-- [ ] **1.X** [VERIFY] End-to-end POC verification
-  - **Verify**: `<command>`
-  - **Done when**: happy path returns the expected result
-
-## Phase 2: Refactoring (delete if the POC is already clean)
-
-> Include only if the POC has genuine duplication or structural mud that warrants cleanup. Skip for tiny features.
-
-## Phase 3: Testing (TDD red / green / yellow)
-
-> Rule: tests first. Red → Green → Yellow. **Collapse red+green into one task when the test and implementation are trivially paired**; split only when the test genuinely precedes a nontrivial implementation.
-> Test quality: primary FR/AC evidence must exercise real behavior. Mock-only, skipped, or assertion-free tests do not count unless backed by integration/e2e coverage or an explicit D-NN waiver.
-
-- [ ] **3.X** [RED→GREEN→YELLOW] ...
-
-- [ ] **3.X+1** [VERIFY] Coverage check
-  - **Verify**: coverage on the changed surface ≥ project standard
-
-- [ ] **3.X+2** [VERIFY] Test quality check
-  - **Do**: apply `test-quality-gate` to tests used as FR/AC evidence
-  - **Done when**: no FR/AC depends solely on mock-only/skipped/assertion-free tests
-  - **Verify**: `<test command>` plus grep scan for skipped tests / mock-only evidence
-
-## Phase 4: Quality Gates
-
-> Include only the checks this project actually runs. `npx eslint` is dead weight if the project uses biome. `tsc --strict` is dead weight for a JS project.
-
-- [ ] **4.VF** [VERIFY] VF: Verify original issue resolved (fix/debug specs only)
-  - **Do**: 1. Read `Reality Check (BEFORE)` in `.progress.md`; 2. Re-run the same reproduction command; 3. Append `Reality Check (AFTER)` with output and comparison
-  - **Files**: `.flow/specs/{{SPEC_NAME}}/.progress.md`
-  - **Done when**: AFTER proves the original observed failure is gone
-  - **Verify**: `grep -q "Verified: Issue resolved" .flow/specs/{{SPEC_NAME}}/.progress.md`
-  - **Commit**: `chore({{SPEC_NAME}}): verify original issue resolved`
-
-- [ ] **4.X** [VERIFY] Final health check
-  - **Do**: flow-verifier performs goal-driven reverse verification
-  - **Done when**: every FR/AC has an automated check
-
-## Phase 5: Evidence Handoff (delete for local-only work, scripts, internal tools without a PR flow)
-
-- [ ] **5.X** Prepare verification/review handoff
-  - **Do**: collect atomic commits, verification report, review report, and residual risk notes
-  - **Done when**: a human can open or release with clear evidence and no hidden blockers
-  - **Verify**: `test -f .flow/specs/{{SPEC_NAME}}/verification-report.md && test -f .flow/specs/{{SPEC_NAME}}/review-report.md`
-
----
-
-## Coverage Audit
-
-<!-- flow-planner fills this in. Every FR / AC / AD / D must map to a task, or explicitly defer with reason. -->
-
-| Requirement ID | Task(s) | Status |
-|--------|---------|------|
-| FR-01 | ... | ✓ |
-
-**Uncovered items must be handled**: add a task, or document the deferral reason in STATE.md.
-
----
-
-_Generated by flow-planner on {{CREATED_DATE}}._