create-saltic
Version:
Spec-Driven Development (SDD) framework for constitutional software development - inject into any project
69 lines (54 loc) • 4 kB
Markdown
Plan how to implement the specified feature.
This is the second step in the Spec-Driven Development lifecycle.
Given the implementation details provided as an argument, do this:
1. Run `scripts/setup-plan.sh --json` from the repo root and parse JSON for FEATURE_SPEC, IMPL_PLAN, SPECS_DIR, BRANCH. All future file paths must be absolute.
2. Read and analyze the feature specification to understand:
- The feature requirements and user stories
- Functional and non-functional requirements
- Success criteria and acceptance criteria
- Any technical constraints or dependencies mentioned
3. Read the constitution at `/memory/constitution.md` and `/memory/angular-constitution.md` to understand constitutional requirements.
4. Always use context7 for planning:
- Use the `mcp__context7__resolve-library-id` and `mcp__context7__get-library-docs` tools to retrieve up-to-date documentation for any external libraries, frameworks, or technologies mentioned in the feature specification
- Ensure all technical decisions are based on current, authoritative documentation
- Document all library references and their context7-compatible library IDs in the planning artifacts
5. Check for contract attachments:
- Scan for any `@docs/contracts/<filename>.md` attachments in the planning arguments
- If contracts are attached, create the `contracts/` directory in `$SPECS_DIR`
- Copy attached contracts to `contracts/` directory with proper filenames
- Update the planning artifacts to reference existing contracts instead of generating new ones
6. Execute the implementation plan template:
- Load `/templates/plan-template.md` (already copied to IMPL_PLAN path)
- Set Input path to FEATURE_SPEC
- Run the Execution Flow (main) function steps 1-10
- The template is self-contained and executable
- Follow error handling and gate checks as specified
- Let the template guide artifact generation in $SPECS_DIR:
* Phase 0 generates research.md
* Phase 1 generates data-model.md, contracts/, quickstart.md
* Phase 2 generates tasks.md
- Incorporate user-provided details from arguments into Technical Context: $ARGUMENTS
- Update Progress Tracking as you complete each phase
**NEW PLANNING WORKFLOW:**
The planning follows a clear architecture pattern with these constraints:
- One component has only one use case, meaning one presenter represents all the state requirements of one component page
- One use case can accept multiple repositories
- Each repository method returns an entity and accepts a DTO as parameter
- Each use case method returns a presenter representing all state requirements
**PLANNING SEQUENCE:**
1. **Create/use/edit entity** - Define or update data model interfaces
2. **Create/use/edit DTO** - Define or update data transfer objects for API communication
3. **Create/use/edit repository** - Define or update abstract repository interfaces with methods returning entities and accepting DTOs
4. **Create/use/edit adapter** - Implement or update concrete repository implementations
5. **Connect repository with adapter in app config** - Configure dependency injection mappings if needed
6. **Create/use/edit use case** - Create or update use cases that accept multiple repositories and return presenters
7. **Consume use case in component** - Implement or update components to consume use cases (one component = one use case = one presenter)
The workflow is carried out only if needed in the plan.
8. Verify execution completed:
- Check Progress Tracking shows all phases complete
- Ensure all required artifacts were generated
- Confirm no ERROR states in execution
- Verify that all external library references have been documented using context7
- Verify that attached contracts have been properly processed and referenced
9. Report results with branch name, file paths, and generated artifacts.
Use absolute paths with the repository root for all file operations to avoid path issues.