@karthikrajkumar.kannan/get-things-done 1.0.0

package/references/questioning.md

@@ -0,0 +1,142 @@
+# Dream Extraction: Questioning Philosophy
+
+> Reference document for the forward pipeline questioning agent.
+> Goal: Surface the user's VISION, not just a feature list.
+
+---
+
+## Core Principle
+
+The user has a dream, not a spec. Your job is to help them articulate what they see in their head. Requirements emerge from understanding the dream -- never start with requirements.
+
+---
+
+## Product Type Detection
+
+Before asking detailed questions, classify the project type to calibrate your approach.
+
+| Signal | Product Type | Question Style |
+|--------|-------------|----------------|
+| "I want to build an app that..." | Consumer product | Focus on UX, users, emotions |
+| "We need a system that..." | Internal tool | Focus on workflow, integrations, data |
+| "I want a site for..." | Content/marketing | Focus on audience, tone, conversion |
+| "I need an API that..." | Developer tool | Focus on contracts, DX, performance |
+| "I want to automate..." | Automation/script | Focus on triggers, reliability, edge cases |
+
+---
+
+## Question Categories
+
+### 1. Scope & Vision
+
+Purpose: Understand the boundaries and ambition level.
+
+- "What does the finished thing look like when someone first uses it?"
+- "What is the ONE thing it absolutely must do well?"
+- "What would make you proud to show this to someone?"
+- "Is this a weekend project or something you want to grow?"
+
+### 2. Users & Audience
+
+Purpose: Ground the vision in real people.
+
+- "Who is the first person that will use this (besides you)?"
+- "What are they doing RIGHT BEFORE they open your app?"
+- "What problem goes away when they use it?"
+- "How technical are your users?"
+
+### 3. Technical Preferences
+
+Purpose: Detect existing opinions and constraints.
+
+- "Do you have a language or framework preference?"
+- "Is there existing code or infrastructure this needs to fit into?"
+- "Any services you already pay for (hosting, databases, auth)?"
+- "Do you have strong opinions about any technology choices?"
+
+### 4. UX & Design
+
+Purpose: Understand aesthetic and interaction expectations.
+
+- "Can you name an app or site that FEELS like what you want?"
+- "Is this mobile-first, desktop-first, or both?"
+- "Minimal and clean, or feature-rich and powerful?"
+- "Any colors, fonts, or visual styles you are drawn to?"
+
+### 5. Constraints & Boundaries
+
+Purpose: Identify hard limits early.
+
+- "What is your budget for hosting and services?"
+- "When do you need this working?"
+- "Are there compliance or privacy requirements?"
+- "What should this explicitly NOT do?"
+
+---
+
+## The "Anything Else?" Pattern
+
+After covering the categories above, always ask one open-ended closing question:
+
+> "Is there anything else about this project that feels important but I have not asked about?"
+
+This catches:
+- Unstated assumptions the user holds
+- Emotional priorities (speed, elegance, simplicity)
+- Prior bad experiences they want to avoid
+- Constraints they forgot to mention
+
+---
+
+## Auto-Mode Extraction
+
+When the user provides a long initial description, extract answers to the categories above without re-asking. Only ask about gaps.
+
+**Process:**
+1. Parse the user input against all 5 categories
+2. Mark each category as: `covered`, `partial`, `missing`
+3. For `covered` categories: confirm your understanding in a single sentence
+4. For `partial` categories: ask ONE targeted follow-up
+5. For `missing` categories: ask the most important question from that category
+
+**Example mapping:**
+
+```
+User says: "I want a task manager with tags, built in React, deployed on Vercel"
+
+Category status:
+- Scope & Vision: partial (what, but not why or success criteria)
+- Users: missing
+- Technical: covered (React + Vercel)
+- UX: missing
+- Constraints: partial (platform chosen, but no timeline/budget)
+```
+
+---
+
+## Adaptive Depth
+
+| User Response Style | Adjust To |
+|--------------------|-----------|
+| Short, terse answers | Ask fewer, more specific questions |
+| Long, detailed answers | Summarize and confirm, skip redundant questions |
+| Uncertain / "I don't know" | Offer 2-3 concrete options to choose from |
+| Opinionated / decisive | Record the decision, move quickly to next topic |
+| Contradictory answers | Gently surface the contradiction, ask which they prefer |
+
+---
+
+## Output Format
+
+After extraction, produce a structured brief:
+
+```markdown
+## Dream Brief
+- **Vision:** [one sentence]
+- **Users:** [who]
+- **Core Feature:** [the ONE thing]
+- **Tech Preferences:** [stated preferences]
+- **Constraints:** [hard limits]
+- **Style:** [aesthetic/UX direction]
+- **Open Items:** [unanswered questions]
+```

package/references/verification-patterns.md

@@ -0,0 +1,67 @@
+# Verification Patterns Reference
+
+> Methodology for verifying generated document accuracy.
+> Used by `gtd-accuracy-verifier` and `gtd-completeness-auditor`.
+
+---
+
+## What is a Verifiable Claim?
+
+A **verifiable claim** is a factual statement that can be checked against the codebase:
+
+| Verifiable | Example | How to Check |
+|-----------|---------|--------------|
+| ✓ Yes | "Auth handled in src/middleware/auth.js" | Check file exists and contains auth logic |
+| ✓ Yes | "Uses Express 4.21" | Check package.json |
+| ✓ Yes | "5 REST endpoints" | Count route definitions |
+| ✓ Yes | "PostgreSQL via Prisma" | Check prisma/schema.prisma |
+| ✗ No | "This is a well-designed system" | Opinion — cannot verify |
+| ✗ No | "Handles high traffic" | No performance data to check |
+| ✗ No | "Should be refactored" | Recommendation — not a claim |
+
+## Confidence Score Methodology
+
+```
+confidence = verified_claims / (total_claims - unverifiable_claims) × 100
+
+Ratings:
+  95-100%  → Excellent — document is highly trustworthy
+  90-95%   → Good — minor corrections needed
+  80-90%   → Acceptable — review flagged sections
+  70-80%   → Needs revision — significant inaccuracies
+  Below 70% → Unreliable — recommend regeneration with /gtd-analyze --force
+```
+
+## Common False Positive Patterns
+
+These patterns LOOK like errors but are often legitimate — verify carefully:
+
+1. **File path with different extension** — `auth.js` vs `auth.ts` (transpilation)
+2. **Version ranges** — "Express ^4.18" in package.json, doc says "Express 4.21" (resolved version)
+3. **Generated files** — Paths in `dist/` or `.next/` may not exist until build
+4. **Aliased imports** — `@/lib/auth` may resolve to `src/lib/auth.ts`
+5. **Workspace paths** — Monorepo paths may include package prefix
+
+## Verification Priority
+
+When time-constrained, verify in this priority order:
+
+1. **File paths** — Most common error, easiest to check
+2. **Dependency versions** — Frequently hallucinated with wrong minor/patch
+3. **API endpoints** — Route paths and methods must be exact
+4. **Code snippets** — Most expensive to verify but most impactful if wrong
+5. **Architecture claims** — Hardest to verify definitively
+
+## Per-Section Verification Depth
+
+| Document Type | High-Scrutiny Sections | Lower-Scrutiny Sections |
+|--------------|----------------------|------------------------|
+| TDD | Architecture, API Design, Data Model | Executive Summary, Limitations |
+| HLD | Subsystems, Integrations | Design Decisions |
+| LLD | Module Specs, Signatures, Queries | Overview |
+| API Docs | Endpoints, Examples, Auth | Overview, Rate Limits |
+| System Design | Architecture, Security, Deployment | Evolution |
+
+---
+
+*End of Verification Patterns Reference*

package/templates/backward/api-docs/standard.md

@@ -0,0 +1,42 @@
+---
+type: api-docs
+format: standard
+sections: 6
+---
+
+# API Documentation: {{project_name}}
+
+**Version:** {{doc_version}}
+**Date:** {{generation_date}}
+**Commit:** {{git_commit}}
+**Generated by:** GTD v{{gtd_version}}
+
+---
+
+## 1. Overview and Base URL
+
+{{api_overview}}
+
+## 2. Authentication
+
+{{api_authentication}}
+
+## 3. Endpoint Reference
+
+{{api_endpoints}}
+
+## 4. Request/Response Examples
+
+{{api_examples}}
+
+## 5. Error Codes
+
+{{api_errors}}
+
+## 6. Rate Limiting and Pagination
+
+{{api_limits}}
+
+---
+
+*Generated by [Get Things Done](https://github.com/get-things-done/get-things-done)*

package/templates/backward/capacity/standard.md

@@ -0,0 +1,50 @@
+---
+type: capacity
+format: standard
+sections: 8
+---
+
+# Capacity Plan: {{project_name}}
+
+**Version:** {{doc_version}}
+**Date:** {{generation_date}}
+**Commit:** {{git_commit}}
+**Generated by:** GTD v{{gtd_version}}
+
+---
+
+## 1. System Profile
+
+{{cap_system_profile}}
+
+## 2. Resource Requirements
+
+{{cap_resource_requirements}}
+
+## 3. Performance Characteristics
+
+{{cap_performance}}
+
+## 4. Scaling Strategy
+
+{{cap_scaling}}
+
+## 5. Database Capacity
+
+{{cap_database}}
+
+## 6. Infrastructure Costs
+
+{{cap_infrastructure}}
+
+## 7. Bottleneck Analysis
+
+{{cap_bottlenecks}}
+
+## 8. Growth Projections
+
+{{cap_growth}}
+
+---
+
+*Generated by [Get Things Done](https://github.com/get-things-done/get-things-done)*

package/templates/backward/formats/compliance-guide.md

@@ -0,0 +1,45 @@
+# Compliance Format Guide
+
+> How to use GTD's compliance document format for SOC 2, ISO 27001, and HIPAA audits.
+
+## Usage
+
+```
+/gtd-create-tdd --format compliance
+/gtd-create-all --format compliance
+/gtd-audit --compliance soc2
+```
+
+## What Compliance Format Adds
+
+| Standard Section | Compliance Addition |
+|-----------------|-------------------|
+| Data Model | Data Classification Matrix (PII, PHI, financial) |
+| Auth Design | Authorization Matrix (RBAC/ABAC mapping) |
+| Security | Encryption & Key Management section |
+| Logging | Audit trail with tamper protection |
+| Dependencies | Supply chain risk assessment |
+| Testing | Security testing section (SAST, DAST, pen test) |
+| New Section | SOC 2 controls mapping |
+| New Section | ISO 27001 Annex A controls |
+| New Section | Risk assessment with residual risk |
+| New Section | Business continuity / disaster recovery |
+
+## SOC 2 Trust Service Criteria Covered
+
+- **Security (CC):** Network, access controls, encryption
+- **Availability (A):** BCDR, monitoring, SLAs
+- **Processing Integrity (PI):** Audit logging, data validation
+- **Confidentiality (C):** Data classification, encryption at rest/transit
+- **Privacy (P):** PII handling, retention policies
+
+## ISO 27001 Annex A Controls Mapped
+
+The compliance format automatically maps to relevant Annex A controls:
+- A.8: Asset management (data classification)
+- A.9: Access control (auth matrix)
+- A.10: Cryptography (encryption section)
+- A.12: Operations security (deployment, monitoring)
+- A.14: System development (testing, dependencies)
+- A.16: Incident management (audit logging)
+- A.17: Business continuity (BCDR)

package/templates/backward/hld/standard.md

@@ -0,0 +1,62 @@
+---
+type: hld
+format: standard
+sections: 8
+---
+
+# High-Level Design: {{project_name}}
+
+**Version:** {{doc_version}}
+**Date:** {{generation_date}}
+**Commit:** {{git_commit}}
+**Generated by:** GTD v{{gtd_version}}
+
+---
+
+## 1. System Overview
+
+{{hld_system_overview}}
+
+## 2. Architecture and Patterns
+
+{{hld_architecture}}
+
+{{#has_diagrams}}
+### Architecture Diagram
+
+{{hld_architecture_diagram}}
+{{/has_diagrams}}
+
+## 3. Major Subsystems
+
+{{hld_subsystems}}
+
+## 4. Data Flow
+
+{{hld_data_flow}}
+
+{{#has_diagrams}}
+### Data Flow Diagram
+
+{{hld_data_flow_diagram}}
+{{/has_diagrams}}
+
+## 5. Integration Points
+
+{{hld_integrations}}
+
+## 6. Deployment Model
+
+{{hld_deployment}}
+
+## 7. Cross-Cutting Concerns
+
+{{hld_cross_cutting}}
+
+## 8. Key Design Decisions
+
+{{hld_decisions}}
+
+---
+
+*Generated by [Get Things Done](https://github.com/get-things-done/get-things-done)*

package/templates/backward/lld/standard.md

@@ -0,0 +1,63 @@
+---
+type: lld
+format: standard
+sections: 10
+---
+
+# Low-Level Design: {{project_name}}
+
+**Version:** {{doc_version}}
+**Date:** {{generation_date}}
+**Commit:** {{git_commit}}
+**Generated by:** GTD v{{gtd_version}}
+
+---
+
+## 1. Module Overview
+
+{{lld_module_overview}}
+
+## 2. Module Specifications
+
+{{lld_module_specs}}
+
+## 3. Class and Function Signatures
+
+{{lld_signatures}}
+
+## 4. Data Structures and Schemas
+
+{{lld_data_structures}}
+
+## 5. Algorithm Details
+
+{{lld_algorithms}}
+
+## 6. API Endpoint Specifications
+
+{{#has_api}}
+{{lld_api_specs}}
+{{/has_api}}
+{{^has_api}}
+Not applicable.
+{{/has_api}}
+
+## 7. Database Query Patterns
+
+{{lld_query_patterns}}
+
+## 8. Error Handling Specifications
+
+{{lld_error_handling}}
+
+## 9. Configuration and Environment
+
+{{lld_configuration}}
+
+## 10. Module Dependency Graph
+
+{{lld_dependency_graph}}
+
+---
+
+*Generated by [Get Things Done](https://github.com/get-things-done/get-things-done)*

package/templates/backward/runbook/standard.md

@@ -0,0 +1,50 @@
+---
+type: runbook
+format: standard
+sections: 8
+---
+
+# Operations Runbook: {{project_name}}
+
+**Version:** {{doc_version}}
+**Date:** {{generation_date}}
+**Commit:** {{git_commit}}
+**Generated by:** GTD v{{gtd_version}}
+
+---
+
+## 1. Service Overview
+
+{{rb_service_overview}}
+
+## 2. Deployment Procedure
+
+{{rb_deployment}}
+
+## 3. Configuration Reference
+
+{{rb_configuration}}
+
+## 4. Health Checks and Monitoring
+
+{{rb_monitoring}}
+
+## 5. Common Issues and Troubleshooting
+
+{{rb_troubleshooting}}
+
+## 6. Incident Response
+
+{{rb_incident_response}}
+
+## 7. Backup and Recovery
+
+{{rb_backup}}
+
+## 8. Access and Permissions
+
+{{rb_access}}
+
+---
+
+*Generated by [Get Things Done](https://github.com/get-things-done/get-things-done)*

package/templates/backward/system-design/standard.md

@@ -0,0 +1,64 @@
+---
+type: system-design
+format: standard
+sections: 10
+---
+
+# System Design: {{project_name}}
+
+**Version:** {{doc_version}}
+**Date:** {{generation_date}}
+**Commit:** {{git_commit}}
+**Generated by:** GTD v{{gtd_version}}
+
+---
+
+## 1. System Architecture
+
+{{sd_architecture}}
+
+## 2. Component Interactions
+
+{{sd_interactions}}
+
+{{#has_diagrams}}
+### Component Diagram
+
+{{sd_component_diagram}}
+{{/has_diagrams}}
+
+## 3. Data Architecture
+
+{{sd_data_architecture}}
+
+## 4. Pipeline and State Machine
+
+{{sd_pipeline}}
+
+## 5. API and Protocol Design
+
+{{sd_api_design}}
+
+## 6. Security Architecture
+
+{{sd_security}}
+
+## 7. Deployment and Infrastructure
+
+{{sd_deployment}}
+
+## 8. Reliability and Fault Tolerance
+
+{{sd_reliability}}
+
+## 9. Observability
+
+{{sd_observability}}
+
+## 10. Evolution and Extensibility
+
+{{sd_evolution}}
+
+---
+
+*Generated by [Get Things Done](https://github.com/get-things-done/get-things-done)*