Project Orchestration & Memory

Global Rules

• All cross-repo coordination, project memory, and the documentation architecture convention are maintained in this file.
• Directive placement rule: Cross-cutting directives → this file. Repo-specific directives → ./AGENTS.md. Pointer files carry zero directives.
• Root Purity: The Code/ root contains no ordinary project files or symlinks. The only allowed root-level control file is /Users/c083074/Code/AGENTS.md, which exists solely to route agents into the correct repo.
• Root Routing Rule: /Users/c083074/Code is the default terminal home for multi-repo work. It is a routing surface, not a project repo. No edits, deploys, or sync actions may be executed "against Code" itself.
• Project Resolution Rule: If cwd is /Users/c083074/Code or another multi-repo parent, the agent must resolve a single target repo from the request before any edit, push, deploy, rebase, install, or destructive command.
• Deploy Ownership Rule: Deploy bindings must live only in the owning repo. No other repo may contain .clasp.json, CI deploy config, or scripts that target another project's production surface.

---

Root Routing

Default Starting Directory

The user may start from:

• /Users/c083074/Code

Agents should treat that as the normal control-plane entrypoint. The user does not need to manually cd into each repo for ordinary work.

Routing Table

When cwd is /Users/c083074/Code, infer the target repo from request intent using this table before touching files or running project commands:

Request Signals	Target Repo	Notes
apps script, clasp, gmail, calendar ops, filters, labels, google automation	/Users/c083074/Code/google-automation	Owner of the Apps Script deploy surface
openclaw, discord, telegram, gateway, vps, bot, config	/Users/c083074/Code/openclaw-config	Owner of OpenClaw runtime/config
obsidian, vault, notes, knowledge base	/Users/c083074/Code/obsidian-vault	Owner of knowledge content
nerv, orchestration, global rules, routing, governance	/Users/c083074/Code/NERV	Governance only; not an app deploy surface

Routing Behavior

Agents operating from /Users/c083074/Code must:

1. Resolve the target repo from the request.
2. Execute file reads, edits, tests, and deploys only inside that repo.
3. Refuse or clarify only when the request is still ambiguous after applying the routing table.

Agents must not:

• run clasp push from /Users/c083074/Code
• edit files across multiple repos unless the task explicitly requires coordination
• let NERV act as the deploy source for another repo
• restore stray deploy bindings in non-owner repos

---

Documentation Architecture

The Three-Layer Governance Model

graph TD
    %% Define Nodes
    subgraph Level3 ["Level 3: Governance (Global Brain)"]
        SYS[".system/README.md"]
        LINT[".system/skills/src/lint-doc-arch.sh"]
    end

    subgraph Level2 ["Level 2: Orchestration (Agent Harnesses)"]
        BOBBY["openclaw-config/ (Bobby)"]
        HERMES["hermes/ (Under Evaluation)"]
    end

    subgraph Level1 ["Level 1: Execution (The Tools)"]
        GAS["google-automation/ (Apps Script)"]
        OBS["obsidian-vault/ (Knowledge)"]
        DOT["dotfiles/ (System Config)"]
    end

    %% Connections
    SYS -->|Defines Laws For| BOBBY
    SYS -->|Defines Laws For| HERMES

    BOBBY -->|Operates On| GAS
    BOBBY -->|Writes to| OBS

    LINT -->|Enforces Purity On| Level1
    LINT -->|Enforces Purity On| Level2
    LINT -->|Enforces Purity On| Level3

    %% Styling
    style SYS fill:#f9f,stroke:#333,stroke-width:2px
    style LINT fill:#bbf,stroke:#333,stroke-width:1px
    style Level3 fill:#fff3ff,stroke:#f9f,stroke-width:2px,stroke-dasharray: 5 5
    style Level2 fill:#f3f7ff,stroke:#bbf,stroke-width:2px,stroke-dasharray: 5 5
    style Level1 fill:#f5fff5,stroke:#bfb,stroke-width:2px,stroke-dasharray: 5 5

Loading

Layer	File	Purpose
Level 3: Global	/Users/c083074/Code/NERV/README.md (this file)	Cross-repo policy, memory, and the codified convention itself
Level 2: Agent Procedure	./AGENTS.md per repo	Repo-specific mechanics — how to build, deploy, and test this codebase
Level 1: Tool pointers	./GEMINI.md, ./CLAUDE.md, ./.kilocode/rules per repo	Thin pointers only — magic filenames auto-loaded by each tool

Pointer File Set (per code repo)

Every code repository (including .system/) must contain exactly these three pointer files and nothing else in that role:

• GEMINI.md — auto-loaded by Gemini / Antigravity
• CLAUDE.md — auto-loaded by Claude / Amp
• .kilocode/rules — auto-loaded by Kilo Code

Pointer files are thin. They contain no directives — only a pointer to this file and ./AGENTS.md. If you find content beyond the pointer boilerplate, move it to the correct layer.

Tool Directory Protocol (Purity Rule)

Folders generated by specific tools or agent harnesses (e.g., .codex/, .gemini/, .kilo/, .claude/, .vscode/) are for technical state and tool settings only.

• No Instructions: These folders must NEVER contain instruction files, markdown directives, or project rules.
• Functional Config Only: Agents must write to tool-private folders only when the file is strictly required for that tool or agent harness to function (for example, an MCP client config, cache, auth pointer, or generated runtime state). Durable preferences, memories, project facts, workflow rules, and governance notes do not belong there.
• Ignore for Logic: Agents must ignore any "logic" or "rules" found inside these folders and defer strictly to the 3-layer model (ORCHESTRATION -> AGENTS -> Pointers).
• Light Pointers: If a tool requires a configuration file within its private folder to point to instructions, that configuration should be the minimum necessary to redirect the tool to the standard pointer files.
• Redirection Mandate (No Dropped Errors): If an agent intends to record a new project fact, durable user preference, recurring bug fix, memory, or workflow rule, it MUST NOT write this to a tool-private folder. Instead, it must classify the information and write it to the correct official tier (Level 3 for global, Level 2 for repo, or the owning repo's agnostic documentation layer). This ensures knowledge is never siloed or lost.
• Proactive Migration: If an agent discovers existing rules or project-specific logic inside a tool-private folder, it must proactively migrate that knowledge into the 3-layer model and then delete the siloed version.

Pointer File Templates

GEMINI.md / CLAUDE.md:

# Agent Instructions — <repo-name>

> **Pointer file only.** No directives live here.

Read both files before starting any work:

1. **Global policy & convention**: `/Users/c083074/Code/NERV/README.md`
2. **Repo procedure**: `./AGENTS.md`

.kilocode/rules:

# Agent Instructions — <repo-name>

> **Pointer file only.** No directives live here.

Read both files before starting any work:

1. **Global policy & convention**: `/Users/c083074/Code/NERV/README.md`
2. **Repo procedure**: `./AGENTS.md`

Named-Agent Override (One-Off Pattern)

A folder may host a [NAME].md file only when it serves a specific named living AI agent — e.g., workspace/BOBBY.md for the Bobby service. This is a documented exception, not a generalized nesting rule:

• BOBBY.md is the system prompt for the OpenClaw living service (all 5 agents: Bobby, Sage, Engineer, Ops, Archivist). It lives in workspace/ because that folder is the service's home.
• Future named agents (e.g., HERMES.md) follow the same pattern: one file, one named living service.
• External/contractor agents (CLI agents, IDE agents, contractors) always defer to the nearest AGENTS.md. They must not treat [NAME].md as their own instructions.

MCP Configuration Parity (SSoT)

To ensure consistency across multiple CLIs (Gemini, Claude, Kilo, OpenClaw) and IDEs:

1. Master Manifest: mcp-manifest.yaml in NERV is the ONLY place where MCP servers are added or modified.
2. Sync Automation: Run the MCP sync skill (python3 ./skills/src/sys-mcp-sync.py) to apply the manifest into MCPM, update MCPM-managed clients, and wire Antigravity through its MCP gateway config.
3. Environment Isolation: Keep API keys in .env; the sync script expands them into the target configs to avoid secret leakage in manifest files.

Native Plugins vs. MCP Overlap Strategy

Core Principle: Native plugins/extensions provided by a specific AI ecosystem are assumed to be superior (in reliability, latency, and deep integration) to third-party MCPs. Therefore, we map MCPs as fallbacks to toolkits (clients) that lack native capabilities, and actively prevent redundant MCPs from loading in clients that already have the native equivalent.

Capability Area	Native Ecosystem Feature	MCP Fallback	Toolkits assigned MCP
GitHub Integration	Codex Github Plugin	github	Antigravity, OpenClaw, Kilo
Context/Research	Gemini context7 Extension	context7	Antigravity, OpenClaw, Kilo
Deep Search	Gemini exa-mcp-server Extension	exa	Antigravity, Kilo
Browser Inspection	Gemini chrome-devtools-mcp Ext	chrome-devtools-mcp	Antigravity, OpenClaw, Kilo

Non-Overlapping Native Capabilities (No MCP Fallback Required/Available):

• Codex Plugins: Coderabbit (Code Review), Gmail, Superpowers
• Gemini Extensions (Also used by Antigravity): caveman, clasp, code-review, gemini-cli-security, superpowers
• OpenClaw Plugins: openai, duckduckgo, discord, google, memory-lancedb-pro-src, tavily, wiki-maintainer, lossless-claw, token-optimizer, obsidian-vault-maintainer

Client-Specific Enforcement Rules (enabled_clients):

1. Gemini CLI & Antigravity: Have native extensions via ~/.gemini/extensions/extension-enablement.json for context7, exa-mcp-server, and chrome-devtools-mcp. They are intentionally excluded from the context7, exa, and chrome-devtools-mcp arrays in mcp-manifest.yaml.
2. Codex CLI: Has a native Github plugin. It is intentionally excluded from the github array in mcp-manifest.yaml.
3. OpenClaw / Kilo: Lacking these specific native plugins (or relying strictly on their own defined subsets like OpenClaw's tavily / duckduckgo for search), these clients receive the full suite of MCP fallbacks via the enabled_clients arrays in the NERV/mcp-manifest.yaml manifest.

---

Project Structure

• .system: Global governance laws, linter automation, and system-wide scripts (This repo).
• google-automation: Personal email filtering, calendar ops, and triage (alsoabel@gmail.com).
• openclaw-config: OpenClaw service configuration, skills, prompts, and workspace for Bobby.
• obsidian-vault: Personal knowledge base notes and human canvases.
• dotfiles: System configuration repository. Resides natively at ~/.local/share/chezmoi.

---

Shared Filtering Logic (Base Layer)

Both google-automation projects share a "Base Layer" for Career, Orders, Health, and Security.

• Career emails: Keywords include job titles; "unsubscribe" does NOT exclude from processing. Labeled, marked read, and archived.
• Health/Orders: Routine items (shipments, receipts) are marked read and archived.
• Security: Routine alerts are archived; Critical alerts are starred and kept in inbox.
• Whitelisting: Dynamic whitelist is built using labels defined in WHITELIST_LABELS constant.

Apps Script & GCP Architecture Policy

To handle the complexity of linking Google Apps Script projects to multiple GCP projects (e.g., to manage Vertex AI free credits, separate access for Openclaw), the following policy applies:

1. Advanced API Requirements: Linking an Apps Script project to a GCP project is only required when using Advanced Services (e.g., Gmail.Users.Labels.list). Basic services (e.g., GmailApp) work without a link.
2. Decoupled Identity: The GCP project hosting the API (the "container") does not need to be owned by the same account running the script. You can link an Apps Script project to any GCP project where you have the necessary IAM permissions.
3. Strategy:
   • Use a "Master" GCP account for API management/billing (e.g., Vertex AI credits).
   • Link individual Apps Script projects (regardless of owner) to the relevant GCP projects for API/Billing access.
4. Permissions:
   • OAuth (Access): Managed by the user running the script.
   • API (Permissions): Managed by the IAM permissions of the developer on the GCP project.
5. Clasp Run Constraint: clasp run requires the Apps Script API to be enabled on the linked GCP project.

---

User Preferences

• Response Formatting (High Priority): Every response MUST include:
  1. Context Summary: A brief summary of the user's question or initial prompt.
  2. MCP Profile: The specific MCP profile selected for the task (minimal, core, research, deep-search, browser, services) and the technical rationale for its selection.
  3. Actions Taken: A concise audit of files edited, memory/config/docs written, commands run for side effects, and notable decisions made during the turn. Explicitly say when durable memory/config was not written.
  4. Tool Audit: A list of all MCPs, CLIs, and internal tools utilized in the turn.
• Warp Terminal Readability: Format replies for polished terminal readability. Use short Markdown headings, compact spacing, semantic emoji, and Unicode box-drawing cards for important summaries, warnings, recommendations, progress, and results. Favor clarity over decoration.
• Terminal Visual Style:
  • Use meaningful status markers such as ✅ success, ⚠️ warning, ❌ failure, 🚀 action, 🧠 reasoning, 📌 important, 🔧 implementation, 📦 output, ⏱️ timing, and 👀 review.
  • Prefer compact cards like ╭─ Status, │ ..., ╰─ for important summaries, warnings, decisions, and results.
  • Prefer open Unicode cards and left-rail sections for normal replies. Closed right-border boxes are only reliable for plain fixed-width text without emoji, Markdown links, proportional glyphs, or renderer-controlled wrapping.
  • When a perfectly straight right border is required, use a fenced text block and avoid emoji inside that closed box unless a wcwidth-aware formatter has padded the line. Otherwise, do not draw a right border; use ╭─ Title, │ ..., ╰─ open cards instead.
  • When summarizing activity transcripts, tool calls, command logs, or explored/read/ran steps, use open Unicode cards by default. Use closed boxes only for plain fixed-width transcript snapshots where every line is hard-wrapped and padded consistently.
  • Use Markdown blockquotes with > for quoted user text, source excerpts, or callout-style quoted material when applicable.
  • Use fenced code blocks for commands and technical snippets.
  • Use Markdown tables only when they remain readable in a monospaced terminal.
  • Do not rely on custom fonts or colors for meaning. Markdown does not reliably control terminal fonts or blue text across renderers; ANSI styling may be used only when explicitly requested and when it will not reduce readability.
  • Avoid HTML, giant ASCII banners, over-centering, decorative fluff, dense walls of text, and emoji spam.
• Tone & Style: Write like a sharp technical operator: direct, crisp, expressive, and slightly opinionated when useful. Use emojis where they improve scanning without making the response noisy.
• Entry-Point Rule: When starting from /Users/c083074/Code, treat the response-formatting rules above as active at the root control surface, not as optional downstream guidance.
• Token Efficiency: Always prefer non-LLM (localShell or standard shell) solutions over LLM-backed (agentTurn) solutions for automatable tasks.
• Browser Automation Preference:
  • Prefer agent-browser as the first-choice shell/browser automation path when the task is direct browser control: open pages, click/type/fill, snapshot, screenshot, console/error inspection, network capture, auth/session reuse, or quick web-app QA.
  • Do not frame agent-browser as a full replacement for every browser MCP. Keep browser MCPs for deeper integrated inspector workflows, crawl/extraction services, or cases where the MCP abstraction is clearly better than direct CLI control.
  • If OpenClaw itself is expected to use agent-browser, the runtime host must have both the CLI/runtime (agent-browser plus its Chrome install/state) and an OpenClaw-visible skill directory such as ~/.openclaw/workspace/skills/agent-browser.
• Measured Context Reduction: When refactoring prompts, Markdown docs, instructions, memory, or other context-heavy files to reduce bloat, agents should quantify the before/after effect where practical. Track at least bytes and lines, and estimate token reduction when useful. If response verbosity, startup time, sync time, lint time, or other performance signals are relevant and cheap to measure, report the before/after values and net reduction in the Actions Taken audit.
• Git Synchronization: The VPS (openclaw) runs an hourly localShell cron job to commit and push changes. The local machine (darwin) has a matching cron job to pull changes and commit local updates.
• Memory Management: All personal preferences and project history are logged here to maintain persistent "OpenClaw-style" memory.
• Memory Layer Roles:
  • cavemem is the cross-agent / cross-tool memory runtime layer.
  • memory-lancedb is the regular OpenClaw-native memory lane.
  • memory-lancedb-pro is the provider-heavy / experimental OpenClaw memory lane and should not be treated as the normal default.
• Cavemem Preference: When cavemem is installed and relevant, agents should treat it as the memory layer they keep track of on Abel's behalf rather than expecting Abel to manage or remember cavemem details manually. Prefer surfacing the simplest user-facing workflow while the agent handles the cavemem bookkeeping.
• Memory Simplicity Default: Avoid making Abel track multiple primary memory systems at once. If a task does not specifically require the distinction, present the simplest user-facing memory workflow and hide the implementation split.
• OpenClaw Memory Default: Keep live/default OpenClaw on regular memory-lancedb unless there is an explicit reason to change it.
• OpenClaw Experimental Memory Rule: Keep memory-lancedb-pro isolated to test or alternate profiles unless the user explicitly asks to promote it into the live/default gateway path.
• Memory Overlap Rule: Treat cavemem and OpenClaw memory plugins as overlapping systems at the persistent-memory layer. Do not casually run them as equal primary systems without explaining the duplication in storage, debugging, and bookkeeping.
• Token / Usage Tracking Guidance: memory-lancedb-pro increases provider-specific usage tracking because embeddings and rerank can run through external providers. cavemem is a separate runtime/operational overhead. When reducing complexity, prefer minimizing the number of active memory systems rather than switching away from plain memory-lancedb.
• Private License Material: Purchased software license keys and related receipts must stay in private documentation and may be labeled Tech or Licenses. Do not commit them to any repository.

---

Tool Usage Hierarchy (The Tiered System)

To optimize for token efficiency and "free-tier" utility, tools are used according to the following priority, split by environment:

1. IDE Environment (VS Code / JetBrains)

Tier	Role	Tool(s)	Usage Logic
Tier 1	The Driver	Antigravity	Primary choice. High-value coding and architecture.
Tier 2	The Grunt	Kilo (DeepSeek V4 Flash)	Basic Automation. Installs, tests, logic explanation.
Tier 3	The Auditor	Coderabbit, Sonarqube	Quality Control. Reviews and linting.
Tier 4	The Lab	Traycer	Prompt Engineering. Refinement of complex logic.

2. CLI Environment (Terminal)

Tier	Role	Tool(s)	Usage Logic
Tier 1	The Driver	Gemini CLI / Claude CLI	Primary choice. Both use Vertex API keys.
Tier 2	The Grunt	Kilo CLI (DeepSeek V4 Flash)	Utility. CURL requests, package management, simple scripts.
Tier 3	The Auditor	Copilot CLI	PR Reviews. Last resort for github.com code reviews.
Tier 4	The Reserve	Codex CLI	Fallback. Full access (ChatGPT Plus) but avoided (OpenClaw constraint).

3. External Research API

Tier	Role	Tool(s)	Usage Logic
Tier 1	The Researcher	Parallel AI (Search / Extract / Task / FindAll / Monitor)	Use for live web research, extraction, and monitored change tracking when a current external source is required.

Selection rule: When a task needs current web facts, a clean extraction from a URL or PDF, entity discovery, or a monitored external source, Parallel AI is an approved first-choice option before falling back to generic browser search.

Search Provider Credit Notes

• Monthly-refresh free keys: Tavily, Brave, Firecrawl
• Non-monthly key: Exa
• Prefer the monthly-refresh providers for routine web search / research when they fit the task.
• Reserve Exa for cases where its result quality or coverage is a better fit than the monthly-refresh options.

Deprecated: Gemini Code Assist (IDE), standard ChatGPT/Claude web interfaces (prefer CLI/IDE).

---

Active Status (2026-05-17)

• Voice Service Quotas: Updated /Users/c083074/Code/NERV/SERVICE_QUOTAS.md to include local Whisper fallback strategy on the VPS for OpenClaw.

---

Active Status (2026-05-16)

• MCP & Tool Reliability Protocol: Codified universal rules for MCP usage, timeouts, fallbacks, and transport selection.
• MCP Configuration Parity: Established a Single Source of Truth (SSoT) model using a master mcp-manifest.yaml and synchronization automation.
• Documentation architecture normalized across all repos (google-automation, openclaw-config, obsidian-vault, NERV).
• Created AGENTS.md for NERV to ensure full compliance with Level 2 orchestration standards.
• P0 fix: workspace/BOBBY.md merge completed — truncated placeholder replaced with full content.
• workspace/AGENTS.md collapsed to 3-line safety-net pointer.
• workspace/BOBBY.md added to safe-commit whitelist in autocommit-safe.sh and local-sync.sh.
• Pointer set enforced: all code repos now have GEMINI.md + CLAUDE.md + .kilocode/rules (thin pointers).
• openclaw-config/GEMINI.md stripped of directives; cross-cutting ones moved here; repo-specific ones remain in openclaw-config/AGENTS.md.
• Lint enforcement script added at google-automation/scripts/lint-doc-arch.sh.

---

Filter Updates (2026-05-13)

• Security: Added "You allowed" to handle Google App Access notifications.
• Technical: Added "AssemblyAI" and related keywords (Voice Agent API, LLM Gateway) to the Technical-Ops filter.
• Personal Repo: Synchronized with OpenClaw to include Technical-Ops processing (mark read & archive).

Final Synchronization (2026-05-13)

• Successful Push: Both 'personal' and 'openclaw' have been pushed to Google Apps Script.
• Git State: All changes committed and .gitignore updated to exclude .clasp.json and .clasprc.json.
• Base Layer: Shared logic for Career, Security, Orders, and Health is now consistent across both accounts.

Package Management

• Default Tools: ALWAYS prefer bun or pnpm over npm or yarn across all projects unless specifically constrained by the repository.

---

Local Shell & Tooling Notes

• Command Preferences:
  • Prefer rg over grep for search.
  • Prefer eza over ls for directory listing.
  • Prefer bat over cat for file reading.
  • Prefer jq for JSON inspection and formatting.
  • Prefer zoxide over raw cd when jumping between known directories.
  • Prefer lazygit when an interactive Git view materially helps, but keep non-interactive Git commands as the default for scripted work.
• Aliases:
  • kc -> kilocode --auto
  • gm -> gemini --yolo
• Zsh Plugins Present:
  • zsh-autosuggestions
  • zsh-syntax-highlighting
  • zsh-completions
  • zsh-history-substring-search
• Installed CLI Tools:
  • eza, gh, bat, zoxide, lazygit, jq, fzf, rg, glances, gpk
  • tvly via Tavily CLI

This section replaces one-off environment record files for aliases, plugin installs, and basic tool inventory.

---

Service Quotas (Voice & Transcription)

Detailed tracking of credits for Deepgram, Cartesia, ElevenLabs, Groq, AssemblyAI, and Speechmatics is maintained in:

• /Users/c083074/Code/NERV/SERVICE_QUOTAS.md

Agents must check this file before initiating high-volume voice or transcription tasks to ensure provider selection optimizes for remaining credits and rate limits.

---

MCP & Tool Reliability Protocol

1. The "Never Block" Mandate

MCP must never be a single point of failure. All MCP-based tool calls MUST be protected by:

• Circuit Breakers + Exponential Backoff: Prevent hammering failing servers.
• Strict Timeouts: Maximum 5–10s for most calls. Use graceful error responses so the agent can continue while logging the failure.
• Graceful Fallbacks: Every capability (e.g., Git search, tests, Jira updates) should have a fallback path (Local CLI or Direct REST API).

2. Transport Selection Logic

Context	Preferred Transport	Rationale
Simple / Idempotent	Direct API / CLI	Low latency, high reliability, token efficiency.
Performance Sensitive	Direct API / CLI	Avoids extra protocol overhead and flakiness.
Multi-turn / Complex	MCP	For rich tool-chaining and conversational workflows.
Audit-Heavy / Enterprise	MCP	Full audit logs and fine-grained permissions.

3. Architecture Pattern: "Load & Use"

A robust implementation involves an internal gateway/broker that:

• Routes tools based on transport preference (marked in config as transport: mcp or transport: cli).
• Enforces reliability constraints (timeouts, retries) per tool rather than per server.
• Maintains the agent's availability even when specific MCP servers are offline.

4. Concrete "Shouldn't Block" Rules

• Prefer API/CLI for: Git, package managers, basic HTTP, and any service with a stable, documented endpoint.
• Use MCP for: Multi-step workflows where tool-oriented orchestration and conversational context provide a genuine benefit.
• Treat MCP as Optional: If an MCP tool fails, immediately fall back to the CLI/API equivalent or log the error and proceed with other parts of the plan.

---

Quick Reference

All available just recipes grouped by category. Run just --list for the full list.

Health & Monitoring

Recipe	Description
just health	Run health pulse (containers, MCP, Redis)
just doctor	Self-diagnostic health check
just doctor-json	Doctor in JSON mode (for automation)
just daily	Daily briefing — full system overview
just dep-drift	Check critical dependency drift
just dep-drift-ack	Acknowledge current dep versions after review
just validate	Validate config consistency (env, models, MCP, Justfile refs)
just mcp-check	Check MCP server wiring
just mcp-latency	Measure MCP server latency
just drift-check	Check for Docker image drift (declared vs running)
just path-check	Standalone path health check (dead refs in dotfiles)
just path-check-stale OLD	Migration helper: scan for stale path references
just watchdog	Agent watchdog — detect and recover stuck/dead agents
just watchdog-auto	Auto-heal stuck agents (non-interactive, for Dagu)
just reconcile	Reconcile service registry vs running services
just autoheal	Auto-heal crashed LaunchAgents

Docker & Services

Recipe	Description
just services *args	Service management
just multica	Start multica self-host stack
just multica-stop	Stop multica stack
just multica-logs	Tail multica backend logs
just multica-status	Multica status (health + containers)
just multica-reset	Reset multica DB (destructive!)
just bobbywarden	Start bobbywarden
just bobbywarden-stop	Stop bobbywarden
just bobbywarden-status	Bobbywarden status
just bobbywarden-logs	Tail bobbywarden logs
just observe	Start observability stack (Grafana + Phoenix)
just observe-stop	Stop observability stack
just observe-status	Observability stack status
just containers	Container monitor (ctop)

Git & PRs

Recipe	Description
just status	Quick status: git + agents + worktrees
just push	Push to personal GitHub
just review	Pretty diff of staged changes
just release	Tag a calver release (YYYY.M.D format)
just activity	Show recent git activity graph
just prs	List my open PRs
just pr NUM	Check a specific PR's CI status
just publish	Publish current branch as draft PR
just worktrees	Show worktree status

Agent Bus & Automation

Recipe	Description
just agents	Show all active copilot agents
just dag NAME	Run a DAG by name
just dags	List available DAGs for current profile
just task-push MSG	Push a task to the cross-agent queue
just task-pop	Pop next task from queue
just task-peek	Peek at next task without removing
just task-count	Count pending tasks
just activity-feed	Generate agent activity feed JSON
just hook-catchup	Replay failed hooks
just radar-dismiss TASK	Dismiss a RADAR task
just retry-blocked	Retry blocked tickets
just launchd	List all registered LaunchAgents
just launchd-install NAME	Install a LaunchAgent from current profile
just sync-mcp	Sync MCP configs from manifest
just sync	Sync copilot home to archive

Diagrams & Visuals

Recipe	Description
just org-chart	Generate org chart (Excalidraw) from live state
just snapshot-boards	Export Excalidraw boards to SVG snapshots
just badge	Generate commits-today badge
just freeze FILE	Screenshot code to PNG

Development & Testing

Recipe	Description
just test	Run all tests (unit + integration)
just test-unit	Run unit tests only
just lint	Lint: validate config, check script syntax
just eval *args	Run promptfoo evals
just eval-view	View promptfoo eval results in browser
just build-instructions	Build generated instruction files (current profile)
just build-instructions-all	Build generated instruction files (all profiles)
just onboard	Bootstrap/verify machine setup
just onboard-fix	Bootstrap with auto-fix
just stress	End-to-end pipeline smoke test
just watch CMD	Watch for changes and auto-run tests
just bench CMD	Benchmark a command
just stats	Code stats for the repo (tokei)
just profile	Show current profile info
just budget	Premium model budget status
just tickets	Fetch & triage Jira tickets
just oncall	On-call knowledge base

Visual & TUI Tools

Recipe	Description
just center	AI Command Center — full TUI dashboard
just dash	Interactive agent dashboard
just dashboard	Run the dashboard (compact)
just monitor	Live agent monitor (auto-refreshing)
just monitor-compact	Compact agent monitor
just motd	Welcome banner
just sysinfo	System info (fastfetch)
just lines	Code lines per language
just disk	Disk usage visual (current dir)
just disks	System disk overview
just top	Process monitor (btm)
just tree	Pretty file tree
just files	File manager (yazi)
just history	Git history TUI (tig)
just sys	System monitor (btop)
just kill-orphans	Kill orphaned copilot processes
just shell-bench	Shell startup benchmark
just notify TITLE MSG	Send notification
just note MSG	Save a quick note to Redis
just notes	Show last 10 notes