mindforge-cc 1.0.0

package/.mindforge/engine/skills/registry.md

@@ -0,0 +1,98 @@
+# MindForge Skills Engine — Registry
+
+## Purpose
+The skills registry tracks every available skill pack across all three tiers,
+their versions, trigger keywords, compatibility requirements, and source locations.
+The registry is the first thing the skills loader reads.
+
+## Registry file location
+`.mindforge/org/skills/MANIFEST.md` — org-level manifest (shared via git)
+
+## Manifest format
+
+The MANIFEST.md uses a structured table format readable by both humans and agents:
+
+```markdown
+# MindForge Skills Manifest
+# Version: 1.0.0
+# MindForge compatibility: >=0.1.0
+# Last updated: [ISO-8601]
+
+## Core Skills (Tier 1 — maintained by MindForge)
+
+| Name | Version | Status | Min MindForge | Triggers (excerpt) |
+|---|---|---|---|---|
+| security-review | 1.0.0 | stable | 0.1.0 | auth, password, token, JWT |
+| code-quality | 1.0.0 | stable | 0.1.0 | refactor, review, lint |
+| api-design | 1.0.0 | stable | 0.1.0 | API, endpoint, REST |
+| testing-standards | 1.0.0 | stable | 0.1.0 | test, spec, coverage |
+| documentation | 1.0.0 | stable | 0.1.0 | README, docs, changelog |
+| performance | 1.0.0 | stable | 0.3.0 | performance, latency, cache |
+| accessibility | 1.0.0 | stable | 0.3.0 | a11y, aria, wcag, screen reader |
+| data-privacy | 1.0.0 | stable | 0.3.0 | GDPR, PII, consent, retention |
+| incident-response | 1.0.0 | stable | 0.3.0 | incident, outage, postmortem |
+| database-patterns | 1.0.0 | stable | 0.3.0 | query, index, migration, N+1 |
+
+## Org Skills (Tier 2 — maintained by your organisation)
+
+| Name | Version | Status | Min MindForge | Triggers (excerpt) |
+|---|---|---|---|---|
+| [org-skill-name] | 1.0.0 | stable | 0.1.0 | [trigger keywords] |
+
+## Project Skills (Tier 3 — maintained per project)
+
+| Name | Version | Status | Min MindForge | Triggers (excerpt) |
+|---|---|---|---|---|
+| [project-skill-name] | 1.0.0 | stable | 0.1.0 | [trigger keywords] |
+```
+
+## Parsing rules for MANIFEST.md
+
+1. Only parse rows inside the three tier tables.
+2. Treat the header row as column definitions.
+3. Columns are positional: Name | Version | Status | Min MindForge | Triggers (excerpt) or Path.
+4. Ignore placeholder rows like `(none yet ...)`.
+5. If a row is missing required columns: mark as invalid and warn.
+
+## Registry operations
+
+### Scan and build registry (run at session start)
+If MANIFEST.md does not exist on first install:
+1. Create it with the current Core skills table from the MindForge default template
+2. Log a warning: "MANIFEST.md was missing; created default registry."
+3. Continue scan on the newly created file
+
+1. Read `.mindforge/org/skills/MANIFEST.md`
+2. For each skill in the manifest, verify its SKILL.md file exists at the expected path
+3. If a skill in the manifest has no corresponding file: mark as `missing`
+4. If a SKILL.md file exists but is not in the manifest: mark as `unregistered`
+5. Build the in-session registry: a flat list of all valid skills with their metadata
+
+### Registry health check
+Run as part of `/mindforge:health`:
+- All manifest entries have corresponding SKILL.md files ✅ / ❌ missing
+- All SKILL.md files have valid frontmatter (name, version, triggers) ✅ / ❌ invalid
+- No trigger keyword conflicts between skills at the same tier ✅ / ⚠️ conflict
+- All skill versions are valid semver strings ✅ / ❌ invalid
+
+### Adding a skill to the registry
+1. Create the skill directory and SKILL.md (content per the authoring guide)
+2. Validate the SKILL.md frontmatter is complete and correct
+3. Add an entry to MANIFEST.md in the correct tier section
+4. Commit: `feat(skills): add [skill-name] v[version]`
+
+### Removing a skill from the registry
+1. Mark the skill as `deprecated` in MANIFEST.md (do not delete the entry)
+2. Add a `deprecated_at` and `replacement` field to the SKILL.md frontmatter
+3. After 2 sprints of deprecation: delete the skill directory and manifest entry
+4. Never hard-delete a skill that might still be referenced in existing PLAN files
+
+## Tier priority for conflict resolution
+When two skills at different tiers have overlapping trigger keywords:
+Priority order: Project (Tier 3) > Org (Tier 2) > Core (Tier 1)
+
+The higher-priority tier's skill is loaded. The lower-priority skill is not loaded.
+This allows org and project skills to override core skill behaviour intentionally.
+
+When two skills at the SAME tier have conflicting trigger keywords:
+See `conflict-resolver.md`.

package/.mindforge/engine/skills/versioning.md

@@ -0,0 +1,75 @@
+# MindForge Skills Engine — Versioning
+
+## Purpose
+Define how skill versions work, what constitutes a breaking change, and how
+agents handle version mismatches between what is installed and what is needed.
+
+## Versioning scheme
+Skills use Semantic Versioning (semver.org): MAJOR.MINOR.PATCH
+
+| Increment | When | Example |
+|---|---|---|
+| MAJOR | Breaking change to skill interface (removed triggers, changed output format, changed mandatory actions) | 1.0.0 → 2.0.0 |
+| MINOR | New trigger keywords, new optional sections, new examples | 1.0.0 → 1.1.0 |
+| PATCH | Clarifications, typo fixes, improved examples with no behaviour change | 1.0.0 → 1.0.1 |
+
+## Frontmatter version fields
+
+Every SKILL.md must have these frontmatter fields:
+
+```yaml
+---
+name: security-review
+version: 1.2.0
+min_mindforge_version: 0.1.0
+status: stable
+deprecated_at:         # ISO-8601 date if deprecated, empty if not
+replacement:           # skill name if deprecated, empty if not
+breaking_changes:
+  - "2.0.0: removed 'xss' as standalone trigger (now part of 'injection' trigger)"
+changelog:
+  - "1.2.0: added supply chain security check"
+  - "1.1.0: expanded OWASP checklist to include A08-A10"
+  - "1.0.0: initial stable release"
+---
+```
+
+## Compatibility check protocol
+
+Before loading any skill, verify compatibility:
+
+### Check 1 — MindForge version compatibility
+Read `min_mindforge_version` from the skill's frontmatter.
+Compare against the current MindForge version (from `package.json`).
+
+If skill's `min_mindforge_version` > current MindForge version:
+- Log a warning: "Skill [name] v[X] requires MindForge v[min] but current is v[current]."
+- Load the skill anyway (do not block execution)
+- Add to AUDIT entry: `"compatibility_warning": "skill requires newer MindForge"`
+
+### Check 2 — Deprecation check
+If the skill's `deprecated_at` field is set:
+- Warn: "Skill [name] was deprecated on [date]. Use [replacement] instead."
+- Load the replacement skill (if available) in addition to the deprecated one
+- Add to AUDIT entry: `"deprecated_skill_loaded": true`
+
+### Check 3 — Breaking change awareness
+If the skill has a MAJOR version bump since it was last used in this project:
+- List the breaking changes from the `breaking_changes` field
+- Alert: "Skill [name] has breaking changes since your last usage.
+  Review these before continuing: [list changes]"
+
+## Skill upgrade protocol
+
+When `/mindforge:skills update [skill-name]` is run:
+
+1. Check current version from MANIFEST.md
+2. Compare against the latest version in the MindForge repository
+3. If a newer version exists:
+   a. Show the diff in behaviour (changelog entries)
+   b. If MINOR or PATCH: auto-update, no confirmation needed
+   c. If MAJOR: show breaking changes, require explicit confirmation
+4. After update: re-validate all PLAN files that reference this skill
+   (check if any `<context>` fields would be affected by the breaking changes)
+5. Update MANIFEST.md with new version
+6. Commit: `chore(skills): upgrade [name] v[old] → v[new]`

package/.mindforge/engine/verification-pipeline.md

@@ -0,0 +1,111 @@
+# MindForge Engine — Verification Pipeline
+
+## Purpose
+Automatically verify that a completed phase has actually delivered what it
+promised in REQUIREMENTS.md. This is the agent's self-audit before human UAT.
+
+## Four verification stages
+
+### Stage 1 — Automated test suite
+```bash
+# Run the project's test suite (adapt command to project)
+npm test
+# or
+pytest
+# or
+cargo test
+```
+
+Pass criteria: ALL tests pass, zero failures.
+If any fail: stop. Do not proceed to Stage 2.
+Create fix plans for the failing tests before continuing (e.g., `PLAN-[N]-FIX-01.md`).
+Record in VERIFICATION.md: "Stage 1: FAILED — [X] tests failing"
+
+### Stage 2 — Requirement traceability
+For each functional requirement tagged v1 for this phase in REQUIREMENTS.md:
+
+1. Read the requirement and its acceptance criterion
+2. Search the codebase for the implementation:
+   ```bash
+   grep -r "[key term from requirement]" src/ --include="*.ts"
+   ```
+3. Find a test that covers this requirement:
+   ```bash
+   grep -r "[acceptance criterion term]" tests/ --include="*.test.ts"
+   ```
+4. Classify:
+   - ✅ Implemented and tested
+   - ⚠️  Implemented but no test
+   - ❌ Not found
+
+Any ❌ result: create a fix plan before proceeding to Stage 3.
+Any ⚠️  result: create a test task for the next phase backlog.
+
+### Stage 3 — Type safety and linting (TypeScript/Python projects)
+```bash
+# TypeScript
+npx tsc --noEmit
+npx eslint . --ext .ts,.tsx --max-warnings 0
+
+# Python
+mypy .
+ruff check .
+```
+
+Pass criteria: Zero errors, zero warnings.
+If any errors: create targeted fix tasks. Do not proceed to Stage 4 with errors.
+
+### Stage 4 — Security regression check
+Activate `security-reviewer.md` persona.
+Run the OWASP checklist from `security-review/SKILL.md` against all files
+modified in this phase.
+
+Specifically look for:
+- Any new endpoints without authentication (if the project uses auth)
+- Any new database queries without parameterisation
+- Any new file handling without MIME type validation
+- Any new environment variables without validation at startup
+
+Write findings to `.planning/phases/[N]/SECURITY-REVIEW-[N].md`.
+
+## VERIFICATION.md template
+
+Write to `.planning/phases/[N]/VERIFICATION.md`:
+
+```markdown
+# Phase [N] Verification Report
+
+## Date
+[ISO-8601]
+
+## Stage 1 — Test suite
+- Command: `[test command]`
+- Result: [X] tests passing, [Y] failing
+- Status: ✅ PASS / ❌ FAIL
+
+## Stage 2 — Requirement traceability
+
+| FR ID | Requirement                   | Status | Evidence                        |
+|-------|-------------------------------|--------|---------------------------------|
+| FR-01 | [requirement text]            | ✅     | `src/auth/login.ts:47` + test   |
+| FR-02 | [requirement text]            | ✅     | `src/auth/register.ts:23` + test|
+| FR-03 | [requirement text]            | ⚠️     | `src/auth/reset.ts:15`, no test |
+
+## Stage 3 — Static analysis
+- TypeScript errors: [0 / N]
+- ESLint warnings: [0 / N]
+- Status: ✅ PASS / ❌ FAIL
+
+## Stage 4 — Security regression
+- New endpoints reviewed: [X]
+- New database queries reviewed: [X]
+- Findings: [None / see SECURITY-REVIEW-[N].md]
+- Status: ✅ PASS / ❌ FAIL
+
+## Overall status
+✅ All stages passed — ready for human UAT
+❌ [N] stages failed — fix plans created
+
+## Fix plans created (if any)
+- `PLAN-[N]-FIX-01.md`: [what it fixes]
+```

package/.mindforge/engine/wave-executor.md

@@ -0,0 +1,235 @@
+# MindForge Engine — Wave Executor
+
+## Purpose
+Group tasks from the dependency graph into waves and execute each wave.
+Within a wave, all tasks are independent and can run in parallel.
+Between waves, execution is strictly sequential.
+
+## Wave grouping algorithm
+
+### Input
+The dependency graph from `dependency-parser.md`.
+
+### Algorithm — Kahn's topological sort (adapted for waves)
+
+```
+Initialize:
+  remaining = all plan IDs
+  completed = empty set
+  waves = []
+
+Repeat until remaining is empty:
+  current_wave = []
+  for each plan in remaining:
+    if ALL of plan's dependencies are in completed:
+      add plan to current_wave
+  
+  if current_wave is empty AND remaining is not empty:
+    ERROR: circular dependency detected (should have been caught by parser)
+  
+  waves.append(current_wave)
+  completed.add(all plans in current_wave)
+  remaining.remove(all plans in current_wave)
+
+Return waves
+```
+
+### Example output for the 5-plan example above:
+```
+Wave 1: [01, 02]          ← No dependencies — run in parallel
+Wave 2: [03, 04]          ← Depend on Wave 1 — run in parallel after Wave 1
+Wave 3: [05]              ← Depends on both Wave 2 tasks — runs after Wave 2
+```
+
+## Wave execution protocol
+
+### Before starting a wave
+1. Confirm all plans in previous wave have:
+   - Status: Completed in SUMMARY file
+   - Git commit SHA recorded
+   - `<verify>` step passed
+   
+   If any plan in the previous wave failed: STOP the entire phase.
+   Do not start the next wave. Report which plan failed and why.
+
+### During a wave — parallel execution
+For each plan in the current wave, spawn a subagent with this exact context
+package (see `context-injector.md` for the injection protocol):
+
+### Subagent invocation protocol (runtime-agnostic)
+Use the runtime-specific mechanism, but keep the inputs identical:
+- **Claude Code:** spawn a subagent with the context package and the PLAN file.
+  Require the subagent to write `SUMMARY-[N]-[M].md` and report completion.
+- **Antigravity:** spawn an agent via `.agent/` command with the same context
+  package and the PLAN file. Require the same SUMMARY file output.
+
+**Context package per subagent:**
+```
+REQUIRED (always inject):
+  .mindforge/org/CONVENTIONS.md
+  .mindforge/org/SECURITY.md
+  The specific PLAN file (PLAN-[N]-[M].md)
+  The persona file specified in <persona> field
+
+CONDITIONAL (inject only if referenced in plan):
+  .planning/ARCHITECTURE.md      ← if plan touches architecture
+  .planning/decisions/ADR-*.md   ← only ADRs referenced in plan's <context>
+  Relevant SKILL.md files        ← only skills listed in plan's <context>
+
+NEVER inject to subagents:
+  STATE.md        ← subagents do not need project-level state
+  ROADMAP.md      ← subagents do not need project-level roadmap
+  HANDOFF.json    ← subagents do not maintain session continuity
+  Other plans     ← subagents must not see sibling task plans
+```
+
+### After each plan in a wave completes
+The executing subagent must:
+1. Run the `<verify>` step and capture output
+2. Write SUMMARY-[N]-[M].md with verify output included
+3. Commit with: `git add [files-in-plan] && git commit -m "type(scope): task name"`
+4. Write an AUDIT entry (see `audit/AUDIT-SCHEMA.md`)
+5. Report completion status back to the orchestrator
+
+### Wave completion
+After all plans in a wave complete:
+1. Collect all SUMMARY files from this wave
+2. Run the project's full test suite
+3. If no test command exists yet: STOP and instruct the user to define it
+   in CONVENTIONS.md or add an initial test harness.
+4. If tests fail: identify which plan introduced the failure (use `git bisect`)
+5. Do not start the next wave until all tests pass
+
+## Failure handling
+
+### Task verify failure (mid-wave)
+
+When a task's `<verify>` step fails:
+
+1. **Stop the task immediately.** Do not attempt a second run automatically.
+2. **Write the SUMMARY file** with status `Failed ❌` and the full verify output.
+3. **Write a `task_failed` AUDIT entry** (see AUDIT-SCHEMA.md).
+4. **Stop the entire wave.** Other tasks in this wave that have not yet started:
+   do not start them. Tasks already running in parallel: let them complete
+   naturally, but do not start the next wave regardless of their outcome.
+5. **Report to the orchestrator:**
+   ```
+   ━━━ Wave [W] STOPPED — Task Failure ━━━━━━━━━━━━━━━━━━━━━━
+   Failed task : Plan [N]-[M]: [task name]
+   Verify output:
+   [full verify output]
+   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+   ```
+6. **Ask the user:**
+   ```
+   Options:
+     1. Spawn debug agent to diagnose the failure
+     2. Show me the failing code and I'll fix it manually
+     3. Skip this task and continue the wave (not recommended)
+     4. Abort the entire phase
+   
+   Choose 1, 2, 3, or 4:
+   ```
+7. If user chooses 1: invoke `/mindforge:debug` with the failure context pre-loaded.
+8. If user chooses 3 (skip): write a `quality_gate_failed` AUDIT entry with
+   `"gate": "verify_skipped_by_user"` and continue. This is tracked.
+9. If user chooses 4: update STATE.md with `status: Phase [N] aborted` and stop.
+
+### Test suite failure (between waves)
+
+When the test suite fails after a wave completes:
+
+1. **Identify the failing tests** — capture the full test output.
+2. **Identify the likely causal commit:**
+   ```bash
+   git log --oneline -[number of tasks in this wave]
+   ```
+3. **Report specifically:**
+   ```
+   ━━━ Test Suite Failure After Wave [W] ━━━━━━━━━━━━━━━━━━━━━
+   [N] tests failing.
+   
+   Likely cause: [commit sha] — [commit message]
+   Failing tests:
+     - [test name]: [error]
+     - [test name]: [error]
+   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+   ```
+4. **Write a `quality_gate_failed` AUDIT entry.**
+5. **Do not start the next wave.** This is absolute — no exceptions.
+6. **Ask the user:**
+   ```
+   Options:
+     1. Debug the failing tests now
+     2. Revert the last wave's commits and re-plan
+     3. I'll fix the tests manually — notify me when done
+   ```
+
+### Subagent hang (no SUMMARY file after expected duration)
+
+When a subagent has been running for an unexpectedly long time:
+(Heuristic: if a task with < 5 files has no SUMMARY after 30 minutes of session time)
+
+1. Alert the user: "Task [N]-[M] appears to be taking longer than expected.
+   Check if the subagent is still running or has stalled."
+2. Provide the option to: wait longer | restart the task | skip the task.
+3. Never silently let a wave stall indefinitely.
+
+### Missing PLAN file detected at runtime
+
+When execute-phase discovers a PLAN file referenced in the dependency graph is missing:
+
+1. Stop immediately.
+2. Report: "PLAN-[N]-[M].md was referenced but does not exist.
+   Run /mindforge:plan-phase [N] to regenerate the missing plan."
+3. Do not continue with partial plan execution.
+
+### Phase completion
+After all waves complete:
+1. Run the phase verification pipeline (see `verification-pipeline.md`)
+2. Write VERIFICATION.md
+3. Update STATE.md: phase N = complete
+4. Update HANDOFF.json with next phase information
+
+## Wave execution report format
+
+Write to `.planning/phases/[N]/WAVE-REPORT-[N].md`:
+
+```markdown
+# Wave Execution Report — Phase [N]
+
+## Wave 1
+| Plan | Task Name           | Status | Duration | Commit     |
+|------|---------------------|--------|----------|------------|
+| 01   | Create user model   | ✅     | ~8 min   | abc1234    |
+| 02   | Create product model| ✅     | ~6 min   | def5678    |
+
+**Wave 1 test results:** All passing ✅
+
+## Wave 2
+| Plan | Task Name             | Status | Duration | Commit     |
+|------|-----------------------|--------|----------|------------|
+| 03   | User API endpoints    | ✅     | ~12 min  | ghi9012    |
+| 04   | Product API endpoints | ✅     | ~10 min  | jkl3456    |
+
+**Wave 2 test results:** All passing ✅
+
+## Wave 3
+| Plan | Task Name     | Status | Duration | Commit     |
+|------|---------------|--------|----------|------------|
+| 05   | Checkout UI   | ✅     | ~15 min  | mno7890    |
+
+**Wave 3 test results:** All passing ✅
+
+### Failure row format (if any task fails)
+| Plan | Task Name         | Status | Duration | Commit  | Error |
+|------|-------------------|--------|----------|---------|-------|
+| 02   | Create product model | ❌  | ~4 min   | n/a     | Verify failed: TypeError ... |
+
+## Phase summary
+- Total tasks: 5
+- Total commits: 5
+- Elapsed: ~51 min
+- Test results: All passing
+- Status: Phase [N] complete ✅
+```

package/.mindforge/governance/GOVERNANCE-CONFIG.md

@@ -0,0 +1,17 @@
+# MindForge Governance Configuration
+
+## Tier policy
+- Tier 1: low-risk documentation or isolated code cleanup
+- Tier 2: broader product or operational changes
+- Tier 3: security, privacy, auth, secrets, payments, compliance, or emergency
+
+## Enforcement rules
+- Tier 3 signals have higher priority than file-count heuristics
+- Compliance gates are blocking
+- Integration failures are non-fatal unless they prevent a required approval or
+  compliance decision from being observed
+
+## Record locations
+- Approval files: `.planning/approvals/`
+- Audit archive: `.planning/audit-archive/`
+- Milestones: `.planning/milestones/`

package/.mindforge/governance/approval-workflow.md

@@ -0,0 +1,37 @@
+# MindForge Governance — Approval Workflow
+
+## Purpose
+Define the human approval process for Tier 2 peer review, Tier 3
+ security/compliance review, and emergency override handling.
+
+## Approval sources
+Approvals are represented as files in `.planning/approvals/`. Commands must list
+ only `status: pending` approval requests by default.
+
+## Identity model
+Current approver identity is derived from `git config user.email` or `$USER`.
+This is convenient but spoofable. For higher-assurance environments, integrate
+ the approval flow with your IdP or SCM identity provider.
+
+## Standard workflow
+1. Classifier determines tier
+2. Create approval file with reason, scope, diff summary, and expiry time
+3. Notify configured approvers
+4. Record approval or rejection
+5. On rejection, create a fix task that carries the rejection reason forward
+6. Re-request approval only after the rejection reason has been addressed
+
+## Expiry and SLA handling
+Expiry processing is session-dependent. If no MindForge session is active, an
+ expired approval will be detected the next time the approval command runs.
+
+Use config-driven values from `INTEGRATIONS-CONFIG.md`:
+- `TIER2_APPROVERS`
+- `TIER3_APPROVERS`
+- `EMERGENCY_APPROVERS`
+- SLA and expiry hour settings
+
+## Emergency override
+Emergency approval requires the `--emergency` flag and an approver identity that
+ appears in `EMERGENCY_APPROVERS`. Log the approver identity and rationale in
+ AUDIT. Emergency override bypass is never implicit.

package/.mindforge/governance/change-classifier.md

@@ -0,0 +1,63 @@
+# MindForge Governance — Change Classifier
+
+## Purpose
+Assign each change a governance tier before execution and again before release.
+Tier 3 signals always override lower-risk heuristics.
+
+## Trigger points
+- Before each plan executes
+- Before PR or merge request creation
+- Before emergency override requests are processed
+
+## Tier model
+
+| Tier | Meaning | Approval requirement |
+|---|---|---|
+| 1 | Low-risk documentation or isolated refactor | none |
+| 2 | Broad change, cross-cutting impact, or moderate operational risk | peer approval |
+| 3 | Security, privacy, auth, payment, secrets, or compliance-sensitive | security/compliance approval |
+
+## Step 1 — Base heuristics
+- More than 10 files or more than 300 lines changed defaults to Tier 2
+- Infra, deployment, or schema changes default to at least Tier 2
+- File count is only a signal; it never downgrades a Tier 3 match
+
+## Step 2 — Apply Tier 3 rules first
+Tier 3 uses three independent signals. Any one match makes the change Tier 3.
+
+### Signal A — File path patterns
+Security-critical directories and files:
+`auth/`, `security/`, `payment/`, `billing/`, `privacy/`, `crypto/`, `secrets/`
+
+Security-critical names:
+`login.ts`, `logout.ts`, `token.ts`, `password.ts`, `credentials.ts`,
+`session.ts`, `oauth.ts`, `jwt.ts`, `hash.ts`, `encrypt.ts`, `stripe.ts`,
+`payment.ts`, `billing.ts`, `pii.ts`, `consent.ts`
+
+### Signal B — Code content patterns
+Scan the actual diff content, not only filenames, for patterns such as:
+`bcrypt`, `argon2`, `jwt.sign`, `jwt.verify`, `jose.sign`, `jose.verify`,
+`stripe.`, `paypal.`, `createCipheriv`, `createDecipheriv`, `crypto.subtle`,
+`hashPassword`, `verifyPassword`, `encrypt(`, `decrypt(`, `role.*permission`,
+`hasPermission`, `SET ROLE`, `GRANT`
+
+This protects against security-critical code being added to innocuous filenames
+ like `src/utils/helper.ts`.
+
+### Signal C — AUDIT history patterns
+If the current phase has a recent HIGH or CRITICAL `security_finding`, the next
+ change in that phase is elevated to Tier 3 automatically.
+
+## Classification audit entry
+Record why the tier was selected:
+
+```json
+{
+  "event": "change_classified",
+  "tier": 3,
+  "classification_reason": "code pattern: jwt.sign found in src/utils/helper.ts",
+  "signals_checked": ["file_path", "code_content", "audit_history"],
+  "signal_triggered": "code_content",
+  "pattern_matched": "jwt.sign"
+}
+```

package/.mindforge/governance/compliance-gates.md

@@ -0,0 +1,31 @@
+# MindForge Governance — Compliance Gates
+
+## Purpose
+Apply non-bypassable release gates for secrets, approvals, and privacy controls.
+
+## Gate 1 — Required verification
+The plan's verify step and the project test suite must pass.
+
+## Gate 2 — Required approvals
+Tier 2 and Tier 3 changes must have approved, non-expired approval records.
+
+## Gate 3 — Secret detection
+No real secrets may enter the diff, audit log, or published docs.
+Override is not permitted.
+
+For tests that exercise secret detection, use clearly fake patterns that do not
+ match production secret regexes, for example `TEST_ONLY_FAKE_KEY_abc123`.
+
+## Gate 4 — GDPR/PII compliance check
+This gate runs independently of skill loading.
+
+Trigger if the diff adds fields or columns resembling:
+`email`, `phone`, `mobile`, `address`, `postcode`, `zip`, `ssn`, `dob`,
+`birth_date`, `first_name`, `last_name`, `national_id`, `passport`,
+`credit_card`, `bank_account`, `iban`, `bic`
+
+If triggered, verify `.planning/ARCHITECTURE.md` documents retention policy for
+ the relevant data. If retention is missing:
+- block completion
+- write `compliance_gate_failed` to AUDIT
+- require Tier 3 compliance approval for override