feat: tighten freestyle discovery and analyst handoff

examples/workflows/prompts/analyst_freestyle.md

@@ -27,6 +27,12 @@ There is always exactly one task id to name by the time you call `emit_artifact`
 yourself unsure whether to name a parent or a child, the answer is always the child. Do not loop on
 this decision.
 
+The DoD is the handoff contract for every later stage. Derive it from the complete discovery brief
+and inspected repository evidence: include the changed surfaces, behavior, failure paths, required
+tests/build checks, and any event or artifact that must be recorded. A criterion is complete only
+when a reviewer or an automated gate can answer yes/no without guessing. Keep criteria atomic and
+avoid vague verbs such as "improve", "handle", or "support" without naming the observable result.
+
 Emit the `dod` artifact once. Its criteria are the complete acceptance contract for this run:
 
 - Give every criterion a stable id (`c1`, `c2`, …), a checkable statement, and its feature area.
@@ -35,6 +41,8 @@ Emit the `dod` artifact once. Its criteria are the complete acceptance contract
 - Tag semantic or UX criteria `verified_by: "reviewer"`.
 - Copy discovery `brief.non_goals` into `out_of_scope`; this is a hard review boundary.
 - Cover the entire in-scope brief now. Later stages may not silently add criteria.
+- Include at least one criterion proving the named task is carried through to the implementation
+  plan, and one criterion for each material failure or recovery path identified during discovery.
 
 Call `emit_artifact` with a JSON object matching this shape:
 `{"summary": string, "criteria": [{"id": string, "statement": string, "part": string,

examples/workflows/prompts/discovery.md

@@ -7,6 +7,12 @@ Read-only tools: `file_read` (also lists a directory's entries when given a dire
 `ls`, `grep`, `cat`, `find`. Use them — do not ask about things you can settle by reading the
 code.
 
+Inspect enough of the repository to cover the whole decision surface before emitting the artifact.
+At minimum, check the requested entry points, neighboring modules, existing tests, relevant build
+configuration, and the current protocol/API or file layout named by the request. Record concrete
+paths and observed facts in the brief; do not claim that something exists merely because the
+request says it does.
+
 Two checks, both grounded in what you actually read:
 
 1. **Underspecification.** Is a fork left open that only the operator can settle — a missing
@@ -21,6 +27,11 @@ Two checks, both grounded in what you actually read:
    the server only exposes `/stream` — flag it and ask, rather than implementing the wrong
    endpoint.
 
+When the request is clear, the brief must still be exhaustive. Populate `scope` with the concrete
+surfaces that will change, `non_goals` with adjacent work you deliberately exclude, `constraints`
+with repository/build/protocol limits, and `assumptions` with visible defaults. If a question is
+needed, batch all operator-only questions after inspection; do not stop at the first uncertainty.
+
 Emit the `discovery` artifact by calling **`emit_artifact`** with:
 - `brief`: the complete comprehension brief. Populate `what`, `why`, `who`, `scope`,
   `non_goals`, `constraints`, and `assumptions` even when questions remain. Use assumptions for