oden-forge 2.0.0

package/.claude/rules/datetime.md

@@ -0,0 +1,118 @@
+# DateTime Rule
+
+## Getting Current Date and Time
+
+When any command requires the current date/time (for frontmatter, timestamps, or logs), you MUST obtain the REAL current date/time from the system rather than estimating or using placeholder values.
+
+### How to Get Current DateTime
+
+Use the `date` command to get the current ISO 8601 formatted datetime:
+
+```bash
+# Get current datetime in ISO 8601 format (works on Linux/Mac)
+date -u +"%Y-%m-%dT%H:%M:%SZ"
+
+# Alternative for systems that support it
+date --iso-8601=seconds
+
+# For Windows (if using PowerShell)
+Get-Date -Format "yyyy-MM-ddTHH:mm:ssZ"
+```
+
+### Required Format
+
+All dates in frontmatter MUST use ISO 8601 format with UTC timezone:
+- Format: `YYYY-MM-DDTHH:MM:SSZ`
+- Example: `2024-01-15T14:30:45Z`
+
+### Usage in Frontmatter
+
+When creating or updating frontmatter in any file (PRD, Epic, Task, Progress), always use the real current datetime:
+
+```yaml
+---
+name: feature-name
+created: 2024-01-15T14:30:45Z  # Use actual output from date command
+updated: 2024-01-15T14:30:45Z  # Use actual output from date command
+---
+```
+
+### Implementation Instructions
+
+1. **Before writing any file with frontmatter:**
+   - Run: `date -u +"%Y-%m-%dT%H:%M:%SZ"`
+   - Store the output
+   - Use this exact value in the frontmatter
+
+2. **For commands that create files:**
+   - PRD creation: Use real date for `created` field
+   - Epic creation: Use real date for `created` field
+   - Task creation: Use real date for both `created` and `updated` fields
+   - Progress tracking: Use real date for `started` and `last_sync` fields
+
+3. **For commands that update files:**
+   - Always update the `updated` field with current real datetime
+   - Preserve the original `created` field
+   - For sync operations, update `last_sync` with real datetime
+
+### Examples
+
+**Creating a new PRD:**
+```bash
+# First, get current datetime
+CURRENT_DATE=$(date -u +"%Y-%m-%dT%H:%M:%SZ")
+# Output: 2024-01-15T14:30:45Z
+
+# Then use in frontmatter:
+---
+name: user-authentication
+description: User authentication and authorization system
+status: backlog
+created: 2024-01-15T14:30:45Z  # Use the actual $CURRENT_DATE value
+---
+```
+
+**Updating an existing task:**
+```bash
+# Get current datetime for update
+UPDATE_DATE=$(date -u +"%Y-%m-%dT%H:%M:%SZ")
+
+# Update only the 'updated' field:
+---
+name: implement-login-api
+status: in-progress
+created: 2024-01-10T09:15:30Z  # Keep original
+updated: 2024-01-15T14:30:45Z  # Use new $UPDATE_DATE value
+---
+```
+
+### Important Notes
+
+- **Never use placeholder dates** like `[Current ISO date/time]` or `YYYY-MM-DD`
+- **Never estimate dates** - always get the actual system time
+- **Always use UTC** (the `Z` suffix) for consistency across timezones
+- **Preserve timezone consistency** - all dates in the system use UTC
+
+### Cross-Platform Compatibility
+
+If you need to ensure compatibility across different systems:
+
+```bash
+# Try primary method first
+date -u +"%Y-%m-%dT%H:%M:%SZ" 2>/dev/null || \
+# Fallback for systems without -u flag
+date +"%Y-%m-%dT%H:%M:%SZ" 2>/dev/null || \
+# Last resort: use Python if available
+python3 -c "from datetime import datetime; print(datetime.utcnow().strftime('%Y-%m-%dT%H:%M:%SZ'))" 2>/dev/null || \
+python -c "from datetime import datetime; print(datetime.utcnow().strftime('%Y-%m-%dT%H:%M:%SZ'))" 2>/dev/null
+```
+
+## Rule Priority
+
+This rule has **HIGHEST PRIORITY** and must be followed by all commands that:
+- Create new files with frontmatter
+- Update existing files with frontmatter
+- Track timestamps or progress
+- Log any time-based information
+
+Commands affected: prd-new, prd-parse, epic-decompose, epic-sync, issue-start, issue-sync, and any other command that writes timestamps.

package/.claude/rules/frontmatter-operations.md

@@ -0,0 +1,58 @@
+# Frontmatter Operations Rule
+
+Standard patterns for working with YAML frontmatter in markdown files.
+
+## Reading Frontmatter
+
+Extract frontmatter from any markdown file:
+1. Look for content between `---` markers at start of file
+2. Parse as YAML
+3. If invalid or missing, use sensible defaults
+
+## Updating Frontmatter
+
+When updating existing files:
+1. Preserve all existing fields
+2. Only update specified fields
+3. Always update `updated` field with current datetime (see `/rules/datetime.md`)
+
+## Standard Fields
+
+### All Files
+```yaml
+---
+name: {identifier}
+created: {ISO datetime}      # Never change after creation
+updated: {ISO datetime}      # Update on any modification
+---
+```
+
+### Status Values
+- PRDs: `backlog`, `in-progress`, `complete`
+- Epics: `backlog`, `in-progress`, `completed`  
+- Tasks: `open`, `in-progress`, `closed`
+
+### Progress Tracking
+```yaml
+progress: {0-100}%           # For epics
+completion: {0-100}%         # For progress files
+```
+
+## Creating New Files
+
+Always include frontmatter when creating markdown files:
+```yaml
+---
+name: {from_arguments_or_context}
+status: {initial_status}
+created: {current_datetime}
+updated: {current_datetime}
+---
+```
+
+## Important Notes
+
+- Never modify `created` field after initial creation
+- Always use real datetime from system (see `/rules/datetime.md`)
+- Validate frontmatter exists before trying to parse
+- Use consistent field names across all files

package/.claude/rules/github-operations.md

@@ -0,0 +1,89 @@
+# GitHub Operations Rule
+
+Standard patterns for GitHub CLI operations across all commands.
+
+## CRITICAL: Repository Protection
+
+**Before ANY GitHub operation that creates/modifies issues or PRs:**
+
+```bash
+# Check if remote origin is the CCPM template repository
+remote_url=$(git remote get-url origin 2>/dev/null || echo "")
+if [[ "$remote_url" == *"automazeio/ccpm"* ]] || [[ "$remote_url" == *"automazeio/ccpm.git"* ]]; then
+  echo "❌ ERROR: You're trying to sync with the CCPM template repository!"
+  echo ""
+  echo "This repository (automazeio/ccpm) is a template for others to use."
+  echo "You should NOT create issues or PRs here."
+  echo ""
+  echo "To fix this:"
+  echo "1. Fork this repository to your own GitHub account"
+  echo "2. Update your remote origin:"
+  echo "   git remote set-url origin https://github.com/YOUR_USERNAME/YOUR_REPO.git"
+  echo ""
+  echo "Or if this is a new project:"
+  echo "1. Create a new repository on GitHub"
+  echo "2. Update your remote origin:"
+  echo "   git remote set-url origin https://github.com/YOUR_USERNAME/YOUR_REPO.git"
+  echo ""
+  echo "Current remote: $remote_url"
+  exit 1
+fi
+```
+
+This check MUST be performed in ALL commands that:
+- Create issues (`gh issue create`)
+- Edit issues (`gh issue edit`)
+- Comment on issues (`gh issue comment`)
+- Create PRs (`gh pr create`)
+- Any other operation that modifies the GitHub repository
+
+## Authentication
+
+**Don't pre-check authentication.** Just run the command and handle failure:
+
+```bash
+gh {command} || echo "❌ GitHub CLI failed. Run: gh auth login"
+```
+
+## Common Operations
+
+### Get Issue Details
+```bash
+gh issue view {number} --json state,title,labels,body
+```
+
+### Create Issue
+```bash
+# Always specify repo to avoid defaulting to wrong repository
+remote_url=$(git remote get-url origin 2>/dev/null || echo "")
+REPO=$(echo "$remote_url" | sed 's|.*github.com[:/]||' | sed 's|\.git$||')
+[ -z "$REPO" ] && REPO="user/repo"
+gh issue create --repo "$REPO" --title "{title}" --body-file {file} --label "{labels}"
+```
+
+### Update Issue
+```bash
+# ALWAYS check remote origin first!
+gh issue edit {number} --add-label "{label}" --add-assignee @me
+```
+
+### Add Comment
+```bash
+# ALWAYS check remote origin first!
+gh issue comment {number} --body-file {file}
+```
+
+## Error Handling
+
+If any gh command fails:
+1. Show clear error: "❌ GitHub operation failed: {command}"
+2. Suggest fix: "Run: gh auth login" or check issue number
+3. Don't retry automatically
+
+## Important Notes
+
+- **ALWAYS** check remote origin before ANY write operation to GitHub
+- Trust that gh CLI is installed and authenticated
+- Use --json for structured output when parsing
+- Keep operations atomic - one gh command per action
+- Don't check rate limits preemptively

package/.claude/rules/oden-methodology.md

@@ -0,0 +1,111 @@
+# Metodología Oden
+
+## Filosofía: Documentation-First Development
+
+La metodología Oden se basa en documentar y diseñar COMPLETAMENTE antes de escribir código.
+
+### Principios Core
+
+1. **Documentation-First**: Todo se documenta antes de codificar
+2. **Design Sprint Adaptado**: Diseño rápido → Validación → Iteración
+3. **Entrega Incremental**: Valor tangible cada semana
+
+## Fases del Proyecto
+
+### FASE 1: Pre-Desarrollo
+
+**Duración:** 1-2 semanas
+
+1. **Technical Architect** (`/oden:architect`)
+   - technical-decisions.md (2000-4000 líneas)
+   - Schema de BD completo
+   - Interfaces TypeScript
+
+2. **Domain Expert** (`/oden:analyze`)
+   - Análisis de 3-5 competidores
+   - User personas y stories
+   - Priorización de features
+
+3. **Spec Writer** (`/oden:spec`)
+   - Specs de 800-1200 líneas por módulo
+   - Máquinas de estado
+   - Validaciones y edge cases
+
+4. **Implementation Planner** (`/oden:plan`)
+   - Plan semana por semana
+   - Estimaciones con buffers
+   - Milestones y criterios
+
+### FASE 2: Implementación
+
+**Duración:** 8-18 semanas según scope
+
+- Seguir specs al pie de la letra
+- Daily logging (`/oden:daily`)
+- Validación contra specs
+
+### FASE 3: Post-Desarrollo
+
+- Mover docs a completed/
+- Crear guías de usuario
+- Archivar docs obsoletos
+
+## Métricas de Éxito
+
+### Durante Desarrollo
+- 100% módulos definidos antes de codificar
+- 0 dependencias circulares
+- Documentación > 8,000 líneas antes de código
+- Progreso diario documentado
+
+### Post-Lanzamiento
+- Performance: < 100ms latencia crítica
+- Uptime: 99.9%
+- NPS: > 50
+
+## Reglas de Oro
+
+### ✅ SIEMPRE
+1. Documenta TODO antes de codificar
+2. Analiza 3+ competidores
+3. Crea specs de 800+ líneas por módulo
+4. Registra progreso diario
+5. Define máquinas de estado para entidades complejas
+6. Especifica edge cases y manejo de errores
+
+### ❌ NUNCA
+1. No empieces sin specs completas
+2. No documentes cambios triviales
+3. No dupliques información
+4. No dejes temp/ con más de 5 archivos
+
+## Decisión: MVP vs Modo Turbo
+
+### MVP (8-10 semanas)
+- 30-40% de features
+- Rápido al mercado
+- Mayor deuda técnica
+- Para: Startups, validación de ideas
+
+### Modo Turbo (14-20 semanas)
+- 100% features profesionales
+- Enterprise-ready desde día 1
+- Menor deuda técnica
+- Para: Productos establecidos, B2B
+
+## Checklist Pre-Código
+
+Antes de escribir la primera línea:
+
+- [ ] technical-decisions.md > 2000 líneas
+- [ ] Schema de BD completo
+- [ ] Análisis de 3+ competidores
+- [ ] Specs de módulos > 800 líneas c/u
+- [ ] Plan semana por semana
+- [ ] Estructura docs/ creada
+- [ ] Decisión MVP/Turbo documentada
+- [ ] Stack tecnológico justificado
+- [ ] Máquinas de estado definidas
+- [ ] Edge cases documentados
+
+**Solo cuando TODO esté ✅, empezar a codificar.**

package/.claude/rules/path-standards.md

@@ -0,0 +1,155 @@
+# Path Standards Specification
+
+## Overview
+This specification defines file path usage standards within the Claude Code PM system to ensure document portability, privacy protection, and consistency.
+
+## Core Principles
+
+### 1. Privacy Protection
+- **Prohibit** absolute paths containing usernames
+- **Prohibit** exposing local directory structure in public documentation  
+- **Prohibit** including complete local paths in GitHub Issue comments
+
+### 2. Portability Principles
+- **Prefer** relative paths for referencing project files
+- **Ensure** documentation works across different development environments
+- **Avoid** environment-specific path formats
+
+## Path Format Standards
+
+### Project File References ✅
+```markdown
+# Correct Examples
+- `internal/auth/server.go` 
+- `cmd/server/main.go`
+- `.claude/commands/pm/sync.md`
+
+# Incorrect Examples ❌
+- `/Users/username/project/internal/auth/server.go`
+- `C:\Users\username\project\cmd\server\main.go`
+```
+
+### Cross-Project/Worktree References ✅
+```markdown
+# Correct Examples
+- `../project-name/internal/auth/server.go`
+- `../worktree-name/src/components/Button.tsx`
+
+# Incorrect Examples ❌
+- `/Users/username/parent-dir/project-name/internal/auth/server.go`
+- `/home/user/projects/worktree-name/src/components/Button.tsx`
+```
+
+### Code Comment File References ✅
+```go
+// Correct Examples
+// See internal/processor/converter.go for data transformation
+// Configuration loaded from configs/production.yml
+
+// Incorrect Examples ❌  
+// See /Users/username/parent-dir/project-name/internal/processor/converter.go
+```
+
+## Implementation Rules
+
+### Documentation Generation Rules
+1. **Issue sync templates**: Use relative path template variables
+2. **Progress reports**: Automatically convert absolute paths to relative paths
+3. **Technical documentation**: Use project root relative paths consistently
+
+### Path Variable Standards
+```yaml
+# Template variable definitions
+project_root: "."              # Current project root directory
+worktree_path: "../{name}"     # Worktree relative path  
+internal_path: "internal/"     # Internal modules directory
+config_path: "configs/"        # Configuration files directory
+```
+
+### Automatic Cleanup Rules
+```bash
+# Path normalization function
+normalize_paths() {
+  local content="$1"
+  # Remove user-specific paths (generic patterns)
+  content=$(echo "$content" | sed "s|/Users/[^/]*/[^/]*/|../|g")
+  content=$(echo "$content" | sed "s|/home/[^/]*/[^/]*/|../|g")  
+  content=$(echo "$content" | sed "s|C:\\\\Users\\\\[^\\\\]*\\\\[^\\\\]*\\\\|..\\\\|g")
+  echo "$content"
+}
+```
+
+## PM Command Integration
+
+### issue-sync Command Updates
+- Automatically clean path formats before sync
+- Use relative path templates for generating comments
+- Record deliverables using standardized paths
+
+### epic-sync Command Updates
+- Standardize task file paths
+- Clean GitHub issue body paths
+- Use relative paths in mapping files
+
+## Validation Checks
+
+### Automated Check Script
+```bash
+# Check for absolute path violations
+check_absolute_paths() {
+  echo "Checking for absolute path violations..."
+  rg -n "/Users/|/home/|C:\\\\\\\\" .claude/ || echo "✅ No absolute paths found"
+}
+
+# Check GitHub sync content
+check_sync_content() {
+  echo "Checking sync content path formats..."
+  # Implement specific check logic
+}
+```
+
+### Manual Review Checklist
+- [ ] GitHub Issue comments contain no absolute paths
+- [ ] Local documentation uses relative paths consistently
+- [ ] Code comment paths follow standards
+- [ ] Configuration file paths are standardized
+
+## Error Handling
+
+### When Absolute Paths Are Found
+1. **Immediate Action**: Clean published public content
+2. **Batch Fix**: Update local documentation formats
+3. **Prevention**: Update generation templates
+
+### Emergency Procedures
+If privacy information has been leaked:
+1. Immediately edit GitHub Issues/comments
+2. Clean Git history if necessary
+3. Update related documentation and templates
+4. Establish monitoring to prevent recurrence
+
+## Example Comparisons
+
+### Documentation Before/After
+```markdown
+# Before ❌
+- ✅ Implemented `/Users/username/parent-dir/project-name/internal/auth/server.go` core logic
+
+# After ✅  
+- ✅ Implemented `../project-name/internal/auth/server.go` core logic
+```
+
+### GitHub Comment Format
+```markdown
+# Correct Format ✅
+## 📦 Deliverables
+- `internal/formatter/batch.go` - Batch formatter
+- `internal/processor/sorter.go` - Sorting algorithm  
+- `cmd/server/main.go` - Server entry point
+
+# Incorrect Format ❌
+## 📦 Deliverables  
+- `/Users/username/parent-dir/project-name/internal/formatter/batch.go`
+```
+
+This specification ensures project documentation maintains professionalism, portability, and privacy security.

package/.claude/rules/standard-patterns.md

@@ -0,0 +1,174 @@
+# Standard Patterns for Commands
+
+This file defines common patterns that all commands should follow to maintain consistency and simplicity.
+
+## Core Principles
+
+1. **Fail Fast** - Check critical prerequisites, then proceed
+2. **Trust the System** - Don't over-validate things that rarely fail
+3. **Clear Errors** - When something fails, say exactly what and how to fix it
+4. **Minimal Output** - Show what matters, skip decoration
+
+## Standard Validations
+
+### Minimal Preflight
+Only check what's absolutely necessary:
+```markdown
+## Quick Check
+1. If command needs specific directory/file:
+   - Check it exists: `test -f {file} || echo "❌ {file} not found"`
+   - If missing, tell user exact command to fix it
+2. If command needs GitHub:
+   - Assume `gh` is authenticated (it usually is)
+   - Only check on actual failure
+```
+
+### DateTime Handling
+```markdown
+Get current datetime: `date -u +"%Y-%m-%dT%H:%M:%SZ"`
+```
+Don't repeat full instructions - just reference `/rules/datetime.md` once.
+
+### Error Messages
+Keep them short and actionable:
+```markdown
+❌ {What failed}: {Exact solution}
+Example: "❌ Epic not found: Run /pm:prd-parse feature-name"
+```
+
+## Standard Output Formats
+
+### Success Output
+```markdown
+✅ {Action} complete
+  - {Key result 1}
+  - {Key result 2}
+Next: {Single suggested action}
+```
+
+### List Output
+```markdown
+{Count} {items} found:
+- {item 1}: {key detail}
+- {item 2}: {key detail}
+```
+
+### Progress Output
+```markdown
+{Action}... {current}/{total}
+```
+
+## File Operations
+
+### Check and Create
+```markdown
+# Don't ask permission, just create what's needed
+mkdir -p .claude/{directory} 2>/dev/null
+```
+
+### Read with Fallback
+```markdown
+# Try to read, continue if missing
+if [ -f {file} ]; then
+  # Read and use file
+else
+  # Use sensible default
+fi
+```
+
+## GitHub Operations
+
+### Trust gh CLI
+```markdown
+# Don't pre-check auth, just try the operation
+gh {command} || echo "❌ GitHub CLI failed. Run: gh auth login"
+```
+
+### Simple Issue Operations
+```markdown
+# Get what you need in one call
+gh issue view {number} --json state,title,body
+```
+
+## Common Patterns to Avoid
+
+### DON'T: Over-validate
+```markdown
+# Bad - too many checks
+1. Check directory exists
+2. Check permissions
+3. Check git status
+4. Check GitHub auth
+5. Check rate limits
+6. Validate every field
+```
+
+### DO: Check essentials
+```markdown
+# Good - just what's needed
+1. Check target exists
+2. Try the operation
+3. Handle failure clearly
+```
+
+### DON'T: Verbose output
+```markdown
+# Bad - too much information
+🎯 Starting operation...
+📋 Validating prerequisites...
+✅ Step 1 complete
+✅ Step 2 complete
+📊 Statistics: ...
+💡 Tips: ...
+```
+
+### DO: Concise output
+```markdown
+# Good - just results
+✅ Done: 3 files created
+Failed: auth.test.js (syntax error - line 42)
+```
+
+### DON'T: Ask too many questions
+```markdown
+# Bad - too interactive
+"Continue? (yes/no)"
+"Overwrite? (yes/no)"
+"Are you sure? (yes/no)"
+```
+
+### DO: Smart defaults
+```markdown
+# Good - proceed with sensible defaults
+# Only ask when destructive or ambiguous
+"This will delete 10 files. Continue? (yes/no)"
+```
+
+## Quick Reference
+
+### Essential Tools Only
+- Read/List operations: `Read, LS`
+- File creation: `Read, Write, LS`
+- GitHub operations: Add `Bash`
+- Complex analysis: Add `Task` (sparingly)
+
+### Status Indicators
+- ✅ Success (use sparingly)
+- ❌ Error (always with solution)
+- ⚠️ Warning (only if action needed)
+- No emoji for normal output
+
+### Exit Strategies
+- Success: Brief confirmation
+- Failure: Clear error + exact fix
+- Partial: Show what worked, what didn't
+
+## Remember
+
+**Simple is not simplistic** - We still handle errors properly, we just don't try to prevent every possible edge case. We trust that:
+- The file system usually works
+- GitHub CLI is usually authenticated  
+- Git repositories are usually valid
+- Users know what they're doing
+
+Focus on the happy path, fail gracefully when things go wrong.