@bhargavvc/sdd-cc 1.30.1 → 1.42.3

package/sdd/references/thinking-partner.md

@@ -0,0 +1,96 @@
+# Thinking Partner Integration
+
+Conditional extended thinking at workflow decision points. Activates when `features.thinking_partner: true` in `.planning/config.json` (default: false).
+
+---
+
+## Tradeoff Detection Signals
+
+The thinking partner activates when developer responses contain specific signals indicating competing priorities:
+
+**Keyword signals:**
+- "or" / "versus" / "vs" connecting two approaches
+- "tradeoff" / "trade-off" / "tradeoffs"
+- "on one hand" / "on the other hand"
+- "pros and cons"
+- "not sure between" / "torn between"
+
+**Structural signals:**
+- Developer lists 2+ competing options
+- Developer asks "which is better" or "what would you recommend"
+- Developer reverses a previous decision ("actually, maybe we should...")
+
+**When NOT to activate:**
+- Developer has already made a clear choice
+- The "or" is rhetorical or trivial (e.g., "tabs or spaces" — use project convention)
+- Simple yes/no questions
+- Developer explicitly asks to move on
+
+---
+
+## Integration Points
+
+### 1. Discuss Phase — Tradeoff Deep-Dive
+
+**When:** During `discuss_areas` step, after a developer answer reveals competing priorities.
+
+**What:** Pause the normal question flow and offer a brief structured analysis:
+```
+I notice competing priorities here — {X} optimizes for {A} while {Y} optimizes for {B}.
+
+Want me to think through the tradeoffs before we decide?
+[Yes, analyze tradeoffs] / [No, I've decided]
+```
+
+If yes, provide a brief (3-5 bullet) analysis covering:
+- What each approach optimizes for
+- What each approach sacrifices
+- Which aligns better with the project's stated goals (from PROJECT.md)
+- A recommendation with reasoning
+
+Then return to the normal discussion flow.
+
+### 2. Plan Phase — Architectural Decision Analysis
+
+**When:** During step 11 (Handle Checker Return), when the plan-checker flags issues containing architectural tradeoff keywords.
+
+**What:** Before sending to the revision loop, analyze the architectural decision:
+```
+The plan-checker flagged an architectural tradeoff: {issue description}
+
+Brief analysis:
+- Option A: {approach} — {pros/cons}
+- Option B: {approach} — {pros/cons}
+- Recommendation: {choice} because {reasoning aligned with phase goals}
+
+Apply this recommendation to the revision? [Yes] / [No, let me decide]
+```
+
+### 3. Explore — Approach Comparison (requires #1729)
+
+**When:** During Socratic conversation, when multiple viable approaches emerge.
+**Note:** This integration point will be added when /sdd:explore (#1729) lands.
+
+---
+
+## Configuration
+
+```json
+{
+  "features": {
+    "thinking_partner": true
+  }
+}
+```
+
+Default: `false`. The thinking partner is opt-in because it adds latency to interactive workflows.
+
+---
+
+## Design Principles
+
+1. **Lightweight** — inline analysis, not a separate interactive session
+2. **Opt-in** — must be explicitly enabled, never activates by default
+3. **Skippable** — always offer "No, I've decided" to bypass
+4. **Brief** — 3-5 bullets max, not a full research report
+5. **Aligned** — recommendations reference PROJECT.md goals when available

package/sdd/references/ui-brand.md

@@ -108,15 +108,15 @@ Always at end of major completions.
 
 **{Identifier}: {Name}** — {one-line description}
 
-`{copy-paste command}`
+`/clear` then:
 
-<sub>`/clear` first → fresh context window</sub>
+`{copy-paste command}`
 
 ───────────────────────────────────────────────────────────────
 
 **Also available:**
-- `/sdd:alternative-1` — description
-- `/sdd:alternative-2` — description
+- `/sdd-alternative-1` — description
+- `/sdd-alternative-2` — description
 
 ───────────────────────────────────────────────────────────────
 ```

package/sdd/references/universal-anti-patterns.md

@@ -0,0 +1,63 @@
+# Universal Anti-Patterns
+
+Rules that apply to ALL workflows and agents. Individual workflows may have additional specific anti-patterns.
+
+---
+
+## Context Budget Rules
+
+1. **Never** read agent definition files (`agents/*.md`) -- `subagent_type` auto-loads them. Reading agent definitions into the orchestrator wastes context for content automatically injected into subagent sessions.
+2. **Never** inline large files into subagent prompts -- tell agents to read files from disk instead. Agents have their own context windows.
+3. **Read depth scales with context window** -- check `context_window` in `.planning/config.json`. At < 500000: read only frontmatter, status fields, or summaries. At >= 500000 (1M model): full body reads permitted when content is needed for inline decisions. See `references/context-budget.md` for the complete table.
+4. **Delegate** heavy work to subagents -- the orchestrator routes, it does not build, analyze, research, investigate, or verify.
+5. **Proactive pause warning**: If you have already consumed significant context (large file reads, multiple subagent results), warn the user: "Context budget is getting heavy. Consider checkpointing progress."
+
+## File Reading Rules
+
+6. **SUMMARY.md read depth scales with context window** -- at context_window < 500000: read frontmatter only from prior phase SUMMARYs. At >= 500000: full body reads permitted for direct-dependency phases. Transitive dependencies (2+ phases back) remain frontmatter-only regardless.
+7. **Never** read full PLAN.md files from other phases -- only current phase plans.
+8. **Never** read `.planning/logs/` files -- only the health workflow reads these.
+9. **Do not** re-read full file contents when frontmatter is sufficient -- frontmatter contains status, key_files, commits, and provides fields. Exception: at >= 500000, re-reading full body is acceptable when semantic content is needed.
+
+## Subagent Rules
+
+10. **NEVER** use non-SDD agent types (`general-purpose`, `Explore`, `Plan`, `Bash`, `feature-dev`, etc.) -- ALWAYS use `subagent_type: "sdd-{agent}"` (e.g., `sdd-phase-researcher`, `sdd-executor`, `sdd-planner`). SDD agents have project-aware prompts, audit logging, and workflow context. Generic agents bypass all of this.
+11. **Do not** re-litigate decisions that are already locked in CONTEXT.md (or PROJECT.md ## Context section) -- respect locked decisions unconditionally.
+
+## Questioning Anti-Patterns
+
+Reference: `references/questioning.md` for the full anti-pattern list.
+
+12. **Do not** walk through checklists -- checklist walking (asking items one by one from a list) is the #1 anti-pattern. Instead, use progressive depth: start broad, dig where interesting.
+13. **Do not** use corporate speak -- avoid jargon like "stakeholder alignment", "synergize", "deliverables". Use plain language.
+14. **Do not** apply premature constraints -- don't narrow the solution space before understanding the problem. Ask about the problem first, then constrain.
+
+## State Management Anti-Patterns
+
+15. **No direct Write/Edit to STATE.md or ROADMAP.md for mutations.** Always use `sdd-sdk query` for registered state/roadmap handlers (e.g. `state.update`, `state.advance-plan`, `roadmap.update-plan-progress`), or legacy `node …/sdd-tools.cjs` for CLI-only commands. Direct Write tool usage bypasses safe update logic and is unsafe in multi-session environments. Exception: first-time creation of STATE.md from template is allowed.
+
+## Behavioral Rules
+
+16. **Do not** create artifacts the user did not approve -- always confirm before writing new planning documents.
+17. **Do not** modify files outside the workflow's stated scope -- check the plan's files_modified list.
+18. **Do not** suggest multiple next actions without clear priority -- one primary suggestion, alternatives listed secondary.
+19. **Do not** use `git add .` or `git add -A` -- stage specific files only.
+20. **Do not** include sensitive information (API keys, passwords, tokens) in planning documents or commits.
+
+## Error Recovery Rules
+
+21. **Git lock detection**: Before any git operation, if it fails with "Unable to create lock file", check for stale `.git/index.lock` and advise the user to remove it (do not remove automatically).
+22. **Config fallback awareness**: Config loading returns `null` silently on invalid JSON. If your workflow depends on config values, check for null and warn the user: "config.json is invalid or missing -- running with defaults."
+23. **Partial state recovery**: If STATE.md references a phase directory that doesn't exist, do not proceed silently. Warn the user and suggest diagnosing the mismatch.
+
+## SDD-Specific Rules
+
+24. **Do not** check for `mode === 'auto'` or `mode === 'autonomous'` -- SDD uses `yolo` config flag. Check `yolo: true` for autonomous mode, absence or `false` for interactive mode.
+25. **Prefer `sdd-sdk query`** for orchestration when a handler exists; when shelling out to the legacy CLI, use **`sdd-tools.cjs`** (not `sdd-tools.js` or any other filename) — SDD ships the programmatic API as CommonJS for Node.js CLI compatibility.
+26. **Plan files MUST follow `{padded_phase}-{NN}-PLAN.md` pattern** (e.g., `01-01-PLAN.md`). Never use `PLAN-01.md`, `plan-01.md`, or any other variation -- sdd-tools detection depends on this exact pattern.
+27. **Do not start executing the next plan before writing the SUMMARY.md for the current plan** -- downstream plans may reference it via `@` includes.
+
+## iOS / Apple Platform Rules
+
+28. **NEVER use `Package.swift` + `.executableTarget` (or `.target`) as the primary build system for iOS apps.** SPM executable targets produce macOS CLI binaries, not iOS `.app` bundles. They cannot be installed on iOS devices or submitted to the App Store. Use XcodeGen (`project.yml` + `xcodegen generate`) to create a proper `.xcodeproj`. See `references/ios-scaffold.md` for the full pattern.
+29. **Verify SwiftUI API availability before use.** Many SwiftUI APIs require a specific minimum iOS version (e.g., `NavigationSplitView` is iOS 16+, `List(selection:)` with multi-select and `@Observable` require iOS 17). If a plan uses an API that exceeds the declared `IPHONEOS_DEPLOYMENT_TARGET`, raise the deployment target or add `#available` guards.

package/sdd/references/user-story-template.md

@@ -0,0 +1,58 @@
+# User Story Template (MVP Mode)
+
+> Used by `mvp-phase` workflow and `sdd-planner` agent when `MVP_MODE=true`. Defines the canonical "As a / I want to / So that" format and the rules for converting it into the `**Goal:**` line in ROADMAP.md.
+
+## Canonical format
+
+```
+As a [user role], I want to [capability], so that [outcome].
+```
+
+Three required components:
+
+| Slot | Question | Examples |
+|---|---|---|
+| `[user role]` | Who is the actor? | "new user", "admin", "signed-in customer", "API consumer" |
+| `[capability]` | What can they do? | "register and log in", "upload a CSV", "see my dashboard" |
+| `[outcome]` | Why does it matter? | "I can access my account", "I can bulk-import contacts", "I can see at a glance what needs attention" |
+
+All three must be present. Refuse to assemble a partial story.
+
+## How it lands in ROADMAP.md
+
+The full user story replaces the existing `**Goal:**` line in the phase section:
+
+**Before:**
+```
+### Phase 1: User Auth MVP
+**Goal:** Users can register and log in
+```
+
+**After:**
+```
+### Phase 1: User Auth MVP
+**Goal:** As a new user, I want to register and log in, so that I can access my dashboard.
+**Mode:** mvp
+```
+
+Two structural rules:
+1. The `**Goal:**` line stays on a single line (no line breaks inside the story). If the story is longer than ~120 chars, it should be split into multiple phases via SPIDR (see `spidr-splitting.md`).
+2. The `**Mode:** mvp` line is added immediately below `**Goal:**`. If `**Mode:**` already exists, it is replaced (not duplicated).
+
+## How it lands in PLAN.md
+
+The `sdd-planner` agent (with MVP_MODE=true) emits the user story as the first content under the phase header in `PLAN.md`:
+
+```markdown
+## Phase Goal
+
+**As a** new user, **I want to** register and log in, **so that** I can access my dashboard.
+
+## Acceptance Criteria
+- [ ] ...
+
+## MVP Slice Tasks
+...
+```
+
+Note the bold-keyword formatting (`**As a**`, `**I want to**`, `**so that**`) is for the PLAN.md emit only. The ROADMAP.md `**Goal:**` line uses prose form (the keywords are not bolded inside the goal line, since the goal is itself a single bolded label).

package/sdd/references/verification-overrides.md

@@ -0,0 +1,227 @@
+# Verification Overrides
+
+Mechanism for intentionally accepting must-have failures when the deviation is known and acceptable. Prevents verification loops on items that will never pass as originally specified.
+
+<override_format>
+
+## Override Format
+
+Overrides are declared in the VERIFICATION.md frontmatter under an `overrides:` key:
+
+```yaml
+---
+phase: 03-authentication
+verified: 2026-04-05T12:00:00Z
+status: passed
+score: 5/5
+overrides_applied: 2
+overrides:
+  - must_have: "OAuth2 PKCE flow implemented"
+    reason: "Using session-based auth instead — PKCE unnecessary for server-rendered app"
+    accepted_by: "dave"
+    accepted_at: "2026-04-04T15:30:00Z"
+  - must_have: "Rate limiting on login endpoint"
+    reason: "Deferred to Phase 5 (infrastructure) — tracked in ROADMAP.md"
+    accepted_by: "dave"
+    accepted_at: "2026-04-04T15:30:00Z"
+---
+```
+
+### Required Fields
+
+| Field | Type | Description |
+|-------|------|-------------|
+| `must_have` | string | The must-have truth, artifact description, or key link being overridden. Does not need to be an exact match — fuzzy matching applies. |
+| `reason` | string | Why this deviation is acceptable. Must be specific — not just "not needed". |
+| `accepted_by` | string | Who accepted the override (username or role). Required. |
+| `accepted_at` | string | ISO timestamp of when the override was accepted. Required. |
+
+</override_format>
+
+## When to Use
+
+Overrides apply when a phase intentionally deviated from the original plan during execution — for example, a requirement was descoped, an alternative approach was chosen, or a dependency changed.
+
+Without overrides, the verifier reports these as FAIL even though the deviation was intentional. Overrides let the developer mark specific items as `PASSED (override)` with a documented reason.
+
+Overrides are appropriate when:
+- A requirement changed after planning but ROADMAP.md hasn't been updated yet
+- An alternative implementation satisfies the intent but not the literal wording
+- A must-have is deferred to a later phase with explicit tracking
+- External constraints make the original must-have impossible or unnecessary
+
+## When NOT to Use
+
+Overrides are NOT appropriate when:
+- The implementation is simply incomplete — fix it instead
+- The must-have is unclear — clarify it instead
+- The developer wants to skip verification — that undermines the process
+- Multiple must-haves are failing for the same phase — if more than 2-3 items need overrides, revisit the plan instead of overriding in bulk
+
+<matching_rules>
+
+## Matching Rules
+
+Override matching uses **fuzzy matching**, not exact string comparison. This accommodates minor wording differences between how must-haves are phrased in ROADMAP.md, PLAN.md frontmatter, and the override entry.
+
+### Matching Algorithm
+
+1. **Normalize both strings:** case-insensitive comparison — lowercase both strings, strip punctuation, collapse whitespace
+2. **Token overlap:** split into words, compute intersection
+3. **Match threshold:** 80% token overlap in EITHER direction (override tokens found in must-have, OR must-have tokens found in override)
+4. **Key noun priority:** nouns and technical terms (file paths, component names, API endpoints) are weighted higher than common words
+
+### Examples
+
+| Must-Have | Override `must_have` | Match? | Reason |
+|-----------|---------------------|--------|--------|
+| "User can authenticate via OAuth2 PKCE" | "OAuth2 PKCE flow implemented" | Yes | Key terms `OAuth2` and `PKCE` overlap, 80% threshold met |
+| "Rate limiting on /api/auth/login" | "Rate limiting on login endpoint" | Yes | `rate limiting` + `login` overlap |
+| "Chat component renders messages" | "OAuth2 PKCE flow implemented" | No | No meaningful token overlap |
+| "src/components/Chat.tsx provides message list" | "Chat.tsx message list rendering" | Yes | `Chat.tsx` + `message` + `list` overlap |
+
+### Ambiguity Resolution
+
+If an override matches multiple must-haves, apply it to the **most specific match** (highest token overlap percentage). If still ambiguous, apply to the first match and log a warning.
+
+</matching_rules>
+
+<verifier_behavior>
+
+## Verifier Behavior with Overrides
+
+### Check Order
+
+The override check happens **before marking a must-have as FAIL**. The flow is:
+
+1. Evaluate must-have against codebase (Steps 3-5 of verification process)
+2. If evaluation result is FAIL or UNCERTAIN:
+   a. Check `overrides:` array in VERIFICATION.md frontmatter for a fuzzy match
+   b. If override found: mark as `PASSED (override)` instead of FAIL
+   c. If no override found: mark as FAIL as normal
+3. If evaluation result is PASS: mark as VERIFIED (overrides are irrelevant)
+
+### Output Format
+
+Overridden items appear with distinct status in all verification tables:
+
+```markdown
+| # | Truth | Status | Evidence |
+|---|-------|--------|----------|
+| 1 | User can authenticate | VERIFIED | OAuth session flow working |
+| 2 | OAuth2 PKCE flow | PASSED (override) | Override: Using session-based auth — accepted by dave on 2026-04-04 |
+| 3 | Chat renders messages | FAILED | Component returns placeholder |
+```
+
+The `PASSED (override)` status must be visually distinct from both `VERIFIED` and `FAILED`. In the evidence column, include the override reason and who accepted it.
+
+### Impact on Overall Status
+
+- `PASSED (override)` items count toward the passing score, not the failing score
+- A phase with all items either VERIFIED or PASSED (override) can have status `passed`
+- Overrides do NOT suppress `human_needed` items — those still require human testing
+
+### Frontmatter Score
+
+The score and override count in frontmatter reflect applied overrides:
+
+```yaml
+score: 5/5  # includes 2 overrides
+overrides_applied: 2
+```
+
+</verifier_behavior>
+
+<creating_overrides>
+
+## Creating Overrides
+
+### Interactive Override Suggestion
+
+When the verifier marks a must-have as FAIL and the failure looks intentional (e.g., alternative implementation exists, or the code explicitly handles the case differently), the verifier should suggest creating an override:
+
+```markdown
+### F-002: OAuth2 PKCE flow
+
+**Status:** FAILED
+**Evidence:** No PKCE implementation found. Session-based auth used instead.
+
+**This looks intentional.** The codebase uses session-based authentication which achieves the same goal differently. To accept this deviation, add an override to VERIFICATION.md frontmatter:
+
+```yaml
+overrides:
+  - must_have: "OAuth2 PKCE flow implemented"
+    reason: "Using session-based auth instead — PKCE unnecessary for server-rendered app"
+    accepted_by: "{your name}"
+    accepted_at: "{current ISO timestamp}"
+```
+
+Then re-run verification to apply.
+```
+
+### Override via sdd-tools
+
+Overrides can also be managed through the verification workflow:
+
+1. Run `/sdd:verify-work` — verification finds gaps
+2. Review gaps — determine which are intentional deviations
+3. Add override entries to VERIFICATION.md frontmatter
+4. Re-run `/sdd:verify-work` — overrides are applied, remaining gaps shown
+
+</creating_overrides>
+
+<override_lifecycle>
+
+## Override Lifecycle
+
+### During Re-verification
+
+When a phase is re-verified (e.g., after gap closure):
+- Existing overrides carry forward automatically
+- If the underlying code now satisfies the must-have, the override becomes unnecessary — mark as VERIFIED instead
+- Overrides are never removed automatically; they persist as documentation
+
+### At Milestone Completion
+
+During `/sdd:audit-milestone`, overrides are surfaced in the audit report:
+
+```
+### Verification Overrides ({count} across {phase_count} phases)
+
+| Phase | Must-Have | Reason | Accepted By |
+|-------|----------|--------|-------------|
+| 03 | OAuth2 PKCE | Session-based auth used instead | dave |
+```
+
+This gives the team visibility into all accepted deviations before closing the milestone.
+
+### Cleanup
+
+Stale overrides (where the must-have was later implemented or removed from ROADMAP.md) can be cleaned up during milestone completion. They are informational — leaving them causes no harm.
+
+</override_lifecycle>
+
+## Example VERIFICATION.md
+
+```markdown
+---
+phase: 03-api-layer
+verified: 2026-04-05T12:00:00Z
+status: passed
+score: 3/3
+overrides_applied: 1
+overrides:
+  - must_have: "paginated API responses"
+    reason: "Descoped — dataset under 100 items, pagination adds complexity without value"
+    accepted_by: "dave"
+    accepted_at: "2026-04-04T15:30:00Z"
+---
+
+## Phase 3: API Layer — Verification
+
+| # | Truth | Status | Evidence |
+|---|-------|--------|----------|
+| 1 | REST endpoints return JSON | VERIFIED | curl tests confirm |
+| 2 | Paginated API responses | PASSED (override) | Descoped — see override: dataset under 100 items |
+| 3 | Authentication middleware | VERIFIED | JWT validation working |
+```

package/sdd/references/verify-mvp-mode.md

@@ -0,0 +1,85 @@
+# Verify-Work — MVP Mode UAT Framing
+
+> Loaded by `verify-work` workflow and `sdd-verifier` agent only when the phase under verification has `mode: mvp` in ROADMAP.md. Reframes UAT generation from technical checks to user-flow walk-throughs.
+
+## Core rule
+
+**Show expected, ask if reality matches** — same philosophy as standard verify-work (from `workflows/verify-work.md`). The MVP-mode change is WHAT gets shown:
+
+- **Standard verify-work:** "The API endpoint at /users/register returns 201 with the new user's ID." → user confirms.
+- **MVP verify-work:** "Open the registration page. Fill in 'name', 'email', 'password'. Click Submit. You should see your dashboard with your name in the header." → user confirms.
+
+The user-flow form mirrors what a real user does: open, fill, click, see. No HTTP verbs, no JSON shapes, no error codes.
+
+## When this framing applies
+
+The framing fires when:
+- The phase under verification has `**Mode:** mvp` in ROADMAP.md (parsed via `sdd-sdk query roadmap.get-phase --pick mode`).
+- AND the phase has a user-story-formatted goal (set by `/sdd mvp-phase` per Phase 2): "As a [user role], I want to [capability], so that [outcome]."
+
+If the phase has `mode: mvp` but the goal is NOT in user-story format, the verifier surfaces this as a discrepancy and asks the user to run `/sdd mvp-phase` to reformat the goal — same pattern as the planner agent under MVP_MODE (per `references/planner-mvp-mode.md`).
+
+## Generated UAT script structure under MVP mode
+
+The UAT script generated by `verify-work` under MVP mode has THREE sections, in this exact order:
+
+### 1. User-flow walk-through (always first, always required)
+
+Derive ordered steps from the phase's user-story goal:
+
+1. The first step opens the entry point ("Open the app", "Navigate to /register", "Run `sdd mvp-phase 1`").
+2. Each subsequent step is one user action: fill, click, type, observe.
+3. The final step asserts the user-visible outcome from the `[outcome]` clause of the user story.
+
+Format each step as: "**Step N: [action]** — Expected: [what the user should see]". The user responds with one of:
+- `yes` / `y` / `next` / empty → step passes
+- Anything else → step is logged as an issue, and the script halts (do not proceed to step N+1 with a broken N).
+
+If ALL user-flow steps pass, advance to section 2. If any step fails, the verdict is FAIL — do not run technical checks.
+
+### 2. Technical checks (only if section 1 passes)
+
+After the user flow passes, run the technical checks that would normally run in non-MVP mode:
+- API endpoint schema verification (if the phase shipped APIs)
+- Error state behavior (4xx, 5xx codes; invalid input handling)
+- Edge cases (empty data, large data, concurrent requests if applicable)
+- Cross-browser / cross-runtime checks (if applicable)
+
+These are the same checks `verify-work` would run without MVP mode — just deferred until the user flow proves the slice actually works for a user.
+
+### 3. Coverage check (always last, always required)
+
+Verify that the user-story `[outcome]` clause is observably true in the codebase:
+- If the outcome is "I can access my dashboard", verify a dashboard route exists and renders for an authenticated user.
+- If the outcome is "I can bulk-import contacts", verify the import path produces persisted records.
+
+Coverage is a goal-backward check: "did this phase deliver what its user story promised?" — sourced from the existing `sdd-verifier` agent's goal-backward methodology, narrowed to the user story.
+
+## Anti-patterns to reject under MVP mode
+
+- **Lead with technical checks.** "Step 1: GET /api/users/me returns 200." Reject. The user does not see API endpoints. Reorder so a user action comes first.
+- **Schema-as-feature.** "User has a `name` field on the User model." Reject. The user does not see database fields. Express the same check as a user-visible outcome ("the user's name appears in the dashboard header").
+- **Skip user flow because the test passed.** The unit test passing in CI is not evidence that the user flow works. The user-flow walk-through is mandatory under MVP mode even when all unit tests are green.
+
+## Compatibility with existing verify-work philosophy
+
+The "show expected, ask if reality matches" model is preserved. The user still types `yes` / `next` / empty to advance. The UAT.md state file format is unchanged. Only the WHAT changes — under MVP mode, the "expected" is a user-visible outcome rather than a technical assertion.
+
+## Output: VERIFICATION.md changes under MVP mode
+
+The `sdd-verifier` agent produces `VERIFICATION.md`. Under MVP mode, the report adds a top-level "User Flow Coverage" section that maps each step of the user story to evidence in the codebase:
+
+```markdown
+## User Flow Coverage
+
+User story: «As a new user, I want to register and log in, so that I can access my dashboard.»
+
+| Step | Expected | Evidence | Status |
+|------|----------|----------|--------|
+| Register | Form at /register accepts name/email/password | src/app/register/page.tsx:12 (form component) | ✓ |
+| Submit | Persists user, redirects to /dashboard | src/api/register/route.ts:34 (db.insert + redirect) | ✓ |
+| See dashboard | Dashboard page renders, shows user's name | src/app/dashboard/page.tsx:8 (greeting line) | ✓ |
+| Outcome | "Access my dashboard" — user lands on a populated page | dashboard route + greeting both verified above | ✓ |
+```
+
+Standard technical-check sections of VERIFICATION.md remain (API verification, error handling, etc.) but are appended below "User Flow Coverage", not above.

package/sdd/references/workstream-flag.md

@@ -9,8 +9,55 @@ parallel milestone work by multiple Claude Code instances on the same codebase.
 
 1. `--ws <name>` flag (explicit, highest priority)
 2. `SDD_WORKSTREAM` environment variable (per-instance)
-3. `.planning/active-workstream` file (shared, last-writer-wins)
-4. `null` — flat mode (no workstreams)
+3. Session-scoped active workstream pointer in temp storage (per runtime session / terminal)
+4. `.planning/active-workstream` file (legacy shared fallback when no session key exists)
+5. `null` — flat mode (no workstreams)
+
+## Why session-scoped pointers exist
+
+The shared `.planning/active-workstream` file is fundamentally unsafe when multiple
+Claude/Codex instances are active on the same repo at the same time. One session can
+silently repoint another session's `STATE.md`, `ROADMAP.md`, and phase paths.
+
+SDD now prefers a session-scoped pointer keyed by runtime/session identity
+(`SDD_SESSION_KEY`, `CODEX_THREAD_ID`, `CLAUDE_CODE_SSE_PORT`, terminal session IDs,
+or the controlling TTY). This keeps concurrent sessions isolated while preserving
+legacy compatibility for runtimes that do not expose a stable session key.
+
+## Session Identity Resolution
+
+When SDD resolves the session-scoped pointer in step 3 above, it uses this order:
+
+1. Explicit runtime/session env vars such as `SDD_SESSION_KEY`, `CODEX_THREAD_ID`,
+   `CLAUDE_SESSION_ID`, `CLAUDE_CODE_SSE_PORT`, `OPENCODE_SESSION_ID`,
+   `GEMINI_SESSION_ID`, `CURSOR_SESSION_ID`, `WINDSURF_SESSION_ID`,
+   `TERM_SESSION_ID`, `WT_SESSION`, `TMUX_PANE`, and `ZELLIJ_SESSION_NAME`
+2. `TTY` or `SSH_TTY` if the shell/runtime already exposes the terminal path
+3. A single best-effort `tty` probe, but only when stdin is interactive
+
+If none of those produce a stable identity, SDD does not keep probing. It falls
+back directly to the legacy shared `.planning/active-workstream` file.
+
+This matters in headless or stripped environments: when stdin is already
+non-interactive, SDD intentionally skips shelling out to `tty` because that path
+cannot discover a stable session identity and only adds avoidable failures on the
+routing hot path.
+
+## Pointer Lifecycle
+
+Session-scoped pointers are intentionally lightweight and best-effort:
+
+- Clearing a workstream for one session removes only that session's pointer file
+- If that was the last pointer for the repo, SDD also removes the now-empty
+  per-project temp directory
+- If sibling session pointers still exist, the temp directory is left in place
+- When a pointer refers to a workstream directory that no longer exists, SDD
+  treats it as stale state: it removes that pointer file and resolves to `null`
+  until the session explicitly sets a new active workstream again
+
+SDD does not currently run a background garbage collector for historical temp
+directories. Cleanup is opportunistic at the pointer being cleared or self-healed,
+and broader temp hygiene is left to OS temp cleanup or future maintenance work.
 
 ## Routing Propagation
 
@@ -29,7 +76,7 @@ This ensures workstream scope chains automatically through the workflow:
 ├── config.json         # Shared
 ├── milestones/         # Shared
 ├── codebase/           # Shared
-├── active-workstream   # Points to current ws
+├── active-workstream   # Legacy shared fallback only
 └── workstreams/
     ├── feature-a/      # Workstream A
     │   ├── STATE.md
@@ -46,13 +93,19 @@ This ensures workstream scope chains automatically through the workflow:
 ## CLI Usage
 
 ```bash
-# All sdd-tools commands accept --ws
-node sdd-tools.cjs state json --ws feature-a
-node sdd-tools.cjs find-phase 3 --ws feature-b
+# All sdd-sdk query commands accept --ws
+sdd-sdk query state.json --ws feature-a
+sdd-sdk query find-phase 3 --ws feature-b
+
+# Session-local switching without --ws on every command
+SDD_SESSION_KEY=my-terminal-a sdd-sdk query workstream.set feature-a
+SDD_SESSION_KEY=my-terminal-a sdd-sdk query state.json
+SDD_SESSION_KEY=my-terminal-b sdd-sdk query workstream.set feature-b
+SDD_SESSION_KEY=my-terminal-b sdd-sdk query state.json
 
 # Workstream CRUD
-node sdd-tools.cjs workstream create <name>
-node sdd-tools.cjs workstream list
-node sdd-tools.cjs workstream status <name>
-node sdd-tools.cjs workstream complete <name>
+sdd-sdk query workstream.create <name>
+sdd-sdk query workstream.list
+sdd-sdk query workstream.status <name>
+sdd-sdk query workstream.complete <name>
 ```