"Why is a single monolithic offensive harness the wrong architecture across multiple domains?"	"Three compounding reasons: (1) Context pollution — every tool description loaded into every session dilutes tool-selection signal. (2) Reasoning drift — a model good at exploit dev AND broad fuzzing is excellent at neither. (3) Token waste — six domains of overhead paid every turn. Cure: meta-harness routing to specialized sub-harnesses."	c2a::s05::analysis
"What is a meta-harness, and what does it NOT do?"	"A thin orchestration layer that classifies tasks, selects sub-harnesses, aggregates telemetry, and controls cost. It does NOT implement offensive capability itself — sub-harnesses do that. It owns only what is true regardless of which sub-harness is executing."	c2a::s05::recall
"What is CSI (Common Scaffold Interface)?"	"Alias Robotics' scaffold combiner. Routes between CAI, Claude Code, Codex CLI, and other harnesses through a LOCAL PROXY. CSI does not implement offensive capability — it routes. The proxy is the only endpoint any sub-harness can reach."	c2a::s05::recall
"Why is the local proxy the load-bearing design decision in CSI?"	"Every sub-harness (CAI, Claude Code, Codex CLI) talks to the same proxy endpoint, regardless of native tool-calling format/model provider/auth. The proxy owns security primitives, scope, evidence, rate limiting. A sub-harness CANNOT bypass it — proxy is the only thing it can reach. You cannot modify sub-harness internals; the proxy is the wrap."	c2a::s05::analysis
"Name the four responsibilities of the meta-harness."	"(1) Task classification — read task, emit domain label (S04.1 meta-agent pattern, allowed to be uncertain). (2) Harness selection — deterministic lookup: domain → sub-harness + prompt + tools + HITL posture. (3) Telemetry aggregation — one ledger per engagement regardless of sub-harness. (4) Cost control — per-engagement budget; re-route, degrade, or halt when exhausted."	c2a::s05::recall
"Why is harness selection a lookup table and not a model call?"	"Once task classification is done, the mapping from domain label to sub-harness configuration is deterministic. A bug bounty task → S02 harness. A CTF task → S04 harness. A code-review task → Codex CLI. No second model call needed — classification is the only model decision; selection is mechanical."	c2a::s05::analysis
"Why can't cost control live in a sub-harness?"	"A sub-harness only sees its OWN consumption. Only the meta-harness sees the TOTAL across all sub-harnesses running in an engagement. Cost control requires the aggregate view — tokens, dollars, wall-clock across CAI + Claude Code + Codex CLI combined."	c2a::s05::analysis
"What is the shared engagement context, and who owns it?"	"One scope file (S00.3), one RoE, one engagement memory handle (S02.1), one engagement_id. Owned by the meta-harness, loaded once at engagement start, passed by reference. Sub-harnesses BORROW it (read-only), never own it. Prevents 'three harnesses, three scope files' drift."	c2a::s05::recall
"What failure does shared engagement context prevent?"	"The 'three harnesses, three scope files' problem. If each sub-harness loads its own scope, they drift. Drifted scope = out-of-scope tool calls. Cure: ONE scope file, owned by meta-harness, read-only to every sub-harness."	c2a::s05::application
"Why must the evidence log be meta-harness-owned rather than sub-harness-owned?"	"If each sub-harness writes its own evidence: three logs, three schemas, three hash chains — unreconcilable, useless for legal defense. Meta-harness-owned: ONE log, one schema, one engagement_id, one hash chain. A finding from CAI and one from Claude Code land in the same log. Client query = single lookup. Sub-harnesses don't even know the log exists; proxy writes transparently."	c2a::s05::analysis
"Name the five security primitives that MUST live at the meta-harness level."	"(1) Scope enforcement — every outbound call checked vs scope.json. (2) Evidence collection — every call logged, hash-chained, scope_ref stamped. (3) Kill chain state — phase-appropriate gating (recon→exploit→post-exploit). (4) Signal/noise filtering — one triage pipeline for all sub-harness findings. (5) RoE enforcement — rate caps + prohibited actions at the proxy."	c2a::s05::recall
"Why can't the five security primitives be delegated to sub-harnesses?"	"You do NOT control the sub-harnesses. CAI has its own scope model; Claude Code has none; Codex CLI has no concept of scope. A sub-harness update can silently remove a primitive. Only way to guarantee every outbound call is scope-checked, evidence-logged, RoE-compliant, triaged consistently = enforce at the ONE choke point every sub-harness passes through: the proxy."	c2a::s05::analysis
"How does the security primitive middleware wrap a sub-harness without modifying its code?"	"Sub-harness emits tool call → middleware intercepts → 3 gates (scope, RoE, kill chain) → execute via sub-harness's OWN executor → evidence log → triage finding if present → cost accounting → structured result back. Sub-harness sees only the result; it has no idea primitives ran. Primitives are NOT in sub-harness's code path → cannot be removed by sub-harness update."	c2a::s05::application
"What are the three gates that run before a sub-harness tool call executes?"	"(1) Scope check — target::action in scope.json? (2) RoE check — action prohibited? would it exceed rate cap? (3) Kill chain gate — action permitted in current phase (e.g., post-exploit needs confirmation even in CTF)? Any gate failing → BLOCKED, scope_ref stamped, block logged."	c2a::s05::recall
"Name the six benchmarking metrics for an offensive harness."	"(1) Detection rate — of seeded vulns, how many found. (2) Exploit success rate — of detected, how many exploitably SHOWN (not just asserted). (3) False positive rate — of surfaced, how many not real. (4) Evidence completeness — of findings, chain complete + reproducible. (5) Time-to-first-finding — wall-clock. (6) Cost per finding — dollars (tokens + compute) / confirmed findings."	c2a::s05::recall
"What is InjecAgent, and why is it a pass/fail gate rather than a performance metric?"	"A benchmark suite for adversarial injection against agent tool-calling — tests whether agent executes injected actions from target output. Pass/fail gate because the failure mode is CATASTROPHIC: a harness that executes injected commands will exfiltrate scope, modify evidence, or call out-of-scope systems. One injected command executed = FAIL, regardless of six-metric scores."	c2a::s05::analysis
"Why must InjecAgent run BEFORE benchmarking offensive performance?"	"A harness that benchmarks well on detection/exploit/FPR but fails InjecAgent is a harness that will betray you in production — it executes attacker-controlled actions from target output. S01.3 reader-actor separation and S02.1 structured-summary-only memory are the defenses; InjecAgent proves they work. Fix injection resistance first, then benchmark."	c2a::s05::application
"Name the three published baselines and when each applies."	"(1) CAI CTF benchmarks — validate S04 router + CTF sub-harness solve rate. (2) EVMbench — smart contract work, when meta-harness routes to smart-contract sub-harness; measures detection + FPR on labeled vulnerable contracts. (3) RedTeamLLM CTF results — competitive baseline for offensive reasoning quality."	c2a::s05::recall
"What is the point of comparing against published baselines?"	"NOT to beat the published number — to confirm same order of magnitude and identify systematic gaps. A harness scoring 40% detection where baseline scores 85% has an ARCHITECTURE problem, not a tuning problem. Baselines reveal whether the gap is tuning or structural."	c2a::s05::analysis
"Name the four properties of a repeatable benchmark lab."	"(1) Isolated targets — Docker/VMs with seeded vulns, no live targets (they change, invalidating baseline). (2) Seeded vulnerabilities — documented vuln set per target; findings scored against it. (3) Consistent scoring methodology — same scoring script every version. (4) Fixed compute envelope — same model, same token budget, same wall-clock. Higher score via 3x compute ≠ better, just more expensive."	c2a::s05::application