@fermindi/pwn-cli 0.1.1 → 0.2.0

package/templates/workspace/.ai/patterns/universal/README.md

@@ -1,141 +1,141 @@
-# Universal Patterns
-
-This directory contains cross-cutting patterns that apply to both frontend and backend development.
-
-## Overview
-
-Universal patterns cover:
-- TypeScript best practices
-- Testing strategies (unit, integration, e2e)
-- Error handling and logging
-- Git workflow and commit conventions
-- Build tool configuration
-- Code organization
-- Documentation standards
-- Performance profiling
-- Security principles
-
-## Structure
-
-```
-universal/
-├── README.md                  # This file
-├── typescript/                # TypeScript patterns
-│   └── README.md             # Type definitions, generics, etc.
-├── testing/                   # Testing patterns
-│   ├── unit/README.md        # Unit test patterns
-│   ├── integration/README.md # Integration test patterns
-│   └── e2e/README.md         # End-to-end test patterns
-├── error-handling/            # Error handling patterns
-│   └── README.md             # Exception handling, logging
-├── git/                       # Git workflow patterns
-│   └── README.md             # Branching, commits, PRs
-├── build-tools/               # Build and package patterns
-│   └── README.md             # Webpack, Vite, etc.
-├── performance/               # Performance optimization
-│   └── README.md             # Profiling, optimization
-└── security/                  # Security patterns
-    └── README.md             # Input validation, secrets, etc.
-```
-
-## Auto-Apply Triggers
-
-These patterns are automatically loaded when:
-
-- **File:** `*.ts`, `*.tsx` (TypeScript)
-- **File:** `*.test.ts`, `*.spec.ts` (Tests)
-- **Import:** `from 'jest'`, `from 'vitest'` (Testing)
-- **Command:** `git commit`, `npm build` (Git, Build)
-- **Path:** `src/__tests__/`, `cypress/`, `playwright/`
-
-See `patterns/index.md` for trigger configuration.
-
-## Common Patterns
-
-### TypeScript
-- Enable strict mode in `tsconfig.json`
-- Use interfaces for object shapes, types for aliases
-- Avoid `any` - use `unknown` with type guards instead
-- Export types alongside implementations
-- Use generics for reusable, type-safe code
-- Document complex types with JSDoc comments
-
-### Testing Strategy
-- Unit tests for utilities and pure functions
-- Integration tests for API endpoints and workflows
-- E2E tests for critical user journeys
-- Test file co-located with source: `feature.ts` + `feature.test.ts`
-- Aim for >80% code coverage on critical paths
-- Mock external dependencies, test real business logic
-
-### Error Handling
-- Use custom error classes that extend Error
-- Include error context (what, why, how to fix)
-- Log errors with full stack traces
-- Different handling strategies for different error types
-- Never silently catch and ignore errors
-- Provide user-friendly error messages
-
-### Git Workflow
-- Descriptive commit messages (50 char subject, blank line, details)
-- Atomic commits (one logical change per commit)
-- Branch naming: `feature/name`, `fix/name`, `docs/name`
-- Pull request template with context
-- Code review before merge
-- Squash or rebase to keep history clean
-
-### Build Tools
-- Consistent build configuration across projects
-- Separate dev and production builds
-- Fast development build (hot reload, source maps)
-- Optimized production build (minification, tree-shaking)
-- Automate with npm/pnpm scripts
-- Cache dependencies to speed up builds
-
-### Code Organization
-- Organize by feature, not by type
-- Keep related code together
-- Use barrel exports (`index.ts`) for clean imports
-- Avoid circular dependencies
-- Monorepo structure for related packages
-- Clear separation of concerns
-
-### Documentation
-- JSDoc comments for public APIs
-- README files in each directory explaining purpose
-- Architecture decision records (ADRs)
-- Code examples for complex logic
-- Keep docs in sync with code
-- Link to external references where relevant
-
-## Usage
-
-1. Read the relevant sub-directory README for your task
-2. Check code examples for reference implementations
-3. Apply patterns to new code
-4. Update patterns if you discover improvements
-
-## Contributing
-
-Found a better pattern?
-
-1. Document it with examples
-2. Add to appropriate subdirectory
-3. Update this README
-4. Commit with message: `docs: add [pattern name] pattern`
-5. Update triggers in `patterns/index.md` if widely applicable
-
-## Links
-
-- [TypeScript Patterns](typescript/README.md)
-- [Testing Strategies](testing/README.md)
-- [Error Handling](error-handling/README.md)
-- [Git Workflow](git/README.md)
-- [Build Tools](build-tools/README.md)
-- [Performance Profiling](performance/README.md)
-- [Security Principles](security/README.md)
-
-## Version
-
-**Last Updated:** (Set on template injection)
-**Maintained By:** Development Team
+# Universal Patterns
+
+This directory contains cross-cutting patterns that apply to both frontend and backend development.
+
+## Overview
+
+Universal patterns cover:
+- TypeScript best practices
+- Testing strategies (unit, integration, e2e)
+- Error handling and logging
+- Git workflow and commit conventions
+- Build tool configuration
+- Code organization
+- Documentation standards
+- Performance profiling
+- Security principles
+
+## Structure
+
+```
+universal/
+├── README.md                  # This file
+├── typescript/                # TypeScript patterns
+│   └── README.md             # Type definitions, generics, etc.
+├── testing/                   # Testing patterns
+│   ├── unit/README.md        # Unit test patterns
+│   ├── integration/README.md # Integration test patterns
+│   └── e2e/README.md         # End-to-end test patterns
+├── error-handling/            # Error handling patterns
+│   └── README.md             # Exception handling, logging
+├── git/                       # Git workflow patterns
+│   └── README.md             # Branching, commits, PRs
+├── build-tools/               # Build and package patterns
+│   └── README.md             # Webpack, Vite, etc.
+├── performance/               # Performance optimization
+│   └── README.md             # Profiling, optimization
+└── security/                  # Security patterns
+    └── README.md             # Input validation, secrets, etc.
+```
+
+## Auto-Apply Triggers
+
+These patterns are automatically loaded when:
+
+- **File:** `*.ts`, `*.tsx` (TypeScript)
+- **File:** `*.test.ts`, `*.spec.ts` (Tests)
+- **Import:** `from 'jest'`, `from 'vitest'` (Testing)
+- **Command:** `git commit`, `npm build` (Git, Build)
+- **Path:** `src/__tests__/`, `cypress/`, `playwright/`
+
+See `patterns/index.md` for trigger configuration.
+
+## Common Patterns
+
+### TypeScript
+- Enable strict mode in `tsconfig.json`
+- Use interfaces for object shapes, types for aliases
+- Avoid `any` - use `unknown` with type guards instead
+- Export types alongside implementations
+- Use generics for reusable, type-safe code
+- Document complex types with JSDoc comments
+
+### Testing Strategy
+- Unit tests for utilities and pure functions
+- Integration tests for API endpoints and workflows
+- E2E tests for critical user journeys
+- Test file co-located with source: `feature.ts` + `feature.test.ts`
+- Aim for >80% code coverage on critical paths
+- Mock external dependencies, test real business logic
+
+### Error Handling
+- Use custom error classes that extend Error
+- Include error context (what, why, how to fix)
+- Log errors with full stack traces
+- Different handling strategies for different error types
+- Never silently catch and ignore errors
+- Provide user-friendly error messages
+
+### Git Workflow
+- Descriptive commit messages (50 char subject, blank line, details)
+- Atomic commits (one logical change per commit)
+- Branch naming: `feature/name`, `fix/name`, `docs/name`
+- Pull request template with context
+- Code review before merge
+- Squash or rebase to keep history clean
+
+### Build Tools
+- Consistent build configuration across projects
+- Separate dev and production builds
+- Fast development build (hot reload, source maps)
+- Optimized production build (minification, tree-shaking)
+- Automate with npm/pnpm scripts
+- Cache dependencies to speed up builds
+
+### Code Organization
+- Organize by feature, not by type
+- Keep related code together
+- Use barrel exports (`index.ts`) for clean imports
+- Avoid circular dependencies
+- Monorepo structure for related packages
+- Clear separation of concerns
+
+### Documentation
+- JSDoc comments for public APIs
+- README files in each directory explaining purpose
+- Architecture decision records (ADRs)
+- Code examples for complex logic
+- Keep docs in sync with code
+- Link to external references where relevant
+
+## Usage
+
+1. Read the relevant sub-directory README for your task
+2. Check code examples for reference implementations
+3. Apply patterns to new code
+4. Update patterns if you discover improvements
+
+## Contributing
+
+Found a better pattern?
+
+1. Document it with examples
+2. Add to appropriate subdirectory
+3. Update this README
+4. Commit with message: `docs: add [pattern name] pattern`
+5. Update triggers in `patterns/index.md` if widely applicable
+
+## Links
+
+- [TypeScript Patterns](typescript/README.md)
+- [Testing Strategies](testing/README.md)
+- [Error Handling](error-handling/README.md)
+- [Git Workflow](git/README.md)
+- [Build Tools](build-tools/README.md)
+- [Performance Profiling](performance/README.md)
+- [Security Principles](security/README.md)
+
+## Version
+
+**Last Updated:** (Set on template injection)
+**Maintained By:** Development Team

package/templates/workspace/.ai/state.template.json

@@ -1,8 +1,8 @@
-{
-  "developer": "unknown",
-  "session_started": "2026-01-21T00:00:00Z",
-  "current_task": null,
-  "context_loaded": [],
-  "patterns_registered": [],
-  "last_updated": "2026-01-21T00:00:00Z"
-}
+{
+  "developer": "unknown",
+  "session_started": "2026-01-21T00:00:00Z",
+  "current_task": null,
+  "context_loaded": [],
+  "patterns_registered": [],
+  "last_updated": "2026-01-21T00:00:00Z"
+}

package/templates/workspace/.ai/tasks/active.md

@@ -1,77 +1,77 @@
-# Active Tasks
-
-This file tracks work currently in progress.
-
-## Format
-
-Use checkboxes to track completion status:
-
-```markdown
-- [ ] US-001: Pending task
-- [x] US-002: Completed task
-```
-
-Each task can have:
-- **Status indicator:** [ ] = pending, [x] = completed
-- **ID:** US-XXX, BUG-XXX, DEV-XXX, or SPIKE-XXX
-- **Title:** Clear, actionable description
-- **Notes:** Optional context or blockers
-- **Assignee:** Who's working on it (optional)
-
----
-
-## Task Types
-
-- **US-XXX:** User Story (feature work)
-- **BUG-XXX:** Bug fix
-- **DEV-XXX:** Developer task (refactoring, tech debt)
-- **SPIKE-XXX:** Research or investigation
-- **DOCS-XXX:** Documentation
-
----
-
-## Management Rules
-
-1. **Limit WIP:** Keep 3-5 tasks active max
-2. **Prioritize:** Order from highest to lowest priority
-3. **Clarify blockers:** Note if task is blocked
-4. **Update daily:** Check boxes as you work
-5. **Archive completion:** Move finished tasks to backlog with date
-
----
-
-## Template for New Task
-
-```markdown
-- [ ] US-XXX: [Clear title]
-  - Assignee: (your name or team)
-  - Priority: High/Medium/Low
-  - Blocked by: (if applicable)
-  - Notes: (context)
-```
-
----
-
-## Current Sprint
-
-Update this section weekly with sprint goals and dates.
-
-**Sprint:** YYYY-MM-DD to YYYY-MM-DD
-**Goal:** (What we're trying to accomplish)
-**Capacity:** (Team capacity/points)
-
----
-
-## Today's Focus
-
-Highlight 1-3 most important tasks for today.
-
----
-
-## Notes
-
-- Check backlog.md for upcoming work
-- Move completed tasks to archive or backlog with completion date
-- When stuck, create SPIKE task to investigate
-- Reference decisions from `memory/decisions.md`
-- Flag architectural changes for team discussion
+# Active Tasks
+
+This file tracks work currently in progress.
+
+## Format
+
+Use checkboxes to track completion status:
+
+```markdown
+- [ ] US-001: Pending task
+- [x] US-002: Completed task
+```
+
+Each task can have:
+- **Status indicator:** [ ] = pending, [x] = completed
+- **ID:** US-XXX, BUG-XXX, DEV-XXX, or SPIKE-XXX
+- **Title:** Clear, actionable description
+- **Notes:** Optional context or blockers
+- **Assignee:** Who's working on it (optional)
+
+---
+
+## Task Types
+
+- **US-XXX:** User Story (feature work)
+- **BUG-XXX:** Bug fix
+- **DEV-XXX:** Developer task (refactoring, tech debt)
+- **SPIKE-XXX:** Research or investigation
+- **DOCS-XXX:** Documentation
+
+---
+
+## Management Rules
+
+1. **Limit WIP:** Keep 3-5 tasks active max
+2. **Prioritize:** Order from highest to lowest priority
+3. **Clarify blockers:** Note if task is blocked
+4. **Update daily:** Check boxes as you work
+5. **Archive completion:** Move finished tasks to backlog with date
+
+---
+
+## Template for New Task
+
+```markdown
+- [ ] US-XXX: [Clear title]
+  - Assignee: (your name or team)
+  - Priority: High/Medium/Low
+  - Blocked by: (if applicable)
+  - Notes: (context)
+```
+
+---
+
+## Current Sprint
+
+Update this section weekly with sprint goals and dates.
+
+**Sprint:** YYYY-MM-DD to YYYY-MM-DD
+**Goal:** (What we're trying to accomplish)
+**Capacity:** (Team capacity/points)
+
+---
+
+## Today's Focus
+
+Highlight 1-3 most important tasks for today.
+
+---
+
+## Notes
+
+- Check backlog.md for upcoming work
+- Move completed tasks to archive or backlog with completion date
+- When stuck, create SPIKE task to investigate
+- Reference decisions from `memory/decisions.md`
+- Flag architectural changes for team discussion

package/templates/workspace/.ai/tasks/backlog.md

@@ -1,95 +1,95 @@
-# Backlog
-
-This file contains prioritized future tasks not yet in active work.
-
-## Format
-
-Tasks are listed in priority order (highest to lowest):
-
-```markdown
-### US-XXX: Task Title
-**Type:** Story | Bug | DevTask
-**Priority:** High | Medium | Low
-**Effort:** (T-shirt size: XS, S, M, L, XL)
-**Description:** What needs to be done
-**Acceptance Criteria:**
-- [ ] Criterion 1
-- [ ] Criterion 2
-**Dependencies:** (Other tasks needed first)
-**Notes:** Context, caveats, research needed
-```
-
----
-
-## Moving to Active
-
-When starting a backlog task:
-
-1. Create issue/ticket in your tracking system
-2. Move to `active.md` with checkbox
-3. Assign team member
-4. Update priority based on sprint plan
-5. Reference in commit messages
-
----
-
-## Adding New Tasks
-
-When new work is identified:
-
-1. Assign next ID (US-XXX, BUG-XXX, etc.)
-2. Add to appropriate section
-3. Fill in all fields
-4. Don't assign yet - wait for planning
-5. Commit with message: `docs: add [ID] to backlog`
-
----
-
-## Backlog Sections
-
-### High Priority
-Work that should start soon. Review weekly.
-
-### Medium Priority
-Important but can wait. Review biweekly.
-
-### Low Priority
-Nice-to-have improvements. Review monthly.
-
-### Roadmap (Future Phases)
-Longer-term projects for future planning.
-
----
-
-## Template for New Backlog Item
-
-```markdown
-### US-XXX: [Title]
-**Type:** Story | Bug | DevTask
-**Priority:** High | Medium | Low
-**Effort:** S/M/L
-**Description:** (What and why)
-**Acceptance Criteria:**
-- [ ] (Specific, measurable outcome)
-**Dependencies:** (Other tasks)
-**Notes:** (Research, concerns, constraints)
-```
-
----
-
-## Management Guidelines
-
-- Groom backlog every sprint (remove duplicates, clarify)
-- Estimate effort using relative sizing (XS, S, M, L, XL)
-- Link related tasks together
-- Archive completed items with date + time spent
-- Keep description brief - link to external tickets for details
-
----
-
-## Cleanup
-
-- Remove or update duplicates
-- Close blocked items after 30 days of no progress
-- Archive completed items to `completed/` section
-- Re-estimate if context changes significantly
+# Backlog
+
+This file contains prioritized future tasks not yet in active work.
+
+## Format
+
+Tasks are listed in priority order (highest to lowest):
+
+```markdown
+### US-XXX: Task Title
+**Type:** Story | Bug | DevTask
+**Priority:** High | Medium | Low
+**Effort:** (T-shirt size: XS, S, M, L, XL)
+**Description:** What needs to be done
+**Acceptance Criteria:**
+- [ ] Criterion 1
+- [ ] Criterion 2
+**Dependencies:** (Other tasks needed first)
+**Notes:** Context, caveats, research needed
+```
+
+---
+
+## Moving to Active
+
+When starting a backlog task:
+
+1. Create issue/ticket in your tracking system
+2. Move to `active.md` with checkbox
+3. Assign team member
+4. Update priority based on sprint plan
+5. Reference in commit messages
+
+---
+
+## Adding New Tasks
+
+When new work is identified:
+
+1. Assign next ID (US-XXX, BUG-XXX, etc.)
+2. Add to appropriate section
+3. Fill in all fields
+4. Don't assign yet - wait for planning
+5. Commit with message: `docs: add [ID] to backlog`
+
+---
+
+## Backlog Sections
+
+### High Priority
+Work that should start soon. Review weekly.
+
+### Medium Priority
+Important but can wait. Review biweekly.
+
+### Low Priority
+Nice-to-have improvements. Review monthly.
+
+### Roadmap (Future Phases)
+Longer-term projects for future planning.
+
+---
+
+## Template for New Backlog Item
+
+```markdown
+### US-XXX: [Title]
+**Type:** Story | Bug | DevTask
+**Priority:** High | Medium | Low
+**Effort:** S/M/L
+**Description:** (What and why)
+**Acceptance Criteria:**
+- [ ] (Specific, measurable outcome)
+**Dependencies:** (Other tasks)
+**Notes:** (Research, concerns, constraints)
+```
+
+---
+
+## Management Guidelines
+
+- Groom backlog every sprint (remove duplicates, clarify)
+- Estimate effort using relative sizing (XS, S, M, L, XL)
+- Link related tasks together
+- Archive completed items with date + time spent
+- Keep description brief - link to external tickets for details
+
+---
+
+## Cleanup
+
+- Remove or update duplicates
+- Close blocked items after 30 days of no progress
+- Archive completed items to `completed/` section
+- Re-estimate if context changes significantly