"front"	"back"	"tags"
"What is ZeroClaw's defining architectural principle (ADR-002)?"	"Trait-driven extensibility. The kernel depends ONLY on zeroclaw-api traits (ModelProvider, Channel, Tool, Memory, Observer, RuntimeAdapter, Peripheral) — never on concrete impls. Adding anything is a trait impl through a factory, not a core patch. Cleanest separation of concerns in the roster."	harness-engineering::dd16::recall
"Name the 6 layers of ZeroClaw's safety model in order."	"(1) Channel pairing/access control (allowed_users, allowed_chats, IP allowlists) (2) Autonomy level: readonly/supervised/full with risk-classified tools (3) Workspace boundary + path rules (workspace_only, forbidden_paths) (4) Shell command policy: allowlist BEFORE exec (5) OS-level sandbox: Landlock/Bubblewrap/Seatbelt/AppContainer/Docker (6) Tool receipts: HMAC-SHA256 over calls+results."	harness-engineering::dd16::recall
"How does ZeroClaw's safety layer interact with the model in the agent loop?"	"Security runs BETWEEN the model emitting a tool call and the tool executing. A block surfaces as ToolResult::Err — the model sees it and can react. NOT a silent failure. The model cannot bypass shell policy (runs before exec) or receipts (computed by the harness, not the model). The loop: Channel -> Runtime.deliver_message -> Provider.chat -> Security.validate(tool_call) -> Tool.invoke -> result back to Provider."	harness-engineering::dd16::analysis
"What is ZeroClaw's system-prompt philosophy and what tradeoff does it imply?"	"No hidden system prompts injecting personality. 'The model sees what you configure.' Tool descriptions are Fluent-localized and deliberately terse. Sharply contrasts with opinionated harnesses shipping multi-thousand-token hidden prompts. TRADEOFF: power and transparency in exchange for more operator burden — there is no hidden prompt doing the work for you. Responsibility for prompt behavior on the operator."	harness-engineering::dd16::recall
"How many LLM providers does ZeroClaw support, and how does the trait-driven kernel make this possible?"	"25+ provider slots. Native trait impls (anthropic, openai, ollama, bedrock, gemini, azure_openai, copilot, glm, etc.) plus compatible.rs OpenAI-compatible shim reused by 20+ vendors (Groq, Mistral, xAI, Venice, OpenRouter). Per-vendor OAuth. reliable.rs for retry/key-rotation. router.rs for per-call model routing. The trait-driven kernel makes this possible: each provider is a ModelProvider trait impl — no core bloat, no provider-specific code in the kernel."	harness-engineering::dd16::recall
"What is the thickness contradiction in ZeroClaw, and how is it being resolved?"	"Stated philosophy: thin harness (single binary, no telemetry, no hidden prompts). Reality: ~700-800k Rust LOC, 1015 files, ~26 MiB binary. Config schema alone is 1.3 MB. The hardware/GPIO/SPI/USB support is thickness most thin harnesses don't carry. RFC #5574 (microkernel refactor) is actively closing the gap by factoring functionality behind feature flags. Honest framing: thin by design and default-surface, currently medium-sized, in-flight refactor to re-thin."	harness-engineering::dd16::analysis
"What are tool receipts, what attack do they defend against, and what is their limitation?"	"HMAC-SHA256 over successful tool calls + results, fed back into conversation. Purpose: defend against the FABRICATED-TOOL-CLAIM attack (Module 11) — if the model says 'the file says X' but no receipt exists for that file_read, the harness can flag it. The model cannot credibly claim a tool returned data it did not, because the receipt is in-context evidence. LIMITATION: keys are ephemeral, so receipts are NOT yet a chained/durable audit log."	harness-engineering::dd16::analysis
"What is ZeroClaw's memory design rule and what security property does it provide?"	"Prompt context, tool output, files, and logs are NOT durable memory by default. A turn only becomes memory if the agent calls memory_store EXPLICITLY. Backends: SQLite (default), Postgres, Qdrant, Markdown. SECURITY PROPERTY: an indirect injection cannot silently persist itself — the agent cannot write to durable memory without an explicit tool call. This is the opposite of Hermes's model-initiated-free-writes (DD-08): ZeroClaw trades compounding capability for a smaller poisoning surface."	harness-engineering::dd16::analysis
"What is ZeroClaw's rubric score and where does it win/lose?"	"34/60. WINS on Module 6 Permission/Safety (5/5): the 6-layer model is the deepest in the thin-harness category. WINS on Module 5 Sandbox (4/5): auto-detects OS-level sandboxes. WINS on Module 12 Prompt (4/5): minimal-prompt philosophy, operator-owned. LOSES on Module 3 Context (2/5): no sophisticated context-budget system, just basic history trimming. LOSES on Module 9 Verification (2/5): limited."	harness-engineering::dd16::analysis
"Describe the workspace Cargo layout of ZeroClaw."	"Three layers. CORE: zeroclaw-runtime (loop, security enforcement, SOP engine, cron, SubAgent lifecycle), zeroclaw-config (TOML + encrypted secrets + autonomy levels), zeroclaw-api (kernel ABI — public traits). EDGE: zeroclaw-providers (25+ LLM clients), zeroclaw-channels (30+ messaging), zeroclaw-gateway (REST/WebSocket/dashboard/webhook), zeroclaw-tools (browser, HTTP, hardware probes). SUPPORT: zeroclaw-memory, zeroclaw-plugins (WASM), zeroclaw-hardware (GPIO/I2C/SPI/USB), zeroclaw-log."	harness-engineering::dd16::recall
"How does ZeroClaw's autonomy level work, and how are tools risk-classified?"	"Three levels: readonly, supervised (default), full. Tools are RISK-CLASSIFIED: low-risk tools run automatically, medium-risk tools ask the operator for approval, high-risk tools are blocked. This is Module 6's risk-tiering principle applied per-tool — not one gate for all actions, but a risk-calibrated cascade. The classification lets the operator tune the autonomy/safety tradeoff per deployment."	harness-engineering::dd16::application
"Why is the shell command policy implemented BEFORE the shell, not after?"	"This is the correct layer for shell injection defense: block at the policy gate (allowed_commands allowlist), not detect at the audit log. The pattern-matcher runs BEFORE the shell executes the command. Detect-after-exec is too late — the command has already run. ZeroClaw's design blocks the disallowed command before any subprocess is spawned, which is the defense-in-depth principle applied at the right layer."	harness-engineering::dd16::analysis
"What is the outbound leak detector and what does it defend against?"	"A high-entropy-token heuristic that scans outbound traffic for secrets. It is a CREDENTIAL-EXFILTRATION defense — it catches secrets on the way out, which most harnesses never check. Combined with encrypted secrets in zeroclaw-config (decrypted at runtime, never logged), this gives ZeroClaw a credential-defense posture most harnesses lack. It complements the tool receipts (which defend integrity) with an exfiltration defense."	harness-engineering::dd16::analysis
"Compare ZeroClaw's memory design to Hermes's (DD-08). What is the trade?"	"Hermes (DD-08): model-initiated free writes — the agent writes to memory freely, enabling compounding capability (self-evolving skills) but creating a larger poisoning surface. ZeroClaw: explicit-only memory — the agent must call memory_store explicitly, shrinking the poisoning surface (an indirect injection cannot silently persist) but sacrificing the compounding capability. The trade is capability vs. security. Both are defensible; the choice depends on whether the deployment values compounding or hardening more."	harness-engineering::dd16::analysis
"What extra gates does ZeroClaw ship beyond the 6 layers?"	"OTP gating per action, emergency stop (zeroclaw estop), prompt-injection guard, outbound leak detector with high-entropy-token heuristic, device pairing guard. Approval routing can redirect to a separate 'approver channel' with fail-closed semantics. These compose with the 6 layers — the cascade is extensible, and the default config ships a conservative posture."	harness-engineering::dd16::recall
"Why is 'thin harness means small codebase' an anti-pattern when reading ZeroClaw?"	"ZeroClaw is uncompromisingly thin by PHILOSOPHY (single binary, no telemetry, no SaaS, no hidden prompts) but medium-thick by IMPLEMENTATION: ~700-800k Rust LOC across 1015 files. The hardware/GPIO/SPI/USB support and 25+ provider slots are thickness most thin harnesses don't carry. Cure: read 'thin' as a design INTENT, not a LOC count. RFC #5574 is closing the gap by factoring functionality behind feature flags."	harness-engineering::dd16::analysis
"Why is 'tool receipts are a complete audit log' an anti-pattern?"	"The tool-receipt system (HMAC-SHA256 over successful tool calls) addresses the fabricated-tool-claim attack, but it uses EPHEMERAL keys. It is NOT yet a chained, cross-signed, durable audit log. Cure: treat receipts as an in-context integrity signal TODAY, and implement the durable audit log (fix #2) before relying on them for post-hoc forensics. The receipt proves the tool ran; it does not prove it to a third party after the session ends."	harness-engineering::dd16::analysis
"What is RFC #5574 and why does it matter?"	"The 'microkernel roadmap' — an active refactor shrinking zeroclaw-runtime so the kernel is just loop + policy, with everything else behind feature flags. The foundation reportedly builds with --no-default-features. It matters because it closes the thickness gap between ZeroClaw's thin philosophy and its medium-thick implementation. When complete, the default-surface will be genuinely thin, with providers/channels/hardware as opt-in features."	harness-engineering::dd16::application
"What are the 3 things ZeroClaw does better and the 3 things to fix?"	"BETTER: (1) Trait-driven kernel — cleanest separation of concerns; adding anything is a trait impl. (2) 6-layer safety — deepest safety surface in the thin-harness category. (3) Provider agnosticism — 25+ slots with routing, retry, key rotation, per-vendor OAuth. TO FIX: (1) Close the microkernel gap — ~700k LOC contradicts the thin philosophy. (2) Durable audit log — tool receipts use ephemeral keys. (3) Context management — basic history trimming is insufficient; add turn-boundary trimming and a context-budget system."	harness-engineering::dd16::recall
"When should you build on ZeroClaw, per the architect's verdict?"	"Build on ZeroClaw when Rust-native safety, provider agnosticism, and self-hosting are requirements. The trait-driven kernel makes it the most extensible thin harness for custom tool/channel development. It optimizes for engineering discipline (no hidden prompts, 6-layer safety, operator ownership). It is thin by intent but medium-thick by implementation (~700k LOC), with an active microkernel refactor closing the gap."	harness-engineering::dd16::application