mindforge-cc 2.2.0 → 2.3.5

package/.planning/decisions/ADR-001-handoff-tracking.md

@@ -1,41 +0,0 @@
-# ADR-001: Track HANDOFF.json in git
-
-**Status:** Accepted
-**Date:** 2026-03-20
-**Deciders:** MindForge core team
-
-## Context
-HANDOFF.json stores the current session state for agent continuity.
-It needs to be readable by the next agent session. The question is whether
-it should be committed to git (team-visible) or gitignored (local-only).
-
-## Decision
-Track HANDOFF.json in git.
-
-## Options considered
-
-### Option A — Track in git (chosen)
-Pros:
-- Any team member or new machine can pick up where the last session left off
-- Git history shows the evolution of session state
-- No risk of losing state on machine failure
-
-Cons:
-- File changes create noise in git history
-- Risk of accidentally committing sensitive session data
-
-Mitigations:
-- Added `_warning` field to prevent accidental secret storage
-- SUMMARY.md captures human-readable history; HANDOFF.json is machine state only
-
-### Option B — Gitignore
-Pros: No git noise, no secret exposure risk
-Cons: State lost on machine switch or re-clone; breaks team continuity
-
-## Rationale
-Team continuity outweighs the git noise concern. The warning field and
-documentation mitigate the secret exposure risk sufficiently.
-
-## Consequences
-Team must be educated to never write secrets into HANDOFF.json.
-CI should include a secret-scanning step that checks HANDOFF.json.

package/.planning/decisions/ADR-002-markdown-commands.md

@@ -1,46 +0,0 @@
-# ADR-002: Use Markdown files for slash commands (not TypeScript)
-
-**Status:** Accepted
-**Date:** 2026-03-20
-**Deciders:** MindForge core team
-
-## Context
-MindForge slash commands could be implemented as:
-A) Markdown instruction files (what we chose)
-B) TypeScript/JavaScript executable scripts
-C) A mix of both
-
-## Decision
-Markdown instruction files for all commands.
-
-## Options considered
-
-### Option A — Markdown instruction files (chosen)
-Pros:
-- Readable and editable without a build step
-- Can be updated directly by modifying text — no recompile
-- Agents can read and follow them natively
-- Community can contribute without TypeScript knowledge
-- Work identically across all runtimes (Claude Code, Antigravity, OpenCode)
-
-Cons:
-- No type safety for command logic
-- Cannot run unit tests on individual steps
-- Edge case handling is described in prose, not enforced in code
-
-### Option B — TypeScript scripts
-Pros: Type safety, unit testable, programmatic edge case handling
-Cons: Build step required, runtime-specific, harder to contribute to,
-      loses the "human-readable instructions" quality that makes them good agent prompts
-
-### Option C — Mix
-Assessed as worst of both: complexity of both without full benefit of either.
-
-## Rationale
-MindForge commands are agent prompts, not programs. Their primary consumer is
-an AI agent reading natural language. Markdown is the best format for that use case.
-Logic enforcement happens through agent quality gates, not code compilation.
-
-## Consequences
-Command edge cases must be described carefully in prose.
-A future "command validator" tool could parse and verify command files statically.

package/.planning/decisions/ADR-003-skills-trigger-model.md

@@ -1,37 +0,0 @@
-# ADR-003: Keyword-trigger model for skill discovery
-
-**Status:** Accepted
-**Date:** 2026-03-20
-**Deciders:** MindForge core team
-
-## Context
-Skills need to be loaded by the agent at the right time. The question is
-how the agent knows which skills are relevant for a given task.
-
-## Decision
-Keyword matching against a `triggers:` list in skill frontmatter.
-
-## Options considered
-
-### Option A — Keyword triggers in frontmatter (chosen)
-Pros: Simple, transparent, editable by anyone, no dependency on AI judgment
-Cons: Can miss contextual relevance; false positives on common words
-
-### Option B — AI decides which skills to load
-Pros: Contextually accurate matching
-Cons: Non-deterministic; different sessions might load different skills
-      for the same task; hard to debug; requires extra model call
-
-### Option C — Explicit user invocation only
-Pros: Precise control
-Cons: Loses the "just-in-time" benefit; users forget to invoke skills
-
-## Rationale
-Determinism is more valuable than perfect accuracy for a framework.
-Teams need to be able to predict what skills will activate. Keyword triggers
-provide that predictability. False positives are acceptable — loading a skill
-unnecessarily has low cost; missing a needed skill has high cost.
-
-## Consequences
-Trigger keyword lists must be maintained as skills evolve.
-A skill with too-narrow triggers will be missed. Err on the side of more triggers.

package/.planning/decisions/ADR-004-wave-parallelism-model.md

@@ -1,45 +0,0 @@
-# ADR-004: Wave-based parallel execution over full parallelism
-
-**Status:** Accepted
-**Date:** 2026-03-20
-**Deciders:** MindForge core team
-
-## Context
-When executing multiple tasks in a phase, we can choose:
-A) Run all tasks simultaneously (maximum parallelism)
-B) Run tasks in dependency-ordered waves (wave parallelism — chosen)
-C) Run tasks sequentially (no parallelism)
-
-## Decision
-Wave-based parallel execution. Tasks within a wave run in parallel.
-Waves execute sequentially.
-
-## Options considered
-
-### Option A — Full parallelism
-Pros: Maximum speed
-Cons: Cannot handle dependencies safely. If Plan 03 depends on Plan 01's output
-and both run simultaneously, Plan 03 reads stale data. Produces corrupt output.
-
-### Option B — Wave parallelism (chosen)
-Pros: Safely parallel within dependency constraints. Significantly faster than
-sequential. Dependency correctness is guaranteed by wave ordering.
-Cons: Some tasks that could theoretically run in parallel must wait for their
-dependency wave to complete.
-
-### Option C — Sequential
-Pros: Simplest to implement and reason about.
-Cons: Discards the primary quality advantage of parallel subagents — isolated
-200K token contexts per task. In sequential mode, the orchestrator's context
-fills up across tasks, degrading output quality over time.
-
-## Rationale
-Wave parallelism gives the correctness of sequential execution (dependency order
-respected) with the quality benefits of parallel isolation (each task gets a
-fresh 200K context). This is the optimal tradeoff.
-
-## Consequences
-- Plan authors must declare dependencies accurately — incorrect dependencies
-  can cause parallel tasks to conflict.
-- The dependency parser must catch cycles and conflicts before execution starts.
-- A small planning overhead (building the wave graph) is incurred per phase.

package/.planning/decisions/ADR-005-append-only-audit-log.md

@@ -1,51 +0,0 @@
-# ADR-005: Append-only JSONL audit log over structured database
-
-**Status:** Accepted
-**Date:** 2026-03-20
-**Deciders:** MindForge core team
-
-## Context
-MindForge needs an audit trail of agent actions. The storage format choices are:
-A) Append-only JSONL file (chosen)
-B) SQLite database
-C) In-memory log (written to JSON on session end)
-
-## Decision
-Append-only JSONL file: `.planning/AUDIT.jsonl`
-
-## Options considered
-
-### Option A — Append-only JSONL (chosen)
-Pros:
-- Zero dependencies (no SQLite driver needed)
-- Readable with standard Unix tools (grep, jq, tail)
-- Git-trackable — history of history
-- Tamper-evident via git (any deletion or modification is visible in `git diff`)
-- Works identically across all platforms and environments
-
-Cons:
-- No query language — filtering requires grep/jq
-- File grows unboundedly (mitigated by archiving strategy)
-- No transactions — a crash mid-write could produce a partial line
-
-### Option B — SQLite
-Pros: Full SQL query capability, transactional writes
-Cons: Binary file — not readable without tooling, not meaningfully git-diffable,
-      adds a native dependency, harder to inspect in CI/CD environments
-
-### Option C — In-memory log
-Pros: No I/O overhead during session
-Cons: Lost entirely if session crashes mid-execution — exactly when the audit log
-      is most needed.
-
-## Rationale
-For a framework targeting solo developers and small teams, readability and
-zero-dependency simplicity outweigh query sophistication. The primary audit use
-case is "what happened in this phase?" which grep handles well.
-
-## Consequences
-- A partial-line recovery tool should be built in a future hardening pass.
-  (Run `python3 -c "import sys,json;[print(l.strip()) for l in sys.stdin if json.loads(l)]"`
-  to filter clean lines from a corrupted AUDIT.jsonl)
-- An archiving strategy (rotate after 10,000 lines) will be added in Day 4.
-- The `status` command reads AUDIT.jsonl from the tail for performance.

package/.planning/decisions/ADR-006-tiered-skills-system.md

@@ -1,22 +0,0 @@
-# ADR-006: Three-tier skills architecture (Core → Org → Project)
-
-**Status:** Accepted
-**Date:** 2026-03-20
-
-## Context
-Skills need to be distributed at three scopes: universal best practices,
-organisation-specific standards, and project-specific patterns.
-
-## Decision
-Three-tier architecture with explicit priority: Project (T3) > Org (T2) > Core (T1).
-
-## Rationale
-The tier system solves the key tension: MindForge provides sensible defaults
-(Core), organisations customise for their standards (Org), and projects fine-tune
-for their specific context (Project). Higher tiers override lower tiers by same name,
-enabling intentional, documented overrides without modifying shared core skills.
-
-## Consequences
-- Skill authors must understand which tier is appropriate for their skill
-- Conflict resolution rules must be well-documented (see conflict-resolver.md)
-- Org-tier skills should be maintained in a shared repo, not per-project

package/.planning/decisions/ADR-007-trigger-keyword-model.md

@@ -1,22 +0,0 @@
-# ADR-007: Keyword-trigger model over AI-decided skill selection
-
-**Status:** Accepted
-**Date:** 2026-03-20
-
-## Context
-How should the agent decide which skills to load for a given task?
-Options: keyword triggers in frontmatter vs. AI-decided relevance.
-
-## Decision
-Keyword triggers in frontmatter (same model as Day 1 ADR-003, confirmed at Day 3 scale).
-
-## Additional rationale at Day 3 scale
-With 10+ skills, AI-decided selection has a higher risk of selecting wrong skills
-due to hallucinated relevance. Keyword triggers are deterministic — identical tasks
-always load identical skills, enabling reproducible results across sessions.
-The added specificity of file-name matching (not just text matching) improves
-trigger accuracy without sacrificing determinism.
-
-## Consequences
-Trigger keyword lists require ongoing maintenance as skill content evolves.
-The conflict resolver handles cases where multiple skills match.

package/.planning/decisions/ADR-008-just-in-time-skill-loading.md

@@ -1,29 +0,0 @@
-# ADR-008: Just-in-time skill loading over session-start loading
-
-**Status:** Accepted
-**Date:** 2026-03-20
-
-## Context
-When should skills be loaded — at session start (front-loaded) or at task time (JIT)?
-
-## Decision
-Just-in-time loading: skills are loaded immediately before the task that needs them.
-Skills are not loaded at session start.
-
-## Rationale
-Front-loading all skills at session start would:
-- Consume 30K+ tokens for 10 skills before any work begins
-- Load skills irrelevant to the current task (e.g., loading incident-response
-  skills for a UI component task)
-- Pollute the agent's context with contradictory guidance from multiple domains
-
-JIT loading means:
-- Each task starts with only the relevant skills in context
-- Context budget is spent on relevant expertise, not irrelevant policies
-- Skills load at the moment they are most useful to the agent
-
-## Consequences
-- Skills must be re-loaded for each task (no session-level caching)
-- The trigger index is built once at session start (inexpensive: reads frontmatter only)
-- Skills that need to be available across multiple tasks should use the
-  minimal context injection (trigger + mandatory actions only) to save budget

package/.planning/decisions/ADR-009-enterprise-integration-retry-policy.md

@@ -1,8 +0,0 @@
-# ADR-009: Standardized retry/backoff policy for enterprise integrations
-
-**Status:** Accepted
-**Date:** 2026-03-20
-
-## Decision
-Use bounded exponential backoff with jitter for integration APIs and stop retrying
-on explicit authorization failures.

package/.planning/decisions/ADR-010-governance-tier-escalation.md

@@ -1,8 +0,0 @@
-# ADR-010: Governance tier escalation by path, content, and history
-
-**Status:** Accepted
-**Date:** 2026-03-20
-
-## Decision
-Classify changes using path signals, code-content risk signals, and recent audit
-history so risk is not underestimated by filename-only matching.

package/.planning/decisions/ADR-011-multi-developer-handoff-contract.md

@@ -1,8 +0,0 @@
-# ADR-011: Multi-developer handoff must remain append-only and conflict-aware
-
-**Status:** Accepted
-**Date:** 2026-03-20
-
-## Decision
-Use append-only handoff records with staleness checks and explicit ownership of
-files/plans to reduce merge-time coordination failures.

package/.planning/decisions/ADR-012-intelligence-feedback-loops.md

@@ -1,19 +0,0 @@
-# ADR-012: Intelligence outputs must feed back into behavior
-
-**Status:** Accepted
-**Date:** 2026-03-20
-
-## Context
-Day 5 introduces difficulty scoring, retrospectives, compaction quality, and
-session metrics. Without explicit feedback connectors these become passive
-reports.
-
-## Decision
-Use explicit loops:
-- difficulty -> planning granularity
-- retrospective -> MINDFORGE updates
-- quality metrics -> session behavior adjustments
-- compaction -> richer handoff continuity
-
-## Consequences
-Every intelligence artifact must define its downstream behavioral effect.

package/.planning/decisions/ADR-013-mindforge-md-constitution.md

@@ -1,16 +0,0 @@
-# ADR-013: MINDFORGE.md is configurable but cannot disable governance primitives
-
-**Status:** Accepted
-**Date:** 2026-03-20
-
-## Context
-Project-level customization is required, but unrestricted overrides would allow
-accidental or malicious disabling of core safety guarantees.
-
-## Decision
-Allow MINDFORGE overrides only for configurable preferences and thresholds.
-Keep secret detection, security auto-trigger, plan-first, and audit-writing
-as non-overridable primitives.
-
-## Consequences
-Customization remains flexible while governance stays enforceable.

package/.planning/decisions/ADR-014-metrics-as-signals-not-evaluation.md

@@ -1,15 +0,0 @@
-# ADR-014: Metrics are process signals, not developer performance metrics
-
-**Status:** Accepted
-**Date:** 2026-03-20
-
-## Context
-Session and phase quality metrics can be misused as individual performance
-scores, which undermines reliability and psychological safety.
-
-## Decision
-Use metrics solely for system/process improvement and personalization.
-Do not use them for individual performance evaluation.
-
-## Consequences
-Documentation and profile policy must explicitly prohibit evaluative use.

package/.planning/decisions/ADR-015-npm-based-skill-registry.md

@@ -1,26 +0,0 @@
-# ADR-015: npm as the MindForge Skills Registry
-
-**Status:** Accepted
-**Date:** 2026-03-21
-
-## Context
-MindForge needs a way to distribute community and organisation skills.
-Options: custom registry server, GitHub releases, npm registry.
-
-## Decision
-Use the standard npm registry with `mindforge-skill-` package naming convention.
-
-## Rationale
-npm is the world's largest package registry with existing infrastructure for:
-versioning, authentication, access control, search, and deprecation.
-Building a custom registry duplicates all of this at significant cost.
-The npm ecosystem's supply chain security tooling (npm audit, Dependabot,
-Snyk) works natively. Private registries (Verdaccio, Artifactory, GitHub Packages)
-are npm-compatible — organisations with private skills don't need separate tooling.
-
-## Consequences
-- Skill names follow npm conventions (lowercase, hyphens)
-- Version management follows npm semver conventions
-- Private skills require a compatible private npm registry
-- The injection guard and validation pipeline are the primary
-  supply chain security controls (npm audit is insufficient alone for SKILL.md content)

package/.planning/decisions/ADR-016-ci-exit-code-0-on-timeout.md

@@ -1,27 +0,0 @@
-# ADR-016: CI timeout exits with code 0 (soft stop)
-
-**Status:** Accepted
-**Date:** 2026-03-21
-
-## Context
-MindForge CI may run out of time before completing all phases.
-The question is: should timeout exit with code 0 (success) or non-zero (failure)?
-
-## Decision
-Timeout exits with code 0. State is saved. Next CI run resumes.
-
-## Rationale
-A MindForge CI timeout is not a code failure — it is a resource limit.
-Failing the build on timeout would:
-1. Block the PR with a failure that has no fix (the code is fine — time ran out)
-2. Force teams to either increase CI limits or split phases artificially
-3. Make MindForge feel unreliable ("it randomly fails when there's a lot to do")
-
-The correct behaviour: save progress, exit cleanly, let the next run continue.
-The CI pipeline is designed for continuation, not completion in a single run.
-
-## Consequences
-- CI pipelines may run multiple times for a single phase
-- HANDOFF.json must be committed during CI runs (CI has write access)
-- Teams must monitor CI for timeout patterns (frequent timeouts → split phases)
-- GitHub Actions step summary provides visibility into timeout state

package/.planning/decisions/ADR-017-sdk-localhost-only.md

@@ -1,28 +0,0 @@
-# ADR-017: MindForge SDK event stream is localhost-only
-
-**Status:** Accepted
-**Date:** 2026-03-21
-
-## Context
-The MindForge SDK includes an SSE event stream for real-time progress.
-The question is whether it should bind to all interfaces or localhost only.
-
-## Decision
-The event stream binds to 127.0.0.1 (localhost) only.
-
-## Rationale
-The event stream exposes:
-- AUDIT.jsonl entries (which contain sensitive project state)
-- Task completion events (which reveal code structure and timing)
-- Security finding events (which reveal vulnerability information)
-
-Exposing this to all network interfaces in a shared development environment
-(VMs, shared cloud desktops, containers) would allow other users to monitor
-another developer's project state in real-time.
-Localhost binding provides adequate protection for the primary use case
-(local developer tooling) without requiring authentication infrastructure.
-
-## Consequences
-- Remote integrations cannot use the event stream directly
-- For remote monitoring: use the audit log query API via SSH tunnel
-- Container environments: map the port explicitly if remote access is needed

package/.planning/decisions/ADR-018-installer-self-install-detection.md

@@ -1,15 +0,0 @@
-# ADR-018: Installer detects and handles self-install scenario
-
-**Status:** Accepted | **Date:** v1.0.0 | **Day:** 7
-
-## Context
-Running `npx mindforge-cc --claude --local` inside the MindForge repo itself
-would copy `.mindforge/` to `.mindforge/` (source = destination).
-
-## Decision
-Detect self-install by checking `package.json.name === 'mindforge-cc'`.
-If self-install: skip framework file copies. Only install commands.
-
-## Rationale
-Core team runs the installer locally for testing frequently.
-Silent no-op with a clear warning is better than a cryptic error or accidental self-overwrite.

package/.planning/decisions/ADR-019-self-update-scope-preservation.md

@@ -1,14 +0,0 @@
-# ADR-019: Self-update preserves the original installation scope
-
-**Status:** Accepted | **Date:** v1.0.0 | **Day:** 7
-
-## Context
-`/mindforge:update --apply` must update the correct installation.
-
-## Decision
-Detect original scope from filesystem (local before global per priority).
-Apply update using the detected scope. Per ADR-019.
-
-## Rationale
-Principle of least surprise. A local install user should get a local update.
-Unexpected global install is confusing and may affect other projects.

package/.planning/decisions/ADR-020-v1.0.0-stable-interface-contract.md

@@ -1,23 +0,0 @@
-# ADR-020: v1.0.0 stable interface contract
-
-**Status:** Accepted | **Date:** v1.0.0 | **Day:** 7
-
-## Context
-MindForge reaches v1.0.0. "Stable" must be precisely defined.
-
-## Decision
-Stable public interfaces (additions require MINOR, removals/changes require MAJOR):
-- All 36 command names and their flag interfaces
-- HANDOFF.json schema fields
-- AUDIT.jsonl event types and required fields
-- All 10 core skill name values
-- MINDFORGE.md setting keys
-- @mindforge/sdk exported types and functions
-- plugin.json manifest format
-
-Governance primitives are permanently fixed and cannot become configurable
-in any future version without a MAJOR bump and explicit RFC process.
-
-## Consequences
-Plugin authors and SDK consumers can build on v1.0.0 with confidence.
-The MindForge team is committed to backwards compatibility in 1.x.x releases.

package/.planning/decisions/ADR-021-autonomy-boundary.md

@@ -1,17 +0,0 @@
-# ADR-021: Autonomy Boundary
-
-## Status: Proposed
-## Deciders: MindForge Architecture Team
-## Date: 2026-03-22
-
-## Context
-MindForge v2 introduces an Autonomous Execution Engine. We need to define where the human's role ends and the agent's role begins to prevent loss of control while maximizing efficiency.
-
-## Decision
-We define the **Autonomy Boundary** as:
-1. **Human = Mission Control**: Humans define the phase objectives, approve the initial plan, and provide mid-execution steering.
-2. **Agent = Execution Engine**: The agent handles the mechanics of wave execution, parallel task dispatch, automated verification, and self-repair for low-risk failures.
-
-## Consequences
-- The agent will not ask for permission for individual tasks in a wave once the phase is started in `:auto` mode.
-- Any decision involving security, payments, or PII (Tier 3) MUST escalate to the human, as it lies outside the autonomy boundary.

package/.planning/decisions/ADR-022-node-repair-hierarchy.md

@@ -1,19 +0,0 @@
-# ADR-022: Node Repair Hierarchy
-
-## Status: Proposed
-## Deciders: MindForge Architecture Team
-## Date: 2026-03-22
-
-## Context
-Tasks in autonomous mode can fail due to various reasons (timeouts, lint errors, logic bugs). Sequential retrying is often insufficient.
-
-## Decision
-We implement a tiered **Node Repair Hierarchy**:
-1. **RETRY**: Re-execute the same plan with a fresh context + error injection. (Budget: 1)
-2. **DECOMPOSE**: Split a failing multi-domain or high-token task into smaller sub-tasks.
-3. **PRUNE**: Skip non-critical path tasks and defer them to a `DEFERRED-ITEMS.md`.
-4. **ESCALATE**: Stop execution, save state, and notify the human.
-
-## Consequences
-- Increases the survival rate of autonomous sessions without human intervention for trivial errors.
-- Ensures complex failures are handled by human experts.

package/.planning/decisions/ADR-023-gate-3-timing.md

@@ -1,15 +0,0 @@
-# ADR-023: Gate 3 Timing
-
-## Status: Proposed
-## Deciders: MindForge Architecture Team
-## Date: 2026-03-22
-
-## Context
-Gate 3 (Secret Detection) used to run post-wave. In autonomous mode, the agent makes multiple commits per wave. A secret committed to git history is an immediate security incident even if never pushed.
-
-## Decision
-Gate 3 must run **PRE-COMMIT** on the staged diff for every task in autonomous mode. If a secret pattern is detected, the commit is blocked, the changes are unstaged, and the engine ESCALATES immediately.
-
-## Consequences
-- Prevents accidental leakage of credentials into the local git history.
-- Adds slight latency to the commit process, which is acceptable for the security gain.

package/.planning/decisions/ADR-036-learn-command-docs-as-skill-source.md

@@ -1,26 +0,0 @@
-# ADR-036: Documentation is the authoritative source for skill content
-
-**Status:** Accepted | **Date:** v2.0.0 | **Day:** 13
-
-## Context
-Where should skill content come from — human-authored or AI-generated?
-
-## Decision
-Skill content is AI-generated from authoritative documentation (official docs,
-internal runbooks, npm READMEs, or session analysis). The AI reads the docs
-and writes down what it learned, following the SKILL.md authoring template.
-
-## Rationale
-Documentation is the authoritative, maintained, versioned source of truth for
-any technology. Human-authored skills get stale and diverge from reality.
-Documentation-sourced skills automatically reflect the current state of the
-technology when regenerated.
-
-The AI's role: transform documentation into the MindForge SKILL.md format
-(structured rules, trigger keywords, code examples, checklist) — not to
-invent patterns that don't exist in the documentation.
-
-## Consequences
-Skills should be regenerated when documentation is updated (major versions).
-The quality of skills depends on the quality of source documentation.
-Internal documentation produces the most project-specific, valuable skills.

package/.planning/decisions/ADR-037-auto-capture-frequency-threshold.md

@@ -1,26 +0,0 @@
-# ADR-037: Pattern frequency ≥ 2 tasks as the auto-capture threshold
-
-**Status:** Accepted | **Date:** v2.0.0 | **Day:** 13
-
-## Context
-What frequency of pattern appearance should trigger auto-capture?
-
-## Decision
-Auto-capture triggers when a pattern appears in ≥ 2 tasks (default).
-Exception: a pattern in 1 task can also qualify if difficulty = "high" AND
-generality ≠ "low" (important patterns worth capturing even on first occurrence).
-
-Configurable via AUTO_CAPTURE_MIN_PATTERN_COUNT in MINDFORGE.md.
-
-## Rationale
-A single occurrence is high-noise — it could be a one-off approach or
-something specific to that task's edge case. Two occurrences strongly
-suggest a reusable pattern. The exception for "high difficulty + non-low
-generality" catches important one-time discoveries (security patterns, tricky
-library APIs) that are hard to rediscover and broadly applicable.
-
-## Consequences
-Most phases will produce 0-3 capture candidates (not noisy).
-High-activity phases with many similar tasks may produce more.
-The user always approves before any skill is created — auto-capture is a
-suggestion, never automatic skill creation.

package/.planning/decisions/ADR-038-skill-quality-minimum-60.md

@@ -1,27 +0,0 @@
-# ADR-038: Minimum quality score of 60 for skill registration
-
-**Status:** Accepted | **Date:** v2.0.0 | **Day:** 13
-
-## Context
-What quality score should be required before a skill can be registered?
-
-## Decision
-Minimum score of 60/100 for project/org registration.
-Minimum score of 80/100 for community marketplace publication.
-Injection check failure (dimension 5 = 0) = absolute block regardless of total score.
-
-## Rationale
-60 is the "minimum viable" threshold — a skill at 60 has enough triggers,
-content, and examples to be useful, but is below the "good" tier (80).
-The gap between 60 and 80 allows registration for internal use while protecting
-the public marketplace from mediocre skills.
-
-The injection check is absolute — a skill that contains "IGNORE ALL PREVIOUS
-INSTRUCTIONS" must NEVER be registered regardless of its other quality dimensions.
-Even a score of 95 with an injection pattern is blocked. This is the same
-non-negotiable principle as Gate 3 (secret detection) in compliance-gates.md.
-
-## Consequences
-The AI-generated learn pipeline is tuned to produce skills scoring ≥ 80.
-Skills below 60 get improvement suggestions but cannot be registered.
-Teams can lower this threshold via SKILL_QUALITY_MIN_SCORE in MINDFORGE.md.