"front"	"back"	"tags"
"What is PicoClaw's defining architectural contribution?"	"Hardware-native tools: i2c, spi, and serial tools in pkg/tools/hardware/ that let the agent directly read sensors and drive peripherals on physical hardware. The ONLY harness in the roster with this capability. From Sipeed (RISC-V/AI-camera hardware company)."	harness-engineering::dd17::recall
"What language is PicoClaw and what hardware does it target?"	"Go single-binary. Cross-compiles to x86_64, ARM64, MIPS, RISC-V, LoongArch. Runs on $10 SBCs (Sipeed LicheeRV Nano, MaixCAM). Co-branded LicheeRV-Claw board sold on AliExpress. Android APK also shipped."	harness-engineering::dd17::recall
"How does PicoClaw's append-only JSONL memory work?"	"Two files per session: {key}.jsonl (one message per line) + {key}.meta.json (summary, truncation offset). Messages NEVER physically deleted — TruncateHistory bumps a skip offset in meta.json. 64 sharded mutexes for concurrency. Crash-safe: append-only writes never corrupt existing lines; a partial line on crash is ignored on recovery."	harness-engineering::dd17::recall
"Why is PicoClaw described as 'thin agent kernel, thick ecosystem'?"	"Kernel: tiny Markdown prompts (SOUL.md 351 bytes, AGENT.md 1278 bytes), ~22 tools, append-only JSONL. Ecosystem: 20+ channels, 10+ providers, MCP client, skills marketplace, subagents, cron, hooks, React dashboard, voice, WebRTC. Thin at runtime (runs on $10 hardware), thick in codebase (~218k LOC, 868 files). The two layers are DECOUPLED — edge builds shed the ecosystem."	harness-engineering::dd17::analysis
"What is the MaixCAM channel?"	"A TCP-socket channel for Sipeed MaixCAM AI cameras. MaixCAM sends image frames over TCP; PicoClaw analyzes them using vision models. The agent acts as a vision/IoT backend on the hardware. This is part of the hardware ecosystem play."	harness-engineering::dd17::recall
"What is PicoClaw's relationship to OpenClaw and NanoBot?"	"NOT a fork. Explicitly states independence. 'Inspired by' HKUDS/nanobot (~4k-LOC Python agent). Ships an OpenClaw migration tool in-repo (pkg/migrate/sources/openclaw/) — actively pulling users from the heavyweight flagship."	harness-engineering::dd17::analysis
"What is the novel hardware attack surface, and why is the confirm gate insufficient?"	"I2C/SPI/Serial access means a compromised agent can physically interact with hardware. The confirm gate on WRITES is necessary but insufficient: a prompt-injected agent can silently READ sensors and ENUMERATE devices without a write. Reads are UNGATED. The fix: ZeroClaw-level autonomy gating (DD-16) on ALL hardware interactions, not just writes."	harness-engineering::dd17::analysis
"What is the honest <10MB RAM claim?"	"The README itself now hedges: 'Recent builds may use 10-20MB RAM. Resource optimization is planned after feature stabilization.' Boot is still sub-second on 0.6GHz hardware (solid). But memory optimization hasn't happened yet — feature stability comes first. The <10MB claim is aspirational, not current."	harness-engineering::dd17::recall
"What is turn-boundary trimming and why does it matter?"	"trimHistoryToFitContextWindow cuts at safe Turn boundaries so a tool-call sequence (assistant+ToolCalls → tool results) is NEVER split. Splitting mid-sequence breaks the model — orphaning a tool_call from its result confuses the LLM. Same insight as Hermes's context management, implemented in Go. PicoClaw pays the cost of doing it right."	harness-engineering::dd17::analysis
"What is the LoCoMo benchmark and why is it notable?"	"PicoClaw ships cmd/membench — a memory benchmark harness using the LoCoMo (long-conversation) benchmark. They actually EVALUATE their own memory layer instead of asserting it works. Rare discipline for a project this young (pre-1.0). Most harnesses this age claim their memory works; PicoClaw measures it."	harness-engineering::dd17::recall
"What are PicoClaw's security gaps?"	"Pre-1.0 (v0.2.9). README warns 'do not deploy to production.' macOS isolation NOT implemented (honest: surfaces as unsupported config). Main picoclaw process UNSANDBOXED on every platform (child-process sandbox only). Hardware read path ungated. 'There may be unresolved security issues.'"	harness-engineering::dd17::analysis
"What is PicoClaw's rubric score and where does it win/lose?"	"28/60. WINS on Module 2 Tools (4/5): hardware-native I2C/SPI/Serial — unique. WINS on Module 3 Context (4/5): turn-boundary trimming + context-budget check. LOSES on Module 5 Sandbox (2/5): no macOS isolation, main process unsandboxed. LOSES on Module 9 Verification (2/5): limited."	harness-engineering::dd17::analysis
"What are the I2C/SPI validation rules in PicoClaw's hardware tools?"	"I2C addresses validated to 7-bit (range 0x03-0x77). Per-transaction byte caps: 256 bytes for I2C, 4096 bytes for SPI. SPI supports Modes 0-3. Hardware writes require confirm: true (operator approval). Per-OS implementations (i2c_linux.go, spi_linux.go, serial_darwin.go)."	harness-engineering::dd17::recall
"How does the context-budget check work in PicoClaw?"	"Proactive check BEFORE calling the LLM. isOverContextBudget() sums: message tokens + tool-definition tokens + output reserve. If over budget, trimHistoryToFitContextWindow cuts at Turn boundaries. This is the same insight as Hermes's context management — never split a tool-call sequence from its results."	harness-engineering::dd17::application
"Why is 'ultra-lightweight means tiny codebase' an anti-pattern when reading PicoClaw?"	"PicoClaw is marketed as ultra-lightweight, and the runtime footprint IS small (sub-second boot on 0.6GHz hardware). But the Go codebase is 868 files, ~218k LOC. 'Ultra-lightweight' describes the RUNTIME FOOTPRINT, not the codebase size. Cure: read it as a deployment claim (runs on $10 hardware), not a code-organization claim."	harness-engineering::dd17::analysis
"Why is 'hardware tools are just another tool category' an anti-pattern?"	"I2C/SPI/Serial are NOT just another tool category — they create a novel attack surface no other harness has. A compromised agent can physically interact with hardware: read sensors, enumerate devices, drive peripherals. The confirm gate on writes is necessary but insufficient (reads are ungated). Cure: treat hardware tools as a distinct risk class needing ZeroClaw-level autonomy gating (DD-16)."	harness-engineering::dd17::analysis
"Why is 'pre-1.0 means it is almost ready' an anti-pattern?"	"The README itself warns 'Do not deploy to production before v1.0' and notes 'unresolved security issues.' v0.2.9. macOS isolation absent. Main process unsandboxed. Read pre-1.0 literally. Cure: PicoClaw's value is the edge/hardware bet, not production security. Do not deploy where security matters until v1.0 ships AND the sandboxing gaps close."	harness-engineering::dd17::analysis
"What are the 3 things PicoClaw does better?"	"(1) Hardware-native tools: I2C/SPI/Serial — the only harness that reads sensors and drives peripherals. (2) Edge deployment: cross-compiles to RISC-V/MIPS/LoongArch, runs on $10 SBCs, co-branded LicheeRV-Claw. (3) Memory benchmarking: ships cmd/membench using LoCoMo — actually evaluates its own memory layer (rare discipline)."	harness-engineering::dd17::recall
"What are the 3 things PicoClaw needs to fix?"	"(1) Security: pre-1.0 with acknowledged gaps; macOS isolation absent; main process unsandboxed. (2) Hardware tool safety: I2C/SPI access needs ZeroClaw-level autonomy gating on ALL interactions, not just writes — reads are currently ungated. (3) Memory footprint: 10-20MB actual vs <10MB claimed; optimize after feature stabilization."	harness-engineering::dd17::recall
"What is PicoClaw's multi-layer permission model?"	"(1) restrict_to_workspace (path jail for file tools). (2) Shell deny/allow patterns (regex gating). (3) pkg/isolation/ (bwrap on Linux, restricted token + Job Object on Windows, macOS NOT implemented). (4) allow_from per channel (identity gate). (5) Hooks: observer (500ms), interceptor (5s), approval (60s). (6) .security.yml + sensitive-data filtering (v0.2.4)."	harness-engineering::dd17::recall
"When should you build on PicoClaw, per the architect's verdict?"	"Build on PicoClaw for hardware/IoT work where the agent must interact with physical devices — it is the only harness that offers this. Do NOT build on it for security-sensitive deployments: it is pre-1.0 with acknowledged security gaps (macOS isolation absent, main process unsandboxed, hardware reads ungated)."	harness-engineering::dd17::application
"How does TruncateHistory work without physically deleting messages?"	"TruncateHistory bumps a skip offset in {key}.meta.json. The messages stay in the .jsonl file but are skipped on read. This is crash-safe: append-only writes never corrupt existing lines, and logical truncation (skip offset) avoids the risk of file mutation. A process kill mid-write loses at most one line (a partial line is ignored on recovery)."	harness-engineering::dd17::analysis