"front"	"back"	"tags"
"Name Pi's 4 tools and why the set is deliberately small."	"bash, read_file, write_file, search. The minimal capable set. The Vercel finding (Module 2: cutting 80% of tools IMPROVED selection accuracy) validates keeping it small — a 5th tool adds decision noise. The minimum capable set is the lowest-noise set.	harness-eng::dd01::recall
"What is Pi's system prompt size, and why is it deliberate?"	"<1,000 tokens. Deliberate delegation to the model: the thin prompt co-evolves (passes the future-proof test), doesn't fight capability growth, and avoids over-specifying behavior the model already handles. A thick prompt rots on model upgrade; the thin prompt gets out of the way.	harness-eng::dd01::recall
"How many of the 5 stop conditions does Pi implement, and which?"	"2 of 5: end_turn (model emits no tool call — natural stop) and max-iterations (hard cap — safety net). Missing: token budget, error threshold, human interrupt. Acceptable for personal use; a scored defect in production.	harness-eng::dd01::analysis
"What is Pi's permission model and what is the implication?"	"Trust-the-model — no per-action approval gates. Implication: correct for a trusted single-user environment (personal assistant on your own machine); a vulnerability catalog for multi-user/untrusted-input. No sandbox, no scoping, no tagging.	harness-eng::dd01::analysis
"State Pi's blast radius if the process is compromised."	"The ENTIRE HOST. bash = full shell; write_file = unrestricted; search = network. No sandbox, no filesystem scope, no network allowlist. An attacker who compromises Pi can read ~/.ssh, write anywhere the process user can, and call any URL.	harness-eng::dd01::analysis
"Does Pi have context management (compaction)? What does it rely on instead?"	"NO compaction. Pi relies on MINIMAL TOOL OUTPUT — the 4 tools return modest results by design. But a long bash session can still rot context. A scored finding (Module 3: 2/5).	harness-eng::dd01::analysis
"Name 3 things Pi does BETTER than any other harness in the deep-dive roster."	"(1) LEGIBILITY: ~1,200 LOC, readable in an afternoon. (2) CO-EVOLUTION: dumb-loop + thin prompt → benefits from every model upgrade (passes the future-proof test). (3) CONCEPTUAL CLARITY: the purest expression of 'harness does only what it must.' Every other harness adds complexity Pi shows is optional.	harness-eng::dd01::recall
"Name 3 things you'd fix if you forked Pi toward 'minimal production.'"	"(1) Add token-budget stop condition (Module 1.2) — cheap, prevents runaway cost. (2) Add 8-field per-turn observability payload (Module 10) — transforms debuggability. (3) Add basic compaction threshold (Module 3) — extends effective range. These move Pi from minimal baseline to minimal production WITHOUT compromising thinness.	harness-eng::dd01::application
"Pi has no sandboxing. Is this a defect or a decision?"	"A DECISION — correct for a trusted single-user environment (personal assistant on your machine). A defect ONLY if deployed in multi-user/untrusted-input. The absence is deliberate, not an oversight; it's the cost of thinness. Adding a sandbox alone (without scoping + gates + observability) gives the cost without the benefit — fork coherently or not at all.	harness-eng::dd01::analysis
"State Pi's Architect's Verdict (optimizes for / sacrifices / who should build on it)."	"OPTIMIZES for model-co-evolution and legibility (~1,200-line harness readable in an afternoon that improves automatically as the model upgrades). SACRIFICES safety, memory, observability. BUILD ON IT for personal-assistant-in-trusted-environment; NOT for multi-tenant/enterprise/untrusted-input.	harness-eng::dd01::recall
"State Pi's MLSecOps Relevance note."	"Pi's defining security property is the ABSENCE of defenses: no sandboxing, no scoping, no untrusted-tagging — correct for a trusted single-user context, but a vulnerability catalog for any deployment that touches untrusted input or multiple users.	harness-eng::dd01::recall
"Why is Pi the benchmark for every other deep-dive?"	"It's the thinnest reference point on the spectrum. Every other harness is measured against Pi's minimalism: 'how much thickness does X add, and why?' Pi defines the baseline; the others define the variations. The comparison question originates here.	harness-eng::dd01::analysis
"Pi scores 25/60 on the rubric. Is that a bad score? Explain."	"NO. The rubric scores production-readiness across ALL dimensions. Pi is DELIBERATELY thin. The score reflects what Pi IS NOT, not a failure of what Pi IS. Pi's value is legibility + co-evolution, not breadth. A 25/60 harness correct for personal use is a better fit than a 55/60 harness that brings enterprise machinery to a task that doesn't need it.	harness-eng::dd01::analysis
"What is the 'future-proof test' and why does Pi pass it by design?"	"The future-proof test (Module 1): does performance improve on model upgrade WITHOUT harness changes? Pi passes BY DESIGN because the dumb-loop + thin prompt add no cleverness that can rot. A thick harness's lookahead/planning/reflection logic can degrade or conflict when the model changes; Pi has none of that, so it benefits for free from every model upgrade.	harness-eng::dd01::analysis
"What is the 'dumb-loop philosophy' and what tradeoff does it accept?"	"The ReAct loop with NO lookahead, NO planning, NO reflection (~80 lines of TypeScript). Tradeoff accepted: error compounding (one bad step propagates because there's no reflection to catch it). Benefit: co-evolution — the harness adds no cleverness that could rot on model upgrade.	harness-eng::dd01::analysis
"Trace one tool call through Pi's 7-step dispatch."	"Model emits tool_use: read_file({path:'auth.ts'}) → harness validates name against the 4-tool registry → schema-validates {path:string} → executes readFileSync('auth.ts') → returns content → appends to history as {role:'tool', content:...} → next model call. Clean, minimal, exactly Module 2's 7-step dispatch with 4 tools.	harness-eng::dd01::application
"How is Pi vulnerable to indirect injection, and why is it 'by design'?"	"No untrusted-content tagging. A file read via read_file that contains injected instructions enters context as RAW content; the model may comply (Module 2.4 Vector 1, OWASP ASI01). 'By design' because Pi is a thin harness that trusts the model — tagging is a layer Pi deliberately omits. This is the surface Course 2B's SDD-B01 offensive expansion lands on first.	harness-eng::dd01::analysis
"How does Course 2B (Attacking Harnesses) read Pi?"	"As the UN-HARDENED BASELINE. SDD-B01's OWASP ASI offensive procedures land on Pi's trust-the-model posture by default: no taint gate = trivial ASI01 drift; no sanitizer = trivial ASI07 output-as-input; no principal binding = trivial ASI10 inter-agent trust escalation. Every row Pi omits is a row where Pi's answer is 'the model handles it' — honest about the threat model, wrong the moment input is untrusted.	harness-eng::dd01::analysis
"How does Course 3 (Fine-Tuning) use Pi's loop, and why does this work?"	"Course 3 drops a fine-tuned model INTO Pi's UNCHANGED loop. This works because Pi passes the future-proof test — the loop adds no cleverness that needs to know the model changed. Course 3's contribution is INSIDE the model; Pi's contribution is the stable loop around it. The dumb-loop philosophy is what makes the swap seamless.	harness-eng::dd01::analysis
"Why is 'add a sandbox and Pi is production-ready' an anti-pattern?"	"Adding a sandbox changes Pi's threat model. Pi's trust-the-model posture is correct for single-user-on-own-machine. Adding a sandbox WITHOUT also adding scoping (M5.3), approval gates (M6), and observability (M10) gives you the cost of the sandbox without the benefit. If you need a sandbox you need the FULL security layer (Course 2A), not one component. Fork Pi coherently.	harness-eng::dd01::analysis
"What is the '4-tool philosophy' and why is it a noise-reduction strategy, not a limitation?"	"bash + read_file + write_file + search = the minimum capable set. The Vercel finding: cutting 80% of tools IMPROVED selection accuracy — more tools means more decision noise for the model at the dispatch layer. A 5th tool adds decision noise; the minimum capable set is the lowest-noise set. Prefer composing the existing 4 over adding a 5th.	harness-eng::dd01::analysis
"How does Course 4 (Enterprise Platforms) deploy Pi, and what does it add?"	"Course 4 deploys Pi's ~80-line loop AT SCALE, replicated across a fleet. It adds the observability layer (Module 10 — the 8-field per-turn payload Pi omits) and the state-checkpoint layer (Module 8 — the resume-on-interrupt Pi omits) ON TOP of Pi's loop. Pi is the UNIT OF DEPLOYMENT; the enterprise layers are wrappers around it.	harness-eng::dd01::analysis
"What does 'the score reflects what Pi IS NOT, not a failure of what Pi IS' mean?"	"The rubric scores production-readiness across ALL 12 dimensions. Pi is DELIBERATELY thin — it is not trying to be production-grade across all dimensions. The 25/60 score is the expected result for a deliberate thin harness: the missing points are deliberate omissions (sandbox, memory, state, verification), not failures. Pi's value is legibility + co-evolution, which the production-readiness rubric does not measure.	harness-eng::dd01::analysis