Pygentic-AI/.specify/templates/plan-template.md

Implementation Plan: [FEATURE]

Branch: [###-feature-name] | Date: [DATE] | Spec: [link] Input: Feature specification from /specs/[###-feature-name]/spec.md

Note: This template is filled in by the /speckit.plan command. See .specify/templates/commands/plan.md for the execution workflow.

Summary

[Extract from feature spec: primary requirement + technical approach from research]

Technical Context

Language/Version: [e.g., Python 3.11, Swift 5.9, Rust 1.75 or NEEDS CLARIFICATION] Primary Dependencies: [e.g., FastAPI, UIKit, LLVM or NEEDS CLARIFICATION] Storage: [if applicable, e.g., PostgreSQL, CoreData, files or N/A] Testing: [e.g., pytest, XCTest, cargo test or NEEDS CLARIFICATION] Target Platform: [e.g., Linux server, iOS 15+, WASM or NEEDS CLARIFICATION] Project Type: [single/web/mobile - determines source structure] Performance Goals: [domain-specific, e.g., 1000 req/s, 10k lines/sec, 60 fps or NEEDS CLARIFICATION] Constraints: [domain-specific, e.g., <200ms p95, <100MB memory, offline-capable or NEEDS CLARIFICATION] Scale/Scope: [domain-specific, e.g., 10k users, 1M LOC, 50 screens or NEEDS CLARIFICATION]

Constitution Check

GATE: Must pass before Phase 0 research. Re-check after Phase 1 design.

The following principles from .specify/memory/constitution.md MUST be verified:

I. Test-Driven Development (NON-NEGOTIABLE)

• Tests planned before implementation
• Red-Green-Refactor cycle documented in tasks
• Test coverage targets defined (>80% general, 100% critical paths)

II. API-First Design

• API contracts documented with Pydantic schemas
• Request/response formats specified
• Error handling and status codes defined
• Authentication/authorization requirements documented

III. Asynchronous Architecture

• I/O-bound operations use async patterns
• Background tasks delegated to Celery (if applicable)
• Database operations use async drivers
• Caching strategy defined (if applicable)

IV. Observability and Monitoring

• Logging strategy defined with structured logs
• Tracing instrumentation planned (OpenTelemetry)
• Metrics collection specified
• Error tracking approach documented

V. Type Safety and Validation

• Pydantic models defined for all data structures
• Type hints planned for all functions
• Input validation at API boundaries
• Runtime validation strategy specified

VI. Security by Default

• No credentials in code (environment variables only)
• Input validation and sanitization planned
• Authentication/authorization requirements clear
• SQL injection prevention via parameterized queries
• Security audit plan included

PASS CRITERIA: All checkboxes must be checked or explicitly waived with justification in Complexity Tracking section.

Project Structure

Documentation (this feature)

specs/[###-feature]/
├── plan.md              # This file (/speckit.plan command output)
├── research.md          # Phase 0 output (/speckit.plan command)
├── data-model.md        # Phase 1 output (/speckit.plan command)
├── quickstart.md        # Phase 1 output (/speckit.plan command)
├── contracts/           # Phase 1 output (/speckit.plan command)
└── tasks.md             # Phase 2 output (/speckit.tasks command - NOT created by /speckit.plan)

Source Code (repository root)

# [REMOVE IF UNUSED] Option 1: Single project (DEFAULT)
src/
├── models/
├── services/
├── cli/
└── lib/

tests/
├── contract/
├── integration/
└── unit/

# [REMOVE IF UNUSED] Option 2: Web application (when "frontend" + "backend" detected)
backend/
├── src/
│   ├── models/
│   ├── services/
│   └── api/
└── tests/

frontend/
├── src/
│   ├── components/
│   ├── pages/
│   └── services/
└── tests/

# [REMOVE IF UNUSED] Option 3: Mobile + API (when "iOS/Android" detected)
api/
└── [same as backend above]

ios/ or android/
└── [platform-specific structure: feature modules, UI flows, platform tests]

Structure Decision: [Document the selected structure and reference the real directories captured above]

Complexity Tracking

Fill ONLY if Constitution Check has violations that must be justified

Violation	Why Needed	Simpler Alternative Rejected Because
[e.g., 4th project]	[current need]	[why 3 projects insufficient]
[e.g., Repository pattern]	[specific problem]	[why direct DB access insufficient]