Defines the format, structure, and quality standards for RESEARCH.md documents. Used by the researcher agent in Phase 0 to produce domain research that gives downstream agents complete context.
Good core principle statement: "The core principle is X.509 certificate chain validation — how a relying party traverses a chain of certificates from leaf to root CA, verifying signatures and constraints at each step."
Bad core principle statement: "The core principle is building a CA." (Too vague. What about a CA? What mechanism?)
Good scope boundary: "In scope: certificate generation, signing, chain building, CRL generation, OCSP response serving. Out of scope: HSM integration, LDAP directory publishing, web UI, production key management."
# RESEARCH.md — [Project Name]
## §1 — Core Principle
[1-2 sentence statement of the fundamental mechanism this experiment demonstrates.]
## §2 — Domain Background
[Comprehensive explanation of the domain. Every concept a newcomer needs. All terms defined on first use. Written so someone with zero domain knowledge can understand what they're building and why.]
### §2.1 — Key Concepts
[Concept-by-concept breakdown with definitions and relationships.]
### §2.2 — How It Works
[End-to-end explanation of the mechanism. Walk through the core principle step by step.]
## §3 — Technology Evaluation
### §3.1 — Programming Language Candidates
[For each candidate: name, relevant standard library capabilities, ecosystem maturity for this domain, pros, cons, verdict.]
### §3.2 — Design Pattern Candidates
[For each candidate pattern: name, how it maps to the domain, pros, cons, applicability to the core principle.]
### §3.3 — Recommendation
[Recommended language and patterns with brief justification tied to the core principle and philosophy constraints.]
## §4 — Prior Art and References
[Relevant specifications (RFCs, standards), reference implementations, educational resources. Cited specifically, not vaguely.]
## §5 — Scope Definition
### §5.1 — In Scope
[Bulleted list. Each item directly serves demonstrating the core principle.]
### §5.2 — Out of Scope
[Bulleted list with brief rationale for each exclusion.]
### §5.3 — Mock Boundaries
[What will be mocked/stubbed and how. Per philosophy: mock everything that isn't the core principle.]
## §6 — Assumptions
[Numbered list of assumptions. Each one is something the specification will treat as true without further validation.]
## §7 — Open Questions
[Numbered list of questions for the user. Things that need human confirmation before proceeding to specification.]