qwen-base 1.0.0

package/src/framework/tasks/groom.md

@@ -0,0 +1,157 @@
+<purpose>
+Structured weekly maintenance cycle. Walk through each workspace area, review with operator, enforce backlog time-based rules, graduate ready items, and log the groom.
+</purpose>
+
+<user-story>
+As an AI builder, I want a guided workspace maintenance session, so that my context documents stay current, my backlog items graduate when ready, and my workspace doesn't drift.
+</user-story>
+
+<when-to-use>
+- Weekly (on configured groom day)
+- When pulse reports overdue grooming
+- When user says "base groom", "let's groom", "workspace maintenance"
+- Entry point routes here via /base:groom
+</when-to-use>
+
+<steps>
+
+<step name="assess_scope" priority="first">
+Determine what needs grooming.
+
+1. Read `.base/workspace.json` manifest
+2. Use `base_get_state` MCP tool (or read `.base/data/state.json`) for last groom dates per area
+3. Identify which areas are due for grooming (past their cadence)
+4. Sort by staleness (most overdue first)
+5. Present: "Groom session starting. {N} areas due for review: {list}. Estimated time: {N*5} minutes."
+
+**Wait for operator confirmation before proceeding.**
+</step>
+
+<step name="groom_projects">
+Review projects — the working memory for all active, blocked, and backlog work.
+
+**Data source:** `base_list_projects` MCP tool (reads projects.json)
+
+1. Use `base_list_projects` to pull all projects grouped by status
+2. Present summary: "{N} active, {N} blocked, {N} backlog, last updated {date}"
+3. For each active/blocked project: "Still active? Status changed? Next action current?"
+4. For each task (type=task): "Done? Still in progress? Blocked?"
+5. Archive completed items via `base_archive_project`
+6. Ask: "Anything new to add?"
+7. Updates via `base_update_project`
+
+**Backlog items (status=backlog) — enforce time-based rules:**
+1. For each backlog item, check `created_at` or `review_by` against thresholds:
+   - High priority: 7 days
+   - Medium priority: 14 days
+   - Low priority: 30 days
+2. Items past review-by → surface: "These items need a decision: {list}"
+3. Items past staleness (2x review-by) → "Auto-archiving: {list} (past {N} days without action)"
+4. Process operator decisions on each flagged item
+
+**Graduation check:**
+5. For each remaining backlog item, ask: "Ready to work on any of these?"
+6. If yes — update status from `backlog` to `in_progress` or `todo` via `base_update_project`
+7. If no — keep with updated review-by date
+
+**The graduation question is explicit every groom.** Items don't graduate silently — the operator decides.
+
+Voice-friendly: walk through one entry at a time, wait for response.
+</step>
+
+<step name="groom_directories">
+Review directory-type areas (projects/, clients/, tools/).
+
+For each directory area due for grooming:
+1. List contents
+2. Flag anything that looks orphaned or new since last groom
+3. Ask: "Anything to archive, delete, or reclassify?"
+4. Execute approved changes
+</step>
+
+<step name="groom_satellites">
+Review PAUL satellite project health.
+
+1. Read `.base/workspace.json` — collect all satellite entries where `groom_check: true`
+2. If no satellites have `groom_check: true` → skip this step silently
+3. For each eligible satellite:
+   a. Read its STATE.md at the path in `satellite.state` (relative to workspace root)
+   b. If STATE.md is missing or unreadable → note as "⚠️ {name}: STATE.md not found"
+   c. Get last activity timestamp:
+      - PRIMARY: read `satellite.last_activity` from workspace.json entry (ISO timestamp written by session-start hook from paul.json)
+      - FALLBACK: if `last_activity` not present in workspace.json, parse "Last activity" line from the satellite's STATE.md
+      - If neither available → note as "⚠️ {name}: cannot determine last activity"
+   d. Parse "Loop Position" section from STATE.md → extract PLAN/APPLY/UNIFY markers (✓ = done, ○ = pending)
+   e. Evaluate health criteria:
+      - **STUCK LOOP**: Loop shows PLAN ✓ APPLY ○ or PLAN ✓ APPLY ✓ UNIFY ○, AND last activity > 7 days ago
+      - **ABANDONED PHASE**: Last activity > 14 days ago AND milestone status is not COMPLETE
+      - **MILESTONE DRIFT**: Milestone marked COMPLETE, loop shows ○ ○ ○ (no new milestone started), AND last activity > 14 days ago
+4. Collect all issues across satellites
+5. If issues found: surface as:
+   ```
+   ⚠️ Satellite health issues:
+     - {satellite-name}: {issue type} (last active: {date})
+   ```
+6. If no issues: output single line "Satellites: all healthy ({N} checked)"
+
+**Report only — do NOT auto-fix.** Operator decides what to do with flagged satellites.
+</step>
+
+<step name="groom_system">
+Review system layer areas (hooks, commands, skills, CARL).
+
+1. Quick scan for obvious dead items
+2. Only flag if something clearly wrong
+3. Ask: "Any system changes to note?"
+4. If CARL hygiene is enabled (workspace.json `carl_hygiene.proactive: true`):
+   - Use `carl_v2_get_staged` to check for pending proposals in carl.json
+   - Use `carl_v2_list_domains` to check rule counts and spot-check `last_reviewed` dates for staleness
+   - Surface: "{N} staged proposals, {N} stale rules — run /base:carl-hygiene?"
+</step>
+
+<step name="log_groom">
+Record the groom session.
+
+1. Use `base_record_groom` MCP tool to update state.json (sets last_groom, advances next_groom_due)
+2. Use `base_update_drift` MCP tool to reset drift indicators
+3. Update area timestamps via `base_update_area` for each groomed area
+4. Write groom summary to `.base/grooming/{YYYY}-W{NN}.md`:
+   ```markdown
+   # Groom Summary — Week {NN}, {YYYY}
+
+   **Date:** {YYYY-MM-DD}
+   **Areas Reviewed:** {list}
+   **Drift Score:** {before} → 0
+
+   ## Changes
+   - {what changed}
+
+   ## Graduated from Backlog
+   - {item} → project (status: in_progress)
+
+   ## Archived / Killed
+   - {item} (reason)
+
+   ## Next Groom Due
+   {YYYY-MM-DD}
+   ```
+5. Report: "Groom complete. Drift score: 0. Next groom due: {date}."
+</step>
+
+</steps>
+
+<output>
+Updated workspace state. All due areas reviewed and current. Backlog time-based rules enforced. Ready items graduated. Groom summary logged.
+</output>
+
+<acceptance-criteria>
+- [ ] All overdue areas reviewed with operator
+- [ ] Projects updated via base_update_project / base_archive_project
+- [ ] Backlog time-based rules enforced (review-by, staleness)
+- [ ] Graduation question asked explicitly for backlog items
+- [ ] Graduated items updated from backlog → active status
+- [ ] state.json updated via base_record_groom
+- [ ] Groom summary written to grooming/ directory
+- [ ] Drift score reset to 0
+- [ ] Operator confirmed completion of each area
+</acceptance-criteria>

package/src/framework/tasks/history.md

@@ -0,0 +1,34 @@
+<purpose>
+Show workspace evolution over time. Read ROADMAP.md and present the chronological record of major workspace changes.
+</purpose>
+
+<user-story>
+As an AI builder, I want to see how my workspace has evolved, so that I can understand the trajectory and make informed decisions about future changes.
+</user-story>
+
+<when-to-use>
+- When user wants to review workspace history
+- Entry point routes here via /base:history
+</when-to-use>
+
+<steps>
+
+<step name="read_history" priority="first">
+Read and present workspace evolution.
+
+1. Read `.base/ROADMAP.md`
+2. Present chronologically: dates, what changed, why
+3. Include audit summaries and major groom outcomes
+4. If ROADMAP.md is empty or missing: "No history yet. Run /base:audit or /base:groom to start building your workspace timeline."
+</step>
+
+</steps>
+
+<output>
+Chronological workspace evolution timeline from ROADMAP.md.
+</output>
+
+<acceptance-criteria>
+- [ ] History presented in clear chronological format
+- [ ] Includes both audits and significant groom outcomes
+</acceptance-criteria>

package/src/framework/tasks/pulse.md

@@ -0,0 +1,83 @@
+<purpose>
+Daily workspace activation. Read workspace state, calculate drift, present health dashboard, prime the operator for their session.
+</purpose>
+
+<user-story>
+As an AI builder, I want a quick workspace health briefing at session start, so that I know what needs attention before I start working.
+</user-story>
+
+<when-to-use>
+- Start of every work session
+- When user says "base pulse", "what's the state of things", "workspace status"
+- When the pulse hook detects overdue grooming and injects a prompt
+- Entry point routes here via /base:pulse
+</when-to-use>
+
+<steps>
+
+<step name="read_state" priority="first">
+Read workspace state from `.base/workspace.json` and `.base/data/state.json`.
+
+1. Read `.base/workspace.json` — the manifest
+2. Read `.base/data/state.json` — the last known state
+3. If either file is missing, suggest running `/base:scaffold` first
+4. Extract: last groom date, groom cadence, area list, satellite list
+</step>
+
+<step name="calculate_drift">
+Check each tracked area against filesystem reality.
+
+For each area in the manifest:
+1. Check filesystem timestamps on tracked paths (stat modification dates)
+2. Compare against last groom date and area-specific cadence
+3. Calculate days overdue (0 if within cadence)
+4. Classify: Current (within cadence), Stale (1-2x overdue), Critical (2x+ overdue)
+
+For each registered satellite:
+1. Check if state file exists and is readable
+2. Extract last modification date
+3. Report current phase if parseable
+
+Calculate total drift score: sum of days-overdue across all areas, with Critical areas weighted 2x.
+</step>
+
+<step name="present_dashboard">
+Present the health dashboard to the operator.
+
+Format:
+```
+BASE Pulse — {workspace-name}
+Last Groom: {date} ({N} days ago)
+Drift Score: {score}
+
+| Area | Status | Age | Due |
+|------|--------|-----|-----|
+...
+
+Satellites:
+| Project | Phase | Last Active |
+...
+
+{Recommendation based on drift score}
+```
+
+Recommendations:
+- Drift 0: "Workspace is clean. Proceed normally."
+- Drift 1-7: "Minor drift in {areas}. Consider grooming this week."
+- Drift 8-14: "Moderate drift. Run /base:groom soon."
+- Drift 15+: "Critical drift. Workspace context is stale. Run /base:groom now."
+</step>
+
+</steps>
+
+<output>
+Health dashboard with drift score, area statuses, satellite health, and recommended next action.
+</output>
+
+<acceptance-criteria>
+- [ ] All manifest areas checked against filesystem reality
+- [ ] Drift score calculated correctly
+- [ ] Satellites checked for health
+- [ ] Clear recommendation provided based on drift level
+- [ ] Dashboard is concise and scannable (not a wall of text)
+</acceptance-criteria>

package/src/framework/tasks/scaffold.md

@@ -0,0 +1,389 @@
+<purpose>
+Set up BASE in a new or existing workspace. Scan the workspace, ask guided questions, generate the manifest, install hooks, initialize JSON data surfaces, and run operator profile setup. Optional --full mode adds CLAUDE.md audit and guided first groom.
+</purpose>
+
+<user-story>
+As an AI builder setting up my workspace, I want a guided scaffolding process that configures workspace management for my specific setup, so that I get maintenance automation without manual configuration.
+</user-story>
+
+<when-to-use>
+- First-time BASE installation in any workspace
+- When user says "base scaffold", "set up base", "initialize workspace management"
+- Entry point routes here via /base:scaffold
+- Use --full flag for batteries-included mode with CLAUDE.md audit + first groom
+</when-to-use>
+
+<context>
+@templates/workspace-json.md
+</context>
+
+<steps>
+
+<step name="detect_mode" priority="first">
+Determine scaffold mode.
+
+1. Check if user specified `--full` or mentioned wanting full setup
+2. If `--full`: CLAUDE.md audit + first groom will be offered after data layer setup
+3. If standard: data layer + hooks + operator profile
+4. Announce mode: "Running BASE scaffold ({standard|full} mode)."
+</step>
+
+<step name="scan_workspace">
+Scan the workspace and detect what exists.
+
+1. List top-level directories and files
+2. Detect common patterns:
+   - .base/data/ → existing JSON surfaces (v2 data model)
+   - ACTIVE.md, BACKLOG.md → legacy working memory (offer migration)
+   - projects/ → project tracking
+   - apps/ → satellite projects
+   - tools/ → tool management
+   - .qwen/ → system layer
+   - .mcp.json → MCP configuration
+   - content/ → content pipeline
+   - clients/ → client work
+   - obsidian/ → knowledge graph
+   - .carl/ → CARL dynamic rules
+3. Detect satellite projects (directories with .paul/ inside apps/)
+4. Present findings: "I found: {list of detected areas}"
+
+**Wait for confirmation before proceeding.**
+</step>
+
+<step name="guided_configuration">
+Walk through each detected area and configure tracking.
+
+For each detected area:
+1. "I found {area}. Want BASE to track this?"
+2. If yes: "What grooming cadence? (weekly/bi-weekly/monthly)"
+3. Auto-select audit strategy based on area type
+4. Allow override of defaults
+
+Also ask:
+- "What day do you prefer for weekly grooming?" (default: Friday)
+- "Any directories I should scan for satellite projects?" (default: apps/)
+- "Anything else you want tracked that I didn't detect?"
+
+Build workspace.json from responses using `@templates/workspace-json.md` schema.
+</step>
+
+<step name="install_data_layer">
+Create .base/ directory and generate JSON data surfaces.
+
+1. Create `.base/` directory structure:
+   ```
+   .base/
+   ├── workspace.json
+   ├── operator.json
+   ├── data/
+   │   ├── projects.json
+   │   ├── entities.json
+   │   ├── state.json
+   │   ├── psmm.json
+   │   └── staging.json
+   ├── hooks/
+   ├── base-mcp/
+   ├── grooming/
+   ├── schemas/
+   └── audits/
+   ```
+2. Write workspace.json from guided configuration (with surfaces and carl_hygiene sections)
+3. Initialize JSON data surfaces with empty starter content (don't overwrite existing):
+   - projects.json — unified active work + backlog tracking
+   - entities.json — people, organizations, systems
+   - state.json — workspace health, drift, groom tracking
+   - psmm.json — per-session meta memory
+   - staging.json — proposed changes staging
+4. Copy operator.json template (don't overwrite existing)
+5. Register any detected satellite projects in workspace.json
+6. Report: "BASE data layer installed. {N} areas tracked, {N} satellites registered, {N} data surfaces initialized."
+</step>
+
+<step name="install_hooks">
+Install and register BASE hooks.
+
+All hooks live in `.base/hooks/`. Session hooks are registered in `.qwen/settings.json`.
+
+**UserPromptSubmit hooks** (fire every prompt):
+- active-hook.py — active work surface injection
+- backlog-hook.py — backlog surface injection
+- base-pulse-check.py — drift detection + groom reminders
+- psmm-injector.py — per-session meta memory injection
+- operator.py — operator identity context injection
+
+**SessionStart hooks** (fire once when Claude Code starts a session):
+- satellite-detection.py — PAUL project auto-registration and state sync
+
+**On-demand hooks** (invoked by commands, not auto-registered):
+- apex-insights.py — workspace analytics (invoked by /apex:insights)
+
+---
+
+### ENVIRONMENT DETECTION (REQUIRED — do this FIRST)
+
+Hooks are shell commands that Claude Code executes. The python path AND file paths must work in the context where Claude Code is running. Detect the environment before wiring anything.
+
+**Step 1: Identify the platform.**
+Run these commands and read the results:
+```bash
+uname -a          # Linux vs Darwin vs MINGW/MSYS
+cat /proc/version 2>/dev/null  # WSL detection (contains "Microsoft" or "WSL")
+echo $TERM_PROGRAM  # vscode = VS Code integrated terminal
+```
+
+**Step 2: Classify the environment.**
+
+| Environment | Detection | Python Command | File Paths |
+|---|---|---|---|
+| **Native Linux** | `uname` = Linux, no WSL in /proc/version | `which python3` → use result | Native paths work |
+| **Native macOS** | `uname` = Darwin | `which python3` → use result (often /opt/homebrew/bin/python3) | Native paths work |
+| **WSL Terminal** (Claude Code CLI in WSL) | Linux + "Microsoft" in /proc/version + NOT in VS Code | `which python3` → use result (typically /usr/bin/python3) | WSL paths work (/home/user/...) |
+| **VS Code Extension (WSL Remote)** | Linux + WSL + TERM_PROGRAM=vscode | `which python3` → use result | WSL paths work (VS Code server runs inside WSL) |
+| **VS Code Extension (Windows-native)** | platform: win32 in Claude Code, OR `uname` returns MINGW/MSYS | See troubleshooting below | Windows paths required |
+| **Native Windows** | No WSL, Windows paths | `where python` or `py -3` | Windows paths (C:\...) |
+
+**Step 3: Handle the tricky cases.**
+
+**VS Code Extension on Windows accessing WSL files (PROBLEMATIC):**
+This is the hardest case. The VS Code extension runs on the Windows side but can see WSL files. Hooks execute in a Windows context, so:
+- `/usr/bin/python3` does NOT exist
+- `/home/user/...` paths are NOT valid
+- The Windows Python stub (`WindowsApps/python3.exe`) can't access WSL paths
+
+**Solutions (present to user in order of preference):**
+
+1. **Use VS Code Remote - WSL extension** (RECOMMENDED):
+   - Install the "WSL" extension in VS Code (by Microsoft)
+   - Open the workspace with "Reopen in WSL" or `code --remote wsl+Ubuntu /path/to/workspace`
+   - This runs the VS Code server inside WSL — all hooks fire natively
+   - All WSL paths and python work correctly
+
+2. **Use Claude Code CLI in WSL terminal instead of VS Code extension:**
+   - Open a WSL terminal, `cd` to workspace, run `claude`
+   - All hooks fire natively in WSL context
+   - Use VS Code separately for editing if needed
+
+3. **Wrapper script approach** (for advanced users who need both contexts):
+   Create a wrapper at a Windows-accessible location that detects context and routes:
+   ```bash
+   #!/bin/bash
+   # Detect if running in WSL or Windows and route accordingly
+   if [ -f /proc/version ] && grep -qi microsoft /proc/version; then
+     # Running in WSL context — use WSL python directly
+     /usr/bin/python3 "$@"
+   else
+     # Running in Windows context — invoke via wsl
+     wsl /usr/bin/python3 "$@"
+   fi
+   ```
+   This is fragile and NOT recommended for most users.
+
+**IMPORTANT: Ask the user which environment they use Claude Code in before proceeding.**
+If they use multiple environments (e.g., CLI in WSL + VS Code extension), explain the constraints and recommend option 1 (VS Code Remote WSL).
+
+---
+
+### HOOK REGISTRATION
+
+After environment is classified and python path is determined:
+
+For each auto-fire hook:
+1. Check if `.base/hooks/{hook}` exists
+2. If not: copy from `~/.qwen/base-framework/hooks/{hook}` (global install source)
+   - If `~/.qwen/base-framework/hooks/{hook}` doesn't exist either, warn:
+     "BASE framework not globally installed. Run `npx base-framework --global` first, then re-run scaffold."
+3. Check `.qwen/settings.json` for hook registration:
+   - **UserPromptSubmit hooks** → register in `UserPromptSubmit` array
+   - **SessionStart hooks** (satellite-detection.py) → register in `SessionStart` array
+4. If not registered: add the hook entry using detected python path + absolute path to `.base/hooks/{hook}`
+
+Hook registration format in settings.json:
+
+**CRITICAL: Each event type array contains objects with a `hooks` array inside — NOT flat command objects.** This is the Claude Code settings.json schema. Getting this wrong means hooks silently fail.
+
+```json
+{
+  "hooks": {
+    "UserPromptSubmit": [
+      {
+        "hooks": [
+          { "type": "command", "command": "{detected_python3_path} {absolute_path_to_workspace}/.base/hooks/active-hook.py" },
+          { "type": "command", "command": "{detected_python3_path} {absolute_path_to_workspace}/.base/hooks/backlog-hook.py" },
+          { "type": "command", "command": "{detected_python3_path} {absolute_path_to_workspace}/.base/hooks/base-pulse-check.py" },
+          { "type": "command", "command": "{detected_python3_path} {absolute_path_to_workspace}/.base/hooks/psmm-injector.py" },
+          { "type": "command", "command": "{detected_python3_path} {absolute_path_to_workspace}/.base/hooks/operator.py" }
+        ]
+      }
+    ],
+    "SessionStart": [
+      {
+        "hooks": [
+          { "type": "command", "command": "{detected_python3_path} {absolute_path_to_workspace}/.base/hooks/satellite-detection.py" }
+        ]
+      }
+    ]
+  }
+}
+```
+
+**Merge strategy:** If `.qwen/settings.json` already has a `hooks` section with existing entries (e.g., from CARL or other tools), APPEND BASE hooks into the existing `hooks` arrays inside the event type objects. Do NOT overwrite existing hooks. Read the file first, find the right array, add entries that aren't already present.
+
+---
+
+### HOOK TROUBLESHOOTING
+
+If hooks aren't firing after setup, diagnose with these checks:
+
+**Symptom: "operation blocked by hook" or "No such file"**
+- Python path is wrong for the current environment
+- Fix: re-detect python path for the environment Claude Code is running in
+
+**Symptom: Zero hooks fire (no CARL, no pulse, no calendar, nothing)**
+- Likely a platform mismatch (Windows paths vs WSL paths)
+- Check: `echo $PATH | tr ':' '\n' | grep python` — does python3 resolve?
+- Check: Can Claude Code's shell access the hook file? Run `cat {hook_path}` to verify
+
+**Symptom: Hooks fire in terminal but not in VS Code (or vice versa)**
+- Different Claude Code instances run in different contexts
+- VS Code extension (Windows-native) ≠ Claude Code CLI (WSL)
+- Fix: Use VS Code Remote WSL extension so both contexts are WSL
+
+**Symptom: "python3: command not found"**
+- Python3 is not on PATH in the hook execution context
+- Fix: Use absolute path to python3 (detect with `which python3`)
+
+**Diagnostic command (run this to check hook health):**
+```bash
+# Test each hook manually
+for hook in .base/hooks/*.py; do
+  echo "--- Testing: $hook ---"
+  {detected_python3_path} "$hook" 2>&1 | head -3
+  echo "Exit code: $?"
+done
+```
+
+Report: "Hooks installed ({N} auto-fire hooks registered, 1 on-demand hook available)."
+Report environment: "{environment_type} detected — hooks configured for {python_path}"
+</step>
+
+<step name="operator_profile">
+Guide the operator through their profile setup.
+
+1. Check if `.base/operator.json` has completed sections (check `completed_at` fields)
+2. If all sections completed: "Operator profile already configured. Want to update any section?"
+3. If incomplete or new:
+   - Walk through each section of operator.json:
+     a. **Deep Why** — 5 progressively deeper questions about motivation
+     b. **North Star** — One measurable metric with timeframe
+     c. **Key Values** — Rank-ordered values with concrete meanings (max 5)
+     d. **Elevator Pitch** — Layered pitch (1-4 floors)
+     e. **Surface Vision** — Concrete scenes of what success looks like
+   - Each section can be skipped: "Skip for now? You can complete it later."
+   - Write responses to operator.json after each section
+4. Report: "Operator profile {complete|partially complete}. The operator hook will inject your identity context every session."
+</step>
+
+<step name="install_mcp">
+Install and wire the MCP server from the global BASE package.
+
+The MCP server package lives globally at `~/.qwen/base-framework/packages/base-mcp/`. Scaffold copies it into the workspace and wires it up.
+
+1. Check if `.base/base-mcp/index.js` exists in the workspace
+2. If NOT present:
+   a. Check if global source exists at `~/.qwen/base-framework/packages/base-mcp/`
+   b. If global source missing: warn "BASE framework not globally installed. Run the installer first."
+   c. If global source exists: copy the entire `base-mcp/` directory to `.base/base-mcp/`
+   d. Run `npm install` in `.base/base-mcp/` to install dependencies
+3. If already present: check for `node_modules/`. If missing, run `npm install`.
+4. Check `.mcp.json` for base-mcp registration
+5. If not registered: add registration to `.mcp.json`:
+   ```json
+   { "base-mcp": { "type": "stdio", "command": "node", "args": ["./.base/base-mcp/index.js"] } }
+   ```
+6. Report: "BASE MCP server installed from global package and registered. Claude can now manage your data surfaces through tool calls."
+</step>
+
+<step name="full_mode_extras">
+**Full mode only.**
+
+**CLAUDE.md audit:**
+1. Check if CLAUDE.md exists
+2. If exists: "Want me to audit your CLAUDE.md against the CLAUDE.md Strategy?"
+   - If yes: route to `/base:audit-claude-md` (interactive, strategy-driven audit with CARL detection)
+3. If doesn't exist: "Want me to generate a CLAUDE.md from the strategy template?"
+   - If yes: use `@{~/.qwen/commands/qwen-base/templates/claudemd-template.md}` as starting point, fill from detected workspace structure
+
+**First groom:**
+1. "Want to run an initial groom to establish baseline? This reviews each area once."
+2. If yes: run /base:groom flow
+3. If no: "Baseline set from filesystem timestamps. First groom due: {date}."
+</step>
+
+<step name="post_scaffold_cleanup">
+Quick review and cleanup. Catches artifacts from path detection bugs, stale files, or misaligned structure.
+
+**Run these checks in order:**
+
+1. **Bogus directories** — Scan workspace root for directories that shouldn't exist:
+   - Any directory starting with `C:` or containing Windows-style paths (path detection bug)
+   - Any directory named `undefined`, `null`, or `[object Object]`
+   - If found: delete them and report what was removed
+
+2. **Sunset files** — Check for files that no longer belong:
+   - `.base/data/active.json` → sunset, replaced by projects.json
+   - `.base/data/backlog.json` → sunset, replaced by projects.json
+   - `ACTIVE.md` or `BACKLOG.md` at workspace root → legacy, offer to remove
+   - If found: report and offer to remove (don't auto-delete without confirmation)
+
+3. **Path sanity** — Verify all registered hooks use correct paths for the current environment:
+   - Read `.qwen/settings.json` hook entries
+   - Check each hook path exists on disk
+   - Check python path resolves (`which {python_path}`)
+   - If any path is invalid: flag it with the correct replacement
+
+4. **MCP sanity** — Verify MCP registration points to a real file:
+   - Read `.mcp.json`
+   - Check `.base/base-mcp/index.js` exists
+   - Check `node_modules/` exists in `.base/base-mcp/`
+   - If broken: fix it (copy from global, npm install, re-register)
+
+5. **Structure alignment** — Verify workspace matches CLAUDE.md's Where section:
+   - Read CLAUDE.md (if it exists) and extract the Where section
+   - Compare declared directories against what actually exists
+   - Flag any mismatches (declared but not created, or created but not declared)
+   - Don't auto-fix — just report for user awareness
+
+**Report:**
+```
+Post-scaffold cleanup:
+- Artifacts removed: {list or "none"}
+- Sunset files found: {list or "none"}
+- Hook paths: {all valid | N issues}
+- MCP: {healthy | issues}
+- Structure alignment: {aligned | N mismatches}
+```
+
+If everything is clean: "Workspace is clean. No artifacts, all paths valid, structure aligned."
+</step>
+
+</steps>
+
+<output>
+Fully configured BASE installation. Standard mode: data layer with JSON surfaces, hooks wired, operator profile setup, MCP registered, post-scaffold cleanup verified. Full mode: adds CLAUDE.md audit and guided first groom.
+</output>
+
+<acceptance-criteria>
+- [ ] Workspace scanned and areas detected
+- [ ] Operator confirmed tracked areas and cadences
+- [ ] .base/ directory created with all required files
+- [ ] workspace.json generated from guided configuration
+- [ ] JSON data surfaces initialized (projects, entities, state, psmm, staging)
+- [ ] operator.json created and profile questionnaire offered
+- [ ] Satellite projects detected and registered
+- [ ] All auto-fire hooks installed and registered in settings.json (UserPromptSubmit + SessionStart)
+- [ ] BASE MCP server wired in .mcp.json
+- [ ] Post-scaffold cleanup passed (no artifacts, valid paths, structure aligned)
+- [ ] (Full mode) CLAUDE.md audit offered
+- [ ] (Full mode) First groom offered
+- [ ] Operator informed of next groom date
+</acceptance-criteria>