trinity-method-sdk 2.0.0

package/dist/templates/shared/claude-commands/trinity-init.md.template

@@ -0,0 +1,606 @@
+---
+description: Complete Trinity integration with TAN → ZEN → INO → EIN → JUNO workflow
+---
+# Quick Start - TL;DR
+
+**Install Trinity in 3 steps**:
+
+1. **Run Init**: `/trinity-init`
+2. **Wait**: ~30 seconds (deploys 19 agents + knowledge base)
+3. **Verify**: `/trinity-verify` (confirm 100% deployment)
+
+**What You Get**:
+- 19 specialized agents in `.claude/agents/`
+- 20 slash commands in `.claude/commands/` (6 categories)
+- Knowledge base in `trinity/knowledge-base/`
+- Work order system in `trinity/work-orders/`
+- Documentation templates in `trinity/templates/documentation/`
+
+**Next Steps**: Run `/trinity-start` to begin your first workflow
+
+---
+
+# Trinity Initialization
+
+**Purpose:** Complete Trinity Method integration with comprehensive setup and quality validation.
+
+## Overview
+
+Trinity initialization populates the Trinity Method infrastructure with:
+- 📁 **Structure Verification:** TAN validates Trinity directory structure
+- 📚 **Knowledge Base Population:** ZEN creates comprehensive documentation
+- 🧠 **Context Hierarchy:** INO establishes CLAUDE.md and ISSUES.md databases
+- ⚙️ **CI/CD Review:** EIN reviews and customizes deployed CI/CD workflows (if present)
+- ✅ **Quality Audit:** JUNO performs comprehensive compliance audit
+
+**Context:** User has run `trinity deploy` and basic Trinity structure exists. Deployment team will now populate and verify all Trinity documents.
+
+**IMPORTANT:** All folders and basic files already exist from deployment. DO NOT attempt to create folders that already exist (trinity/, .claude/, etc.). Focus on POPULATING and VERIFYING content.
+
+## Trinity Method Capabilities
+
+### Investigation Templates
+5 comprehensive templates for guided investigations:
+- **Bug** - Reproduction, debugging, Five Whys, testing
+- **Performance** - Profiling, optimization, benchmarks
+- **Security** - CVSS scoring, PoC, remediation
+- **Technical** - Architecture decisions, ADRs
+- **Feature** - User stories, acceptance criteria, epic breakdown
+
+**Explore:** `/trinity-investigate-templates`
+
+**Benefits:**
+- Consistent investigation quality
+- Comprehensive documentation
+- Knowledge preservation
+- Integration with orchestration
+
+## Intelligent CLAUDE.md Placement
+
+Trinity requires CLAUDE.md files for context, but intelligently adapts to your repository structure rather than forcing a rigid setup.
+
+### Standard 3-File Setup
+
+Trinity creates 3 CLAUDE.md files minimum:
+
+1. **Root CLAUDE.md** (required) - Project-level context and overview
+2. **Tests CLAUDE.md** (required) - Testing standards, patterns, and conventions
+3. **Source CLAUDE.md** (adaptive) - Source code context and architecture
+
+### Adaptive Source Placement
+
+Trinity automatically detects your source directory and places CLAUDE.md appropriately:
+
+**Common Source Directory Patterns:**
+- `src/` - Most common (Node.js, TypeScript, React, Vue, Angular)
+- `lib/` - Library projects (npm packages, Ruby gems)
+- `app/` - Rails, Laravel, Django, some web frameworks
+- `source/` - Some documentation projects, Sphinx docs
+- `code/` - Legacy projects or specific naming conventions
+- Root level - Small projects without dedicated source folder
+
+**Detection Logic:**
+1. Check for `src/` directory → Place CLAUDE.md in `src/`
+2. If not found, check for `lib/` → Place CLAUDE.md in `lib/`
+3. If not found, check for `app/` → Place CLAUDE.md in `app/`
+4. If none found → Place `SOURCE.CLAUDE.md` in root directory
+
+### Multi-Directory Repositories
+
+For complex repositories with multiple distinct source directories, Trinity detects and creates additional CLAUDE.md files automatically:
+
+#### Pattern 1: Frontend + Backend
+
+**Detection Triggers:**
+- Directories named: `frontend/`, `backend/`, `client/`, `server/`
+- Multiple `package.json` files in separate directories
+- Framework markers: React/Vue/Angular + Express/NestJS/Fastify
+
+**Result:**
+```
+project/
+├── CLAUDE.md                    # Root context (project overview)
+├── frontend/
+│   ├── CLAUDE.md                # Frontend-specific context
+│   └── src/...
+├── backend/
+│   ├── CLAUDE.md                # Backend-specific context
+│   └── src/...
+└── tests/
+    └── CLAUDE.md                # Testing context
+```
+
+**Frontend CLAUDE.md should include:**
+- UI component architecture (component tree, state flow)
+- State management patterns (Redux, Zustand, Context API)
+- Routing structure and navigation
+- API integration approach and data fetching
+- Styling conventions (CSS-in-JS, Tailwind, modules)
+
+**Backend CLAUDE.md should include:**
+- API design and endpoint structure
+- Database schema and migrations approach
+- Authentication/authorization patterns
+- Business logic organization
+- External service integrations
+
+#### Pattern 2: Monorepo
+
+**Detection Triggers:**
+- Presence of `packages/`, `apps/`, or `services/` directory
+- Multiple `package.json` files across subdirectories
+- Monorepo tool markers: `lerna.json`, `nx.json`, `turbo.json`, `pnpm-workspace.yaml`
+
+**Result:**
+```
+monorepo/
+├── CLAUDE.md                    # Monorepo root context
+├── packages/
+│   ├── api/
+│   │   ├── CLAUDE.md            # API package context
+│   │   └── src/...
+│   ├── web/
+│   │   ├── CLAUDE.md            # Web app context
+│   │   └── src/...
+│   └── mobile/
+│       ├── CLAUDE.md            # Mobile app context
+│       └── src/...
+└── tests/
+    └── CLAUDE.md                # Shared tests context
+```
+
+**Each package CLAUDE.md should include:**
+- Package purpose and responsibilities
+- Internal dependencies (other packages)
+- External dependencies (npm packages)
+- Package-specific conventions
+- Build and test scripts
+
+#### Pattern 3: Microservices Architecture
+
+**Detection Triggers:**
+- Multiple service directories with independent codebases
+- `docker-compose.yml` file with multiple services
+- Kubernetes manifests with multiple deployments
+- Service directories: `*-service/`, `services/*/`
+
+**Result:**
+```
+services/
+├── CLAUDE.md                    # Services root context
+├── auth-service/
+│   ├── CLAUDE.md                # Auth microservice context
+│   └── src/...
+├── payment-service/
+│   ├── CLAUDE.md                # Payment microservice context
+│   └── src/...
+└── user-service/
+    ├── CLAUDE.md                # User microservice context
+    └── src/...
+```
+
+**Each service CLAUDE.md should include:**
+- Service boundaries and responsibilities
+- Inter-service communication (gRPC, REST, message queue)
+- Service-specific data stores
+- Deployment configuration
+- Health checks and monitoring
+
+#### Pattern 4: Mobile + Web Application
+
+**Detection Triggers:**
+- `ios/`, `android/` directories
+- React Native, Flutter, or native mobile project markers
+- Paired with web application directory
+
+**Result:**
+```
+app/
+├── CLAUDE.md                    # Application root
+├── web/
+│   ├── CLAUDE.md                # Web app context
+│   └── src/...
+├── ios/
+│   ├── CLAUDE.md                # iOS-specific context
+│   └── ...
+└── android/
+    ├── CLAUDE.md                # Android-specific context
+    └── ...
+```
+
+**Platform CLAUDE.md files should include:**
+- Platform-specific conventions
+- Native module integration
+- Platform navigation patterns
+- Build and deployment processes
+
+#### Pattern 5: Documentation Projects
+
+**Detection Triggers:**
+- `docs/`, `documentation/`, `sphinx/` directories
+- Documentation framework files: `conf.py`, `mkdocs.yml`, `_config.yml`
+
+**Result:**
+```
+project/
+├── CLAUDE.md                    # Project root
+├── docs/
+│   ├── CLAUDE.md                # Documentation context
+│   └── ...
+└── src/
+    ├── CLAUDE.md                # Source context
+    └── ...
+```
+
+### Detection Rules Summary
+
+Trinity creates additional CLAUDE.md files when it detects:
+
+**1. Frontend + Backend Split:**
+- **Triggers:** `frontend/`, `backend/`, `client/`, `server/` directories
+- **Files:** Multiple `package.json` in subdirectories
+- **Frameworks:** React/Vue/Angular + Express/NestJS markers
+- **Result:** 2 additional CLAUDE.md files (frontend + backend)
+
+**2. Monorepo Structure:**
+- **Triggers:** `packages/`, `apps/`, `services/` directories
+- **Files:** Multiple `package.json` files
+- **Config:** `lerna.json`, `nx.json`, `turbo.json`, `pnpm-workspace.yaml`
+- **Result:** 1 CLAUDE.md per package/app
+
+**3. Microservices Architecture:**
+- **Triggers:** Multiple `*-service/` or `services/*/` directories
+- **Files:** `docker-compose.yml` with multiple services
+- **Config:** Kubernetes manifests for multiple deployments
+- **Result:** 1 CLAUDE.md per service
+
+**4. Mobile + Web Application:**
+- **Triggers:** `ios/`, `android/` directories + web directory
+- **Files:** `package.json`, `build.gradle`, `Podfile`
+- **Frameworks:** React Native, Flutter markers
+- **Result:** 1 CLAUDE.md per platform (3 total: web, ios, android)
+
+**5. Documentation Projects:**
+- **Triggers:** `docs/`, `documentation/`, `sphinx/` directories
+- **Files:** `conf.py`, `mkdocs.yml`, `_config.yml`
+- **Result:** 1 CLAUDE.md in docs directory
+
+### Configuration Override
+
+You can manually specify CLAUDE.md locations in `trinity/config.json`:
+
+```json
+{
+  "claudeFiles": {
+    "auto": true,
+    "locations": [
+      "CLAUDE.md",
+      "src/CLAUDE.md",
+      "tests/CLAUDE.md",
+      "frontend/CLAUDE.md",
+      "backend/CLAUDE.md",
+      "docs/CLAUDE.md"
+    ],
+    "detection": {
+      "enableFrontendBackend": true,
+      "enableMonorepo": true,
+      "enableMicroservices": true,
+      "enableMobile": true,
+      "customPatterns": [
+        "custom-dir/CLAUDE.md"
+      ]
+    }
+  }
+}
+```
+
+**Configuration Options:**
+- `auto`: Enable/disable automatic detection (default: `true`)
+- `locations`: Explicit CLAUDE.md locations (overrides detection when `auto: false`)
+- `detection.enable*`: Toggle specific detection patterns
+- `customPatterns`: Additional directories to include
+
+**When to use manual configuration:**
+- Non-standard repository structure
+- Custom directory naming that doesn't match patterns
+- Specific CLAUDE.md placement requirements
+- Disabling automatic detection for control
+
+### Verification
+
+After `trinity init`, verify CLAUDE.md placement:
+
+```bash
+trinity verify
+```
+
+**Verification shows:**
+- **Detected Structure:** Repository type (standard, frontend+backend, monorepo, etc.)
+- **CLAUDE.md Locations:** All detected CLAUDE.md files
+- **Coverage Analysis:** Percentage of codebase covered by nearest CLAUDE.md
+- **Suggestions:** Recommendations for additional CLAUDE.md files
+- **Validation:** Confirms all required CLAUDE.md files present
+
+**Example output:**
+```
+✅ Trinity Verification Report
+
+Repository Structure: Frontend + Backend
+CLAUDE.md Files: 4 detected
+  ✓ CLAUDE.md (root)
+  ✓ frontend/CLAUDE.md
+  ✓ backend/CLAUDE.md
+  ✓ tests/CLAUDE.md
+
+Coverage Analysis:
+  Frontend: 98% (242/247 files within 2 directory levels)
+  Backend: 100% (189/189 files within 2 directory levels)
+  Tests: 100% (67/67 files within 2 directory levels)
+  Overall: 99% (498/503 files)
+
+Suggestions:
+  • Consider adding CLAUDE.md to docs/ directory (15 files, 2% uncovered)
+
+✨ Verification complete!
+```
+
+### Why Adaptive Placement Matters
+
+**Context Density:**
+- **Without adaptive placement:** Single massive root CLAUDE.md (1000+ lines, hard to maintain)
+- **With adaptive placement:** Distributed context across directories (100-200 lines each, focused and relevant)
+- **Agent efficiency:** Agents read nearest CLAUDE.md first for focused context
+
+**Maintainability:**
+- Team members update only relevant CLAUDE.md files
+- Reduces context drift and outdated information
+- Clear ownership per directory/subsystem
+
+**Scalability:**
+- Monorepos can have 50+ packages
+- One CLAUDE.md per package = manageable
+- Single root CLAUDE.md = unmaintainable at scale
+
+**Example:** Frontend changes don't need backend context. Adaptive placement ensures agents get only relevant context.
+
+## Initialization Process
+
+### Phase 1: TAN (Structure Specialist) - Verify Trinity structure
+- Check that all folders exist (they should from deploy)
+- Verify folder permissions
+- Report any structural issues (don't create folders - they already exist)
+
+### Phase 2: ZEN (Knowledge Base Specialist) - Populate Trinity documentation
+- Analyze existing codebase
+- POPULATE trinity/knowledge-base/ARCHITECTURE.md with detailed architecture analysis
+- POPULATE trinity/knowledge-base/ISSUES.md with discovered issues
+- POPULATE trinity/knowledge-base/To-do.md with identified tasks
+- POPULATE trinity/knowledge-base/Technical-Debt.md with technical debt assessment
+- Update existing Trinity.md if needed
+
+### Phase 3: INO (Context Specialist) - Establish context hierarchy
+- Analyze codebase context and complexity
+- UPDATE existing CLAUDE.md files with project-specific instructions
+- POPULATE trinity/knowledge-base/ISSUES.md database structure
+- Verify CLAUDE.md hierarchy is complete
+
+### Phase 4: JUNO (Quality Auditor) - Perform comprehensive audit
+- Verify all folders exist and are writable
+- Verify all documentation files are populated (not empty)
+- Validate CLAUDE.md hierarchy completeness
+- Check that knowledge base documents have real content
+- Generate audit report in trinity/reports/
+- Report findings to user with compliance score
+
+### Phase 5: EIN (CI/CD Specialist) - Review CI/CD and Pre-commit Configuration
+
+**MANDATORY STEP:** Check for CI/CD files and invoke EIN if present.
+
+**File Detection (Use Bash tool to check):**
+
+1. **Check for GitHub Actions workflows:**
+   ```bash
+   ls .github/workflows/ci.yml 2>/dev/null && echo "CI FOUND" || echo "CI NOT_FOUND"
+   ls .github/workflows/cd.yml 2>/dev/null && echo "CD FOUND" || echo "CD NOT_FOUND"
+   ```
+
+2. **Check for pre-commit configuration:**
+   ```bash
+   ls .pre-commit-config.yaml 2>/dev/null && echo "FOUND" || echo "NOT_FOUND"
+   ```
+
+**Decision Tree:**
+
+- **IF any CI/CD files exist (ci.yml, cd.yml, OR pre-commit config):**
+  - ✅ **Invoke EIN** - Adopt EIN (CI/CD Specialist) persona
+  - Continue with "EIN's Responsibilities" below
+  - Include EIN's work in JUNO's audit report
+
+- **IF no CI/CD files exist:**
+  - ⏭️ **Skip EIN phase** - No CI/CD templates to review
+  - Add to JUNO report: "EIN Phase: Skipped (no CI/CD templates deployed)"
+  - Inform user they can set up CI/CD later with `/trinity-cicd`
+  - Continue to "Post-Init Next Steps"
+
+**EIN's Responsibilities (Review & Customize Deployed Templates):**
+
+**IMPORTANT:** Templates were already deployed by `trinity deploy`. EIN's job is to:
+1. **Review** the deployed files
+2. **Customize** them for the detected framework/runtime
+3. **Validate** configuration is correct
+4. **Provide** activation instructions
+
+**1. GitHub Actions CI Workflow** (if `.github/workflows/ci.yml` exists):
+   - **Read** the deployed ci.yml file
+   - **Verify** all 6 BAS quality gate phases are present:
+     - Phase 1: Linting with auto-fix
+     - Phase 2: Structure validation
+     - Phase 3: Build validation
+     - Phase 4: Testing (all tests pass)
+     - Phase 5: Coverage check (≥80%)
+     - Phase 6: Best practices validation
+   - **Customize** for detected runtime (Node.js, Flutter, Python, etc.)
+   - **Validate** triggers are correct (push to main/dev, pull requests)
+   - **Confirm** coverage threshold enforcement is configured
+
+**2. GitHub Actions CD Workflow** (if `.github/workflows/cd.yml` exists):
+   - **Read** the deployed cd.yml file
+   - **Verify** deployment stages (CI gate → build → staging → production)
+   - **Validate** CI workflow is called as prerequisite
+   - **Customize** deployment commands for project type
+   - **Confirm** environment protection is documented
+   - **Validate** artifact management (upload/download between jobs)
+
+**3. Pre-commit Hooks** (if `.pre-commit-config.yaml` exists):
+   - **Read** the deployed .pre-commit-config.yaml file
+   - **Verify** all hooks are configured:
+     - Standard hooks (trailing whitespace, YAML/JSON validation, etc.)
+     - ESLint with auto-fix
+     - TypeScript type checking (if applicable)
+     - Jest for changed files
+   - **Customize** for project framework (remove TypeScript hooks if not TypeScript project)
+   - **Provide** installation instructions
+
+**EIN Output Format:**
+
+After reviewing and customizing CI/CD files, EIN should report:
+
+```
+### Phase 5: EIN (CI/CD Specialist) - CI/CD Configuration ✅
+
+**Files Reviewed & Customized:**
+- .github/workflows/ci.yml ✅
+  - Status: Ready (customized for {{FRAMEWORK}})
+  - BAS 6-phase quality gates configured
+  - Runtime: {{DETECTED_RUNTIME}}
+  - Coverage: ≥80% enforced
+
+- .github/workflows/cd.yml ✅
+  - Status: Ready (deployment commands customized)
+  - Staging: Auto-deploy on main branch
+  - Production: Deploy via version tags (v*)
+  - Environments: Require setup (see instructions below)
+
+- .pre-commit-config.yaml ✅ (if deployed)
+  - Status: Ready (customized for {{FRAMEWORK}})
+  - Hooks: Linting, type checking, tests
+  - Activation: Requires local install (see instructions below)
+
+**Customizations Applied:**
+- ✅ Detected framework: {{FRAMEWORK}}
+- ✅ Configured runtime: {{DETECTED_RUNTIME}}
+- ✅ Adjusted build commands for framework
+- ✅ Configured test commands
+- ✅ Set coverage threshold to 80%
+
+**Activation Instructions:**
+
+📋 **Step 1: Activate GitHub Actions Workflows**
+```bash
+# Workflows are already in place, just commit and push
+git add .github/workflows/ci.yml .github/workflows/cd.yml
+git commit -m "Activate Trinity CI/CD pipelines"
+git push
+```
+
+📋 **Step 2: Set Up GitHub Environments** (Required for CD)
+1. Go to: Repository Settings → Environments
+2. Create "staging" environment:
+   - No protection rules needed
+3. Create "production" environment:
+   - ✅ Enable "Required reviewers" (add team members)
+   - ⏱️ Optional: "Wait timer" (e.g., 5 minutes before deploy)
+
+📋 **Step 3: Activate Pre-commit Hooks** (Optional but Recommended)
+```bash
+# Install pre-commit framework
+pip install pre-commit
+
+# Activate hooks in repository
+pre-commit install
+
+# Test hooks (optional)
+pre-commit run --all-files
+```
+
+📋 **Step 4: Monitor First Run**
+- CI will run automatically on next push
+- Check: https://github.com/{{USER}}/{{REPO}}/actions
+- All 6 BAS phases should pass
+
+💡 **What happens now:**
+- Every commit/PR runs through CI quality gates
+- Push to main → Auto-deploy to staging
+- Create version tag (v2.0.0) → Deploy to production (with approval)
+- Pre-commit hooks validate locally before push
+
+**Ready to activate!** Follow the steps above to enable Trinity quality automation.
+```
+
+**Include in JUNO Report:**
+- Add "EIN Phase: Complete" to audit summary
+- Document which CI/CD files were reviewed
+- Include activation instructions
+
+**Outcome:** Trinity Method fully integrated, audited, and CI/CD templates reviewed (if deployed).
+
+**Note:** This command should be run once after initial deployment. The deployment created the structure; this command populates it with project-specific content.
+
+## Post-Init Next Steps
+
+After Trinity initialization, explore Trinity Method workflows:
+
+### 1. Plan Your First Workflow
+```
+/trinity-orchestrate
+```
+
+Plan your implementation approach. Claude will guide you through workflow selection based on task scale.
+
+### 2. Explore Investigation Templates
+```
+/trinity-investigate-templates
+```
+
+Learn about 5 investigation template types. Choose the right template for your first investigation.
+
+### 3. Verify Installation
+```
+/trinity-verify
+```
+
+Confirm Trinity structure completeness. Ensure all agents and directories are properly deployed.
+
+### 4. Create Your First Investigation
+```
+/trinity-create-investigation
+```
+
+Use investigation wizard to create structured investigation from template.
+
+### 5. Start Development
+Use Trinity workflow commands based on task scale:
+- Small tasks: `/trinity-start` for direct implementation
+- Medium tasks: `/trinity-requirements` → `/trinity-design` → `/trinity-plan`
+- Large tasks: Full workflow with `/trinity-orchestrate` guidance
+
+## Related Commands
+
+- `/trinity-orchestrate` - Workflow orchestration guide
+- `/trinity-investigate-templates` - Investigation template guide
+- `/trinity-verify` - Verification command documentation
+- `/trinity-start` - Start your first Trinity workflow
+- `/trinity-requirements` - Requirements analysis (MON)
+- `/trinity-design` - Technical design (ROR)
+- `/trinity-plan` - Implementation planning (TRA)
+
+## What's Next?
+
+Trinity is now fully integrated. Your next steps:
+
+1. **Verify Setup:** Use `/trinity-verify` to confirm structure completeness
+2. **First Investigation:** Create investigation with `/trinity-create-investigation`
+3. **First Workflow:** Use `/trinity-orchestrate` to plan your implementation approach
+4. **Start Building:** Choose workflow based on task scale (Small/Medium/Large)
+
+Trinity Method will help you maintain high quality standards throughout your development process.