jettypod 4.1.0 → 4.1.1

package/test-tmp/external-transition-1762982855562/.claude/skills/epic-planning/SKILL.md

@@ -0,0 +1,297 @@
+---
+name: epic-planning
+description: Guide epic planning with feature brainstorming and optional architectural decision prototyping. Use when user asks to plan an epic, mentions planning features for an epic, says "help me plan epic", or when they just created an epic and want to break it down into features.
+---
+
+# Epic Planning Skill
+
+Guides Claude through comprehensive epic planning including feature identification and architectural decisions.
+
+## Instructions
+
+When this skill is activated, you are helping plan an epic. Follow this structured approach:
+
+### Step 1: Understand the Epic
+
+You'll receive context about the epic being planned. Review:
+- Epic title and description
+- Project context
+- Any parent context
+
+### Step 2: Check Existing Features and Decisions
+
+**CRITICAL:** Before suggesting features or approaches, check what already exists:
+
+**Check for existing features:**
+```bash
+node jettypod.js backlog | grep -A 20 "Epic Name"
+```
+
+If features already exist, acknowledge them and skip to Step 4 (Architectural Decision).
+
+**Check for existing decisions:**
+```bash
+node -e "const { showDecisionsForEpic } = require('./features/decisions/index.js'); showDecisionsForEpic(epicId)"
+```
+
+If decisions exist, present them to the user:
+
+```
+🎯 **Existing Architectural Decisions for This Epic:**
+
+[For each decision:]
+- **[Aspect]:** [Decision]
+  *Rationale:* [Why this was chosen]
+  *Decided:* [Date]
+
+These decisions were made previously. Before we continue:
+1. Do these decisions still apply?
+2. Should we revisit any of them?
+3. Are there additional aspects we need to decide?
+```
+
+Only proceed with suggesting new architectural options if:
+- No decisions exist yet, OR
+- User confirms decisions need to be revisited, OR
+- User identifies new aspects to decide
+
+### Step 3: Brainstorm Features (Skip if Features Already Exist)
+
+Based on the epic's purpose, suggest features that belong in this epic:
+
+```
+I'll help you plan the features for this epic.
+
+Based on [epic name], here are the features I recommend:
+
+**Feature 1: [Name]** - [Brief description of what users can do]
+**Feature 2: [Name]** - [Brief description]
+**Feature 3: [Name]** - [Brief description]
+...
+
+**Questions:**
+- [Any clarifying questions about scope]
+- [Missing features to consider]
+
+What features should we include? What am I missing?
+```
+
+### Step 4: Architectural Decision (Optional)
+
+After features are defined, ask if this epic needs a shared technical approach:
+
+```
+**Architectural question:** Does this epic need a shared technical decision?
+
+For example:
+- Which library/framework for this capability?
+- What data structure or protocol?
+- What architectural pattern?
+
+Examples where architectural decisions matter:
+- Real-time features: WebSockets vs SSE vs polling?
+- Auth system: Which auth library and token strategy?
+- Data sync: Optimistic vs pessimistic locking?
+
+Should we explore different architectural approaches?
+```
+
+### Step 5A: If Architectural Decision Needed
+
+If the epic needs architectural decision, suggest exactly 3 approaches:
+
+```
+Here are 3 different architectural approaches for [epic name]:
+
+**Option 1: [Simple/Conservative approach name]**
+- **Pros**: ✅ [2-3 advantages - proven, reliable, fast to implement]
+- **Cons**: ❌ [2-3 trade-offs - limitations, constraints]
+- **Technical Impact**: [How this affects the features in this epic]
+
+**Option 2: [Balanced approach name]**
+- **Pros**: ✅ [2-3 advantages - good balance]
+- **Cons**: ❌ [2-3 trade-offs]
+- **Technical Impact**: [How this affects the features in this epic]
+
+**Option 3: [Advanced/Modern approach name]**
+- **Pros**: ✅ [2-3 advantages - powerful, flexible]
+- **Cons**: ❌ [2-3 trade-offs - complexity, learning curve]
+- **Technical Impact**: [How this affects the features in this epic]
+
+**Additional approaches considered but not recommended:**
+- *[Alternative 1]*: [Brief] - Not selected because [reason]
+- *[Alternative 2]*: [Brief] - Not selected because [reason]
+
+Would you like me to create working prototypes of these architectural approaches?
+```
+
+### Step 5B: If Prototyping Needed
+
+If user wants to prototype approaches:
+
+1. Build 2-3 prototype approaches in `/prototypes/epic-[id]-[approach-name]/`
+2. Each prototype should demonstrate the architectural difference
+3. **Add prototype header**:
+   ```
+   // Prototype: Epic [epic-id] - [approach name]
+   // Created: [date]
+   // Purpose: Demonstrate [architectural aspect]
+   // Decision: [to be filled after testing]
+   ```
+4. After user tests, help them choose the winner
+5. Document the decision and rationale
+
+### Step 5C: If Approach Already Known
+
+If user already knows the approach or skips prototyping:
+
+```
+Which architectural approach works best for this epic?
+```
+
+Then record their decision.
+
+### Step 6: Create Features and Complete Discovery
+
+Once features are defined and architectural decision is made (if needed):
+
+**CRITICAL: You must EXECUTE commands using the Bash tool. Do NOT just display them as text.**
+
+#### Step 6A: Create Features
+
+Use the Bash tool to create each feature:
+
+```javascript
+// For each feature, use Bash tool to execute:
+node jettypod.js work create feature "[Feature 1]" "[Description]" --parent=[epic-id]
+node jettypod.js work create feature "[Feature 2]" "[Description]" --parent=[epic-id]
+// etc.
+```
+
+Display to user as you create each one:
+```
+Creating features...
+✅ Created Feature #123: [Feature 1]
+✅ Created Feature #456: [Feature 2]
+```
+
+#### Step 6B: Record Architectural Decision (if applicable)
+
+If an architectural decision was made, propose the rationale to the user:
+
+```
+I'm going to record this architectural decision:
+
+Aspect: Architecture
+Decision: [architectural approach chosen]
+Rationale: [why this approach was selected]
+
+Does this rationale capture why you chose this approach? (You can edit it if needed)
+```
+
+**WAIT for user to confirm or provide edited rationale.**
+
+**CRITICAL: After user confirms, use Bash tool to EXECUTE the epic-implement command:**
+
+```javascript
+// Use Bash tool to execute:
+node jettypod.js work epic-implement [epic-id] \
+  --aspect="Architecture" \
+  --decision="[architectural approach chosen]" \
+  --rationale="[user's confirmed/edited rationale]"
+```
+
+**DO NOT display this as example text. EXECUTE IT using the Bash tool.**
+
+After execution succeeds, verify the decision was recorded and display:
+
+```
+✅ Architectural decision recorded
+
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+🎯 Epic Planning Complete!
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+Features created: [count]
+Architectural decision: Recorded
+
+**Next step:** Plan your first feature
+Run: jettypod work discover [feature-id]
+Or talk to Claude Code: "Let's do feature discovery for #[feature-id]"
+```
+
+## Key Principles
+
+1. **Feature brainstorming is always required** - Don't skip this even if architectural decision is clear
+2. **Architectural decision is optional** - Not all epics need one (e.g., "Q1 Goals" is just grouping)
+3. **Always suggest exactly 3 options** when architectural decision needed - Simple/Conservative, Balanced, Advanced
+4. **Be specific about features** - Each feature should be user-facing capability
+5. **Use the Approach Suggestion template** - Pros, Cons, Technical Impact format
+6. **Suggest next step** - Always end with clear guidance on what to do next
+7. **Use jettypod commands** - Create features using jettypod CLI, record decisions with epic-implement
+
+## Example: Epic with Architectural Decision
+
+Epic: "Real-time Collaboration"
+
+**Features brainstormed:**
+- Live cursor tracking
+- Concurrent editing with conflict resolution
+- Presence indicators
+- Real-time chat
+
+**Architectural approaches suggested:**
+
+**Option 1: Long Polling (REST)**
+- **Pros**: ✅ Simple, works with all proxies, uses existing HTTP infrastructure
+- **Cons**: ❌ Higher latency (1-2s), more server load, inefficient for high-frequency updates
+- **Technical Impact**: Each feature polls independently, easy to implement per feature
+
+**Option 2: Server-Sent Events (SSE)**
+- **Pros**: ✅ Lightweight, auto-reconnection, efficient one-way streaming
+- **Cons**: ❌ One-direction only (server→client), limited browser connections (6 per domain)
+- **Technical Impact**: Good for cursor/presence, requires separate POST for edits
+
+**Option 3: WebSockets (Socket.io)**
+- **Pros**: ✅ Bidirectional, low latency (<100ms), perfect for real-time, fallback support
+- **Cons**: ❌ More complex infrastructure, requires sticky sessions, WebSocket proxies needed
+- **Technical Impact**: All features use unified connection, best UX but infrastructure complexity
+
+**Additional approaches considered:**
+- *WebRTC Data Channels*: Peer-to-peer, low latency - Not selected due to NAT/firewall traversal complexity
+- *GraphQL Subscriptions*: Good for selective updates - Not selected as overkill for this use case
+
+**User choice:** Option 3 (WebSockets with Socket.io)
+
+**Rationale confirmation:**
+Claude proposes: "Bidirectional real-time updates needed for collaboration, Socket.io provides fallbacks and auto-reconnection"
+User confirms: "Yes, that's right"
+
+**Command run:**
+```bash
+jettypod work epic-implement 5 \
+  --aspect="Architecture" \
+  --decision="WebSockets with Socket.io" \
+  --rationale="Bidirectional real-time updates needed for collaboration, Socket.io provides fallbacks and auto-reconnection"
+```
+
+## Example: Epic without Architectural Decision
+
+Epic: "User Management"
+
+**Features brainstormed:**
+- User registration
+- Profile editing
+- Password reset
+- Account deletion
+
+**Architectural decision:** None needed - these are independent features using existing auth system
+
+## Validation
+
+Before completing epic discovery, ensure:
+- [ ] At least 2-3 features identified
+- [ ] Features are user-facing capabilities (not technical tasks)
+- [ ] Architectural decision documented if needed
+- [ ] Features created in database
+- [ ] User knows next step .jettypod work discover [feature-id])

package/test-tmp/external-transition-1762982855562/.claude/skills/external-transition/SKILL.md

@@ -0,0 +1,384 @@
+---
+name: external-transition
+description: Guide users through transitioning project from internal to external state when they mention launch, production deployment, or accepting real users. Explains infrastructure work creation and gets confirmation before executing.
+---
+
+# External Transition Skill
+
+Guides users through transitioning their JettyPod project from internal (staging/preview) to external (production-ready) state.
+
+## When to Activate
+
+This skill should activate when the user expresses intent to:
+- Launch to production
+- Accept external/real users
+- Deploy publicly
+- Go live
+- Prepare for production
+- Make the project production-ready
+- Similar language indicating readiness for customer/public access
+
+## Instructions
+
+When this skill is activated, follow this structured approach:
+
+### Step 1: Explain the Transition
+
+**CRITICAL:** Do not execute anything yet. First explain what this transition means.
+
+Say to the user:
+
+```
+You're ready to transition to external state. Here's what that means:
+
+🏗️  **Infrastructure Work Items Will Be Created:**
+
+I'll create an "Infrastructure Readiness" epic with 15 work items across 4 categories:
+
+• **Security Infrastructure (5 items)**
+  - Input validation on public endpoints
+  - SQL injection prevention
+  - XSS protection
+  - Rate limiting on public APIs
+  - Authentication/authorization
+
+• **Monitoring Setup (3 items)**
+  - Error tracking integration
+  - Performance monitoring
+  - Audit logging
+
+• **Infrastructure Setup (4 items)**
+  - Database backup automation
+  - Rollback procedures tested
+  - Load testing completed
+  - Graceful degradation under load
+
+• **Compliance (3 items)**
+  - Privacy policy
+  - Data retention policy
+  - Security headers implemented
+
+📦 **Production Chores Will Be Generated:**
+
+For each feature currently in stable mode, I'll:
+  • Generate production scenarios from your chosen standards
+  • Append scenarios to the feature's BDD file
+  • Create production chores (security, scale, compliance)
+  • Move features to production mode and reopen them
+
+This uses your feature's BDD scenarios as context for what needs hardening.
+
+⚠️  **Mode Requirement Changes:**
+
+After this transition, ALL customer-facing features MUST be built through Production mode (not Stable).
+
+This change is essentially permanent - you're declaring that real users will access your project.
+
+Ready to proceed? (yes/no)
+```
+
+### Step 2: Wait for Initial Confirmation
+
+**CRITICAL:** Do NOT proceed without explicit confirmation from the user.
+
+Wait for the user to respond with "yes" or similar affirmative response.
+
+If they say "no" or express hesitation, ask what concerns they have or what they need to clarify.
+
+### Step 3: Production Standards Selection
+
+After user confirms, explain production standards and show preset options:
+
+```
+Before we transition, let's establish your production standards. These define what "production-ready" means for your project and will guide all future production work.
+
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+📋 Choose Your Production Standards Preset
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+🚀 **Startup MVP**
+Early-stage products, internal tools going external, prototypes with first users
+
+Examples: Beta SaaS with first 20 customers, internal tool opened to partners, developer tool in early access, side project gaining traction
+
+What you get:
+  ✅ HTTPS/TLS, basic auth, structured logging
+  ✅ Health checks, daily backups (24h RPO)
+  ✅ Single region, 2 instances, 99.0% SLO
+  ❌ No 24/7 on-call, no multi-region
+
+Cost: $200–$500/mo | Time: 1–2 weeks
+
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+🏢 **Production SaaS**
+Established SaaS with paying customers, revenue dependency, uptime expectations
+
+Examples: B2B SaaS with annual contracts, consumer app with 5k DAU, API service with enterprise customers, e-commerce platform
+
+What you get:
+  ✅ WAF + rate limiting, OAuth/OIDC
+  ✅ APM with SLO dashboards, PII sanitization
+  ✅ Zero-downtime deployments, 15min backups
+  ✅ Multi-AZ, on-call rotation, 99.9% SLO
+  ⚠️ Single region (multi-region optional)
+
+Cost: $1.5k–$4k/mo infra + $2k–$3k/mo ops | Time: 4–6 weeks
+
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+🏛️ **Enterprise**
+Mission-critical systems, large customer base with strict SLAs, Fortune 500 customers
+
+Examples: Enterprise SaaS for F500, financial services platform, infrastructure/DevOps tooling, global marketplace
+
+What you get:
+  ✅ Everything in Production SaaS, plus:
+  ✅ Multi-region active-passive or active-active
+  ✅ Advanced DDoS, mTLS, per-tenant encryption
+  ✅ SOC2 Type II ready, chaos engineering
+  ✅ PITR backups (1min RPO), 99.95% SLO
+
+Cost: $5k–$15k/mo infra + $4k–$8k/mo ops | Time: 8–12 weeks
+
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+🏥 **Regulated (Healthcare, Finance, Gov)**
+Products handling PHI, PCI, FedRAMP - strict compliance mandates, legal liability
+
+Examples: Healthcare app (HIPAA), fintech/payments (PCI), government contractor (FedRAMP), legal tech, HR platform
+
+What you get:
+  ✅ Everything in Enterprise, plus:
+  ✅ HIPAA/PCI/FedRAMP compliance controls
+  ✅ Encryption at rest/in transit, MFA, PAM
+  ✅ Quarterly pentesting, annual audits
+  ✅ Real-time replication, 99.99% SLO
+
+Cost: $10k–$30k/mo infra + $6k–$12k/mo ops + $20k–$50k/yr audits | Time: 12–24 weeks
+
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+Which preset best matches your needs? (startup-mvp / production-saas / enterprise / regulated)
+```
+
+### Step 4: Refinement Questions
+
+After user selects preset, ask 3-5 refinement questions to tailor standards:
+
+**For All Presets:**
+
+1. **What does your app do?** (free text)
+   - Use to validate preset choice and infer compliance needs
+
+2. **How many users do you expect?**
+   - Options: 1-10 / 10-100 / 100-1k / 1k-10k / 10k+
+   - Use to adjust performance budgets
+
+3. **What happens if it's down for an hour?**
+   - Options: No big deal / Users annoyed / Revenue loss / Contractual violation / Safety risk
+   - Use to validate SLO and on-call needs
+
+4. **What happens if you lose the last day of data?**
+   - Options: Annoying / Bad but recoverable / Major problem / Catastrophic
+   - Use to adjust RPO (24h → 15min → 1min)
+
+5. **Does it handle sensitive data? If yes, what kind?**
+   - Examples: Passwords only / Email addresses / Credit cards / Health records
+   - Use to activate PII sanitization, encryption, compliance
+
+**Additional for Production SaaS / Enterprise / Regulated:**
+
+6. **Where are your users?** (Single country / North America / Europe / Global)
+   - Use for data residency requirements
+
+7. **Do you have compliance requirements?** (GDPR / CCPA / SOC2 / HIPAA / PCI / None yet)
+   - Use to activate specific compliance standards
+
+8. **How often do you want to deploy?** (Daily+ / Weekly / Monthly)
+   - Use to recommend canary/feature flags
+
+### Step 5: Generate and Show Recommendations
+
+After collecting answers, use the `lib/production-standards-engine.js` to generate tailored standards, then show recommendations:
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+📋 Recommended Production Standards
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+Based on:
+  • Preset: [preset name]
+  • App: [user's description]
+  • Users: [user count]
+  • Downtime impact: [impact level]
+  • Data loss impact: [impact level]
+  • Sensitive data: [yes/no + types]
+  • Compliance: [requirements]
+
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+✅ SECURITY ([X] standards)
+
+  [✓] TLS/HTTPS enforcement
+      Why: [reasoning]
+      Test: [acceptance criteria]
+
+  [✓] [Other security standards...]
+
+✅ PERFORMANCE & SCALE ([X] standards)
+
+  [✓] Performance budgets
+      Why: [reasoning]
+      Test: [acceptance criteria]
+
+  [✓] [Other scale standards...]
+
+✅ COMPLIANCE ([X] standards)
+
+  [✓] [Compliance standards if applicable]
+
+✅ INFRASTRUCTURE ([X] standards)
+
+  [✓] [Infrastructure standards]
+
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+💰 Estimated Cost: $[X]–$[Y]/mo
+
+  Infrastructure: $[range]
+  Operations: $[range]
+  Drivers: [list of cost drivers]
+
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+⚠️  Warnings (if any)
+
+  • [Warning messages for edge cases]
+
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+Accept these standards? (yes / review / customize)
+```
+
+### Step 6: Handle Customization
+
+If user chooses "review" or "customize", offer interactive customization:
+
+```
+Which standards would you like to adjust?
+
+Commands:
+  • disable <id>   - Disable a non-required standard
+  • adjust <id>    - Modify threshold/config
+  • show <id>      - Show details for a standard
+  • done           - Accept current configuration
+```
+
+Allow user to toggle/adjust standards, then regenerate the summary.
+
+### Step 7: Save Production Standards
+
+After user accepts, save standards to `.jettypod/production-standards.json` using the engine's output format.
+
+Confirm to user:
+
+```
+✅ Production standards saved to .jettypod/production-standards.json
+
+These standards will guide all production mode work going forward.
+```
+
+### Step 8: Final Confirmation for Transition
+
+Now confirm the actual state transition:
+
+```
+Ready to execute the external transition? (yes/no)
+```
+
+Wait for final "yes" confirmation.
+
+### Step 9: Execute Transition
+
+Only after receiving explicit "yes" confirmation, execute the transition using the Bash tool:
+
+```bash
+node jettypod.js project external
+```
+
+### Step 10: Report Results
+
+After the command completes successfully, relay the results to the user:
+
+```
+✅ **Transition Complete!**
+
+Your project is now in external state.
+
+📦 Created Infrastructure Readiness epic with:
+  • 4 features (Security, Monitoring, Infrastructure, Compliance)
+  • 15 chores across those features
+
+🔍 Production mode work items are now visible in your backlog.
+
+**Next Steps:**
+
+1. Run `jettypod backlog` to see all infrastructure work items
+2. Start working on infrastructure: `jettypod work start [epic-id]`
+3. Remember: All customer-facing features must use Production mode from now on
+
+**Want to start on infrastructure work now?**
+```
+
+### Step 11: Guide Next Actions
+
+If the user wants to start infrastructure work:
+- Suggest they run `jettypod backlog` to see the epic
+- Offer to help them start work on specific infrastructure items
+
+If they want to continue building features:
+- Remind them that customer-facing features require Production mode
+- Explain that Production mode includes security, scale, and compliance chores
+
+## Key Principles
+
+1. **Always explain before executing** - User must understand the implications
+2. **Always get confirmation** - This is a significant project state change
+3. **Emphasize no duplication** - Production chores already exist from stable mode
+4. **Clarify mode requirements** - Customer-facing features need Production mode
+5. **Guide next steps** - Help user understand what to do after transition
+
+## Example Flow
+
+**User:** "I think we're ready to launch this to real users"
+
+**Claude:** [Explains transition as shown in Step 1]
+
+**User:** "Yes, let's do it"
+
+**Claude:** [Executes command via Bash tool]
+
+**Claude:** [Reports results as shown in Step 4]
+
+**User:** "What should I work on first?"
+
+**Claude:** "I'd suggest starting with the Security Infrastructure items since those are critical for protecting user data. Want me to show you what's in that category?"
+
+## Validation
+
+Before completing external transition, ensure:
+- [ ] User expressed intent to go external/production
+- [ ] Transition implications explained clearly
+- [ ] User provided initial confirmation
+- [ ] Production standards preset shown (4 options)
+- [ ] User selected preset
+- [ ] Refinement questions asked (3-8 questions based on preset)
+- [ ] Standards generated using production-standards-engine.js
+- [ ] Recommendations shown with reasoning and acceptance criteria
+- [ ] User accepted or customized standards
+- [ ] Production standards saved to .jettypod/production-standards.json
+- [ ] Final confirmation obtained
+- [ ] Command executed successfully via Bash tool
+- [ ] Results reported to user
+- [ ] Next steps suggested