mindforge-cc 9.0.0 → 10.0.1

package/docs/Templates/Project/MILESTONE-ARCHIVE.md

@@ -1,123 +0,0 @@
-# Milestone Archive Template
-
-This template is used by the complete-milestone workflow to create archive files in `.planning/milestones/`.
-
----
-
-## File Template
-
-# Milestone v{{VERSION}}: {{MILESTONE_NAME}}
-
-**Status:** ✅ SHIPPED {{DATE}}
-**Phases:** {{PHASE_START}}-{{PHASE_END}}
-**Total Plans:** {{TOTAL_PLANS}}
-
-## Overview
-
-{{MILESTONE_DESCRIPTION}}
-
-## Phases
-
-{{PHASES_SECTION}}
-
-[For each phase in this milestone, include:]
-
-### Phase {{PHASE_NUM}}: {{PHASE_NAME}}
-
-**Goal**: {{PHASE_GOAL}}
-**Depends on**: {{DEPENDS_ON}}
-**Plans**: {{PLAN_COUNT}} plans
-
-Plans:
-
-- [x] {{PHASE}}-01: {{PLAN_DESCRIPTION}}
-- [x] {{PHASE}}-02: {{PLAN_DESCRIPTION}}
-      [... all plans ...]
-
-**Details:**
-{{PHASE_DETAILS_FROM_ROADMAP}}
-
-**For decimal phases, include (INSERTED) marker:**
-
-### Phase 2.1: Critical Security Patch (INSERTED)
-
-**Goal**: Fix authentication bypass vulnerability
-**Depends on**: Phase 2
-**Plans**: 1 plan
-
-Plans:
-
-- [x] 02.1-01: Patch auth vulnerability
-
-**Details:**
-{{PHASE_DETAILS_FROM_ROADMAP}}
-
----
-
-## Milestone Summary
-
-**Decimal Phases:**
-
-- Phase 2.1: Critical Security Patch (inserted after Phase 2 for urgent fix)
-- Phase 5.1: Performance Hotfix (inserted after Phase 5 for production issue)
-
-**Key Decisions:**
-{{DECISIONS_FROM_PROJECT_STATE}}
-[Example:]
-
-- Decision: Use ROADMAP.md split (Rationale: Constant context cost)
-- Decision: Decimal phase numbering (Rationale: Clear insertion semantics)
-
-**Issues Resolved:**
-{{ISSUES_RESOLVED_DURING_MILESTONE}}
-[Example:]
-
-- Fixed context overflow at 100+ phases
-- Resolved phase insertion confusion
-
-**Issues Deferred:**
-{{ISSUES_DEFERRED_TO_LATER}}
-[Example:]
-
-- PROJECT-STATE.md tiering (deferred until decisions > 300)
-
-**Technical Debt Incurred:**
-{{SHORTCUTS_NEEDING_FUTURE_WORK}}
-[Example:]
-
-- Some workflows still have hardcoded paths (fix in Phase 5)
-
----
-
-_For current project status, see .planning/ROADMAP.md_
-
----
-
-## Usage Guidelines
-
-<guidelines>
-**When to create milestone archives:**
-- After completing all phases in a milestone (v1.0, v1.1, v2.0, etc.)
-- Triggered by complete-milestone workflow
-- Before planning next milestone work
-
-**How to fill template:**
-
-- Replace {{PLACEHOLDERS}} with actual values
-- Extract phase details from ROADMAP.md
-- Document decimal phases with (INSERTED) marker
-- Include key decisions from PROJECT-STATE.md or SUMMARY files
-- List issues resolved vs deferred
-- Capture technical debt for future reference
-
-**Archive location:**
-
-- Save to `.planning/milestones/v{VERSION}-{NAME}.md`
-- Example: `.planning/milestones/v1.0-mvp.md`
-
-**After archiving:**
-
-- Update ROADMAP.md to collapse completed milestone in `<details>` tag
-- Update PROJECT.md to brownfield format with Current State section
-- Continue phase numbering in next milestone (never restart at 01)
-  </guidelines>

package/docs/Templates/Project/MILESTONE.md

@@ -1,115 +0,0 @@
-# Milestone Entry Template
-
-Add this entry to `.planning/MILESTONES.md` when completing a milestone:
-
-```markdown
-## v[X.Y] [Name] (Shipped: YYYY-MM-DD)
-
-**Delivered:** [One sentence describing what shipped]
-
-**Phases completed:** [X-Y] ([Z] plans total)
-
-**Key accomplishments:**
-- [Major achievement 1]
-- [Major achievement 2]
-- [Major achievement 3]
-- [Major achievement 4]
-
-**Stats:**
-- [X] files created/modified
-- [Y] lines of code (primary language)
-- [Z] phases, [N] plans, [M] tasks
-- [D] days from start to ship (or milestone to milestone)
-
-**Git range:** `feat(XX-XX)` → `feat(YY-YY)`
-
-**What's next:** [Brief description of next milestone goals, or "Project complete"]
-
----
-```
-
-<structure>
-If MILESTONES.md doesn't exist, create it with header:
-
-```markdown
-# Project Milestones: [Project Name]
-
-[Entries in reverse chronological order - newest first]
-```
-</structure>
-
-<guidelines>
-**When to create milestones:**
-- Initial v1.0 MVP shipped
-- Major version releases (v2.0, v3.0)
-- Significant feature milestones (v1.1, v1.2)
-- Before archiving planning (capture what was shipped)
-
-**Don't create milestones for:**
-- Individual phase completions (normal workflow)
-- Work in progress (wait until shipped)
-- Minor bug fixes that don't constitute a release
-
-**Stats to include:**
-- Count modified files: `git diff --stat feat(XX-XX)..feat(YY-YY) | tail -1`
-- Count LOC: `find . -name "*.swift" -o -name "*.ts" | xargs wc -l` (or relevant extension)
-- Phase/plan/task counts from ROADMAP
-- Timeline from first phase commit to last phase commit
-
-**Git range format:**
-- First commit of milestone → last commit of milestone
-- Example: `feat(01-01)` → `feat(04-01)` for phases 1-4
-</guidelines>
-
-<example>
-```markdown
-# Project Milestones: WeatherBar
-
-## v1.1 Security & Polish (Shipped: 2025-12-10)
-
-**Delivered:** Security hardening with Keychain integration and comprehensive error handling
-
-**Phases completed:** 5-6 (3 plans total)
-
-**Key accomplishments:**
-- Migrated API key storage from plaintext to macOS Keychain
-- Implemented comprehensive error handling for network failures
-- Added Sentry crash reporting integration
-- Fixed memory leak in auto-refresh timer
-
-**Stats:**
-- 23 files modified
-- 650 lines of Swift added
-- 2 phases, 3 plans, 12 tasks
-- 8 days from v1.0 to v1.1
-
-**Git range:** `feat(05-01)` → `feat(06-02)`
-
-**What's next:** v2.0 SwiftUI redesign with widget support
-
----
-
-## v1.0 MVP (Shipped: 2025-11-25)
-
-**Delivered:** Menu bar weather app with current conditions and 3-day forecast
-
-**Phases completed:** 1-4 (7 plans total)
-
-**Key accomplishments:**
-- Menu bar app with popover UI (AppKit)
-- OpenWeather API integration with auto-refresh
-- Current weather display with conditions icon
-- 3-day forecast list with high/low temperatures
-- Code signed and notarized for distribution
-
-**Stats:**
-- 47 files created
-- 2,450 lines of Swift
-- 4 phases, 7 plans, 28 tasks
-- 12 days from start to ship
-
-**Git range:** `feat(01-01)` → `feat(04-01)`
-
-**What's next:** Security audit and hardening for v1.1
-```
-</example>

package/docs/Templates/Project/PROJECT.md

@@ -1,206 +0,0 @@
-# PROJECT.md Template
-
-Template for `.planning/PROJECT.md` — the living project context document.
-
-<template>
-
-```markdown
-# [Project Name]
-
-## What This Is
-
-[Current accurate description — 2-3 sentences. What does this product do and who is it for?
-Use the user's language and framing. Update whenever reality drifts from this description.]
-
-## Core Value
-
-[The ONE thing that matters most. If everything else fails, this must work.
-One sentence that drives prioritization when tradeoffs arise.]
-
-## Stakeholders
-
-<!-- Internal and external parties invested in this project. -->
-
-| Role | Personnel | Responsibilities |
-|------|-----------|------------------|
-| [e.g. Product Owner] | [Name] | [Primary decision maker] |
-| [e.g. Lead Dev] | [Name] | [Technical oversight] |
-
-## Requirements
-
-### Validated
-
-<!-- Shipped and confirmed valuable. -->
-
-(None yet — ship to validate)
-
-
-### Active
-
-<!-- Current scope. Building toward these. -->
-
-
-- [ ] [Requirement 1]
-- [ ] [Requirement 2]
-- [ ] [Requirement 3]
-
-
-### Out of Scope
-
-<!-- Explicit boundaries. Includes reasoning to prevent re-adding. -->
-
-- [Exclusion 1] — [why]
-- [Exclusion 2] — [why]
-
-## Context
-
-[Background information that informs implementation:
-- Technical environment or ecosystem
-- Relevant prior work or experience
-- User research or feedback themes
-- Known issues to address]
-
-## Constraints
-
-- **[Type]**: [What] — [Why]
-- **[Type]**: [What] — [Why]
-
-Common types: Tech stack, Timeline, Budget, Dependencies, Compatibility, Performance, Security
-
-## Risk Register
-
-<!-- Potential roadblocks and mitigation strategies. -->
-
-| Risk | Impact | Probability | Mitigation Strategy |
-|------|--------|-------------|---------------------|
-| [Risk Title] | [H/M/L] | [H/M/L] | [Action plan] |
-
-## Key Decisions
-
-<!-- Decisions that constrain future work. Add throughout project lifecycle. -->
-
-| Decision | Rationale | Outcome |
-| :--- | :--- | :--- |
-| [Choice] | [Why] | [✓ Good / ⚠️ Revisit / — Pending] |
-
----
-*Last updated: [date] after [trigger]*
-```
-
-</template>
-
-<guidelines>
-
-**What This Is:**
-- Current accurate description of the product
-- 2-3 sentences capturing what it does and who it's for
-- Use the user's words and framing
-- Update when the product evolves beyond this description
-
-**Core Value:**
-- The single most important thing
-- Everything else can fail; this cannot
-- Drives prioritization when tradeoffs arise
-- Rarely changes; if it does, it's a significant pivot
-
-**Requirements — Validated:**
-- Requirements that shipped and proved valuable
-- Format: `- ✓ [Requirement] — [version/phase]`
-- These are locked — changing them requires explicit discussion
-
-**Requirements — Active:**
-- Current scope being built toward
-- These are hypotheses until shipped and validated
-- Move to Validated when shipped, Out of Scope if invalidated
-
-**Requirements — Out of Scope:**
-- Explicit boundaries on what we're not building
-- Always include reasoning (prevents re-adding later)
-- Includes: considered and rejected, deferred to future, explicitly excluded
-
-**Context:**
-- Background that informs implementation decisions
-- Technical environment, prior work, user feedback
-- Known issues or technical debt to address
-- Update as new context emerges
-
-**Constraints:**
-- Hard limits on implementation choices
-- Tech stack, timeline, budget, compatibility, dependencies
-- Include the "why" — constraints without rationale get questioned
-
-**Key Decisions:**
-- Significant choices that affect future work
-- Add decisions as they're made throughout the project
-- Track outcome when known:
-  - ✓ Good — decision proved correct
-  - ⚠️ Revisit — decision may need reconsideration
-  - — Pending — too early to evaluate
-
-**Last Updated:**
-- Always note when and why the document was updated
-- Format: `after Phase 2` or `after v1.0 milestone`
-- Triggers review of whether content is still accurate
-
-</guidelines>
-
-<evolution>
-
-PROJECT.md evolves throughout the project lifecycle.
-These rules are embedded in the generated PROJECT.md (## Evolution section)
-and implemented by workflows/transition.md and workflows/complete-milestone.md.
-
-**After each phase transition:**
-1. Requirements invalidated? → Move to Out of Scope with reason
-2. Requirements validated? → Move to Validated with phase reference
-3. New requirements emerged? → Add to Active
-4. Decisions to log? → Add to Key Decisions
-5. "What This Is" still accurate? → Update if drifted
-
-**After each milestone:**
-1. Full review of all sections
-2. Core Value check — still the right priority?
-3. Audit Out of Scope — reasons still valid?
-4. Update Context with current state (users, feedback, metrics)
-
-</evolution>
-
-<brownfield>
-
-For existing codebases:
-
-1. **Map codebase first** via `/mindforge-map-codebase`
-
-2. **Infer Validated requirements** from existing code:
-   - What does the codebase actually do?
-   - What patterns are established?
-   - What's clearly working and relied upon?
-
-3. **Gather Active requirements** from user:
-   - Present inferred current state
-   - Ask what they want to build next
-
-4. **Initialize:**
-   - Validated = inferred from existing code
-   - Active = user's goals for this work
-   - Out of Scope = boundaries user specifies
-   - Context = includes current codebase state
-
-</brownfield>
-
-<state_reference>
-
-STATE.md references PROJECT.md:
-
-```markdown
-## Project Reference
-
-See: .planning/PROJECT.md (updated [date])
-
-**Core value:** [One-liner from Core Value section]
-**Current focus:** [Current phase name]
-```
-
-This ensures the agent reads current PROJECT.md context.
-
-</state_reference>

package/docs/Templates/Project/REQUIREMENTS.md

@@ -1,231 +0,0 @@
-# Requirements Template
-
-Template for `.planning/REQUIREMENTS.md` — checkable requirements that define "done."
-
-<template>
-
-```markdown
-# Requirements: [Project Name]
-
-**Defined:** [date]
-**Core Value:** [from PROJECT.md]
-
-## v1 Requirements
-
-Requirements for initial release. Each maps to roadmap phases.
-
-### Authentication
-
-- [ ] **AUTH-01**: User can sign up with email and password
-- [ ] **AUTH-02**: User receives email verification after signup
-- [ ] **AUTH-03**: User can reset password via email link
-- [ ] **AUTH-04**: User session persists across browser refresh
-
-### [Category 2]
-
-- [ ] **[CAT]-01**: [Requirement description]
-- [ ] **[CAT]-02**: [Requirement description]
-- [ ] **[CAT]-03**: [Requirement description]
-
-### [Category 3]
-
-- [ ] **[CAT]-01**: [Requirement description]
-- [ ] **[CAT]-02**: [Requirement description]
-
-## v2 Requirements
-
-Deferred to future release. Tracked but not in current roadmap.
-
-### [Category]
-
-- **[CAT]-01**: [Requirement description]
-- **[CAT]-02**: [Requirement description]
-
-## Out of Scope
-
-Explicitly excluded. Documented to prevent scope creep.
-
-| Feature | Reason |
-|---------|--------|
-| [Feature] | [Why excluded] |
-| [Feature] | [Why excluded] |
-
-## Traceability
-
-Which phases cover which requirements. Updated during roadmap creation.
-
-| Requirement | Phase | Status |
-|-------------|-------|--------|
-| AUTH-01 | Phase 1 | Pending |
-| AUTH-02 | Phase 1 | Pending |
-| AUTH-03 | Phase 1 | Pending |
-| AUTH-04 | Phase 1 | Pending |
-| [REQ-ID] | Phase [N] | Pending |
-
-**Coverage:**
-- v1 requirements: [X] total
-- Mapped to phases: [Y]
-- Unmapped: [Z] ⚠️
-
----
-*Requirements defined: [date]*
-*Last updated: [date] after [trigger]*
-```
-
-</template>
-
-<guidelines>
-
-**Requirement Format:**
-- ID: `[CATEGORY]-[NUMBER]` (AUTH-01, CONTENT-02, SOCIAL-03)
-- Description: User-centric, testable, atomic
-- Checkbox: Only for v1 requirements (v2 are not yet actionable)
-
-**Categories:**
-- Derive from research FEATURES.md categories
-- Keep consistent with domain conventions
-- Typical: Authentication, Content, Social, Notifications, Moderation, Payments, Admin
-
-**v1 vs v2:**
-- v1: Committed scope, will be in roadmap phases
-- v2: Acknowledged but deferred, not in current roadmap
-- Moving v2 → v1 requires roadmap update
-
-**Out of Scope:**
-- Explicit exclusions with reasoning
-- Prevents "why didn't you include X?" later
-- Anti-features from research belong here with warnings
-
-**Traceability:**
-- Empty initially, populated during roadmap creation
-- Each requirement maps to exactly one phase
-- Unmapped requirements = roadmap gap
-
-**Status Values:**
-- Pending: Not started
-- In Progress: Phase is active
-- Complete: Requirement verified
-- Blocked: Waiting on external factor
-
-</guidelines>
-
-<evolution>
-
-**After each phase completes:**
-1. Mark covered requirements as Complete
-2. Update traceability status
-3. Note any requirements that changed scope
-
-**After roadmap updates:**
-1. Verify all v1 requirements still mapped
-2. Add new requirements if scope expanded
-3. Move requirements to v2/out of scope if descoped
-
-**Requirement completion criteria:**
-- Requirement is "Complete" when:
-  - Feature is implemented
-  - Feature is verified (tests pass, manual check done)
-  - Feature is committed
-
-</evolution>
-
-<example>
-
-```markdown
-# Requirements: CommunityApp
-
-**Defined:** 2025-01-14
-**Core Value:** Users can share and discuss content with people who share their interests
-
-## v1 Requirements
-
-### Authentication
-
-- [ ] **AUTH-01**: User can sign up with email and password
-- [ ] **AUTH-02**: User receives email verification after signup
-- [ ] **AUTH-03**: User can reset password via email link
-- [ ] **AUTH-04**: User session persists across browser refresh
-
-### Profiles
-
-- [ ] **PROF-01**: User can create profile with display name
-- [ ] **PROF-02**: User can upload avatar image
-- [ ] **PROF-03**: User can write bio (max 500 chars)
-- [ ] **PROF-04**: User can view other users' profiles
-
-### Content
-
-- [ ] **CONT-01**: User can create text post
-- [ ] **CONT-02**: User can upload image with post
-- [ ] **CONT-03**: User can edit own posts
-- [ ] **CONT-04**: User can delete own posts
-- [ ] **CONT-05**: User can view feed of posts
-
-### Social
-
-- [ ] **SOCL-01**: User can follow other users
-- [ ] **SOCL-02**: User can unfollow users
-- [ ] **SOCL-03**: User can like posts
-- [ ] **SOCL-04**: User can comment on posts
-- [ ] **SOCL-05**: User can view activity feed (followed users' posts)
-
-## v2 Requirements
-
-### Notifications
-
-- **NOTF-01**: User receives in-app notifications
-- **NOTF-02**: User receives email for new followers
-- **NOTF-03**: User receives email for comments on own posts
-- **NOTF-04**: User can configure notification preferences
-
-### Moderation
-
-- **MODR-01**: User can report content
-- **MODR-02**: User can block other users
-- **MODR-03**: Admin can view reported content
-- **MODR-04**: Admin can remove content
-- **MODR-05**: Admin can ban users
-
-## Out of Scope
-
-| Feature | Reason |
-|---------|--------|
-| Real-time chat | High complexity, not core to community value |
-| Video posts | Storage/bandwidth costs, defer to v2+ |
-| OAuth login | Email/password sufficient for v1 |
-| Mobile app | Web-first, mobile later |
-
-## Traceability
-
-| Requirement | Phase | Status |
-|-------------|-------|--------|
-| AUTH-01 | Phase 1 | Pending |
-| AUTH-02 | Phase 1 | Pending |
-| AUTH-03 | Phase 1 | Pending |
-| AUTH-04 | Phase 1 | Pending |
-| PROF-01 | Phase 2 | Pending |
-| PROF-02 | Phase 2 | Pending |
-| PROF-03 | Phase 2 | Pending |
-| PROF-04 | Phase 2 | Pending |
-| CONT-01 | Phase 3 | Pending |
-| CONT-02 | Phase 3 | Pending |
-| CONT-03 | Phase 3 | Pending |
-| CONT-04 | Phase 3 | Pending |
-| CONT-05 | Phase 3 | Pending |
-| SOCL-01 | Phase 4 | Pending |
-| SOCL-02 | Phase 4 | Pending |
-| SOCL-03 | Phase 4 | Pending |
-| SOCL-04 | Phase 4 | Pending |
-| SOCL-05 | Phase 4 | Pending |
-
-**Coverage:**
-- v1 requirements: 18 total
-- Mapped to phases: 18
-- Unmapped: 0 ✓
-
----
-*Requirements defined: 2025-01-14*
-*Last updated: 2025-01-14 after initial definition*
-```
-
-</example>