Multica Ultimate Workbench

A durable operating memory layer for coordinating Codex, Claude Code, and Hermes agents on top of Multica.

Jump to: Overview · Architecture · Windburn Cache · Two-Ring System · Self-Awareness · SDD · Algorithm Advisory · Goal Mode · L2 Pressure · Wake Reports · Capy Process Check · Sanity Context · Agent Install · Flue Harness · Mirage VFS · Repo Brand Uplift · Runtime Model · Commands · Docs · 中文总览

Overview

Multica Ultimate Workbench is the durable operating memory for a multi-agent workbench built on top of Multica. Multica remains the live collaboration layer for agents, issues, comments, direct chat, runtimes, skills, and autopilots. This repository preserves the operating model around that layer — roles, decisions, templates, safety rules, verification scripts, and review discipline — in Git, where it can be versioned, diffed, and audited independently of the live workspace.

Install Skills

The public Workbench skill pack is installable through the open skills ecosystem:

npx skills add Fearvox/multica-ultimate-workbench --list --full-depth
npx skills add Fearvox/multica-ultimate-workbench --skill workbench-self-awareness-infra workbench-sdd workbench-conductor
npx skills add Fearvox/multica-ultimate-workbench --all

Use --list first to inspect the 33 public-safe skills. Install only the slice a runtime needs unless you are intentionally bootstrapping the full workbench grammar.

Why It Exists

Agent collaboration gains power from structure. Direct chat is good for fuzzy thought; real execution needs owners, evidence, review gates, and memory that survives the session. This repo provides those rails without modifying Multica's daemon, Desktop UI, or core runtime. It is the workbench's long-term memory — the part that persists when chat scrolls away.

Architecture

The workbench separates live execution from durable operating memory:

The workbench also accepts a small external review surface: the Capy Git Dialogue Lane. Captain Capy and other external coding agents should use commit
subjects, PR titles/descriptions, and review comments as durable, reviewable
signals back into the workbench. A bounded GitHub webhook responder now listens
for payload-scoped Capy dialogue across issue, PR, review, check, and workflow
events, using the payload owner/repo as source of truth and treating
self-authored bot churn as observation-only unless a human explicitly
re-requests action; see docs/capy-git-dialogue-responder.md and skills/workbench-capy-git-dialogue-guardrails/SKILL.md. Those artifacts complement Multica's live coordination; they do not replace it, and they do not authorize daemon, Desktop UI, or core runtime mutation.

A sibling evidence-sync lane can project the same PR, CI, and review evidence into Linear and Slack for external status hygiene without changing the authority order: Captain classifies state, Linear is the durable external ledger, Slack is the human notification surface, and merge authority stays with humans plus GitHub evidence; see docs/capy-linear-slack-sync-lane.md.

Status-changing closeout now has a source-layer validator for the exact
CHANGED / VERIFIED / REMAINING / PRS / LINKS / VERDICT shape, PR reference
types, cross-issue REMAINING sync, and audit-only Linear adapter events; see
skills/workbench-closeout-validator/SKILL.md
and autopilots/closeout-audit-sweeper.md.
Public repository hardening is staged separately: the rulesets spec and rollout
plan document the commands for main and release-tag protection, but GitHub
settings mutation still requires explicit operator approval; see
docs/ops/PUBLIC_REPO_RULESETS_HARDENING_SPEC.md.

For new webpage, subpage, landing-page, or microsite work, the default route is
the Project Windburn scaffold lane only when no target repo is named in the
request, attached to the issue or project, or otherwise established by primary
repo evidence. Treat Fearvox/project-windburn as a public landing-zone
scaffold until repo evidence shows created child page projects; see
docs/project-windburn-scaffold-lane.md.

Windburn Cognitive Cache Direction

Windburn's next important direction is not a new base model first. It is a
memory-native agent substrate: a .learning layer that preserves perceptions,
beliefs, failures, source truth, skills, and parking ideas so future runs can
change behavior from prior reality feedback.

This direction keeps Workbench Self-Awareness and L2 Pressure intact while
adding the question they do not answer alone: what has the system learned from
prior verified deltas, and how should that change the next run?

See docs/windburn-cognitive-cache-direction.md
for the original decision record,
docs/windburn-cognitive-cache-dispatch.md
for the implementation dispatch contract, and
docs/windburn-divergence-gated-trust-research.md
for the v0.3 divergence-gated trust-promotion research packet, and
docs/windburn-materiality-classifier-contract.md
for the classifier and promotion-gate boundary that routes challenger
alternatives without promoting trust, and
docs/windburn-challenge-orchestration-contract.md
for the local challenge-review bridge that composes verifier and promotion-gate outputs.

Two-Ring System

The system uses two rings instead of a flat swarm to keep agent coordination manageable.

See agents/AGENT_ROSTER.md for the full role map and ring assignments.

Friction Tier Router

Workbench Admin routes each request before adding ceremony:

Completion Cooling stops late-stage expansion: after 75% complete, work should
verify, commit, or hand off; new ideas go to a one-line parking lot for later
review.

Self-Awareness

Self-Awareness is the workbench's Heavy Path bootstrap layer. Agents post
SELF_AWARENESS_BOOTSTRAP for Heavy work, ambiguous repo/runtime ownership, or
Standard work that depends on current runtime capability: runtime identity, role
boundary, repo anchor, tool/MCP envelope, memory sources checked, current-state
proof, risk boundary, route, success metric, and operator-call conditions.

It keeps current evidence ahead of old memory, prevents wrong-runtime/tool
assumptions, and routes work into SDD, Goal Mode, L2 Pressure, VM execution,
child issues, or Supervisor review as needed. It is public-safe by design: no
raw environment dumps, secrets, live IDs, request payloads, or raw transcripts.

See skills/workbench-self-awareness-infra/SKILL.md and docs/self-awareness-infra-layer.md.

SDD Workflow

Non-trivial work follows Specification-Driven Development:

raw requirement → product design → technical design → optional algorithm advisory → task list → execution/review

Each stage is recorded as a structured issue comment. Issue status stays coarse-grained; the detailed workflow lives in comments and review labels.

Algorithm Advisory Gate

Algorithm Advisory Gate is an optional SDD stage between Technical Design and
Task List. A VM Claude Code advisor uses the data-algo skill to review
correctness, complexity, data-structure choice, and verification pressure
without directly modifying code.

See docs/algorithm-advisory-gate-lane.md
and skills/workbench-algorithm-advisory-gate/SKILL.md.

Goal Mode

Goal Mode is the workbench wrapper for /goal tasks: the assigned owner locks the objective, keeps it alive across turns and reruns, and does not claim completion until the relevant build, test, smoke, docs/report, git-status, and evidence gates are addressed.

It is not a permission override. Destructive actions, credentials, public/private boundary changes, and live runtime mutations still require the normal approval and Supervisor review path.

See skills/workbench-goal-mode/SKILL.md.

L2 Pressure

L2 Pressure is the Research Vault grounding layer for remote Hermes, VM, and HarnessMax work. Before routing or claiming a high-pressure autonomous path, the owner posts RV_PRESSURE_CHECK: what vault source was checked, which prior failures or proven patterns matter, how they changed the route, and whether the result is PASS, FLAG, or BLOCK.

Remote runtimes start read-only. The approved remote RV MCP surface is vault_status, vault_search, vault_taxonomy, and vault_get; writes, ingest, deletion, maintenance, and broad raw export require separate approval and Supervisor review.

See skills/workbench-l2-pressure-gate/SKILL.md and docs/remote-rv-mcp.md.

Mirage VFS Tool Lane

Mirage is tracked as an optional virtual-filesystem tool layer for agents: a
single shell-addressable tree for temporary RAM/disk workspaces and bounded
cross-service pilots. It is useful when an agent needs one command vocabulary
across already-approved resources, but it is not a source-of-truth replacement
for Git, GitHub, Linear, CI, Multica issue evidence, or reviewed Workbench docs.

Use docs/mirage-vfs-tool-lane.md and
skills/workbench-mirage-vfs-tool
before installing, piloting, or reviewing Mirage use.

Agent + Runtime Model

Codex, Claude Code, and Hermes are assigned by role, not treated as interchangeable text boxes:

Normal Workbench Codex runs use a lean per-run profile rather than inheriting
the user's full plugin and marketplace configuration. The default profile keeps
shell, Git, model/context settings, and multica access, while omitting
plugin/marketplace tables unless a task explicitly needs a named capability.
See docs/codex-workbench-runtime-profile.md
and config/multica-workbench-codex-profile.example.toml.

The Windburn remote NixOS workhorse is registered as a remote execution cell,
not an orchestrator. Its durable surface is systemd plus fixed tmux lanes;
Herdr is a local cockpit that can attach to the remote lane without owning
durability. Current public-safe capability evidence covers
herdr-cockpit-socket-api, codex-fixed-tmux-lane,
hermes-yolo-tmux-lane, runner aggregate PASS, and health safety-gate
PASS. See
docs/windburn-workhorse-runtime-registry.md.

Workspace Skills

Workspace skills are the shared grammar of the workbench. They make high-frequency behavior explicit — SDD, conductor routing, research, implementation, review, docs release, browser proofshot QA, token/context discipline, L2 pressure, and memory synthesis.

See skills/README.md for the live skill map and attachment design.

For public docs and skill sync, Claude Code writes the first patch and Hermes
reviews it with workbench-hermes-docs-sync
before publish when the change touches README, docs maps, install instructions,
agent roles, templates, or registry-facing skills.

Wake Reports

workbench-waking-up is the context-restore skill for direct-chat catchups and
fresh-session restarts. When an operator asks "gm", "where are we", "what can
move now", "最近干了什么", or whether a session-derived update should become
Workbench-visible, agents recall memory leads, verify live repo/issue/cron/runner
state, surface drift first, and return a short P0/P1/P2/PARKED action menu with
receipts.

Use skills/workbench-waking-up/SKILL.md
when recent sessions, dropped task leads, branch drift, Multica runs, cron jobs,
Research Vault/Sanity context, or runner state affect the next move.

Repo Brand Uplift

Selected public GitHub repos should be readable as proof-first artifacts, not
internal run logs. Use
workbench-repo-brand-uplift
and docs/repo-brand-uplift-lane.md to lift a
repo toward the Zonic/Evensong standard: brand-first, proof-first,
public-safe, installable, and evidence-backed.

Multica 0.2.22 Platform

Multica 0.2.22 provides the platform surfaces the workbench builds on: project-bound repos, Quick Capture intake, fresh reruns, Mermaid rendering, per-agent model config, and safer custom env handling. The workbench uses these as routing and evidence rails — they extend what the workbench can do, but do not replace SDD or Supervisor review.

flowchart LR
  A["Quick Capture / raw request"] --> B["Project-bound repo"]
  B --> C["SDD handoff"]
  C --> D["Owner execution"]
  D --> E["Evidence artifact"]
  E --> F["Supervisor verdict"]

See docs/multica-021-workflow.md for the platform capability map.

Flight Recorder

The flight recorder produces a compact issue-level digest — metadata, comments, runs, verdict markers, checkout evidence, and run-message counts — as a RUN_DIGEST. It is not full telemetry and does not persist raw payloads by default.

./scripts/collect-flight-recorder.sh <issue-id>

See WORKBENCH_METRICS.md and docs/flight-recorder.md.

Capy VM Lane

A controlled VM/Computer execution path for GUI, browser, sandbox, and screenshot-backed tasks. It does not replace Multica routing or Supervisor review; it gives assigned agents a disposable execution cell when shell-only work is insufficient.

./scripts/vm-smoke.sh

See docs/capy-vm-lane.md.

Capy Process Check Lane

Capy Process Check is the lightweight Brave/Computer Use lane for observing Capy task, thread, PR, and review state in real time. It is deliberately simple: read the UI, compare it against GitHub CLI or repo evidence, and publish a compact CAPY_PROCESS_CHECK.

Capy UI is supporting evidence, not the source of truth. Merge, done, and release claims still require GitHub, CI, repo, or review evidence.

Capy project context lives in CLAUDE.md, .capy/CAPTAIN.md, .capy/BUILD.md, .capy/REVIEW.md, and .capy/settings.json. The settings file registers the Sanity MCP endpoint as sanitized supporting context only.

See docs/capy-process-check-lane.md, skills/workbench-capy-process-check/SKILL.md, and issue-templates/capy-process-check.md.

Sanity Unified Context Lane

Sanity is the structured context registry for cross-CLI workbench state. It stores sanitized records such as agent profiles, runtime surfaces, skill contracts, evidence events, decisions, handoffs, and Capy process checks so different CLIs can query the same context without loading the same long prompt.

Sanity does not store secrets, raw logs, OAuth material, raw transcripts, raw request payloads, private screenshots, or unreviewed memory overrides.

See docs/sanity-unified-context-lane.md, skills/workbench-sanity-context/SKILL.md, and issue-templates/sanity-context-schema.md.

Agent-Install Unifier Lane

The agent-install lane distributes reviewed skills, MCP server definitions, and AGENTS.md sections across supported coding agents. It is a sync layer, not a governance layer: Multica and this repo still own routing, SDD, review gates, and final acceptance.

See docs/agent-install-unifier-lane.md, skills/workbench-agent-install-unifier/SKILL.md, and issue-templates/agent-install-unifier.md.

Flue Agent Harness Lane

Flue is the deployable agent harness outlet for mature workbench workflows. When a workflow should become a reusable HTTP agent, CI reviewer, Node service, Cloudflare Worker, or sandbox-backed coding/support agent, the owner writes a FLUE_AGENT_CONTRACT and packages the smallest useful Flue scaffold.

The lane does not replace Multica, SDD, Goal Mode, L2 Pressure, or Supervisor review. It turns stable workbench behavior into deployable agent code while keeping live routing and evidence gates in Multica.

See docs/flue-agent-harness-lane.md, skills/workbench-flue-agent-harness/SKILL.md, and issue-templates/flue-agent-scaffold.md.

Skill Curator

The maintenance protocol for keeping workbench skills useful over time. It reviews stale skills, overlapping instructions, role-binding drift, token/context risk, and recoverable archive candidates. Version 1 is review-only — it proposes changes through issues instead of silently deleting or rewriting skills.

See docs/skill-curator.md and issue-templates/curator-review.md.

Autopilots

Autopilots create issues for recurring checks — daily health, auto-review sweeps, remote HarnessMax evolve sweeps, dependency review, stale-memory checks, skill-curator checks, benchmark-artifact checks. They are scheduled entry points into the review pipeline; they do not silently execute high-risk work.

See autopilots/daily-health.md, autopilots/auto-review-sweeper.md, and autopilots/remote-harnessmax-evolve-sweeper.md.

Commands

Read-only helpers (safe to run anytime):

./scripts/list-workbench-state.sh
./scripts/collect-flight-recorder.sh <issue-id>
./scripts/multica-codex-cache-janitor.sh

Source regeneration:

./scripts/generate-create-commands.sh

Windburn local trust helpers:

node scripts/windburn-verify.mjs <belief-file.md>
node scripts/windburn-momentum-decay.mjs <belief-file.md> --dry-run
node scripts/windburn-belief-write.mjs --source <candidate.md> --dest .learning/beliefs/<slug>.md

Human approval required before running:

./scripts/create-pilot-agent.sh
./scripts/create-agent-roster.sh
./scripts/multica-codex-cache-janitor.sh --apply

Documentation Map

Safety Boundaries

The workbench is intentionally conservative:

• It does not replace Multica.
• It does not modify Multica daemon, Desktop UI, or core runtime.
• It does not store secrets, credential material, raw request payloads, or raw run transcripts.
• The Capy Git Dialogue Lane stays compact and public-safe: no live IDs,
  private payloads, or noisy run logs in committed docs, commit bodies, PR
  descriptions, or review comments.
• No agent may claim done without evidence.
• PRs are proposed dialogue artifacts; merge or acceptance remains a human or
  Supervisor review decision.
• Outer Ring agents do not assign work to each other.
• Autopilots create issues; they do not silently execute high-risk work.

中文总览

Multica Ultimate Workbench 是建立在 Multica 之上的多 agent 工作台持久记忆层。Multica 负责实时协作（agents、issues、comments、direct chat、runtimes、skills、autopilots），本仓库负责沉淀协作方式（角色、决策、模板、安全边界、验证脚本和 review 纪律），以 Git 版本化管理，独立于 live workspace。

核心概念

安全边界

• 不替代 Multica，不修改其 daemon、Desktop UI 或 core runtime。
• 不存储 secrets、credential、raw payloads、OAuth material 或 raw run transcripts。
• Sanity 只存去敏结构化上下文，不作为未复核记忆覆盖源。
• 没有证据不能 claim done。
• Outer Ring agents 不互相派活。
• Autopilots 只创建 issue，不静默执行高风险任务。

当前状态

工作台已具备：经过验证的双环 roster、高频 workspace skill pack、Hermes docs-sync review、source-first prompt compression、daily health autopilot、automatic review sweeper、通过 live QA/Supervisor review 的 flight recorder、skill curator protocol、wake report/context restore skill、受控 VM lane、Capy process check lane、Sanity context registry、agent-install unifier lane、Flue deployable agent harness lane、Mirage VFS candidate tool lane、Multica 0.2.22 project-bound repo anchor、在线 NYC remote execution cell。

当前事实看 SYNTHESIS.md，历史流水账看 WORKBENCH_LOG.md。