Wayfinder Backlog Model Grill Log

Source: user request to adapt Matt Pocock's in-progress wayfinder skill into Harness as a backlog-native decision frontier above implementation delivery.

Source Brief

The proposed Harness wayfinder should handle loose ideas that are too large for one agent session and still wrapped in fog. It should route unresolved work into backlog-native planning tickets, then let existing Harness phases and skills resolve those tickets.

Known source points:

wayfinder should be an always-visible root workflow routing concept in generated/root AGENTS.md.
It should be invoked conditionally for a loose idea that is too big for one session and wrapped in fog.
It should operate on backlog/project state, not the wiki as its living map.
Existing write-backlog module/milestone grouping remains the organizing primitive.
Backlog must expand beyond accepted implementation epics/stories to include uncertainty and learning tickets.

2026-08-04 Research Reassessment

The original grill adapted an earlier Wayfinder shape. A fresh comparison against Matt Pocock's current engineering skills found four material deltas:

Current Wayfinder is a durable chart/work lifecycle, not only a route classifier. It names a destination, distinguishes specifiable questions from fog and out-of-scope work, defines the frontier as open/unblocked/unclaimed tickets, claims before work, resolves one decision ticket per session except parallel research, and updates the map after each resolution.
Harness already has a standalone prototype primitive with logic and UI branches, plus a design-specific prototype mode. The missing surface is a generic prototype-ticket lifecycle and the newer upstream primary-source capture contract.
Matt's research adds one durable, claim-cited Markdown report in the repository. Harness parallel-research is stronger at readonly fan-out and synthesis, but has no durable report mode and weakens final source tracing from every retained factual claim to only important claims.
Matt's to-tickets shapes implementation-ready tracer bullets, explicit blocker graphs, approval, and agent readiness. Harness write-backlog instead owns governed planning taxonomy, accepted-scope provenance, capability hierarchy, provider fidelity, and materialization authority. These are adjacent stages, not interchangeable skills.

Primary evidence:

Matt Wayfinder
Matt Prototype
Matt Research
Matt To Tickets
Canonical Harness sources: finder-phase, wayfinder, prototype, parallel-research, and write-backlog in /Users/stefan/Desktop/repos/wearedevpunks-skills.

Open Branches

The current branch dashboard lives in wayfinder-backlog-model-grill-status.md.

Branch A: Backlog-Native Map

Q1

Question: Should Harness wayfinder use a wiki/project map first, or operate directly on the backlog provider?

Accepted answer:

wayfinder operates on backlog provider state.
Wiki and grill artifacts may provide evidence, but the living map is the project/backlog root.
"What is still fog?" must be visible in backlog, not only in docs.
Rationale: the user wants higher-level surveillance over project planning and routing, so the durable operating surface should be the same tracker used to coordinate work.

Glossary Q2

Question: What term should describe the outer wayfinder surface?

Accepted answer:

Canonical term: Backlog root — the project-level backlog container that functions as the wayfinder map.
Avoid: map issue, wiki map, docs-only project map.
Relationship: Backlog root contains root-level Fog and module/milestone groups.
Axiom: Harness wayfinder does not create a separate map item; the project/backlog root is the map.

Branch B: Item Taxonomy

Q3

Question: What first-class backlog item types should wayfinder support?

Accepted answer:

Supported item types: fog, grilling, research, prototype, epic, story.
Do not add a separate map item type.
epic and story keep their existing implementation meaning from write-backlog.
fog, grilling, research, and prototype expand backlog to represent uncertainty, decision work, fact-finding, and artifact-learning work before accepted implementation scope exists.
Rationale: the project/backlog root already plays the map role; item types should describe the work or uncertainty represented inside that root.

Glossary Q4

Question: What is a fog item?

Accepted answer:

Canonical term: Fog — a root-level backlog item that tracks a real but not-yet-sharp area of uncertainty.
Relationship: Fog anticipates future modules, tickets, epics, and stories.
Relationship: Fog is a module candidate, not an execution container.
Axiom: A fog item is not delivery-eligible and is not a SPEC.md anchor.

Branch C: Backlog Hierarchy

Q5

Question: Should fog sit under a module/milestone, or should it sit at the project/backlog root?

Accepted answer:

fog is root-level only.
Once a concrete grilling, research, prototype, epic, or story can be named, the agent must first choose or create a module/milestone and then place the item there.
Default hierarchy:

Project / Backlog root
  Fog
  Module / Milestone
    Grilling
    Research
    Prototype
    Epic
      Story

Rationale: if a concrete ticket can be named, enough is known to attach it to an existing module or create a provisional module. Keeping concrete tickets under modules prevents fog from becoming an execution container.

Glossary Q6

Question: What invariant should govern fog children?

Accepted answer:

Axiom: Fog does not have child tickets by default.
Axiom: Sharpening a fog item first chooses or creates a module/milestone, then creates concrete tickets there.
Flagged ambiguity: "fog" could sound like a parent bucket for research or grilling. Resolution: fog is root-level anticipation of future module/ticket shape, not the parent of execution tickets.

Branch D: Resolution Into Implementation Scope

Q7

Question: Should grilling, research, and prototype be allowed to become epic directly, or must they close into an explicit accepted decision first?

Accepted answer:

grilling, research, and prototype tickets must close into an accepted decision before they create or update an epic or story.
The closing ticket should leave a short resolution note naming the answer, accepted direction, produced artifacts when applicable, and the created or updated implementation items.
Rationale: this keeps learning and decision work separate from implementation-ready scope while still making the transition visible in backlog.

Branch E: Root Routing Integration

Q8

Question: How should root AGENTS.md guidance discover wayfinder?

Accepted answer:

wayfinder should be available as an explicit root workflow routing concept.
Conditional trigger shape: "A loose idea has arrived - too big for one agent session, and wrapped in fog."
The exact wording, skill description, and placement in root prompt generation remain open.

Branch F: Provider Kind Representation

Q9

Question: Should wayfinder item type be stored as one canonical backlog field, with provider-specific fallbacks?

Accepted answer:

Yes. The canonical concept is kind, with values fog, grilling, research, prototype, epic, and story.
Provider implementations should use the strongest native single-value representation available instead of forcing every provider into labels.
Linear: use a single-select label group such as Kind/fog, Kind/grilling, Kind/research, Kind/prototype, Kind/epic, Kind/story, because Linear label groups allow only one label from a group per issue.
GitHub Projects V2: use a project custom single-select field named Kind; avoid GitHub issue type as the default because issue types are organization-level and better for broad org taxonomy.
monday.com: use a dedicated Status or Dropdown column named Kind; keep workflow state in a separate column.
Azure DevOps: use a custom picklist field such as Custom.DevpunksKind; use Work Item Type for structural level and tags only as searchable mirrors.
Labels/tags may be compatibility mirrors, but they are not canonical when a native field exists.
Rationale: kind must be stable across providers for skills and docs, but the physical storage should respect each provider's actual data model.

Glossary Q10

Question: What relationship should kind have to workflow state and hierarchy?

Accepted answer:

Canonical term: Kind — the single-value backlog classification for fog, grilling, research, prototype, epic, or story.
Avoid: workflow status, provider label pile, GitHub issue type by default, module name.
Relationship: Kind is separate from workflow state.
Relationship: Kind is separate from module/milestone grouping.
Relationship: Kind is separate from parent/child hierarchy.
Axiom: Provider-specific storage may vary, but kind semantics do not.

Branch G: `write-backlog` Skill Restructure

Q11

Question: Should write-backlog become the owner of both wayfinder planning graph creation and classic implementation backlog creation, or should wayfinder remain a separate skill?

Accepted answer:

wayfinder remains a separate skill.
The current discussion is about how wayfinder blends into the Harness flow, not about absorbing it into write-backlog.
wayfinder owns the decision frontier above the tracker: fog discovery, route selection, frontier surveillance, and deciding whether the next move is grilling, research, prototype, or accepted implementation scope.
write-backlog owns the backlog structure and provider payload contracts for the supported kinds: fog, grilling, research, prototype, epic, and story.
write-backlog must also re-architect the existing epic and story kind handling so implementation tickets stay strict while sitting beside the new learning and uncertainty tickets.
Rationale: keeping wayfinder separate preserves a focused orchestration skill, while write-backlog remains the provider/backlog writer that knows how to shape durable tracker items.

Glossary Q12

Question: What ownership boundary should separate wayfinder from write-backlog?

Accepted answer:

Canonical term: Wayfinder frontier — the current set of unclear or unresolved decisions that need routing before delivery scope is accepted.
Relationship: Wayfinder frontier sits above Backlog root state and is expressed through backlog items rather than a separate map artifact.
Relationship: write-backlog materializes accepted wayfinder routing decisions into provider-specific backlog structure.
Axiom: wayfinder decides what kind of work the frontier needs next; write-backlog writes that work into the backlog correctly.

Q13

Question: Should write-backlog physically treat fog, grilling, research, and prototype as first-class backlog items in every provider payload, or should some providers store them as lighter metadata wrappers until they resolve?

Accepted answer:

fog, grilling, research, and prototype must be first-class backlog items in every supported provider.
Provider-specific field shapes may vary, but the coordination object must be visible, assignable, searchable, linkable, and closeable.
Do not represent these kinds as metadata-only wrappers, hidden notes, or docs-only records.
epic and story also remain first-class backlog items, with stricter delivery semantics.
Rationale: wayfinder needs real tracker-native surveillance over uncertainty and learning work; if these items are hidden metadata, the frontier disappears from the operating surface.

Glossary Q14

Question: What invariant should govern physical backlog representation for all supported kinds?

Accepted answer:

Axiom: Every supported kind is represented by a first-class provider backlog item.
Axiom: First-class backlog items must be visible, assignable, searchable, linkable, and closeable in the target provider.
Avoid: metadata wrapper, hidden planning note, docs-only tracker, implicit child list.

Branch H: Skill Composition

Q15

Question: Should wayfinder/SKILL.md contain the full frontier workflow inline, or should wayfinder stay as its own lean block with a higher-order Harness skill adding the extra references?

Accepted answer:

Keep wayfinder as its own individual lean skill/block.
Introduce a higher-order Harness workflow skill for the new primitive, tentatively named finder-phase.
The higher-order skill owns Harness-specific references and integration: backlog item lifecycle, root workflow routing, provider-writing expectations, and how the frontier routes into grilling, research, prototype, or implementation backlog work.
The higher-order skill should include or invoke the lean as-is wayfinder skill rather than bloating wayfinder itself.
Rationale: wayfinder should remain portable and sharp, while Harness needs a larger workflow wrapper that connects frontier discovery to backlog-native project tracking.

Glossary Q16

Question: What terms describe the lean skill and the higher-order Harness wrapper?

Accepted answer:

Canonical term: Wayfinder primitive — the lean frontier-discovery skill/block that identifies fog, decisions, and next-route candidates.
Canonical term: Finder phase — the higher-order Harness workflow skill that composes the wayfinder primitive with backlog-native routing and references.
Relationship: Finder phase includes or invokes the Wayfinder primitive.
Relationship: Finder phase routes frontier outputs into grilling, research, prototype, epic, or story backlog items.
Axiom: Harness-specific backlog integration belongs in the higher-order phase skill, not in the lean wayfinder primitive.
Axiom: The skill slug is finder-phase.

Q17

Question: Should finder-phase own one bundled reference that explains the whole backlog-native lifecycle, or split that into progressive-disclosure references?

Accepted answer:

Split finder-phase guidance into progressive-disclosure references, following writing-great-skills.
Keep finder-phase/SKILL.md lean.
Inline only the ordered core steps, branch selection pointers, always-needed rules, and completion criteria.
Put branch-specific depth in disclosed references rather than one bundled lifecycle reference.
The finder-phase skill should compose the lean as-is wayfinder primitive and add Harness-specific references around it.
Rationale: this keeps the main skill predictable and small while loading extra lifecycle/provider/root-routing detail only when the active branch needs it.

Glossary Q18

Question: What invariant should govern finder-phase reference design?

Accepted answer:

Canonical term: Progressive-disclosure reference — a linked skill reference loaded only when a specific branch needs its detail.
Relationship: Finder phase uses Progressive-disclosure reference files for Harness-specific depth.
Axiom: Inline what every finder-phase branch needs; disclose what only some branches need.
Axiom: Keep each behavior in one source of truth.

Q19

Question: Should finder-phase own the backlog item taxonomy and provider materialization references itself, or should those live under write-backlog with finder-phase linking to them?

Accepted answer:

Use a source-of-truth split.
finder-phase owns frontier lifecycle and root routing references.
write-backlog owns backlog item taxonomy and provider materialization references.
finder-phase links to write-backlog when it needs to materialize backlog items.
Rationale: finder-phase should orchestrate the frontier, while write-backlog remains the durable authority for how backlog items are shaped and written to providers.

Glossary Q20

Question: What source-of-truth boundary should govern finder-phase and write-backlog references?

Accepted answer:

Relationship: Finder phase owns frontier lifecycle and root routing.
Relationship: write-backlog owns backlog item taxonomy and provider materialization.
Axiom: finder-phase links to write-backlog for backlog materialization instead of duplicating provider or taxonomy rules.

Branch I: Final Planning Defaults

Q21

Question: What final defaults close the remaining finder-phase, wayfinder, and write-backlog planning questions?

Accepted answer:

Reference file names should use noun names, such as frontier-lifecycle.md, root-routing.md, backlog-item-taxonomy.md, and provider-materialization.md.
The lean wayfinder primitive lives in the normal /skills folder and can sit in the planning default pack with finder-phase.
finder-phase/SKILL.md should use the previously recommended lean shape: trigger, core loop, route-selection steps, completion criteria, and reference pointers only.
finder-phase is model-invoked.
Root AGENTS.md guidance should route loose, oversized, foggy work to finder-phase before requirements-phase.
The wayfinder inner reference owns the route-selection decision tree, then delegates backlog materialization to write-backlog.
finder-phase output contract is an updated backlog frontier plus concise handoff; wiki docs are not the living map.
Shared fields for backlog kinds follow the already accepted first-class backlog item contract.
Lifecycle states for fog, grilling, research, and prototype use simple provider-native statuses plus kind-specific closure requirements.
Closure notes for grilling, research, and prototype include the answer, accepted direction, artifacts, and created or updated epics/stories.
finder-phase creates or chooses a provisional module/milestone as soon as a concrete non-fog item can be named.
write-backlog owns exact Linear, GitHub, monday.com, and Azure provider payload shapes for each kind.
Do not design or perform a migration for old epic/story state.
Shared-skill implementation should be authored in /Users/stefan/Desktop/repos/wearedevpunks-skills, synced into Harness, then wired into catalog/pack/baseline when shipping.
Rationale: the requirements direction is sufficiently closed; remaining work is implementation and provider validation.

Glossary Q22

Question: What final axioms should prevent implementation drift?

Accepted answer:

Axiom: Reference filenames describe knowledge surfaces; steps and actions stay in SKILL.md.
Axiom: finder-phase is model-invoked.
Axiom: finder-phase routes before requirements-phase when a loose idea is too large for one session and wrapped in fog.
Axiom: The wayfinder primitive owns route selection; write-backlog owns backlog materialization.
Axiom: No legacy epic/story migration is part of v1.
Axiom: Shared skill edits start in /Users/stefan/Desktop/repos/wearedevpunks-skills, not Harness mirrors.

Branch J: Wayfinder Lifecycle Reassessment

Q23

Prerequisites:

none

Question: Should Harness expand finder-phase from a one-pass classifier into a durable chart/work lifecycle adapted to the backlog-root model?

Accepted answer:

Yes. Add destination, chart/work modes, precise fog graduation, an open/unblocked/unclaimed frontier, claim-before-work, and resumability.
Preserve the accepted Harness rule that the backlog root is the map; do not create Matt's separate map issue.
Do not make finder-phase auto-resolve every ticket. It charts, selects, claims, routes, and later reconciles resolutions produced by the appropriate research, prototype, grilling, specification, backlog, or delivery flow.

Branch K: Generic Prototype Route

Q24

Prerequisites:

none

Question: Should Harness refresh the existing prototype primitive and add a generic standalone prototype-phase wrapper?

Accepted answer:

Yes. Refresh the existing Devpunks prototype primitive with Matt's latest logic/UI behavior and safeguards.
Add a generic standalone prototype-phase for prototype-ticket lifecycle, separate from the existing design-specific prototype mode.
Adopt durable throwaway-branch capture: prototype code remains disposable, while the full prototype is retained off main as primary evidence and the accepted verdict is linked into the durable decision flow.

Branch L: Durable Research Contract

Q25

Prerequisites:

none

Question: When should parallel-research persist one consolidated repository report, and who owns that write?

Accepted answer:

Durable research requests and research backlog work produce exactly one consolidated Markdown report.
Readonly research agents continue to fan out; one designated coordinator or consolidator owns the single report write after synthesis.
Every factual claim retained in the report cites its owning primary source.
The report is a source/learning artifact. docs-ingest-phase may later ingest its durable knowledge into routed project wiki flows, concepts, or learning pages without turning the report itself into the canonical wiki surface.
Ad hoc audits may remain response-only when no durable research artifact was requested or routed.

Branch M: Write-Backlog Ticket Readiness

Q26

Prerequisites:

none

Question: Should Matt's implementation ticketization primitives be merged now, selectively borrowed, or parked as a separate downstream effort?

Accepted answer:

Selectively merge tracer-bullet completeness, native blocker graphs, explicit breakdown approval, and agent readiness into write-backlog.
write-backlog runs after the authoritative SPEC.md and projects its user stories, acceptance criteria, dependencies, parked scope, and evidence into provider-native backlog items.
Preserve artifact separation: concrete files, commands, implementation steps, test cases, worker assignments, and execution order remain owned by create-plan and delivery.
Do not import unrelated prefactor/wide-refactor implementation planning into write-backlog as part of this decision.

Branch N: Direct Backlog Vocabulary

Glossary Q27

Prerequisites:

Question: Should Harness keep kind as the canonical umbrella term and provider field for its backlog taxonomy?

Accepted answer:

No. Drop the canonical kind wording and field abstraction.
Name the six backlog concepts directly: fog, grilling, research, prototype, epic, and story.
This supersedes Q9, Glossary Q10, and the kind-specific portions of Q21.
Provider representations may differ, but they must preserve the meaning and lifecycle of each directly named concept without requiring one cross-provider field called Kind.

Branch O: Finder-to-Delivery Lifecycle Correction

Q28

Prerequisites:

Q23, Q24, Q25, Q26

Question: What is the canonical lifecycle from foggy work to implementation?

Accepted answer:

finder
  -> research / prototype
  -> requirements-grill
  -> create-spec
  -> write-backlog
  -> delivery-phase / create-plan
  -> implementation

Research, prototype, and grilling close the decision frontier before specification.
The authoritative spec precedes final delivery-backlog projection.
A pre-spec tracker item may exist only as an intake/frontier anchor, not as the final delivery decomposition.

Q29

Prerequisites:

Question: What role should create-spec play in the corrected lifecycle?

Accepted answer:

create-spec is a no-interview compiler of an already-developed conversation and closed decision frontier.
Missing material decisions route or fail back to research, prototype, or requirements grilling; create-spec does not interview to repair them locally.
Remove the explicit user-review stop. Successful compilation emits agent readiness, with the exact readiness marker still open.
Preserve durable SPEC.md and wiki/project bookkeeping.

Q30

Prerequisites:

Question: Which artifacts own specification, backlog projection, and concrete planning?

Accepted answer:

SPEC.md is the provider-neutral authority for binding requirements and accepted decisions.
write-backlog projects the spec into provider-native epics/stories and readiness state.
create-plan owns concrete implementation translation.
One delivery epic corresponds to the spec capability boundary; child stories derive from the spec's user stories and acceptance criteria and link back to the authoritative spec.

Q31

Prerequisites:

Question: What content belongs in the compiled spec versus the plan?

Accepted answer:

The spec owns binding product requirements, extensive numbered user stories, binary observable acceptance criteria, accepted architecture/contracts/schema decisions, accepted implementation and testing decisions, constraints, verification seams, and prototype verdicts.
Technical decisions enter the spec only when grounded in accepted grill decisions, relevant ADRs, accepted prototype conclusions, confirmed constraints, or existing system/contracts evidence.
The plan owns concrete files, tasks, dependencies, test cases, commands, implementation order, and worker assignments.
ADR and glossary discovery remain upstream in requirements-grill; create-spec consumes those artifacts instead of duplicating discovery.

Q32

Prerequisites:

Question: What verification primitive should create-spec adopt?

Accepted answer:

Adopt verification seams: name the highest useful observable boundary, prefer existing seams, cite analogous test prior art, add a new seam only when necessary, and require runtime evidence where behavior needs it.
Whether every spec requires explicit verification seams or only risk-qualified specs remains open.

Q33

Prerequisites:

Q24, Q31

Question: What prototype evidence may be compiled into a spec?

Accepted answer:

The prototype output supplies the question answered, evidence, verdict, rejected alternatives, unresolved risks, and an optional decision-rich snippet when prose would lose precision.
Prototype code remains disposable; accepted implications become requirements, implementation decisions, testing decisions, constraints, or decision-log entries.
Exact artifact structure/location and the explicit human-acceptance mechanism remain open.

Branch P: R3 Contract Details

Q34

Prerequisites:

Question: What exact boundary separates finder-phase lifecycle work from child-flow resolution?

Accepted answer:

finder-phase owns destination, the backlog-root map, frontier computation, claims, routing, resumption, and semantic reconciliation.
Research, prototype, grilling, specification, backlog, and delivery flows own their work and produce their bounded evidence, verdict, or artifact.
write-backlog owns provider mutations. Child flows do not independently invent provider state.
On child-flow completion, finder-phase consumes the result, delegates any provider update, records the resolution pointer, graduates newly precise fog, and recomputes the frontier.

Q35

Prerequisites:

Question: Where does the consolidated research report live, and how does docs-ingest-phase mark or project it?

Accepted answer:

Commit the report on a research/<slug> branch and identify it by immutable commit SHA plus repository path.
The research backlog item records that source pointer and the consolidated answer.
docs-ingest-phase uses its private/internal path to scan the report as a knowledge source, then keep, update, consolidate, replace, or mark stale the relevant routed wiki knowledge.
Wiki projections cite the source pointer, add future-use hooks, and use normal route/log bookkeeping. The report remains primary evidence; routed wiki pages become canonical reusable knowledge.

Q36

Prerequisites:

Question: How do providers represent the six directly named backlog concepts without recreating a canonical Kind field?

Accepted answer:

Use each provider's closest native type, category, label-group, or single-select mechanism with the direct values fog, grilling, research, prototype, epic, and story.
A provider may require a physical field or grouping name, but that name is an adapter detail rather than Harness domain vocabulary.
Provider validation must ensure exactly one of the six applies to each governed backlog item.

Q37

Prerequisites:

Question: What exact entry and failure contract governs the no-interview create-spec compiler?

Accepted answer:

Enter only when shared understanding is confirmed and all required research/prototype work is resolved or explicitly parked.
Compile only accepted decisions, evidence, constraints, prototype verdicts, glossary, and axioms.
If material input is missing, write no partial spec. Return structured spec-not-ready output naming each missing decision/evidence item and its required upstream route.
Dependency-readiness failures remain explicit blockers rather than implicit questions inside spec writing.

Q38

Prerequisites:

Question: Are explicit verification seams mandatory in every spec or conditional by risk?

Accepted answer:

Every spec must contain a verification-seam decision.
When no runtime or observable seam is warranted, record an explicit Not applicable result with rationale; omission is invalid.
Concrete test cases and commands remain plan-owned.

Q39

Prerequisites:

Question: What traceability format links numbered user stories to binary acceptance criteria?

Accepted answer:

Give stories stable US-### ids and criteria stable AC-### ids.
Each acceptance criterion declares Covers: US-### references.
Compilation fails when a user story lacks at least one acceptance criterion or an acceptance criterion maps to no user story.
Keep the mapping in one direction to avoid duplicate relationship lists drifting.

Q40

Prerequisites:

Q24, Q33

Question: What structure and location own the durable prototype verdict and throwaway-branch pointer?

Accepted answer:

Store PROTOTYPE-VERDICT.md beside the prototype on its throwaway branch.
The artifact records question, evidence, verdict, rejected alternatives, unresolved risks, run/inspection instructions, and optional decision-rich snippet.
The prototype backlog item and grill artifacts record an immutable commit-SHA/path pointer.
create-spec consumes the explicitly accepted verdict recorded by the grill, not an unreviewed prototype branch by itself.

Branch Q: Spec Before Backlog

Q41

Prerequisites:

Q28, Q29, Q30

Question: Must create-spec precede backlog creation, with SPEC.md as the direct artifact output of the closed grill?

Accepted answer:

Yes. The grill closes and confirms the decision frontier; create-spec directly compiles those decisions into SPEC.md.
No delivery epic/story projection is created before the authoritative spec exists.
write-backlog consumes the completed spec and projects it afterward.
A pre-spec intake/frontier item may exist, but it is not delivery backlog creation.

Branch R: R4 Orchestration Details

Q42

Prerequisites:

Question: Does requirements orchestration invoke create-spec immediately after grill confirmation, or stop at a spec-ready handoff?

Accepted answer:

After explicit shared-understanding confirmation, requirements-phase immediately invokes create-spec.
requirements-grill remains the decision interview and durable grill-artifact owner; create-spec remains a distinct compiler.
The orchestration reaches spec-written before any delivery backlog projection.

Q43

Prerequisites:

Q37, Q41

Question: What exact readiness marker does successful create-spec emit?

Accepted answer:

Successful compilation adds readiness: agent-ready to SPEC.md frontmatter and returns spec-written.
Readiness remains separate from the existing spec lifecycle status.
spec-not-ready writes no partial spec and emits no agent-ready marker.

Q44

Prerequisites:

Question: Must a prototype verdict be accepted inside requirements-grill before spec compilation?

Accepted answer:

No. Reject the premise that every prototype route must pass through grilling.
wayfinder decides whether the unresolved question needs research, prototype, or grilling; these are alternative decision-closing routes, not mandatory sequential stages.
An accepted prototype may route directly back through finder-phase to create-spec when the overall frontier is closed.
If prototyping exposes unresolved human decisions, finder-phase may then route those decisions to grilling.
The exact acceptance action owned by prototype-phase remains open.
This supersedes any linear interpretation of Q28 that required requirements-grill after every research or prototype route. Q41 remains authoritative when grilling is the selected route.

Q45

Prerequisites:

Q30, Q41

Question: What happens to a pre-spec intake/frontier item after SPEC.md exists?

Accepted answer:

Resolve the intake/frontier item with an immutable link to SPEC.md and a compiled into specification resolution.
Do not silently promote the intake item into a delivery epic because its semantics and readiness contract differ.
write-backlog creates the delivery epic/stories from the authoritative spec afterward.

Branch S: Frontier Convergence And Backlog Materialization

Q46

Prerequisites:

Question: What exact interaction lets prototype-phase accept, reject, or iterate its bounded verdict before returning control to Wayfinder?

Accepted answer:

prototype-phase remains active until the user expresses a verdict in natural language; no special command is required.
Accept: persist the selected answer, supporting evidence, accepted implications, rejected alternatives, and unresolved items in PROTOTYPE-VERDICT.md, then return control to Wayfinder.
Iterate: revise the prototype and verdict on the same throwaway branch and keep the phase active.
Reject: persist the rejection and rationale, leave the bounded question unresolved, and return it to Wayfinder for rerouting.
After any terminal verdict, Wayfinder recomputes the frontier and chooses grilling, research, another prototype, or create-spec from the remaining uncertainty.

Q47

Prerequisites:

Q23, Q34, Q44

Question: What authority and convergence rule lets research, prototype, or grilling close its question and return to Wayfinder?

Accepted answer:

Research may close factual uncertainty supported by its cited evidence, but it does not silently settle product choices.
prototype-phase may close the bounded design question recorded in its accepted verdict.
requirements-grill closes human product, architecture, and implementation decisions through explicit shared-understanding confirmation.
Each child flow returns its answer, evidence, unresolved items, and immutable artifact pointer to finder-phase; Wayfinder reconciles the result and recomputes the frontier.
A prototype does not always route to grilling and does not always bypass it. Wayfinder may next route to grilling, research, another prototype, or create-spec, depending on what remains unresolved.
create-spec begins only when the recomputed frontier is empty or all remaining items are explicitly parked.
This supersedes Q40's grill-specific verdict-consumption rule: create-spec consumes a verdict accepted by prototype-phase when Wayfinder determines that the overall frontier is closed.

Q48

Prerequisites:

Q26, Q39, Q43

Question: What exact approval and ready-for-agent contract does post-spec write-backlog enforce?

Accepted answer:

write-backlog does not stop for a separate human approval checkpoint after receiving an agent-ready spec.
Before provider mutation, validate that the spec is agent-ready, story-to-acceptance-criterion traceability is complete, every story is a vertically demonstrable tracer bullet, and the blocker graph is valid and acyclic.
If validation succeeds, write the delivery epic/stories immediately and mark only validated items ready-for-agent.
If validation fails, fail closed before provider mutation and report the missing or invalid readiness evidence; do not write a partial delivery backlog.
This supersedes the explicit breakdown-approval requirement accepted in Q26. Tracer-bullet completeness, blocker-graph validation, and agent readiness remain required.

Q49

Prerequisites:

Q30, Q45

Question: How should existing backlog-first epics/stories coexist with the new spec-first lifecycle?

Accepted answer:

Park legacy backlog-first coexistence and migration. It is not a current priority.
Do not design or execute a bulk migration as part of this work.
The new spec-first lifecycle governs newly routed work; existing provider items remain untouched unless a later scoped effort decides otherwise.

Branch T: Requirements And Delivery Route Gates

Q50

Prerequisites:

Q42, Q47

Question: Should requirements-phase become the route-gated wrapper for bounded grilling, research, prototype, and spec compilation?

Accepted answer:

Rewrite requirements-phase as a Durable Workflow Graph using write-graph-based-skills in convert mode.
Its owned graph runs requirements-grill -> create-spec -> write-backlog.
requirements-grill owns human decision closure, create-spec owns no-interview compilation, and write-backlog owns provider validation and mutation.
Research and prototype are not internal requirements-phase gates. Finder routes them above requirements and reconciles their results.
Successful requirements completion means the authoritative spec and its verified backlog projection are ready for delivery.
This supersedes Q42's requirements boundary at spec-written: requirements now continues through the delegated write-backlog gate before returning its terminal handoff.

Q51

Prerequisites:

Q28, Q30

Question: Should delivery remove its spec.md and backlog.md phases rather than retain inert compatibility gates?

Accepted answer:

Yes. Remove spec.md and backlog.md from the delivery graph.
delivery-phase begins at the plan gate and does not manage requirements, spec compilation, or backlog projection.
create-plan remains the first delivery-owned delegate.

Q52

Prerequisites:

Q28, Q34

Question: When direct delivery lacks prerequisites, should it stop with a deterministic upstream handoff or execute the upstream route?

Accepted answer:

Add no new prerequisite-error route or upstream-required status to delivery.
Delivery selects its plan gate when no execution-ready plan exists.
The existing minimal grilling inside create-plan handles planning ambiguity under its current contract.
This does not authorize delivery to invoke requirements-grill, create-spec, or write-backlog; those requirements steps remain outside delivery.

Q53

Prerequisites:

Question: Should strict delivery prerequisites leave direct explicit create-plan invocation unchanged?

Accepted answer:

Yes. Preserve direct explicit create-plan behavior unchanged.
Do not require an agent-ready spec for every standalone create-plan invocation as part of this refactor.
The delivery-phase boundary and the create-plan public-entry contract remain distinct.

Q54

Prerequisites:

Q50, Q51, Q52

Question: What exact top-level states and transitions should Finder own across fog, research/prototype, requirements, and delivery?

Accepted answer:

Finder is the thin top-level lifecycle router: fog/charting -> research | prototype | requirements-phase -> delivery-phase -> complete.
Finder uses wayfinder to compute and reconcile the frontier.
Finder may invoke parallel-research or prototype-phase for their bounded work.
Finder always uses requirements-phase for specification and backlog projection; it does not invoke requirements-grill, create-spec, or write-backlog directly.
After research or prototype, requirements-phase may skip grilling when current evidence proves the decisions are already closed or explicitly parked.
requirements-complete means the authoritative spec and its matching backlog projection are verified.
Finder invokes delivery-phase after requirements-complete; delivery begins at plan.
A child returning finder-required causes Finder to reconcile the evidence and recompute the frontier.
Provider mutation remains delegated to write-backlog through the workflow that owns the selected gate.

Q55

Prerequisites:

Question: What artifact guards select requirements-grill, create-spec, write-backlog, or terminal completion on entry and cold resume?

Accepted answer:

Open human decisions or missing shared-understanding confirmation select requirements-grill.
Closed or explicitly parked decisions without a valid retained agent-ready spec select create-spec.
A valid retained agent-ready spec without a verified current matching backlog projection selects write-backlog.
A valid spec plus verified matching backlog projection selects terminal requirements-complete.
Invalid or stale evidence returns to the earliest unmet gate.
If grilling exposes required research or prototype work, return finder-required; do not execute those routes inside requirements.
The requirements router selects exactly one gate and performs no child mutation itself.

Q56

Prerequisites:

Question: Which durable runtime handoff should every requirements gate update so the router can resume deterministically?

Accepted answer:

Persist one <planning-surface>/REQUIREMENTS-HANDOFF.md as the requirements graph's runtime handoff.
Record the current or last gate, phase-scoped status, grill artifact pointers, retained spec SHA and verified URL, backlog projection evidence, validation, blockers, and next suggested route.
Keep this runtime handoff separate from the target skill's AUTHORING-HANDOFF.md, requirements-grill status/log artifacts, SPEC.md, and provider state.
The requirements router re-derives its route from current direct evidence and fresh workflow-native artifacts; the recorded next route remains advisory.

Branch T Closure

Shared-understanding confirmation: explicitly confirmed by the user on 2026-08-06.
Requirements and Finder route-gate decisions Q50-Q56 are closed.
The next workflow action is create-spec; graph authoring and shared-skill implementation have not started.

Wayfinder Backlog Model Grill Log

On this page