mindforge-cc 2.1.0 → 2.1.2

package/docs/Templates/Agents/CLAUDE-MD.md

@@ -0,0 +1,122 @@
+# GEMINI.md Template
+
+Template for project-root `GEMINI.md` — auto-generated by `mindforge-tools generate-claude-md`.
+
+Contains 6 marker-bounded sections. Each section is independently updatable.
+The `generate-claude-md` subcommand manages 5 sections (project, stack, conventions, architecture, workflow enforcement).
+The profile section is managed exclusively by `generate-claude-profile`.
+
+---
+
+## Section Templates
+
+### Project Section
+```
+<!-- MindForge:project-start source:PROJECT.md -->
+## Project
+
+{{project_content}}
+<!-- MindForge:project-end -->
+```
+
+**Fallback text:**
+```
+Project not yet initialized. Run /mindforge-new-project to set up.
+```
+
+### Stack Section
+```
+<!-- MindForge:stack-start source:STACK.md -->
+## Technology Stack
+
+{{stack_content}}
+<!-- MindForge:stack-end -->
+```
+
+**Fallback text:**
+```
+Technology stack not yet documented. Will populate after codebase mapping or first phase.
+```
+
+### Conventions Section
+```
+<!-- MindForge:conventions-start source:CONVENTIONS.md -->
+## Conventions
+
+{{conventions_content}}
+<!-- MindForge:conventions-end -->
+```
+
+**Fallback text:**
+```
+Conventions not yet established. Will populate as patterns emerge during development.
+```
+
+### Architecture Section
+```
+<!-- MindForge:architecture-start source:ARCHITECTURE.md -->
+## Architecture
+
+{{architecture_content}}
+<!-- MindForge:architecture-end -->
+```
+
+**Fallback text:**
+```
+Architecture not yet mapped. Follow existing patterns found in the codebase.
+```
+
+### Workflow Enforcement Section
+```
+<!-- MindForge:workflow-start source:MindForge defaults -->
+## MindForge Workflow Enforcement
+
+Before using Edit, Write, or other file-changing tools, start work through a MindForge command so planning artifacts and execution context stay in sync.
+
+Use these entry points:
+- `/mindforge-quick` for small fixes, doc updates, and ad-hoc tasks
+- `/mindforge-debug` for investigation and bug fixing
+- `/mindforge-execute-phase` for planned phase work
+
+Do not make direct repo edits outside a MindForge workflow unless the user explicitly asks to bypass it.
+<!-- MindForge:workflow-end -->
+```
+
+### Profile Section (Placeholder Only)
+```
+<!-- MindForge:profile-start -->
+## Developer Profile
+
+> Profile not yet configured. Run `/mindforge-profile-user` to generate your developer profile.
+> This section is managed by `generate-claude-profile` — do not edit manually.
+<!-- MindForge:profile-end -->
+```
+
+**Note:** This section is NOT managed by `generate-claude-md`. It is managed exclusively
+by `generate-claude-profile`. The placeholder above is only used when creating a new
+GEMINI.md file and no profile section exists yet.
+
+---
+
+## Section Ordering
+
+1. **Project** — Identity and purpose (what this project is)
+2. **Stack** — Technology choices (what tools are used)
+3. **Conventions** — Code patterns and rules (how code is written)
+4. **Architecture** — System structure (how components fit together)
+5. **Workflow Enforcement** — Default MindForge entry points for file-changing work
+6. **Profile** — Developer behavioral preferences (how to interact)
+
+## Marker Format
+
+- Start: `<!-- MindForge:{name}-start source:{file} -->`
+- End: `<!-- MindForge:{name}-end -->`
+- Source attribute enables targeted updates when source files change
+- Partial match on start marker (without closing `-->`) for detection
+
+## Fallback Behavior
+
+When a source file is missing, fallback text provides Claude-actionable guidance:
+- Guides the agent's behavior in the absence of data
+- Not placeholder ads or "missing" notices
+- Each fallback tells the agent what to do, not just what's absent

package/docs/Templates/Agents/COPILOT-INSTRUCTIONS.md

@@ -0,0 +1,7 @@
+# Instructions for MindForge
+
+- Use the mindforge skill when the user asks for MindForge or uses a `mindforge-*` command.
+- Treat `/mindforge-...` or `mindforge-...` as command invocations and load the matching file from `.github/skills/mindforge-*`.
+- When a command says to spawn a subagent, prefer a matching custom agent from `.github/agents`.
+- Do not apply MindForge workflows unless the user explicitly asks for them.
+- After completing any `mindforge-*` command (or any deliverable it triggers: feature, bug fix, tests, docs, etc.), ALWAYS: (1) offer the user the next step by prompting via `ask_user`; repeat this feedback loop until the user explicitly indicates they are done.

package/docs/Templates/Agents/DEBUGGER-PROMPT.md

@@ -0,0 +1,91 @@
+# Debug Subagent Prompt Template
+
+Template for spawning mindforge-debugger agent. The agent contains all debugging expertise - this template provides problem context only.
+
+---
+
+## Template
+
+```markdown
+<objective>
+Investigate issue: {issue_id}
+
+**Summary:** {issue_summary}
+</objective>
+
+<symptoms>
+expected: {expected}
+actual: {actual}
+errors: {errors}
+reproduction: {reproduction}
+timeline: {timeline}
+</symptoms>
+
+<mode>
+symptoms_prefilled: {true_or_false}
+goal: {find_root_cause_only | find_and_fix}
+</mode>
+
+<debug_file>
+Create: .planning/debug/{slug}.md
+</debug_file>
+```
+
+---
+
+## Placeholders
+
+| Placeholder | Source | Example |
+|-------------|--------|---------|
+| `{issue_id}` | MindForge Principal-assigned | `auth-screen-dark` |
+| `{issue_summary}` | User description | `Auth screen is too dark` |
+| `{expected}` | From symptoms | `See logo clearly` |
+| `{actual}` | From symptoms | `Screen is dark` |
+| `{errors}` | From symptoms | `None in console` |
+| `{reproduction}` | From symptoms | `Open /auth page` |
+| `{timeline}` | From symptoms | `After recent deploy` |
+| `{goal}` | MindForge Principal sets | `find_and_fix` |
+| `{slug}` | Generated | `auth-screen-dark` |
+
+---
+
+## Usage
+
+**From /mindforge-debug:**
+```python
+Task(
+  prompt=filled_template,
+  subagent_type="mindforge-debugger",
+  description="Debug {slug}"
+)
+```
+
+**From diagnose-issues (UAT):**
+```python
+Task(prompt=template, subagent_type="mindforge-debugger", description="Debug UAT-001")
+```
+
+---
+
+## Continuation
+
+For checkpoints, spawn fresh agent with:
+
+```markdown
+<objective>
+Continue debugging {slug}. Evidence is in the debug file.
+</objective>
+
+<prior_state>
+Debug file: @.planning/debug/{slug}.md
+</prior_state>
+
+<checkpoint_response>
+**Type:** {checkpoint_type}
+**Response:** {user_response}
+</checkpoint_response>
+
+<mode>
+goal: {goal}
+</mode>
+```

package/docs/Templates/Agents/PLANNER-PROMPT.md

@@ -0,0 +1,117 @@
+# Planner Subagent Prompt Template
+
+Template for spawning mindforge-planner agent. The agent contains all planning expertise - this template provides planning context only.
+
+---
+
+## Template
+
+```markdown
+<planning_context>
+
+**Phase:** {phase_number}
+**Mode:** {standard | gap_closure}
+
+**Project State:**
+@.planning/STATE.md
+
+**Roadmap:**
+@.planning/ROADMAP.md
+
+**Requirements (if exists):**
+@.planning/REQUIREMENTS.md
+
+**Phase Context (if exists):**
+@.planning/phases/{phase_dir}/{phase_num}-CONTEXT.md
+
+**Research (if exists):**
+@.planning/phases/{phase_dir}/{phase_num}-RESEARCH.md
+
+**Gap Closure (if --gaps mode):**
+@.planning/phases/{phase_dir}/{phase_num}-VERIFICATION.md
+@.planning/phases/{phase_dir}/{phase_num}-UAT.md
+
+</planning_context>
+
+<downstream_consumer>
+Output consumed by /mindforge-execute-phase
+Plans must be executable prompts with:
+- Frontmatter (wave, depends_on, files_modified, autonomous)
+- Tasks in XML format
+- Verification criteria
+- must_haves for goal-backward verification
+</downstream_consumer>
+
+<quality_gate>
+Before returning PLANNING COMPLETE:
+- [ ] PLAN.md files created in phase directory
+- [ ] Each plan has valid frontmatter
+- [ ] Tasks are specific and actionable
+- [ ] Dependencies correctly identified
+- [ ] Waves assigned for parallel execution
+- [ ] must_haves derived from phase goal
+</quality_gate>
+```
+
+---
+
+## Placeholders
+
+| Placeholder | Source | Example |
+|-------------|--------|---------|
+| `{phase_number}` | From roadmap/arguments | `5` or `2.1` |
+| `{phase_dir}` | Phase directory name | `05-user-profiles` |
+| `{phase}` | Phase prefix | `05` |
+| `{standard \| gap_closure}` | Mode flag | `standard` |
+
+---
+
+## Usage
+
+**From /mindforge-plan-phase (standard mode):**
+```python
+Task(
+  prompt=filled_template,
+  subagent_type="mindforge-planner",
+  description="Plan Phase {phase}"
+)
+```
+
+**From /mindforge-plan-phase --gaps (gap closure mode):**
+```python
+Task(
+  prompt=filled_template,  # with mode: gap_closure
+  subagent_type="mindforge-planner",
+  description="Plan gaps for Phase {phase}"
+)
+```
+
+---
+
+## Continuation
+
+For checkpoints, spawn fresh agent with:
+
+```markdown
+<objective>
+Continue planning for Phase {phase_number}: {phase_name}
+</objective>
+
+<prior_state>
+Phase directory: @.planning/phases/{phase_dir}/
+Existing plans: @.planning/phases/{phase_dir}/*-PLAN.md
+</prior_state>
+
+<checkpoint_response>
+**Type:** {checkpoint_type}
+**Response:** {user_response}
+</checkpoint_response>
+
+<mode>
+Continue: {standard | gap_closure}
+</mode>
+```
+
+---
+
+**Note:** Planning methodology, task breakdown, dependency analysis, wave assignment, TDD detection, and goal-backward derivation are baked into the mindforge-planner agent. This template only passes context.

package/docs/Templates/Codebase/architecture.md

@@ -0,0 +1,255 @@
+# Architecture Template
+
+Template for `.mindforge/codebase/ARCHITECTURE.md` - captures conceptual code organization.
+
+**Purpose:** Document how the code is organized at a conceptual level. Complements STRUCTURE.md (which shows physical file locations).
+
+---
+
+## File Template
+
+```markdown
+# Architecture
+
+**Analysis Date:** [YYYY-MM-DD]
+
+## Pattern Overview
+
+**Overall:** [Pattern name: e.g., "Monolithic CLI", "Serverless API", "Full-stack MVC"]
+
+**Key Characteristics:**
+- [Characteristic 1: e.g., "Single executable"]
+- [Characteristic 2: e.g., "Stateless request handling"]
+- [Characteristic 3: e.g., "Event-driven"]
+
+## Layers
+
+[Describe the conceptual layers and their responsibilities]
+
+**[Layer Name]:**
+- Purpose: [What this layer does]
+- Contains: [Types of code: e.g., "route handlers", "business logic"]
+- Depends on: [What it uses: e.g., "data layer only"]
+- Used by: [What uses it: e.g., "API routes"]
+
+**[Layer Name]:**
+- Purpose: [What this layer does]
+- Contains: [Types of code]
+- Depends on: [What it uses]
+- Used by: [What uses it]
+
+## Data Flow
+
+[Describe the typical request/execution lifecycle]
+
+**[Flow Name] (e.g., "HTTP Request", "CLI Command", "Event Processing"):**
+
+1. [Entry point: e.g., "User runs command"]
+2. [Processing step: e.g., "Router matches path"]
+3. [Processing step: e.g., "Controller validates input"]
+4. [Processing step: e.g., "Service executes logic"]
+5. [Output: e.g., "Response returned"]
+
+**State Management:**
+- [How state is handled: e.g., "Stateless - no persistent state", "Database per request", "In-memory cache"]
+
+## Key Abstractions
+
+[Core concepts/patterns used throughout the codebase]
+
+**[Abstraction Name]:**
+- Purpose: [What it represents]
+- Examples: [e.g., "UserService, ProjectService"]
+- Pattern: [e.g., "Singleton", "Factory", "Repository"]
+
+**[Abstraction Name]:**
+- Purpose: [What it represents]
+- Examples: [Concrete examples]
+- Pattern: [Pattern used]
+
+## Entry Points
+
+[Where execution begins]
+
+**[Entry Point]:**
+- Location: [Brief: e.g., "src/index.ts", "API Gateway triggers"]
+- Triggers: [What invokes it: e.g., "CLI invocation", "HTTP request"]
+- Responsibilities: [What it does: e.g., "Parse args, route to command"]
+
+## Error Handling
+
+**Strategy:** [How errors are handled: e.g., "Exception bubbling to top-level handler", "Per-route error middleware"]
+
+**Patterns:**
+- [Pattern: e.g., "try/catch at controller level"]
+- [Pattern: e.g., "Error codes returned to user"]
+
+## Cross-Cutting Concerns
+
+[Aspects that affect multiple layers]
+
+**Logging:**
+- [Approach: e.g., "Winston logger, injected per-request"]
+
+**Validation:**
+- [Approach: e.g., "Zod schemas at API boundary"]
+
+**Authentication:**
+- [Approach: e.g., "JWT middleware on protected routes"]
+
+---
+
+*Architecture analysis: [date]*
+*Update when major patterns change*
+```
+
+<good_examples>
+```markdown
+# Architecture
+
+**Analysis Date:** 2025-01-20
+
+## Pattern Overview
+
+**Overall:** CLI Application with Plugin System
+
+**Key Characteristics:**
+- Single executable with subcommands
+- Plugin-based extensibility
+- File-based state (no database)
+- Synchronous execution model
+
+## Layers
+
+**Command Layer:**
+- Purpose: Parse user input and route to appropriate handler
+- Contains: Command definitions, argument parsing, help text
+- Location: `src/commands/*.ts`
+- Depends on: Service layer for business logic
+- Used by: CLI entry point (`src/index.ts`)
+
+**Service Layer:**
+- Purpose: Core business logic
+- Contains: FileService, TemplateService, InstallService
+- Location: `src/services/*.ts`
+- Depends on: File system utilities, external tools
+- Used by: Command handlers
+
+**Utility Layer:**
+- Purpose: Shared helpers and abstractions
+- Contains: File I/O wrappers, path resolution, string formatting
+- Location: `src/utils/*.ts`
+- Depends on: Node.js built-ins only
+- Used by: Service layer
+
+## Data Flow
+
+**CLI Command Execution:**
+
+1. User runs: `mindforge new-project`
+2. Commander parses args and flags
+3. Command handler invoked (`src/commands/new-project.ts`)
+4. Handler calls service methods (`src/services/project.ts` → `create()`)
+5. Service reads templates, processes files, writes output
+6. Results logged to console
+7. Process exits with status code
+
+**State Management:**
+- File-based: All state lives in `.mindforge/` directory
+- No persistent in-memory state
+- Each command execution is independent
+
+## Key Abstractions
+
+**Service:**
+- Purpose: Encapsulate business logic for a domain
+- Examples: `src/services/file.ts`, `src/services/template.ts`, `src/services/project.ts`
+- Pattern: Singleton-like (imported as modules, not instantiated)
+
+**Command:**
+- Purpose: CLI command definition
+- Examples: `src/commands/new-project.ts`, `src/commands/plan-phase.ts`
+- Pattern: Commander.js command registration
+
+**Template:**
+- Purpose: Reusable document structures
+- Examples: MINDFORGE.md, PLAN.md templates
+- Pattern: Markdown files with substitution variables
+
+## Entry Points
+
+**CLI Entry:**
+- Location: `src/index.ts`
+- Triggers: User runs `mindforge <command>`
+- Responsibilities: Register commands, parse args, display help
+
+**Commands:**
+- Location: `src/commands/*.ts`
+- Triggers: Matched command from CLI
+- Responsibilities: Validate input, call services, format output
+
+## Error Handling
+
+**Strategy:** Throw exceptions, catch at command level, log and exit
+
+**Patterns:**
+- Services throw Error with descriptive messages
+- Command handlers catch, log error to stderr, exit(1)
+- Validation errors shown before execution (fail fast)
+
+## Cross-Cutting Concerns
+
+**Logging:**
+- Console.log for normal output
+- Console.error for errors
+- Chalk for colored output
+
+**Validation:**
+- Zod schemas for config file parsing
+- Manual validation in command handlers
+- Fail fast on invalid input
+
+**File Operations:**
+- FileService abstraction over fs-extra
+- All paths validated before operations
+- Atomic writes (temp file + rename)
+
+---
+
+*Architecture analysis: 2025-01-20*
+*Update when major patterns change*
+```
+</good_examples>
+
+<guidelines>
+**What belongs in ARCHITECTURE.md:**
+- Overall architectural pattern (monolith, microservices, layered, etc.)
+- Conceptual layers and their relationships
+- Data flow / request lifecycle
+- Key abstractions and patterns
+- Entry points
+- Error handling strategy
+- Cross-cutting concerns (logging, auth, validation)
+
+**What does NOT belong here:**
+- Exhaustive file listings (that's STRUCTURE.md)
+- Technology choices (that's STACK.md)
+- Line-by-line code walkthrough (defer to code reading)
+- Implementation details of specific features
+
+**File paths ARE welcome:**
+Include file paths as concrete examples of abstractions. Use backtick formatting: `src/services/user.ts`. This makes the architecture document actionable for MindForge when planning.
+
+**When filling this template:**
+- Read main entry points (index, server, main)
+- Identify layers by reading imports/dependencies
+- Trace a typical request/command execution
+- Note recurring patterns (services, controllers, repositories)
+- Keep descriptions conceptual, not mechanical
+
+**Useful for phase planning when:**
+- Adding new features (where does it fit in the layers?)
+- Refactoring (understanding current patterns)
+- Identifying where to add code (which layer handles X?)
+- Understanding dependencies between components
+</guidelines>