Finder
Optional Business or Functional intake over one resumable Fog workflow
Finder is optional intake for uncertain product intent. Its public entrypoints are exactly business-finder and functional-finder. Both require explicit human invocation and compose the same internal finder-phase engine.
Finder can create or resume one Fog, gather useful evidence, and optionally project product structure. It does not run Requirements Grill, compile a specification, or project Stories and Tasks. Requirements Phase owns those delivery-depth operations whether Finder context exists or not.
Choose The Lens
| Entrypoint | Use when | Optional backlog projection |
|---|---|---|
$business-finder | A nontechnical colleague needs to capture the affected actor, problem or opportunity, desired outcome, value, evidence, constraints, non-goals, urgency, and open questions. | Product Areas and Initiatives. |
$functional-finder | A technical or proficient nontechnical colleague needs to capture user-visible behavior, functional boundaries, acceptance signals, exceptions, risks, evidence needs, and likely technical handoff questions. | Business structure plus Epics. |
Functional Finder can reuse existing Business structure, but it does not require Business Finder to have run first. The lenses are intake perspectives, not cumulative maturity stages.
One Engine, Two Wrappers
The shared engine owns Fog identity, provenance, support-work routing, reconciliation, resume behavior, and bounded return. A Fog can own several generic Kind/grilling children plus direct Research and Prototype children. Business, Functional, and Technical are not Grilling kinds, stages, provider maturity fields, or prerequisites.
Research and Prototype can identify unknowns and return durable evidence. Neither independently authorizes backlog projection. When an existing child is obviously relevant, Finder reuses it; when separate work is useful, Finder may create another child. Genuine ambiguity returns to the human without manufacturing duplicate work.
Product Boundary
Finder intake
Business lens -> optional Product Area / Initiative
Functional lens -> optional Business structure + Epic
Requirements Phase
Requirements Grill -> Create Spec (`OUT-###`) -> Write Backlog
-> derived Epic / Story / Task identitiesFinder returns control when its bounded result is reached. That does not assert that the Fog is resolved or complete, and no fixed number of Grilling children, specifications, Stories, or Tasks is required.
Writing And Reconciliation
$write-backlog is the only physical Linear or GitHub writer. Finder supplies semantic intent and allowed projection depth; the writer reads fresh provider state, reuses coherent structure, validates stable provider and durable wiki identities, previews material structural changes, and reads every write back exactly.
Finder never projects Stories or Tasks. When delivery-depth work is needed, it hands its durable context to Requirements Phase. That phase may also start directly from ordinary bounded requirements without creating a Fog or Finder child.
Delivery Truth
Fog remains lateral provenance rather than a product-hierarchy parent. It records its immutable original Business or Functional intake lens and links to the structure or delivery work it enriches or produces.
Work started, blocked, reviewed, merged, staged, produced, and complete remain distinct facts. A Fog completes only when accepted production evidence covers its resulting delivery scope; merge or staging alone is insufficient.
See the Requirements And Backlog flow for requirements closure and delivery-depth projection, and the Project Backlog Operating Model for provider mappings and hierarchy.