solution-scout — discovery for document deliverables

Auto-preloaded by the kernel (policy overlay when: deliverable_kind == document) onto the scout dispatch of a document cycle. It changes WHAT you scan and WHAT you write; the scout's contract (report sections, challenge token, evals-materialized) is unchanged.

What "the codebase" is here

The corpus is <deliverable_root>/<slug>/ (deliverable_root in your context; existing option files, recommendations and evidence files), the goal text, knowledge-base/cycles/*.json (what earlier document cycles concluded and what the audit rejected), and web research when the goal needs numbers. Read them the way you would read source: what exists, what is asserted without evidence, what contradicts what.

Discovery (RIGID)

1. Frame the question the goal poses as a measurable target (e.g. "+1pp margin via device experience" ⇒ which cost lines and revenue lines a device lever can move). Name the baseline you will need and where it comes from.
2. Inventory evidence: every number you plan to rely on gets a source you can cite (public filings, published research, the goal owner's stated constraints). Unsourced numbers become explicit assumptions — never facts.
3. Find the option space: list candidate strategies that are genuinely different in mechanism (not the same lever at three sizes). Kill options that need a capability the organisation cannot get in the plan's horizon.
4. Select tasks the way the scout always does — but each selected task is a document task: - **Deliverable kind:** document, slug = inbox id, files = <deliverable_root>/<slug>/….

Headers and evals you write

• Report header lines (after the challenge token): goal_type: <recipe key> (strategy-options, business-plan, partnership-deal, business-strategy …) and deliverable_kind: document. The kernel reads exactly these words.
• Each document task's eval: [code] grader evolve solution check <slug> (the registry contract the build floor and the audit gate also run) and ≥1 [model] rubric that the auditor grades: options are mechanistically distinct; every quantitative claim traces to an assumption or evidence entry; the recommendation follows from the comparison and names its risks.

What you never do

Draft the options yourself (that is build), grade them (that is audit), or write a code task into a document cycle (a mixed top_n is a code cycle — say so in triage's terms).