"In a typical production session, tool outputs are ~X% of context; the system prompt is ~Y%. Name X and Y."	"X = 67.6% (tool outputs). Y = 3.4% (system prompt). The single most asymmetric leverage point in harness engineering."	harness-engineering::m0.3::recall
"A ~100-line Python agent scores 74-76% on SWE-bench Verified. State the resolution of the apparent paradox."	"The execution loop is NOT where the complexity lives. World-class teams invest 6-12 months in the 98.4% AROUND the loop. The last 4-6 SWE-bench points + reliability/security/governance live entirely in the 98.4%. The loop is necessary and cheap."	harness-engineering::m0.3::analysis
"Is this rubric a feature checklist or a decision audit? State the three questions a decision audit asks."	"Decision audit. Three questions: (1) What pattern did they choose? (2) What did they GIVE UP? (3) Where in the code is the evidence?	harness-engineering::m0.3::recall
"What is the 'tell' that you did the rubric wrong (transcribed marketing instead of auditing a decision)?"	"If your rubric output for a harness could be generated by reading its README's feature list, you didn't audit a decision. You transcribed marketing."	harness-engineering::m0.3::application
"Contrast: 'Pi has a loop, 4 tools, and a max-iterations guard' vs a real decision-audit sentence on Pi."	"Feature: useless. Decision: 'Pi chose ReAct + trust-the-model + no compaction, trading safety and long-session coherence for model-co-evolution and a 1,200-line codebase any engineer can read in an afternoon. Correct for personal assistant; wrong for enterprise multi-tenant.'"	harness-engineering::m0.3::analysis
"Name the tell that distinguishes 'a design decision' from 'a feature'."	"A feature says 'has X'. A design decision names the pattern AND the tradeoff AND (ideally) the use-case fit. 'Puts sandbox outside the agent's reach because credentials can't live in-sandbox for multi-tenant' is a decision; 'has a sandbox' is a feature.	harness-engineering::m0.3::analysis
How many modules does the rubric have? List at least 6.	"12. (Any 6 of:) Execution Loop · Tool Design · Context Mgmt · Memory · Sandboxing · Permission · Error Handling · State & Checkpoint · Prompt Assembly · Subagent Orchestration · Verification · Observability.	harness-engineering::m0.3::recall
"How many phases in the deep-dive methodology? Name them in order."	"6: (1) First Contact (2) Architecture Map (3) Design Decision Audit (4) Security Audit (5) Benchmark & Performance (6) Score & Synthesize.	harness-engineering::m0.3::recall
"What does Phase 1 (First Contact) require you to read that docs pages often omit?"	"The system prompt in full SOURCE, not docs. Plus: README top-to-bottom noting what is NOT explained; cloc lines-by-language; file-structure map.	harness-engineering::m0.3::recall
"What does Phase 2 (Architecture Map) produce?"	"A Mermaid loop diagram, every tool listed with its schema, a traced single tool call (model output → dispatch → execution → result → context), the context-assembly function's input stack, and all stop conditions.	harness-engineering::m0.3::recall
"What does Phase 3 (Decision Audit) require beyond filling the 12-row table?"	"Find 3 decisions you AGREE with (explain why) and 3 you would make DIFFERENTLY (explain the alternative). Forces engagement, not transcription.	harness-engineering::m0.3::application
"What is the most-skipped phase, and why is skipping it catastrophic?"	"Phase 4 (Security Audit). Skipping it ships a verdict that misses the harness's central vulnerability — which for a security-focused course defeats the entire exercise.Credential flow, exec paths, injection test, blast radius.	harness-engineering::m0.3::analysis
"What is the deliverable of a deep-dive? State the exact format."	"(1) Scoring sheet: 12 rows × (1-5 score + decision + tradeoff + code location), total /60, evidence required. (2) Architect's Verdict: EXACTLY 3 sentences (optimizes for / sacrifices / who should build on it). (3) MLSecOps Relevance: EXACTLY 1 sentence.	harness-engineering::m0.3::recall
"Why does the deliverable enforce a strict format (3-sentence verdict, 1-sentence MLSecOps note)?"	The constraint is the point: forcing every harness into the same template makes them COMPARABLE. Comparability turns a pile of deep-dives into a mental model of the field. A verdict that drifts from the template cannot be compared to others.	harness-engineering::m0.3::analysis
"State precisely why NemoClaw can inherit ~90% of OpenClaw's code and still be a distinct, scorable harness."	Because the rubric scores DECISIONS, not features. NemoClaw's entire score is in the governance decision (enforcement outside the agent's reach); the inherited 90% is OpenClaw's score, not NemoClaw's contribution. A fork's meaning is its diff from the parent.	harness-engineering::m0.3::analysis
"True or false: a score on the rubric without a code location is acceptable if the pattern is well-known."	False. A score without a code location is an OPINION, not an audit. Evidence required means file:line.	harness-engineering::m0.3::application
"A team spent 2 weeks polishing their system prompt and ignored tool-output formatting. Per the anchor, what did they optimize and what did they neglect?"	"Optimized ~3.4% (system prompt); neglected ~67.6% (tool outputs). The most common senior-engineer mistake. Modules 2 + 3 exist to fix this.	harness-engineering::m0.3::application
"Why does a 'dumb loop' (delegate everything to the model) sometimes beat a sophisticated plan-then-execute loop?"	"Co-evolution: a dumb loop improves automatically as the model improves; a rigid architecture constrains capability growth. The tradeoff is that debugging is harder and reliability depends heavily on the model. (Anthropic's philosophy; Pi.)	harness-engineering::m0.3::analysis
"In Phase 3, you must find 3 decisions you'd make differently. What's the failure mode if you skip this?"	"You produce a verdict that is pure description — no critical engagement. The '3 disagree' requirement forces you to actually evaluate tradeoffs rather than just transcribe what the team did. Without it the deep-dive is hagiography, not analysis.	harness-engineering::m0.3::analysis
"Which rubric module asks 'what happens when the model calls the same failing tool 10 times in a row'?"	"Module 7 (Error Handling & Recovery) — specifically stuck-loop detection and circuit breakers. (Direct tie to Course 1 Module 7.2.)	harness-engineering::m0.3::application
"Which rubric module audits the tradeoff 'credentials can't live in the sandbox if you're multi-tenant'?"	"Module 5 (Sandboxing & Isolation) — the inside-sandbox vs outside-sandbox split. Outside-sandbox trades API-hop latency for credential isolation. (Luzzardi framing.)	harness-engineering::m0.3::application
"In the n8n 6-phase workflow, what does Phase 6 emit that the earlier phases don't?"	"The canonical TEMPLATES: scoring sheet (12 rows), Architect's Verdict (3 sentences), MLSecOps Relevance (1 sentence). Phases 1-5 produce EVIDENCE; Phase 6 produces the DELIVERABLE (filled by a human or LLM judge from that evidence).	harness-engineering::m0.3::recall
"Does the n8n methodology workflow score the harness for you?"	"No. A human (or LLM judge) fills the templates from the grep evidence Phases 1-5 produced. The workflow operationalizes the methodology so no phase gets skipped — that is its job.	harness-engineering::m0.3::analysis