dh Glossary

A mandate that names a dh concept states only the name, not the method — the orchestrator sees the outcome (a verdict, a gate, a report) and can misinfer the mechanism from watching what it does. Load this skill instead of inferring; each entry states the method, not just the outcome, and points to the file that is authoritative if this entry ever drifts from it.

Terms

RT-ICA (Reverse Thinking - Information Completeness Assessment) — works backward from the stated goal through its prerequisite chain: what must exist to reach the goal, then what each of those things requires, recursively back to the current state. Classifies each prerequisite as AVAILABLE, DERIVABLE, or MISSING. dh:rt-ica blocks planning on any MISSING condition (S2 implementation gate); dh:planner-rt-ica is the non-blocking sister used during grooming, which localizes a MISSING condition to the affected task instead of halting. Canonical: skills/rt-ica/SKILL.md.

ARL (Autonomous Refinement Loop) — research into the prerequisites for autonomous agent execution without synchronous human blocking gates: failure categories, and the conditions under which a machine-verifiable check can replace human judgment. dh's human-touchpoint model is ARL-derived — see the S1-S7 entry below. Canonical: plugins/plugin-creator/skills/arl/SKILL.md.

SAM (Stateless Agent Methodology) — the 7-stage development pipeline this harness implements (S1-S7, below). "Stateless" means each stage's state lives in a provider-owned artifact, never in conversation history — a stage reads its input from the prior stage's registered artifact, not from what an agent remembers saying earlier. Canonical: plugins/development-harness/AGENTS.md ("SAM 7-Stage Pipeline").

S1-S7 — the SAM pipeline stage names, in order: S1 Discovery (understand the feature, codebase, constraints) → S2 Planning + RT-ICA (generate a plan, gated by dh:rt-ica) → S3 Context Integration (validate the plan against actual codebase state) → S4 Task Decomposition (break the plan into executable tasks) → S5 Execution (implement tasks via language-specific specialists) → S6 Forensic Review (verify each task against its acceptance criteria) → S7 Final Verification (certify the feature meets the original requirements). Not every stage requires human review — ARL-derived constraint analysis decides when to escalate, not a fixed checkpoint per stage. Canonical: plugins/development-harness/AGENTS.md ("How It Works").

Impact Radius — the backlog-item section listing every system a proposed change affects (code, docs, configuration, CI, tests, agent instructions), written by @dh:impact-analyst before planning. The feasibility gate and grooming staleness checks read this section to size a change's blast radius; an item using an older grooming template may have this content under a Resources section instead — readers of the primary key fall back to it. Canonical: plugins/development-harness/agents/impact-analyst.md.