fix(discuss): enforce depends_on frontmatter in multi-milestone CONTEXT.md (#507)

The multi-milestone discussion flow writes CONTEXT.md files for each
milestone but never adds depends_on YAML frontmatter. The QUEUE.md
documents the dependency chain, but the auto-mode state machine reads
dependencies from CONTEXT.md frontmatter only — not from QUEUE.md.

Without frontmatter, milestones execute in filesystem order regardless
of their actual dependency chain, causing out-of-order execution.

Fix: Added MANDATORY depends_on documentation to both discuss.md
(Phase 2, after primary milestone) and queue.md (output section).
Instructs the LLM to write frontmatter with the exact milestone IDs
from the dependency chain confirmed during the milestone split gate.

Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-authored-by: TÂCHES <afromanguy@me.com>

src/resources/extensions/gsd/prompts/discuss.md

@@ -215,6 +215,20 @@ Once the user confirms the milestone split:
 5. Write a full `CONTEXT.md` for the primary milestone (the one discussed in depth).
 6. Write a `ROADMAP.md` for **only the primary milestone** — detail-planning later milestones now is waste because the codebase will change. Include requirement coverage and a milestone definition of done.
 
+#### MANDATORY: depends_on Frontmatter in CONTEXT.md
+
+Every CONTEXT.md for a milestone that depends on other milestones MUST have YAML frontmatter with `depends_on`. The auto-mode state machine reads this field to determine execution order — without it, milestones may execute out of order or in parallel when they shouldn't.
+
+```yaml
+---
+depends_on: [M001, M002]
+---
+
+# M003: Title
+```
+
+If a milestone has no dependencies, omit the frontmatter. The dependency chain from the milestone confirmation gate MUST be reflected in each CONTEXT.md frontmatter. Do NOT rely on QUEUE.md or PROJECT.md for dependency tracking — the state machine only reads CONTEXT.md frontmatter.
+
 #### Phase 3: Sequential readiness gate for remaining milestones
 
 For each remaining milestone **one at a time, in sequence**, use `ask_user_questions` to assess readiness. Present three options:

src/resources/extensions/gsd/prompts/queue.md

@@ -82,7 +82,13 @@ Determine where the new milestones should go in the overall sequence. Consider d
 Once the user is satisfied, in a single pass for **each** new milestone (starting from {{nextId}}):
 
 1. `mkdir -p .gsd/milestones/<ID>/slices`
-2. Write `.gsd/milestones/<ID>/<ID>-CONTEXT.md` — use the **Context** output template below. Capture intent, scope, risks, constraints, integration points, and relevant requirements. Mark the status as "Queued — pending auto-mode execution."
+2. Write `.gsd/milestones/<ID>/<ID>-CONTEXT.md` — use the **Context** output template below. Capture intent, scope, risks, constraints, integration points, and relevant requirements. Mark the status as "Queued — pending auto-mode execution." **If this milestone depends on other milestones, add YAML frontmatter with `depends_on`:**
+   ```yaml
+   ---
+   depends_on: [M001, M002]
+   ---
+   ```
+   The auto-mode state machine reads this field to enforce execution order. Without it, milestones may execute out of order. List the exact milestone IDs (including any suffix like `-0zjrg0`) from the dependency chain discussed with the user.
 
 Then, after all milestone directories and context files are written: