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.

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.