qwen-base 1.0.0

package/src/commands/pulse.md

@@ -0,0 +1,33 @@
+---
+name: base:pulse
+description: Daily workspace health briefing
+allowed-tools: [Read, Glob, Grep, Bash]
+---
+
+<objective>
+Workspace health briefing — drift score, stale areas, overdue grooming, quick status.
+
+**When to use:** Session start, "what's the state of my workspace", daily check-in.
+</objective>
+
+<execution_context>
+@{~/.qwen/commands/qwen-base/tasks/pulse.md}
+@{~/.qwen/commands/qwen-base/context/base-principles.md}
+</execution_context>
+
+<context>
+$ARGUMENTS
+
+@.base/workspace.json
+@.base/data/state.json
+</context>
+
+<process>
+Follow task: @{~/.qwen/commands/qwen-base/tasks/pulse.md}
+</process>
+
+<success_criteria>
+- [ ] Drift score calculated and displayed
+- [ ] Stale areas identified
+- [ ] Groom cadence checked
+</success_criteria>

package/src/commands/scaffold.md

@@ -0,0 +1,33 @@
+---
+name: base:scaffold
+description: Set up BASE in a new workspace
+argument-hint: "[--full]"
+allowed-tools: [Read, Write, Edit, Glob, Bash, AskUserQuestion]
+---
+
+<objective>
+Guided workspace setup — scan, configure, install BASE infrastructure. Optional --full mode adds operational templates.
+
+**When to use:** First-time BASE installation, "set up base", "scaffold my workspace".
+</objective>
+
+<execution_context>
+@{~/.qwen/commands/qwen-base/tasks/scaffold.md}
+@{~/.qwen/commands/qwen-base/templates/workspace-json.md}
+@{~/.qwen/commands/qwen-base/templates/workspace-json.md}
+</execution_context>
+
+<context>
+$ARGUMENTS
+</context>
+
+<process>
+Follow task: @{~/.qwen/commands/qwen-base/tasks/scaffold.md}
+</process>
+
+<success_criteria>
+- [ ] .base/ directory structure created
+- [ ] workspace.json generated from scan
+- [ ] state.json initialized
+- [ ] Hooks and MCP servers installed (if --full)
+</success_criteria>

package/src/commands/status.md

@@ -0,0 +1,28 @@
+---
+name: base:status
+description: Quick workspace health check
+allowed-tools: [Read, Glob, Bash]
+---
+
+<objective>
+One-liner workspace health status — drift score and area summary.
+
+**When to use:** Quick check, "workspace status", "how's my workspace".
+</objective>
+
+<execution_context>
+@{~/.qwen/commands/qwen-base/tasks/status.md}
+</execution_context>
+
+<context>
+@.base/workspace.json
+@.base/data/state.json
+</context>
+
+<process>
+Follow task: @{~/.qwen/commands/qwen-base/tasks/status.md}
+</process>
+
+<success_criteria>
+- [ ] Health status displayed
+</success_criteria>

package/src/commands/surface-convert.md

@@ -0,0 +1,35 @@
+---
+name: base:surface-convert
+description: Convert a markdown file into a data surface
+argument-hint: "<file-path>"
+allowed-tools: [Read, Write, Edit, Glob, Bash, AskUserQuestion]
+---
+
+<objective>
+Convert an existing @-mentioned markdown file into a structured data surface. Analyzes structure, proposes schema, migrates content.
+
+**When to use:** User has a markdown file they want to convert to a structured surface.
+</objective>
+
+<execution_context>
+@{~/.qwen/commands/qwen-base/tasks/surface-convert.md}
+@.base/hooks/_template.py
+</execution_context>
+
+<context>
+$ARGUMENTS
+
+@.base/workspace.json
+</context>
+
+<process>
+Follow task: @{~/.qwen/commands/qwen-base/tasks/surface-convert.md}
+</process>
+
+<success_criteria>
+- [ ] .base/data/{name}.json created with migrated items
+- [ ] .base/hooks/{name}-hook.py created
+- [ ] workspace.json updated with surface registration
+- [ ] settings.json updated with hook entry
+- [ ] Original markdown file preserved
+</success_criteria>

package/src/commands/surface-create.md

@@ -0,0 +1,34 @@
+---
+name: base:surface-create
+description: Create a new data surface (guided)
+argument-hint: "[surface-name]"
+allowed-tools: [Read, Write, Edit, Glob, Bash, AskUserQuestion]
+---
+
+<objective>
+Create a new data surface through guided conversation. Generates JSON data file, injection hook, workspace.json registration, and settings.json hook entry.
+
+**When to use:** User wants to track something new as a structured data surface.
+</objective>
+
+<execution_context>
+@{~/.qwen/commands/qwen-base/tasks/surface-create.md}
+@.base/hooks/_template.py
+</execution_context>
+
+<context>
+$ARGUMENTS
+
+@.base/workspace.json
+</context>
+
+<process>
+Follow task: @{~/.qwen/commands/qwen-base/tasks/surface-create.md}
+</process>
+
+<success_criteria>
+- [ ] .base/data/{name}.json created
+- [ ] .base/hooks/{name}-hook.py created
+- [ ] workspace.json updated with surface registration
+- [ ] settings.json updated with hook entry
+</success_criteria>

package/src/commands/surface-list.md

@@ -0,0 +1,27 @@
+---
+name: base:surface-list
+description: Show all registered data surfaces
+allowed-tools: [Read, Bash]
+---
+
+<objective>
+Display all registered data surfaces with item counts and hook status.
+
+**When to use:** User wants to see what surfaces exist.
+</objective>
+
+<execution_context>
+@{~/.qwen/commands/qwen-base/tasks/surface-list.md}
+</execution_context>
+
+<context>
+@.base/workspace.json
+</context>
+
+<process>
+Follow task: @{~/.qwen/commands/qwen-base/tasks/surface-list.md}
+</process>
+
+<success_criteria>
+- [ ] All registered surfaces displayed with counts
+</success_criteria>

package/src/commands/weekly-domain.md

@@ -0,0 +1,34 @@
+---
+name: base:weekly-domain
+description: Create a custom domain phase for the weekly ritual
+allowed-tools: [Read, Write, Edit, Glob, Grep, Bash, AskUserQuestion]
+---
+
+<objective>
+Guided creation of a custom domain phase for /base:weekly. Walks the user through defining what to check, what tools to use, what questions to ask, and what output to produce.
+
+**When to use:** "Add a domain to my weekly", "create a weekly domain phase", "I want to track X in my weekly".
+</objective>
+
+<execution_context>
+@{~/.qwen/commands/qwen-base/tasks/weekly-domain-create.md}
+</execution_context>
+
+<context>
+$ARGUMENTS
+
+@.base/weekly.json
+</context>
+
+<process>
+Follow task: @{~/.qwen/commands/qwen-base/tasks/weekly-domain-create.md}
+</process>
+
+<success_criteria>
+- [ ] User described the domain area
+- [ ] Data sources identified (with tool discovery if needed)
+- [ ] Weekly questions defined
+- [ ] Position in weekly flow chosen
+- [ ] Output type specified
+- [ ] Domain phase config written to weekly.json
+</success_criteria>

package/src/commands/weekly.md

@@ -0,0 +1,39 @@
+---
+name: base:weekly
+description: Weekly review and planning ritual
+allowed-tools: [Read, Write, Edit, Glob, Grep, Bash, AskUserQuestion]
+---
+
+<objective>
+Guided weekly ritual — close the week, plan the next, run maintenance, lock in priorities with calendar events.
+
+**When to use:** Weekly planning, "run my weekly", "weekly review", "time for my weekly".
+</objective>
+
+<execution_context>
+@{~/.qwen/commands/qwen-base/tasks/weekly.md}
+@{~/.qwen/commands/qwen-base/context/base-principles.md}
+</execution_context>
+
+<context>
+$ARGUMENTS
+
+@.base/workspace.json
+@.base/data/state.json
+@.base/weekly.json
+</context>
+
+<process>
+Follow task: @{~/.qwen/commands/qwen-base/tasks/weekly.md}
+</process>
+
+<success_criteria>
+- [ ] Week reviewed (daily logs consumed if available)
+- [ ] Calendar audited with rules applied
+- [ ] Workspace groomed (drift score updated)
+- [ ] Priority stack set (outcome-based, aligned to north star)
+- [ ] Backlog triaged (overdue items processed)
+- [ ] Domain phases executed (if configured)
+- [ ] Blockers identified, follow-ups queued
+- [ ] Week committed — calendar events created, weekly.json entry logged
+</success_criteria>

package/src/framework/context/base-principles.md

@@ -0,0 +1,69 @@
+# BASE Principles
+
+## Core Laws
+
+1. **If it's not current, it's harmful.** Stale context documents feed AI bad information. Maintenance isn't optional.
+2. **Every file earns its place.** If you can't explain why it's here in 5 seconds, it moves or dies.
+3. **Archive > delete.** When in doubt, archive. You can always delete later. You can't un-delete.
+4. **The workspace is the product.** Treat it like production code, not a scratch pad.
+5. **Clean as you go.** The best time to file something correctly is when you create it. The second best time is now.
+6. **Scaffold generates manifest. Manifest drives everything.** One configuration point. No manual bookkeeping.
+7. **Tools register themselves.** PAUL projects auto-register with BASE. No human memory required.
+
+## Drift Score
+
+Drift is the gap between documented state and actual state. Measured in days-overdue across all tracked areas.
+
+- **0** — Everything current. Workspace is clean.
+- **1-7** — Minor drift. Normal during execution sprints. Fix at next groom.
+- **8-14** — Moderate drift. Context documents are likely misleading AI. Groom soon.
+- **15+** — Critical drift. Sessions are operating on stale context. Groom NOW.
+
+## Maintenance Cadence
+
+| What | Default Cadence | Override |
+|------|----------------|---------|
+| projects.json | Every session or weekly | workspace.json |
+| Project directory | Monthly | workspace.json |
+| Tools/MCP | Monthly | workspace.json |
+| System layer | Monthly | workspace.json |
+| Full audit | Quarterly or after major shifts | On demand |
+
+## Backlog Rules
+
+Items have time-based properties enforced by grooming:
+
+- **Added** — auto-set when item enters backlog
+- **Review-by** — priority-based: High=7d, Medium=14d, Low=30d
+- **Staleness** — 2x review-by threshold. Auto-archive if reached without action.
+
+During groom: items past review-by surface as "decide or kill." Items past staleness auto-archive with a note.
+
+## Graduation Flow
+
+Backlog items don't sit forever. They graduate to active when the operator is ready to work on them.
+
+```
+BACKLOG (status=backlog in projects.json)
+  → ACTIVE (status updated to in_progress/todo via base_update_project)
+  → DONE (archived via base_archive_project with outcome)
+```
+
+**TASKS vs PROJECTS:** A task is bounded — it has a finish line. "Extract .mcp.json secrets" is a task. "Build the CARL MCP server" might start as a task but could become a project if it grows. The operator decides during groom.
+
+**Graduation is never automatic.** The groom flow asks explicitly: "Ready to work on any backlog items?" The operator decides what graduates and where it lands.
+
+**Items can also move backward:** An active project that loses priority can return to backlog status. A project that stalls can move to DEFERRED. Nothing is permanent.
+
+## Scaffold Modes
+
+BASE scaffold operates in two modes:
+
+- **Standard** (`/base:scaffold`) — Data layer only. Creates `.base/` with workspace.json, `.base/data/state.json`, ROADMAP.md. Scans and tracks what exists. Framework-agnostic.
+- **Full** (`/base:scaffold --full`) — Data layer + projects.json + entities.json. Offers CLAUDE.md audit. The "batteries included" version for AI builders who want the full system.
+
+Standard mode works for any workspace. Full mode provides Chris's proven operational structure.
+
+## File Location
+
+BASE operates strictly out of `.base/`. All data (projects.json, entities.json, state.json, psmm.json) lives in `.base/data/`. Configuration (workspace.json) and documentation (ROADMAP.md) live in `.base/`. Data is accessed via MCP tools (`base_list_projects`, `base_add_project`, `base_update_project`, `base_get_state`, etc.). `.base/data/` is the canonical location for all structured data.

package/src/framework/frameworks/audit-strategies.md

@@ -0,0 +1,53 @@
+# Audit Strategies
+
+Reusable audit strategies that can be applied to any workspace area. The workspace manifest (`workspace.json`) maps areas to strategies. The audit command reads the manifest and applies the appropriate strategy to each area.
+
+## Strategies
+
+### staleness
+**Applies to:** Data files (projects.json, state.json, any tracked document)
+**What it does:** Check file modification timestamps against configured thresholds. Flag files past their groom cadence.
+**Config:**
+- `threshold_days` — days after which the file is considered stale
+**Output:** List of stale files with age, recommended action (update or review)
+
+### classify
+**Applies to:** Directories with lifecycle items (projects/, clients/)
+**What it does:** List all items in the directory. For each, present to operator for classification: active, archive, or delete. Check for planning docs, recent activity, git history.
+**Config:**
+- `states` — classification options (default: ["active", "archive", "delete"])
+- `archive_path` — where archived items go (default: `{path}/_archive/`)
+**Output:** Classification decisions, items moved to archive, items deleted
+
+### cross-reference
+**Applies to:** Tools/servers that have a config file mapping (e.g., MCP servers vs .mcp.json)
+**What it does:** Compare directory contents against a configuration file. Identify directories not referenced in config (orphaned) and config entries pointing to missing directories (broken).
+**Config:**
+- `config_file` — path to the configuration file to cross-reference
+**Output:** Orphaned items, broken references, recommendations
+
+### dead-code
+**Applies to:** System directories (hooks, commands, skills)
+**What it does:** Scan for files that appear unused — no references from other files, no recent invocations, no clear purpose. Presents findings for human decision.
+**Config:**
+- `reference_check` — whether to search for references in other files (default: true)
+**Output:** Potentially dead files with evidence, operator decides keep/delete
+
+### pipeline-status
+**Applies to:** Content pipelines, task queues, any workflow with stages
+**What it does:** Check items in each pipeline stage. Flag stuck items (in same stage too long), empty stages, bottlenecks.
+**Config:**
+- `stages` — ordered list of pipeline stages
+- `stuck_threshold_days` — days in one stage before flagging
+**Output:** Pipeline health report, stuck items, stage distribution
+
+## Extending Strategies
+
+Custom strategies can be added for workspace-specific needs. A strategy is defined by:
+1. A name (kebab-case)
+2. What it applies to (description)
+3. What it checks (logic)
+4. What config it needs (parameters)
+5. What it outputs (findings format)
+
+Add custom strategies to this file and reference them in `workspace.json`.

package/src/framework/frameworks/claude-config-alignment.md

@@ -0,0 +1,256 @@
+# Claude Config Alignment Strategy
+
+Standalone strategy for auditing `.qwen/` directory sprawl across a workspace. Discovers all `.qwen/` directories, catalogs their contents, classifies each item against a global/workspace/project hierarchy, and produces a remediation plan.
+
+Designed to be composed into any audit workflow that touches the system layer. The `/base:audit-claude` command references this strategy directly. The general `/base:audit` can compose it in when running system-layer checks.
+
+---
+
+## When to Use
+
+- During initial BASE setup on an existing workspace (lots of legacy `.qwen/` dirs)
+- As part of periodic workspace audits
+- After installing a new tool/skill globally and wanting to clean up project-level copies
+- When the user suspects their Claude Code config is fragmented
+
+---
+
+## Discovery Rules
+
+### What to scan
+- All directories named `.claude` under the workspace root
+- Recursively (projects may nest: `apps/foo/bar/.qwen/`)
+
+### What to skip
+- `node_modules/` — third-party packages may contain `.qwen/` dirs
+- `_archive/` — archived projects are frozen, don't audit
+- `.git/` — git internals
+- `vendor/`, `dist/`, `build/` — build artifacts
+
+### What to catalog per directory
+For each discovered `.qwen/` directory, record:
+- **Path** (relative to workspace root)
+- **hooks/** — list filenames
+- **commands/** — list subdirectories and files
+- **skills/** — list skill directories
+- **rules/** — list files
+- **settings.json** — exists? contents summary
+- **settings.local.json** — exists? contents summary
+- **Other files** — anything unexpected
+
+---
+
+## Git Boundary Awareness
+
+Understanding git boundaries is critical for correct classification. The scanner dataset includes `git_boundary` data for each directory.
+
+### How git boundaries affect visibility
+
+- **`has_own_git: true`** — This project has its own git root. It does NOT see the workspace root `.qwen/` or workspace `.mcp.json`. It only sees global `~/.qwen/` + its own `.qwen/`.
+- **`has_own_git: false`** — This project inherits the workspace root. It sees global `~/.qwen/` + workspace root `.qwen/` + its own `.qwen/`.
+
+### What this changes about classification
+
+If a project has its own git root and contains a hook that also exists in the workspace root `.qwen/`, that's **not a duplicate running twice** — the workspace root version is invisible to that project. Removing the local copy would leave the project with NO version of that hook.
+
+For own-git projects, the right framing is:
+- Does a current version exist in **global** `~/.qwen/`? If yes, the local copy is a true DUPLICATE (global is always visible).
+- Does a version only exist in **workspace root** `.qwen/`? Then the local copy is the project's ONLY access to that functionality. The right recommendation is PROMOTE_TO_GLOBAL — centralize it so all projects benefit, then clean up local copies.
+- Is the local copy an outdated version of something in a baseline? It's DIVERGED.
+
+---
+
+## Classification Rules
+
+Each item found in a project-level `.qwen/` must be classified into exactly one category. These rules define how.
+
+**Classification order:** TEMPLATE → ACCIDENTAL → DUPLICATE → DIVERGED → PROMOTE_TO_GLOBAL → STALE → GLOBAL_CANDIDATE → PROJECT_SPECIFIC
+
+### DUPLICATE — Exists in a visible baseline, safe to remove
+
+An item is a DUPLICATE if:
+- Its MD5 hash matches a file in a baseline the project can **actually see**
+- Global baseline (`~/.qwen/`): always checked — global is always visible
+- Workspace root baseline (`.qwen/`): only checked if `has_own_git: false`
+- A match against a **non-visible** baseline (workspace root for own-git projects) is NOT a duplicate — see PROMOTE_TO_GLOBAL
+- Common examples: hooks copied into project dirs that now run globally, skills that were installed globally after being copied locally
+
+**Verification before removal:**
+1. Confirm the global version is the current/active version (not the other way around)
+2. Confirm the project's `settings.json` doesn't reference the local copy with a relative path that would break if removed
+3. If the local copy has modifications not in the global version, flag as DIVERGED instead
+
+### DIVERGED — Local copy differs from global
+
+An item is DIVERGED if:
+- A version exists both locally and globally
+- The local copy has meaningful differences (not just whitespace or path variations)
+- Requires human decision: merge local changes into global? Keep local override? Or discard local changes?
+
+**Never auto-resolve diverged items. Always present both versions and ask.**
+
+### PROMOTE_TO_GLOBAL — Centralize to global, then clean up copies
+
+An item is PROMOTE_TO_GLOBAL if:
+- It exists in workspace root `.qwen/` (or the same pattern appears across multiple own-git projects) but NOT in global `~/.qwen/`
+- For own-git projects: a file matching a non-visible baseline (workspace root) is NOT a duplicate — it's a signal something should be centralized
+- When multiple projects have the same hook with the same MD5, that's strong evidence it belongs in global
+- This is the most valuable finding: "put this in global and stop copying it into every project"
+
+**PROMOTE_TO_GLOBAL is about removing the need for copies.** Once promoted, all project copies become true DUPLICATES (global is always visible) and can be safely removed.
+
+**Promotion is a suggestion, never automatic.** After promoting to global, the global `settings.json` must also register the hook or it won't fire.
+
+### GLOBAL_CANDIDATE — Should be promoted to global (single occurrence)
+
+An item is a GLOBAL_CANDIDATE if:
+- It exists in a project-level `.qwen/` but NOT in global
+- It serves a user-level purpose (not project-specific)
+- It would be useful across multiple projects
+- Examples: a custom skill the user installed in one project but uses everywhere, a hook that provides general utility
+
+**Promotion is a suggestion, never automatic.** Present the item, explain why it's a candidate, let operator decide.
+
+### PROJECT_SPECIFIC — Legitimately belongs here
+
+An item is PROJECT_SPECIFIC if:
+- It references project-local paths, configs, or conventions
+- It only makes sense in the context of this specific project
+- Examples: project-specific commands, MCP server lists tailored to that project's stack, hooks that interact with project-local files
+
+**These stay. Note them for reference but take no action.**
+
+### STALE — References things that no longer exist
+
+An item is STALE if:
+- settings.json references MCP servers that aren't in the current `.mcp.json` or global config
+- hooks reference scripts or tools that have been renamed or removed
+- Settings use old configuration patterns that Claude Code no longer supports
+- The `.qwen/` directory hasn't been modified in 60+ days AND the project itself shows no recent activity
+
+**Present specific evidence of staleness. Never assume — prove it.**
+
+### ACCIDENTAL — Clearly unintentional
+
+An item is ACCIDENTAL if:
+- Nested `.qwen/.qwen/` directories
+- Empty `.qwen/` directories (no files at all)
+- `.qwen/` inside directories that aren't projects (temp dirs, scratch folders)
+
+**Safe to remove, but still confirm with operator.**
+
+### TEMPLATE — Intentional scaffold template
+
+An item is TEMPLATE if:
+- It lives in a directory named `_template/`, `template/`, or `templates/`
+- It contains placeholder values (e.g., `{{PROJECT_NAME}}`)
+- It's designed to be copied, not used directly
+
+**Never modify templates. Note them and move on.**
+
+---
+
+## Settings Reconciliation
+
+Project-level `settings.json` and `settings.local.json` require special handling because they override global settings.
+
+### Check for
+1. **Hook definitions that duplicate global hooks** — If global `settings.json` already runs `base-pulse-check.py` on UserPromptSubmit, a project that also defines it runs it twice (or runs a stale version)
+2. **Stale MCP server references** — Server names change. Old lists reference servers that no longer exist
+3. **Empty hook arrays** — `"UserPromptSubmit": []` overrides global hooks with nothing, potentially breaking the user's setup
+4. **Permission overrides** — Project-level allow/deny that may conflict with or duplicate global permissions
+5. **enabledMcpjsonServers** — Lists that reference old server names
+
+### Critical safety rule
+**An empty hooks array `[]` in a project settings.json OVERRIDES the global hooks with nothing.** This is the most dangerous pattern — it silently disables all hooks for that project. Always flag this explicitly.
+
+---
+
+## Remediation Safety Protocol
+
+This is the most important section. `.qwen/` configuration is what makes Claude Code work. A broken config means a broken development environment. Every remediation action must follow these rules:
+
+### Before any change
+1. **Explain what will change and why** — No "cleaning up your config." Say exactly: "Removing `apps/casegate-v2/.qwen/hooks/carl-hook.py` because an identical version runs globally from `~/.qwen/hooks/dynamic-rules-loader.py`. The global hook already fires on every prompt in every project."
+2. **Show evidence** — Side-by-side comparison, file dates, path references
+3. **Wait for explicit approval** — Not "I'll go ahead and clean these up." Ask: "Approve this removal? [y/n]"
+
+### During changes
+4. **One category at a time** — Process all ACCIDENTAL items first (lowest risk), then DUPLICATES, then STALE, then DIVERGED. Save GLOBAL_CANDIDATE promotions for last.
+5. **Verify after each change** — After removing a hook, confirm the project's settings.json no longer references it. After removing a skill, confirm no commands reference it.
+6. **Never delete settings.json itself** — Even if everything in it is stale. The file's existence may matter. Clean its contents instead, or flag for operator to remove manually.
+
+### After all changes
+7. **Summary report** — What was changed, what was kept, what needs manual follow-up
+8. **Recommend a test** — "Open Claude Code in {project} and verify hooks fire correctly"
+
+### What this workflow NEVER does
+- Modify `~/.qwen/` (global config) without explicit promotion approval
+- Delete a `.qwen/` directory entirely (may have gitignore or settings implications)
+- Batch-delete without per-item confirmation
+- Assume a "messy" config is wrong — it may be working exactly as intended
+- Move files between directories (copy + verify + then remove original)
+
+---
+
+## Output Format
+
+The discovery phase produces an inventory. Present it as:
+
+```
+## .qwen/ Directory Inventory
+
+Found {N} .qwen/ directories ({N} excluding templates and root).
+
+### {relative/path/.qwen/}
+  hooks/: carl-hook.py, get-current-time-cst.py
+  settings.json: yes (hooks: 2 UserPromptSubmit)
+  settings.local.json: yes (MCP servers: 12)
+  skills/: ui-ux-pro-max/
+  commands/: (none)
+  Last modified: 2026-02-26
+
+  Classification:
+    - hooks/carl-hook.py → DUPLICATE (identical to ~/.qwen/hooks/dynamic-rules-loader.py)
+    - hooks/get-current-time-cst.py → DUPLICATE (identical to ~/.qwen/hooks/get-current-time-cst.sh)
+    - settings.json hooks → STALE (references local hook paths that would be removed)
+    - settings.local.json → PROJECT_SPECIFIC (MCP server list is project-tailored)
+    - skills/ui-ux-pro-max/ → DUPLICATE (exists at ~/.qwen/skills/ui-ux-pro-max/)
+```
+
+The remediation phase groups by action type and risk level:
+
+```
+## Remediation Plan
+
+### Safe Removals (ACCIDENTAL)
+1. apps/hunter-exotics/.qwen/.qwen/ — nested .claude dir (accidental)
+   Action: Delete entire nested directory
+   Risk: None
+
+### Duplicate Removals
+2. apps/casegate-v2/.qwen/hooks/carl-hook.py — identical to global
+   Action: Delete file
+   Risk: Low — must also clean settings.json hook reference
+
+(... etc, one per item ...)
+
+### Requires Decision (DIVERGED)
+5. apps/hunter-exotics/.qwen/settings.local.json — has project-specific MCP list
+   Local version: [12 servers including project-specific ones]
+   Global version: [different set]
+   Recommendation: Keep as PROJECT_SPECIFIC
+```
+
+---
+
+## Composability
+
+This strategy is a standalone reference document. It does not modify or depend on other strategy files. Any workflow can compose it in:
+
+- `/base:audit-claude` — reads this strategy directly as its framework
+- `/base:audit` — can reference this when auditing the system-layer area
+- `/base:groom` — can optionally flag `.qwen/` drift during system-layer groom step
+- Manual invocation — an operator can ask "audit my .claude dirs" and Claude reads this file
+
+No registration in workspace.json is required. No modification to audit-strategies.md is needed.