@thedecipherist/mdd 1.7.1 → 1.8.0

package/README.md

@@ -943,6 +943,7 @@ All MDD artifacts live in one place:
 │       ├── agent-N-config.md
 │       └── agent-N-notes.md
 ├── .startup.md                   # Auto-generated session context (read by Claude on start)
+├── settings.json                 # Stack config — auto-populated by discovery, committed to git
 └── connections.md                # Pre-computed relationship map (path tree + Mermaid graph)
 ```
 
@@ -982,6 +983,91 @@ The auto-generated section above the `---` is rebuilt each time. The Notes secti
 
 ---
 
+## Stack Settings
+
+MDD creates `.mdd/settings.json` on first run. It controls which rule files load during audit and build phases, whether stack detection runs automatically, and a few other session behaviours.
+
+```json
+{
+  "autoDiscovery": true,
+  "stack": {
+    "language": ["typescript"],
+    "runtime": ["node"],
+    "frameworks": ["express"],
+    "orm": ["prisma"],
+    "auth": ["jwt"]
+  },
+  "overrides": {},
+  "phaseLogging": true,
+  "securityScan": false
+}
+```
+
+**`autoDiscovery: true` (default)** - MDD scans your manifest files once at session start and writes the detected stack into `settings.json`. It checks `package.json`, `go.mod`, `pyproject.toml`, and `composer.json`. The `stack` field is owned by discovery when this is on; `overrides` is always yours to edit.
+
+**`autoDiscovery: false`** - MDD reads `settings.json` as-is. You control the stack manually. Useful when your dependencies don't reflect the full picture (custom implementations, monorepos, unusual setups).
+
+**`overrides`** - Merged on top of `stack` at phase time. Add anything discovery misses - custom auth implementations, internal frameworks, or anything else that needs stack-specific rules.
+
+**`phaseLogging: true` (default)** - Controls whether MDD writes phase timing data via `mdd-log-phase.sh`. Set to `false` to suppress all phase log output.
+
+**`securityScan: false` (default)** - Enables the security rule generator. See the section below.
+
+### Stack-Specific Rule Files
+
+Once MDD knows your stack, it loads matching rule files at the start of each audit and build phase. These files live in `~/.claude/mdd/` alongside the other mode files and are installed with `mdd install`.
+
+```
+mdd-rules-typescript.md   # TypeScript-specific audit criteria and build checklists
+mdd-rules-express.md      # Express error handling, middleware, route validation rules
+mdd-rules-jwt.md          # JWT decode safety, expiry checks, secret validation
+mdd-rules-prisma.md       # Prisma query safety, transaction patterns, migration checks
+```
+
+Rules are additive - they append criteria to the existing phase rather than replacing anything. If a rule file doesn't exist for a stack entry, MDD warns once and continues. A misconfigured or missing `settings.json` never halts a session.
+
+### Security Rule Generator
+
+When `securityScan: true`, MDD runs a vulnerability scan against your declared stack and generates new audit rules for any patterns not already covered.
+
+```bash
+# Runs automatically during /mdd audit when securityScan: true
+# Or run directly:
+/mdd security-rules
+```
+
+**How it works:**
+
+1. Scans your dependencies using free tools - `npm audit` for Node projects, `osv-scanner` for multi-language, Snyk CLI free tier if installed. No API keys required.
+2. Reads all existing `mdd-rules-{stack}.md` files and extracts the current rule set.
+3. For each vulnerability found: checks whether the attack vector is already covered by an existing rule.
+4. If a gap exists: generates a new rule targeting the vulnerability *class*, not just the specific CVE. A rule about "prototype pollution via unvalidated query parameters" will catch future variants, not just the package version that triggered it.
+5. Appends new rules to the relevant `mdd-rules-{stack}.md` file with the source CVE as a reference.
+
+```
+Security rule generator - 2026-05-20
+
+Sources: npm audit, osv-scanner
+Findings reviewed: 12
+Already covered by existing rules: 9
+Gaps found: 3
+
+New rules generated:
+  mdd-rules-express.md  +2 rules
+    - [P2] Prototype pollution via req.query or req.body merge — use structuredClone() or
+      a safe merge utility. Reference: CVE-2024-29041
+    - [P2] res.redirect() called with user-supplied path without allowlist validation.
+      Reference: CVE-2024-43796
+
+  mdd-rules-jwt.md  +1 rule
+    - [P2] jwt.decode() used instead of jwt.verify() — decode skips signature check.
+      Reference: CVE-2022-21449 (class)
+```
+
+The gap check uses semantic comparison, not string matching, so rules generated in a previous run are not duplicated even if they use different wording. Each generated rule includes the CVE ID so you can trace where it came from and review or remove it if needed.
+
+---
+
 ## MDD Versioning
 
 Every file created by MDD is stamped with `mdd_version: N` in its frontmatter. This tracks which version of the workflow created or last updated each doc.

package/commands/mdd-audit.md

@@ -2,20 +2,30 @@
 
 Triggered when arguments start with `audit`.
 
-## Phase Logging
+### Stack Rule Loading (runs before Phase A1)
 
-At the **start** of every phase (before any action) and the **end** of every phase (after all actions), run the command below. Substitute `PHASE` with the phase identifier (e.g., `Phase A1`, `Phase A2`) and `EVENT` with `start` or `end`:
+After Step 0c in `mdd.md` sets `$MDD_STACK` and `$MDD_DIR`, load any matching stack rule files. This runs silently — no output unless a problem occurs.
 
-```bash
-bash -c 'D=$(date +%Y-%m-%d); T=$(date +%H:%M:%S); K=$(compressmcp --status 2>/dev/null | grep -oE "[0-9]+K/[0-9]+K" | head -1 || echo "-"); mkdir -p ~/.claude/mdd; printf "| %s | mdd-audit | PHASE | EVENT | %s | %s |\n" "$D" "$T" "$K" >> ~/.claude/mdd/log.md' 2>/dev/null || true
+```
+For each entry in $MDD_STACK:
+  If $MDD_DIR/mdd-rules-{entry}.md exists:
+    Read the file — append all rules found to the active audit criteria for this session
+  Else:
+    Emit one line: ⚠ No rule file for '{entry}' — skipping
+    Continue (never halt)
 ```
 
-Log file: `~/.claude/mdd/log.md`
+Stack rules are **additive only** — they extend the P1/P2/P3/P4 criteria lists used in Phase A3. They never replace or gate core audit behaviour.
 
----
+If `$MDD_SECURITY_SCAN` is `true`, run the security rule generator before loading rules:
+**Read `$MDD_DIR/mdd-security-rules.md` and follow its SECURITY RULES MODE instructions.** New rules it writes to `mdd-rules-{stack}.md` files will be picked up by the loading step above.
 
 ### Phase A1 — Scope
 
+```bash
+bash ~/.claude/hooks/mdd-log-phase.sh "mdd-audit" "Phase A1" start "$AUDIT_TARGET"
+```
+
 **Stale job detection (runs first):** Check `.mdd/jobs/` for any existing `audit-*/` folder.
 - If found: check whether a corresponding `audits/report-<date>.md` exists.
   - If yes: job completed but cleanup failed — delete the stale jobs folder and proceed normally.
@@ -106,8 +116,16 @@ Create `.mdd/jobs/audit-<date>/` and write `MANIFEST.md`:
 
 ---
 
+
+```bash
+bash ~/.claude/hooks/mdd-log-phase.sh "mdd-audit" "Phase A1" end "$AUDIT_TARGET"
+```
 ### Phase A2 — Per-Agent Config Setup
 
+```bash
+bash ~/.claude/hooks/mdd-log-phase.sh "mdd-audit" "Phase A2" start "$AUDIT_TARGET"
+```
+
 Main writes a shard file and config file for each agent into the job folder **before spawning anything**.
 
 **`shard-N.md`** — flat list of files assigned to this agent, extracted from the manifest. The agent uses this to know its scope without parsing the full manifest.
@@ -217,8 +235,16 @@ This config file contains no source code or findings — only paths and instruct
 
 ---
 
+
+```bash
+bash ~/.claude/hooks/mdd-log-phase.sh "mdd-audit" "Phase A2" end "$AUDIT_TARGET"
+```
 ### Phase A3 — Parallel Agent Execution
 
+```bash
+bash ~/.claude/hooks/mdd-log-phase.sh "mdd-audit" "Phase A3" start "$AUDIT_TARGET"
+```
+
 Main spawns all agents simultaneously. Each agent receives only the path to its config file.
 
 **Per-file loop (each agent follows exactly):**
@@ -264,8 +290,16 @@ shows no contracts apply to this file, write "(none)" — never omit the line en
 
 ---
 
+
+```bash
+bash ~/.claude/hooks/mdd-log-phase.sh "mdd-audit" "Phase A3" end "$AUDIT_TARGET"
+```
 ### Phase A4 — Convergence Check
 
+```bash
+bash ~/.claude/hooks/mdd-log-phase.sh "mdd-audit" "Phase A4" start "$AUDIT_TARGET"
+```
+
 After all agents signal completion, main reads `MANIFEST.md` and checks for any `[ ]` or `[~]` entries.
 
 - **`[ ]` entries:** agent never reached this file — re-run that agent's shard for remaining files
@@ -276,8 +310,16 @@ Audit does not advance to Phase A5 until every file is `[x]`, `[!]`, or `[e]`.
 
 ---
 
+
+```bash
+bash ~/.claude/hooks/mdd-log-phase.sh "mdd-audit" "Phase A4" end "$AUDIT_TARGET"
+```
 ### Phase A5 — Merge
 
+```bash
+bash ~/.claude/hooks/mdd-log-phase.sh "mdd-audit" "Phase A5" start "$AUDIT_TARGET"
+```
+
 Main merges all agent notes into the canonical output file:
 
 1. Read `MANIFEST.md` to get canonical file order
@@ -290,8 +332,16 @@ Merge is in manifest order, not agent completion order. The job folder is not to
 
 ---
 
+
+```bash
+bash ~/.claude/hooks/mdd-log-phase.sh "mdd-audit" "Phase A5" end "$AUDIT_TARGET"
+```
 ### Phase A6 — Analyze
 
+```bash
+bash ~/.claude/hooks/mdd-log-phase.sh "mdd-audit" "Phase A6" start "$AUDIT_TARGET"
+```
+
 Read `audits/notes-<date>.md` as the primary source. Produce `audits/report-<date>.md` — include `mdd_version: <current from mdd.md frontmatter>` as the first line of frontmatter.
 
 **Source code access in this phase:** Standard synthesis (items 1-8 below) uses only the notes file. The integration contract verification step that follows may re-read specific source files — that is the only exception, and it is mandatory.
@@ -338,8 +388,16 @@ The manifest is kept permanently in `audits/` — `[x]` vs `[!]` per file shows
 
 ---
 
+
+```bash
+bash ~/.claude/hooks/mdd-log-phase.sh "mdd-audit" "Phase A6" end "$AUDIT_TARGET"
+```
 ### Phase A7 — Present Findings + Fix
 
+```bash
+bash ~/.claude/hooks/mdd-log-phase.sh "mdd-audit" "Phase A7" start "$AUDIT_TARGET"
+```
+
 Show the user:
 ```
 🔍 MDD Audit Complete
@@ -385,8 +443,16 @@ Report progress per finding. Update documentation `known_issues` to remove fixed
 
 ---
 
+
+```bash
+bash ~/.claude/hooks/mdd-log-phase.sh "mdd-audit" "Phase A7" end "$AUDIT_TARGET"
+```
 ### Phase A8 — MDD Self-Review
 
+```bash
+bash ~/.claude/hooks/mdd-log-phase.sh "mdd-audit" "Phase A8" start "$AUDIT_TARGET"
+```
+
 Runs at the end of every audit, after fixes (or immediately after A7 if user chose not to fix now).
 
 **Opt-in gate — check before doing anything else:**
@@ -461,3 +527,12 @@ When running `/mdd audit <section>` with fewer than 10 resolved files, skip the
 **Integration context still applies in this mode.** Before starting the per-file loop, build `integration-context.md` into the job folder using the same logic as Phase A2 (read all `.mdd/docs/*.md`, extract contracts and feature-to-file mappings). Read `integration-context.md` at the start of the per-file loop and after every context clear — identical to the multi-agent startup sequence. The mandatory `Contracts:` line in notes applies here too.
 
 ---
+
+
+```bash
+bash ~/.claude/hooks/mdd-log-phase.sh "mdd-audit" "Phase A8" end "$AUDIT_TARGET"
+```
+
+```bash
+bash ~/.claude/hooks/mdd-log-phase.sh "mdd-audit" "-" "complete" "$AUDIT_TARGET"
+```

package/commands/mdd-bug.md

@@ -4,22 +4,12 @@
 
 The user is reporting a bug in an existing feature. Do NOT create a new feature doc.
 
-## Phase Logging
-
-At the **start** of every phase (before any action) and the **end** of every phase (after all actions), run the command below. Substitute `PHASE` with the phase identifier (e.g., `Phase B0`, `Phase B1`) and `EVENT` with `start` or `end`:
+### Phase B0 — Parse
 
 ```bash
-bash -c 'D=$(date +%Y-%m-%d); T=$(date +%H:%M:%S); K=$(compressmcp --status 2>/dev/null | grep -oE "[0-9]+K/[0-9]+K" | head -1 || echo "-"); mkdir -p ~/.claude/mdd; printf "| %s | mdd-bug | PHASE | EVENT | %s | %s |\n" "$D" "$T" "$K" >> ~/.claude/mdd/log.md' 2>/dev/null || true
+bash ~/.claude/hooks/mdd-log-phase.sh "mdd-bug" "Phase B0" start "$BUG_SLUG"
 ```
 
-Log file: `~/.claude/mdd/log.md`
-Instead: scan existing docs to identify which feature(s) own the broken behavior,
-document the bug in those docs, fix it, and mark it complete.
-
----
-
-### Phase B0 — Parse
-
 Extract the bug description from `$ARGUMENTS` by stripping the leading `bug ` prefix.
 Store as `$BUG_DESC`.
 
@@ -28,8 +18,16 @@ If `$BUG_DESC` is empty after stripping, ask the user:
 
 ---
 
+
+```bash
+bash ~/.claude/hooks/mdd-log-phase.sh "mdd-bug" "Phase B0" end "$BUG_SLUG"
+```
 ### Phase B1 — Triage
 
+```bash
+bash ~/.claude/hooks/mdd-log-phase.sh "mdd-bug" "Phase B1" start "$BUG_SLUG"
+```
+
 Read the frontmatter of every file in `.mdd/docs/` (excluding `archive/` subdirectory).
 Do **not** read doc bodies during triage — frontmatter only. You need: `id`, `title`, `tags`, `source_files`.
 
@@ -65,8 +63,16 @@ Run /mdd status to see the full project overview.
 
 ---
 
+
+```bash
+bash ~/.claude/hooks/mdd-log-phase.sh "mdd-bug" "Phase B1" end "$BUG_SLUG"
+```
 ### Phase B2 — Confirm Related Docs
 
+```bash
+bash ~/.claude/hooks/mdd-log-phase.sh "mdd-bug" "Phase B2" start "$BUG_SLUG"
+```
+
 Present the triage results and ask the user to confirm which docs the bug relates to.
 Always show the full doc list so the user can add docs that scored below the threshold.
 
@@ -88,8 +94,16 @@ Store the confirmed list as `$RELATED_DOCS`.
 
 ---
 
+
+```bash
+bash ~/.claude/hooks/mdd-log-phase.sh "mdd-bug" "Phase B2" end "$BUG_SLUG"
+```
 ### Phase B3 — Document the Bug
 
+```bash
+bash ~/.claude/hooks/mdd-log-phase.sh "mdd-bug" "Phase B3" start "$BUG_SLUG"
+```
+
 For each doc in `$RELATED_DOCS`:
 
 1. Read the full doc file
@@ -135,8 +149,16 @@ Store the bug IDs per doc as `$BUG_IDS` (map of doc-id → B-number) for use in
 
 ---
 
+
+```bash
+bash ~/.claude/hooks/mdd-log-phase.sh "mdd-bug" "Phase B3" end "$BUG_SLUG"
+```
 ### Phase B4 — Fix
 
+```bash
+bash ~/.claude/hooks/mdd-log-phase.sh "mdd-bug" "Phase B4" start "$BUG_SLUG"
+```
+
 Ask the user via AskUserQuestion how to proceed with the fix:
 
 ```
@@ -202,8 +224,16 @@ At the end of Phase 7, return here to Phase B5 to mark the bug complete in the d
 
 ---
 
+
+```bash
+bash ~/.claude/hooks/mdd-log-phase.sh "mdd-bug" "Phase B4" end "$BUG_SLUG"
+```
 ### Phase B5 — Mark Complete
 
+```bash
+bash ~/.claude/hooks/mdd-log-phase.sh "mdd-bug" "Phase B5" start "$BUG_SLUG"
+```
+
 After the fix is verified (via either Path A or Path B), update every doc in `$RELATED_DOCS`:
 
 For each doc, find the bug entry created in Phase B3 (use `$BUG_IDS` to find the right B-number):
@@ -258,3 +288,12 @@ Options:
 ```
 
 Follow the same commit/merge logic as BUILD MODE Phase 7d.
+
+
+```bash
+bash ~/.claude/hooks/mdd-log-phase.sh "mdd-bug" "Phase B5" end "$BUG_SLUG"
+```
+
+```bash
+bash ~/.claude/hooks/mdd-log-phase.sh "mdd-bug" "-" "complete" "$BUG_SLUG"
+```

package/commands/mdd-build.md

@@ -1,19 +1,27 @@
 ## BUILD MODE — New Feature Development
 
-## Phase Logging
+### Stack Rule Loading (runs before Phase 0)
 
-At the **start** of every phase (before any action) and the **end** of every phase (after all actions), run the command below. Substitute `PHASE` with the phase identifier (e.g., `Phase 0`, `Phase 1`) and `EVENT` with `start` or `end`:
+After Step 0c in `mdd.md` sets `$MDD_STACK` and `$MDD_DIR`, load any matching stack rule files. This runs silently — no output unless a problem occurs.
 
-```bash
-bash -c 'D=$(date +%Y-%m-%d); T=$(date +%H:%M:%S); K=$(compressmcp --status 2>/dev/null | grep -oE "[0-9]+K/[0-9]+K" | head -1 || echo "-"); mkdir -p ~/.claude/mdd; printf "| %s | mdd-build | PHASE | EVENT | %s | %s |\n" "$D" "$T" "$K" >> ~/.claude/mdd/log.md' 2>/dev/null || true
+```
+For each entry in $MDD_STACK:
+  If $MDD_DIR/mdd-rules-{entry}.md exists:
+    Read the file — append all build checklist items to Phase 6 implementation steps
+    Append any additional audit criteria to Phase 7b verification checks
+  Else:
+    Emit one line: ⚠ No rule file for '{entry}' — skipping
+    Continue (never halt)
 ```
 
-Log file: `~/.claude/mdd/log.md`
-
----
+Stack rules are **additive only** — they extend Phase 6 checklists and Phase 7b verification. They never replace or gate core build behaviour.
 
 ### Phase 0 — Branch Safety Check
 
+```bash
+bash ~/.claude/hooks/mdd-log-phase.sh "mdd-build" "Phase 0" start "$FEATURE_SLUG"
+```
+
 Before gathering any context, verify the current branch is compatible with the requested feature.
 
 ```bash
@@ -75,8 +83,16 @@ What would you like to do?
 - Report: "Aborted. Commit your current work, merge `<branch-name>` to main, then re-run `/mdd $ARGUMENTS` on a fresh branch."
 - Stop.
 
+
+```bash
+bash ~/.claude/hooks/mdd-log-phase.sh "mdd-build" "Phase 0" end "$FEATURE_SLUG"
+```
 ### Phase 1 — Understand the Feature
 
+```bash
+bash ~/.claude/hooks/mdd-log-phase.sh "mdd-build" "Phase 1" start "$FEATURE_SLUG"
+```
+
 Read the user's description: **$ARGUMENTS**
 
 Before writing anything, gather context using **3 parallel Explore agents**. Launch all three simultaneously — do not wait for one before starting the others:
@@ -111,8 +127,16 @@ Then ask the user targeted questions using AskUserQuestion. Ask ALL relevant que
 
 Wait for all answers before proceeding.
 
+
+```bash
+bash ~/.claude/hooks/mdd-log-phase.sh "mdd-build" "Phase 1" end "$FEATURE_SLUG"
+```
 ### Phase 2 — Data Flow & Impact Analysis
 
+```bash
+bash ~/.claude/hooks/mdd-log-phase.sh "mdd-build" "Phase 2" start "$FEATURE_SLUG"
+```
+
 **Skip condition:** If `.mdd/docs/` has no existing files AND `src/` has fewer than 5 source files, skip this phase entirely and note: "Greenfield detected — skipping data flow analysis." Then jump to Phase 3.
 
 Otherwise, use the answers from Phase 1 (depends_on, endpoints, models) to identify which existing files to read. Do NOT scan blindly — read only what the feature will touch or extend.
@@ -176,8 +200,16 @@ Ask the user: **"Proceed with documentation? (yes / adjust scope based on findin
 
 **This gate is mandatory.** Do not proceed to Phase 3 until the user confirms. If consistency issues were found, discuss whether to fix them as part of this feature or track them as pre-existing known issues first.
 
+
+```bash
+bash ~/.claude/hooks/mdd-log-phase.sh "mdd-build" "Phase 2" end "$FEATURE_SLUG"
+```
 ### Phase 3 — Write the MDD Documentation
 
+```bash
+bash ~/.claude/hooks/mdd-log-phase.sh "mdd-build" "Phase 3" start "$FEATURE_SLUG"
+```
+
 Create the feature documentation file at `.mdd/docs/<NN>-<feature-name>.md`.
 
 **Auto-number:** Read `.mdd/docs/` directory, find the highest existing number, increment by 1.
@@ -318,8 +350,16 @@ Show the completed doc to the user and ask: **"Does this accurately describe wha
 
 Wait for confirmation before proceeding.
 
+
+```bash
+bash ~/.claude/hooks/mdd-log-phase.sh "mdd-build" "Phase 3" end "$FEATURE_SLUG"
+```
 ### Phase 4 — Generate Test Skeletons
 
+```bash
+bash ~/.claude/hooks/mdd-log-phase.sh "mdd-build" "Phase 4" start "$FEATURE_SLUG"
+```
+
 Read the documentation file created in Phase 3. From the endpoints, business rules, and edge cases documented, generate test skeletons.
 
 **Skeleton template (unit):**
@@ -382,8 +422,16 @@ That's the point — they're the finish line.
 
 ---
 
+
+```bash
+bash ~/.claude/hooks/mdd-log-phase.sh "mdd-build" "Phase 4" end "$FEATURE_SLUG"
+```
 ### Phase 4b — Red Gate (mandatory)
 
+```bash
+bash ~/.claude/hooks/mdd-log-phase.sh "mdd-build" "Phase 4b" start "$FEATURE_SLUG"
+```
+
 **No skip condition.** This phase runs after every skeleton generation, every time.
 
 Run ONLY the new test file(s) — not the full suite:
@@ -422,8 +470,16 @@ If any test passes unexpectedly and the fix isn't trivial, ask the user:
    Proceed with fix? (yes / adjust differently / stop)
 ```
 
+
+```bash
+bash ~/.claude/hooks/mdd-log-phase.sh "mdd-build" "Phase 4b" end "$FEATURE_SLUG"
+```
 ### Phase 5 — Present the Build Plan
 
+```bash
+bash ~/.claude/hooks/mdd-log-phase.sh "mdd-build" "Phase 5" start "$FEATURE_SLUG"
+```
+
 **Auto-detect feature size** before choosing plan format:
 
 - **Simple** — fewer than 3 new files, no API routes, no database: use flat steps (block overhead not warranted)
@@ -525,8 +581,16 @@ Ready to build? (yes / modify plan / stop here)
 
 Wait for user confirmation.
 
+
+```bash
+bash ~/.claude/hooks/mdd-log-phase.sh "mdd-build" "Phase 5" end "$FEATURE_SLUG"
+```
 ### Phase 6 — Implement (Test-Driven)
 
+```bash
+bash ~/.claude/hooks/mdd-log-phase.sh "mdd-build" "Phase 6" start "$FEATURE_SLUG"
+```
+
 #### Step 6a — Layered execution
 
 Execute blocks in dependency layer order (Layer 1 → 2 → 3 → 4). Within the same layer, blocks marked `Runs in: parallel agents (2)` run simultaneously. Blocks marked `Runs in: main conversation` run sequentially.
@@ -606,8 +670,16 @@ Block 2 (Services):   ✅ — 8/8 tests passing, no regressions
 Block 3 (Wiring):     🔄 in progress...
 ```
 
+
+```bash
+bash ~/.claude/hooks/mdd-log-phase.sh "mdd-build" "Phase 6" end "$FEATURE_SLUG"
+```
 ### Phase 7 — Verify + Report
 
+```bash
+bash ~/.claude/hooks/mdd-log-phase.sh "mdd-build" "Phase 7" start "$FEATURE_SLUG"
+```
+
 #### Phase 7a — Quality Gates
 
 ```bash
@@ -802,3 +874,12 @@ Changes: <N files changed, N insertions, N deletions> (from git diff --stat)
 Report: "Skipped. Branch `feat/<feature-name>` — run `/commit` and then merge when ready."
 
 ---
+
+
+```bash
+bash ~/.claude/hooks/mdd-log-phase.sh "mdd-build" "Phase 7" end "$FEATURE_SLUG"
+```
+
+```bash
+bash ~/.claude/hooks/mdd-log-phase.sh "mdd-build" "-" "complete" "$FEATURE_SLUG"
+```