create-claude-cabinet 0.20.0 → 0.21.0

package/lib/omega-setup.js

@@ -121,6 +121,39 @@ function setupOmega() {
           results.push('Downloaded cross-encoder reranker model');
         }
       } catch { /* non-fatal */ }
+
+      // Ensure MCP server extra is installed (added in v0.21)
+      try {
+        execSync(`"${VENV_PYTHON}" -c "import mcp"`, { stdio: 'pipe' });
+      } catch {
+        console.log('  Installing MCP server support...');
+        try {
+          execSync(`"${VENV_PYTHON}" -m pip install --quiet "omega-memory[server]"`, {
+            stdio: 'pipe', timeout: 120000,
+          });
+          results.push('Installed MCP server support');
+        } catch { /* non-fatal */ }
+      }
+
+      // Ensure omega MCP server is registered in global settings
+      try {
+        const settingsPath = path.join(os.homedir(), '.claude', 'settings.json');
+        let settings = {};
+        if (fs.existsSync(settingsPath)) {
+          try { settings = JSON.parse(fs.readFileSync(settingsPath, 'utf8')); } catch { settings = {}; }
+        }
+        if (!settings.mcpServers) settings.mcpServers = {};
+        if (!settings.mcpServers.omega) {
+          settings.mcpServers.omega = {
+            command: path.join(VENV_DIR, 'bin', 'omega'),
+            args: ['serve'],
+          };
+          fs.mkdirSync(path.dirname(settingsPath), { recursive: true });
+          fs.writeFileSync(settingsPath, JSON.stringify(settings, null, 2) + '\n');
+          results.push('Registered omega MCP server (global settings)');
+        }
+      } catch { /* non-fatal */ }
+
       return results;
     } catch {
       // Venv is broken — nuke and rebuild (D5)
@@ -133,13 +166,13 @@ function setupOmega() {
   execSync(`"${pythonPath}" -m venv "${VENV_DIR}"`, { stdio: 'pipe' });
   results.push('Created venv at ~/.claude-cabinet/omega-venv/');
 
-  // 4. Install omega-memory
+  // 4. Install omega-memory (with MCP server support)
   console.log('  Installing omega-memory...');
-  execSync(`"${VENV_PYTHON}" -m pip install --quiet omega-memory`, {
+  execSync(`"${VENV_PYTHON}" -m pip install --quiet "omega-memory[server]"`, {
     stdio: 'pipe',
     timeout: 120000,
   });
-  results.push('Installed omega-memory');
+  results.push('Installed omega-memory (with MCP server)');
 
   // 5. Download embedding model at install time (D4)
   console.log('  Downloading embedding model...');
@@ -179,6 +212,41 @@ function setupOmega() {
     results.push('Omega hooks setup skipped (run `omega hooks setup` manually)');
   }
 
+  // 8. Register omega MCP server in global settings
+  //    This enables omega_store(), omega_query(), etc. as MCP tools
+  //    available to Claude Code directly (not just via hooks).
+  console.log('  Registering omega MCP server...');
+  try {
+    // Smoke-test: verify `omega serve` can start (requires mcp package)
+    execSync(
+      `echo '{}' | "${path.join(VENV_DIR, 'bin', 'omega')}" serve 2>&1 | head -1`,
+      { stdio: 'pipe', timeout: 10000 }
+    );
+
+    const settingsPath = path.join(os.homedir(), '.claude', 'settings.json');
+    let settings = {};
+    if (fs.existsSync(settingsPath)) {
+      try { settings = JSON.parse(fs.readFileSync(settingsPath, 'utf8')); } catch { settings = {}; }
+    }
+    if (!settings.mcpServers) settings.mcpServers = {};
+
+    // Only add if not already configured
+    if (!settings.mcpServers.omega) {
+      settings.mcpServers.omega = {
+        command: path.join(VENV_DIR, 'bin', 'omega'),
+        args: ['serve'],
+      };
+      fs.mkdirSync(path.dirname(settingsPath), { recursive: true });
+      fs.writeFileSync(settingsPath, JSON.stringify(settings, null, 2) + '\n');
+      results.push('Registered omega MCP server (global settings)');
+    } else {
+      results.push('Omega MCP server already registered');
+    }
+  } catch {
+    // Non-fatal — MCP tools are a convenience, hooks still work
+    results.push('Omega MCP server registration skipped (run `omega serve` manually to test)');
+  }
+
   return results;
 }
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-claude-cabinet",
-  "version": "0.20.0",
+  "version": "0.21.0",
   "description": "Claude Cabinet — opinionated process scaffolding for Claude Code projects",
   "bin": {
     "create-claude-cabinet": "bin/create-claude-cabinet.js"

package/templates/hooks/omega-memory-guard.sh

@@ -27,14 +27,12 @@ if [ -z "$FILE_PATH" ]; then
 fi
 
 # Only care about memory directory paths
-case "$FILE_PATH" in
-  *.claude/memory/*|*.claude/projects/*/memory/*)
-    ;;
-  *)
-    echo '{"decision":"allow"}'
-    exit 0
-    ;;
-esac
+# Note: case patterns with * don't cross / boundaries in some shells,
+# so we use [[ ]] substring matching for absolute path compatibility.
+if [[ "$FILE_PATH" != *"/.claude/memory/"* ]] && [[ "$FILE_PATH" != *"/.claude/projects/"*"/memory/"* ]]; then
+  echo '{"decision":"allow"}'
+  exit 0
+fi
 
 # Allow MEMORY.md index files (structural, not memory content)
 BASENAME=$(basename "$FILE_PATH")

package/templates/rules/memory-capture.md

@@ -56,3 +56,24 @@ verbally, or a constraint discovered through external research).
 Over-capturing degrades retrieval quality. The test: *"Would a future
 session benefit from knowing this?"* If yes, capture it. If it's just
 noise or ephemera, skip it.
+
+## Known Limitation: Auto-Memory System Prompt Conflict
+
+Claude Code's built-in auto-memory system prompt describes a file-based
+`.md` memory system (`/Users/<user>/.claude/projects/<project>/memory/`).
+When omega is active, this conflicts — the system prompt tells Claude to
+write `.md` files while CLAUDE.md and this rules file tell it to use
+omega. The system prompt's instructions are strong and may override
+project-level rules in some sessions.
+
+**Mitigations:**
+- The `omega-memory-guard` PreToolUse hook blocks flat markdown writes
+  when omega is available (structural enforcement, ~100% reliable)
+- This rules file and CLAUDE.md omega instructions provide prompt-level
+  guidance (~80% reliable)
+- If Claude creates a `.md` memory file despite these, the guard will
+  block it and redirect to `omega_store()`
+
+This is a platform limitation — the auto-memory system prompt cannot
+be suppressed from project configuration. The guard hook is the
+primary defense.

package/templates/scripts/pib-db-mcp-server.mjs

@@ -11,10 +11,53 @@ import { join, dirname } from 'node:path';
 import { fileURLToPath } from 'node:url';
 import { createRequire } from 'node:module';
 import { createInterface } from 'node:readline';
+import { existsSync, readFileSync, statSync } from 'node:fs';
 import * as lib from './pib-db-lib.mjs';
 
 const __dirname = dirname(fileURLToPath(import.meta.url));
-const DB_PATH = process.env.PIB_DB_PATH || join(process.cwd(), 'pib.db');
+
+// Resolve pib.db path, handling git worktrees where cwd may not contain
+// the canonical database. Worktrees have a .git *file* (not directory)
+// pointing to the main repo's .git/worktrees/<name>/ directory.
+function resolveDbPath() {
+  if (process.env.PIB_DB_PATH) return process.env.PIB_DB_PATH;
+
+  const cwd = process.cwd();
+  const localDb = join(cwd, 'pib.db');
+
+  // If local pib.db exists and is non-trivial (>8KB), use it
+  if (existsSync(localDb)) {
+    try {
+      const stats = statSync(localDb);
+      if (stats.size > 8192) return localDb;
+    } catch { /* fall through to worktree detection */ }
+  }
+
+  // Check if we're in a git worktree (.git is a file, not a directory)
+  const gitPath = join(cwd, '.git');
+  if (existsSync(gitPath)) {
+    try {
+      const stats = statSync(gitPath);
+      if (stats.isFile()) {
+        // .git file contains: "gitdir: /path/to/main/.git/worktrees/<name>"
+        const content = readFileSync(gitPath, 'utf-8').trim();
+        const match = content.match(/^gitdir:\s*(.+)/);
+        if (match) {
+          // Walk up from .git/worktrees/<name> to find the main repo
+          const gitdir = match[1];
+          const mainGitDir = join(gitdir, '..', '..');
+          const mainRepoDir = dirname(mainGitDir);
+          const mainDb = join(mainRepoDir, 'pib.db');
+          if (existsSync(mainDb)) return mainDb;
+        }
+      }
+    } catch { /* fall through to default */ }
+  }
+
+  return localDb;
+}
+
+const DB_PATH = resolveDbPath();
 
 // ---------------------------------------------------------------------------
 // SQLite setup

package/templates/scripts/skill-validator.sh

@@ -231,7 +231,7 @@ check_description() {
   # "When" component: the description must contain an explicit trigger
   # phrase. This is heuristic but catches the common cases of describing
   # only the skill's scope without saying when to invoke it.
-  local when_phrases='(Use when|Use at|Use after|Use before|Use during|Use to |Run when|Run at|Invoke when|Invoke during|Activated during|Activated when|Activates during|Activates when|Activate when|Trigger(s|ed)? (when|during|on)|Call when|Called during|Fires when)'
+  local when_phrases='(Use when|Use at|Use after|Use before|Use during|Use to |Run when|Run at|Invoke when|Invoke during|Activated during|Activated when|Activates during|Activates when|Activate(s|d)?(\s+\S+){0,4}\s+(when|during)|Trigger(s|ed)? (when|during|on)|Call when|Called during|Fires when)'
   if ! printf '%s' "$desc" | grep -qE "$when_phrases"; then
     fail "$file" "description-when" "no explicit trigger phrase" \
       "Add a 'when' component. Workflow skills: 'Use when...'. Cabinet members: 'Activated during audit/plan/execute...'. See $BEST_PRACTICES_DOC §Description."

package/templates/skills/cc-feedback/SKILL.md

@@ -63,27 +63,22 @@ mechanism:
 - This is the dogfood case — the project IS the upstream repo, so
   feedback goes directly into the local `feedback/` directory.
 
-**If linked** (not the source repo, but CC package resolves to a local
-directory — check if
-`node -e "console.log(require.resolve('create-claude-cabinet'))"` points
-to a local path rather than `node_modules`):
+**Everything else** (consuming projects, whether linked or not):
 
-- Write to the CC repo's `feedback/` directory
-- Filename: `[source-project]-[date]-[short-title].md`
-
-**If not linked**, check whether `gh` is available (`gh auth status`):
+Save to `~/.claude/cc-feedback-outbox.json` (create as `[]` if missing).
+Append entry with fields: `source`, `date`, `component`, `title`, `body`,
+`status: "pending"`, `delivered: false`.
 
-- **If `gh` works**, offer the choice:
-  > Send as a GitHub issue, or save locally?
-  > 1. GitHub issue (developer sees it directly)
-  > 2. Save locally
+The outbox is picked up by orient in the CC source repo next session
+and delivered to `feedback/`. This avoids dirtying the CC repo's working
+tree from consuming projects (which caused confusion when the linked
+direct-write path was used).
 
-  If GitHub: open issue on `orenmagid/claude-cabinet` with title
-  `Field feedback: [short title]` and label `field-feedback`.
+If `gh` is available (`gh auth status` succeeds), also offer:
+> Also send as a GitHub issue for faster visibility?
 
-- **If no `gh`**: save to `~/.claude/cc-feedback-outbox.json` (create
-  as `[]` if missing). Append entry with fields: `source`, `date`,
-  `component`, `title`, `body`, `status: "pending"`.
+If yes: open issue on `orenmagid/claude-cabinet` with title
+`Field feedback: [short title]` and label `field-feedback`.
 
 ### 4. Confirm
 

package/templates/skills/cc-publish/SKILL.md

@@ -79,6 +79,9 @@ With user confirmation:
 - Update `system-status.md` if it exists
 - Report the published version and npm URL
 
+**DO NOT stop here.** Step 6 is mandatory — the publish is incomplete
+until all local consumers are updated. Proceed to Step 6 immediately.
+
 ### 6. Update Local Consumers
 
 Read `~/.claude/cc-registry.json` for all registered CC projects. For
@@ -88,10 +91,12 @@ each project that is NOT the CC source repo itself:
 2. If it's older than the just-published version, update it:
    - `cd <path> && npx create-claude-cabinet@latest --yes`
    - Verify the install succeeded (`.ccrc.json` version matches)
-3. After a successful update, commit the CC-managed files in the consumer:
-   - `git -C <path> add .claude/ .mcp.json scripts/pib-db*.mjs scripts/pib-db-schema.sql scripts/*.cjs .ccrc.json`
-   - Commit with message: `chore: update claude-cabinet to v<version>`
+3. After a successful update, commit ONLY CC-managed files in the consumer:
+   - First: `git -C <path> reset HEAD -- .` (clear any pre-staged files —
+     the consumer may have project files staged from a prior session)
+   - Then: `git -C <path> add .claude/ .mcp.json scripts/pib-db*.mjs scripts/pib-db-schema.sql scripts/*.cjs .ccrc.json`
    - Only stage files that are actually modified (`git -C <path> diff --name-only` to check)
+   - Commit with message: `chore: update claude-cabinet to v<version>`
    - Do NOT push — leave that to the user
 4. Report which consumers were updated, committed, and which were already current
 

package/templates/skills/debrief/SKILL.md

@@ -291,6 +291,11 @@ is in a good state for next time.
 
 ### 8. Persist Work
 
+**Unmerged commits check:** Run `git log --oneline main..HEAD`. If
+non-empty, enumerate the commits and ask: merge to main now, keep the
+branch, or discard? This prevents orphan worktree branches that sit
+unmerged with no surface signal.
+
 Commit and push the session's changes. Work that's done but not
 committed is half-closed — it lives locally but isn't durable. Persist
 before recording lessons, so the commit captures code and doc changes
@@ -389,68 +394,26 @@ rarer than project-specific skills.
 
 ### 12. Cabinet Check (core)
 
-Silently reflect: is this project's expertise coverage still right
-for what it's actually doing?
-
-This is the anti-entropy mechanism for the cabinet. Without
-it, a project can adopt a framework, start handling sensitive data, or
-grow complex enough to need architectural review — and none of the
-relevant expertise ever activates because nobody ran `/seed`.
+Silently check: is this project's expertise coverage still right?
 
 **Two checks, both silent unless they find something:**
 
-**Check A — Uncovered technology.** Quickly scan what this session
-touched. Did the work involve a framework, library, data store, or
-infrastructure that isn't covered by any existing cabinet member? Compare
-against the cabinet members in `.claude/skills/cabinet-*/` and the
-merged committees (run `node scripts/resolve-committees.cjs`).
-
-Examples of what to catch:
-- Session used Mantine components but there's no framework-quality
-  cabinet member
-- Session wrote database queries but there's no data-integrity
-  cabinet member
-- Session built UI but accessibility isn't in any active committee
-
-**Check B — Dormant cabinet member that should be active.** Are there
-cabinet members installed in the project that aren't in any committee
-(check merged output from `node scripts/resolve-committees.cjs`), but based on the last few sessions, probably should be? A
-cabinet member sitting dormant while the project does exactly the kind of
-work it's designed to review is a waste.
-
-**Most sessions: nothing.** These checks should be completely silent
-when nothing is off. Don't mention cabinet members if everything is fine.
-
-**When there's a gap:** Explain it plainly — no jargon about
-"cabinet members" or "committees." Talk about what the project is missing
-in terms of what it would DO for them:
-
-> "You've been building UI for the last few sessions, but nothing is
-> checking whether it works well on phones or is usable for people
-> with accessibility needs. I can set that up so it gets checked
-> automatically when you run quality reviews. Want me to?"
-
-or:
-
-> "You're using Mantine a lot now. There's a specialist review that
-> checks whether you're getting the full value from it — catching
-> things like hand-rolling components that Mantine already provides.
-> Want me to turn that on?"
-
-or:
-
-> "This project has gotten complex enough that it might help to have
-> something watching whether the overall architecture still makes
-> sense as it grows. Want me to set that up?"
-
-If the user says yes, either:
-- Activate a dormant cabinet member (add it to `committees-project.yaml`)
-- Run `/seed` to build a new one
-- Install a Tier 3 cabinet member that isn't in the project yet
-
-If the user says no, move on. Don't re-suggest the same gap next
-session. Track declined suggestions in system-status.md or equivalent
-so you don't nag.
+**Check A — Uncovered technology.** Did this session touch a framework,
+library, or infrastructure not covered by any cabinet member? Compare
+against `.claude/skills/cabinet-*/` and merged committees
+(`node scripts/resolve-committees.cjs`).
+
+**Check B — Dormant member that should be active.** Are there installed
+cabinet members not in any committee that the recent work would benefit
+from?
+
+**Most sessions: nothing.** Silent when nothing is off.
+
+**When there's a gap:** Explain plainly what the project is missing
+in terms of what it would DO for them (no jargon about "cabinet
+members" or "committees"). If the user wants it, activate the member
+via `committees-project.yaml`, `/seed`, or Tier 3 install. Track
+declined suggestions so you don't re-suggest next session.
 
 ### 13. Capture Loose Ends (core)
 

package/templates/skills/debrief/phases/close-work.md

@@ -97,12 +97,23 @@ After closing actions, check the `feedback/` directory for field feedback
 files from consuming projects. For each file, evaluate whether this
 session's work addressed the friction described.
 
+**Trigger conditions** (check ALL, not just git-log matching):
+1. **Git-log matching:** Cross-reference feedback files against this
+   session's changed files and commit messages.
+2. **Project-name matching:** If any closed project's name or description
+   contains "feedback", "remediation", or "field feedback", explicitly
+   scan ALL feedback files and present them for resolution — the project
+   was likely created to address them.
+3. **Component matching:** If this session edited files in a component
+   mentioned by a feedback file (e.g., session edited `cc-publish/SKILL.md`
+   and a feedback file has `component: skills/cc-publish`), surface it.
+
 **How to check:**
 1. Scan `feedback/` for `.md` files (skip `.gitkeep`)
 2. For each file, read the `component` from frontmatter and the friction
    description
-3. Cross-reference against this session's git log and changed files —
-   did the session fix or address the reported friction?
+3. Apply all trigger conditions above — any match means the feedback
+   should be presented for resolution
 4. For each resolved item, present to the user:
    > "Field feedback resolved: [title] from [source] — [one-line summary
    > of what fixed it]. Delete the feedback file? (yes/no)"

package/templates/skills/execute/SKILL.md

@@ -195,11 +195,21 @@ Group the plan's implementation steps by logical file groups
 
 For each group:
 1. Make the changes
-2. **Checkpoint 2: File Group Review** — if cabinet members are active,
+2. **Post-change verification:**
+   - **After component extraction or file splitting:** Immediately run
+     the project's type checker (`tsc --noEmit`, `mypy`, `pyright`, etc.)
+     before writing any further code. Extraction frequently orphans
+     imports — the type checker catches this before it compounds.
+   - **Before using unfamiliar UI component props:** Read the component's
+     `.d.ts` file from `node_modules/<package>/` or check the type
+     definitions. Never guess prop names from memory of prior framework
+     versions — prop APIs change between major versions and guessing
+     wastes build cycles.
+3. **Checkpoint 2: File Group Review** — if cabinet members are active,
    spawn agents for ONLY cabinet members matching the changed files. Each
    receives the git diff for this file group + plan context. Same
    escalation rules as Checkpoint 1.
-3. If all continue, move to the next group
+4. If all continue, move to the next group
 
 File-group granularity keeps reviews focused. A cabinet member reviewing
 3 changed files gives better feedback than one reviewing 30.

package/templates/skills/orient/SKILL.md

@@ -76,6 +76,14 @@ The skeleton always does something reasonable when a phase file is absent.
 Phase files customize, not enable. Use `skip: true` when you actively
 don't want a phase to run — not even the default.
 
+**Phase separation principle:** Phases that both gather data and act on
+the results should use clear structural separation. Without it, the
+model tends to treat data-gathering as completion — running a query
+satisfies the "do something" impulse and the acting step gets skipped.
+Use numbered steps with explicit transitions: "1. Query X. 2. **Now
+act on the results above:** [specific action]." If the acting step is
+critical, mark it as `**BLOCKING**` — querying is not processing.
+
 ## Why This Matters
 
 If Claude Code starts a session without reading what happened last time,
@@ -133,6 +141,20 @@ sessions, and project-specific context.
   > ⚠ Found N unmigrated memory files in .claude/memory/.
   > Run: `python3 scripts/migrate-memory-to-omega.py --dry-run`
 
+- **Deployment method detection:** Check for deployment indicators and
+  surface the deploy command in the briefing so sessions don't default
+  to wrong deployment methods (e.g., `git push` when the project uses
+  `railway up`):
+  - `railway.toml` → Railway (`railway up --detach`)
+  - `fly.toml` → Fly.io (`fly deploy`)
+  - `vercel.json` or `.vercel/` → Vercel (`vercel --prod`)
+  - `netlify.toml` → Netlify (`netlify deploy --prod`)
+  - `.github/workflows/deploy*` → GitHub Actions (push triggers deploy)
+  - `Dockerfile` alone → manual container deploy (surface as "Docker-based,
+    check deployment docs")
+
+  If found, include in the briefing: "**Deployment:** [method] via [command]"
+
 The goal: build a mental model of where things stand before doing
 anything else.
 
@@ -277,6 +299,34 @@ Surface missing plugins as health warnings:
 
 Advisory only — do not block orient for missing plugins.
 
+### Unmerged branch check
+
+Scan for branches with commits ahead of the main branch that may
+represent unmerged work from prior sessions (especially worktree
+sessions that ended without merging):
+
+```bash
+git for-each-ref --format='%(refname:short)' refs/heads/ | while read branch; do
+  ahead=$(git log --oneline main..$branch 2>/dev/null | wc -l | tr -d ' ')
+  if [ "$ahead" -gt 0 ]; then
+    echo "$branch: $ahead commits ahead"
+  fi
+done
+```
+
+Also check `git worktree list` for active worktrees whose branches
+have diverged from main.
+
+Surface as advisory:
+> ⚠ Branch `feature-x` has N commits ahead of main (last touched
+> [date]). Merge, continue working, or discard?
+
+**Known platform limitation:** The Claude Code Agent tool with
+`isolation: "worktree"` branches from the remote tracking ref, not
+local HEAD. Unpushed commits are invisible to worktree agents. Always
+push before spawning worktree agents, or manually review their diffs
+for spurious deletions of unpushed work.
+
 > **Orient vs Pulse vs Audit:** Orient health checks verify *operational*
 > state — is the system running, is data fresh, are processes alive?
 > Pulse (embedded in orient) verifies *descriptive* accuracy — do counts

package/templates/skills/validate/SKILL.md

@@ -42,8 +42,14 @@ Phase files have three states:
 Read `phases/validators.md` for the list of project-specific checks.
 Each validator has a name, command, and description of what it catches.
 
-If `phases/validators.md` is empty or missing, report that no validators
-are configured and suggest the user define some.
+**Default (absent/empty):** Auto-discover validators by scanning for
+`scripts/*-validator.sh` (or `scripts/*-validator.cjs`). For each found,
+treat the filename as the validator name and run it against the
+appropriate targets (e.g., `skill-validator.sh` runs against all
+`templates/skills/*/SKILL.md` files if they exist, or `.claude/skills/*/SKILL.md`).
+
+If no phase file exists AND no validator scripts are discovered, report
+that no validators are configured and suggest the user define some.
 
 ### 2. Run Each Validator