@fermindi/pwn-cli 0.1.1 → 0.3.0

package/templates/workspace/.ai/config/README.md

@@ -1,79 +1,79 @@
-# PWN Configuration
-
-This directory contains personal configuration files (git-ignored).
-
-## notifications.json
-
-Configure how you receive notifications when tasks complete.
-
-### Channels
-
-#### Desktop (default)
-Native OS notifications. Works out of the box on Windows, macOS, and Linux.
-
-```json
-{
-  "channels": {
-    "desktop": {
-      "enabled": true
-    }
-  }
-}
-```
-
-#### ntfy.sh
-Free, open-source push notifications. Great for mobile alerts.
-
-```json
-{
-  "channels": {
-    "ntfy": {
-      "enabled": true,
-      "server": "https://ntfy.sh",
-      "topic": "pwn-abc12345",
-      "priority": "default"
-    }
-  }
-}
-```
-
-**Setup:**
-1. A unique topic is auto-generated during `pwn inject`
-2. Subscribe to your topic:
-   - Browser: `https://ntfy.sh/YOUR_TOPIC`
-   - Mobile: Install ntfy app and subscribe to your topic
-3. Enable: set `enabled: true`
-4. Test: `pwn notify test ntfy`
-
-**Privacy:** Topics are public by default. Your auto-generated topic uses a random ID making it hard to guess. For private topics, create an account at ntfy.sh or self-host.
-
-#### Pushover (paid)
-Premium push notification service with more features.
-
-```json
-{
-  "channels": {
-    "pushover": {
-      "enabled": true,
-      "userKey": "your-user-key",
-      "apiToken": "your-api-token"
-    }
-  }
-}
-```
-
-### Priority Levels
-
-- `low` - Silent, no sound
-- `default` - Normal notification
-- `high` - Important, may bypass DND
-- `urgent` - Critical, persistent alert
-
-### Commands
-
-```bash
-pwn notify test              # Test default channel (desktop)
-pwn notify test ntfy         # Test specific channel
-pwn notify send "Message"    # Send custom notification
-pwn notify config            # Show current configuration
-```
+# PWN Configuration
+
+This directory contains personal configuration files (git-ignored).
+
+## notifications.json
+
+Configure how you receive notifications when tasks complete.
+
+### Channels
+
+#### Desktop (default)
+Native OS notifications. Works out of the box on Windows, macOS, and Linux.
+
+```json
+{
+  "channels": {
+    "desktop": {
+      "enabled": true
+    }
+  }
+}
+```
+
+#### ntfy.sh
+Free, open-source push notifications. Great for mobile alerts.
+
+```json
+{
+  "channels": {
+    "ntfy": {
+      "enabled": true,
+      "server": "https://ntfy.sh",
+      "topic": "pwn-abc12345",
+      "priority": "default"
+    }
+  }
+}
+```
+
+**Setup:**
+1. A unique topic is auto-generated during `pwn inject`
+2. Subscribe to your topic:
+   - Browser: `https://ntfy.sh/YOUR_TOPIC`
+   - Mobile: Install ntfy app and subscribe to your topic
+3. Enable: set `enabled: true`
+4. Test: `pwn notify test ntfy`
+
+**Privacy:** Topics are public by default. Your auto-generated topic uses a random ID making it hard to guess. For private topics, create an account at ntfy.sh or self-host.
+
+#### Pushover (paid)
+Premium push notification service with more features.
+
+```json
+{
+  "channels": {
+    "pushover": {
+      "enabled": true,
+      "userKey": "your-user-key",
+      "apiToken": "your-api-token"
+    }
+  }
+}
+```
+
+### Priority Levels
+
+- `low` - Silent, no sound
+- `default` - Normal notification
+- `high` - Important, may bypass DND
+- `urgent` - Critical, persistent alert
+
+### Commands
+
+```bash
+pwn notify test              # Test default channel (desktop)
+pwn notify test ntfy         # Test specific channel
+pwn notify send "Message"    # Send custom notification
+pwn notify config            # Show current configuration
+```

package/templates/workspace/.ai/config/notifications.template.json

@@ -1,20 +1,20 @@
-{
-  "enabled": true,
-  "defaultChannel": "desktop",
-  "channels": {
-    "ntfy": {
-      "enabled": false,
-      "server": "https://ntfy.sh",
-      "topic": "your-unique-topic-here",
-      "priority": "default"
-    },
-    "desktop": {
-      "enabled": true
-    },
-    "pushover": {
-      "enabled": false,
-      "userKey": "",
-      "apiToken": ""
-    }
-  }
-}
+{
+  "enabled": true,
+  "defaultChannel": "desktop",
+  "channels": {
+    "ntfy": {
+      "enabled": false,
+      "server": "https://ntfy.sh",
+      "topic": "your-unique-topic-here",
+      "priority": "default"
+    },
+    "desktop": {
+      "enabled": true
+    },
+    "pushover": {
+      "enabled": false,
+      "userKey": "",
+      "apiToken": ""
+    }
+  }
+}

package/templates/workspace/.ai/memory/deadends.md

@@ -1,79 +1,79 @@
-# Failed Approaches & Dead Ends
-
-This file documents approaches that failed, to avoid repeating mistakes.
-
-## Format
-
-Each dead end follows this structure:
-
-```markdown
-## DE-XXX: Failed Approach Title
-**Date:** YYYY-MM-DD
-**Attempted:** What we tried
-**Problem:** Why it failed
-**Solution:** What worked instead
-**Time Spent:** Approximate hours
-**Reference:** Related decision or issue
-```
-
----
-
-## Adding New Dead Ends
-
-When an approach fails:
-
-1. Assign next DE number (DE-001, DE-002, etc.)
-2. Fill in all sections while fresh in memory
-3. Commit with message: `docs: add DE-XXX dead end`
-4. Reference in code: `// See DE-XXX - why we don't use X`
-
----
-
-## Categories
-
-- **Architecture:** Structural decisions that didn't work
-- **Performance:** Optimization attempts that backfired
-- **Dependencies:** Library choices that caused problems
-- **Testing:** Test strategies that were too brittle
-- **Integration:** External service integrations that failed
-- **Data Modeling:** Schema or object structure issues
-- **DevOps:** Deployment/infrastructure approaches
-
----
-
-## Template for New Dead End
-
-```markdown
-## DE-XXX: [Title]
-**Date:** YYYY-MM-DD
-**Attempted:** (What we tried and why we thought it would work)
-**Problem:** (Why it failed - specific errors, limitations, etc.)
-**Solution:** (What we did instead - working approach)
-**Time Spent:** X hours
-**Reference:** (Link to related DEC, issue, or PR)
-```
-
----
-
-## Tips for Recording Dead Ends
-
-- Be honest about what failed
-- Include error messages and specific blockers
-- Document the solution for future reference
-- Note if this is a category-wide dead end or specific case
-- Update if you discover new info about why it failed
-
----
-
-## Archiving
-
-Dead ends are archived to `/context/dead-ends/archive/` after:
-- 90 days with no new references
-- Superseded by later approaches
-- External changes (library update) invalidate the issue
-
----
-
-## Current Backlog
-
-Document new dead ends as they occur. Keep the most recent 5-10 active.
+# Failed Approaches & Dead Ends
+
+This file documents approaches that failed, to avoid repeating mistakes.
+
+## Format
+
+Each dead end follows this structure:
+
+```markdown
+## DE-XXX: Failed Approach Title
+**Date:** YYYY-MM-DD
+**Attempted:** What we tried
+**Problem:** Why it failed
+**Solution:** What worked instead
+**Time Spent:** Approximate hours
+**Reference:** Related decision or issue
+```
+
+---
+
+## Adding New Dead Ends
+
+When an approach fails:
+
+1. Assign next DE number (DE-001, DE-002, etc.)
+2. Fill in all sections while fresh in memory
+3. Commit with message: `docs: add DE-XXX dead end`
+4. Reference in code: `// See DE-XXX - why we don't use X`
+
+---
+
+## Categories
+
+- **Architecture:** Structural decisions that didn't work
+- **Performance:** Optimization attempts that backfired
+- **Dependencies:** Library choices that caused problems
+- **Testing:** Test strategies that were too brittle
+- **Integration:** External service integrations that failed
+- **Data Modeling:** Schema or object structure issues
+- **DevOps:** Deployment/infrastructure approaches
+
+---
+
+## Template for New Dead End
+
+```markdown
+## DE-XXX: [Title]
+**Date:** YYYY-MM-DD
+**Attempted:** (What we tried and why we thought it would work)
+**Problem:** (Why it failed - specific errors, limitations, etc.)
+**Solution:** (What we did instead - working approach)
+**Time Spent:** X hours
+**Reference:** (Link to related DEC, issue, or PR)
+```
+
+---
+
+## Tips for Recording Dead Ends
+
+- Be honest about what failed
+- Include error messages and specific blockers
+- Document the solution for future reference
+- Note if this is a category-wide dead end or specific case
+- Update if you discover new info about why it failed
+
+---
+
+## Archiving
+
+Dead ends are archived to `/context/dead-ends/archive/` after:
+- 90 days with no new references
+- Superseded by later approaches
+- External changes (library update) invalidate the issue
+
+---
+
+## Current Backlog
+
+Document new dead ends as they occur. Keep the most recent 5-10 active.

package/templates/workspace/.ai/memory/decisions.md

@@ -1,58 +1,58 @@
-# Architectural Decisions
-
-This file tracks major architectural decisions made for this project.
-
-## Format
-
-Each decision follows this structure:
-
-```markdown
-## DEC-XXX: Decision Title
-**Date:** YYYY-MM-DD
-**Status:** Active | Superseded | Deprecated
-**Context:** Why this decision was needed
-**Decision:** What was decided
-**Rationale:** Why this is the best choice
-**Impact:** What this affects
-**Alternatives Considered:** Other options we evaluated
-```
-
----
-
-## DEC-001: Example Decision
-**Date:** 2026-01-21
-**Status:** Active
-**Context:** (Describe the situation that required this decision)
-**Decision:** (State what was decided)
-**Rationale:** (Explain why this is the right choice)
-**Impact:** (List what this affects - files, patterns, dependencies)
-**Alternatives Considered:**
-- Option A: (why rejected)
-- Option B: (why rejected)
-
----
-
-## Adding New Decisions
-
-When making significant architectural choices:
-1. Assign next DEC number (DEC-002, DEC-003, etc.)
-2. Fill in all sections
-3. Commit with message: `docs: add DEC-XXX decision`
-4. Reference in code comments: `// See DEC-XXX`
-
-## Decision Categories
-
-- **Technology Choices:** Frameworks, libraries, tools
-- **Architecture Patterns:** How systems interact
-- **Data Models:** Database schemas, API contracts
-- **Security:** Authentication, authorization, encryption
-- **Performance:** Caching, optimization strategies
-- **DevOps:** Deployment, CI/CD, monitoring
-
-## Superseding Decisions
-
-When a decision changes:
-1. Update status to "Superseded"
-2. Link to new decision: "Superseded by DEC-XXX"
-3. Don't delete - keep for historical context
-4. Move to `.ai/memory/archive/` after 90 days unused
+# Architectural Decisions
+
+This file tracks major architectural decisions made for this project.
+
+## Format
+
+Each decision follows this structure:
+
+```markdown
+## DEC-XXX: Decision Title
+**Date:** YYYY-MM-DD
+**Status:** Active | Superseded | Deprecated
+**Context:** Why this decision was needed
+**Decision:** What was decided
+**Rationale:** Why this is the best choice
+**Impact:** What this affects
+**Alternatives Considered:** Other options we evaluated
+```
+
+---
+
+## DEC-001: Example Decision
+**Date:** 2026-01-21
+**Status:** Active
+**Context:** (Describe the situation that required this decision)
+**Decision:** (State what was decided)
+**Rationale:** (Explain why this is the right choice)
+**Impact:** (List what this affects - files, patterns, dependencies)
+**Alternatives Considered:**
+- Option A: (why rejected)
+- Option B: (why rejected)
+
+---
+
+## Adding New Decisions
+
+When making significant architectural choices:
+1. Assign next DEC number (DEC-002, DEC-003, etc.)
+2. Fill in all sections
+3. Commit with message: `docs: add DEC-XXX decision`
+4. Reference in code comments: `// See DEC-XXX`
+
+## Decision Categories
+
+- **Technology Choices:** Frameworks, libraries, tools
+- **Architecture Patterns:** How systems interact
+- **Data Models:** Database schemas, API contracts
+- **Security:** Authentication, authorization, encryption
+- **Performance:** Caching, optimization strategies
+- **DevOps:** Deployment, CI/CD, monitoring
+
+## Superseding Decisions
+
+When a decision changes:
+1. Update status to "Superseded"
+2. Link to new decision: "Superseded by DEC-XXX"
+3. Don't delete - keep for historical context
+4. Move to `.ai/memory/archive/` after 90 days unused

package/templates/workspace/.ai/memory/patterns.md

@@ -1,65 +1,65 @@
-# Codebase Patterns
-
-This file documents recurring patterns discovered during development.
-
-## Format
-
-Each pattern follows this structure:
-
-```markdown
-## Pattern Category
-
-### Pattern Name
-**Context:** When this pattern applies
-**Pattern:** Code example or description
-**Rationale:** Why this is the better approach
-**Example Location:** Where to find real examples
-```
-
----
-
-## Add New Patterns
-
-When you discover a useful pattern:
-
-1. Identify the category (Frontend, Backend, Testing, etc.)
-2. Fill in all sections
-3. Add code example if possible
-4. Commit with message: `docs: add pattern - [name]`
-5. Update `patterns/index.md` if this should be auto-applied
-
----
-
-## Pattern Categories
-
-- **Frontend:** React, TypeScript, styling, component patterns
-- **Backend:** API design, database queries, middleware
-- **Testing:** Unit tests, integration tests, fixtures
-- **Performance:** Caching, memoization, optimization
-- **Security:** Input validation, authentication, authorization
-- **Error Handling:** Exception patterns, recovery strategies
-- **Data Structures:** Modeling domain objects effectively
-
----
-
-## Template for New Pattern
-
-```markdown
-## [Category]
-
-### [Pattern Name]
-**Context:** (When to use this pattern)
-**Pattern:** (Description or code example)
-**Rationale:** (Why this is better)
-**Example Location:** (Where in codebase)
-```
-
----
-
-## Notes
-
-- Patterns should be language-agnostic when possible
-- Prioritize patterns that prevent common bugs
-- Link related patterns together
-- Update this file as team learns new approaches
-- Archive rarely-used patterns after 3 months of no references
+# Codebase Patterns
+
+This file documents recurring patterns discovered during development.
+
+## Format
+
+Each pattern follows this structure:
+
+```markdown
+## Pattern Category
+
+### Pattern Name
+**Context:** When this pattern applies
+**Pattern:** Code example or description
+**Rationale:** Why this is the better approach
+**Example Location:** Where to find real examples
+```
+
+---
+
+## Add New Patterns
+
+When you discover a useful pattern:
+
+1. Identify the category (Frontend, Backend, Testing, etc.)
+2. Fill in all sections
+3. Add code example if possible
+4. Commit with message: `docs: add pattern - [name]`
+5. Update `patterns/index.md` if this should be auto-applied
+
+---
+
+## Pattern Categories
+
+- **Frontend:** React, TypeScript, styling, component patterns
+- **Backend:** API design, database queries, middleware
+- **Testing:** Unit tests, integration tests, fixtures
+- **Performance:** Caching, memoization, optimization
+- **Security:** Input validation, authentication, authorization
+- **Error Handling:** Exception patterns, recovery strategies
+- **Data Structures:** Modeling domain objects effectively
+
+---
+
+## Template for New Pattern
+
+```markdown
+## [Category]
+
+### [Pattern Name]
+**Context:** (When to use this pattern)
+**Pattern:** (Description or code example)
+**Rationale:** (Why this is better)
+**Example Location:** (Where in codebase)
+```
+
+---
+
+## Notes
+
+- Patterns should be language-agnostic when possible
+- Prioritize patterns that prevent common bugs
+- Link related patterns together
+- Update this file as team learns new approaches
+- Archive rarely-used patterns after 3 months of no references