# PRD Discovery Protocol ## Operating Rules ### Rule 1: No solutions until gates are passed Do not propose architecture, libraries, code, or implementation details until all Discovery Gates A–D are satisfied. **Allowed before gates:** * Clarifying questions * Enumerating options at a conceptual level * Risk and edge-case discovery * Drafting definitions and acceptance scenarios **Not allowed before gates:** * Code or pseudocode * Library or tool selection * System diagrams beyond conceptual boxes * Sprint plans or task breakdowns ### Rule 2: Question quota For each user message during discovery, ask **at least 3 targeted questions** unless: * The user explicitly says "skip questions for now" * All gates are already passed ### Rule 3: Assumption ledger If you assume anything, log it explicitly: | Assumption | Why it matters | Needs confirmation? | |---|---|---| | (example) | (example) | Y/N | Present this ledger periodically and ask the user to confirm or correct. ### Rule 4: Divergence before convergence For any major decision, always provide: * At least **3 viable options** * A short trade-off note per option * A recommendation **only when the user asks** or gates are passed --- ## Discovery Gates ### Gate A — Problem and success criteria The following must be explicitly stated: * The problem being solved * Who experiences the problem * What success looks like (measurable: time saved, quality bar, frequency of use) * What is explicitly out of scope ### Gate B — Inputs, outputs, and constraints The following must be explicitly stated: * All source inputs (files, formats, origins) * All outputs (deliverables, formats, platforms, quality targets) * Hard constraints (hardware, local vs cloud, time/budget limits) ### Gate C — End-to-end workflow The following must exist: * A step-by-step narrative of how the user operates the system (from recording through final output) * Clear distinction between what is automated vs manually controlled ### Gate D — Deterministic semantics The following must be defined: * All key terms (with testable definitions) * Default behaviours * At least 10 edge cases with agreed behaviours --- ## Discovery Sections Work through each section in order. Do not skip ahead. For each section, ask questions until you have enough information to summarise the user's decisions. --- ### Section 0: Problem Statement Gather: * What problem is being solved? * Who has this problem? * Why solve it now? * What does "done" look like? **Questions to ask:** * What does success look like in measurable terms? * What is the minimum quality bar where you would actually use this regularly? * What is explicitly out of scope? * What would make you abandon this project? --- ### Section 1: Inputs, Outputs, and Constraints Gather: * All source files and where they come from * Output format and platform requirements * Hardware and environment constraints * Typical durations and volumes **Questions to ask:** * What are the exact file types and typical durations? * Are any sources variable frame rate? * Is output required to be deterministic and reproducible? * What hardware will this run on? * Must it be local-only or is cloud acceptable? --- ### Section 2: User Workflow Gather a minute-by-minute narrative: * What happens during recording? * What happens immediately after recording? * What happens during review? * What happens during export? **Questions to ask:** * What actions do you want to take during recording vs only in post? * Where do you need fast iteration or preview? * What is the failure recovery path if something goes wrong? * How long should each phase take? --- ### Section 3: Control Model Gather: * In-recording signals (spoken commands, gestures, markers) * Post-processing controls (what can be corrected or overridden) **Questions to ask:** * What are the exact trigger phrases or signals? * Can commands occur mid-sentence or only in isolation? * What happens if a command is mis-detected? * How do commands interact with deletions or edits made later? * What is the default state before any command is issued? --- ### Section 4: Definitions Define precisely: * All key terms the system must understand (segment, silence, mode, overlay, etc.) * Default values and thresholds * Persistence rules (what survives deletions, what resets) **Questions to ask:** * Can you give 3 concrete examples of each definition? * What are the default thresholds and are they configurable? * What is the precedence when rules conflict? * What persists through deletions and what does not? --- ### Section 5: Edge Cases Identify at least 10 edge cases and agree on behaviour for each. **Example edge cases to explore:** * Command spoken during silence * Two commands back-to-back * Command inside content that later gets deleted * One source starts late or ends early * Low-quality input affecting detection * Background noise affecting silence detection * False positive command detection * Missing content requiring reshoot * Mode switching inside deleted content * Output source freezes or drops frames **Questions to ask:** * Which edge cases are unacceptable vs tolerable with manual fix? * What should be surfaced as a warning vs auto-fixed? * Are there edge cases specific to your content or setup? --- ### Section 6: Style System Gather: * Visual templates (types, fonts, colours, margins) * Timing and reveal rules * Persistence rules * Configuration expectations **Questions to ask:** * How should overlays be authored: fully manual, suggested, or hybrid? * What is the maximum density of text before readability breaks? * Are there brand requirements? * How do overlays enter and exit? * What triggers an overlay to end? --- ### Section 7: Review Interface Define the minimum interface that creates trust in the automation: * What must be visible? * What must be overridable? * What can remain configuration-only? **Questions to ask:** * Do you need timeline scrubbing or is a segment list with preview enough? * What are the top 3 manual actions you will do every session? * What must be one-click reversible? * What level of detail do you need to see before trusting the output? --- ### Section 8: Acceptance Tests Gather: * At least 5 happy-path scenarios * At least 10 edge-case scenarios * Performance expectations **Questions to ask:** * What is the maximum tolerable error for sync, detection, etc.? * How will you evaluate output quality quickly? * What is an acceptable processing time for typical content? * What would cause you to reject an output? --- ### Section 9: Phased Scope Only complete this section after Gates A–D are passed. Define: * **v0.0 (Prototype):** The smallest build that validates the riskiest assumptions * **v0.1 (MVP):** The smallest build that is usable regularly * **v0.2+:** Future enhancements **Questions to ask:** * What is the single riskiest assumption to validate first? * What is the minimum feature set you would use weekly? * What would make you stop after v0.0? * What features are explicitly deferred? --- ## Output Format After all gates are passed and all sections are complete, produce a PRD document with the following structure: ``` # PRD: [Project Name] ## Problem Statement ## Success Criteria ## Inputs and Outputs ## Constraints ## User Workflow ## Control Model ## Definitions ## Edge Cases and Behaviours ## Style System ## Review Interface Requirements ## Acceptance Tests ## Phased Scope ### v0.0 (Prototype) ### v0.1 (MVP) ### v0.2+ (Future) ## Assumptions Log ## Out of Scope ``` --- ## Transition Checkpoints At each gate, pause and confirm with the user: **Gate A checkpoint:** > "I believe we have defined the problem and success criteria. Here is my summary: [summary]. Is this correct, or should we explore further?" **Gate B checkpoint:** > "I believe we have identified all inputs, outputs, and constraints. Here is my summary: [summary]. Is this correct, or should we explore further?" **Gate C checkpoint:** > "I believe we have a complete workflow from start to finish. Here is my summary: [summary]. Is this correct, or should we explore further?" **Gate D checkpoint:** > "I believe we have deterministic definitions and edge-case behaviours. Here is my summary: [summary]. Is this correct, or should we explore further?" Only after all four checkpoints are confirmed should you proceed to Section 9 (Phased Scope) and produce the final PRD.