[
{
"id": "file-read-tool-paged-line-numbered",
"domain": 1,
"domain_name": "Tool set",
"capability": "File read tool (paged, line-numbered)",
"semantics": "Dedicated read with offset/limit, `cat -n` style output",
"cc": "yes",
"cx": "no",
"cc_detail": "✓",
"cx_detail": "—¹",
"catalog_supercode_today": "✓ `read_file` (builtins.rs:52-58)",
"provenance": "cc§1 Read; oc§1 read; pi§1 read",
"status": "implemented",
"evidence": [
{
"kind": "tool",
"name": "read_file"
},
{
"kind": "config",
"key": "core.tools.read_file.line_numbers"
},
{
"kind": "code",
"path": "crates/harness/src/tools/builtins.rs",
"symbol": "fn render_read_slice(ctx: &ToolContext, slice: &str, first_line: usize) -> String {"
}
],
"note": "BP-2: `read_file` emits the `cat -n` gutter under cc-parity — a right-aligned line number and a tab per line, numbered from the requested `offset` (an `offset = 2` read starts at 2, so the model cites real file line numbers), on the whole-file, head-truncated and sliced branches alike. Off for every preset that does not set `[core.tools.read_file] line_numbers` (pi-core and cx-parity keep the raw slice; Codex reads through `cat`)."
},
{
"id": "multimodal-read-images-pdf-notebook",
"domain": 1,
"domain_name": "Tool set",
"capability": "Multimodal read (images/PDF/notebook)",
"semantics": "Read tool returns images/PDFs/ipynb as model-visible content",
"cc": "yes",
"cx": "variant",
"cc_detail": "✓ (img+PDF+ipynb)",
"cx_detail": "✓* `view_image` tool",
"catalog_supercode_today": "—",
"provenance": "cc§1; cx§1 view_image; oc§1; pi§1",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/harness/src/tools/builtins.rs",
"symbol": "if ctx.multimodal_read && is_image_path(&path) {"
},
{
"kind": "code",
"path": "crates/harness/src/tools/builtins.rs",
"symbol": "if ctx.multimodal_read && is_pdf_path(&path) {"
},
{
"kind": "code",
"path": "crates/harness/src/tools/builtins.rs",
"symbol": "if ctx.multimodal_read && is_notebook_path(&path) {"
},
{
"kind": "code",
"path": "crates/harness/src/tools/convert.rs",
"symbol": "pub fn pdf_text(bytes: &[u8]) -> PdfDocument {"
},
{
"kind": "code",
"path": "crates/harness/src/tools/mod.rs",
"symbol": "r.register(ViewImageTool);"
}
],
"note": "BP-2 closed the PDF/notebook half under cc-parity: with `[core.tools.read_file] multimodal` on, a `.pdf` comes back as its extracted text pages (`tools::convert::pdf_text` walks the content streams, inflating `/FlateDecode` ones, and decodes literal/hex/UTF-16 strings) and a `.ipynb` as its cells rendered WITH their outputs (streams, execute_results, errors) instead of lossy-decoded UTF-8. A PDF with no text layer (scanned, or an undecoded filter) returns a structured summary saying exactly that rather than silence — the extractor recovers a text layer, it does not render pages, which is the honest limit of this row's implementation. cx-parity's half is `view_image`, registered by its own module set (BP-1) — that IS Codex's variant of this row (`cx = variant`, cx§1 `view_image`, images only), so the row now holds under each applicable preset as that harness has it. [Evidence: the branches and the extractor. Reading: that a variant column is satisfied by the variant, not by cc's superset.]"
},
{
"id": "file-write-create-tool",
"domain": 1,
"domain_name": "Tool set",
"capability": "File write/create tool",
"semantics": "Create or fully overwrite a file",
"cc": "yes",
"cx": "no",
"cc_detail": "✓ Write",
"cx_detail": "—¹",
"catalog_supercode_today": "✓ `write_file` (builtins.rs:119-125)",
"provenance": "cc§1; oc§1; pi§1",
"status": "implemented",
"evidence": [
{
"kind": "tool",
"name": "write_file"
}
],
"note": ""
},
{
"id": "exact-string-edit-tool",
"domain": 1,
"domain_name": "Tool set",
"capability": "Exact-string edit tool",
"semantics": "old→new string replacement with uniqueness check",
"cc": "yes",
"cx": "no",
"cc_detail": "✓ Edit",
"cx_detail": "—¹",
"catalog_supercode_today": "✓ `edit_file` (builtins.rs:170-176)",
"provenance": "cc§1; oc§1; pi§1",
"status": "implemented",
"evidence": [
{
"kind": "tool",
"name": "edit_file"
}
],
"note": ""
},
{
"id": "apply-patch-envelope-multi-file-patch",
"domain": 1,
"domain_name": "Tool set",
"capability": "apply_patch envelope (multi-file patch)",
"semantics": "`*** Begin Patch` grammar adding/updating/deleting files",
"cc": "no",
"cx": "yes",
"cc_detail": "—",
"cx_detail": "✓ (freeform lark + shell form)",
"catalog_supercode_today": "✓ `apply_patch` (builtins.rs:775-776)",
"provenance": "cx§1; oc§1 apply_patch",
"status": "implemented",
"evidence": [
{
"kind": "tool",
"name": "apply_patch"
},
{
"kind": "module",
"name": "tools_apply_patch"
}
],
"note": ""
},
{
"id": "read-before-edit-enforcement",
"domain": 1,
"domain_name": "Tool set",
"capability": "Read-before-edit enforcement",
"semantics": "Edit refuses unless file was read (and unchanged) this conversation",
"cc": "yes",
"cx": "no",
"cc_detail": "✓ (+Bash-view exemptions)",
"cx_detail": "—",
"catalog_supercode_today": "—",
"provenance": "cc§1 Edit",
"status": "implemented",
"evidence": [
{
"kind": "config",
"key": "core.tools.edit_file.require_read_before_edit"
},
{
"kind": "code",
"path": "crates/harness/src/tools/mod.rs",
"symbol": "pub fn read_state(&self, path: &Path) -> ReadState {"
},
{
"kind": "code",
"path": "crates/harness/src/tools/builtins.rs",
"symbol": "crate::tools::ReadState::Stale => {"
},
{
"kind": "code",
"path": "crates/harness/src/tools/builtins.rs",
"symbol": "pub(crate) fn bash_view_target(command: &str) -> Option<String> {"
}
],
"note": "BP-2 closed the \"and unchanged\" half: `ToolContext::read_paths` now maps each read path to its CONTENT HASH at read time, and `edit_file` refuses a path whose bytes changed (or became unreadable) since the model read it, with its own message, distinct from the never-read refusal. A successful edit re-stamps the record, so the model's own consecutive edits are not self-refused. The Bash-view exemptions are implemented as the CC inventory states them (cc§1 Edit): a single-file `cat`/`head`/`tail`/`sed -n`/`grep`/`egrep`/`fgrep` that exited 0 satisfies the rule; pipes, redirects, composition, multi-file views and `sed` without `-n` do not, since a transformed view is not a view of the file."
},
{
"id": "directory-listing",
"domain": 1,
"domain_name": "Tool set",
"capability": "Directory listing",
"semantics": "List entries of a directory as a tool",
"cc": "no",
"cx": "no",
"cc_detail": "—²",
"cx_detail": "—¹",
"catalog_supercode_today": "✓ `list_dir` (builtins.rs:240-246)",
"provenance": "oc§1; pi§1",
"status": "not_applicable",
"evidence": [],
"note": ""
},
{
"id": "glob-filename-search-tool",
"domain": 1,
"domain_name": "Tool set",
"capability": "Glob / filename search tool",
"semantics": "Pattern-match file names (ripgrep/fd-backed)",
"cc": "yes",
"cx": "no",
"cc_detail": "✓ Glob",
"cx_detail": "—¹",
"catalog_supercode_today": "✓ `glob` (builtins.rs:295-296)",
"provenance": "cc§1; oc§1; pi§1",
"status": "implemented",
"evidence": [
{
"kind": "tool",
"name": "glob"
},
{
"kind": "config",
"key": "capabilities.tools_search.glob"
}
],
"note": ""
},
{
"id": "content-search-tool-regex",
"domain": 1,
"domain_name": "Tool set",
"capability": "Content search tool (regex)",
"semantics": "ripgrep-backed content grep with scoping",
"cc": "yes",
"cx": "no",
"cc_detail": "✓ Grep",
"cx_detail": "—¹",
"catalog_supercode_today": "✓ `search` (builtins.rs:360-361)",
"provenance": "cc§1; oc§1; pi§1",
"status": "implemented",
"evidence": [
{
"kind": "tool",
"name": "search"
},
{
"kind": "config",
"key": "capabilities.tools_search.content_search"
}
],
"note": ""
},
{
"id": "one-shot-shell-execution",
"domain": 1,
"domain_name": "Tool set",
"capability": "One-shot shell execution",
"semantics": "Run a shell command, capture output, timeout",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ Bash (+PowerShell)",
"cx_detail": "✓ shell_command",
"catalog_supercode_today": "✓ `bash` (builtins.rs:445-446)",
"provenance": "cc§1; cx§1; oc§1; pi§1",
"status": "implemented",
"evidence": [
{
"kind": "tool",
"name": "bash"
}
],
"note": ""
},
{
"id": "persistent-interactive-shell-session",
"domain": 1,
"domain_name": "Tool set",
"capability": "Persistent/interactive shell session",
"semantics": "PTY-backed session surviving across calls; stdin writable",
"cc": "no",
"cx": "yes",
"cc_detail": "—³",
"cx_detail": "✓ exec_command + write_stdin",
"catalog_supercode_today": "✓ `shell` PersistentShellTool (builtins.rs:981-984)",
"provenance": "cx§1; pi§7 examples",
"status": "implemented",
"evidence": [
{
"kind": "tool",
"name": "shell"
},
{
"kind": "module",
"name": "tools_persistent_shell"
}
],
"note": ""
},
{
"id": "background-async-command-execution",
"domain": 1,
"domain_name": "Tool set",
"capability": "Background/async command execution",
"semantics": "Long-running command detached from the turn",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ run_in_background + /tasks",
"cx_detail": "✓ unified-exec sessions, /ps /stop",
"catalog_supercode_today": "—",
"provenance": "cc§1 Bash; cx§1; oc§10; pi§10",
"status": "implemented",
"evidence": [
{
"kind": "module",
"name": "tools_background"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "out.push(Self::background_exec_schema());"
}
],
"note": ""
},
{
"id": "command-output-monitor-event-feed",
"domain": 1,
"domain_name": "Tool set",
"capability": "Command-output monitor / event feed",
"semantics": "Stream a command's/WebSocket's output lines back as events",
"cc": "yes",
"cx": "no",
"cc_detail": "✓ Monitor (+WS)",
"cx_detail": "—",
"catalog_supercode_today": "—",
"provenance": "cc§1 Monitor",
"status": "irreducible",
"evidence": [],
"note": "Design doc §4.2 cc-parity \"Irreducible gaps\" row **Monitor / WebSocket event feed**: \"UNIQUE CC row (cc§1 Monitor); requires the background-event plumbing above plus network-guard policy.\""
},
{
"id": "notebook-cell-editing",
"domain": 1,
"domain_name": "Tool set",
"capability": "Notebook cell editing",
"semantics": "Jupyter cell-level replace/insert/delete",
"cc": "yes",
"cx": "no",
"cc_detail": "✓ NotebookEdit",
"cx_detail": "—",
"catalog_supercode_today": "—",
"provenance": "cc§1",
"status": "implemented",
"evidence": [
{
"kind": "config",
"key": "core.tools.edit_file.notebook_aware"
},
{
"kind": "code",
"path": "crates/harness/src/tools/builtins.rs",
"symbol": "let result = edit_notebook_cell(self.name(), ctx, &path, &a).await?;"
}
],
"note": ""
},
{
"id": "web-fetch-tool",
"domain": 1,
"domain_name": "Tool set",
"capability": "Web fetch tool",
"semantics": "Fetch a URL, convert to markdown, return to model",
"cc": "yes",
"cx": "no",
"cc_detail": "✓ WebFetch (LLM-extract, cached)",
"cx_detail": "—⁵",
"catalog_supercode_today": "—",
"provenance": "cc§1; oc§1; pi§10",
"status": "implemented",
"evidence": [
{
"kind": "module",
"name": "tools_web"
},
{
"kind": "tool",
"name": "web_fetch"
},
{
"kind": "code",
"path": "crates/harness/src/tools/builtins.rs",
"symbol": "crate::tools::convert::html_to_markdown(&body)"
},
{
"kind": "code",
"path": "crates/harness/src/tools/builtins.rs",
"symbol": "pub(crate) fn web_cache_get(url: &str) -> Option<(String, u64)> {"
}
],
"note": "BP-2: an HTML response is converted to markdown before the model sees it (headings, links, list items, emphasis and code survive; `script`/`style`/comments are dropped and entities decoded), non-HTML content types are returned untouched, and a successful fetch is cached on disk for 15 minutes — CC's WebFetch window — keyed by URL, with the URL stored inside the entry so a hash collision or a hand-edited cache directory can never serve one page under another's name. A cache hit says so in its notice. Not identical to CC's WebFetch in one named respect: CC additionally runs an LLM extraction pass over the page against the caller's prompt; supercode returns the converted page itself, which is this row's stated semantics (\"convert to markdown, return to model\") — the extraction pass is a model call, not a fetch behavior. cx: Codex has no web-fetch tool at all (`fetch = false` in cx-parity), so the row is cc-only."
},
{
"id": "web-search-tool",
"domain": 1,
"domain_name": "Tool set",
"capability": "Web search tool",
"semantics": "Provider/server-backed search",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ WebSearch (Anthropic-side)",
"cx_detail": "✓ hosted web_search (cached/indexed/live)",
"catalog_supercode_today": "—",
"provenance": "cc§1; cx§1; oc§1; pi§10",
"status": "implemented",
"evidence": [
{
"kind": "module",
"name": "tools_web"
},
{
"kind": "tool",
"name": "web_search"
},
{
"kind": "code",
"path": "crates/harness/src/tools/builtins.rs",
"symbol": "pub const DEFAULT_WEB_SEARCH_URL: &str = \"https://html.duckduckgo.com/html/\";"
},
{
"kind": "code",
"path": "crates/harness/src/tools/convert.rs",
"symbol": "pub fn parse_html_search_results(html: &str) -> Vec<SearchResult> {"
}
],
"note": "BP-2: the tool works with no operator configuration at all — it queries DuckDuckGo's public HTML endpoint (no key, no account, the same surface a browser gets) and renders the extracted hits as a numbered title/url/snippet list, unwrapping the engine's redirector so the URLs are the real destinations. `SUPERCODE_WEB_SEARCH_URL` still overrides the endpoint for an operator who wants their own. A results page whose markup is not recognized falls back to the page as markdown rather than to a false \"no results\", and an unreachable backend names the endpoint it tried and the override. Not identical to either harness's mechanism: CC's search executes provider-side and Codex's is hosted (cached/indexed/live); supercode's runs client-side. Same row semantics — \"provider/server-backed search\" that works out of the box — reached through supercode's own door."
},
{
"id": "plan-task-checklist-tool",
"domain": 1,
"domain_name": "Tool set",
"capability": "Plan / task-checklist tool",
"semantics": "Model-maintained step list with statuses",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ TaskCreate/Update (TodoWrite legacy)",
"cx_detail": "✓ update_plan",
"catalog_supercode_today": "✓ `update_plan` (builtins.rs:1133-1134)",
"provenance": "cc§1; cx§1; oc§1; pi§10",
"status": "implemented",
"evidence": [
{
"kind": "tool",
"name": "update_plan"
},
{
"kind": "module",
"name": "todos"
}
],
"note": ""
},
{
"id": "sub-agent-spawn-tool",
"domain": 1,
"domain_name": "Tool set",
"capability": "Sub-agent spawn tool",
"semantics": "Spawn a child agent with own context; parent gets result",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ Agent (Task)",
"cx_detail": "✓ multi_agent v1/v2 spawn_agent",
"catalog_supercode_today": "—",
"provenance": "cc§1; cx§1; oc§1; pi§3",
"status": "implemented",
"evidence": [
{
"kind": "module",
"name": "subagents"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "out.push(self.spawn_subagent_schema());"
}
],
"note": ""
},
{
"id": "structured-user-question-tool",
"domain": 1,
"domain_name": "Tool set",
"capability": "Structured user-question tool",
"semantics": "Model asks user multiple-choice/free-text questions mid-run",
"cc": "yes",
"cx": "variant",
"cc_detail": "✓ AskUserQuestion",
"cx_detail": "✓* request_user_input (experimental)",
"catalog_supercode_today": "—",
"provenance": "cc§1; cx§1; oc§1",
"status": "implemented",
"evidence": [
{
"kind": "tool",
"name": "ask_user"
},
{
"kind": "module",
"name": "tools_question"
},
{
"kind": "code",
"path": "crates/harness/src/tools/question.rs",
"symbol": "pub const REQUEST_USER_INPUT"
},
{
"kind": "code",
"path": "crates/harness/src/server.rs",
"symbol": "set_user_question_handler(Arc::new(FrontendElicitationHandler("
}
],
"note": "`ask_user` (crates/harness/src/tools/question.rs) takes Claude Code's AskUserQuestion shape — 1-4 questions, labelled options, `multiSelect`, free-text fallback — and asks through the elicitation handler the design names as this module's protocol side, so under an SDK-owned runtime the request is published into the sequenced frontend stream and the turn BLOCKS until `harness.v1.runtimes.respond` answers it; the TUI bridge installs the same seam. cx-parity registers Codex's experimental spelling `request_user_input` as a second name for the SAME tool object. Two named differences from the harnesses: a question is answered on `respond` but is NOT listed by `harness.v1.approvals.list`, which filters to allow/deny approvals by design; and headless (no interactive frontend) is deny-default per module 6's own rule, telling the model nobody can be asked rather than blocking."
},
{
"id": "plan-mode-enter-exit-tools",
"domain": 1,
"domain_name": "Tool set",
"capability": "Plan-mode enter/exit tools",
"semantics": "Model-invocable mode transitions with plan approval",
"cc": "yes",
"cx": "no",
"cc_detail": "✓ Enter/ExitPlanMode",
"cx_detail": "—⁶",
"catalog_supercode_today": "—",
"provenance": "cc§1; oc§1; pi§10",
"status": "implemented",
"evidence": [
{
"kind": "tool",
"name": "enter_plan_mode"
},
{
"kind": "tool",
"name": "exit_plan_mode"
},
{
"kind": "module",
"name": "plan_mode"
},
{
"kind": "code",
"path": "crates/harness/src/tools/plan_mode.rs",
"symbol": "pub struct ExitPlanModeTool"
}
],
"note": "`enter_plan_mode`/`exit_plan_mode` are registered under cc-parity by `[capabilities.plan_mode]`. Entering narrows the permissions engine (see `plan-mode-read-only-research-phase`); exiting is a real approval — the plan travels in a `permissions::ApprovalRequest` answered by the session's own approval door (the frontend request broker under an SDK-owned runtime, so `approvals list` shows it and `respond` answers it), and a refusal keeps the mode on with the plan intact. No approval door attached means the exit is refused, never self-approved."
},
{
"id": "skill-invocation-surface",
"domain": 1,
"domain_name": "Tool set",
"capability": "Skill-invocation surface",
"semantics": "Load a skill's body on demand",
"cc": "yes",
"cx": "variant",
"cc_detail": "✓ Skill tool",
"cx_detail": "✓* `$slug` mention / implicit match (no tool)",
"catalog_supercode_today": "partial (prompt templates only, config.rs:193-194)",
"provenance": "cc§1; cx§2; oc§1; pi§2",
"status": "implemented",
"evidence": [
{
"kind": "tool",
"name": "skill"
},
{
"kind": "config",
"key": "core.skills.harness"
},
{
"kind": "code",
"path": "crates/harness/src/tools/skill.rs",
"symbol": "pub const SKILL_TOOL: &str = \"skill\";"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "fn expand_skill_mentions(&self, input: &str) -> String {"
},
{
"kind": "code",
"path": "crates/harness/src/skills.rs",
"symbol": "pub fn find_skill<'a>(skills: &'a [LoopSkill], name: &str) -> Option<&'a LoopSkill> {"
}
],
"note": "BP-6: one `skill` tool — Claude Code's own shape, one tool through which every package is invoked rather than one tool per package. The model calls it with a name from the prompt index and the body is read from disk on that call, with `$ARGUMENTS` / `$1`..`$9` substituted; an unknown name is refused by naming the set that WAS discovered. cx's cell is a variant because Codex has no skill TOOL, and both of Codex's own doors are honored under `cx-parity`: a `$slug` mention APPENDS the body to the user's turn without replacing their text (capped at six loads per message), and the implicit description match sits behind `[core.skills] implicit_match`, off in the preset because an implicit load spends a body's tokens the user never asked for. The bare `/name` form is Claude Code's, so it is honored only where the config reads Claude Code's roots; `/skill:name` is pi's explicit form and works under every skills-enabled preset. All four doors resolve one name through one resolver (`find_skill`) and render one envelope (`render_skill`), so a transcript reads the same whichever door fired. Proved over both resolved presets in `crates/harness/tests/bp6_skills_parity.rs`."
},
{
"id": "deferred-tool-loading-tool-search",
"domain": 1,
"domain_name": "Tool set",
"capability": "Deferred tool loading (tool_search)",
"semantics": "Tool schemas kept out of context until searched/activated",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ ToolSearch",
"cx_detail": "✓ tool_search (BM25, native Deferred exposure)",
"catalog_supercode_today": "✓ `ToolAdvertising::Deferred` (config.rs:66-76)",
"provenance": "cc§1,§7; cx§1",
"status": "implemented",
"evidence": [
{
"kind": "module",
"name": "deferred_tools"
},
{
"kind": "config",
"key": "capabilities.deferred_tools.core"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "out.push(Self::tool_search_schema());"
}
],
"note": ""
},
{
"id": "tool-exposure-tiers-direct-deferred-hidden",
"domain": 1,
"domain_name": "Tool set",
"capability": "Tool exposure tiers (direct/deferred/hidden)",
"semantics": "Per-tool visibility level to model vs dispatcher",
"cc": "variant",
"cx": "yes",
"cc_detail": "✓* (bare-name deny removes from context)",
"cx_detail": "✓ ToolExposure enum",
"catalog_supercode_today": "✓ ToolOverride.enabled (config.rs:101-104)",
"provenance": "cc§4; cx§1; oc§4; pi§7",
"status": "implemented",
"evidence": [
{
"kind": "config",
"key": "capabilities.deferred_tools.core"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "ToolAdvertising::Deferred { core } => core.iter().any(|c| c == name),"
}
],
"note": ""
},
{
"id": "mcp-resource-list-read-tools",
"domain": 1,
"domain_name": "Tool set",
"capability": "MCP resource list/read tools",
"semantics": "Enumerate/read MCP server resources",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓",
"cx_detail": "✓ (+templates)",
"catalog_supercode_today": "—",
"provenance": "cc§1; cx§1; oc§1",
"status": "implemented",
"evidence": [
{
"kind": "module",
"name": "mcp"
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "config.module_activation.is_active(ModuleId::McpClient)"
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "for t in handle.resource_tools() {"
}
],
"note": "McpResourcesListTool/McpResourceReadTool are built per server by McpServerHandle::resource_tools and registered by attach_mcp_with_elicitation. BP-1 removed the [experimental] module_registry conjunct from mcp_module_on, which is now exactly \"is ModuleId::McpClient in the resolved activation set\" — true under both parity presets ([capabilities.mcp] enabled = true), so the registration past `if !module_on { continue; }` runs and the resource tools reach the model."
},
{
"id": "code-mode-code-cell-tool-orchestration",
"domain": 1,
"domain_name": "Tool set",
"capability": "Code mode (code-cell tool orchestration)",
"semantics": "Model writes code that calls other tools programmatically",
"cc": "no",
"cx": "yes",
"cc_detail": "—",
"cx_detail": "✓ exec/wait cells (feature)",
"catalog_supercode_today": "—",
"provenance": "cx§1; oc§1",
"status": "irreducible",
"evidence": [],
"note": "Design doc §4.3 cx-parity \"Irreducible gaps\": **Freeform lark-grammar custom tools** (\"`ToolSpec::Custom` (apply_patch, code-mode `exec`) is a *Responses-API wire type* … there is no chat-wire equivalent\"), and the **Long tail** row, which names \"Code mode (`exec`/`wait` cells)\" explicitly."
},
{
"id": "image-generation-tool",
"domain": 1,
"domain_name": "Tool set",
"capability": "Image generation tool",
"semantics": "Provider-executed image creation",
"cc": "no",
"cx": "yes",
"cc_detail": "—",
"cx_detail": "✓ image_gen (feature)",
"catalog_supercode_today": "—",
"provenance": "cx§1",
"status": "implemented",
"evidence": [
{
"kind": "tool",
"name": "image_gen"
},
{
"kind": "code",
"path": "crates/harness/src/tools/image_gen.rs",
"symbol": "unsupported_action: the configured provider exposes no image endpoint"
}
],
"note": "`image_gen` posts the prompt to the SESSION's own provider (`{base_url}/images/generations`, the OpenAI-compatible route, with the same credential the chat provider uses), writes the returned bytes into the working directory through the same sandbox check and write observers every other write-capable tool passes, and returns the path. The generation itself runs on the provider, which is the row's semantics; the CALL is client-issued, so this is not the hosted-tool channel the irreducible \"server-executed tools\" row describes — a provider without an images route gets a named `unsupported_action` refusal rather than a fabricated file."
},
{
"id": "clock-sleep-tools",
"domain": 1,
"domain_name": "Tool set",
"capability": "Clock / sleep tools",
"semantics": "Current-time reminder; pause up to hours, wake on input",
"cc": "variant",
"cx": "yes",
"cc_detail": "✓* ScheduleWakeup (loop pacing)",
"cx_detail": "✓ clock/curr_time + sleep (features)",
"catalog_supercode_today": "—",
"provenance": "cc§1; cx§1",
"status": "implemented",
"evidence": [
{
"kind": "tool",
"name": "current_time"
},
{
"kind": "tool",
"name": "sleep"
},
{
"kind": "code",
"path": "crates/harness/src/tools/clock.rs",
"symbol": "pub const MAX_SLEEP_SECS"
}
],
"note": "`current_time` returns the instant as RFC3339 UTC (through `sidecar::ms_to_rfc3339`, the one clock rendering this workspace has) plus the IANA zone and UTC offset where the platform reports them; `sleep` pauses the turn for a bounded number of seconds (4h ceiling) and is cancel-safe, so an interrupt drops the timer with the turn. Both are optional default-tool names in cc-parity's and cx-parity's `[core.tools] enabled`, the `view_image` precedent. Neither is a scheduler: nothing here starts background work, which is the honest difference from cc's `ScheduleWakeup` loop pacing (the row's `✓*`)."
},
{
"id": "context-budget-tools",
"domain": 1,
"domain_name": "Tool set",
"capability": "Context-budget tools",
"semantics": "`new_context` fresh window; `get_context_remaining`",
"cc": "no",
"cx": "yes",
"cc_detail": "—",
"cx_detail": "✓ (token_budget feature)",
"catalog_supercode_today": "—",
"provenance": "cx§1",
"status": "implemented",
"evidence": [
{
"kind": "tool",
"name": "get_context_remaining"
},
{
"kind": "tool",
"name": "new_context"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "fn apply_pending_new_context"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "pub fn context_usage"
}
],
"note": "Both tools are the MODEL's door onto mechanisms the agent already owns, not a second implementation of either: `get_context_remaining` returns `Agent::context_usage()` verbatim (the same struct `/context` prints, over the same estimates the context guard enforces, so what the model reads and what refuses an oversized turn can never disagree), computed at the moment the tool asks; `new_context` parks a request that `Agent::apply_pending_new_context` hands to `Agent::new_context` — the same in-session handoff the operator's `/handoff` runs — as soon as the tool round ends, so the next request is the fresh window. Named residue: the keep-set is the objective plus the recent tail (the session's own keep-recent token budget by default), not an arbitrary curated selection, and the set-aside turns are retained only where a transcript sidecar is attached — which the handoff marker states outright rather than implying."
},
{
"id": "model-requested-permission-grants",
"domain": 1,
"domain_name": "Tool set",
"capability": "Model-requested permission grants",
"semantics": "Tool for the model to ask for fs/network grants mid-session",
"cc": "no",
"cx": "yes",
"cc_detail": "—",
"cx_detail": "✓ request_permissions (feature)",
"catalog_supercode_today": "—",
"provenance": "cx§1",
"status": "partial",
"evidence": [
{
"kind": "config",
"key": "capabilities.permissions.approval"
},
{
"kind": "code",
"path": "crates/harness/src/permissions/mod.rs",
"symbol": "crate::config::ApprovalPolicy::ModelRequested => Decision::Allow,"
}
],
"note": "The `model_requested` approval MODE is real and wired (cx-parity sets it; the permissions gate defaults it to Allow so the model is not prompted). The tool is what is missing: nothing lets the model ASK for an fs/network grant mid-session — escalation is driven by `sandbox.escalation`, never model-initiated."
},
{
"id": "custom-user-defined-tools",
"domain": 1,
"domain_name": "Tool set",
"capability": "Custom/user-defined tools",
"semantics": "User-authored tools registered into the loop",
"cc": "no",
"cx": "variant",
"cc_detail": "—⁷",
"cx_detail": "✓* dynamic tools (app-server hosts) + extension tools",
"catalog_supercode_today": "partial (Rust `Tool` trait for embedders; no file discovery)",
"provenance": "cx§1; oc§1; pi§7",
"status": "partial",
"evidence": [
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "crate::plugins::register_into(&config, &mut registry);"
}
],
"note": "Embedders can implement the Rust `Tool` trait, and the `plugins` module can register a trusted plugin's declared tools — but `capabilities.plugins` is unset in cx-parity (so `plugins::register_into` no-ops) and there is no file-discovered user tool directory; user-authored tools reach the loop only via MCP."
},
{
"id": "per-tool-description-schema-override",
"domain": 1,
"domain_name": "Tool set",
"capability": "Per-tool description/schema override",
"semantics": "Rewrite what the model sees for a tool",
"cc": "no",
"cx": "no",
"cc_detail": "—",
"cx_detail": "—",
"catalog_supercode_today": "✓ ToolOverride.description + SchemaTier (config.rs:98-110, 219-225)",
"provenance": "oc§1; pi§1",
"status": "not_applicable",
"evidence": [],
"note": ""
},
{
"id": "tool-output-truncation-with-recoverable-spill",
"domain": 1,
"domain_name": "Tool set",
"capability": "Tool-output truncation with recoverable spill",
"semantics": "Oversized output truncated; full content kept reachable",
"cc": "yes",
"cx": "variant",
"cc_detail": "✓ (Bash overflow→session file)",
"cx_detail": "✓* token-capped (`original_token_count`, no spill file)",
"catalog_supercode_today": "✓* truncation + lossless sidecar (config.rs:158-162; reduce.rs:95-103 ToolOutputTruncated)",
"provenance": "cc§1; cx§1; oc§1; pi§1",
"status": "implemented",
"evidence": [
{
"kind": "config",
"key": "core.tool_output_spill"
},
{
"kind": "tool",
"name": "bash"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "fn spill_tool_output(&self, full: &str) -> Option<std::path::PathBuf> {"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "format!(\"; full output spilled to {} — {door}\", path.display())"
}
],
"note": "BP-2: with `core.tool_output_spill` (set by both parity presets) a capped result's FULL bytes are written to a per-session spill file — beside the session sidecar when one is recording, else a per-process temp directory — and the cap notice names that path plus the door the preset actually has: `read_file` under cc-parity, `cat` under cx-parity, whose whole read pathway is the shell. The recovery therefore no longer depends on `expand_reduction`, which is advertised only alongside a ReductionPolicy that `capabilities.reduction = false` never installs. Default-off for embedders: an SDK caller who never asked for disk writes gets today's notice, byte-identical."
},
{
"id": "parallel-tool-call-execution",
"domain": 1,
"domain_name": "Tool set",
"capability": "Parallel tool-call execution",
"semantics": "Independent sibling calls run concurrently",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ batches (+PostToolBatch, concurrency cap)",
"cx_detail": "✓ RwLock gate (shell tools parallel)",
"catalog_supercode_today": "—",
"provenance": "cc§1; cx§1; oc§6; pi§1",
"status": "implemented",
"evidence": [
{
"kind": "config",
"key": "core.parallel_tool_calls"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "let results = futures::future::join_all(futs).await;"
}
],
"note": "BP-2: both parity presets now set `core.parallel_tool_calls = true`, so an assistant turn's independent sibling calls actually run as a concurrent batch under cc-parity and cx-parity (CC batches with a concurrency cap; Codex runs shell tools in parallel behind its RwLock gate). Dispatch stays strictly sequential where it must be — approvals, doom-loop detection, pre-tool hooks and every `record`/`history` append — so the sidecar's append-order invariant (S1.13) is unchanged. pi-core keeps the sequential path."
},
{
"id": "malformed-tool-call-recovery",
"domain": 1,
"domain_name": "Tool set",
"capability": "Malformed-tool-call recovery",
"semantics": "Invalid calls surfaced to model as tool error, loop continues",
"cc": "no",
"cx": "no",
"cc_detail": "—",
"cx_detail": "—",
"catalog_supercode_today": "—",
"provenance": "oc§1",
"status": "not_applicable",
"evidence": [],
"note": ""
},
{
"id": "lsp-diagnostics-in-edit-path",
"domain": 1,
"domain_name": "Tool set",
"capability": "LSP diagnostics in edit path",
"semantics": "Type errors/lint fed back after edit/write",
"cc": "variant",
"cx": "no",
"cc_detail": "✓* (plugin-gated LSP, auto-reports post-edit)",
"cx_detail": "—",
"catalog_supercode_today": "—",
"provenance": "cc§1 LSP; oc§7,§10",
"status": "partial",
"evidence": [
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "let lsp_manager = crate::lsp::manager_for_config(config);"
}
],
"note": "`LspDiagnosticsObserver` is wired into the shared write-path seam and does feed diagnostics back into edit/write results — but `[capabilities.lsp] enabled = false` in cc-parity, so no preset user gets them, and the module only ever spawns servers named explicitly under `capabilities.lsp.servers` (no auto-provisioning)."
},
{
"id": "lsp-query-tool-defs-refs-hover-symbols",
"domain": 1,
"domain_name": "Tool set",
"capability": "LSP query tool (defs/refs/hover/symbols)",
"semantics": "On-demand code-intelligence queries by the model",
"cc": "yes",
"cx": "no",
"cc_detail": "✓ (plugin-gated)",
"cx_detail": "—",
"catalog_supercode_today": "—",
"provenance": "cc§1; oc§1",
"status": "absent",
"evidence": [],
"note": "`crate::lsp`'s module doc records this as a deliberate gap: \"No `/find/symbol` symbol-indexing query tool … none is exposed\" — no defs/refs/hover/symbols surface exists, and no `query`/`symbols` key is even parsed.",
"cost": "architectural"
},
{
"id": "hosted-server-executed-tools",
"domain": 1,
"domain_name": "Tool set",
"capability": "Hosted/server-executed tools",
"semantics": "Tools executed provider-side, not by the client",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ advisor, WebSearch",
"cx_detail": "✓ web_search, image_gen",
"catalog_supercode_today": "—",
"provenance": "cc§1; cx§1",
"status": "irreducible",
"evidence": [],
"note": "Design doc §4.2 cc-parity \"Irreducible gaps\" row **Server-executed tools**: WebSearch's Anthropic-side backend and the `advisor` server tool are \"provider-side, not composable client-side. Our `tools_web.search` must use a third-party backend: behavioral, not result, parity.\""
},
{
"id": "computer-use-browser-control",
"domain": 1,
"domain_name": "Tool set",
"capability": "Computer use / browser control",
"semantics": "Drive native apps or a real browser",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ (macOS computer-use; --chrome)",
"cx_detail": "✓ (browser_use/computer_use features)",
"catalog_supercode_today": "—",
"provenance": "cc§1,§10; cx§10",
"status": "partial",
"evidence": [
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "register_browser_tools(&mut registry);"
}
],
"note": "A provider-independent browser capability exists (`crate::browser`), but `register_browser_tools` is called only from `supercode mcp serve` — neither parity preset puts browser operations in the agent's own registry — and there is no native computer-use surface. Design doc §4.2's **Ecosystem surface** irreducible row also places computer-use/Chrome outside preset scope."
},
{
"id": "auto-provisioned-search-binaries",
"domain": 1,
"domain_name": "Tool set",
"capability": "Auto-provisioned search binaries",
"semantics": "Harness downloads pinned rg/fd when missing",
"cc": "variant",
"cx": "no",
"cc_detail": "✓* (USE_BUILTIN_RIPGREP bundled)",
"cx_detail": "—",
"catalog_supercode_today": "—",
"provenance": "cc§6 env; oc§7; pi§1",
"status": "implemented",
"evidence": [
{
"kind": "tool",
"name": "glob"
},
{
"kind": "tool",
"name": "search"
},
{
"kind": "code",
"path": "crates/harness/src/tools/builtins.rs",
"symbol": "let walker = ignore::WalkBuilder::new(&root).build();"
},
{
"kind": "code",
"path": "crates/harness/src/tools/builtins.rs",
"symbol": "if let Ok(paths) = glob::glob(&full) {"
}
],
"note": "BP-2 re-grade (mechanism differs, outcome is the row's). What this row is FOR is that the search tools work on a box where the user installed nothing — which is why CC's own cell is a variant (`✓*` bundled ripgrep, not a download) and why supercode's `glob`/`search` need no provisioning step at all: they run IN-PROCESS (the `glob` crate; an `ignore::WalkBuilder` gitignore-respecting walk with a regex matcher), so under cc-parity both tools are registered and functional with no external binary, no download, no PATH lookup and no version pin to drift. Nothing here downloads `rg`/`fd`, and nothing needs to. [Evidence: the two in-process implementations and their registration under cc-parity. Reading: that the row's semantics are the guarantee (search available without user installation), not the mechanism (a download) — the harness columns already disagree about the mechanism.]",
"cost": "trivial"
},
{
"id": "built-in-system-prompt-replaceable-appendable",
"domain": 2,
"domain_name": "Prompt / context architecture",
"capability": "Built-in system prompt, replaceable/appendable",
"semantics": "Harness prompt with user override + append levers",
"cc": "yes",
"cx": "variant",
"cc_detail": "✓ (--system-prompt / --append-*)",
"cx_detail": "✓* per-model file, `model_instructions_file`",
"catalog_supercode_today": "✓ `system_prompt` (config.rs:131-132, DEFAULT_SYSTEM_PROMPT)",
"provenance": "cc§2; cx§2; oc§2; pi§2",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "let base_prompt_live = base_prompt_for_config(&config);"
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "if let Some(sp) = &cli.system_prompt {"
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "if let Some(extra) = &cli.append_system_prompt {"
}
],
"note": ""
},
{
"id": "per-model-family-base-prompt-selection",
"domain": 2,
"domain_name": "Prompt / context architecture",
"capability": "Per-model-family base-prompt selection",
"semantics": "Different bundled system prompt per model family",
"cc": "no",
"cx": "yes",
"cc_detail": "—",
"cx_detail": "✓ (gpt-5.x prompt files)",
"catalog_supercode_today": "—",
"provenance": "cx§2; oc§2",
"status": "implemented",
"evidence": [
{
"kind": "config",
"key": "capabilities.model_catalog.base_prompts"
},
{
"kind": "code",
"path": "crates/harness/src/model_catalog.rs",
"symbol": "pub fn base_prompt_for"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "fn base_prompt_for_config"
}
],
"note": "`[capabilities.model_catalog] base_prompts` maps a model-id glob to that family's base system prompt, selected at prompt assembly (most specific — longest — pattern wins, so a TOML table's lack of order cannot decide it) and RE-SELECTED on `Agent::set_model`, the way cx re-selects `base_instructions` when the model changes; the stale text is located and replaced, the same mechanism `refresh_env_context` uses. cx-parity carries two entries, split on the one functional difference in cx's own prompt-file set: the codex-tuned families are taught the apply_patch envelope, the general gpt-5 families are not. The texts are supercode's own, never a copy of upstream's. A model matching no pattern keeps `core.system_prompt`, so cc-parity (no table) is byte-identical to before."
},
{
"id": "project-instruction-files-w-directory-walk",
"domain": 2,
"domain_name": "Prompt / context architecture",
"capability": "Project instruction files w/ directory walk",
"semantics": "AGENTS.md/CLAUDE.md discovered up/down the tree, concatenated",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ CLAUDE.md tiers + nested on-demand",
"cx_detail": "✓ AGENTS.md root→cwd (+override files, 32KiB cap)",
"catalog_supercode_today": "✓ `load_project_context` (config.rs:171-172)",
"provenance": "cc§2; cx§2; oc§2; pi§2",
"status": "implemented",
"evidence": [
{
"kind": "config",
"key": "core.project_context"
},
{
"kind": "config",
"key": "core.project_root_markers"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "fn instruction_walk_roots(config: &Config) -> Vec<std::path::PathBuf> {"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "for root in walk.iter().chain(config.additional_dirs.iter()) {"
}
],
"note": "BP-4 added the ANCESTOR half: `instruction_walk_roots` climbs from `cwd` to the first directory carrying a `core.project_root_markers` entry (`.git`, now set by both presets), bounded at 64 levels, and `assemble_project_instructions` concatenates the chain outermost-first so the nearest directory wins by appearing last — cc§2's \"concatenated root→cwd, closest read last\" and cx§2's \"nearer-to-cwd wins by appearing later\", the same ordering. The downward half (`core.nested_instructions`) stays cc-parity-only, matching the inventories: CC loads subdir CLAUDE.md on demand, Codex does not."
},
{
"id": "global-user-level-instruction-file",
"domain": 2,
"domain_name": "Prompt / context architecture",
"capability": "Global/user-level instruction file",
"semantics": "Home-scoped instructions loaded every session",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ ~/.claude/CLAUDE.md",
"cx_detail": "✓ $CODEX_HOME/AGENTS.md",
"catalog_supercode_today": "—",
"provenance": "cc§2; cx§2; oc§2; pi§2",
"status": "implemented",
"evidence": [
{
"kind": "config",
"key": "core.project_context"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "let global_dir = global_instructions_dir();"
}
],
"note": ""
},
{
"id": "cross-harness-instruction-interop",
"domain": 2,
"domain_name": "Prompt / context architecture",
"capability": "Cross-harness instruction interop",
"semantics": "Reads the *other* harness's context file natively",
"cc": "variant",
"cx": "no",
"cc_detail": "✓* (@AGENTS.md import bridge, manual)",
"cx_detail": "—",
"catalog_supercode_today": "✓ (loads both CLAUDE.md and AGENTS.md)",
"provenance": "cc§2; oc§2; pi§2; config.rs:171",
"status": "implemented",
"evidence": [
{
"kind": "config",
"key": "core.project_context"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "for name in [\"CLAUDE.md\", \"AGENTS.md\"] {"
}
],
"note": ""
},
{
"id": "nested-instruction-files-loaded-on-demand",
"domain": 2,
"domain_name": "Prompt / context architecture",
"capability": "Nested instruction files loaded on demand",
"semantics": "Subdir context injected only when files there are touched",
"cc": "yes",
"cx": "no",
"cc_detail": "✓",
"cx_detail": "—⁸",
"catalog_supercode_today": "—",
"provenance": "cc§2; oc§2",
"status": "implemented",
"evidence": [
{
"kind": "config",
"key": "core.nested_instructions"
},
{
"kind": "code",
"path": "crates/harness/src/tools/builtins.rs",
"symbol": "if let Some(notice) = nested_instructions_notice(ctx, &path) {"
}
],
"note": ""
},
{
"id": "instruction-imports-extra-instruction-files",
"domain": 2,
"domain_name": "Prompt / context architecture",
"capability": "Instruction imports / extra instruction files",
"semantics": "`@path` imports or `instructions[]` incl. remote URLs",
"cc": "yes",
"cx": "no",
"cc_detail": "✓ @path (depth 4)",
"cx_detail": "—",
"catalog_supercode_today": "—",
"provenance": "cc§2; oc§2",
"status": "implemented",
"evidence": [
{
"kind": "config",
"key": "core.instruction_imports"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "expand_instruction_imports(text, dir, root, project_scoped, 0)"
}
],
"note": ""
},
{
"id": "path-scoped-rules",
"domain": 2,
"domain_name": "Prompt / context architecture",
"capability": "Path-scoped rules",
"semantics": "Rule files activated only when matching files are touched",
"cc": "yes",
"cx": "no",
"cc_detail": "✓ `.claude/rules` `paths:`",
"cx_detail": "—",
"catalog_supercode_today": "—",
"provenance": "cc§2",
"status": "implemented",
"evidence": [
{
"kind": "config",
"key": "core.path_rules"
},
{
"kind": "code",
"path": "crates/harness/src/path_rules.rs",
"symbol": "pub fn load"
},
{
"kind": "code",
"path": "crates/harness/src/tools/builtins.rs",
"symbol": "fn path_rules_notice"
}
],
"note": "`core.path_rules` reads `.claude/rules/*.md` from the user tier and every directory of the instruction walk. A rule with no `paths:` joins the instruction blob at construction, beside CLAUDE.md/AGENTS.md; a rule WITH `paths:` is held back and injected as a tool-result notice the first time a tool touches a matching file — the same door `core.nested_instructions` already used, with the selector swapped from the touched directory to the rule's globs, and deduped so a rule is injected once per conversation. gitignore's zero-directory `**/` reading is supplied as a second candidate spelling, so `src/**/*.rs` covers `src/lib.rs`. cx-parity sets nothing and opens no rules directory."
},
{
"id": "instruction-file-hygiene-controls",
"domain": 2,
"domain_name": "Prompt / context architecture",
"capability": "Instruction-file hygiene controls",
"semantics": "Excludes, size caps, comment stripping",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ claudeMdExcludes + HTML-comment strip",
"cx_detail": "✓ project_doc_max_bytes / fallback names",
"catalog_supercode_today": "—",
"provenance": "cc§2; cx§2",
"status": "implemented",
"evidence": [
{
"kind": "config",
"key": "core.project_doc_max_bytes"
},
{
"kind": "config",
"key": "core.project_doc_excludes"
},
{
"kind": "config",
"key": "core.project_doc_strip_comments"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "fn instruction_file_excluded("
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "fn strip_html_comments(text: &str) -> String {"
}
],
"note": "All three of the row's levers exist and each preset arms ITS harness's documented ones: cx-parity sets `project_doc_max_bytes = 32768` (cx§2's documented default, spent incrementally by `InstructionBudget` as files concatenate root→cwd — per-file truncation notice, then an aggregate notice once the budget is gone); cc-parity sets `project_doc_strip_comments = true` (cc§2 block `<!-- … -->` stripping) and an empty `project_doc_excludes` (cc§2 `claudeMdExcludes`, which CC ships empty), plus `project_doc_max_bytes = 0` — §3.1's spelling for uncapped, which is what CC documents. `project_doc_excludes` is project-forbidden (§3.3): it can suppress the user's own global tier."
},
{
"id": "managed-enterprise-instruction-injection",
"domain": 2,
"domain_name": "Prompt / context architecture",
"capability": "Managed/enterprise instruction injection",
"semantics": "Org-pushed instructions above user layer",
"cc": "yes",
"cx": "variant",
"cc_detail": "✓ managed CLAUDE.md / `claudeMd` key",
"cx_detail": "✓* (managed config layers)",
"catalog_supercode_today": "—",
"provenance": "cc§2; cx§6; oc§6",
"status": "absent",
"evidence": [],
"note": "STAYS OPEN, and the honest state is a refusal by absence rather than a message: `crate::configfile` resolves exactly two layers — a trusted user/global layer and a narrowing-only project layer — so there is no tier ABOVE the user's for an org to push into, and nothing reads cc's managed instruction paths (`/Library/Application Support/ClaudeCode/CLAUDE.md`, `/etc/claude-code/CLAUDE.md`, the managed-settings `claudeMd` key) or cx's managed config layers. A managed CLAUDE.md on the box is simply not in the prompt. BP-5 deliberately did not fake it: an org-pushed instruction is only meaningful if the layer carrying it cannot be overridden from below, which is a settings-precedence tier with its own enforcement keys — BP-14's managed layer — not a prompt-assembly input like the other seven rows in this cut. Re-graded trivial → architectural for that reason: the missing piece is a trust tier, not a knob.",
"cost": "architectural"
},
{
"id": "auto-memory-agent-maintained-cross-session",
"domain": 2,
"domain_name": "Prompt / context architecture",
"capability": "Auto memory (agent-maintained, cross-session)",
"semantics": "Harness-curated memory dir auto-loaded per project",
"cc": "yes",
"cx": "variant",
"cc_detail": "✓ MEMORY.md + topic files",
"cx_detail": "✓* memories pipeline (experimental, off)",
"catalog_supercode_today": "—",
"provenance": "cc§2; cx§7",
"status": "absent",
"evidence": [],
"note": "`memory` is a `MODULE_NAMES` entry consulted only by `validate_modules`' D-9 small-model check; there is no memory directory, no MEMORY.md loader, and no curation pipeline. `capabilities.memory` is also off in cx-parity.",
"cost": "architectural"
},
{
"id": "environment-context-block",
"domain": 2,
"domain_name": "Prompt / context architecture",
"capability": "Environment context block",
"semantics": "cwd/git/platform/date/policy injected as structured context",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ startup context",
"cx_detail": "✓ `<environment_context>` (re-emitted on change)",
"catalog_supercode_today": "—",
"provenance": "cc§2; cx§2; oc§2; pi§2",
"status": "implemented",
"evidence": [
{
"kind": "config",
"key": "core.env_context"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "approval policy: {} · sandbox: {}"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "pub fn refresh_env_context(&mut self) -> bool {"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "self.refresh_env_context();"
}
],
"note": "The block now carries the POLICY line the semantics name — `approval policy: <mode> · sandbox: <tier>`, in the config schema's own vocabulary — alongside cwd/platform/date/git branch, and `Agent::refresh_env_context` re-derives it once per user turn (`run_loop`), replacing the stale copy in the system message when cwd, approval/sandbox policy or the branch moves. Replacement rather than a second block: two `# Environment` sections disagreeing about cwd is worse context than one, and the system message is re-sent every request, so the rewrite IS the re-emission. Unchanged (no git subprocess, no rewrite) for any config that leaves `core.env_context` off."
},
{
"id": "synthetic-context-injection-blocks",
"domain": 2,
"domain_name": "Prompt / context architecture",
"capability": "Synthetic context-injection blocks",
"semantics": "Harness-spliced reminders/nudges/instruction blocks",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ (hook additionalContext, UserPromptSubmit)",
"cx_detail": "✓ (whole `context/` library: ~25 block types)",
"catalog_supercode_today": "—",
"provenance": "cc§2; cx§2; oc§2; pi§7",
"status": "implemented",
"evidence": [
{
"kind": "config",
"key": "core.context_injections"
},
{
"kind": "code",
"path": "crates/harness/src/context_injection.rs",
"symbol": "pub fn builtin_blocks(config: &Config) -> Vec<ContextInjectionBlock> {"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "pub fn inject_context_block("
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "system.push_str(&crate::context_injection::assemble(&config, &[]));"
}
],
"note": "Both presets set `core.context_injections`, and the key now gates a real registry (`crate::context_injection`) with three sources: BUILT-IN ambient blocks derived from the resolved config (task list, plan mode, protected paths, background work — each gated on the capability it describes, so a block never claims something the preset didn't arm), the pre-existing embedder list, and `Agent::inject_context_block` for mid-session splices (the hook-`additionalContext`/frontend-nudge seam). Before BP-4 the key gated only a static list nothing ever populated, and neither preset set it."
},
{
"id": "file-mentions-attachments",
"domain": 2,
"domain_name": "Prompt / context architecture",
"capability": "@-file mentions / attachments",
"semantics": "File references from the prompt with autocomplete",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ (+deny-rule aware)",
"cx_detail": "✓ fuzzy popup / `/mention`",
"catalog_supercode_today": "—",
"provenance": "cc§2; cx§2; oc§2; pi§2",
"status": "implemented",
"evidence": [
{
"kind": "config",
"key": "core.file_mentions"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "fn expand_file_mentions"
},
{
"kind": "code",
"path": "crates/cli/src/repl_completer.rs",
"symbol": "fn mention_start"
}
],
"note": "`core.file_mentions` (set by both presets) expands every `@path` token on the send path — `Agent::expand_file_mentions`, ahead of slash/skill expansion, so a mention works in a bare message, in a command's arguments and in the text a `$slug` mention appends to. Each mention is resolved through the ONE permissions engine (`evaluate_path_safe_roots`, the same call a `read_file` argument goes through), so cc-parity's `.env*` and cx-parity's `.codex/**` refuse IN PLACE with the verdict named instead of inlining bytes — the cc column's `+deny-rule aware` footnote. The composer half is the chat REPL's completer: an `@` opening a word completes as a path through the same `FilenameCompleter` the path-taking slash commands use. Bounded at 10 mentions and 64 KiB each; a token naming nothing readable (an email address, a decorator) is left exactly as typed."
},
{
"id": "agent-mentions",
"domain": 2,
"domain_name": "Prompt / context architecture",
"capability": "@-agent mentions",
"semantics": "Mention a subagent in the prompt to spawn it",
"cc": "no",
"cx": "no",
"cc_detail": "—",
"cx_detail": "—",
"catalog_supercode_today": "—",
"provenance": "oc§2",
"status": "not_applicable",
"evidence": [],
"note": ""
},
{
"id": "skills-progressive-disclosure-packages",
"domain": 2,
"domain_name": "Prompt / context architecture",
"capability": "Skills (progressive-disclosure packages)",
"semantics": "SKILL.md capability folders, names in prompt, body on demand",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ (frontmatter-rich, plugins, hooks)",
"cx_detail": "✓ (.agents/skills, `$` mention, implicit)",
"catalog_supercode_today": "partial (named prompt templates, config.rs:193-194)",
"provenance": "cc§7; cx§7; oc§7; pi§2",
"status": "implemented",
"evidence": [
{
"kind": "config",
"key": "core.skills.enabled"
},
{
"kind": "tool",
"name": "skill"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "fn skills_prompt_section(config: &Config, skills: &[crate::skills::LoopSkill]) -> String {"
},
{
"kind": "code",
"path": "crates/harness/src/skills.rs",
"symbol": "pub fn body(&self, arguments: &str) -> std::io::Result<String> {"
}
],
"note": "BP-6: SKILL.md capability folders are discovered by walking each harness's own documented roots and reading FRONTMATTER only (`name`, `description`, `version`, `enabled`), never past it. The `# Skills` prompt section is the resulting INDEX — one `- name: description` line per package and nothing else — and the `[core.prompts]` template names keep their own sub-list below it. A body is read from disk only when something invokes the package (the `skill` tool, `/skill:name`, cc's bare `/name`, cx's `$slug`), with the frontmatter stripped, `$ARGUMENTS` / `$1`..`$9` substituted and the result capped at 64 KiB. A package whose frontmatter opts out (`enabled: false`, pi's `disable-model-invocation: true`) is not advertised to the model but stays invocable by name (cc§7 \"Invocation control\"). The tests over both resolved presets assert the index lines are present AND that not one body byte reaches the system prompt."
},
{
"id": "prompt-templates-custom-slash-commands",
"domain": 2,
"domain_name": "Prompt / context architecture",
"capability": "Prompt templates / custom slash commands",
"semantics": "Markdown commands with $ARGUMENTS/positional args",
"cc": "yes",
"cx": "no",
"cc_detail": "✓ (commands merged into skills engine)",
"cx_detail": "—⁹",
"catalog_supercode_today": "✓ `prompts` `/name {args}` (config.rs:12-23, 193-194)",
"provenance": "cc§7; cx§7; oc§2; pi§7",
"status": "implemented",
"evidence": [
{
"kind": "config",
"key": "core.skills.harness"
},
{
"kind": "code",
"path": "crates/harness/src/skills.rs",
"symbol": "fn command_roots"
},
{
"kind": "code",
"path": "crates/harness/src/skills.rs",
"symbol": "fn substitute_arguments"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "let expanded = self.expand_prompt_async(&prompt).await;"
}
],
"note": "Markdown command files are discovered from disk — `~/.claude/commands/*.md` then project `.claude/commands/*.md`, one namespacing subdirectory qualified `dir:name` — and become `LoopSkill`s, which is cc's own architecture for them (cc§7: \"custom commands merged into skills (same engine, `$ARGUMENTS` etc.)\"). They therefore inherit every skills door BP-6 built: the `/name` invocation, the prompt index, progressive disclosure, and the `skill` tool. Substitution now covers `$ARGUMENTS`, `$ARGUMENTS[N]`, `$1`..`$9` and the ARGUMENT SCHEMA — `$name` for each name in the file's own `arguments:` frontmatter, with `argument-hint` shown on the index line. Collected after every skill root, so cc's \"skills override same-name commands\" falls out of the same first-root-wins de-duplication. The `[core.prompts]` TOML templates remain, unchanged, as the config-borne form. cx is `—` for this row (cx§7: custom prompts are ABSENT at the pin), and cx-parity discovers no command files."
},
{
"id": "shell-output-injection-in-templates-skills",
"domain": 2,
"domain_name": "Prompt / context architecture",
"capability": "Shell-output injection in templates/skills",
"semantics": "!`cmd` executed at load time into the prompt",
"cc": "yes",
"cx": "no",
"cc_detail": "✓ (+block form; org-disableable)",
"cx_detail": "—",
"catalog_supercode_today": "—",
"provenance": "cc§7; oc§2",
"status": "implemented",
"evidence": [
{
"kind": "config",
"key": "core.skills.shell_injection"
},
{
"kind": "code",
"path": "crates/harness/src/skills.rs",
"symbol": "pub struct ShellInjection"
},
{
"kind": "code",
"path": "crates/harness/src/skills.rs",
"symbol": "fn run_injected_command"
},
{
"kind": "code",
"path": "crates/harness/src/permissions/mod.rs",
"symbol": "pub fn rules_for_config"
}
],
"note": "Both cc forms — inline `` !`cmd` `` and the ```` ```! ```` block — are executed when a skill or command BODY is loaded, at every invocation door (`skill` tool, `/name`, `/skill:name`, `$slug`), because all four go through `LoopSkill::body_with_shell`. The gate is the one permissions engine: `permissions::rules_for_config` + `default_decision(config, \"bash\")` — the exact rule set and baseline the tool-dispatch gate uses — with the body's own `allowed-tools` frontmatter folded into the ALLOW tier for its own commands only, so a deny rule or protected path still wins first-match. Under cc-parity's `untrusted` default a body that declares nothing is refused with its verdict inlined where the output would have gone. `[core.skills] shell_injection` is cc's `disableSkillShellExecution` stated positively; cx-parity leaves it off, and the token stays literal text there. Bounded: 16 commands per body, 8 KiB of output each, killed at 30s."
},
{
"id": "auto-compaction-on-context-pressure",
"domain": 2,
"domain_name": "Prompt / context architecture",
"capability": "Auto-compaction on context pressure",
"semantics": "Summarize/clear when near window limit",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ (clear tool outputs → summarize)",
"cx_detail": "✓ (remote auto-compact at token limit)",
"catalog_supercode_today": "✓* `compact_after_messages` (config.rs:196-199) + reduce TurnsCleared (reduce.rs:117-134)",
"provenance": "cc§2; cx§2; oc§2; pi§2",
"status": "implemented",
"evidence": [
{
"kind": "config",
"key": "core.compaction.enabled"
},
{
"kind": "config",
"key": "core.compaction.reserve_tokens"
},
{
"kind": "config",
"key": "core.compaction.summarize"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "let pressure_trigger = self.compaction_pressure_triggered();"
},
{
"kind": "code",
"path": "crates/harness/src/configfile.rs",
"symbol": "compaction_summarize: c.compaction.summarize,"
}
],
"note": "Both presets now arm the pressure trigger: cc-parity's reserve_tokens = 16384 was already there, and BP-1 armed cx-parity's (it set NEITHER after_messages nor reserve_tokens, so Agent::maybe_compact returned false on its `threshold.is_none() && compaction_reserve_tokens.is_none()` guard and nothing could ever compact there). compaction_pressure_triggered fires at `used + reserve > model_context_limit` and the span is cleared into a marker. core.compaction.summarize was parsed into CoreCompactionConfig and dropped; it now materializes onto Config::compaction_summarize and is what the marker states."
},
{
"id": "manual-compact-with-focus-instructions",
"domain": 2,
"domain_name": "Prompt / context architecture",
"capability": "Manual compact with focus instructions",
"semantics": "`/compact [instructions]` steers what's preserved",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓",
"cx_detail": "✓",
"catalog_supercode_today": "partial (reduce engine callable; no instruction steering)",
"provenance": "cc§2; cx§2; oc§2; pi§2",
"status": "implemented",
"evidence": [
{
"kind": "config",
"key": "core.compaction.focus_instructions"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "pub fn compact_now(&mut self, focus: Option<&str>) -> bool {"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "fn summarize_span("
},
{
"kind": "code",
"path": "crates/cli/src/slash.rs",
"symbol": "name: \"/compact\","
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "SlashCmd::Compact => {"
}
],
"note": "`/compact [focus]` exists in the REPL command table and `Agent::compact_now(focus)` compacts on demand regardless of either automatic trigger, keeping the tighter of the token budget and the message trigger's own \"most recent half\" window. The per-invocation focus overrides the standing `core.compaction.focus_instructions` for that compaction, is carried into the SUMMARIZER's input (not only the marker text), and is stated on the marker. Both presets now set the key — to `\"\"`, because neither CC nor Codex has a standing focus: steering is per invocation in both (cc§2/cx§2 `/compact [instructions]`)."
},
{
"id": "compaction-markers-persisted-in-transcript",
"domain": 2,
"domain_name": "Prompt / context architecture",
"capability": "Compaction markers persisted in transcript",
"semantics": "On-disk record of what was compacted (boundary/summary)",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ compact_boundary",
"cx_detail": "✓ `compacted` record + window-id chain",
"catalog_supercode_today": "✓* ReductionLog sidecar `<name>.reduction.json` (reduce.rs:322-331)",
"provenance": "cc§5; cx§5; oc§2; pi§2",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "if let Err(error) = self.record(&summary) {"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "let retention = if self.recorder.is_some() {"
}
],
"note": "The legacy (no-`ReductionPolicy`) path — the one both presets take, since `capabilities.reduction` is off — now `record`s the boundary marker, so it lands in the session transcript on disk instead of existing only in the live window. The marker states where the originals went: retained in the session's transcript sidecar when a recorder is attached, or explicitly not retained when none is. The reversible `<name>.reduction.json` ReductionLog remains the reduction module's stronger artifact (catalog footnote ¹⁰); this row's semantics — \"on-disk record of what was compacted (boundary/summary)\" — is the boundary record, and it is now persisted under the presets."
},
{
"id": "lossless-sidecar-reduction-view-storage",
"domain": 2,
"domain_name": "Prompt / context architecture",
"capability": "Lossless-sidecar reduction (view ≠ storage)",
"semantics": "Reduced view with byte-exact restore of every elision",
"cc": "no",
"cx": "no",
"cc_detail": "— (compaction is lossy)",
"cx_detail": "—¹⁰",
"catalog_supercode_today": "✓ reduce: SidecarPtr+invert, blake3-verified (reduce.rs:45-79)",
"provenance": "reduce.rs",
"status": "not_applicable",
"evidence": [],
"note": ""
},
{
"id": "stale-read-elision-read-log",
"domain": 2,
"domain_name": "Prompt / context architecture",
"capability": "Stale-read elision / read-log",
"semantics": "Old file reads dropped when file unchanged; reads logged",
"cc": "no",
"cx": "no",
"cc_detail": "—",
"cx_detail": "—",
"catalog_supercode_today": "✓ FileReadElided + ReadLogEntry (reduce.rs:104-111, 291-304)",
"provenance": "reduce.rs",
"status": "not_applicable",
"evidence": [],
"note": ""
},
{
"id": "re-read-as-diff",
"domain": 2,
"domain_name": "Prompt / context architecture",
"capability": "Re-read-as-diff",
"semantics": "A changed file's re-read replaced by a diff vs prior read",
"cc": "no",
"cx": "no",
"cc_detail": "—",
"cx_detail": "—",
"catalog_supercode_today": "✓ FileReadDiffed (reduce.rs:203-218)",
"provenance": "reduce.rs",
"status": "not_applicable",
"evidence": [],
"note": ""
},
{
"id": "duplicate-superseded-output-eviction",
"domain": 2,
"domain_name": "Prompt / context architecture",
"capability": "Duplicate/superseded output eviction",
"semantics": "Identical or re-run tool results stubbed to newest instance",
"cc": "no",
"cx": "no",
"cc_detail": "—",
"cx_detail": "—",
"catalog_supercode_today": "✓ DuplicateOutput + Superseded (reduce.rs:220-259; reduce/supersede.rs)",
"provenance": "oc§2; reduce.rs",
"status": "not_applicable",
"evidence": [],
"note": ""
},
{
"id": "tool-input-payload-elision",
"domain": 2,
"domain_name": "Prompt / context architecture",
"capability": "Tool-input payload elision",
"semantics": "Executed write-tool `content` args elided from view",
"cc": "no",
"cx": "no",
"cc_detail": "—",
"cx_detail": "—",
"catalog_supercode_today": "✓ ToolInputElided (reduce.rs:135-169)",
"provenance": "reduce.rs",
"status": "not_applicable",
"evidence": [],
"note": ""
},
{
"id": "terminal-output-normalization",
"domain": 2,
"domain_name": "Prompt / context architecture",
"capability": "Terminal-output normalization",
"semantics": "ANSI/redraw frames collapsed to final rendered text",
"cc": "no",
"cx": "no",
"cc_detail": "—",
"cx_detail": "—",
"catalog_supercode_today": "✓ OutputNormalized (reduce.rs:170-182; reduce/normalize.rs)",
"provenance": "reduce.rs",
"status": "not_applicable",
"evidence": [],
"note": ""
},
{
"id": "handoff-fresh-objective-curated-keep-set",
"domain": 2,
"domain_name": "Prompt / context architecture",
"capability": "Handoff (fresh objective + curated keep-set)",
"semantics": "New working view seeded with objective + kept artifacts",
"cc": "no",
"cx": "variant",
"cc_detail": "—¹¹",
"cx_detail": "✓* new_context (state kept, no curation)",
"catalog_supercode_today": "✓ reduce/handoff.rs (named ReductionLog snapshot)",
"provenance": "cx§1; reduce/handoff.rs",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "pub fn new_context(&mut self, objective: &str, keep_recent: Option<usize>) -> usize {"
},
{
"kind": "code",
"path": "crates/cli/src/slash.rs",
"symbol": "name: \"/handoff\","
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "SlashCmd::Handoff => {"
}
],
"note": "The row's semantics is the MECHANISM — \"new working view seeded with objective + kept artifacts\" — and cx's own variant (`new_context`) is exactly that, with no curation and no reversibility. `Agent::new_context` supplies it in-session: system prompt (plus any cache-protected imported prefix), a persisted handoff marker naming the objective and what was set aside, then the curated recent keep-set (the `core.compaction.keep_recent_tokens` budget by default — the same curation the rest of the compaction machinery uses — never beginning on an orphaned tool result). Reached from the REPL as `/handoff <objective>`. Deliberately NOT `Config::handoff_enabled`: that flag gates the reduction module's reversible ReductionLog snapshot (the offline `supercode handoff` projection), which is a different, stronger artifact and stays where the design homes it — cx-parity keeps `capabilities.reduction` off and still has the row."
},
{
"id": "llm-summaries-of-cleared-spans",
"domain": 2,
"domain_name": "Prompt / context architecture",
"capability": "LLM summaries of cleared spans",
"semantics": "Cleared-turn placeholder upgraded to model-written summary",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ (compaction summary)",
"cx_detail": "✓",
"catalog_supercode_today": "✓ SpanSummary + reduce/summarize.rs (reduce.rs:268-289)",
"provenance": "all §2; reduce.rs",
"status": "implemented",
"evidence": [
{
"kind": "config",
"key": "core.compaction.summarize"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "let summary_body = if self.config.compaction_summarize {"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "match summarizer.summarize(&span_text) {"
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "let core_compaction_summarizes = config.compaction_summarize"
}
],
"note": "Re-decided against the design, which is explicit: §1.5 states obligation 5 as \"auto-compaction at context pressure + a manual compact command + a persisted marker + AN LLM SUMMARY OF THE COMPACTED SPAN\", lists `[core.compaction] … summarize` among its knobs, and adds \"the summary side-call depends on a utility model … core falls back to the main model\"; §3.1 annotates the same key \"SpanSummary side-call (reduce.rs:274-289; D-9 small-model fallback)\". The side-call is therefore CORE, and BP-1's narrower reading (marker wording only) does not survive that citation. Core compaction now runs the installed summarizer over the cleared span and carries its text on the marker; the CLI installs the summarizer for either consumer — `capabilities.reduction.span_summaries` OR `core.compaction.summarize` with compaction able to fire. Every failure mode (no summarizer, Err, empty reply) degrades to the count-only marker, never blocking compaction. `capabilities.reduction` stays off in both presets and is not required."
},
{
"id": "image-redaction-from-context",
"domain": 2,
"domain_name": "Prompt / context architecture",
"capability": "Image redaction from context",
"semantics": "Image parts stubbed out of the model view",
"cc": "no",
"cx": "no",
"cc_detail": "—",
"cx_detail": "—",
"catalog_supercode_today": "✓ ImageRedacted (reduce.rs:112-116)",
"provenance": "pi§4; reduce.rs",
"status": "not_applicable",
"evidence": [],
"note": ""
},
{
"id": "context-usage-introspection",
"domain": 2,
"domain_name": "Prompt / context architecture",
"capability": "Context-usage introspection",
"semantics": "Live context %/tokens breakdown for the user",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ /context grid",
"cx_detail": "✓ /status + get_context_remaining",
"catalog_supercode_today": "partial (`inspect stats` savings, per config.rs:233-236 comment)",
"provenance": "cc§2; cx§8; oc§3; pi§3",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "pub fn context_usage(&self) -> ContextUsage {"
},
{
"kind": "code",
"path": "crates/cli/src/slash.rs",
"symbol": "name: \"/context\","
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "SlashCmd::Context => {"
},
{
"kind": "code",
"path": "crates/harness/src/server.rs",
"symbol": "kind: FrontendOperationKind::Context,"
}
],
"note": "`Agent::context_usage` reports the live breakdown — messages, message tokens, tool count, tool-schema tokens, the guard's projected total, the reply reserve, the window, remaining tokens, used percent, and whether the next request fits — computed from the SAME `crate::tokens` estimator the context guard enforces, so the readout and the refusal can never disagree. It is pure (the projection never mutates the reduction log). Two doors: the REPL `/context` command, and the `context:usage` frontend operation, which every runtime advertises unconditionally and answers without submitting a turn."
},
{
"id": "cache-aware-context-architecture",
"domain": 2,
"domain_name": "Prompt / context architecture",
"capability": "Cache-aware context architecture",
"semantics": "Explicit prompt-cache plans/stability levers",
"cc": "yes",
"cx": "no",
"cc_detail": "✓ (cache-action matrix, /cd cache-preserving, TTL switches)",
"cx_detail": "—",
"catalog_supercode_today": "✓ CachePlan::ImportedPrefix + cache_warnings (config.rs:78-96, 227-239)",
"provenance": "cc§2; oc§9; pi§9",
"status": "implemented",
"evidence": [
{
"kind": "module",
"name": "cache"
},
{
"kind": "config",
"key": "capabilities.cache.plan"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "provider::apply_cache_plan(&messages, effective_cache_plan, self.imported_prefix_len)"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "self.emit(AgentEvent::CacheWarning {"
}
],
"note": "cc-parity now enables `[capabilities.cache]` with `plan = \"imported_prefix\"` and `warnings = true`, so the machinery that was already implemented and wired actually fires under the preset: `CachePlan::ImportedPrefix` breakpoints, the imported-prefix compaction clamp, and in-session `AgentEvent::CacheWarning` churn warnings. §4.2's own `enabled = false` line reasoned \"CC caching is provider-automatic\", which the catalog's own grading of the same behaviour contradicts (catalog:110 marks CC ✓ with the cache-action matrix, cache-preserving `/cd` and TTL switches — a harness that shapes its cached prefix). `capabilities.cache.warnings` also reaches `Config::cache_warnings` now; it was parsed and dropped. cx-parity is unaffected (cx has no cache-plan surface — the row's cx column is `—`)."
},
{
"id": "per-turn-system-prompt-override",
"domain": 2,
"domain_name": "Prompt / context architecture",
"capability": "Per-turn system-prompt override",
"semantics": "System prompt attached to a user message, not the session",
"cc": "no",
"cx": "no",
"cc_detail": "—",
"cx_detail": "—",
"catalog_supercode_today": "—",
"provenance": "oc§2; pi§2",
"status": "not_applicable",
"evidence": [],
"note": ""
},
{
"id": "output-style-personality-module",
"domain": 2,
"domain_name": "Prompt / context architecture",
"capability": "Output style / personality module",
"semantics": "Swappable response-style instruction layer",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ output styles",
"cx_detail": "✓ personality (friendly/pragmatic)",
"catalog_supercode_today": "—",
"provenance": "cc§2; cx§2",
"status": "implemented",
"evidence": [
{
"kind": "config",
"key": "core.output_style"
},
{
"kind": "code",
"path": "crates/harness/src/output_style.rs",
"symbol": "pub fn resolve"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "if let Some(style) = output_style.as_ref().filter(|s| !s.replaces_base)"
}
],
"note": "`core.output_style` names the layer; `crate::output_style` resolves it to text and prompt assembly appends one section at the END of the system prompt, where cc puts it. Both presets pin their harness's own neutral selection — cc's Default, cx's `personality = none` — which resolve and add nothing, exactly as those selections do upstream; naming any other style (`explanatory`/`learning`/`proactive`, cx's `friendly`/`pragmatic`, or a `~/.claude/output-styles/<name>.md` of the user's own, read through `CLAUDE_CONFIG_DIR`) swaps the response-style instructions without touching `system_prompt`. cc's `keep-coding-instructions` is honored: a custom style REPLACES the base coding instructions unless its frontmatter keeps them. A prompt-assembly input with no state and no module of its own; an unknown name resolves to nothing rather than failing a session."
},
{
"id": "branch-summaries-on-tree-navigation",
"domain": 2,
"domain_name": "Prompt / context architecture",
"capability": "Branch summaries on tree navigation",
"semantics": "Leaving a branch injects an LLM summary of abandoned work",
"cc": "no",
"cx": "no",
"cc_detail": "—",
"cx_detail": "—",
"catalog_supercode_today": "—",
"provenance": "pi§2",
"status": "not_applicable",
"evidence": [],
"note": ""
},
{
"id": "split-turn-compaction-cut-points",
"domain": 2,
"domain_name": "Prompt / context architecture",
"capability": "Split-turn compaction cut points",
"semantics": "Mid-turn cuts with merged turn-prefix summaries; never at tool results",
"cc": "no",
"cx": "no",
"cc_detail": "—",
"cx_detail": "—",
"catalog_supercode_today": "—",
"provenance": "pi§2",
"status": "not_applicable",
"evidence": [],
"note": ""
},
{
"id": "self-documentation-in-prompt",
"domain": 2,
"domain_name": "Prompt / context architecture",
"capability": "Self-documentation in prompt",
"semantics": "Agent told where its own docs live so it can extend itself",
"cc": "no",
"cx": "no",
"cc_detail": "—",
"cx_detail": "—",
"catalog_supercode_today": "—",
"provenance": "pi§2",
"status": "not_applicable",
"evidence": [],
"note": ""
},
{
"id": "prompt-input-debugging",
"domain": 2,
"domain_name": "Prompt / context architecture",
"capability": "Prompt-input debugging",
"semantics": "Render the exact model-visible input for inspection",
"cc": "no",
"cx": "yes",
"cc_detail": "—",
"cx_detail": "✓ codex debug prompt-input",
"catalog_supercode_today": "—",
"provenance": "cx§2",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "pub fn model_input"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "fn chat_request"
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "show_prompt: bool"
}
],
"note": "`supercode run --show-prompt` prints the exact model-visible input as JSON and exits without issuing a request — cx's `codex debug prompt-input` shape. It is the REAL request, not a reconstruction: `Agent::model_input` calls the same `build_request_messages`/`tool_schemas` pair the loop calls and assembles them with `chat_request`, which is now the ONE place a `ChatRequest` is built from a config, so the rendered input and the sent one cannot drift. The CLI renders after `create_agent`/`attach_mcp`/`open_session`, so MCP tool schemas and a continued session's history are in it, and the prompt has been through the same expansion a send gives it. Messages and tool schemas serialize through their own wire serializers — the bytes the provider is handed. Nothing is recorded or persisted."
},
{
"id": "streaming-agentic-loop-tools-until-final",
"domain": 3,
"domain_name": "Agent loop mechanics",
"capability": "Streaming agentic loop (tools until final)",
"semantics": "user → model → tool dispatch → repeat → final message",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓",
"cx_detail": "✓",
"catalog_supercode_today": "✓ Agent::send + max_iterations (config.rs:140-141)",
"provenance": "all §3",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "for _ in 0..self.config.max_iterations"
},
{
"kind": "tool",
"name": "bash"
}
],
"note": "`Agent::send`'s bounded tool-dispatch loop is the core loop under both presets: each iteration builds a request, records the assistant message, executes its tool calls, and only returns when a reply carries no tool calls."
},
{
"id": "turn-step-bracketing-records",
"domain": 3,
"domain_name": "Agent loop mechanics",
"capability": "Turn/step bracketing records",
"semantics": "Persisted per-round-trip markers (context, usage, finish)",
"cc": "variant",
"cx": "yes",
"cc_detail": "✓* turn_duration system records",
"cx_detail": "✓ turn_context per turn",
"catalog_supercode_today": "—",
"provenance": "cc§5; cx§5; oc§3; pi§3",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/harness/src/turn_record.rs",
"symbol": "pub struct TurnRecord"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "fn push_turn_marker_at(&mut self, turn: usize, marker: crate::turn_record::TurnMarker)"
},
{
"kind": "code",
"path": "crates/harness/src/store.rs",
"symbol": "pub fn save_turn_records("
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "let _ = agent.save_turn_records(&store, name);"
}
],
"note": "Every model round-trip writes `context` (messages/tools/estimated tokens, before the request is issued), `usage` (provider counts + cost) and `finish` (`end_turn` / `tool_calls` / `max_iterations` / `output_token_budget` / `spend_budget` / `step_budget`) markers, plus `retry`, `aborted`, `effort` and `goal` markers between round-trips. They land in `<session>.events.jsonl` — the sidecar-family member the store always reserved and swept but never had a writer for — and `persist_session` writes them on every turn. cc's `turn_duration` system records and cx's `turn_context`/`turn_aborted` rows are the same shape."
},
{
"id": "mid-turn-steering",
"domain": 3,
"domain_name": "Agent loop mechanics",
"capability": "Mid-turn steering",
"semantics": "New user input injected into the running turn",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ (Esc interrupt + steer)",
"cx_detail": "✓ (Enter injects into current turn)",
"catalog_supercode_today": "—",
"provenance": "cc§3; cx§3; oc§3; pi§3",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "inbox.drain(self.config.steering_mode)"
},
{
"kind": "runtime",
"capability": "steer"
}
],
"note": "The loop drains the shared `SteerInbox` at the top of every iteration (i.e. after the previous iteration's tool calls) and pushes the text into the RUNNING turn's history; `Server::steer` enqueues into that inbox over the RPC/SDK/ACP surface, and both live-runtime backends report `steer`."
},
{
"id": "prompt-queueing-for-next-turn",
"domain": 3,
"domain_name": "Agent loop mechanics",
"capability": "Prompt queueing for next turn",
"semantics": "Input queued while agent runs, delivered at idle",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ queue-operation records",
"cx_detail": "✓ (Tab queues)",
"catalog_supercode_today": "—",
"provenance": "cc§3; cx§3; oc§3; pi§3",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "Self::drain_steer_queue(&mut self.follow_up_queue, self.config.follow_up_mode)"
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "soft_steer::spawn()"
}
],
"note": "Two queues, both wired: `follow_up_queue` is drained at idle (the loop's no-more-tool-calls boundary) per `follow_up_mode`, and the REPL's soft-steer watcher captures a line typed while a turn streams and delivers it as the next turn's input without touching the running turn."
},
{
"id": "interrupt-abort-with-state-preserved",
"domain": 3,
"domain_name": "Agent loop mechanics",
"capability": "Interrupt/abort with state preserved",
"semantics": "Esc aborts; partial work + abort marker persisted",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓",
"cx_detail": "✓ turn_aborted records",
"catalog_supercode_today": "—",
"provenance": "cc§3; cx§3; oc§3; pi§3",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "async fn race_ctrl_c<F: std::future::Future>"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "pub fn note_abort(&mut self, source: &str)"
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "agent.note_abort(\"ctrl_c\");"
}
],
"note": "Ctrl-C aborts the in-flight turn, the append-only transcript keeps the partial work, and the interruption is now a persisted FACT: `Agent::note_abort` emits `AgentEvent::TurnAborted` and writes an `aborted` marker (source + history length at the moment of the abort) into `<session>.events.jsonl`, which the REPL's cancel arm then persists. cx's `turn_aborted` record, same shape — a reader no longer has to infer the interruption from a dangling tool call."
},
{
"id": "sub-agents-first-class",
"domain": 3,
"domain_name": "Agent loop mechanics",
"capability": "Sub-agents, first-class",
"semantics": "Child agent runs with own context, linked to parent",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ (built-in + custom + nested)",
"cx_detail": "✓ (v1/v2 tools, roles, depth/threads caps)",
"catalog_supercode_today": "—",
"provenance": "cc§3; cx§3; oc§3; pi§3",
"status": "implemented",
"evidence": [
{
"kind": "module",
"name": "subagents"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "if call.function.name == SPAWN_SUBAGENT {"
}
],
"note": "The `subagents` module is on in both presets and the loop intercepts `spawn_subagent`, running the child on its own history with a narrowed tool set, depth/concurrency caps (`crate::subagents`), and lineage written to the parent's store."
},
{
"id": "named-agent-definitions-as-data",
"domain": 3,
"domain_name": "Agent loop mechanics",
"capability": "Named agent definitions as data",
"semantics": "Agent = prompt+model+tools+permissions in a file/config",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ .claude/agents/*.md frontmatter",
"cx_detail": "✓ [agents.<role>] + own config file",
"catalog_supercode_today": "—",
"provenance": "cc§3; cx§6; oc§7",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/harness/src/configfile.rs",
"symbol": "config.subagents_definitions = subagent_definitions(cap);"
},
{
"kind": "code",
"path": "crates/harness/src/subagents.rs",
"symbol": "pub struct AgentPermissions"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "fn merge_project_agent_definitions(config: &mut Config)"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "pub fn child_config_for_agent_type(&self, agent_type: &str) -> Option<Config>"
}
],
"note": "All four components of the row's own semantics (`prompt+model+tools+permissions`) are data, from either source. `NamedAgentDefinition` now carries an `AgentPermissions` bundle (approval, sandbox tier, auto-approved tools, deny patterns) read from `[capabilities.subagents.agents.<name>.permissions]` AND from `.claude/agents/*.md` frontmatter, and `.claude/agents` discovery runs for every harness whose subagents module is on — it was reachable only from the Claude emulate/resume path before. The bundle can only TIGHTEN: the two policy values go through the same strictness ranks `clamp_project_permissions` applies to the untrusted project layer (a looser value is ignored, never honored), the auto-approve list is intersected, the deny list unioned — a definition sitting in a repo can never be an escalation door. Config-table entries win over discovered files of the same name."
},
{
"id": "background-subagents-resume",
"domain": 3,
"domain_name": "Agent loop mechanics",
"capability": "Background subagents + resume",
"semantics": "Detached child agents; resumable with context intact",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ (default bg; SendMessage resume)",
"cx_detail": "✓ v2 mailbox (send_message/wait/interrupt)",
"catalog_supercode_today": "—",
"provenance": "cc§3; cx§1; oc§3",
"status": "implemented",
"evidence": [
{
"kind": "module",
"name": "subagents"
},
{
"kind": "config",
"key": "capabilities.subagents.background"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "fn run_subagent_message(&mut self, call: &crate::message::ToolCall) -> (String, bool)"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "async fn run_subagent_resume(&mut self, call: &crate::message::ToolCall) -> (String, bool)"
}
],
"note": "Both presets detach (`background = true`; cx-parity's `false` contradicted the very column it transcribed — cx§1's multi-agent v2 mailbox — and it now also carries the `background_prompts = \"auto_policy\"` key C6 requires, without which `run_spawn_subagent` refused every background spawn). The two missing halves are built as intrinsics advertised alongside `subagent_status`: `subagent_message` delivers into a still-running child's own `SteerInbox` — the P4b seam that is writable while the child's turn holds `&mut Agent`, so delivery ordering is already defined (top of the child's next iteration, per its `steering_mode`) rather than being a second channel; and `subagent_resume` continues a FINISHED child over its own transcript (in-process reap cache, or its persisted `<parent>.subagents/<id>.sidecar.jsonl`), rebuilt through `build_child_config` from the same named definition so its permission posture on resume is the one it was spawned with."
},
{
"id": "multi-agent-teams-inter-agent-messaging",
"domain": 3,
"domain_name": "Agent loop mechanics",
"capability": "Multi-agent teams / inter-agent messaging",
"semantics": "Peer sessions coordinating with shared tasks + messages",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ agent teams (experimental)",
"cx_detail": "✓ inter_agent_communication records, fan-out",
"catalog_supercode_today": "—",
"provenance": "cc§3; cx§5; pi§10",
"status": "partial",
"evidence": [
{
"kind": "code",
"path": "crates/harness/src/harness_service.rs",
"symbol": "message_live_session(¶ms, &crate::claude_peer::ProcessCourierRunner)"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "fn run_subagent_message(&mut self, call: &crate::message::ToolCall) -> (String, bool)"
}
],
"note": "Two directions exist now. (1) The harness service delivers a message to a LIVE Claude Code peer session (registry discovery + headless courier). (2) BP-7's `subagent_message`/`subagent_resume` give a supercode agent a real mailbox into its OWN running children and a way to continue a finished one with context intact. Still missing, and this is the row's actual subject: messaging between PEER sessions — two independently-started supercode sessions have no channel to each other, only parent→child; there is no shared-task/team construct at all (no work item two agents can both see and claim); and the Codex direction is unavailable at all, since `codex_peer` is discovery/status only and the service answers `HarnessUnsupported` — Codex exposes no message-into-a-live-session door for a peer to use, so that third piece is blocked on the peer, not on supercode."
},
{
"id": "csv-fan-out-agent-jobs",
"domain": 3,
"domain_name": "Agent loop mechanics",
"capability": "CSV fan-out agent jobs",
"semantics": "One worker per CSV row, blocking join",
"cc": "no",
"cx": "yes",
"cc_detail": "—",
"cx_detail": "✓ spawn_agents_on_csv",
"catalog_supercode_today": "—",
"provenance": "cx§1",
"status": "irreducible",
"evidence": [],
"note": "COMPOSABLE-HARNESS-DESIGN.md §4.3 cx-parity \"Irreducible gaps\" table, `Long tail` row: \"Code mode (`exec`/`wait` cells), CSV fan-out jobs, config lockfile, ... — UNIQUE CX rows (catalog §1) and `integrations`-scope.\" Only cx has the row, so cx-parity's ledger governs it."
},
{
"id": "plan-mode-read-only-research-phase",
"domain": 3,
"domain_name": "Agent loop mechanics",
"capability": "Plan mode (read-only research phase)",
"semantics": "Restricted mode producing an approved plan",
"cc": "yes",
"cx": "variant",
"cc_detail": "✓ (mode + Plan agent + opusplan)",
"cx_detail": "✓* (/plan + plan-mode effort)",
"catalog_supercode_today": "—",
"provenance": "cc§3; cx§6; oc§3; pi§10",
"status": "implemented",
"evidence": [
{
"kind": "module",
"name": "permissions.rules"
},
{
"kind": "code",
"path": "crates/harness/src/tools/plan_mode.rs",
"symbol": "pub fn deny_rules"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": ".extend(crate::tools::plan_mode::deny_rules(&self.ctx.plan_mode));"
},
{
"kind": "code",
"path": "crates/cli/src/slash.rs",
"symbol": "SlashCmd::Plan"
}
],
"note": "The restricted mode IS a narrowing of the one permissions engine, module 8's own `plan_mode → permissions.rules|sandbox` edge honored literally: while the mode is active `plan_mode::deny_rules` (the `write(*)` pseudo-tool plus the write/exec tool names) joins the deny tier of the same first-match deny→ask→allow evaluation every other rule gets, so research tools keep working and writes/execs are refused. Both parity presets enable `permissions.rules`, and `/plan [on|off]` toggles the mode from the composer under either — which is also how cx-parity supplies its `✓*` variant (cx's `/plan` is user-driven, not a model-invocable tool pair, so cx-parity leaves `[capabilities.plan_mode]` off and gets the mode without the tools)."
},
{
"id": "goals-persistent-objective-across-turns",
"domain": 3,
"domain_name": "Agent loop mechanics",
"capability": "Goals (persistent objective across turns)",
"semantics": "Harness-tracked condition the agent works toward",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ /goal",
"cx_detail": "✓ /goal (+goals_1.sqlite)",
"catalog_supercode_today": "—",
"provenance": "cc§3; cx§2",
"status": "implemented",
"evidence": [
{
"kind": "config",
"key": "capabilities.todos.goals"
},
{
"kind": "code",
"path": "crates/harness/src/goals.rs",
"symbol": "pub struct GoalRecord"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "pub fn set_goal(&mut self, objective: impl Into<String>) -> bool"
},
{
"kind": "code",
"path": "crates/cli/src/slash.rs",
"symbol": "name: \"/goal\","
}
],
"note": "`/goal` sets a standing objective under both presets (`capabilities.todos.goals`, design §2 module 7's persistent-objective variant of the checklist). It is restated at the TAIL of every request while it stands — after the cache annotation, which sits on the prefix, so a goal change never busts the cached prefix — persisted as `<session>.goal.json` beside the transcript, restored on resume, and audit-logged as `goal` markers. Deliberately never written into `history`: the transcript stays exactly what the conversation was, so a translation to another harness never has to invent a message for a harness-tracked goal."
},
{
"id": "self-paced-scheduled-loops",
"domain": 3,
"domain_name": "Agent loop mechanics",
"capability": "Self-paced / scheduled loops",
"semantics": "Recurring prompts, model-chosen wakeups, crons",
"cc": "yes",
"cx": "variant",
"cc_detail": "✓ /loop + ScheduleWakeup + Cron*",
"cx_detail": "✓* clock/sleep tool (≤12h)",
"catalog_supercode_today": "—",
"provenance": "cc§3; cx§1",
"status": "absent",
"evidence": [],
"note": "Nothing schedules or fires anything: no timer, no cron runner, no wakeup execution. A resumed Claude session's `Cron*`/`ScheduleWakeup` state is carried in the runtime manifest as an inert record, and the `CronList`/`ScheduleWakeup` schemas are advertised only on the Claude emulate/resume path (`claude_compat::apply_resume_compatibility`, which states the agent owns no timer). Neither parity preset enables that surface. Firing is the orchestrator's, through `supercode orchestrator import --from claude-session <id>`.",
"cost": "architectural"
},
{
"id": "review-mode-dedicated-code-review-flow",
"domain": 3,
"domain_name": "Agent loop mechanics",
"capability": "Review mode (dedicated code-review flow)",
"semantics": "Purpose-built review turn with presets/report format",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ /code-review, /security-review, ultrareview",
"cx_detail": "✓ /review + codex review + review_model",
"catalog_supercode_today": "—",
"provenance": "cc§10; cx§3; oc§2",
"status": "implemented",
"evidence": [
{
"kind": "config",
"key": "core.prompts.code-review"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "pub async fn review(&mut self, args: &str) -> Result<String>"
},
{
"kind": "code",
"path": "crates/cli/src/slash.rs",
"symbol": "name: \"/review\","
}
],
"note": "Both presets pin a `[core.prompts] code-review` template, and the template IS the report format (Correctness / Security / Reuse / Verdict, severity-ordered with file:line). `/review` (aliased `/code-review`, so cc's and cx's own spellings both work) expands it with the user's focus text and sends it as an ordinary turn of the SAME session, so the review inherits the session's tools, permissions, transcript and records rather than being a second agent. `Config::prompts` was already consumed by `Agent::expand_prompt`; what was missing was a preset that pinned a template and a command that reached it."
},
{
"id": "advisor-guardian-second-model",
"domain": 3,
"domain_name": "Agent loop mechanics",
"capability": "Advisor / guardian second model",
"semantics": "Stronger model consulted or reviewing mid-task",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ advisor (server tool)",
"cx_detail": "✓ guardian auto-reviewer (approvals)",
"catalog_supercode_today": "—",
"provenance": "cc§3; cx§3",
"status": "irreducible",
"evidence": [],
"note": "Both presets' ledgers refuse it. COMPOSABLE-HARNESS-DESIGN.md §4.2 cc-parity \"Irreducible gaps\", `Server-executed tools` row: \"the `advisor` server tool (cc§1) ... provider-side, not composable client-side\". §4.3 cx-parity \"Irreducible gaps\", `Guardian auto-reviewer` row: \"`approvals_reviewer = \\\"auto_review\\\"` with a restricted-tool guardian agent ... an agent-in-the-approval-loop architecture; UNIQUE-class.\""
},
{
"id": "auto-retry-on-transient-provider-errors",
"domain": 3,
"domain_name": "Agent loop mechanics",
"capability": "Auto-retry on transient provider errors",
"semantics": "Backoff retries, surfaced as events/records",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ api_retry system events",
"cx_detail": "✓ responses_retry",
"catalog_supercode_today": "—",
"provenance": "cc§5; cx§3; oc§3; pi§3",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "provider::HttpOptions::from_retry_config("
},
{
"kind": "code",
"path": "crates/runtime/src/provider.rs",
"symbol": "pub struct RetryNotice"
},
{
"kind": "code",
"path": "crates/runtime/src/event.rs",
"symbol": "ProviderRetry {"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "for notice in self.retry_log.drain() {"
}
],
"note": "Backoff retries were already real and configurable (`Config::retry_*` → `OpenAiProvider::send_with_retry`); the missing half was surfacing. The transport now records each retry it makes into a shared `RetryLog` at the decision point (after \"retryable, attempts left\", before the sleep, so the notice survives a death during backoff); the agent drains it after every completion — success or failure — into `AgentEvent::ProviderRetry` (rendered by `--trace`/`stream-json`) and a persisted `retry` marker. cc's `api_retry` and cx's `responses_retry` records."
},
{
"id": "doom-loop-breaker",
"domain": 3,
"domain_name": "Agent loop mechanics",
"capability": "Doom-loop breaker",
"semantics": "Repeated identical tool call triggers an ask",
"cc": "no",
"cx": "no",
"cc_detail": "—",
"cx_detail": "—",
"catalog_supercode_today": "—",
"provenance": "oc§3",
"status": "not_applicable",
"evidence": [],
"note": ""
},
{
"id": "structured-final-output-schema",
"domain": 3,
"domain_name": "Agent loop mechanics",
"capability": "Structured final output (schema)",
"semantics": "Final answer validated against a JSON schema",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ --json-schema",
"cx_detail": "✓ --output-schema",
"catalog_supercode_today": "✓ `response_format` (config.rs:146-147)",
"provenance": "cc§8; cx§8; oc§3; pi§7",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "config.response_format = Some(serde_json::json!({"
}
],
"note": "`run --output-schema <file>` reads the user's JSON Schema and installs it as a strict `json_schema` `response_format` on the request, so the provider constrains the final answer. The flag is not module-gated, so it holds under both presets (cc-parity keeps `capabilities.structured_output` off exactly as the design doc prescribes: \"headless-only surface; enable per-run\")."
},
{
"id": "turn-budget-caps",
"domain": 3,
"domain_name": "Agent loop mechanics",
"capability": "Turn/budget caps",
"semantics": "Max turns, spend, steps, output tokens",
"cc": "yes",
"cx": "variant",
"cc_detail": "✓ --max-turns, --max-budget-usd",
"cx_detail": "✓* agents.job_max_runtime (sub-agents)",
"catalog_supercode_today": "✓ max_iterations + max_total_output_tokens (config.rs:140-156)",
"provenance": "cc§3; cx§6; oc§2",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "Err(Error::MaxIterations(self.config.max_iterations))"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "if let Some(budget) = self.config.max_total_output_tokens {"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "let spend_exhausted = self"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "let steps_exhausted = self"
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "max_budget_usd: Option<f64>"
}
],
"note": "All four caps the semantics name are enforced in the loop and exposed on the CLI: turns (`--max-iterations`), cumulative output tokens (`--max-output-tokens`), SPEND (`--max-budget-usd`, measured against the agent's lifetime cost from `crate::pricing` — a dollar budget that reset each prompt would not be one) and STEPS (`--max-steps`, tool calls executed, which one round-trip's parallel batch can exhaust without any turn cap firing). Each stops the loop the same way the output-token cap always did: synthetic tool results so the transcript stays resumable, plus a `spend_budget`/`step_budget` finish marker. A spend cap armed against a model this build cannot price is refused at `Agent::new` rather than accepted and silently never enforced."
},
{
"id": "per-turn-cost-usage-accounting",
"domain": 3,
"domain_name": "Agent loop mechanics",
"capability": "Per-turn cost/usage accounting",
"semantics": "Tokens+cost persisted per message/turn",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ (statusline, /cost, /usage)",
"cx_detail": "✓ token_count events + SQLite tokens_used",
"catalog_supercode_today": "partial (savings figures via inspect stats)",
"provenance": "cc§8; cx§5; oc§5; pi§3",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "self.emit(AgentEvent::Usage(usage.clone()));"
},
{
"kind": "code",
"path": "crates/harness/src/pricing.rs",
"symbol": "pub fn cost_usd(&self, prompt_tokens: u64, completion_tokens: u64) -> f64"
},
{
"kind": "code",
"path": "crates/harness/src/usage_log.rs",
"symbol": "pub cost_usd: Option<f64>"
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "let _ = agent.save_usage_log(&store, name);"
}
],
"note": "Tokens AND cost, per round-trip, persisted. `UsageRecord` carries `cost_usd` computed from `crate::pricing` (config override `core.price_input_per_mtok`/`price_output_per_mtok` over a built-in list-price table), and `persist_session` writes `<session>.usage.jsonl` on every turn — `save_usage_log`'s missing caller was the whole residue. Live streaming (`AgentEvent::Usage`, `/tokens`, `--trace`) is unchanged. Named deviation: cached prompt tokens are billed at the full input rate, which over-reports rather than under-reports — the safe direction for the spend cap that reads the same figure."
},
{
"id": "turn-diff-tracking",
"domain": 3,
"domain_name": "Agent loop mechanics",
"capability": "Turn diff tracking",
"semantics": "Cumulative file-diff of the turn for UI (/diff)",
"cc": "variant",
"cx": "yes",
"cc_detail": "✓* /diff command",
"cx_detail": "✓ turn_diff_tracker",
"catalog_supercode_today": "—",
"provenance": "cc§10; cx§3; oc§4",
"status": "implemented",
"evidence": [
{
"kind": "config",
"key": "capabilities.checkpoint"
},
{
"kind": "code",
"path": "crates/harness/src/checkpoint.rs",
"symbol": "pub fn turn_patch(&self, id: &str, project_root: &Path) -> Result<String>"
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "let text = cp.turn_patch(&id)?;"
}
],
"note": "Both presets now capture per-turn pre-images, and `supercode checkpoint diff <id> --patch` renders the turn's CUMULATIVE unified diff — pre-image vs. the working tree now, so a file written three times in one turn shows one diff from where it started to where it ended. That closes the first gap (`turn_diff` returned manifest PATHS only; it still does, as the file-list view). The second gap was cx-parity's `capabilities.checkpoint.enabled = false`: §4.3's reason (\"no shadow-git; ghost_snapshot is a legacy no-op\") is about the RESTORE half, so the module is on there with the new `restore = false` key — Codex's exact shape, a real `turn_diff_tracker` with no code-restore surface, and `CheckpointObserver::restore` refuses under it. Same documented limitation as CC's: an edit made by bash rather than a write tool is not captured."
},
{
"id": "side-ephemeral-q-a",
"domain": 3,
"domain_name": "Agent loop mechanics",
"capability": "Side/ephemeral Q&A",
"semantics": "Tool-less question over full context, never enters history",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ /btw (+fork-out)",
"cx_detail": "✓ /side (alias /btw)",
"catalog_supercode_today": "—",
"provenance": "cc§3; cx§8",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "pub async fn side_question(&self, question: &str) -> Result<String>"
},
{
"kind": "code",
"path": "crates/cli/src/slash.rs",
"symbol": "name: \"/btw\","
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "race_ctrl_c(agent.side_question(&rest), Some(spinner)).await"
}
],
"note": "`/btw` (aliased `/side`, cc's and cx's two spellings) asks a question over the session's full current context with NO tools advertised, and records nothing: not history, not the sidecar, not the usage log, not the marker log. `&self` rather than `&mut self` is the type system stating the guarantee, and the REPL's arm deliberately skips `persist_session` afterwards because nothing new happened to the session."
},
{
"id": "extended-thinking-control",
"domain": 3,
"domain_name": "Agent loop mechanics",
"capability": "Extended thinking control",
"semantics": "Reasoning on/off/levels mid-session",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ (Alt+T, budgets, adaptive)",
"cx_detail": "✓ (reasoning effort/summary knobs)",
"catalog_supercode_today": "✓ `effort` (config.rs:143-144)",
"provenance": "cc§3; cx§9; oc§9; pi§3",
"status": "implemented",
"evidence": [
{
"kind": "config",
"key": "core.effort"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "pub fn set_effort(&mut self, effort: Option<String>) -> Option<String>"
},
{
"kind": "code",
"path": "crates/cli/src/slash.rs",
"symbol": "name: \"/effort\","
}
],
"note": "Both presets pin the starting level (`core.effort = \"medium\"`) and `/effort low|medium|high|off` changes it MID-SESSION: `run_loop` reads `config.effort` fresh when it builds each `ChatRequest`, so the change reaches the very next request with no other copy to update. `off` is the on/off toggle distinct from the level (no `reasoning_effort` on the wire at all), and every change appends an `effort` marker — the extended-thinking analog of the `model_change` log."
},
{
"id": "auto-title-session-summary-generation",
"domain": 3,
"domain_name": "Agent loop mechanics",
"capability": "Auto-title / session summary generation",
"semantics": "Cheap-model titles/summaries of the session",
"cc": "yes",
"cx": "variant",
"cc_detail": "✓ ai-title records",
"cx_detail": "✓* (SQLite title/preview; /title manual)",
"catalog_supercode_today": "—",
"provenance": "cc§5; cx§5; oc§2",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "apply_auto_title(agent, &persist_name);"
},
{
"kind": "config",
"key": "core.session.auto_title"
}
],
"note": "The small-model titler (`session_title`, routed through `Config::small_model` with a main-model fallback) and its `SessionStore::set_title` write were already complete and CLI-wired; the only residue was that neither parity preset set the gate it waits on. Both now set `[core.session] auto_title = true`, so a session under either preset gets a generated title. cc writes `ai-title` records (`✓`); cx's own default derives its title/preview from the first message rather than a model call, which is the `✓*` variant the catalog footnotes."
},
{
"id": "stop-hook-completion-gating",
"domain": 3,
"domain_name": "Agent loop mechanics",
"capability": "Stop-hook / completion gating",
"semantics": "Harness can refuse the agent's stop and continue the loop",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ Stop hook block (+cap)",
"cx_detail": "✓ Stop hook (CC-shaped)",
"catalog_supercode_today": "—",
"provenance": "cc§3; cx§7; oc§7; pi§7",
"status": "implemented",
"evidence": [
{
"kind": "module",
"name": "hooks"
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "config.stop_gate = Some(Box::new(move |content: &str| {"
}
],
"note": "The `hooks` module is on in both presets; a `[hooks] stop = \"cmd\"` entry installs `Config::stop_gate`, and the loop consults it exactly once on each iteration that would otherwise return — a blocking verdict is pushed into history and the loop continues instead of finishing."
},
{
"id": "approval-policy-modes",
"domain": 4,
"domain_name": "Permissions / approval / sandbox",
"capability": "Approval policy modes",
"semantics": "Named prompting stances (never/on-request/untrusted/…)",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ 6+ modes incl. plan/auto/dontAsk/bypass",
"cx_detail": "✓ untrusted/on-request/never (+granular)",
"catalog_supercode_today": "✓ ApprovalPolicy (config.rs:34-43)",
"provenance": "cc§4; cx§4; oc§4; pi§4",
"status": "implemented",
"evidence": [
{
"kind": "module",
"name": "permissions"
},
{
"kind": "config",
"key": "capabilities.permissions.approval"
},
{
"kind": "code",
"path": "crates/harness/src/permissions/mod.rs",
"symbol": "crate::config::ApprovalPolicy::ModelRequested => Decision::Allow,"
}
],
"note": "Four named stances (`never`/`on_request`/`untrusted`/`model_requested`) parse from `capabilities.permissions.approval` and each one drives the baseline decision the rule engine falls back to when no rule matches. Both presets pin their harness's own stance: cc-parity `untrusted`, cx-parity `model_requested` (Codex's model-initiated `on-request`, deliberately distinct from supercode's client-allowlist `on_request`)."
},
{
"id": "allow-ask-deny-rule-language",
"domain": 4,
"domain_name": "Permissions / approval / sandbox",
"capability": "Allow/ask/deny rule language",
"semantics": "Pattern rules per tool/path/domain/command",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ Tool(specifier), deny→ask→allow first-match",
"cx_detail": "✓ execpolicy Starlark .rules + granular categories",
"catalog_supercode_today": "partial (auto_approved_tools allowlist, config.rs:180-181)",
"provenance": "cc§4; cx§4; oc§4",
"status": "implemented",
"evidence": [
{
"kind": "module",
"name": "permissions.rules"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "permissions::evaluate_command(&rules, name, command, default)"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "permissions::evaluate_path_safe_roots(&rules, kind, &roots, path, default)"
},
{
"kind": "code",
"path": "crates/harness/src/permissions/rules.rs",
"symbol": "pub fn evaluate_domain(rules: &RuleSet, host: Option<&str>, default: Decision) -> Decision {"
},
{
"kind": "code",
"path": "crates/harness/src/tools/mod.rs",
"symbol": "pub(crate) fn domain_tier_of("
}
],
"note": "All four rule subjects are real, in ONE deny→ask→allow first-match engine both presets enable: per-tool (bare name), per-command (canonicalized bash), per-path (traversal/symlink-safe, now folded over every granted root), and — BP-10 — per-DOMAIN. A `domain(host-glob)` pattern is an ordinary rule in the ordinary tiers: `permissions::evaluate_domain` matches it with the same glob syntax and the same tier priority every other subject gets, its `ask` tier resolves on the same approval door, and the `sandbox.network` allow/deny lists are TRANSLATED into that same algebra (`NetworkPolicy::domain_rule_set`) rather than checked by a second matcher. Proved over both resolved presets: `agent::bp10_permissions_tests::domain_rules_are_part_of_the_rule_algebra_under_both_presets`."
},
{
"id": "command-parsing-for-permission-matching",
"domain": 4,
"domain_name": "Permissions / approval / sandbox",
"capability": "Command parsing for permission matching",
"semantics": "Compound/prefix/wrapper-aware bash rule matching",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ (separators, wrappers stripped, save-5-rules)",
"cx_detail": "✓ canonicalization + safe-command list + prefix rules",
"catalog_supercode_today": "—",
"provenance": "cc§4; cx§4; oc§4",
"status": "implemented",
"evidence": [
{
"kind": "module",
"name": "permissions.rules"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "permissions::evaluate_command(&rules, name, command, default)"
},
{
"kind": "code",
"path": "crates/harness/src/permissions/canon.rs",
"symbol": "let mut parser = tree_sitter::Parser::new();"
}
],
"note": "`permissions::canon` parses each bash command with tree-sitter-bash (opencode's own grammar) into subcommands, stripping wrappers and splitting compounds before any rule is matched, and fails CLOSED on an ERROR/MISSING node rather than matching a half-parsed string. The engine both presets enable evaluates every subcommand, so a compound or wrapped command cannot slip past a rule authored against its inner command."
},
{
"id": "session-approval-caching-don-t-ask-again",
"domain": 4,
"domain_name": "Permissions / approval / sandbox",
"capability": "Session approval caching (\"don't ask again\")",
"semantics": "Approvals persisted per session/project/prefix",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ (per project+command; edits per session)",
"cx_detail": "✓ with_cached_approval + saved prefix rules",
"catalog_supercode_today": "—",
"provenance": "cc§4; cx§4; oc§4",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "permissions::resolve_ask(&self.permissions_approval_cache, handler, &req)"
},
{
"kind": "code",
"path": "crates/harness/src/permissions/approval.rs",
"symbol": "pub fn persistent(store: impl Into<PathBuf>) -> Self {"
},
{
"kind": "code",
"path": "crates/harness/src/permissions/approval.rs",
"symbol": "pub fn cache_for_config(config: &crate::Config) -> ApprovalCache {"
},
{
"kind": "config",
"key": "capabilities.permissions.approvals.persist"
}
],
"note": "An `Ask` resolved `AllowForSession` is cached by tool+subject (full-args digest for non-builtins) and later matching calls skip the handler — and BP-10 makes that grant OUTLIVE THE PROCESS. `capabilities.permissions.approvals.persist` (both presets set it) backs the cache with `$SUPERCODE_HOME/approvals/<project tag>.json`, the same `$SUPERCODE_HOME`/project-tag layout the checkpoint shadow store uses, so an approval sits beside the session's other per-project records. Reversible by construction: the file IS the state, so `ApprovalCache::clear` (or deleting it) makes the next matching call re-ask. Proved over both resolved presets across two Agents with a deny-everything door installed on the second: `agent::bp10_permissions_tests::an_approval_grant_survives_the_process_and_a_clear_re_asks`."
},
{
"id": "deny-with-feedback-to-the-model",
"domain": 4,
"domain_name": "Permissions / approval / sandbox",
"capability": "Deny-with-feedback to the model",
"semantics": "Rejection reason fed back as model-visible correction",
"cc": "variant",
"cx": "variant",
"cc_detail": "✓* (deny reason)",
"cx_detail": "✓* (failure returns to model)",
"catalog_supercode_today": "✓ PreToolHook Some(reason) blocks + feeds back (config.rs:48-51)",
"provenance": "cc§4; cx§4; oc§4; pi§4",
"status": "implemented",
"evidence": [
{
"kind": "module",
"name": "permissions"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "if let Some(reason) = self.permissions_gate_denial(name, &args, hook_decision) {"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "if let Some(hook) = &self.config.pre_tool_hook {"
}
],
"note": "A refused call never silently vanishes: the gate's reason string is returned to the loop as that call's tool result (`Error: <reason>`), so the model sees the refusal and its cause on the next request. Both refusal sources feed the same channel — the permissions engine's decision and a `pre_tool` hook's `Some(reason)` veto."
},
{
"id": "filesystem-sandbox-os-enforced",
"domain": 4,
"domain_name": "Permissions / approval / sandbox",
"capability": "Filesystem sandbox (OS-enforced)",
"semantics": "Kernel-level fs isolation for tool processes",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ opt-in (seatbelt/bwrap; fs+net+creds lists)",
"cx_detail": "✓ default modes (Seatbelt/Landlock/Windows)",
"catalog_supercode_today": "✓* SandboxPolicy ReadOnly/WorkspaceWrite/DangerFullAccess; seatbelt profile for bash (tools/mod.rs:35-43; builtins.rs:552-556)",
"provenance": "cc§4; cx§4; pi§4",
"status": "implemented",
"evidence": [
{
"kind": "config",
"key": "capabilities.permissions.sandbox"
},
{
"kind": "code",
"path": "crates/harness/src/tools/builtins.rs",
"symbol": "let plan = resolve_sandbox_plan(ctx, command)?;"
},
{
"kind": "code",
"path": "crates/harness/src/tools/builtins.rs",
"symbol": "let fs_decision = decide_fs("
}
],
"note": "Real kernel confinement of the spawned shell subprocess: seatbelt on macOS, Landlock on Linux (applied in the forked child before exec, so only the tool's process tree is confined). Both presets set the key explicitly and to their harness's own default posture — cc-parity `enabled = false` (CC's `/sandbox` is opt-in), cx-parity `sandbox = \"workspace_write\"`. A confining tier a platform cannot enforce refuses to run rather than silently running unconfined. Depth is narrower than upstream's (no bwrap/seccomp, no Windows sandbox levels)."
},
{
"id": "network-sandbox-domain-rules",
"domain": 4,
"domain_name": "Permissions / approval / sandbox",
"capability": "Network sandbox / domain rules",
"semantics": "Domain allow/deny + proxy enforcement",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ sandbox.network.*",
"cx_detail": "✓ permissions.network + network-proxy crate",
"catalog_supercode_today": "—",
"provenance": "cc§4; cx§4",
"status": "partial",
"evidence": [
{
"kind": "code",
"path": "crates/harness/src/tools/builtins.rs",
"symbol": ".redirect(network_checked_redirect_policy("
},
{
"kind": "code",
"path": "crates/harness/src/tools/builtins.rs",
"symbol": "fn seatbelt_profile(ctx: &ToolContext, plan: &SandboxPlan) -> Option<String> {"
},
{
"kind": "config",
"key": "capabilities.permissions.sandbox.network"
}
],
"note": "BP-10 closed the row's two ARMING gaps. (a) Both presets now state their network posture: cx-parity sets `sandbox.network.enabled = true` (its `workspace_write` claim, cx§4) and cc-parity states CC's opt-in `false`; before this neither preset set `sandbox.network.*` at all, so no policy was active under either. (b) The cut-off is REAL on this host, not a warning: macOS gets seatbelt's `(deny network*)` in the same profile that confines writes, Linux a fresh network namespace. Domain allow/deny is enforced for the harness's own network tools (`web_fetch`/`web_search`, including every redirect hop) through the ONE rule engine's `domain(...)` subject. STILL MISSING, precisely: per-domain filtering of arbitrary SUBPROCESS traffic. Neither OS primitive can express it — seatbelt's `network*` filter has no hostname predicate and Landlock's network scoping (ABI v4, kernel ≥6.7) is port-level, not name-level — so a subprocess is either fully cut off or fully open. What CC's `sandbox.network.*` and cx's `network-proxy` crate both do here needs the TLS-terminating proxy COMPOSABLE-HARNESS-DESIGN.md §4.3 lists as the irreducible `Network-MITM permission proxy`, which supercode does not have."
},
{
"id": "sandbox-escalation-path",
"domain": 4,
"domain_name": "Permissions / approval / sandbox",
"capability": "Sandbox-escalation path",
"semantics": "Fail in sandbox → model justifies → approved unsandboxed rerun",
"cc": "variant",
"cx": "yes",
"cc_detail": "✓* allowUnsandboxedCommands",
"cx_detail": "✓ sandbox_permissions:\"require_escalated\"+justification",
"catalog_supercode_today": "—",
"provenance": "cc§4; cx§4",
"status": "implemented",
"evidence": [
{
"kind": "config",
"key": "capabilities.permissions.sandbox.escalation"
},
{
"kind": "code",
"path": "crates/harness/src/tools/builtins.rs",
"symbol": "fn escalation_requested("
},
{
"kind": "code",
"path": "crates/harness/src/tools/builtins.rs",
"symbol": "pub(crate) fn build_unsandboxed_sh(command: &str, ctx: &ToolContext) -> tokio::process::Command {"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": ".get(\"with_escalated_permissions\")"
}
],
"note": "The whole flow exists, in Codex's own spelling. FAIL IN SANDBOX: a confined `bash` call that exits non-zero with a confinement-shaped error gets the escalation channel named in its own result (`looks_sandbox_denied` → `escalation_hint`), so the model can discover the path at all. MODEL JUSTIFIES: `with_escalated_permissions` + `justification` are advertised arguments (cx§4 `sandbox_permissions: \"require_escalated\"`). APPROVED UNSANDBOXED RERUN: the request is a TIER of the one engine — `Agent::permissions_gate_denial_impl` forces such a call to at least `Ask` (which is what made it a no-op under cx-parity's `model_requested` Allow baseline), the door sees the justification in `raw_args`, and only then does `build_unsandboxed_sh` spawn without the confinement wrapper. The request is never the grant: `stricter` only tightens, so a deny rule still refuses, and the tool refuses the flag outright where no engine adjudicated it. Both presets set `escalation`. Proved over the resolved cx-parity preset: `agent::bp10_permissions_tests::a_model_requested_escalation_is_forced_to_the_ask_tier_with_its_justification`."
},
{
"id": "protected-paths",
"domain": 4,
"domain_name": "Permissions / approval / sandbox",
"capability": "Protected paths",
"semantics": "Paths never auto-approved / kept read-only",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ (.git, rc files, .claude…)",
"cx_detail": "✓ (.git/.codex read-only in writable roots)",
"catalog_supercode_today": "—",
"provenance": "cc§4; cx§4; oc§4; pi§4",
"status": "implemented",
"evidence": [
{
"kind": "module",
"name": "permissions.protected_paths"
},
{
"kind": "config",
"key": "capabilities.permissions.protected_paths.paths"
},
{
"kind": "code",
"path": "crates/harness/src/permissions/mod.rs",
"symbol": "deny.extend(protected_path_deny_rules("
}
],
"note": "Both presets enable the module and pin their harness's own path set (cc-parity `.git/**`, `.env*`, `.claude/**`, …; cx-parity `.git/**`, `.codex/**`). The paths are expanded into DENY rules prepended to the rule set on every gate evaluation, so they outrank the approval policy — a protected path is refused even under `approval = never`. Coverage is the rule layer: file tools, apply_patch targets, shell redirect targets and enumerated argv-writers, with any write shape it recognizes but cannot statically resolve forced to at least Ask."
},
{
"id": "project-workspace-trust-gate",
"domain": 4,
"domain_name": "Permissions / approval / sandbox",
"capability": "Project/workspace trust gate",
"semantics": "Prompt before loading project-local config/code",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ workspace trust (settings allow rules)",
"cx_detail": "✓ trust_level (project config+hooks gated)",
"catalog_supercode_today": "—",
"provenance": "cc§4; cx§4; pi§4",
"status": "implemented",
"evidence": [
{
"kind": "module",
"name": "trust"
},
{
"kind": "config",
"key": "capabilities.trust.default"
},
{
"kind": "code",
"path": "crates/harness/src/trust.rs",
"symbol": "pub fn is_trusted(config: &crate::Config, surface: TrustSurface) -> bool {"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "if !crate::trust::is_trusted(config, crate::trust::TrustSurface::Instructions) {"
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "struct InteractiveTrustPrompt;"
}
],
"note": "The PROMPT exists now, and it bites. `crate::trust` is the consumer of `TrustDecision::Ask` that was missing: the question is an `ApprovalRequest` on the SAME approval-handler trait every other `Ask` uses, installed on `Config::trust_handler` (not on `Agent` — every gated surface is decided before construction), with the CLI's `InteractiveTrustPrompt` as the real interactive door. The answer is recorded per project in `$SUPERCODE_HOME/trust/<project tag>.json` and revoked by deleting it. It gates THREE surfaces on one decision: project instruction files (CLAUDE.md/AGENTS.md and the agent-package tier), config-declared lifecycle hooks, and plugin code (`plugins::is_trusted` routes through it). Stated exactly: with NO door installed each surface keeps its PRE-BP-10 outcome (plugin code refused, hooks installed, instruction text loaded), so a scripted run never loses behaviour to a question nobody can answer; an explicit `default = \"never\"` refuses all three. Proved over both resolved presets: `agent::bp10_permissions_tests::a_refused_trust_prompt_keeps_project_instructions_out_of_the_prompt`."
},
{
"id": "hook-plugin-permission-veto",
"domain": 4,
"domain_name": "Permissions / approval / sandbox",
"capability": "Hook/plugin permission veto",
"semantics": "Programmatic allow/deny/rewrite before the user sees it",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ PreToolUse + PermissionRequest hooks",
"cx_detail": "✓ PreToolUse/PermissionRequest hooks",
"catalog_supercode_today": "✓ pre_tool_hook (config.rs:48-51, 186-187)",
"provenance": "cc§4; cx§7; oc§4; pi§7",
"status": "implemented",
"evidence": [
{
"kind": "module",
"name": "hooks"
},
{
"kind": "code",
"path": "crates/harness/src/config.rs",
"symbol": "pub enum HookDecision {"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "fn run_pre_tool_hook("
},
{
"kind": "code",
"path": "crates/cli/src/hooks.rs",
"symbol": "fn parse_pre_tool_stdout(stdout: &str) -> PreToolOutcome {"
}
],
"note": "All of \"programmatic allow/deny/rewrite before the user sees it\". A `[hooks] pre_tool` command now returns a `PreToolOutcome`, not a bare deny: `deny` refuses fail-closed (unchanged, including on spawn error/timeout), `allow` ANSWERS an `Ask` on the user's behalf without a prompt (CC's `PermissionRequest`-class reply), `ask` forces a prompt the rules alone would not have raised, and `updated_args` REWRITES the call. CC's own PreToolUse JSON (`hookSpecificOutput.permissionDecision`/`permissionDecisionReason`/`updatedInput`) is parsed as-is, so a hook written for Claude Code works unchanged. It is a TIER, not a second gate: the hook runs BEFORE the engine so the rules judge the REWRITTEN arguments (a rewrite cannot launder a denied command past them), and `allow` can never lift a `deny` rule or a protected path. Proved over both resolved presets: `agent::bp10_permissions_tests::a_hook_allow_answers_the_ask`, `..._a_hook_rewrite_is_what_the_engine_judges_and_what_runs`."
},
{
"id": "llm-safety-classifier-approvals-auto-mode",
"domain": 4,
"domain_name": "Permissions / approval / sandbox",
"capability": "LLM safety-classifier approvals (auto mode)",
"semantics": "Server-side classifier decides non-read actions",
"cc": "yes",
"cx": "no",
"cc_detail": "✓ (block-list taxonomy, fallback after denials)",
"cx_detail": "—",
"catalog_supercode_today": "—",
"provenance": "cc§4",
"status": "irreducible",
"evidence": [],
"note": "COMPOSABLE-HARNESS-DESIGN.md §4.2 cc-parity \"Irreducible gaps\" table, `Auto permission mode (LLM safety classifier)` row: the classifier is Anthropic-server-side over a curated slice with a server-side result probe, so \"a local imitation would be a different (weaker) security claim; the preset's honest ceiling is `untrusted` + rules + `dontAsk`-style deny defaults.\" Only cc has the row."
},
{
"id": "approvals-routed-to-a-reviewer-agent",
"domain": 4,
"domain_name": "Permissions / approval / sandbox",
"capability": "Approvals routed to a reviewer agent",
"semantics": "Second model reviews and answers approval requests",
"cc": "no",
"cx": "yes",
"cc_detail": "—",
"cx_detail": "✓ approvals_reviewer=\"auto_review\" (guardian)",
"catalog_supercode_today": "—",
"provenance": "cx§4",
"status": "irreducible",
"evidence": [],
"note": "COMPOSABLE-HARNESS-DESIGN.md §4.3 cx-parity \"Irreducible gaps\" table, `Guardian auto-reviewer` row: \"`approvals_reviewer = \\\"auto_review\\\"` with a restricted-tool guardian agent (cx§1:96, cx§4) — an agent-in-the-approval-loop architecture; UNIQUE-class.\" Only cx has the row."
},
{
"id": "named-permission-profiles",
"domain": 4,
"domain_name": "Permissions / approval / sandbox",
"capability": "Named permission profiles",
"semantics": "Reusable, inheritable permission bundles",
"cc": "no",
"cx": "yes",
"cc_detail": "—¹²",
"cx_detail": "✓ [permissions.<name>] extends, fs+net rules (Beta)",
"catalog_supercode_today": "✓* ConfigProfile carries sandbox+approval (config.rs:326-346)",
"provenance": "cx§4; oc§4",
"status": "implemented",
"evidence": [
{
"kind": "config",
"key": "capabilities.permissions.profiles"
},
{
"kind": "code",
"path": "crates/harness/src/configfile.rs",
"symbol": "fn apply_permission_profile(hc: &mut HarnessConfig) -> Vec<String> {"
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "permission_profile: Option<String>,"
}
],
"note": "`[capabilities.permissions.profiles.<name>]` is cx§4's `[permissions.<name>]` Beta: a reusable bundle carrying the sandbox tier plus fs rules and protected paths, with `extends` inheritance (chased root-first, cycle- and depth-guarded). It is selectable PER RUN — `supercode --permission-profile <name>`, deliberately sugar for `-c capabilities.permissions.profile=<name>` so the selection travels the same resolver layer every other key does rather than a flag-only side channel into the engine. cx-parity ships three (`read-only`, `workspace-write`, `locked-down extends read-only`). Folded into the ONE engine before validation, so a bundle's deny rules are ordinary deny rules (they hide tools at schema time like any other) and the fold is monotonic: a bundle may ADD a floor, never remove one the config already set. `approval` is accepted from a user's bundle but the shipped three do not set it — §2.2 C4/C6 couple the approval mode to the loop's shape. Proved over the resolved cx-parity preset: `agent::bp10_permissions_tests::a_named_permission_profile_is_selectable_per_run`, `..._a_profile_extends_its_ancestor_and_its_rules_join_the_one_engine`."
},
{
"id": "tool-hiding-via-policy",
"domain": 4,
"domain_name": "Permissions / approval / sandbox",
"capability": "Tool hiding via policy",
"semantics": "Deny/disable removes the tool from the model's view",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ bare-name deny",
"cx_detail": "✓ disabled_tools / enabled_tools",
"catalog_supercode_today": "✓ ToolOverride.enabled (config.rs:101-104)",
"provenance": "cc§4; cx§6; oc§4; pi§4",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": ".filter(|t| self.config.tool_enabled(t.name()))"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "out.retain(|schema| !self.policy_hides_tool(&schema.name));"
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "disallow_tool: Vec<String>,"
},
{
"kind": "code",
"path": "crates/harness/src/tools/mod.rs",
"symbol": "config.core_tools_enabled.iter().any(|t| t == name)"
}
],
"note": "Three doors, and the rule layer is the third. (1) `--disallow-tool` sets `ToolOverride::enabled = false`. (2) `core.tools.enabled` shapes the registry, so cx-parity never registers read/write/edit at all. (3) BP-10: a `capabilities.permissions.rules.deny` entry that a tool NAME alone satisfies now REMOVES the tool from the model's view (cc§4's bare-name deny), applied once over the finished schema array so every appended family (`spawn_subagent`, `background_*`, the Claude aliases) is hidden by the same one rule. Only the CONFIG-declared deny tier hides: a rule naming a command/path (`bash(rm -rf*)`) cannot be satisfied without a subject and so still refuses at dispatch without hiding, and plan mode's runtime narrowing is a MODE, not a policy — CC's plan mode refuses a write, it does not make Write vanish and reappear mid-session. Proved over both resolved presets: `agent::bp10_permissions_tests::a_bare_name_deny_hides_the_tool_from_the_model`."
},
{
"id": "additional-working-directories",
"domain": 4,
"domain_name": "Permissions / approval / sandbox",
"capability": "Additional working directories",
"semantics": "Extra roots granted beyond cwd",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ --add-dir/additionalDirectories",
"cx_detail": "✓ --add-dir writable roots",
"catalog_supercode_today": "✓ additional_dirs (config.rs:167-169)",
"provenance": "cc§4; cx§4; oc§4",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "if let Some(dirs) = &fc.core.additional_dirs {"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "for root in walk.iter().chain(config.additional_dirs.iter()) {"
},
{
"kind": "code",
"path": "crates/harness/src/tools/mod.rs",
"symbol": "pub extra_roots: Vec<PathBuf>,"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "extra_roots: config.additional_dirs.clone(),"
},
{
"kind": "code",
"path": "crates/harness/src/permissions/rules.rs",
"symbol": "pub fn evaluate_path_safe_roots("
}
],
"note": "An extra root is a real GRANT now, not just a discovery hint. `--add-dir`/`core.additional_dirs` reach `ToolContext::extra_roots`, and all three enforcement points read the one `ToolContext::write_roots` list: `check_write` treats a path under a granted root as inside the workspace, the OS backstop adds each root to the subprocess's writable set (seatbelt `subpath` on macOS, Landlock on Linux), and the permissions engine's path rules are evaluated relative to every root. That last one is why the fold exists: evaluating against `cwd` alone meant a write to `<extra root>/.git/config` matched no root-relative pattern and fell through to the default — i.e. granting a directory silently also removed the protected-path floor inside it. Proved over the resolved cx-parity preset (`workspace_write`): `agent::bp10_permissions_tests::an_extra_root_is_writable_and_still_carries_the_protected_path_floor`."
},
{
"id": "child-process-env-sanitization",
"domain": 4,
"domain_name": "Permissions / approval / sandbox",
"capability": "Child-process env sanitization",
"semantics": "Control env vars passed to spawned tools",
"cc": "variant",
"cx": "yes",
"cc_detail": "✓* sandbox.credentials envVars",
"cx_detail": "✓ shell_environment_policy (default secret filter)",
"catalog_supercode_today": "—",
"provenance": "cc§4; cx§4; oc§7",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/harness/src/tools/builtins.rs",
"symbol": "apply_sandbox_env_policy(&mut cmd, ctx);"
},
{
"kind": "config",
"key": "capabilities.permissions.sandbox.env_policy"
}
],
"note": "The mechanism was already applied at every shell spawn (`inherit`/`filtered`/`none`); what was missing is that neither preset armed it, so both resolved to `Inherit` and NO sanitization happened under either. BP-10 makes both presets state their posture on the key: cx-parity sets `filtered`, matching Codex's `shell_environment_policy`, which filters secrets from a spawned shell by default (cx§4); cc-parity states `inherit`, because CC's env control is `sandbox.credentials.envVars` — an opt-in of the opt-in `/sandbox` — so a CC Bash call inherits the user's environment. An escalated (approved unsandboxed) command is still sanitized: unconfined is not un-sanitized. Proved by the CHILD's own view of the variable under each resolved preset: `agent::bp10_permissions_tests::cx_parity_strips_a_secret_from_the_spawned_shell_and_cc_parity_does_not`."
},
{
"id": "bypass-danger-modes",
"domain": 4,
"domain_name": "Permissions / approval / sandbox",
"capability": "Bypass/danger modes",
"semantics": "Skip all prompting (with residual circuit breakers)",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ bypassPermissions (+rm -rf breaker)",
"cx_detail": "✓ --yolo",
"catalog_supercode_today": "✓ ApprovalPolicy::Never is the default (config.rs:36-38)",
"provenance": "cc§4; cx§4; oc§4",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "let approval = if cli.dangerous || cli.yes {"
},
{
"kind": "code",
"path": "crates/harness/src/permissions/mod.rs",
"symbol": "deny.extend(protected_path_deny_rules("
}
],
"note": "`--dangerous` (and `-y`) skip all prompting: `--dangerous` resolves to `ApprovalPolicy::Never` plus `SandboxPolicy::DangerFullAccess`, `-y` to `Never` alone. The residual breaker is real and not bypassable by the flag — the protected-path set is expanded into DENY rules, and deny is matched before the policy-derived baseline, so a `.git/**`/`.env*` write is still refused under `never`."
},
{
"id": "managed-enterprise-policy-constraints",
"domain": 4,
"domain_name": "Permissions / approval / sandbox",
"capability": "Managed/enterprise policy constraints",
"semantics": "Admin-pinned permission/sandbox/hook/MCP limits",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ managed-only keys, fail-closed parsing",
"cx_detail": "✓ requirements.toml Constrained<T>",
"catalog_supercode_today": "—",
"provenance": "cc§4; cx§6; oc§6",
"status": "absent",
"evidence": [],
"note": "There is no managed layer. Config resolution is user file → project file (sanitized/clamped) → CLI flags, with the preset `extends` chain underneath; nothing reads a plist, registry, MDM path, or `requirements.toml`, and no field can be pinned as admin-owned and non-overridable. The project-config sanitizer is the only constraint mechanism, and it constrains the PROJECT, never the user.",
"cost": "architectural"
},
{
"id": "interactive-approval-ui",
"domain": 4,
"domain_name": "Permissions / approval / sandbox",
"capability": "Interactive approval UI",
"semantics": "Ask the human per call with once/always/reject",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓",
"cx_detail": "✓ (+/approve retry)",
"catalog_supercode_today": "partial (ApprovalHandler callback; no UI, config.rs:45-46, 183-184)",
"provenance": "cc§4; cx§4; oc§4",
"status": "implemented",
"evidence": [
{
"kind": "module",
"name": "permissions"
},
{
"kind": "code",
"path": "crates/harness/src/server.rs",
"symbol": "set_permissions_approval_handler(FrontendApprovalHandler(broker.clone()));"
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "config.approval_handler = Some(Box::new(prompt_for_approval));"
}
],
"note": "All three replies exist and reach the engine: `ApprovalOutcome::{Deny, Allow, AllowForSession}` — reject, once, and always. The frontend runtime installs `FrontendApprovalHandler`, which blocks the `Ask`-tier decision on a real user reply through the TUI's approval modal (fail-closed if the channel dies); the line-mode REPL installs a simpler y/N stdin prompt. A handler can only answer an ask the rule engine already routed to a human — it can never widen a `Deny`."
},
{
"id": "read-write-path-rules-on-file-tools",
"domain": 4,
"domain_name": "Permissions / approval / sandbox",
"capability": "Read/write path rules on file tools",
"semantics": "Path-pattern gating of Read/Edit incl. inside bash",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ (4 anchors, symlink checks, bash-visible cmds)",
"cx_detail": "✓ filesystem rules (deny>write>read, globs)",
"catalog_supercode_today": "✓* SandboxPolicy path confinement (tools/mod.rs:35-43)",
"provenance": "cc§4; cx§4; oc§1",
"status": "implemented",
"evidence": [
{
"kind": "module",
"name": "permissions.rules"
},
{
"kind": "module",
"name": "permissions.protected_paths"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "permissions::evaluate_path_safe_roots(&rules, kind, &roots, path, default)"
}
],
"note": "Path-pattern gating is evaluated per read/write kind against the RESOLVED path (normalized and symlink-checked, closing the `x/../.git/config` traversal and symlink-escape bypasses), for `read_file`/`write_file`/`edit_file`/`apply_patch` and — via the tree-sitter canonicalizer — for a bash command's redirect targets and enumerated argv-writers, so the same rules apply to writes made from inside the shell. Both presets enable the rule set and the protected-path floor it is prepended with."
},
{
"id": "append-only-durable-transcript",
"domain": 5,
"domain_name": "Session / state model",
"capability": "Append-only durable transcript",
"semantics": "Every event flushed to disk during the session",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ JSONL, continuous writes",
"cx_detail": "✓ rollout JSONL, flush-per-line, retry",
"catalog_supercode_today": "✓ (session store + reduction sidecars, reduce.rs:322-331)",
"provenance": "cc§5; cx§5; oc§5; pi§5",
"status": "implemented",
"evidence": [
{
"kind": "config",
"key": "core.session.append_only"
},
{
"kind": "code",
"path": "crates/harness/src/session_journal.rs",
"symbol": "file.flush()?;"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "if let Err(error) = guard.append_message(msg) {"
},
{
"kind": "code",
"path": "crates/harness/src/session_journal.rs",
"symbol": "pub fn arm("
}
],
"note": "Both presets set `[core.session] append_only`, which arms a `SessionJournal` on the agent: every message the loop produces is written and FLUSHED to `<name>.journal.jsonl` at the moment it exists (`Agent::record`), not at end-of-turn. `SessionStore::save`'s whole-file rewrite is now a CHECKPOINT over that log rather than the only durable write, and journal records past the last checkpoint are exactly what a crash mid-turn would have lost — `session_journal::arm` appends them back on the next open. Append-only in the strict sense: no operation shortens the file, so a rewound-away message's bytes stay where they were."
},
{
"id": "resume-continue-picker-by-id-name",
"domain": 5,
"domain_name": "Session / state model",
"capability": "Resume (continue / picker / by id-name)",
"semantics": "Reopen a prior session with context intact",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ --continue/--resume//resume",
"cx_detail": "✓ codex resume/exec resume/--last",
"catalog_supercode_today": "✓* (loads foreign sessions; own-store resume partial)",
"provenance": "cc§5; cx§5; oc§5; pi§5",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "let target = if cli.continue_ {"
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "fn resume_picker_candidates("
}
],
"note": "All three doors exist: `--continue` (most recent in this directory, cwd-tag scoped), `--last` (most recent anywhere), and `supercode resume <session>` by name or unique prefix — plus an interactive arrow-key picker when a bare resume runs on a TTY. Resuming loads the saved transcript back into the agent's history (and, for a reduced session, its sidecar, reduction log and view) before the next turn."
},
{
"id": "fork-branch-to-a-new-session",
"domain": 5,
"domain_name": "Session / state model",
"capability": "Fork/branch to a new session",
"semantics": "Copy conversation from a point into a new lineage",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ /branch, --fork-session, /fork",
"cx_detail": "✓ codex fork, forked_from_id",
"catalog_supercode_today": "partial (spliced export = fork-with-provenance)",
"provenance": "cc§5; cx§5; oc§5; pi§5",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "store.fork(&name, &new_name, &title, *at, timestamp_ms)?;"
}
],
"note": "`supercode sessions fork <session> [--at N]` copies a session into a new, independently continuable lineage — a full copy by default, or truncated to the first N messages, which is exactly the copy-plus-truncation shape both CC's `--fork-session` and CX's `codex fork` use. The fork's origin is written as a `ForkProvenance` record beside the new session, so the lineage is recoverable rather than implied."
},
{
"id": "in-place-conversation-tree",
"domain": 5,
"domain_name": "Session / state model",
"capability": "In-place conversation tree",
"semantics": "Single store holds branches; move leaf anywhere",
"cc": "variant",
"cx": "no",
"cc_detail": "✓* (uuid/parentUuid tree; surfaced via /rewind)",
"cx_detail": "—¹³",
"catalog_supercode_today": "—",
"provenance": "cc§5; cx§5; pi§3",
"status": "implemented",
"evidence": [
{
"kind": "module",
"name": "session_tree"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "let session_tree = if config.session_tree_enabled {"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "tree.append_message(msg.clone(), now_ms());"
},
{
"kind": "code",
"path": "crates/harness/src/session_journal.rs",
"symbol": "let _ = store.save_tree(name, tree);"
},
{
"kind": "code",
"path": "crates/interchange/src/session_tree.rs",
"symbol": "pub fn active_path(&self) -> Result<Vec<NodeId>> {"
}
],
"note": "`Config::session_tree_enabled` has its reader: under cc-parity the agent materializes a `SessionTree` at construction, every recorded message becomes a node, the tree is persisted with the session (`save_tree`) and reloaded on resume (`load_tree`), and `Agent::rewind_conversation` moves the ACTIVE BRANCH'S LEAF to a node named by `SessionTree::active_path` — preserving the old leaf under a sibling branch, which is the row's \"move leaf anywhere\". cx-parity leaves the module off and has no tree, matching its own `—` column."
},
{
"id": "rewind-rollback-conversation",
"domain": 5,
"domain_name": "Session / state model",
"capability": "Rewind / rollback conversation",
"semantics": "Restore conversation (± code) to an earlier point",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ /rewind menu (conversation and/or code)",
"cx_detail": "✓ ThreadRollback + double-Esc edit-and-fork",
"catalog_supercode_today": "—",
"provenance": "cc§5; cx§5; oc§4; pi§3",
"status": "implemented",
"evidence": [
{
"kind": "config",
"key": "capabilities.checkpoint"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "pub fn rewind_conversation(&mut self, keep: usize) -> RewindOutcome {"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "pub fn undo_rewind(&mut self) -> bool {"
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "fn handle_rewind(agent: &mut SdkAgent, persist_name: Option<&str>, arg: &str) {"
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "let report = cp.restore(&id)?;"
}
],
"note": "`/rewind` is the menu: bare, it lists this conversation's rewind points; `/rewind <n>` moves THIS session back to an arbitrary earlier point in place (not `/undo`'s last exchange, and not `sessions fork --at`'s new session); `/rewind undo` inverts it. The operation is RECORDED — an appended journal record, so nothing is deleted and the removed messages stay recoverable — and the undo stack itself is restored from the journal on resume, so a rewind stays reversible across a restart. Under cc-parity the code half is paired in: the same call restores that turn's checkpoint file snapshot. cx-parity arms `checkpoint` for turn-diff TRACKING only (BP-7's `restore = false`, Codex's own shape), so there is no file snapshot to pair in there and the conversation moves alone — which is exactly Codex's own ThreadRollback."
},
{
"id": "file-checkpointing-code-restore",
"domain": 5,
"domain_name": "Session / state model",
"capability": "File checkpointing / code restore",
"semantics": "Harness-tracked file snapshots restorable per prompt",
"cc": "yes",
"cx": "no",
"cc_detail": "✓ file-history-snapshot (not bash-made edits)",
"cx_detail": "— (ghost_snapshot legacy, stripped)",
"catalog_supercode_today": "—",
"provenance": "cc§5; cx§5; oc§4; pi§10",
"status": "implemented",
"evidence": [
{
"kind": "module",
"name": "checkpoint"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "cp.begin_turn(&label);"
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "let report = cp.restore(&id)?;"
}
],
"note": "cc-parity enables the module and the loop opens a checkpoint at the top of every turn; each write-tool call records the file's pre-image into that turn's manifest. `checkpoint list/diff/restore` then restores per prompt — rewriting modified files and deleting ones the turn created — with every target re-validated against project containment and the protected-path floor, refusals reported rather than silently applied. Same documented limitation as CC's: an edit made by bash rather than a write tool is not captured."
},
{
"id": "session-naming-rename",
"domain": 5,
"domain_name": "Session / state model",
"capability": "Session naming/rename",
"semantics": "Human handles for sessions, usable for resume",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ -n//rename/auto-name",
"cx_detail": "✓ session_index.jsonl + /rename",
"catalog_supercode_today": "—",
"provenance": "cc§5; cx§5; oc§5; pi§3",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/harness/src/configfile.rs",
"symbol": "session_persist: c.session.persist,"
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "let name = new_session_name(&cwd_for_name, agent.session_name());"
},
{
"kind": "code",
"path": "crates/harness/src/store.rs",
"symbol": "pub fn rename(&self, from: &str, to: &str) -> Result<()> {"
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "store.rename(&name, new_name)?;"
}
],
"note": "Sessions get human handles that work for resume — `[core.session] name` pins one, otherwise a memorable `<tag>-<adjective>-<noun>` is minted, and every resume door takes a name or unique prefix — and the RENAME half now exists: `supercode sessions rename <session> <new-name>` moves the handle itself by moving the whole `<name>.*` family (refusing up front on a collision rather than half-moving), records the rename in the journal, and leaves the old handle resolving to nothing. `--title` keeps `set_title`'s display-only behaviour, so the two halves are separable."
},
{
"id": "session-picker-ux",
"domain": 5,
"domain_name": "Session / state model",
"capability": "Session picker UX",
"semantics": "Search/preview/filter/rename/delete over sessions",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ (scope widening, PR-URL search)",
"cx_detail": "✓ (cwd-scoped, --all, non-interactive filter)",
"catalog_supercode_today": "—",
"provenance": "cc§5; cx§8; oc§8; pi§5",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "fn resume_picker_candidates("
},
{
"kind": "code",
"path": "crates/cli/src/picker.rs",
"symbol": "pub fn filter_items(items: &[PickerItem], query: &str) -> Vec<usize> {"
},
{
"kind": "code",
"path": "crates/cli/src/picker.rs",
"symbol": "pub fn pick_searchable("
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "PickerScope::Everywhere => None,"
}
],
"note": "The interactive picker now has the row's own semantics: type-to-search filters live over every candidate's id, title and preview (all whitespace-separated terms must match); the highlighted row shows a PREVIEW — the session's own first user line plus its message count — from the derived index, so it costs no extra read; and Ctrl-W widens scope past the cwd tag to every non-archived session (an empty cwd scope widens automatically rather than refusing). Rename/delete are `sessions rename`/`sessions delete`, not in-picker keystrokes — the same split cx's own cell describes (\"cwd-scoped, --all, non-interactive filter\") and one CC's cell (\"scope widening, PR-URL search\") does not contradict."
},
{
"id": "archive-delete-lifecycle-retention",
"domain": 5,
"domain_name": "Session / state model",
"capability": "Archive/delete lifecycle + retention",
"semantics": "Explicit archive dirs or auto-cleanup windows",
"cc": "variant",
"cx": "yes",
"cc_detail": "✓* cleanupPeriodDays (30d)",
"cx_detail": "✓ archive/unarchive/delete + archived_sessions/",
"catalog_supercode_today": "—",
"provenance": "cc§5; cx§5; oc§5; pi§5",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "let pruned = store.prune_expired(days, std::time::SystemTime::now())?;"
},
{
"kind": "code",
"path": "crates/harness/src/store.rs",
"symbol": "pub fn archive(&self, name: &str) -> Result<()> {"
}
],
"note": "Both halves the row names: an explicit archive directory (`sessions archive` moves the transcript, sidecar, reduction log and subagent transcripts into it; loaders read from either location) plus `sessions delete`, and a retention window — `sessions prune [--retention-days N]`, falling back to `core.session.retention_days`, permanently deletes archived sessions older than the window."
},
{
"id": "derived-index-cache-over-transcripts",
"domain": 5,
"domain_name": "Session / state model",
"capability": "Derived index/cache over transcripts",
"semantics": "Fast listing DB rebuilt from the authoritative log",
"cc": "no",
"cx": "yes",
"cc_detail": "—¹⁴",
"cx_detail": "✓ state_5.sqlite (read-repaired, fs fallback)",
"catalog_supercode_today": "—",
"provenance": "cx§5; oc§5; pi§5",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/harness/src/harness_service.rs",
"symbol": "crate::session_index::SessionIndexSubscription::open("
},
{
"kind": "code",
"path": "crates/harness/src/store.rs",
"symbol": "pub fn index(&self) -> SessionIndex {"
},
{
"kind": "code",
"path": "crates/harness/src/store.rs",
"symbol": "pub fn invalidate_index(&self) {"
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "let sessions = store.index().entries;"
}
],
"note": "Two halves, both present. Over FOREIGN transcripts, `SessionIndexSubscription` treats filesystem events as invalidation hints and reconciles periodically to repair coalesced or dropped ones. Over supercode's OWN store, `SessionStore::index` is the persistent cache the row's \"fast listing DB\" names: `<root>/.session-index.json` carries title, ordering time, message count and a first-line preview per session, each row validated against its transcript's `(mtime, size)` so an unchanged row is served without opening the file and a changed one is re-read alone (read-repair, with the counters to prove which happened). The transcripts stay the only record — deleting the cache rebuilds an identical answer. `sessions list` and the resume picker both read it instead of stat-and-read-per-session."
},
{
"id": "cross-session-prompt-history",
"domain": 5,
"domain_name": "Session / state model",
"capability": "Cross-session prompt history",
"semantics": "Reverse-search over past prompts across sessions",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ Ctrl+R (100 unique)",
"cx_detail": "✓ history.jsonl (locked, trimmed)",
"catalog_supercode_today": "—",
"provenance": "cc§8; cx§5",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "let history_file = uc::config_home().join(\"history.txt\");"
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": ".load_history(&history_file);"
}
],
"note": "The REPL loads and saves one shared prompt history at `<config home>/history.txt`, so prompts typed in one session are searchable from any later session in any directory, and rustyline's Ctrl+R reverse search is the search surface — the same affordance the row names for CC."
},
{
"id": "export-import-interchange",
"domain": 5,
"domain_name": "Session / state model",
"capability": "Export/import interchange",
"semantics": "Session exported to a documented shape; importable",
"cc": "variant",
"cx": "no",
"cc_detail": "✓* /export text; -p json; format internal",
"cx_detail": "—¹⁵",
"catalog_supercode_today": "✓ (whole product: lossless load/export of CC/CX/OC/PI formats — see cx§10 supercode notes)",
"provenance": "cc§5; cx§5; oc§5; pi§5",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "session.to_jsonl(format)?"
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "let name = resolve_session(&store, session)?;"
}
],
"note": "This is the product's own core: `supercode convert <file> --to <format>` loads any supported session and re-emits it in a documented, importable shape (with a raw-passthrough path that makes a same-format convert byte-identical, and hard failures rather than silent loss when a parse would drop content), `supercode resume <file>` imports one to continue, and `sessions export` renders a human-readable text/HTML view."
},
{
"id": "session-sharing-public-link",
"domain": 5,
"domain_name": "Session / state model",
"capability": "Session sharing (public link)",
"semantics": "Push transcript to a viewable share URL",
"cc": "no",
"cx": "no",
"cc_detail": "—",
"cx_detail": "—",
"catalog_supercode_today": "—",
"provenance": "oc§5; pi§8",
"status": "not_applicable",
"evidence": [],
"note": ""
},
{
"id": "subagent-transcripts-linked-to-parent",
"domain": 5,
"domain_name": "Session / state model",
"capability": "Subagent transcripts linked to parent",
"semantics": "Child conversations stored + join-keyed to the spawn call",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ subagents/*.jsonl, isSidechain, tool_use_id",
"cx_detail": "✓ separate rollouts w/ lineage meta (ThreadSpawn)",
"catalog_supercode_today": "✓* (parses CC sidechain layout on import)",
"provenance": "cc§5; cx§5; oc§3",
"status": "implemented",
"evidence": [
{
"kind": "module",
"name": "subagents"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "let _ = store.save_subagent_transcript(parent_name, child_id, &sidecar_jsonl);"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "let _ = store.save_subagent_lineage(parent_name, child_id, lineage);"
}
],
"note": "A spawned child's own transcript is written under the parent session's subagent directory, keyed by child id, and a separate lineage record joins it back to the spawning call — so a child conversation is stored in full and addressable from the parent, not just summarized into the parent's tool result. The `subagents` module that produces them is on in both presets."
},
{
"id": "ephemeral-no-persist-mode",
"domain": 5,
"domain_name": "Session / state model",
"capability": "Ephemeral / no-persist mode",
"semantics": "Run without writing a session file",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ --no-session-persistence",
"cx_detail": "✓ exec --ephemeral",
"catalog_supercode_today": "—",
"provenance": "cc§5; cx§5; pi§5",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/harness/src/configfile.rs",
"symbol": "session_persist: c.session.persist,"
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "if !agent.session_persist() {"
}
],
"note": "`[core.session] persist = false` resolves into `Config::session_persist`, and every write path checks it first: `persist_session`, the explicit reduced-view writer, and the auto-titler all return immediately, so a run leaves no transcript, metadata, sidecar or title behind."
},
{
"id": "format-versioning-migration",
"domain": 5,
"domain_name": "Session / state model",
"capability": "Format versioning/migration",
"semantics": "Version markers + in-place upgrade of old files",
"cc": "no",
"cx": "variant",
"cc_detail": "—¹⁶",
"cx_detail": "✓* legacy aliases/backfills; versionless-additive",
"catalog_supercode_today": "✓* (tolerates all generations of all four formats)",
"provenance": "cx§5; oc§5; pi§5",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/interchange/src/sidecar.rs",
"symbol": "supercode_turn: 1,"
},
{
"kind": "code",
"path": "crates/harness/src/store.rs",
"symbol": "pub const FORMAT_VERSION: u32 = 2;"
},
{
"kind": "code",
"path": "crates/harness/src/store.rs",
"symbol": "pub fn upgrade_in_place(&self, name: &str) -> Result<Option<FormatUpgrade>> {"
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "fn upgrade_session_format(store: &SessionStore, name: &str, quiet: bool) {"
}
],
"note": "Version MARKERS: every native record carries a `supercode_turn` discriminant, every journal record a `supercode_journal` one, and a session's meta now carries `format_version` (absent reads as generation 0 — every pre-BP-8 session). IN-PLACE UPGRADE: the first open of an unmarked session rewrites `<name>.jsonl` through a per-line `ChatMessage` round-trip that drops keys this build does not model and normalizes the rest, then stamps the marker — so the tolerant path is paid once, not on every read, and a second open is a no-op. REVERSIBLE: the original bytes are copied verbatim to `<name>.v<old>.jsonl` before anything is rewritten, and the upgrade is recorded in the journal naming that file. The loaders' tolerance across every generation of all four foreign formats is unchanged — that tolerance is the product's own reason to exist and is deliberately NOT migrated away."
},
{
"id": "event-sourced-session-engine",
"domain": 5,
"domain_name": "Session / state model",
"capability": "Event-sourced session engine",
"semantics": "Typed event stream + projector rebuilding views",
"cc": "no",
"cx": "no",
"cc_detail": "—",
"cx_detail": "—",
"catalog_supercode_today": "—",
"provenance": "oc§5",
"status": "not_applicable",
"evidence": [],
"note": ""
},
{
"id": "transcript-compression-at-rest",
"domain": 5,
"domain_name": "Session / state model",
"capability": "Transcript compression at rest",
"semantics": "Idle logs compressed, rematerialized on resume",
"cc": "no",
"cx": "yes",
"cc_detail": "—",
"cx_detail": "✓ zstd + lock file",
"catalog_supercode_today": "—",
"provenance": "cx§5",
"status": "irreducible",
"evidence": [],
"note": "COMPOSABLE-HARNESS-DESIGN.md §4.3 cx-parity \"Irreducible gaps\" table, `Long tail` row: \"Code mode (`exec`/`wait` cells), CSV fan-out jobs, config lockfile, zstd transcript compression, ChatGPT app handoff, cloud tasks, realtime voice (cx§1, cx§6, cx§10) — UNIQUE CX rows (catalog §1) and `integrations`-scope.\" Only cx has the row."
},
{
"id": "queued-prompt-persistence",
"domain": 5,
"domain_name": "Session / state model",
"capability": "Queued-prompt persistence",
"semantics": "Pending user inputs survive in the store",
"cc": "yes",
"cx": "no",
"cc_detail": "✓ queue-operation records",
"cx_detail": "—",
"catalog_supercode_today": "—",
"provenance": "cc§5; oc§5",
"status": "implemented",
"evidence": [
{
"kind": "config",
"key": "core.session.queue_persist"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "if self.config.session_queue_persist {"
},
{
"kind": "code",
"path": "crates/harness/src/session_journal.rs",
"symbol": "agent.restore_queues(&state.steer_queue, &state.follow_up_queue);"
}
],
"note": "cc-parity sets `[core.session] queue_persist`, and both of the agent's input queues now write QUEUE-OPERATION records to the session journal — CC's own mechanism for this row. An input is recorded BEFORE it is queued (so the window in which a crash loses it is zero) and a `dequeue` record is written when the loop consumes it, so replay yields exactly the still-pending inputs; `session_journal::arm` re-queues those on the next open without re-recording them. cx-parity deliberately leaves the key unset: catalog scores this row `—` for Codex, and a cx-parity session must not gain an input-durability guarantee stock Codex does not have."
},
{
"id": "todos-plan-persisted-per-session",
"domain": 5,
"domain_name": "Session / state model",
"capability": "Todos/plan persisted per session",
"semantics": "Task list stored with the session",
"cc": "yes",
"cx": "variant",
"cc_detail": "✓ ~/.claude/tasks (shareable id)",
"cx_detail": "✓* plan in rollout via update_plan calls",
"catalog_supercode_today": "—",
"provenance": "cc§3; oc§5",
"status": "implemented",
"evidence": [
{
"kind": "tool",
"name": "update_plan"
},
{
"kind": "module",
"name": "todos"
},
{
"kind": "code",
"path": "crates/harness/src/configfile.rs",
"symbol": "config.todos_persist = cap"
},
{
"kind": "code",
"path": "crates/harness/src/tools/mod.rs",
"symbol": "pub plan: Arc<Mutex<Vec<crate::session_journal::PlanEntry>>>,"
},
{
"kind": "code",
"path": "crates/harness/src/session_journal.rs",
"symbol": "let _ = store.save_plan(name, &agent.plan());"
}
],
"note": "`[capabilities.todos] persist = true` (set by both presets) finally has a consumer. The checklist moved off `UpdatePlanTool`'s own mutex — where the agent could not read it — onto the shared `ToolContext`, so every `update_plan` call is journaled at the next loop boundary AND written to `<name>.plan.json` beside the transcript at every persist; `session_journal::arm` restores it on resume. Under cc-parity `update_plan` also joins the auto-approved read-only tier: CC never prompts before TodoWrite, and a plan the model cannot write is not a plan that can be persisted."
},
{
"id": "global-cross-project-state-dir",
"domain": 5,
"domain_name": "Session / state model",
"capability": "Global cross-project state dir",
"semantics": "One home dir owning config+auth+sessions",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ ~/.claude (+~/.claude.json)",
"cx_detail": "✓ $CODEX_HOME",
"catalog_supercode_today": "—",
"provenance": "cc§5; cx§6; oc§6; pi§6",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/cli/src/userconfig.rs",
"symbol": "pub fn config_home() -> PathBuf {"
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": ".unwrap_or_else(|| uc::config_home().join(\"sessions\"))"
}
],
"note": "One home directory owns the lot: `config_home()` (overridable by `SUPERCODE_HOME`) holds `config.toml`, `credentials.toml`, `mcp.json`, the MCP OAuth token store, the cross-session prompt history, and `sessions/` — which is where the session store roots itself unless `core.session.dir` overrides it."
},
{
"id": "entry-labels-bookmarks",
"domain": 5,
"domain_name": "Session / state model",
"capability": "Entry labels / bookmarks",
"semantics": "User-set persistent markers on transcript nodes",
"cc": "no",
"cx": "no",
"cc_detail": "—",
"cx_detail": "—",
"catalog_supercode_today": "—",
"provenance": "pi§3",
"status": "not_applicable",
"evidence": [],
"note": ""
},
{
"id": "stock-resumability-as-interop-contract",
"domain": 5,
"domain_name": "Session / state model",
"capability": "Stock-resumability as interop contract",
"semantics": "Foreign-written session resumes under the stock CLI",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ (supercode's acceptance test)",
"cx_detail": "✓ (verified)",
"catalog_supercode_today": "✓ (its export bar)",
"provenance": "cc§5; cx§5; oc§5; pi§10",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "session.to_jsonl(format)?"
},
{
"kind": "code",
"path": "crates/interchange/src/session/codex.rs",
"symbol": "self.write_synthesized_codex_header(&mut out);"
}
],
"note": "The export path writes each harness's native shape faithfully enough for the stock CLI to reopen it — for Codex that includes splicing a verbatim/synthesized `session_meta` + `turn_context` header ahead of the response items, because a rollout without its own header is not resumable by stock `codex`. This is the bar the design doc's §4.2 fidelity section already names as an existing acceptance instrument for both harnesses."
},
{
"id": "layered-config-w-precedence",
"domain": 6,
"domain_name": "Config surface",
"capability": "Layered config w/ precedence",
"semantics": "managed→user→project→local→CLI (order varies)",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ 5 scopes + drop-in managed dir",
"cx_detail": "✓ 8 layers (mdm→system→user→profile→project→flags)",
"catalog_supercode_today": "partial (ConfigFile profiles + defaults; CLI TOML separate, config.rs:348-357)",
"provenance": "cc§6; cx§6; oc§6; pi§6",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/harness/src/configfile.rs",
"symbol": "pub struct ConfigLayers"
},
{
"kind": "code",
"path": "crates/cli/src/userconfig.rs",
"symbol": "pub fn load_layered"
}
],
"note": "Nine layers with one documented precedence line (on `ConfigLayers`, the type every route goes through): built-in defaults < preset chain (`extends`, root-first) < user/global file < selected profile (`--profile`) < project file < project-local file (`.supercode.local.toml`) < `--settings` < `--config key=value` < individual flags. BP-9 added the profile, project-local and two per-run layers. Both UNTRUSTED file layers are sanitized and clamped INDIVIDUALLY, each against the accumulated result below it, so a project file that tightened the posture cannot be loosened back by the `.local` file above it — `.supercode.local.toml` is gitignored BY CONVENTION and a convention is not a trust boundary, so it buys precedence, never authority. (Fixing that surfaced a real defect: a process-wide `Once` meant only the first sanitized file reported its drops; the diagnostic is keyed per layer now.) The remaining managed/admin layer is its own catalog row, `managed-mdm-enterprise-config`, not residue here. BP-9."
},
{
"id": "managed-mdm-enterprise-config",
"domain": 6,
"domain_name": "Config surface",
"capability": "Managed / MDM enterprise config",
"semantics": "Admin-enforced settings the user can't override",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ (plist/registry/managed-settings.json)",
"cx_detail": "✓ (mdm + requirements.toml constraints)",
"catalog_supercode_today": "—",
"provenance": "cc§6; cx§6; oc§6",
"status": "absent",
"evidence": [],
"note": "`crate::configfile` resolves exactly two trusted layers (user/global + narrowing project); nothing reads a managed-settings file, plist/registry, or an MDM constraints document. A new trust layer, not a knob.",
"cost": "architectural"
},
{
"id": "named-profiles",
"domain": 6,
"domain_name": "Config surface",
"capability": "Named profiles",
"semantics": "Switchable named config bundles",
"cc": "no",
"cx": "yes",
"cc_detail": "—¹⁷",
"cx_detail": "✓ -p/--profile files + legacy [profiles]",
"catalog_supercode_today": "✓ ConfigProfile/ConfigFile + from_profile_file (config.rs:326-374)",
"provenance": "cx§6; config.rs",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/cli/src/userconfig.rs",
"symbol": "pub profiles: BTreeMap<String, Box<FileConfig>>"
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "profile: cli.profile.clone()"
}
],
"note": "`supercode -p/--profile <name>` selects a `[profiles.<name>]` bundle from the USER config and applies it as its own layer between the user layer and the project layer (cx§6's `user → profile → project` order). A bundle carries any subset of the config's own keys, including `[profiles.<name>.core]` and `[profiles.<name>.capabilities.*]`, and is TRUSTED (no sandbox/approval clamp — its author is the user), unlike the project layer. A project file may not define one: `[profiles]` is stripped by `sanitized_for_layer`, since a named bundle would otherwise smuggle unsanitized config in behind a name. An unknown `--profile` is a hard error listing the known names, never a silent resolve without the bundle. The SDK-side `ConfigFile`/`from_profile_file` JSON mechanism is unchanged. BP-9."
},
{
"id": "config-hot-reload",
"domain": 6,
"domain_name": "Config surface",
"capability": "Config hot reload",
"semantics": "Live-apply edits without restart",
"cc": "yes",
"cx": "no",
"cc_detail": "✓ (watched; ConfigChange hook veto)",
"cx_detail": "—",
"catalog_supercode_today": "—",
"provenance": "cc§6; pi§7",
"status": "absent",
"evidence": [],
"note": "`core.hot_reload` is parsed (`configfile.rs` key list) but its own docblock records the watch + live-reload subsystem as UNIMPLEMENTED; nothing watches the resolved file. cc-only row.",
"cost": "architectural"
},
{
"id": "published-json-schema-for-config",
"domain": 6,
"domain_name": "Config surface",
"capability": "Published JSON schema for config",
"semantics": "Editor validation via $schema",
"cc": "yes",
"cx": "no",
"cc_detail": "✓",
"cx_detail": "— (--strict-config errors instead)",
"catalog_supercode_today": "—",
"provenance": "cc§6; cx§6; oc§6",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/harness/src/config_schema.rs",
"symbol": "pub fn config_schema()"
},
{
"kind": "code",
"path": "docs/schema/supercode-config.schema.json",
"symbol": "\"$id\""
}
],
"note": "A JSON Schema (draft 2020-12, `additionalProperties: false`) is generated from the config's serde types and checked in at `docs/schema/supercode-config.schema.json`; `supercode config schema [--write]` prints/regenerates it, and the committed copy is asserted current by a test, so it cannot silently go stale. The schema is bound to the parser in BOTH directions: `schema_covers_exactly_the_parsed_keys` compares the field table against the keys serde itself emits for a default `HarnessConfig` (a new `CoreSection` field with no schema entry fails), and `every_schema_key_parses_with_its_declared_type` feeds every declared path back through the real parser AND `--strict-config` at its declared type (which is how BP-9 found `core.project_doc_max_bytes`/`core.doom_loop_threshold` parsing fine but being rejected by strict mode). `$schema` is an accepted top-level key in both TOML and JSON, so a file that points an editor at the schema still resolves. BP-9."
},
{
"id": "env-command-substitution-in-config-values",
"domain": 6,
"domain_name": "Config surface",
"capability": "Env/command substitution in config values",
"semantics": "${VAR}, {file:…}, !command in config/credentials",
"cc": "yes",
"cx": "variant",
"cc_detail": "✓ (.mcp.json ${VAR:-default})",
"cx_detail": "✓* (env_key indirection; auth command helpers)",
"catalog_supercode_today": "—",
"provenance": "cc§7; cx§9; oc§6; pi§6",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/harness/src/configfile.rs",
"symbol": "pub fn command_substitution_refusals"
},
{
"kind": "code",
"path": "crates/harness/src/configfile.rs",
"symbol": "FILE_REF_PREFIX"
}
],
"note": "Three substitution forms in the same `[core]` values `${VAR}` already covered (`base_url`, `system_prompt`, `append_system_prompt`, `additional_dirs`, `extra_headers`, string `extra_body` values): `${VAR}` (unset stays LITERAL, so a failed lookup is visible), `${VAR:-default}` (cc§7's `.mcp.json` form; the explicit default means this one never leaves a literal), and `{file:/path}` (oc§6's form, trailing newlines trimmed; unreadable stays literal). The credential-command indirection cx§6 spells `auth{command}` is `core.api_key_cmd` / `core.api_key_command`. DELIBERATE DIVERGENCE, not residue: pi's `!command` form is REFUSED — a config VALUE that executes a command turns every layer that can set it into arbitrary code execution — and `command_substitution_refusals` emits a resolve warning naming the refusal and the sanctioned door, so a reader coming from pi is never left thinking the command ran. Neither cc nor cx has `!command` in arbitrary values either. `{file:` joins `${` on `is_safe_project_dir`'s rejection list, so a project layer still cannot make the harness read an arbitrary file. BP-9."
},
{
"id": "inline-per-run-config-override",
"domain": 6,
"domain_name": "Config surface",
"capability": "Inline per-run config override",
"semantics": "`-c key=value` / inline JSON settings at launch",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ --settings JSON + /config key=value",
"cx_detail": "✓ -c key=value (TOML-parsed)",
"catalog_supercode_today": "—",
"provenance": "cc§6; cx§6",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/harness/src/configfile.rs",
"symbol": "pub fn resolve_with_layers"
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "config_override: Vec<String>"
}
],
"note": "`--config key=value` (repeatable, dotted TOML keys, TOML-typed values, bare word falls back to a string) and `--settings <inline-json|inline-toml|path>` resolve as the two highest FILE layers, above user/project/project-local and below the individual flags. Both go THROUGH the resolver (`ConfigLayers` / `resolve_with_layers`, and `userconfig::apply_run_layers` on the CLI route), so a project layer's §3.3 sanitization still ran underneath: a repo's `core.system_prompt` is dropped and warned about even when the same key is set inline. `--bare` keeps these (they are this command line's own) while still dropping both config FILES. Spelling note: cx uses `-c`; here `-c` is `--continue` (cc's spelling), so the short form is not offered — the capability, not the letter, is what this row grades. Proven end-to-end against the real binary (crates/cli/tests/config_surface_cli.rs) and over both resolved parity presets (configfile.rs `inline_overrides_reach_the_resolved_parity_presets`). BP-9."
},
{
"id": "feature-flag-system",
"domain": 6,
"domain_name": "Config surface",
"capability": "Feature-flag system",
"semantics": "Staged experimental gates",
"cc": "variant",
"cx": "yes",
"cc_detail": "✓* (~40 CLAUDE_CODE_DISABLE_*/enable envs)",
"cx_detail": "✓ [features] staged table + features CLI + /experimental",
"catalog_supercode_today": "—",
"provenance": "cc§6; cx§6; oc§6; pi§6",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/harness/src/configfile.rs",
"symbol": "pub const EXPERIMENTAL_FLAGS"
},
{
"kind": "code",
"path": "crates/cli/src/slash.rs",
"symbol": "SlashCmd::Experimental"
}
],
"note": "`[experimental]` is a STAGED registry now, not a bag of booleans: every flag declares a stage (`experimental` = off unless opted in, `beta` = off but settled, `default` = on, surviving only as the opt-OUT escape hatch) and the stage decides the default, so `experimental_opt_in` no longer hard-codes one. `supercode features list [--json]` and the REPL's `/experimental` (aliased `/features`) both render from that one registry, with each flag's stage, default, resolved value and whether the config set it explicitly. A key with no gate in this build is reported as an unknown flag rather than looking honored. The registry holds one flag today (`module_registry`, stage `default`) — the MECHANISM is what this row grades, and the population is whatever is currently staged, exactly as for cx's `[features]` table. BP-9."
},
{
"id": "deterministic-clean-startup-mode",
"domain": 6,
"domain_name": "Config surface",
"capability": "Deterministic/clean startup mode",
"semantics": "Skip all discovered customization for CI/debug",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ --bare / --safe-mode / --setting-sources",
"cx_detail": "✓ --strict-config / --ignore-user-config",
"catalog_supercode_today": "—",
"provenance": "cc§2,§6; cx§6; oc§6; pi§6",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "cli.bare"
}
],
"note": ""
},
{
"id": "auto-update-channels",
"domain": 6,
"domain_name": "Config surface",
"capability": "Auto-update + channels",
"semantics": "Self-update with stable/latest channels",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓",
"cx_detail": "✓ codex update + startup check",
"catalog_supercode_today": "—",
"provenance": "cc§6; cx§10; oc§8; pi§6",
"status": "partial",
"evidence": [
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "fn update_check_url"
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "fn startup_update_check"
}
],
"note": "`supercode update --channel stable|latest` selects the release stream (`stable` = GitHub's latest-release endpoint, which excludes pre-releases; `latest` = the releases list, whose first entry is the newest publication of any kind), `--install` runs the detected install method's upgrade command (Homebrew / cargo / from-source), and `core.update_check = true` adds an opt-in startup check — skipped under `--bare`, `--quiet`, non-terminal stderr and the `update` command itself, so no invocation reaches the network unless someone asked for it. RESIDUE: the install-script / release-tarball channel has no self-upgrade path — `--install` refuses there with the download URL rather than downloading and replacing the running binary, which needs signature/checksum verification and an atomic swap (M-sized, security-bearing) rather than the S-sized command dispatch the other three channels take. That is the most common way a user gets the binary, so this row stays PARTIAL. BP-9."
},
{
"id": "credential-helpers-keyring",
"domain": 6,
"domain_name": "Config surface",
"capability": "Credential helpers / keyring",
"semantics": "Scripted or OS-keyring credential sourcing",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ apiKeyHelper (+cloud auth refresh)",
"cx_detail": "✓ auth{command} + keyring stores",
"catalog_supercode_today": "partial (api_key/api_key_env only, config.rs:125-129)",
"provenance": "cc§6; cx§6; oc§9; pi§6",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "pub(crate) fn run_api_key_command"
},
{
"kind": "code",
"path": "crates/cli/src/userconfig.rs",
"symbol": "pub fn keyring_get"
}
],
"note": "Both halves of the row's semantics. SCRIPTED: `core.api_key_command` is an ARGV helper exec'd directly (no shell, so a path with spaces or an argument containing `$`/`;` means what it says) whose trimmed stdout is the key — cc's `apiKeyHelper` / cx's `auth{command}` shape — consulted by `Agent::new` before the pre-existing shell-string `core.api_key_cmd`, with the same fall-through-on-failure posture. OS KEYRING: `[credentials] store = \"keyring\"` routes `login`'s write and `resolve_api_key`'s read through the platform's own tool (macOS `security`, Linux `secret-tool`), with the file store (`credentials.toml`, 0600) staying the default and `doctor` naming which store answered. No new crate dependency. Both keys are `[project-forbidden]`: a repo may neither choose the program whose stdout becomes your API key nor redirect where credentials are read. Platform note: Windows has no keyring path and says so explicitly rather than writing nowhere. BP-9."
},
{
"id": "config-reproducibility-lockfile",
"domain": 6,
"domain_name": "Config surface",
"capability": "Config reproducibility lockfile",
"semantics": "Resolved-config snapshot pinned to a version",
"cc": "no",
"cx": "yes",
"cc_detail": "—",
"cx_detail": "✓ [debug.config_lockfile]",
"catalog_supercode_today": "—",
"provenance": "cx§6",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/harness/src/configfile.rs",
"symbol": "pub struct ConfigLock"
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "ConfigAction::Lock"
}
],
"note": "`supercode config lock` writes `.supercode.lock` at the marker-defined project root: the fully-folded `HarnessConfig` (every layer merged, sanitized and clamped), the resolved `extends` chain root-first, and the supercode version whose resolver produced it. `supercode config check --lock [--json]` re-resolves and reports drift per dotted key (`core.max_tokens: locked 100 != resolved 200`) plus version and preset-chain drift, exiting non-zero when anything differs — a resolver change that silently alters what the same config text MEANS is drift too, which is the point of pinning the version. BP-9."
},
{
"id": "white-label-rebranding",
"domain": 6,
"domain_name": "Config surface",
"capability": "White-label rebranding",
"semantics": "Rename app + config dir for distributions",
"cc": "no",
"cx": "no",
"cc_detail": "—",
"cx_detail": "—",
"catalog_supercode_today": "—",
"provenance": "pi§6",
"status": "not_applicable",
"evidence": [],
"note": ""
},
{
"id": "env-var-config-surface",
"domain": 6,
"domain_name": "Config surface",
"capability": "Env-var config surface",
"semantics": "Behavior toggles via environment",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ (~290 documented)",
"cx_detail": "✓ (~30)",
"catalog_supercode_today": "✓* (SUPERCODE_CACHE_WARNINGS, DEFAULT_API_KEY_ENV, config.rs:10, 236-238)",
"provenance": "cc§6; cx§6; oc§6; pi§6",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/harness/src/config.rs",
"symbol": "SUPERCODE_CACHE_WARNINGS"
}
],
"note": ""
},
{
"id": "project-root-detection-markers",
"domain": 6,
"domain_name": "Config surface",
"capability": "Project-root detection markers",
"semantics": "Configurable markers defining the project root",
"cc": "variant",
"cx": "yes",
"cc_detail": "✓* (git-keyed memory/projects)",
"cx_detail": "✓ project_root_markers (default .git)",
"catalog_supercode_today": "—",
"provenance": "cx§6; oc§6",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/harness/src/config.rs",
"symbol": "pub fn project_root_for"
},
{
"kind": "code",
"path": "crates/cli/src/userconfig.rs",
"symbol": "fn find_upward"
}
],
"note": "`core.project_root_markers` (default `[\".git\"]`) has its reader: `config::project_root_for(cwd, markers)` is the one shared ancestor walk — nearest ancestor containing any marker, file or directory (a git worktree writes `.git` as a FILE), empty list = no detection. Two consumers read it today: the `core.env_context` git probe now reports the ROOT's branch instead of whatever subdirectory the process sat in, and the CLI's `.supercode.toml` / `.supercode.local.toml` discovery walk stops at the root instead of climbing to `/` (so an unrelated repo's config above the root can no longer leak in). Changing the markers demonstrably moves both, proven through the real binary (`project_root_markers_bound_the_config_discovery_walk`). Prompt assembly's instruction walk consumes the same helper (BP-4). BP-9."
},
{
"id": "mcp-client-stdio-transport",
"domain": 7,
"domain_name": "MCP / extension model",
"capability": "MCP client, stdio transport",
"semantics": "Spawn local MCP servers as tool sources",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓",
"cx_detail": "✓ (env allowlists, remote executor)",
"catalog_supercode_today": "✓ (McpTool::from_client wraps remote tools — config.rs:62-64)",
"provenance": "cc§7; cx§7; oc§7; pi§7",
"status": "implemented",
"evidence": [
{
"kind": "module",
"name": "mcp"
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "McpClient::connect(command, &args, &env).await"
}
],
"note": "`attach_mcp` spawns every stdio server from the mcp.json registry, --mcp-config files, and (module-on) [capabilities.mcp.servers.*], registering each tool as mcp__<server>__<tool>."
},
{
"id": "mcp-client-remote-http-sse-ws",
"domain": 7,
"domain_name": "MCP / extension model",
"capability": "MCP client, remote HTTP(+SSE/WS)",
"semantics": "Connect to hosted MCP servers",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ (http/sse/ws)",
"cx_detail": "✓ (streamable HTTP)",
"catalog_supercode_today": "partial (surveyed core references MCP client; transports unverified here)",
"provenance": "cc§7; cx§7; oc§7",
"status": "partial",
"evidence": [
{
"kind": "module",
"name": "mcp"
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "config.module_activation.is_active(ModuleId::McpClient)"
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "McpClient::connect_http(&url, &headers, network_policy.as_ref()).await"
}
],
"note": "McpClient implements Streamable HTTP (with Mcp-Session-Id replay) and the legacy HTTP+SSE transport, both honoring the NetworkPolicy, both exercised against real servers in crates/harness/tests/mcp_remote.rs. Reachable under both parity presets since BP-1: mcp_module_on is the mcp module's own activation bit, so attach_mcp no longer refuses an http/sse entry. The REMAINING gap is WebSocket — no ws transport at all, which CC additionally offers, so a ws-only hosted server is unreachable."
},
{
"id": "mcp-oauth",
"domain": 7,
"domain_name": "MCP / extension model",
"capability": "MCP OAuth",
"semantics": "Browser/device auth to remote servers, token storage",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓",
"cx_detail": "✓ (file/keyring)",
"catalog_supercode_today": "—",
"provenance": "cc§7; cx§7; oc§7",
"status": "partial",
"evidence": [
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "mcp_oauth::run_device_flow(&client, &endpoints, |auth| {"
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "uc::save_mcp_oauth_tokens(name, &refreshed)"
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "config.module_activation.is_active(ModuleId::McpClient)"
}
],
"note": "`supercode mcp login <name>` runs the RFC 8628 device-code grant and stores tokens 0600 in mcp_oauth.json; resolve_oauth_header refreshes an expired token and attaches the bearer header, and that http/sse branch is reachable under both parity presets since BP-1 (mcp_module_on is the mcp module's own activation bit). The REMAINING gap is the BROWSER half of this row's semantics: mcp_oauth.rs implements only the device grant, not the interactive authorization-code + PKCE + local-redirect flow, so a hosted server offering only that flow is unauthenticable."
},
{
"id": "mcp-resources-templates",
"domain": 7,
"domain_name": "MCP / extension model",
"capability": "MCP resources & templates",
"semantics": "List/read server resources into context",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ (+@server:uri mentions)",
"cx_detail": "✓",
"catalog_supercode_today": "—",
"provenance": "cc§7; cx§1; oc§7",
"status": "implemented",
"evidence": [
{
"kind": "module",
"name": "mcp"
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "config.module_activation.is_active(ModuleId::McpClient)"
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "for t in handle.resource_tools() {"
}
],
"note": "McpServerHandle::resource_tools builds per-server resources_list (resources AND resource templates), resources_read and resources_subscribe tools, and attach_mcp registers them. Live under both parity presets since BP-1: mcp_module_on is the mcp module's own activation bit, with no [experimental] flag on top. CC's `@server:uri` mention syntax has no equivalent — that is an input affordance, not part of this row's list/read-into-context semantics, and is graded on its own catalog rows."
},
{
"id": "mcp-prompts-as-commands",
"domain": 7,
"domain_name": "MCP / extension model",
"capability": "MCP prompts as commands",
"semantics": "Server prompts exposed as slash commands",
"cc": "yes",
"cx": "no",
"cc_detail": "✓ /mcp__server__prompt",
"cx_detail": "—",
"catalog_supercode_today": "—",
"provenance": "cc§7; oc§7",
"status": "implemented",
"evidence": [
{
"kind": "module",
"name": "mcp"
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "config.module_activation.is_active(ModuleId::McpClient)"
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "agent.register_mcp_prompt(command_name, source);"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "let expanded = self.expand_prompt_async(&user_input.into()).await;"
}
],
"note": "attach_mcp registers each server prompt as mcp__<server>__<prompt> and Agent::send expands the typed slash form through expand_prompt_async with a real prompts/get round trip. Live under cc-parity since BP-1: register_mcp_prompt sits past `if !module_on { continue; }`, and mcp_module_on is now the mcp module's own activation bit. Command COMPLETION is separate: server.rs builds the frontend catalog from config.prompts only, so an MCP prompt has no help entry — discovery, not exposure, and graded on the command-catalog rows."
},
{
"id": "mcp-server-instructions-honored",
"domain": 7,
"domain_name": "MCP / extension model",
"capability": "MCP server `instructions` honored",
"semantics": "Server guidance injected into system prompt",
"cc": "no",
"cx": "yes",
"cc_detail": "—",
"cx_detail": "✓ (first 512 chars prioritized)",
"catalog_supercode_today": "—",
"provenance": "cx§7; oc§2",
"status": "implemented",
"evidence": [
{
"kind": "module",
"name": "mcp"
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "config.module_activation.is_active(ModuleId::McpClient)"
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "# MCP: {name} instructions"
}
],
"note": "attach_mcp appends each server's initialize-time instructions to the system prompt via append_system_note (in full, rather than CX's first-512-chars prioritization — a superset, not a shortfall). Live under cx-parity since BP-1: the call is past `if !module_on { continue; }` and mcp_module_on is now the mcp module's own activation bit, with no [experimental] flag on top."
},
{
"id": "mcp-elicitation",
"domain": 7,
"domain_name": "MCP / extension model",
"capability": "MCP elicitation",
"semantics": "Server requests structured user input mid-call",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ (+hooks auto-answer)",
"cx_detail": "✓ (Form/Url + OAuth elicitations)",
"catalog_supercode_today": "—",
"provenance": "cc§7; cx§7",
"status": "implemented",
"evidence": [
{
"kind": "module",
"name": "mcp"
},
{
"kind": "module",
"name": "tui"
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "attach_mcp_with_elicitation(&cli, &mut agent, elicitation).await;"
},
{
"kind": "code",
"path": "crates/harness/src/tui/handlers.rs",
"symbol": "impl McpElicitationHandler for TuiElicitationHandler"
}
],
"note": "Server-initiated elicitation/create is dispatched on the stdio and SSE read loops to the installed handler; the interactive handler is installed when the TUI activates, and HeadlessElicitationHandler declines (fail-closed) otherwise. Only the generic accept/decline/cancel form shape is modeled — no CC hook auto-answer and no CX Url/OAuth elicitation subtypes."
},
{
"id": "per-mcp-tool-approval-modes",
"domain": 7,
"domain_name": "MCP / extension model",
"capability": "Per-MCP-tool approval modes",
"semantics": "auto/prompt/writes/approve per server/tool",
"cc": "variant",
"cx": "yes",
"cc_detail": "✓* (mcp__ rules + requiresUserInteraction meta)",
"cx_detail": "✓ default_tools_approval_mode + per-tool",
"catalog_supercode_today": "—",
"provenance": "cc§4; cx§7; oc§4",
"status": "partial",
"evidence": [
{
"kind": "module",
"name": "permissions"
},
{
"kind": "config",
"key": "capabilities.permissions.rules.allow"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "rules.evaluate(name, None).unwrap_or(default)"
}
],
"note": "Per-server/per-tool auto vs prompt vs deny is expressible: the permissions rule engine glob-matches any tool name, including mcp__<server>__<tool> (config.rs glob_match handles `mcp__*__search`), and the decision routes through the approval cache/handler. Missing: no MCP tool-annotation handling at all (CC's requiresUserInteraction meta is never read — mcp.rs parses no annotations), and no per-server default_tools_approval_mode knob under [capabilities.mcp]; the only surface is hand-written rule globs."
},
{
"id": "deferred-mcp-tools",
"domain": 7,
"domain_name": "MCP / extension model",
"capability": "Deferred MCP tools",
"semantics": "Server tools reachable only via tool_search",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ (default)",
"cx_detail": "✓ (deferred_mcp_tools)",
"catalog_supercode_today": "✓ (Deferred advertising targets MCP surface, config.rs:60-64)",
"provenance": "cc§7; cx§7",
"status": "implemented",
"evidence": [
{
"kind": "module",
"name": "deferred_tools"
},
{
"kind": "config",
"key": "capabilities.deferred_tools.core"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "ToolAdvertising::Deferred { core } => core.iter().any(|c| c == name)"
}
],
"note": "Both parity presets set a core allowlist of builtins only, so every registered mcp__* tool is withheld from the advertised schema set until the synthetic tool_search intrinsic activates it."
},
{
"id": "harness-as-mcp-server",
"domain": 7,
"domain_name": "MCP / extension model",
"capability": "Harness AS MCP server",
"semantics": "Expose own tools over MCP to other clients",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ claude mcp serve",
"cx_detail": "✓ codex mcp-server (+approval reverse-RPCs)",
"catalog_supercode_today": "—",
"provenance": "cc§7; cx§7",
"status": "implemented",
"evidence": [
{
"kind": "module",
"name": "mcp"
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "supercode::mcp::serve_stdio(®istry, &ctx).await?;"
}
],
"note": "`supercode mcp serve` answers initialize/tools/list/tools/call over stdio JSON-RPC against the real ToolRegistry under a workspace-write sandbox by default. Tools only — no resources/prompts and no approval reverse-RPCs (CX's variant)."
},
{
"id": "full-programmatic-server-rpc-api",
"domain": 7,
"domain_name": "MCP / extension model",
"capability": "Full programmatic server/RPC API",
"semantics": "JSON-RPC/HTTP/stdio API for embedding clients",
"cc": "variant",
"cx": "yes",
"cc_detail": "✓* Agent SDK + stream-json stdio",
"cx_detail": "✓ app-server (threads/turns/fs/exec/config, ~80 notifs)",
"catalog_supercode_today": "—",
"provenance": "cc§8; cx§7; oc§7; pi§8",
"status": "partial",
"evidence": [
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "config.event_sink = Some(with_trace(stream_json_sink(), cli.trace));"
},
{
"kind": "code",
"path": "crates/harness/src/server.rs",
"symbol": "pub async fn run_stdio"
}
],
"note": "The in-process SDK (EventSink) and `--output-format stream-json` NDJSON feed are always available, and a JSONL-RPC-over-stdio + HTTP /rpc + /events surface exists in server.rs — but [capabilities.server] is disabled in BOTH parity presets, so neither preset actually serves it, and nothing reproduces CX's app-server contract (threads/turns/fs/exec/config methods, ~80 notification types). Design doc §4.3 calls app-server parity out of preset scope rather than irreducible."
},
{
"id": "lifecycle-hooks-config-registered",
"domain": 7,
"domain_name": "MCP / extension model",
"capability": "Lifecycle hooks, config-registered",
"semantics": "Declarative event handlers around the loop",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ 30 events, 5 handler types",
"cx_detail": "✓ 10 events (CC-compatible shape), command-only",
"catalog_supercode_today": "partial (pre_tool_hook/post_tool_hook only, config.rs:48-55)",
"provenance": "cc§7; cx§7",
"status": "partial",
"evidence": [
{
"kind": "module",
"name": "hooks"
},
{
"kind": "code",
"path": "crates/cli/src/hooks.rs",
"symbol": "pub fn fire_notification"
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "hooks::fire_pre_tool(&hs, &extra, quiet)"
}
],
"note": "All 11 config-registerable events now have a live emission site: BP-11 fires `pre_compact`/`post_compact` from the one compaction path (`Agent::compact_in_place`, automatic and `/compact`, trigger named) and `subagent_start`/`subagent_stop` around a validated `spawn_subagent` call, through `Config::lifecycle_hook` (observational) that `main.rs` installs when any of the four is configured. REMAINING residue: only the `command` handler type exists (CC has 5: command/http/mcp_tool/prompt/agent) and 11 of CC's 30 events, matching the design §4.2 'Hook surface breadth' gap row."
},
{
"id": "in-process-extension-plugin-api",
"domain": 7,
"domain_name": "MCP / extension model",
"capability": "In-process extension/plugin API",
"semantics": "Code modules hooking the loop, tools, UI, providers",
"cc": "no",
"cx": "variant",
"cc_detail": "—",
"cx_detail": "✓* dynamic/extension tools (host apps)",
"catalog_supercode_today": "partial (Rust embedder: hooks, Tool trait, EventSink, config.rs:211-212)",
"provenance": "cx§1; oc§7; pi§7",
"status": "partial",
"evidence": [
{
"kind": "code",
"path": "crates/harness/src/sdk.rs",
"symbol": "pub fn register_tool(&mut self, tool: impl crate::Tool + 'static) {"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "if let Some(hook) = &self.config.pre_tool_hook {"
}
],
"note": "A Rust embedder can register tools (Agent/SdkAgent::register_tool), install pre_tool_hook/post_tool_hook/stop_gate/approval_handler closures, and observe the loop through EventSink. Missing: no dynamically loaded in-process extension (a plugin is an out-of-process manifest-declared subprocess by design — plugins.rs's ABI decision), no UI-surface hooks, and no provider injection."
},
{
"id": "hook-extension-trust-gating",
"domain": 7,
"domain_name": "MCP / extension model",
"capability": "Hook/extension trust gating",
"semantics": "Untrusted hook code quarantined until reviewed",
"cc": "no",
"cx": "yes",
"cc_detail": "—",
"cx_detail": "✓ trusted_hash + re-quarantine on change",
"catalog_supercode_today": "—",
"provenance": "cx§7; pi§4",
"status": "partial",
"evidence": [
{
"kind": "module",
"name": "trust"
},
{
"kind": "code",
"path": "crates/cli/src/userconfig.rs",
"symbol": "if self.hooks != crate::hooks::HooksFileConfig::default() {"
}
],
"note": "Untrusted (project-layer) hook code never runs: sanitized_for_project drops [hooks] and the whole [capabilities.hooks] table from a project .supercode.toml, so a hook command can only come from the user's own config or SUPERCODE_HOOK_* env. Missing the review half of the semantics — there is no trusted-hash record, no quarantine list, and no path by which a reviewed project hook can ever be approved and re-quarantined on change."
},
{
"id": "plugin-packaging-marketplaces",
"domain": 7,
"domain_name": "MCP / extension model",
"capability": "Plugin packaging + marketplaces",
"semantics": "Installable bundles (skills/agents/hooks/MCP/themes)",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ plugins + git marketplaces",
"cx_detail": "✓ plugins + marketplaces (git/local/npm)",
"catalog_supercode_today": "—",
"provenance": "cc§7; cx§7; oc§7; pi§7",
"status": "partial",
"evidence": [
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "crate::plugins::register_into(&config, &mut registry);"
}
],
"note": "A plugin is a trust-gated directory with a plugin.toml manifest whose [[tools]] register as plugin__<plugin>__<tool>. Missing: [capabilities.plugins] is off in BOTH parity presets (unset), there is no marketplace/registry client and no install command of any kind (plugins.rs states 'No marketplace / package installation'), manifest [[hooks]] are parsed but never emitted, and a bundle cannot contribute skills, agents, MCP servers, or themes."
},
{
"id": "custom-tools-from-project-files",
"domain": 7,
"domain_name": "MCP / extension model",
"capability": "Custom tools from project files",
"semantics": "Drop-in tool files auto-discovered",
"cc": "no",
"cx": "no",
"cc_detail": "—",
"cx_detail": "—",
"catalog_supercode_today": "—",
"provenance": "oc§1; pi§7",
"status": "not_applicable",
"evidence": [],
"note": ""
},
{
"id": "provider-injection-via-extension",
"domain": 7,
"domain_name": "MCP / extension model",
"capability": "Provider injection via extension",
"semantics": "Plugins add/patch model providers + auth flows",
"cc": "no",
"cx": "no",
"cc_detail": "—",
"cx_detail": "—",
"catalog_supercode_today": "—",
"provenance": "oc§7; pi§7",
"status": "not_applicable",
"evidence": [],
"note": ""
},
{
"id": "extension-ui-toolkit",
"domain": 7,
"domain_name": "MCP / extension model",
"capability": "Extension UI toolkit",
"semantics": "Dialogs/widgets/editors/overlays from extensions",
"cc": "no",
"cx": "no",
"cc_detail": "—",
"cx_detail": "—",
"catalog_supercode_today": "—",
"provenance": "oc§7; pi§7",
"status": "not_applicable",
"evidence": [],
"note": ""
},
{
"id": "external-notify-program-channels",
"domain": 7,
"domain_name": "MCP / extension model",
"capability": "External notify program / channels",
"semantics": "Push events out (argv program) or into (channels) a session",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ Notification hooks + channels (inbound!)",
"cx_detail": "✓ notify argv (turn-complete)",
"catalog_supercode_today": "—",
"provenance": "cc§7; cx§8; oc§8",
"status": "partial",
"evidence": [
{
"kind": "code",
"path": "crates/cli/src/notify.rs",
"symbol": "crate::hooks::fire_notification("
},
{
"kind": "code",
"path": "crates/cli/src/hooks.rs",
"symbol": "SUPERCODE_HOOK_NOTIFICATION_KIND"
}
],
"note": "The outbound argv half exists: the `notification` hook command fires at turn finish with kind/model/elapsed/summary passed as environment variables, alongside built-in desktop/bell/email notification. Missing the inbound half entirely — there is no channel by which an external process can push an event or a message INTO a running session (CC's channels)."
},
{
"id": "first-run-import-from-other-harnesses",
"domain": 7,
"domain_name": "MCP / extension model",
"capability": "First-run import from other harnesses",
"semantics": "Migrate config/skills/history from a rival CLI",
"cc": "no",
"cx": "yes",
"cc_detail": "—",
"cx_detail": "✓ /import (Claude Code setup+chats)",
"catalog_supercode_today": "✓* (UX-27 MCP-config import; interop loaders)",
"provenance": "cx§7; oc§7; pi§7",
"status": "partial",
"evidence": [
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "maybe_first_run_mcp_import(cli);"
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "McpAction::Import { from, dry_run } => mcp_import_cmd(*from, *dry_run),"
}
],
"note": "Config migration covers MCP servers only: a first-run interactive offer plus `supercode mcp import` read ~/.claude.json, ~/.claude/mcp.json, ~/.mcp.json and ~/.codex/config.toml, never overwriting an existing entry; rival session HISTORY needs no migration because the loaders read it natively. Missing: no skills import (there is no skill-file subsystem at all) and no other settings/config migration."
},
{
"id": "skill-discovery-from-multiple-roots",
"domain": 7,
"domain_name": "MCP / extension model",
"capability": "Skill discovery from multiple roots",
"semantics": "User/project/admin/plugin skill paths merged",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ (enterprise>user>project + plugins)",
"cx_detail": "✓ (repo/.agents, user, admin, system, plugins)",
"catalog_supercode_today": "—",
"provenance": "cc§7; cx§7; oc§7; pi§2",
"status": "implemented",
"evidence": [
{
"kind": "config",
"key": "core.skills.harness"
},
{
"kind": "code",
"path": "crates/harness/src/skills.rs",
"symbol": "pub fn load_loop_skills("
},
{
"kind": "code",
"path": "crates/harness/src/skills.rs",
"symbol": "pub fn skill_roots(harness: &str, homes: &SkillHomes, cwd: &Path) -> Vec<(SkillScope, PathBuf)> {"
},
{
"kind": "code",
"path": "crates/harness/src/skills.rs",
"symbol": "fn nested_claude_roots(cwd: &Path) -> Vec<(String, PathBuf)> {"
}
],
"note": "BP-6: `skills::load_loop_skills` merges every root the named harness's own loader consults, in that harness's documented precedence, de-duplicated by invocation name (first root wins, the collision rule all of these harnesses state) and by directory (one folder reachable through two roots is one skill). `[core.skills] harness` names whose table to read. `cc-parity` reads Claude Code's: enterprise/managed, `~/.claude/skills`, installed plugin bundles namespaced `plugin:skill`, project `.claude/skills` from cwd to the enclosing repo, plus nested `<subdir>/.claude/skills` packages qualified `dir:skill` (bounded to depth 3 / 400 directories so a large tree cannot make agent construction expensive). `cx-parity` reads Codex's: `/etc/codex/skills`, the bundled `$CODEX_HOME/skills/.system` cache, `~/.agents/skills`, `$CODEX_HOME/skills`, and repo `.agents/skills` from cwd to the repo root. `[core.skills] dirs` adds roots ahead of every discovered one. The tests build the whole estate in temp directories reached through each harness's own relocation contract (`CLAUDE_CONFIG_DIR`, `CODEX_HOME`, `HOME`) and assert both the merge and the collision winner under each preset."
},
{
"id": "non-interactive-print-mode",
"domain": 8,
"domain_name": "Output / streaming / UX",
"capability": "Non-interactive print mode",
"semantics": "One-shot prompt → response, scriptable",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ -p",
"cx_detail": "✓ codex exec",
"catalog_supercode_today": "— (core is a library; CLI outside surveyed files)",
"provenance": "cc§8; cx§8; oc§8; pi§8",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "let prompt = read_prompt(prompt.clone())?;"
}
],
"note": "`supercode run <prompt>` is a one-shot turn that prints the reply to stdout, with --output-format text|json|stream-json|rpc and --output-schema; session_start/session_end hooks bracket it."
},
{
"id": "json-jsonl-event-stream-output",
"domain": 8,
"domain_name": "Output / streaming / UX",
"capability": "JSON/JSONL event-stream output",
"semantics": "Machine-readable live event feed",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ stream-json (+partial messages, hook events)",
"cx_detail": "✓ --json item/turn events",
"catalog_supercode_today": "partial (EventSink stream, config.rs:211-212)",
"provenance": "cc§8; cx§8; oc§8; pi§8",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "config.event_sink = Some(with_trace(stream_json_sink(), cli.trace));"
}
],
"note": "`--output-format stream-json` emits one AgentEvent JSON object per line on a stdout kept free of any other bytes (AgentEvent::to_json is the single projection the RPC notification path also uses); `--output-format json` gives the single-object form. No partial-message deltas and no hook events in the stream, which CC's stream-json carries."
},
{
"id": "stdin-prompt-piping",
"domain": 8,
"domain_name": "Output / streaming / UX",
"capability": "stdin prompt piping",
"semantics": "Compose prompts from piped input",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓",
"cx_detail": "✓ exec -",
"catalog_supercode_today": "—",
"provenance": "cc§8; cx§8; pi§8",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "read_prompt_from(prompt, io::stdin())"
}
],
"note": "An omitted prompt argument, or an explicit `-`, reads and trims the prompt from stdin."
},
{
"id": "interactive-tui",
"domain": 8,
"domain_name": "Output / streaming / UX",
"capability": "Interactive TUI",
"semantics": "Full-screen terminal client",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ (classic + fullscreen renderers)",
"cx_detail": "✓",
"catalog_supercode_today": "—",
"provenance": "all §8",
"status": "implemented",
"evidence": [
{
"kind": "module",
"name": "tui"
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "supercode_frontend_tui::app::run(runtime.clone())"
},
{
"kind": "code",
"path": "crates/frontend-tui/src/app.rs",
"symbol": "async fn run_attached("
}
],
"note": "A ratatui/crossterm alternate-screen client (transcript + composer, bracketed paste, overlays for approvals/elicitations, interrupt, detach) drives any SDK runtime. Activated by capabilities.tui.enabled plus all three streams being a tty; otherwise the line-mode rustyline REPL runs."
},
{
"id": "slash-command-system",
"domain": 8,
"domain_name": "Output / streaming / UX",
"capability": "Slash-command system",
"semantics": "/commands incl. user-defined",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ (~100 built-in)",
"cx_detail": "✓ (~50)",
"catalog_supercode_today": "✓* (`/name` prompt expansion, config.rs:193-194)",
"provenance": "all §8",
"status": "partial",
"evidence": [
{
"kind": "code",
"path": "crates/harness/src/server.rs",
"symbol": "id: format!(\"prompt:{name}\"),"
},
{
"kind": "code",
"path": "crates/frontend-model/src/capabilities.rs",
"symbol": "pub fn invocation_for_command"
}
],
"note": "User-defined commands work: every [core.prompts] key is advertised as a typed frontend Prompt operation and `/name args` in the composer resolves to it (and Agent::send expands the template). Missing the built-in command set — the full-screen frontend ships ZERO built-in slash commands, and the 10-entry table in crates/cli/src/slash.rs (SLASH_COMMANDS: /help /model /tokens /add /save /clear /undo /expand /reduce /exit) belongs to the legacy line-mode REPL, which both parity presets bypass by enabling the TUI. CC has ~100 built-ins, CX ~50."
},
{
"id": "shell-escape-from-composer",
"domain": 8,
"domain_name": "Output / streaming / UX",
"capability": "Shell escape from composer",
"semantics": "`!cmd` runs locally, result into context",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ (+auto-respond option)",
"cx_detail": "✓ (under current sandbox)",
"catalog_supercode_today": "—",
"provenance": "cc§8; cx§8; oc§3; pi§4",
"status": "partial",
"evidence": [
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "run_shell_escape(shell_cmd).await;"
}
],
"note": "`!cmd` exists only in the legacy line-mode REPL (the full-screen composer both parity presets select has no shell escape), and even there the result is NOT put into context — the REPL prints 'output only, nothing sent to the model', which is the half of the row's semantics that matters."
},
{
"id": "rebindable-keybindings",
"domain": 8,
"domain_name": "Output / streaming / UX",
"capability": "Rebindable keybindings",
"semantics": "User keymap file/chords",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ keybindings.json",
"cx_detail": "✓ /keymap",
"catalog_supercode_today": "—",
"provenance": "all §8",
"status": "absent",
"evidence": [],
"note": "The live composer's keys are hardcoded in crates/frontend-model/src/composer.rs. A Keymap view-model with 8 rebindable actions and a `capabilities.tui.keymap.<name>` parse path exists in crates/harness/src/tui/keymap.rs, and Config::tui_keymap is populated from config — but nothing reads it: Keymap::with_overrides has no caller outside its own module's tests. No chords/multi-key sequences either.",
"cost": "trivial"
},
{
"id": "vim-editing-mode",
"domain": 8,
"domain_name": "Output / streaming / UX",
"capability": "Vim editing mode",
"semantics": "Modal editor emulation in the composer",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ (full NORMAL/INSERT/VISUAL)",
"cx_detail": "✓ /vim",
"catalog_supercode_today": "—",
"provenance": "cc§8; cx§8; pi§7",
"status": "absent",
"evidence": [],
"note": "No modal editing in the live composer. crates/harness/src/tui/state.rs carries a VimMode/VimSetMode view-model, but TuiState has no consumer anywhere outside its own module (the frontend is crates/frontend-tui, which never references it).",
"cost": "trivial"
},
{
"id": "themes",
"domain": 8,
"domain_name": "Output / streaming / UX",
"capability": "Themes",
"semantics": "Color themes, custom + shipped",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ (+plugin themes, daltonized)",
"cx_detail": "✓ /theme (+/pets)",
"catalog_supercode_today": "—",
"provenance": "all §7/§8",
"status": "absent",
"evidence": [],
"note": "The live frontend only detects terminal color capability (ColorCapabilities::resolve, NO_COLOR/COLORTERM) — it has no theme concept. The Dark/Light Theme enum and capabilities.tui.theme parse in crates/harness/src/tui/theme.rs have no consumer. No custom/shipped theme files of any kind.",
"cost": "trivial"
},
{
"id": "custom-status-line-footer",
"domain": 8,
"domain_name": "Output / streaming / UX",
"capability": "Custom status line / footer",
"semantics": "User-scripted status surface",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ statusLine command (rich JSON stdin)",
"cx_detail": "✓ /statusline + [tui].status_line",
"catalog_supercode_today": "—",
"provenance": "cc§8; cx§8; oc§8; pi§7",
"status": "absent",
"evidence": [],
"note": "The frontend renders exactly two regions (transcript tail + composer); there is no status/footer widget and no user-scripted status hook. The StatusLine struct in crates/harness/src/tui/state.rs is part of the unused view-model.",
"cost": "trivial"
},
{
"id": "desktop-notifications",
"domain": 8,
"domain_name": "Output / streaming / UX",
"capability": "Desktop notifications",
"semantics": "OS notifications on attention states",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ (channels + bell + hooks)",
"cx_detail": "✓ OSC9/bel (+notify argv)",
"catalog_supercode_today": "—",
"provenance": "cc§8; cx§8; oc§6",
"status": "partial",
"evidence": [
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "notify::maybe_fire("
},
{
"kind": "code",
"path": "crates/cli/src/notify.rs",
"symbol": "let child = Command::new(\"notify-send\")"
}
],
"note": "Opt-in turn-finish notification (desktop via `notify-send`, BEL fallback, optional SMTP email, plus the `notification` lifecycle hook), gated on enabled + tty + non-machine-format + an elapsed threshold. Gaps: only the turn-finish attention state (never an approval prompt or input request); `notify-send` is Linux-only (no osascript/Windows path); and no call site fires it from the full-screen frontend both parity presets select — only from `run`, `resume`, and the line-mode REPL. The OSC9/BEL backend ported into crates/frontend-tui/src/terminal/notifications has no caller at all."
},
{
"id": "external-editor-handoff",
"domain": 8,
"domain_name": "Output / streaming / UX",
"capability": "External editor handoff",
"semantics": "Compose the prompt in $EDITOR",
"cc": "yes",
"cx": "no",
"cc_detail": "✓ Ctrl+G",
"cx_detail": "—",
"catalog_supercode_today": "—",
"provenance": "cc§8; oc§8; pi§8",
"status": "absent",
"evidence": [],
"note": "No $EDITOR handoff on any live path. Action::RequestExternalEditor/ExternalEditorResult and a KeymapAction::ExternalEditor exist in the unused crates/harness/src/tui view-model; the frontend composer has no such key.",
"cost": "trivial"
},
{
"id": "image-paste-attach-input",
"domain": 8,
"domain_name": "Output / streaming / UX",
"capability": "Image paste/attach input",
"semantics": "Multimodal input from terminal",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ Ctrl+V chips",
"cx_detail": "✓ -i/--image",
"catalog_supercode_today": "—",
"provenance": "all §8",
"status": "partial",
"evidence": [
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "supercode::submit_agent_with_images(&mut agent, &prompt, &urls)"
}
],
"note": "`-i/--image <path|url>` (repeatable) attaches images to a `run` turn, converted by image_to_url and sent as multimodal content parts — matching CX's -i/--image. Missing the interactive half: main.rs warns '--image is only used by `run`', and the full-screen composer has no image paste/attach (crossterm bracketed paste carries text only), so CC's Ctrl+V chip flow has no equivalent."
},
{
"id": "inline-terminal-image-rendering",
"domain": 8,
"domain_name": "Output / streaming / UX",
"capability": "Inline terminal image rendering",
"semantics": "Render images in the TUI itself",
"cc": "no",
"cx": "no",
"cc_detail": "—",
"cx_detail": "—",
"catalog_supercode_today": "—",
"provenance": "pi§8",
"status": "not_applicable",
"evidence": [],
"note": ""
},
{
"id": "thinking-tool-detail-display-toggles",
"domain": 8,
"domain_name": "Output / streaming / UX",
"capability": "Thinking/tool-detail display toggles",
"semantics": "Collapse/expand reasoning + tool output",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ Ctrl+O/Ctrl+E",
"cx_detail": "✓ /raw + reasoning toggles",
"catalog_supercode_today": "—",
"provenance": "all §8",
"status": "absent",
"evidence": [],
"note": "The transcript renders reasoning and tool cells unconditionally (TranscriptKind::Reasoning / tool cells in crates/frontend-model/src/transcript.rs); there is no collapse/expand key, no /raw, and no verbosity setting on any surface.",
"cost": "trivial"
},
{
"id": "transcript-export-for-humans",
"domain": 8,
"domain_name": "Output / streaming / UX",
"capability": "Transcript export for humans",
"semantics": "Clipboard/file/HTML rendering of the conversation",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ /export, /copy",
"cx_detail": "✓ Ctrl+O copy last",
"catalog_supercode_today": "—",
"provenance": "cc§5; cx§8; oc§8; pi§8",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "supercode::human_export::render_messages(&messages, Some(&name), None, fmt)"
}
],
"note": "`supercode sessions export [--format text|html] [--out <path>]` renders a stored session for a human, to a file or stdout, defaulting from core.session.export_format. No clipboard (`/copy`) path and no in-session command — export is a CLI subcommand only."
},
{
"id": "web-ui-client",
"domain": 8,
"domain_name": "Output / streaming / UX",
"capability": "Web UI client",
"semantics": "Browser front-end on the same engine",
"cc": "variant",
"cx": "no",
"cc_detail": "✓* claude.ai web sessions (cloud)",
"cx_detail": "—",
"catalog_supercode_today": "—",
"provenance": "cc§10; oc§8",
"status": "partial",
"evidence": [
{
"kind": "code",
"path": "sdk/frontend-browser/package.json",
"symbol": "Reference browser observer and capability-gated controller for Supercode SDK runtimes"
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "require_server_capability(&supervision_config, &supervision_resolved, \"serve\")?;"
}
],
"note": "A reference browser front-end (sdk/frontend-browser: observer plus capability-gated controller) drives the same SDK runtime the terminal frontend does, over the HTTP /rpc + /events surface. But it can only attach to a served runtime, and cc-parity sets [capabilities.server] enabled = false — `serve` refuses without it — so no browser client is reachable under the preset."
},
{
"id": "remote-attach-control",
"domain": 8,
"domain_name": "Output / streaming / UX",
"capability": "Remote attach / control",
"semantics": "Drive a session from another device/terminal",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ Remote Control (phone) + claude attach",
"cx_detail": "✓ remote-control pairing (exp.)",
"catalog_supercode_today": "—",
"provenance": "cc§10; cx§10; oc§8",
"status": "partial",
"evidence": [
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "async fn serve_cmd("
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "supercode_frontend_tui::app::run(runtime.clone())"
}
],
"note": "`supercode serve` (loopback-by-default bind, bearer token, tmux-supervised detach) plus `supercode attach <id|url>` with a controller lease, observer-only mode, explicit displacement, and an SSH-tunnel recipe is a complete drive-from-another-terminal path. Gap: it is entirely gated on [capabilities.server], which BOTH parity presets disable, so neither preset can serve or attach; and there is no phone/remote-control pairing surface."
},
{
"id": "voice-input",
"domain": 8,
"domain_name": "Output / streaming / UX",
"capability": "Voice input",
"semantics": "Dictation / realtime voice",
"cc": "yes",
"cx": "variant",
"cc_detail": "✓ dictation",
"cx_detail": "✓* realtime voice (experimental)",
"catalog_supercode_today": "—",
"provenance": "cc§8; cx§10",
"status": "absent",
"evidence": [],
"note": "No dictation or realtime-voice path anywhere; would need an audio capture + speech pipeline.",
"cost": "architectural"
},
{
"id": "prompt-suggestions",
"domain": 8,
"domain_name": "Output / streaming / UX",
"capability": "Prompt suggestions",
"semantics": "Model-suggested next prompts",
"cc": "yes",
"cx": "no",
"cc_detail": "✓ (+print-mode messages)",
"cx_detail": "—",
"catalog_supercode_today": "—",
"provenance": "cc§8",
"status": "absent",
"evidence": [],
"note": "Nothing proposes follow-up prompts on any surface.",
"cost": "trivial"
},
{
"id": "away-summary-recap",
"domain": 8,
"domain_name": "Output / streaming / UX",
"capability": "Away summary / recap",
"semantics": "Auto recap after user absence",
"cc": "yes",
"cx": "no",
"cc_detail": "✓ /recap + away_summary records",
"cx_detail": "—",
"catalog_supercode_today": "—",
"provenance": "cc§8",
"status": "absent",
"evidence": [],
"note": "No absence detection and no recap record or command.",
"cost": "trivial"
},
{
"id": "shell-completions",
"domain": 8,
"domain_name": "Output / streaming / UX",
"capability": "Shell completions",
"semantics": "Generated bash/zsh/fish completions",
"cc": "no",
"cx": "yes",
"cc_detail": "—",
"cx_detail": "✓ codex completion",
"catalog_supercode_today": "—",
"provenance": "cx§6; oc§8",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "clap_complete::generate(*shell, &mut cmd, \"supercode\", &mut io::stdout());"
}
],
"note": "`supercode completions <shell>` generates completions from the real clap command tree (and `supercode man` renders the man page)."
},
{
"id": "terminal-title-management",
"domain": 8,
"domain_name": "Output / streaming / UX",
"capability": "Terminal title management",
"semantics": "Session-aware terminal titles",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓",
"cx_detail": "✓ [tui].terminal_title + /title",
"catalog_supercode_today": "—",
"provenance": "cc§8; cx§8; oc§6; pi§7",
"status": "partial",
"evidence": [
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "terminal_title::TitleGuard::enter(quiet, &model_label)"
}
],
"note": "An OSC 0 TitleGuard sets model + Thinking/Idle state and restores on drop, gated on quiet/TERM=dumb/non-tty and written to stderr only. It is installed at exactly one call site — the legacy line-mode REPL — so under both parity presets (which enable the TUI) neither the full-screen frontend nor `run` ever sets a title."
},
{
"id": "localization",
"domain": 8,
"domain_name": "Output / streaming / UX",
"capability": "Localization",
"semantics": "UI language setting",
"cc": "yes",
"cx": "no",
"cc_detail": "✓",
"cx_detail": "—",
"catalog_supercode_today": "—",
"provenance": "cc§8",
"status": "absent",
"evidence": [],
"note": "Every UI string is a hardcoded English literal; there is no locale setting, catalogue, or message-lookup layer.",
"cost": "architectural"
},
{
"id": "paste-handling-burst-summary",
"domain": 8,
"domain_name": "Output / streaming / UX",
"capability": "Paste handling (burst/summary)",
"semantics": "Large pastes collapsed with markers",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ paste mode",
"cx_detail": "✓ disable_paste_burst",
"catalog_supercode_today": "—",
"provenance": "all §8",
"status": "partial",
"evidence": [
{
"kind": "code",
"path": "crates/frontend-tui/src/terminal/lifecycle.rs",
"symbol": "self.ops.set_bracketed_paste(true)?;"
},
{
"kind": "code",
"path": "crates/frontend-model/src/composer.rs",
"symbol": "paste_burst: PasteBurst::default(),"
}
],
"note": "Bracketed paste is enabled on entry and restored on exit, and a PasteBurst detector wired into ComposerModel handles the unbracketed case (a rapid key stream makes Enter insert a newline instead of submitting, with retro-grab of already-typed characters) — the CX disable_paste_burst analog. Missing the row's own semantics: a large paste is inserted verbatim, never collapsed into a `[pasted N lines]` marker or summary."
},
{
"id": "multi-provider-model-access",
"domain": 9,
"domain_name": "Model routing",
"capability": "Multi-provider model access",
"semantics": "More than one backend/provider family",
"cc": "variant",
"cx": "variant",
"cc_detail": "✓* Claude-only across API/Bedrock/Vertex/Foundry/gateways",
"cx_detail": "✓* Responses-wire providers + OSS local",
"catalog_supercode_today": "✓* any OpenAI-compatible base_url (config.rs:119-123)",
"provenance": "cc§9; cx§9; oc§9; pi§9",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "let provider = OpenAiProvider::new_with_options("
},
{
"kind": "code",
"path": "crates/runtime/src/provider.rs",
"symbol": "format!(\"{}/chat/completions\", self.base_url.trim_end_matches('/'))"
}
],
"note": "Every agent builds its provider from core.base_url + api_key + extra_headers, so any OpenAI-compatible endpoint (a gateway, a router, a local server) is reachable, and the built-in alias table already spans anthropic/openai/google/deepseek/meta slugs. Like both harnesses this is a variant: reach comes from the endpoint, not from speaking several wire protocols — see the wire-protocol-breadth row."
},
{
"id": "remote-refreshed-model-catalog",
"domain": 9,
"domain_name": "Model routing",
"capability": "Remote-refreshed model catalog",
"semantics": "Capability DB fetched/refreshed, overridable",
"cc": "no",
"cx": "yes",
"cc_detail": "—",
"cx_detail": "✓ models-manager + model_catalog_json",
"catalog_supercode_today": "—",
"provenance": "cx§9; oc§9; pi§9",
"status": "absent",
"evidence": [],
"note": "The catalog is compiled in (model_catalog.rs DEFAULT_ALIASES plus runtime/src/model_limits.rs); nothing fetches, caches, refreshes, or overrides a capability database, and there is no model_catalog_json-style local override file.",
"cost": "architectural"
},
{
"id": "model-aliases-patterns",
"domain": 9,
"domain_name": "Model routing",
"capability": "Model aliases / patterns",
"semantics": "Friendly names resolving per account/provider",
"cc": "yes",
"cx": "no",
"cc_detail": "✓ (default/best/opus/[1m]…)",
"cx_detail": "—",
"catalog_supercode_today": "—",
"provenance": "cc§9; pi§9",
"status": "implemented",
"evidence": [
{
"kind": "module",
"name": "model_catalog"
},
{
"kind": "config",
"key": "capabilities.model_catalog.provider"
},
{
"kind": "code",
"path": "crates/harness/src/model_catalog.rs",
"symbol": "pub fn resolve_alias(&self, model: &str) -> String"
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "let model = model_routing.resolve_alias("
}
],
"note": "Friendly names resolve per provider AND per account through one table. cc-parity declares `provider = \"anthropic\"` + `account = \"max\"`, so `default`/`best` mean Opus the way CC's account-type defaults do (cc§9) and a different declared plan resolves the same name differently; `fast` comes from the provider scope; the built-in eleven resolve underneath both. PATTERN aliases match by single-`*` glob with the captured stem itself alias-resolved before substitution, so CC's suffix form `sonnet[1m]` lands on `anthropic/claude-sonnet-4-6[1m]`; exact entries always beat patterns and an unknown value still passes through. The table is no longer inert: `--model`, `/model` and the picker all resolve through `Config::model_routing`, the same value the request build and the fallback chain read."
},
{
"id": "mid-session-model-switching",
"domain": 9,
"domain_name": "Model routing",
"capability": "Mid-session model switching",
"semantics": "Change model without losing the session",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ /model, Alt+P",
"cx_detail": "✓ /model (+switch instructions injected)",
"catalog_supercode_today": "— (config-time only)",
"provenance": "cc§9; cx§9; oc§9; pi§3",
"status": "implemented",
"evidence": [
{
"kind": "config",
"key": "core.model_switch.allow_switch"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "pub fn record_model_change(&mut self, from: &str, to: &str, reason: Option<&str>)"
},
{
"kind": "code",
"path": "crates/harness/src/server.rs",
"symbol": "FrontendOperationInvocation::Model {"
},
{
"kind": "code",
"path": "crates/frontend-model/src/capabilities.rs",
"symbol": "FrontendOperationKind::Model => Some(FrontendOperationInvocation::Model {"
}
],
"note": "Both presets set `core.model_switch.allow_switch`, and the governed switch has its call sites. `Agent::record_model_change` is the one place a change is performed: it strips model-A reasoning artifacts from the live history (dep 8), moves `Config::model`, appends the typed `ModelChangeRecord`, writes that record into BP-8's append-only session journal, and emits `AgentEvent::ModelChanged`. It is reached from `/model <name>` and the picker in the REPL, and from a typed `Model` frontend operation the runtime advertises exactly when the gate is on — so the TUI both presets enable renders `/model` too, rather than the control existing only on the line-mode surface. cx-parity additionally sets `core.model_switch.notice`, splicing Codex's switch instructions into the conversation (cx§9); cc-parity leaves it unset because CC switches silently."
},
{
"id": "cross-provider-mid-session-handoff",
"domain": 9,
"domain_name": "Model routing",
"capability": "Cross-provider mid-session handoff",
"semantics": "Continue the same conversation on another provider",
"cc": "no",
"cx": "no",
"cc_detail": "—",
"cx_detail": "—¹⁹",
"catalog_supercode_today": "✓* (its mission: translate + emulate-to-continue; reduce/rehydrate.rs)",
"provenance": "oc§9; pi§9",
"status": "not_applicable",
"evidence": [],
"note": ""
},
{
"id": "small-utility-model-routing",
"domain": 9,
"domain_name": "Model routing",
"capability": "Small/utility model routing",
"semantics": "Cheap model for titles/summaries/extraction",
"cc": "yes",
"cx": "variant",
"cc_detail": "✓ ANTHROPIC_SMALL_FAST_MODEL",
"cx_detail": "✓* extract/consolidation models (memories)",
"catalog_supercode_today": "—",
"provenance": "cc§9; cx§6; oc§9",
"status": "implemented",
"evidence": [
{
"kind": "config",
"key": "core.compaction.summarize"
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "let core_compaction_summarizes = config.compaction_summarize"
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "fn maybe_install_span_summarizer"
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "fn maybe_install_auto_titler"
}
],
"note": "The cheap-model side-call is reachable under BOTH presets. Core compaction's own span summary (`core.compaction.summarize`, set by both, with a trigger armed in both) installs the `CliSpanSummarizer` on `capabilities.model_catalog.small_model` with the D-9 main-model fallback; cc-parity additionally sets `core.session.auto_title`, so CC's own small-fast-model titling (cc§9 ANTHROPIC_SMALL_FAST_MODEL) runs too. cc-parity pins Haiku, so the side-calls genuinely go somewhere cheaper than Opus. cx-parity pins none and falls back to the main model — faithful, not a gap: Codex's own small-model consumers are the memory extract/consolidation models, and cx-parity keeps `memory` off to match Codex's `[features].memories = false` default."
},
{
"id": "reasoning-effort-thinking-budgets",
"domain": 9,
"domain_name": "Model routing",
"capability": "Reasoning effort / thinking budgets",
"semantics": "Per-model effort levels + budgets",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ effort levels + MAX_THINKING_TOKENS",
"cx_detail": "✓ none…ultra (+plan-mode effort)",
"catalog_supercode_today": "✓ `effort` (config.rs:143-144)",
"provenance": "cc§9; cx§9; oc§9; pi§9",
"status": "implemented",
"evidence": [
{
"kind": "config",
"key": "core.effort"
},
{
"kind": "config",
"key": "capabilities.model_catalog.models"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "fn apply_routing(&self, req: &mut ChatRequest)"
},
{
"kind": "code",
"path": "crates/runtime/src/provider.rs",
"symbol": "o.insert(\"max_tokens\".into(), json!(budget));"
}
],
"note": "All three halves land, decided by one `Agent::apply_routing` call per request so a mid-session switch re-decides them for the new model. LEVEL: `[core] effort` (both presets `medium`) with a per-model tier table — `[capabilities.model_catalog.models.<pattern>] effort` / `max_effort`, most specific pattern winning — so cc-parity's Haiku is capped at `low` however the session is set, and an unrankable spelling is forwarded verbatim rather than silently rewritten. BUDGET: `thinking_budget` (CC's MAX_THINKING_TOKENS) reaches the wire as the unified `reasoning.max_tokens` field. PLAN MODE: `[capabilities.plan_mode] effort` (cc-parity `high`) is the level while the mode is live and hands the session level back on exit — Codex's `/plan` effort-tier steering (cx§6), armed under the preset that has the module."
},
{
"id": "failure-fallback-model-chains",
"domain": 9,
"domain_name": "Model routing",
"capability": "Failure fallback model chains",
"semantics": "Auto-switch on overload/unavailability",
"cc": "yes",
"cx": "variant",
"cc_detail": "✓ --fallback-model (≤3)",
"cx_detail": "✓* compact_model_fallback only",
"catalog_supercode_today": "—",
"provenance": "cc§9; cx§2",
"status": "implemented",
"evidence": [
{
"kind": "module",
"name": "model_catalog"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "async fn complete_with_fallback("
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "pub fn is_failover_worthy(error: &Error) -> bool"
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "fallback_model: Vec<String>,"
}
],
"note": "The chain is EXECUTED, not just resolved. When a request fails in a way another model could answer (`is_failover_worthy`: 429 or 5xx — where overload lives — after the transport's own retry has given up), `Agent::complete_with_fallback` re-sends against the next entry of `Config::model_fallback`, re-applying routing for that model and stripping model-A reasoning artifacts from the request first. Each hop is recorded exactly like a user switch (typed record carrying the failure as its `reason`, session-journal line, `ModelChanged` event) and the model stays switched. A 4xx that is not a rate limit is never walked — it would fail identically against every entry. Both presets ship the list empty because neither harness ships a default fallback; `--fallback-model` (repeatable) is CC's own per-invocation shape (cc§9) and appends to whatever the config resolved, through the same alias table."
},
{
"id": "content-based-safety-rerouting",
"domain": 9,
"domain_name": "Model routing",
"capability": "Content-based safety rerouting",
"semantics": "Classifier reroutes flagged requests to another model",
"cc": "yes",
"cx": "variant",
"cc_detail": "✓ (Fable→Opus + notice)",
"cx_detail": "✓* ModelReroute/SafetyBuffering events",
"catalog_supercode_today": "—",
"provenance": "cc§9; cx§9",
"status": "absent",
"evidence": [],
"note": "No classifier, no reroute decision point, and no reroute notice; a request always goes to the configured model.",
"cost": "architectural"
},
{
"id": "org-model-allowlists-effort-caps",
"domain": 9,
"domain_name": "Model routing",
"capability": "Org model allowlists / effort caps",
"semantics": "Enterprise restriction of models/effort",
"cc": "yes",
"cx": "variant",
"cc_detail": "✓ availableModels + enforce",
"cx_detail": "✓* requirements-pinned features/profiles",
"catalog_supercode_today": "—",
"provenance": "cc§9; cx§6; oc§9",
"status": "partial",
"evidence": [
{
"kind": "config",
"key": "capabilities.model_catalog.allowed_models"
},
{
"kind": "code",
"path": "crates/harness/src/model_catalog.rs",
"symbol": "pub fn refusal(&self, model: &str) -> Option<String>"
},
{
"kind": "code",
"path": "crates/harness/src/configfile.rs",
"symbol": "ResolveError::ModelNotAllowed"
}
],
"note": "The RULE exists and binds, at the config layer. `allowed_models` / `denied_models` match by the same patterns the rest of routing uses and refuse at resolve time with a hard `ResolveError::ModelNotAllowed` — an error, never a warning — against every model the table hands out (`core.model`, `small_model`, each `fallback` entry), and the `/model` doors refuse a forbidden target rather than switching to it. `max_effort` clamps rather than refusing, per model or table-wide, and the clamp is named in the resolver's warnings. §3.3 monotonic tightening holds: those three keys are stripped from a project layer, so a repo can never lift a restriction its user/global layer set. RESIDUE, and the reason this is not `implemented`: there is still no MANAGED/enterprise tier above the user's own file — the layer an org admin owns and the user cannot edit, which is what makes CC's `availableModels` + enforce an ORG control rather than a preference. That tier is BP-14's; this row is the config-layer half only."
},
{
"id": "subscription-oauth-login",
"domain": 9,
"domain_name": "Model routing",
"capability": "Subscription OAuth login",
"semantics": "Consumer-plan auth (Claude Max/ChatGPT/Copilot)",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ /login",
"cx_detail": "✓ codex login (ChatGPT)",
"catalog_supercode_today": "—",
"provenance": "cc§9; cx§9; oc§9; pi§9",
"status": "partial",
"evidence": [
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "supercode::harness_authentication_plan("
}
],
"note": "`supercode harness login <claude|codex>` discovers the native CLI's own sign-in mechanisms (browser or device-code), launches it, and verifies the result through that harness's own status command — consumer-plan auth for the emulate-to-continue lane, with no credential ever read or copied. supercode's OWN provider path has no OAuth at all: capabilities.model_oauth is disabled in both parity presets and module 27 is unimplemented, so the agent loop still requires an api_key."
},
{
"id": "custom-local-providers",
"domain": 9,
"domain_name": "Model routing",
"capability": "Custom/local providers",
"semantics": "User-declared endpoints (Ollama/vLLM/proxies)",
"cc": "variant",
"cx": "yes",
"cc_detail": "✓* gateway base_url only",
"cx_detail": "✓ [model_providers] + --oss",
"catalog_supercode_today": "✓ base_url + extra_headers/extra_body (config.rs:122-123, 148-151, 207-209)",
"provenance": "cc§9; cx§9; oc§9; pi§9",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "let provider = OpenAiProvider::new_with_options("
},
{
"kind": "code",
"path": "crates/runtime/src/provider.rs",
"symbol": "for (k, v) in &self.extra_headers {"
}
],
"note": "core.base_url points the agent at any user-declared endpoint (Ollama/vLLM/a proxy), with extra_headers and extra_body passthrough and env substitution in config values; base_url is stripped from a project-layer config, so an untrusted repo cannot redirect credentials."
},
{
"id": "per-model-capability-bits-drive-tools",
"domain": 9,
"domain_name": "Model routing",
"capability": "Per-model capability bits drive tools",
"semantics": "Tool surface adapts to model (apply_patch, search…)",
"cc": "no",
"cx": "yes",
"cc_detail": "—",
"cx_detail": "✓ catalog capability bits",
"catalog_supercode_today": "—",
"provenance": "cx§9; oc§1; pi§9",
"status": "implemented",
"evidence": [
{
"kind": "config",
"key": "capabilities.tools_apply_patch.per_model"
},
{
"kind": "config",
"key": "capabilities.model_catalog.models"
},
{
"kind": "code",
"path": "crates/harness/src/tools/mod.rs",
"symbol": "(\"edit_file\" | \"write_file\", Some(false)) => true,"
}
],
"note": "cx-parity's `tools_apply_patch.per_model` flag now has a second, load-bearing reader: `ToolRegistry::from_config`'s own selection. `[capabilities.model_catalog.models.<pattern>]` carries the catalog bits (cx§9 `apply_patch_tool_type`, `supports_search_tool`), and the registry resolves them for `Config::model` out of the same `Routing` table every other routing decision reads — no parallel registry. Under cx-parity the `openai/gpt-5*` family gets the freeform `apply_patch` envelope and never the edit/write pair, while `openai/gpt-4*` gets `edit_file`/`write_file` and no `apply_patch`, even though `[core.tools] enabled` names neither: the write SURFACE follows the model. A model no rule matches keeps the preset's own selection, so a config that names no bits is byte-identical to before."
},
{
"id": "fast-mode-service-tiers",
"domain": 9,
"domain_name": "Model routing",
"capability": "Fast mode / service tiers",
"semantics": "Priority/fast variants toggle",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ /fast (+cache invalidation warning)",
"cx_detail": "✓ service_tier + /fast",
"catalog_supercode_today": "—",
"provenance": "cc§9; cx§9",
"status": "implemented",
"evidence": [
{
"kind": "config",
"key": "capabilities.model_catalog.service_tier"
},
{
"kind": "code",
"path": "crates/runtime/src/provider.rs",
"symbol": "obj.insert(\"service_tier\".into(), json!(tier));"
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "fn handle_fast("
}
],
"note": "`service_tier` is modelled on the request (`ChatRequest::service_tier`, sent as the OpenAI-compatible field) and resolved per model out of the routing table; both presets set it to their harness's standard tier. `/fast [on|off]` is the toggle: it sets the session-level override that wins over the configured rule for every subsequent request until cleared, and it carries CC's own warning that changing tier changes the cache key so the next request pays a full-price prompt-cache miss (cc§9). Named boundary: the toggle is a REPL slash command — the runtime-level control the TUI composer renders is `/model`, not `/fast`."
},
{
"id": "request-path-interception",
"domain": 9,
"domain_name": "Model routing",
"capability": "Request-path interception",
"semantics": "Rewrite headers/payload per provider request",
"cc": "no",
"cx": "variant",
"cc_detail": "—²⁰",
"cx_detail": "✓* static http_headers/env_http_headers",
"catalog_supercode_today": "✓ extra_headers + extra_body passthrough (config.rs:148-151, 207-209)",
"provenance": "cx§9; oc§9; pi§9",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/runtime/src/provider.rs",
"symbol": "for (k, v) in &self.extra_headers {"
},
{
"kind": "code",
"path": "crates/runtime/src/provider.rs",
"symbol": "for (k, v) in &req.extra_body {"
}
],
"note": "core.extra_headers are applied to every provider request and core.extra_body keys are merged into the request body, overriding modeled fields — the same static, config-declared shape CX's http_headers/env_http_headers row describes. No programmatic per-request callback."
},
{
"id": "reasoning-replay-artifacts-preserved",
"domain": 9,
"domain_name": "Model routing",
"capability": "Reasoning-replay artifacts preserved",
"semantics": "Signatures/encrypted CoT kept for faithful resume",
"cc": "variant",
"cx": "yes",
"cc_detail": "✓* redacted_thinking blocks",
"cx_detail": "✓ encrypted_content on reasoning items",
"catalog_supercode_today": "✓* (schema preserves; never replays cross-model — cx§3 supercode note)",
"provenance": "cc§5; cx§3; oc§3",
"status": "partial",
"evidence": [
{
"kind": "code",
"path": "crates/interchange/src/session/mod.rs",
"symbol": "pub raw: Vec<String>,"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "reduce::rehydrate::filter_reasoning_artifacts(&mut self.history)"
}
],
"note": "Preservation is solid and unchanged: thinking / thinking_signature / redacted_thinking blocks and Codex encrypted_content survive an import/export round trip byte-exactly (Session::raw retains every source line, and per-block signatures are kept rather than collapsed to the last one). BP-13 closed the caller half of the old note: `reduce::rehydrate::filter_reasoning_artifacts` now runs on every governed switch and every fallback hop, through `Agent::record_model_change`, which both parity presets reach. RESIDUE: REPLAY. supercode's provider speaks OpenAI chat-completions, which has no slot for a signed thinking block or `encrypted_content`, so a resumed SAME-model turn cannot carry CoT continuity forward — the design doc's cx-parity 'Responses-only wire + encrypted reasoning' gap names exactly this, and it is bounded by the wire row below, not by anything in this row's own machinery."
},
{
"id": "model-served-vs-requested-provenance",
"domain": 9,
"domain_name": "Model routing",
"capability": "Model-served-vs-requested provenance",
"semantics": "Record the concrete model that answered",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ (model on assistant records)",
"cx_detail": "✓ (turn_context model)",
"catalog_supercode_today": "—",
"provenance": "cc§5; cx§5; oc§5; pi§9",
"status": "implemented",
"evidence": [
{
"kind": "config",
"key": "core.session.append_only"
},
{
"kind": "code",
"path": "crates/harness/src/usage_log.rs",
"symbol": "pub served_model: Option<String>,"
},
{
"kind": "code",
"path": "crates/runtime/src/provider.rs",
"symbol": "pub const SERVED_MODEL_KEY"
},
{
"kind": "code",
"path": "crates/harness/src/session_journal.rs",
"symbol": "JournalOp::Usage { record } => state.usage.push(record),"
}
],
"note": "Both gaps closed. The provider now captures the `model` field the response itself reports and hands it up on the assistant message (`SERVED_MODEL_KEY`), so `UsageRecord` carries the model REQUESTED and the model that SERVED it as separate fields and `diverged()` can be true — a gateway resolving a floating name to a dated snapshot, a routed tier, a fallback hop. A provider that reports nothing leaves `served_model` absent; an unknown is never recorded as agreement. Persistence no longer depends on a `save_usage_log` call nobody makes: every record is written to BP-8's append-only session journal as the turn completes, which both presets arm via `core.session.append_only`, so it is on disk before the transcript rewrite and survives the process."
},
{
"id": "wire-protocol-breadth",
"domain": 9,
"domain_name": "Model routing",
"capability": "Wire-protocol breadth",
"semantics": "Number of provider wire APIs spoken",
"cc": "variant",
"cx": "variant",
"cc_detail": "✓* Anthropic Messages (+gateway)",
"cx_detail": "✓* Responses only (chat REMOVED)",
"catalog_supercode_today": "✓* OpenAI chat-completions style",
"provenance": "cc§9; cx§9; oc§9; pi§9",
"status": "partial",
"evidence": [
{
"kind": "code",
"path": "crates/runtime/src/provider.rs",
"symbol": "format!(\"{}/chat/completions\", self.base_url.trim_end_matches('/'))"
}
],
"note": "Exactly one wire is spoken: OpenAI chat-completions (with SSE streaming). Numerically that matches CC's one (Anthropic Messages) and CX's one (Responses), but it is a DIFFERENT one in both cases — under cc-parity supercode cannot talk the Anthropic Messages API directly, and under cx-parity it cannot talk Responses, which the design doc's cx-parity gap table records as irreducible ('wire_api = responses is mandatory upstream'). Reaching those models depends on an OpenAI-compatible gateway in front of them."
},
{
"id": "git-worktree-parallelism",
"domain": 10,
"domain_name": "Harness-specific / everything else",
"capability": "Git worktree parallelism",
"semantics": "Isolated worktrees per session/subagent",
"cc": "yes",
"cx": "no",
"cc_detail": "✓ (--worktree, isolation:worktree, hooks for non-git VCS)",
"cx_detail": "—",
"catalog_supercode_today": "—",
"provenance": "cc§10; oc§10",
"status": "absent",
"evidence": [],
"note": "No worktree creation, no per-session or per-subagent isolation root, and no --worktree flag; subagents share the parent's cwd. Would need a VCS-isolation subsystem plus a lifecycle contract for creating/cleaning worktrees.",
"cost": "architectural"
},
{
"id": "cloud-execution-task-delegation",
"domain": 10,
"domain_name": "Harness-specific / everything else",
"capability": "Cloud execution / task delegation",
"semantics": "Sessions/tasks running in vendor cloud",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ (web sessions, --cloud, /teleport, routines)",
"cx_detail": "✓ (codex cloud, codex apply)",
"catalog_supercode_today": "—",
"provenance": "cc§10; cx§10; oc§10",
"status": "absent",
"evidence": [],
"note": "Every turn runs in the local process; there is no vendor cloud target, no task-delegation API, and no apply-a-cloud-result path.",
"cost": "architectural"
},
{
"id": "background-agent-manager-daemon",
"domain": 10,
"domain_name": "Harness-specific / everything else",
"capability": "Background-agent manager daemon",
"semantics": "Local supervisor hosting detached sessions",
"cc": "yes",
"cx": "variant",
"cc_detail": "✓ (agent view, claude daemon)",
"cx_detail": "✓* (app-server daemon for remote-control)",
"catalog_supercode_today": "—",
"provenance": "cc§10; cx§10; oc§8",
"status": "partial",
"evidence": [
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "async fn serve_cmd("
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "require_server_capability(&supervision_config, &supervision_resolved, \"serve\")?;"
}
],
"note": "`supercode serve` detaches itself under a predictable tmux session, registers the runtime so `sessions list --live` finds it, reconciles an already-supervised runtime instead of double-starting, and `attach`/detach never stop the hosted runtime — a real local supervisor for detached sessions. Gaps: it is gated on [capabilities.server], which BOTH parity presets disable; supervision depends on tmux being installed (otherwise it degrades to foreground); and there is no respawn or aggregated agent-view surface."
},
{
"id": "ide-integration",
"domain": 10,
"domain_name": "Harness-specific / everything else",
"capability": "IDE integration",
"semantics": "VS Code/JetBrains/Zed surfaces",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ (VS Code + JetBrains)",
"cx_detail": "✓ (vscode session source, IDE clients of app-server)",
"catalog_supercode_today": "—",
"provenance": "cc§10; cx§5; oc§10; pi§8",
"status": "partial",
"evidence": [
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "supercode::acp_server::run_stdio(server, stdin, stdout).await?;"
}
],
"note": "`supercode acp` serves Agent Client Protocol v1 over stdio (with a compatibility profile switch), which is the editor surface Zed and other ACP clients speak, and `resume <session> --acp` exposes an imported continuation the same way. No VS Code extension and no JetBrains plugin, so CC's and CX's own IDE surfaces have no equivalent."
},
{
"id": "acp-agent-client-protocol",
"domain": 10,
"domain_name": "Harness-specific / everything else",
"capability": "ACP (Agent Client Protocol)",
"semantics": "Native ACP server for ACP editors",
"cc": "no",
"cx": "no",
"cc_detail": "—",
"cx_detail": "—",
"catalog_supercode_today": "—",
"provenance": "oc§10",
"status": "not_applicable",
"evidence": [],
"note": ""
},
{
"id": "github-gitlab-ci-agents",
"domain": 10,
"domain_name": "Harness-specific / everything else",
"capability": "GitHub/GitLab CI agents",
"semantics": "Bot responds in issues/PRs via CI",
"cc": "yes",
"cx": "variant",
"cc_detail": "✓ (GH Actions, GitLab)",
"cx_detail": "✓* (cloud from integrations)",
"catalog_supercode_today": "—",
"provenance": "cc§10; cx§10; oc§10",
"status": "absent",
"evidence": [],
"note": "Nothing responds in issues or PRs; there is no bot, no CI action, and no forge webhook surface shipped with the product.",
"cost": "architectural"
},
{
"id": "slack-chat-integration",
"domain": 10,
"domain_name": "Harness-specific / everything else",
"capability": "Slack/chat integration",
"semantics": "Harness reachable from chat",
"cc": "yes",
"cx": "no",
"cc_detail": "✓ (Claude Tag)",
"cx_detail": "—",
"catalog_supercode_today": "—",
"provenance": "cc§10; oc§10; pi§10",
"status": "absent",
"evidence": [],
"note": "No chat transport of any kind — no Slack app, no bot bridge, no chat adapter.",
"cost": "architectural"
},
{
"id": "git-integration-metadata-diff-pr",
"domain": 10,
"domain_name": "Harness-specific / everything else",
"capability": "Git integration (metadata, diff, PR)",
"semantics": "Branch/sha captured; diff/PR affordances",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ (gitBranch on records, PR badges, /from-pr)",
"cx_detail": "✓ (session_meta.git, /diff, repo guard)",
"catalog_supercode_today": "✓* (preserves gitBranch etc. on import)",
"provenance": "cc§5; cx§10; oc§10",
"status": "partial",
"evidence": [
{
"kind": "code",
"path": "crates/interchange/src/session/mod.rs",
"symbol": "pub raw: Vec<String>,"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "crate::git_metadata::capture(&config.cwd, now_ms())"
}
],
"note": "A foreign session's own git fields (Claude gitBranch, Codex session_meta.git) survive import/export byte-exactly through raw-line preservation, and supercode's own sessions can capture a typed GitMetadataRecord (branch/sha/dirty) once at construction. Gaps: the capture is gated on core.session.git_metadata, which NEITHER parity preset sets, so it is off under both; and there are no diff or PR affordances at all (no /diff, no PR badges, no from-PR entry point)."
},
{
"id": "telemetry-otel-export",
"domain": 10,
"domain_name": "Harness-specific / everything else",
"capability": "Telemetry / OTel export",
"semantics": "Metrics/logs/traces with content toggles",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ (OTel + org analytics)",
"cx_detail": "✓ ([otel] exporters, statsig)",
"catalog_supercode_today": "—",
"provenance": "cc§10; cx§6; oc§6; pi§6",
"status": "absent",
"evidence": [],
"note": "`telemetry` is a reserved module name (MODULE_NAMES, modules.rs '34. telemetry — OTel/analytics exporters') with no implementation behind it: no exporter, no span/metric emission, no content toggle. Neither parity preset enables it.",
"cost": "architectural"
},
{
"id": "diagnostics-doctor",
"domain": 10,
"domain_name": "Harness-specific / everything else",
"capability": "Diagnostics / doctor",
"semantics": "Self-check of install/config/auth",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ /doctor (+context-cost analysis)",
"cx_detail": "✓ codex doctor (--json)",
"catalog_supercode_today": "—",
"provenance": "cc§10; cx§10; oc§6; pi§8",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "async fn doctor(cli: &Cli, json: bool, deep: bool) -> Result<()> {"
}
],
"note": "`supercode doctor [--json] [--deep]` reports tiered self-checks — config/api-key source, provider reachability, catalog resolution, and with --deep a live probe request — in both a styled and a machine-readable shape."
},
{
"id": "usage-stats-reporting",
"domain": 10,
"domain_name": "Harness-specific / everything else",
"capability": "Usage/stats reporting",
"semantics": "Local aggregation of tokens/cost/tools",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ /usage /insights /stats",
"cx_detail": "✓ /usage",
"catalog_supercode_today": "partial (inspect stats savings figures)",
"provenance": "cc§10; cx§8; oc§10; pi§3",
"status": "partial",
"evidence": [
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "println!(\"{}\", ui::kv(\"messages\", ui::bold_plain(message_line)));"
}
],
"note": "`supercode inspect <session> [--json]` aggregates one session: message counts by role plus, when a reduction log exists, view-vs-full token estimates and per-reduction retained/saved/suppressed attribution. Under both parity presets capabilities.reduction is disabled, so a supercode-produced session has no reduction log and only the counts render. Gaps beyond that: no cost accounting, no per-tool tallies, no cross-session or time-window aggregation (CC's /usage /stats), and the per-turn token log the agent already builds is never written to disk — Agent::save_usage_log has no CLI call site."
},
{
"id": "token-reduction-engine-lossless",
"domain": 10,
"domain_name": "Harness-specific / everything else",
"capability": "Token-reduction engine (lossless)",
"semantics": "Systematic context shrinking with byte-exact restore + audit log",
"cc": "no",
"cx": "no",
"cc_detail": "—",
"cx_detail": "—",
"catalog_supercode_today": "✓ reduce.rs (8 reduction kinds + ReductionLog + sentinel + invert)",
"provenance": "reduce.rs (whole)",
"status": "not_applicable",
"evidence": [],
"note": ""
},
{
"id": "session-format-translation-between-harnesses",
"domain": 10,
"domain_name": "Harness-specific / everything else",
"capability": "Session-format translation between harnesses",
"semantics": "Load one harness's session, emit another's",
"cc": "no",
"cx": "variant",
"cc_detail": "—",
"cx_detail": "✓* /import (one-way, from CC)",
"catalog_supercode_today": "✓ (core product: CC/CX/OC/PI loaders + exporters)",
"provenance": "cx§7; oc§5; supercode SPEC (cited in cc§10/cx§10 notes)",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "let jsonl = session.to_jsonl(format)?;"
},
{
"kind": "code",
"path": "crates/interchange/src/session/mod.rs",
"symbol": "pub raw: Vec<String>,"
}
],
"note": "The product's core loop, and independent of every capability module: loaders for Claude Code, Codex, opencode (JSONL and SQLite), pi and others, a canonical in-memory Session, and Session::to_jsonl back out to a chosen harness format — with verbatim raw-line retention making the line-oriented round trips byte-lossless. Reached from `convert`, `resume`, and `handoff`; the reduced-export variant additionally splices origin bytes, but that path needs capabilities.reduction, which both parity presets disable."
},
{
"id": "world-state-channel-in-session-file",
"domain": 10,
"domain_name": "Harness-specific / everything else",
"capability": "World-state channel in session file",
"semantics": "Durable non-conversation state records for tools/extensions",
"cc": "variant",
"cx": "yes",
"cc_detail": "✓* (file-history-snapshot, worktree-state records)",
"cx_detail": "✓ world_state records (exp.)",
"catalog_supercode_today": "✓* (Unknown-record preservation on import)",
"provenance": "cc§5; cx§10; oc§3; pi§5",
"status": "partial",
"evidence": [
{
"kind": "code",
"path": "crates/interchange/src/session/mod.rs",
"symbol": "pub raw: Vec<String>,"
},
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "crate::usage_log::UsageRecord::from_usage("
}
],
"note": "Foreign non-conversation records with no canonical representation (Claude file-history-snapshot, Codex world_state) are retained verbatim and re-emitted, and supercode has its own typed durable side-channels (usage log, model-change log, git metadata) that are session data rather than display notices. Missing the write side of the row's semantics: no tool or extension can append a durable state record — the typed channels are internal and their save_* methods have no CLI call site."
},
{
"id": "shell-environment-snapshotting",
"domain": 10,
"domain_name": "Harness-specific / everything else",
"capability": "Shell environment snapshotting",
"semantics": "Capture user shell env once to speed commands",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ (rc capture at start + CLAUDE_ENV_FILE)",
"cx_detail": "✓ shell_snapshot feature",
"catalog_supercode_today": "—",
"provenance": "cc§1; cx§10",
"status": "partial",
"evidence": [
{
"kind": "code",
"path": "crates/harness/src/agent.rs",
"symbol": "let shell_env = if config.shell_env_snapshot {"
}
],
"note": "core.shell_env_snapshot captures `$SHELL -lc env` once at agent construction and every bash call inherits the snapshot (empty and warned, never fatal, if the login shell fails). cx-parity turns it on; cc-parity does NOT set the key, so under cc-parity it stays off (default false) and CC's rc-capture + CLAUDE_ENV_FILE has no equivalent there."
},
{
"id": "process-hardening-supply-chain-posture",
"domain": 10,
"domain_name": "Harness-specific / everything else",
"capability": "Process hardening / supply-chain posture",
"semantics": "Self-hardening, pinned deps, script-less installs",
"cc": "no",
"cx": "yes",
"cc_detail": "—",
"cx_detail": "✓ process-hardening crate",
"catalog_supercode_today": "—",
"provenance": "cx§4; pi§4",
"status": "partial",
"evidence": [
{
"kind": "code",
"path": "deny.toml",
"symbol": "yanked = \"deny\""
}
],
"note": "Supply-chain half only: a cargo-deny policy (advisories with dated triage, yanked = deny, license allow-list, source/ban rules) over a committed Cargo.lock, and the npm package template declares only `bin` with no install scripts. The self-hardening half is entirely absent — no equivalent of CX's process-hardening crate (no core-dump/ptrace suppression, no environment scrubbing at startup)."
},
{
"id": "deep-links-url-launch",
"domain": 10,
"domain_name": "Harness-specific / everything else",
"capability": "Deep links / URL launch",
"semantics": "Protocol handler starts a session from a URL",
"cc": "yes",
"cx": "no",
"cc_detail": "✓ claude-cli://",
"cx_detail": "—",
"catalog_supercode_today": "—",
"provenance": "cc§10",
"status": "absent",
"evidence": [],
"note": "No URL scheme is registered or parsed; a session can only be started from the CLI.",
"cost": "trivial"
},
{
"id": "artifacts-publish-live-pages",
"domain": 10,
"domain_name": "Harness-specific / everything else",
"capability": "Artifacts (publish live pages)",
"semantics": "Session publishes hosted interactive pages",
"cc": "yes",
"cx": "no",
"cc_detail": "✓",
"cx_detail": "—",
"catalog_supercode_today": "—",
"provenance": "cc§10",
"status": "absent",
"evidence": [],
"note": "Nothing publishes hosted pages from a session; would need a hosting/publish service and a share surface.",
"cost": "architectural"
},
{
"id": "onboarding-education-ux",
"domain": 10,
"domain_name": "Harness-specific / everything else",
"capability": "Onboarding/education UX",
"semantics": "Lessons, insights, team-onboarding generators",
"cc": "yes",
"cx": "no",
"cc_detail": "✓ (/powerup /insights /team-onboarding)",
"cx_detail": "—",
"catalog_supercode_today": "—",
"provenance": "cc§10; pi§8",
"status": "partial",
"evidence": [
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "maybe_onboard(cli).await;"
}
],
"note": "A first-run guided setup fires at most once on a real terminal (suppressed by --bare/--quiet/non-tty) and writes a working config, with `supercode login` and `supercode doctor` as the on-demand follow-ups. That is setup, not education: no lessons, no insights/usage-review surface, and no team-onboarding generator."
},
{
"id": "self-extending-agent-workflow",
"domain": 10,
"domain_name": "Harness-specific / everything else",
"capability": "Self-extending agent workflow",
"semantics": "Agent writes its own extensions/skills, hot-reloads",
"cc": "no",
"cx": "no",
"cc_detail": "—",
"cx_detail": "—",
"catalog_supercode_today": "—",
"provenance": "pi§10",
"status": "not_applicable",
"evidence": [],
"note": ""
},
{
"id": "ambient-delight-features",
"domain": 10,
"domain_name": "Harness-specific / everything else",
"capability": "Ambient/delight features",
"semantics": "Terminal pets etc. (config-modeled)",
"cc": "variant",
"cx": "yes",
"cc_detail": "✓* /stickers /radio",
"cx_detail": "✓ /pets ([tui].pet)",
"catalog_supercode_today": "—",
"provenance": "cc§8; cx§10; pi§10",
"status": "absent",
"evidence": [],
"note": "No pets, stickers, radio, or comparable ambient surface, and no config knob modelling one.",
"cost": "trivial"
},
{
"id": "scheduled-job-list-get",
"domain": 11,
"domain_name": "Orchestration & automation",
"capability": "Scheduled job: list/get",
"semantics": "Enumerate the harness's scheduled jobs and read one job's definition",
"cc": "variant",
"cx": "no",
"cc_detail": "✓*²¹ CronList (session-scoped)",
"cx_detail": "—",
"catalog_supercode_today": "✓* `ClaudeRuntimeManifest.active_crons`/`pending_wakeups` (claude_runtime_state.rs:37-39), surfaced by cli/main.rs:11608",
"provenance": "cc§1 CronCreate/CronList; cc§5 session-scoped crons",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/harness/src/claude_runtime_state.rs",
"symbol": "pub active_crons: Vec<ClaudeCronJob>,"
},
{
"kind": "code",
"path": "crates/harness/src/jobs.rs",
"symbol": "fn claude_cron_row"
},
{
"kind": "code",
"path": "crates/harness/src/harness_service.rs",
"symbol": "\"harness.v1.jobs.get\""
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "\"harness.v1.jobs.list\""
}
],
"note": "ORCH-7 closed this row for Claude Code: `harness.v1.jobs.list|get` and `supercode jobs list|get` enumerate a session's `active_crons` and `pending_wakeups` as uniform rows (wakeups as one-shot `payload.kind = wakeup`) and read one by id, with the native `ClaudeCronJob` / `ClaudeWakeup` record returned verbatim. Without `--session` the scan is bounded: only index sessions whose JSONL mentions `CronCreate` / `ScheduleWakeup` are derived, newest-first under a declared cap. Boundary, stated rather than hidden: Claude Code publishes no cron query API, and its own tool result calls these jobs session-only, so the session's JSONL IS the store this row can be answered from — a job created in the current turn is visible as soon as its record is written."
},
{
"id": "scheduled-job-create-update-pause-resume-run-delete",
"domain": 11,
"domain_name": "Orchestration & automation",
"capability": "Scheduled job: create/update/pause/resume/run/delete",
"semantics": "Create, edit, pause/resume, run-now and delete a scheduled job through the harness's own verb",
"cc": "variant",
"cx": "no",
"cc_detail": "✓*²¹ CronCreate/CronDelete (model-invoked; no pause/resume/run-now)",
"cx_detail": "—",
"catalog_supercode_today": "—",
"provenance": "cc§1",
"status": "absent",
"evidence": [],
"note": "supercode has no mutating job verb of any kind. Claude Code's only door is the model-invoked `CronCreate`/`CronDelete` tool pair inside a driven session, so the uniform verb (plan C1) means a new `harness.v1.jobs.*` noun plus a way to emit a tool call into a live session — a new subsystem, not a knob. The emulated tool pair edits the imported manifest (`Agent::run_claude_runtime_tool`) and every response says the job will not execute, so even that is a record, not a job the harness owns.",
"cost": "architectural"
},
{
"id": "run-list-get",
"domain": 11,
"domain_name": "Orchestration & automation",
"capability": "Run: list/get",
"semantics": "List one job's past fires and read a fire's outcome",
"cc": "variant",
"cx": "no",
"cc_detail": "✓*²² a fire is an ordinary turn in the session; no run store",
"cx_detail": "—",
"catalog_supercode_today": "—",
"provenance": "cc§1; cc§5",
"status": "absent",
"evidence": [],
"note": "supercode holds no fire record for a Claude Code job. Claude Code keeps no run store at all — a `CronCreate` fire is an ordinary turn inside the session that created the job — and supercode does not fire one either: a resumed session's crons and wakeups are carried in the runtime manifest as a record and never executed (`ClaudeRuntimeManifest`, `jobs.list --harness claude-code`). ORCH-8 added the read verb this row asks for (`harness.v1.runs.list|get`, `supercode runs list|get`), but `claude-code` is deliberately not one of its harnesses: the verb refuses with `UnsupportedAction` naming the harnesses that do keep a store, rather than reconstructing fires from turns, which would be supercode's inference and not Claude Code's record. Compiling those jobs into a scheduler that does record fires is `supercode orchestrator import --from claude-session <id>`, and the fires it produces are the ORCHESTRATOR's, listed under that harness. Codex has no scheduled job at all, so the `cx` column stays `—`. This row can only close if Claude Code itself starts recording fires.",
"cost": "architectural"
},
{
"id": "conversation-surface-key-and-scope",
"domain": 11,
"domain_name": "Orchestration & automation",
"capability": "Conversation: surface key + scope",
"semantics": "A conversation is addressed by an explicit key and carries a declared scope/expiry policy",
"cc": "variant",
"cx": "variant",
"cc_detail": "✓*²³ session id under a cwd-derived project dir; `cleanupPeriodDays` window",
"cx_detail": "✓*²³ thread id + cwd in `state_5.sqlite`; `archived_sessions/`",
"catalog_supercode_today": "partial (`SessionInfo.name` + `prune_expired`, store.rs:19-27, 1143)",
"provenance": "cc§5; cx§5; oc§5; pi§5",
"status": "partial",
"evidence": [
{
"kind": "code",
"path": "crates/harness/src/store.rs",
"symbol": "pub struct SessionInfo {"
},
{
"kind": "code",
"path": "crates/harness/src/store.rs",
"symbol": "pub fn prune_expired("
}
],
"note": "supercode's own conversations key on a store-unique NAME and expire by a retention window (`prune_expired`, falling back to `core.session.retention_days`) — the same shape as Claude Code's cwd-scoped session id + `cleanupPeriodDays` and Codex's thread id + `archived_sessions/`. What is missing is the KEY as a modelled noun: `SessionInfo` carries name/title/archived/tier and no cwd, project, workspace or surface tuple, so a listed session cannot be addressed by where it came from, and scope is an implicit global default rather than a per-conversation policy field (plan S3/O3)."
},
{
"id": "conversation-new-reset-archive-delete",
"domain": 11,
"domain_name": "Orchestration & automation",
"capability": "Conversation: new/reset/archive/delete",
"semantics": "Start a new, reset, archive or delete a conversation through the harness's own verb",
"cc": "variant",
"cx": "yes",
"cc_detail": "✓* `/clear` (`/new`, `/reset`); delete is a 30-day retention window, no archive",
"cx_detail": "✓ `codex archive|unarchive|delete`, `/new`",
"catalog_supercode_today": "partial (`SessionStore::archive`/`delete`/`prune_expired`, store.rs:534, 587, 1143; `SessionAction::Archive`, cli/main.rs:1082)",
"provenance": "cc§5; cx§5; oc§5; pi§5",
"status": "partial",
"evidence": [
{
"kind": "code",
"path": "crates/harness/src/store.rs",
"symbol": "pub fn archive(&self, name: &str) -> Result<()> {"
},
{
"kind": "code",
"path": "crates/harness/src/store.rs",
"symbol": "pub fn delete(&self, name: &str) -> Result<()> {"
}
],
"note": "Archive and delete exist on supercode's OWN store (`sessions archive|delete|prune`, the D5 `archive-delete-lifecycle-retention` row). Two halves are missing: there is no `new`/`reset` verb (a fresh conversation is a fresh `resume`/`run` invocation, not a conversation-lifecycle call), and none of these verbs is routed through the HARNESS's own door — archiving a Codex thread still means running `codex archive` by hand, and `/clear` on a driven Claude Code session is not reachable (plan C2)."
},
{
"id": "pending-request-list",
"domain": 11,
"domain_name": "Orchestration & automation",
"capability": "Pending request: list",
"semantics": "Enumerate the permission/approval requests currently awaiting an answer",
"cc": "variant",
"cx": "variant",
"cc_detail": "✓*²⁴ live prompt + `PermissionRequest` hook",
"cx_detail": "✓*²⁴ live prompt + `/approve`",
"catalog_supercode_today": "partial (`FrontendRequestBroker::publish` + attach replay, server.rs:346-390)",
"provenance": "cc§4; cx§4; oc§4; pi§4",
"status": "partial",
"evidence": [
{
"kind": "code",
"path": "crates/harness/src/approvals.rs",
"symbol": "pub fn classify_live_request("
},
{
"kind": "code",
"path": "crates/harness/src/harness_service.rs",
"symbol": "harness.v1.approvals.list"
},
{
"kind": "code",
"path": "crates/harness/src/server.rs",
"symbol": "fn publish(&self, request: &FrontendRequest) -> bool {"
}
],
"note": "ORCH-9 (observed tier): `harness.v1.approvals.list` / `supercode approvals list` enumerate outstanding requests in one uniform row, over supercode's own frontend broker envelope and over every driven runtime that can carry a protocol request — including Codex's app-server `*Approval` reverse requests, so a `cx-parity` session's pending approvals are addressable by id, with the answers the door accepts. Since ORC-2 that includes Claude Code's stream-json `can_use_tool` control request, so `--harness claude-code` lists like every other driven door (docs/interop/research/orc2-claude-respond-receipt-2026-09-04.json). STILL PARTIAL on one count: a request raised in a session supercode does not drive is still invisible — there is no stored pending-request queue in any harness to read, so the live request IS the only source."
},
{
"id": "pending-request-resolve",
"domain": 11,
"domain_name": "Orchestration & automation",
"capability": "Pending request: resolve",
"semantics": "Answer one outstanding request (allow once/always/deny) from an attached surface",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ interactive approval UI (+`--permission-prompt-tool`)",
"cx_detail": "✓ interactive approval (+`/approve` retry)",
"catalog_supercode_today": "partial (`RpcEngine::respond`, server.rs; every driven door including Claude Code's `can_use_tool`, adapters.rs; allow-always/rule-saving absent everywhere)",
"provenance": "cc§4; cx§4; oc§4; pi§4",
"status": "partial",
"evidence": [
{
"kind": "code",
"path": "crates/harness/src/server.rs",
"symbol": "pub fn respond(&self, response: FrontendResponse) -> Result<(), FrontendRuntimeError> {"
},
{
"kind": "runtime",
"capability": "respond_to_requests"
},
{
"kind": "code",
"path": "crates/harness/src/runtime/adapters.rs",
"symbol": "\"--permission-prompt-tool\".into(),"
},
{
"kind": "code",
"path": "crates/harness/src/approvals.rs",
"symbol": "fn claude_code_request(payload: &Value) -> Option<LiveRequest> {"
}
],
"note": "`respond` resolves one pending interactive request exactly once and is wired through the ACP, opencode, pi, Codex AND Claude Code doors. ORC-2 closed the Claude Code hole: the backend launches `claude` as the CLI's own permission handler (`--permission-prompt-tool stdio`), the inbound `control_request{subtype:can_use_tool}` lists as a pending approval row, and `harness.v1.runtimes.respond` answers it with the permission result the CLI's own validator accepts (`{behavior:'allow'}` / `{behavior:'deny',message}`); an unanswered request is denied on the adapter's own bound, because the CLI has none. Measured end to end against claude 2.1.258 with a mock base URL and an isolated CLAUDE_CONFIG_DIR (zero paid spend): `approvals.resolve <id> allow_once` ran the blocked Bash tool and `deny` blocked it — docs/interop/research/orc2-claude-respond-receipt-2026-09-04.json. STILL PARTIAL on one count, unchanged on every door: allow-always/rule-saving. Claude Code expresses it as an `updatedPermissions` array carrying the request's own `permission_suggestions` (measured in the same receipt: a suggestion echoed back with `destination:'session'` suppressed the second prompt), which the uniform `(door, options, decision)` translation does not carry, so `allow_always` is refused by name with `allow` and `deny` listed."
},
{
"id": "profile-list-get",
"domain": 11,
"domain_name": "Orchestration & automation",
"capability": "Profile: list/get",
"semantics": "Enumerate the named config homes/agents and read one's settings",
"cc": "no",
"cx": "yes",
"cc_detail": "—²⁵",
"cx_detail": "✓ `-p/--profile` files + legacy `[profiles]`; app-server `permissionProfile/list`",
"catalog_supercode_today": "partial (`ConfigFile::from_profile_file`, config.rs:326-374)",
"provenance": "cx§6; cx§7",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/harness/src/profiles.rs",
"symbol": "pub fn list_profiles("
},
{
"kind": "code",
"path": "crates/harness/src/profiles.rs",
"symbol": "fn codex_rows("
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "fn profiles_list_cmd("
}
],
"note": "ORCH-10: `harness.v1.profiles.list|get` and `supercode profiles list|show` enumerate Codex's OWN profiles — the `[profiles.<name>]` tables in `$CODEX_HOME/config.toml`, with the top-level `profile = \"<name>\"` key naming the default and each table's `model` reported as the pin — beside supercode's presets, which are its analog of the same noun. Claude Code has no profile concept and is refused with `unsupported_action`, which is the row's cc column. Two neighbouring rows carry the rest: profile SELECTION at launch (`-p/--profile`) is the D6 `named-profiles` row, and the app-server's `permissionProfile/list` view of `[permissions.<name>]` bundles is the D4 `named-permission-profiles` row."
},
{
"id": "profile-create-delete",
"domain": 11,
"domain_name": "Orchestration & automation",
"capability": "Profile: create/delete",
"semantics": "Create or remove a named config home through the harness's own door",
"cc": "no",
"cx": "variant",
"cc_detail": "—²⁵",
"cx_detail": "✓* author/remove `$CODEX_HOME/<name>.config.toml` (file-authored; no CLI verb)",
"catalog_supercode_today": "✓* `[profiles.<name>]` blocks, file-authored (config.rs:326-374)",
"provenance": "cx§6",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/harness/src/config.rs",
"symbol": "pub fn from_profile_file("
}
],
"note": "Parity holds at the door Codex actually provides: a Codex profile is CREATED by writing `$CODEX_HOME/<name>.config.toml` and DELETED by removing it — there is no `codex profile create|delete` verb — and a supercode profile is created and removed exactly the same way, as a `[profiles.<name>]` block loaded by `from_profile_file`/`apply_profile`. Neither side has a CLI lifecycle verb, so this row is at parity; profile SELECTION is the gap and is the D6 `named-profiles` row."
},
{
"id": "skills-list",
"domain": 11,
"domain_name": "Orchestration & automation",
"capability": "Skills: list",
"semantics": "Enumerate the installed skill packages",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ `/skills` over the discovery roots",
"cx_detail": "✓ `/skills`; app-server `skills/list`",
"catalog_supercode_today": "—",
"provenance": "cc§7; cx§7; oc§7; pi§2",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/harness/src/skills.rs",
"symbol": "pub fn list_skills("
},
{
"kind": "code",
"path": "crates/harness/src/skills.rs",
"symbol": "homes.claude_code.join(\"skills\")"
},
{
"kind": "code",
"path": "crates/harness/src/skills.rs",
"symbol": "homes.agents.join(\"skills\")"
},
{
"kind": "code",
"path": "crates/harness/src/skills.rs",
"symbol": "fn apply_codex_enablement("
},
{
"kind": "code",
"path": "crates/harness/src/harness_service.rs",
"symbol": "harness.v1.skills.list"
}
],
"note": "ORCH-11: `harness.v1.skills.list` / `supercode skills list` enumerate the installed skill packages over each harness's own discovery roots — Claude Code's managed root, personal `~/.claude/skills`, project `.claude/skills` in the working tree, and the installed plugin bundles under `plugins/cache`; Codex's `.agents/skills` chain from cwd to the repo root, `~/.agents/skills`, `$CODEX_HOME/skills`, `/etc/codex/skills` and the bundled `$CODEX_HOME/skills/.system` cache — with `SKILL.md` frontmatter parsed for name/description/version and Codex's `[skills]` overlay read for `enabled`. Read-only: this row is enumeration; installing and removing is `skills-install-remove`. The D1/D2 rows on invoking a skill body in supercode's OWN loop are separate and unchanged."
},
{
"id": "skills-install-remove",
"domain": 11,
"domain_name": "Orchestration & automation",
"capability": "Skills: install/remove",
"semantics": "Install or remove a skill package through the harness's own package door",
"cc": "yes",
"cx": "yes",
"cc_detail": "✓ plugins + marketplaces",
"cx_detail": "✓ `codex plugin add|remove` + `plugin marketplace`",
"catalog_supercode_today": "—",
"provenance": "cc§7; cx§7; oc§7; pi§7",
"status": "partial",
"evidence": [
{
"kind": "code",
"path": "crates/harness/src/skills_control.rs",
"symbol": "pub fn mutate_skill"
},
{
"kind": "code",
"path": "crates/harness/src/skills_control.rs",
"symbol": "fn directory_install"
},
{
"kind": "code",
"path": "crates/harness/src/skills_control.rs",
"symbol": "fn directory_remove"
},
{
"kind": "code",
"path": "crates/harness/src/skills.rs",
"symbol": "pub fn writable_skill_roots"
},
{
"kind": "code",
"path": "crates/harness/src/harness_service.rs",
"symbol": "harness.v1.skills.install"
}
],
"note": "ORCH-22 landed the SKILL-PACKAGE half. Neither Claude Code nor Codex publishes a skills CLI verb, so for both of them the door IS the directory their own loader reads: `harness.v1.skills.install|remove` and `supercode skills install|remove --harness X` copy a package holding SKILL.md into the inventory-cited root for the requested scope (`~/.claude/skills` and the working tree's `.claude/skills`; `~/.agents/skills` and `.agents/skills`) and delete it from there, confined to those roots — a name that would escape one, a source that is not a package, a symlink inside it, or a scope the harness owns (managed, plugin, bundled) all refuse. Receipt: docs/interop/research/orch22-claude-code-skills-receipt.json (both scopes, install -> `skills list` reports it -> remove -> gone). What is still missing is the PLUGIN half this row's cc/cx cells name: Claude Code's plugin/marketplace install and `codex plugin add|remove` bundle skills with commands, agents and MCP servers, which is the `plugin-packaging-marketplaces` row's subsystem, not a skill directory."
},
{
"id": "memory-show-search",
"domain": 11,
"domain_name": "Orchestration & automation",
"capability": "Memory: show/search",
"semantics": "Read and search the harness's persistent cross-session memory store",
"cc": "yes",
"cx": "no",
"cc_detail": "✓ `/memory` + auto-memory dir",
"cx_detail": "—²⁶",
"catalog_supercode_today": "—",
"provenance": "cc§2; cx§7; pi§2",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/harness/src/memory.rs",
"symbol": "pub fn show_memory("
},
{
"kind": "code",
"path": "crates/harness/src/memory.rs",
"symbol": "pub fn search_memory("
},
{
"kind": "code",
"path": "crates/harness/src/memory.rs",
"symbol": "fn claude_code_stores("
},
{
"kind": "code",
"path": "crates/harness/src/memory.rs",
"symbol": "fn claude_project_slug("
},
{
"kind": "code",
"path": "crates/harness/src/harness_service.rs",
"symbol": "harness.v1.memory.show"
},
{
"kind": "code",
"path": "crates/harness/src/harness_service.rs",
"symbol": "harness.v1.memory.search"
}
],
"note": "ORCH-12: `harness.v1.memory.show|search` and `supercode memory show|search --harness X` read Claude Code's Claude-maintained per-project auto-memory directory `<claude home>/projects/<encoded-cwd>/memory/` — the `MEMORY.md` index plus its topic files (`inventory/claude-code.md` §2 \"Auto memory\", `docs:memory#auto-memory`). The project is resolved from the enclosing git repository, which is the key Claude Code shares the directory across worktrees by; `--profile` names another project directory (or an absolute path, for an `autoMemoryDirectory` relocation), and `--session` picks the project directory holding that session's transcript. Read-only: `show` previews each document's head unless `--full` is given, `search` is a plain substring/regex scan with no index, and toggling or clearing auto memory stays Claude Code's `/memory`. Codex has no memory store at the pin, so this stays a cc-only row and `codex` is refused with UnsupportedAction rather than an empty list."
},
{
"id": "delivery-target-on-jobs-runs",
"domain": 11,
"domain_name": "Orchestration & automation",
"capability": "Delivery target on jobs/runs",
"semantics": "Where a job's or a turn's output is delivered (program, channel, webhook), declared on the job/run",
"cc": "variant",
"cx": "variant",
"cc_detail": "✓*²⁷ Notification hooks + PushNotification/SendUserFile",
"cx_detail": "✓*²⁷ `notify` argv (`agent-turn-complete`)",
"catalog_supercode_today": "partial (`notification` hook, cli/notify.rs; per-turn only)",
"provenance": "cc§1; cc§8; cx§6; oc§6",
"status": "partial",
"evidence": [
{
"kind": "code",
"path": "crates/cli/src/notify.rs",
"symbol": "crate::hooks::fire_notification("
},
{
"kind": "code",
"path": "crates/harness/src/jobs.rs",
"symbol": "pub struct JobDeliver"
},
{
"kind": "code",
"path": "crates/harness/src/runs.rs",
"symbol": "pub struct RunDelivery"
}
],
"note": "The per-TURN half — which is all Claude Code and Codex themselves have — exists: the `notification` hook fires at turn finish with kind/model/elapsed/summary. ORCH-13 added the row's own subject for the harnesses that HAVE it: `deliver` on a job row (target, chat, thread, account, mode) and `delivery` on a run row (target, state, attempts, last_error, delivered_at), read from Hermes's `delivery_obligations` ledger and OpenClaw's `cron_jobs` / `cron_run_logs` delivery columns. This row stays partial because of its own two columns: a Claude Code fire is a prompt injected back into the session that created it, so its `deliver` target is `session` and there is no destination, ledger or delivery outcome to read; Codex has no scheduled job at all. Neither can close until the harness itself records where a fire's output went."
},
{
"id": "channel-list-status",
"domain": 11,
"domain_name": "Orchestration & automation",
"capability": "Channel: list/status",
"semantics": "Enumerate the transports/accounts the harness is reachable on, with connection status",
"cc": "variant",
"cx": "no",
"cc_detail": "✓* channel MCP servers (session-scoped), `--channels`, `channelsEnabled`",
"cx_detail": "—",
"catalog_supercode_today": "—",
"provenance": "cc§7",
"status": "absent",
"evidence": [],
"note": "Nothing enumerates Claude Code's channels. ORCH-14 gave the noun a uniform read (`harness.v1.channels.list|status`), but only for the two gateway harnesses whose channels live in a config file; this row is cc-only and cc is not one of them. A Claude Code channel is an MCP server that declares the channel capability over the MCP protocol at connect time, and nothing in `settings.json` or `.mcp.json` marks a server as one — `channelsEnabled` and `allowedChannelPlugins` are enterprise GATES, not declarations. Telling a channel server from any other MCP server therefore needs the inbound channel contract first (plan O9); `channels list --harness claude-code` refuses with UnsupportedAction rather than guessing a key name. The D7 `external-notify-program-channels` row records the same hole from the inbound side.",
"cost": "architectural"
},
{
"id": "routing-list",
"domain": 11,
"domain_name": "Orchestration & automation",
"capability": "Routing: list",
"semantics": "Enumerate the surface→profile/agent bindings that decide who answers",
"cc": "no",
"cx": "no",
"cc_detail": "—",
"cx_detail": "—",
"catalog_supercode_today": "—",
"provenance": "— (absent from all four; orchestration inventory §4)",
"status": "not_applicable",
"evidence": [],
"note": "No core harness has surface→agent routing: a Claude Code or Codex session is opened directly, never dispatched to a profile by a channel tuple. Bindings are Hermes `gateway.profile_routes` and OpenClaw `bindings[]` only — outside the cc/cx parity program."
},
{
"id": "inbound-trigger-list",
"domain": 11,
"domain_name": "Orchestration & automation",
"capability": "Inbound trigger: list",
"semantics": "Enumerate the webhooks / mapped events that can OPEN a turn",
"cc": "variant",
"cx": "no",
"cc_detail": "✓* channels push messages/webhooks into a running session",
"cx_detail": "—",
"catalog_supercode_today": "—",
"provenance": "cc§7",
"status": "absent",
"evidence": [],
"note": "supercode has no inbound door at all: nothing outside the process can open a turn, so there is nothing to enumerate. Claude Code's channel servers are the only core-four form (the same mechanism as the channel row, seen from the trigger side); its lifecycle shell hooks are a different thing and live in D7. cc-only row.",
"cost": "architectural"
},
{
"id": "gateway-health",
"domain": 11,
"domain_name": "Orchestration & automation",
"capability": "Gateway health",
"semantics": "The harness's always-on runtime endpoint can be started and its liveness queried",
"cc": "variant",
"cx": "variant",
"cc_detail": "✓* `claude daemon` + agent view over the SDK server",
"cx_detail": "✓* `codex app-server` (+ daemon), `codex doctor` app-server check",
"catalog_supercode_today": "partial (`serve_cmd` + runtime registry, cli/main.rs; `probe_running_instance`, harness_service.rs:2700)",
"provenance": "cc§8; cc§10; cx§7; cx§10; oc§7",
"status": "partial",
"evidence": [
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "async fn serve_cmd("
},
{
"kind": "code",
"path": "crates/harness/src/harness_service.rs",
"symbol": "fn probe_running_instance("
}
],
"note": "supercode can start and reach its OWN endpoint (`serve` registers the runtime, `sessions list --live` finds it, `attach --connect` reaches it) and it does probe a running instance for daemon harnesses — but `probe_running_instance` covers only the orchestration harnesses' gateways (`probe_openclaw_running`, `probe_hermes_running`). For the two parity harnesses there is no health query at all: nothing connects to Claude Code's SDK server or Codex's app-server to report liveness, and `serve` itself is gated on `[capabilities.server]`, which both parity presets disable (plan O12)."
}
]