gsd-opencode 1.3.31

package/get-shit-done/templates/codebase/testing.md

@@ -0,0 +1,480 @@
+# Testing Patterns Template
+
+Template for `.planning/codebase/TESTING.md` - captures test framework and patterns.
+
+**Purpose:** Document how tests are written and run. Guide for adding tests that match existing patterns.
+
+---
+
+## File Template
+
+```markdown
+# Testing Patterns
+
+**Analysis Date:** [YYYY-MM-DD]
+
+## Test Framework
+
+**Runner:**
+- [Framework: e.g., "Jest 29.x", "Vitest 1.x"]
+- [Config: e.g., "jest.config.js in project root"]
+
+**Assertion Library:**
+- [Library: e.g., "built-in expect", "chai"]
+- [Matchers: e.g., "toBe, toEqual, toThrow"]
+
+**Run Commands:**
+```bash
+[e.g., "npm test" or "npm run test"]              # Run all tests
+[e.g., "npm test -- --watch"]                     # Watch mode
+[e.g., "npm test -- path/to/file.test.ts"]       # Single file
+[e.g., "npm run test:coverage"]                   # Coverage report
+```
+
+## Test File Organization
+
+**Location:**
+- [Pattern: e.g., "*.test.ts alongside source files"]
+- [Alternative: e.g., "__tests__/ directory" or "separate tests/ tree"]
+
+**Naming:**
+- [Unit tests: e.g., "module-name.test.ts"]
+- [Integration: e.g., "feature-name.integration.test.ts"]
+- [E2E: e.g., "user-flow.e2e.test.ts"]
+
+**Structure:**
+```
+[Show actual directory pattern, e.g.:
+src/
+  lib/
+    utils.ts
+    utils.test.ts
+  services/
+    user-service.ts
+    user-service.test.ts
+]
+```
+
+## Test Structure
+
+**Suite Organization:**
+```typescript
+[Show actual pattern used, e.g.:
+
+describe('ModuleName', () => {
+  describe('functionName', () => {
+    it('should handle success case', () => {
+      // arrange
+      // act
+      // assert
+    });
+
+    it('should handle error case', () => {
+      // test code
+    });
+  });
+});
+]
+```
+
+**Patterns:**
+- [Setup: e.g., "beforeEach for shared setup, avoid beforeAll"]
+- [Teardown: e.g., "afterEach to clean up, restore mocks"]
+- [Structure: e.g., "arrange/act/assert pattern required"]
+
+## Mocking
+
+**Framework:**
+- [Tool: e.g., "Jest built-in mocking", "Vitest vi", "Sinon"]
+- [Import mocking: e.g., "vi.mock() at top of file"]
+
+**Patterns:**
+```typescript
+[Show actual mocking pattern, e.g.:
+
+// Mock external dependency
+vi.mock('./external-service', () => ({
+  fetchData: vi.fn()
+}));
+
+// Mock in test
+const mockFetch = vi.mocked(fetchData);
+mockFetch.mockResolvedValue({ data: 'test' });
+]
+```
+
+**What to Mock:**
+- [e.g., "External APIs, file system, database"]
+- [e.g., "Time/dates (use vi.useFakeTimers)"]
+- [e.g., "Network calls (use mock fetch)"]
+
+**What NOT to Mock:**
+- [e.g., "Pure functions, utilities"]
+- [e.g., "Internal business logic"]
+
+## Fixtures and Factories
+
+**Test Data:**
+```typescript
+[Show pattern for creating test data, e.g.:
+
+// Factory pattern
+function createTestUser(overrides?: Partial<User>): User {
+  return {
+    id: 'test-id',
+    name: 'Test User',
+    email: 'test@example.com',
+    ...overrides
+  };
+}
+
+// Fixture file
+// tests/fixtures/users.ts
+export const mockUsers = [/* ... */];
+]
+```
+
+**Location:**
+- [e.g., "tests/fixtures/ for shared fixtures"]
+- [e.g., "factory functions in test file or tests/factories/"]
+
+## Coverage
+
+**Requirements:**
+- [Target: e.g., "80% line coverage", "no specific target"]
+- [Enforcement: e.g., "CI blocks <80%", "coverage for awareness only"]
+
+**Configuration:**
+- [Tool: e.g., "built-in coverage via --coverage flag"]
+- [Exclusions: e.g., "exclude *.test.ts, config files"]
+
+**View Coverage:**
+```bash
+[e.g., "npm run test:coverage"]
+[e.g., "open coverage/index.html"]
+```
+
+## Test Types
+
+**Unit Tests:**
+- [Scope: e.g., "test single function/class in isolation"]
+- [Mocking: e.g., "mock all external dependencies"]
+- [Speed: e.g., "must run in <1s per test"]
+
+**Integration Tests:**
+- [Scope: e.g., "test multiple modules together"]
+- [Mocking: e.g., "mock external services, use real internal modules"]
+- [Setup: e.g., "use test database, seed data"]
+
+**E2E Tests:**
+- [Framework: e.g., "Playwright for E2E"]
+- [Scope: e.g., "test full user flows"]
+- [Location: e.g., "e2e/ directory separate from unit tests"]
+
+## Common Patterns
+
+**Async Testing:**
+```typescript
+[Show pattern, e.g.:
+
+it('should handle async operation', async () => {
+  const result = await asyncFunction();
+  expect(result).toBe('expected');
+});
+]
+```
+
+**Error Testing:**
+```typescript
+[Show pattern, e.g.:
+
+it('should throw on invalid input', () => {
+  expect(() => functionCall()).toThrow('error message');
+});
+
+// Async error
+it('should reject on failure', async () => {
+  await expect(asyncCall()).rejects.toThrow('error message');
+});
+]
+```
+
+**Snapshot Testing:**
+- [Usage: e.g., "for React components only" or "not used"]
+- [Location: e.g., "__snapshots__/ directory"]
+
+---
+
+*Testing analysis: [date]*
+*Update when test patterns change*
+```
+
+<good_examples>
+```markdown
+# Testing Patterns
+
+**Analysis Date:** 2025-01-20
+
+## Test Framework
+
+**Runner:**
+- Vitest 1.0.4
+- Config: vitest.config.ts in project root
+
+**Assertion Library:**
+- Vitest built-in expect
+- Matchers: toBe, toEqual, toThrow, toMatchObject
+
+**Run Commands:**
+```bash
+npm test                              # Run all tests
+npm test -- --watch                   # Watch mode
+npm test -- path/to/file.test.ts     # Single file
+npm run test:coverage                 # Coverage report
+```
+
+## Test File Organization
+
+**Location:**
+- *.test.ts alongside source files
+- No separate tests/ directory
+
+**Naming:**
+- unit-name.test.ts for all tests
+- No distinction between unit/integration in filename
+
+**Structure:**
+```
+src/
+  lib/
+    parser.ts
+    parser.test.ts
+  services/
+    install-service.ts
+    install-service.test.ts
+  bin/
+    install.ts
+    (no test - integration tested via CLI)
+```
+
+## Test Structure
+
+**Suite Organization:**
+```typescript
+import { describe, it, expect, beforeEach, afterEach, vi } from 'vitest';
+
+describe('ModuleName', () => {
+  describe('functionName', () => {
+    beforeEach(() => {
+      // reset state
+    });
+
+    it('should handle valid input', () => {
+      // arrange
+      const input = createTestInput();
+
+      // act
+      const result = functionName(input);
+
+      // assert
+      expect(result).toEqual(expectedOutput);
+    });
+
+    it('should throw on invalid input', () => {
+      expect(() => functionName(null)).toThrow('Invalid input');
+    });
+  });
+});
+```
+
+**Patterns:**
+- Use beforeEach for per-test setup, avoid beforeAll
+- Use afterEach to restore mocks: vi.restoreAllMocks()
+- Explicit arrange/act/assert comments in complex tests
+- One assertion focus per test (but multiple expects OK)
+
+## Mocking
+
+**Framework:**
+- Vitest built-in mocking (vi)
+- Module mocking via vi.mock() at top of test file
+
+**Patterns:**
+```typescript
+import { vi } from 'vitest';
+import { externalFunction } from './external';
+
+// Mock module
+vi.mock('./external', () => ({
+  externalFunction: vi.fn()
+}));
+
+describe('test suite', () => {
+  it('mocks function', () => {
+    const mockFn = vi.mocked(externalFunction);
+    mockFn.mockReturnValue('mocked result');
+
+    // test code using mocked function
+
+    expect(mockFn).toHaveBeenCalledWith('expected arg');
+  });
+});
+```
+
+**What to Mock:**
+- File system operations (fs-extra)
+- Child process execution (child_process.exec)
+- External API calls
+- Environment variables (process.env)
+
+**What NOT to Mock:**
+- Internal pure functions
+- Simple utilities (string manipulation, array helpers)
+- TypeScript types
+
+## Fixtures and Factories
+
+**Test Data:**
+```typescript
+// Factory functions in test file
+function createTestConfig(overrides?: Partial<Config>): Config {
+  return {
+    targetDir: '/tmp/test',
+    global: false,
+    ...overrides
+  };
+}
+
+// Shared fixtures in tests/fixtures/
+// tests/fixtures/sample-command.md
+export const sampleCommand = `---
+description: Test command
+---
+Content here`;
+```
+
+**Location:**
+- Factory functions: define in test file near usage
+- Shared fixtures: tests/fixtures/ (for multi-file test data)
+- Mock data: inline in test when simple, factory when complex
+
+## Coverage
+
+**Requirements:**
+- No enforced coverage target
+- Coverage tracked for awareness
+- Focus on critical paths (parsers, service logic)
+
+**Configuration:**
+- Vitest coverage via c8 (built-in)
+- Excludes: *.test.ts, bin/install.ts, config files
+
+**View Coverage:**
+```bash
+npm run test:coverage
+open coverage/index.html
+```
+
+## Test Types
+
+**Unit Tests:**
+- Test single function in isolation
+- Mock all external dependencies (fs, child_process)
+- Fast: each test <100ms
+- Examples: parser.test.ts, validator.test.ts
+
+**Integration Tests:**
+- Test multiple modules together
+- Mock only external boundaries (file system, process)
+- Examples: install-service.test.ts (tests service + parser)
+
+**E2E Tests:**
+- Not currently used
+- CLI integration tested manually
+
+## Common Patterns
+
+**Async Testing:**
+```typescript
+it('should handle async operation', async () => {
+  const result = await asyncFunction();
+  expect(result).toBe('expected');
+});
+```
+
+**Error Testing:**
+```typescript
+it('should throw on invalid input', () => {
+  expect(() => parse(null)).toThrow('Cannot parse null');
+});
+
+// Async error
+it('should reject on file not found', async () => {
+  await expect(readConfig('invalid.txt')).rejects.toThrow('ENOENT');
+});
+```
+
+**File System Mocking:**
+```typescript
+import { vi } from 'vitest';
+import * as fs from 'fs-extra';
+
+vi.mock('fs-extra');
+
+it('mocks file system', () => {
+  vi.mocked(fs.readFile).mockResolvedValue('file content');
+  // test code
+});
+```
+
+**Snapshot Testing:**
+- Not used in this codebase
+- Prefer explicit assertions for clarity
+
+---
+
+*Testing analysis: 2025-01-20*
+*Update when test patterns change*
+```
+</good_examples>
+
+<guidelines>
+**What belongs in TESTING.md:**
+- Test framework and runner configuration
+- Test file location and naming patterns
+- Test structure (describe/it, beforeEach patterns)
+- Mocking approach and examples
+- Fixture/factory patterns
+- Coverage requirements
+- How to run tests (commands)
+- Common testing patterns in actual code
+
+**What does NOT belong here:**
+- Specific test cases (defer to actual test files)
+- Technology choices (that's STACK.md)
+- CI/CD setup (that's deployment docs)
+
+**When filling this template:**
+- Check package.json scripts for test commands
+- Find test config file (jest.config.js, vitest.config.ts)
+- Read 3-5 existing test files to identify patterns
+- Look for test utilities in tests/ or test-utils/
+- Check for coverage configuration
+- Document actual patterns used, not ideal patterns
+
+**Useful for phase planning when:**
+- Adding new features (write matching tests)
+- Refactoring (maintain test patterns)
+- Fixing bugs (add regression tests)
+- Understanding verification approach
+- Setting up test infrastructure
+
+**Analysis approach:**
+- Check package.json for test framework and scripts
+- Read test config file for coverage, setup
+- Examine test file organization (collocated vs separate)
+- Review 5 test files for patterns (mocking, structure, assertions)
+- Look for test utilities, fixtures, factories
+- Note any test types (unit, integration, e2e)
+- Document commands for running tests
+</guidelines>

package/get-shit-done/templates/config.json

@@ -0,0 +1,18 @@
+{
+  "mode": "interactive",
+  "depth": "standard",
+  "gates": {
+    "confirm_project": true,
+    "confirm_phases": true,
+    "confirm_roadmap": true,
+    "confirm_breakdown": true,
+    "confirm_plan": true,
+    "execute_next_plan": true,
+    "issues_review": true,
+    "confirm_transition": true
+  },
+  "safety": {
+    "always_confirm_destructive": true,
+    "always_confirm_external_services": true
+  }
+}

package/get-shit-done/templates/context.md

@@ -0,0 +1,161 @@
+# Phase Context Template
+
+Template for `.planning/phases/XX-name/{phase}-CONTEXT.md` - captures the user's vision for a phase.
+
+**Purpose:** Document how the user imagines the phase working. This is vision context, not technical analysis. Technical details come from research.
+
+---
+
+## File Template
+
+```markdown
+# Phase [X]: [Name] - Context
+
+**Gathered:** [date]
+**Status:** [Ready for research / Ready for planning]
+
+<vision>
+## How This Should Work
+
+[User's description of how they imagine this phase working. What happens when someone uses it? What does it look/feel like? This is the "pitch" version, not the technical spec.]
+
+</vision>
+
+<essential>
+## What Must Be Nailed
+
+[The core of this phase. If we only get one thing right, what is it? What's the non-negotiable that makes this phase successful?]
+
+- [Essential thing 1]
+- [Essential thing 2]
+- [Essential thing 3 if applicable]
+
+</essential>
+
+<boundaries>
+## What's Out of Scope
+
+[Explicit exclusions for this phase. What are we NOT building? Where does this phase end and the next begin?]
+
+- [Not doing X - that's Phase Y]
+- [Not including Z - deferred]
+- [Explicitly excluding W]
+
+</boundaries>
+
+<specifics>
+## Specific Ideas
+
+[Any particular things the user has in mind. References to existing products/features they like. Specific behaviors or interactions. "I want it to work like X" or "When you click Y, it should Z."]
+
+[If none: "No specific requirements - open to standard approaches"]
+
+</specifics>
+
+<notes>
+## Additional Context
+
+[Anything else captured during the discussion that doesn't fit above. User's priorities, concerns mentioned, relevant background.]
+
+[If none: "No additional notes"]
+
+</notes>
+
+---
+
+*Phase: XX-name*
+*Context gathered: [date]*
+```
+
+<good_examples>
+```markdown
+# Phase 3: User Dashboard - Context
+
+**Gathered:** 2025-01-20
+**Status:** Ready for research
+
+<vision>
+## How This Should Work
+
+When users log in, they land on a dashboard that shows them everything important at a glance. I imagine it feeling calm and organized - not overwhelming like Jira or cluttered like Notion.
+
+The main thing is seeing their active projects and what needs attention. Think of it like a "what should I work on today" view. It should feel personal, not like enterprise software.
+
+</vision>
+
+<essential>
+## What Must Be Nailed
+
+- **At-a-glance clarity** - Within 2 seconds of landing, user knows what needs their attention
+- **Personal feel** - This is YOUR dashboard, not a team dashboard. It should feel like opening your personal notebook.
+
+</essential>
+
+<boundaries>
+## What's Out of Scope
+
+- Team features (shared dashboards, permissions) - that's a future milestone
+- Analytics/reporting - just show what needs attention, not graphs
+- Customizable layouts - keep it simple, one good layout
+- Mobile optimization - desktop first for now
+
+</boundaries>
+
+<specifics>
+## Specific Ideas
+
+- I like how Linear's home screen highlights what's assigned to you without noise
+- Should show projects in a card format, not a list
+- Maybe a "Today" section at the top with urgent stuff
+- Dark mode is essential (already have this from Phase 2)
+
+</specifics>
+
+<notes>
+## Additional Context
+
+User mentioned they've abandoned several dashboards before because they felt too "corporate." The key differentiator is making it feel personal and calm.
+
+Priority is clarity over features. Better to show less and make it obvious than show everything.
+
+</notes>
+
+---
+
+*Phase: 03-user-dashboard*
+*Context gathered: 2025-01-20*
+```
+</good_examples>
+
+<guidelines>
+**This template captures VISION, not technical specs.**
+
+The user is the visionary. They know:
+- How they imagine it working
+- What it should feel like
+- What's essential vs nice-to-have
+- References to things they like
+
+The user does NOT know (and shouldn't be asked):
+- Codebase patterns (Claude reads the code)
+- Technical risks (Claude identifies during research)
+- Implementation constraints (Claude figures out)
+- Success metrics (Claude infers from the work)
+
+**Content should read like:**
+- A founder describing their product vision
+- "When you use this, it should feel like..."
+- "The most important thing is..."
+- "I don't want it to be like X, I want it to feel like Y"
+
+**Content should NOT read like:**
+- A technical specification
+- Risk assessment matrix
+- Success criteria checklist
+- Codebase analysis
+
+**After creation:**
+- File lives in phase directory: `.planning/phases/XX-name/{phase}-CONTEXT.md`
+- Research phase adds technical context (patterns, risks, constraints)
+- Planning phase creates executable tasks informed by both vision AND research
+</guidelines>