Project Backlog Operating Model Grill Log

Source

2026-08-25 meeting: FOG workflow, epic definition, and Linear project setup.

Locked Decisions

Business intake

business-finder is the public Finder entrypoint for nontechnical users.
It must run business-level $grilling, emit one new root Fog, and stop before technical requirements, specifications, epics, or stories.
Business intake does not update an existing Fog.
Existing finder-phase receives the emitted Fog afterward. Its downstream flow is outside this change.

Project initialization and roadmap

Project initialization is separate from Business intake.
It creates or updates the Project brief, project metadata, and first-class provider-visible capability roadmap candidates.
Capability roadmap candidates are backed by the Project brief. They are not epics or stories.
Project initialization never creates delivery epics or stories before grilling is closed and an agent-ready specification exists.

Backlog writing and Normalization

write-backlog remains one public skill with progressive /references structured by writing-for-agents.
Accepted branch references are project-context.md, fog-intake.md, delivery-projection.md, issue-reconciliation.md, backlog-normalization.md, and delivery-status.md.
Accepted provider references are providers/linear.md and providers/github.md. They contain payload mechanics only.
The main file contains the router and always-needed steps. Branch-only rules live behind precise Context pointers.
Definitions, rules, and caveats have one Single Source Truth.
Every step and reference branch has a clear, exhaustive, checkable Completion Criterion.
The always-loaded flow selects the branch, resolves the destination and authority, reads relevant wiki and provider state, builds and validates the complete intended mutation, shows material topology changes, mutates, and performs provider readback.
Completion accounts for every intended item, relationship, source link, and provider state, or returns an explicit zero-write blocker.
Normalization is the canonical branch name. Its invocation cadence is external to the skill branch.

Authority and provider scope

Settings select the destination.
The wiki owns durable product context and rules.
Fresh provider reads prove live backlog state.
Repository and Deployment evidence prove implementation and environment state.
A new explicit human decision resolves a genuine semantic conflict and is persisted in its durable owning source.
The workflow targets Linear and GitHub first. Azure DevOps and monday.com are not current-scope promises.
The normal GitHub mode is Projects V2 plus Issues and sub-issues.
An Issues-only path is not a normal mode. It can be considered only when an unavoidable provider failure makes Projects V2 unavailable.

Delivery and deployment status

The delivery flow must keep the linked provider item current while work progresses.
PR creation, merge, staging deployment, and production deployment are distinct facts.
Merge does not prove deployment. A deployment transition requires evidence for the named environment.

Contradictions and Resolutions

The transcript used "epic" for both high-level product capabilities and implementation containers. Resolution: capability roadmap candidates can exist before a specification; a Delivery epic exists only after grilling is closed and an agent-ready specification exists.
The transcript wanted one familiar lifecycle with a distinct nontechnical entrypoint. Resolution: business-finder performs Business intake and passes its new Fog to the unchanged finder-phase.
Q8 asked how downstream grilling should behave. It is deferred because this change does not redesign the downstream Finder lifecycle.
"Backlog normalization" implied that cadence was part of the branch. Resolution: the canonical name is Normalization; periodic invocation is external behavior.
Earlier GitHub wording allowed an ordinary Issues-only mode. Resolution: GitHub Projects V2 plus Issues and sub-issues is the normal mode.
A merged PR was discussed as an automation input but is not Deployment evidence. Resolution: merge records only the merge fact.

R1 — Accepted Answers

Q1

Prerequisites:

none

Question: What durable output must the nontechnical business entrypoint create, and where must it stop?

Accepted answer:

Business intake does not update an existing Fog.
The nontechnical Finder entrypoint must run business-level $grilling and emit one new root Fog.
It stops before technical requirements, specifications, epics, or stories.
Project initialization remains a separate flow.

State: answered.

Q2

Prerequisites:

none

Question: Should write-backlog be one public progressive entrypoint or several public skills?

Accepted answer:

Keep one public write-backlog skill.
Use progressive /references according to writing-for-agents.
Keep the main file as the router with always-needed steps.
Put branch-only rules behind precise Context pointers.
Keep each definition, rule, and caveat in one Single Source Truth.
Give each step and reference branch a clear, exhaustive, checkable Completion Criterion.

State: answered.

Q3

Prerequisites:

none

Question: Which hierarchy can project initialization create before an agent-ready specification exists?

Accepted answer:

Epics and stories are created only after grilling is closed and an agent-ready specification exists.
Pre-spec project initialization can create project metadata, a Project brief, and capability roadmap candidates.
It cannot create delivery epics or stories.

State: answered.

Q4

Prerequisites:

none

Question: Which source wins when settings, wiki context, repository evidence, Deployment evidence, and provider state conflict?

Accepted answer:

Settings select the destination and provider.
The wiki owns durable product context, goals, constraints, and declared operating rules.
Fresh provider reads prove current backlog state.
Repository and Deployment evidence prove implementation and environment state.
A new explicit human decision resolves a genuine semantic conflict and is persisted in its durable owning source.

State: answered.

Q5

Prerequisites:

none

Question: Which providers does the new workflow target now?

Accepted answer:

Target Linear and GitHub first.
Do not retain Azure DevOps or monday.com as current-scope promises.

State: answered.

R2 — Accepted and Open Decisions

Q6

Prerequisites:

Question: Which fields must Business intake complete before business-finder can emit a Fog?

Accepted answer:

Require actor or user, problem or opportunity, desired outcome and value, evidence and context, constraints and non-goals, priority or urgency, and open questions.
Each field must be populated or explicitly marked unknown.
Do not require a technical solution.

State: answered.

Q7

Prerequisites:

Q1, Q2

Question: What is the precise public name of the nontechnical Finder entrypoint?

Accepted answer:

Create the public business-finder skill.
It composes shared Finder behavior with business-level $grilling, emits one new Fog, and stops.
Shared lifecycle rules remain in one Finder-owned source.

State: answered.

Q8

Prerequisites:

Q1, Q3

Question: How should downstream grilling behave after Business intake emits a Fog?

Disposition:

Defer this question outside the current change.
Existing finder-phase receives the emitted Fog afterward and remains unchanged.

State: deferred.

Q9

Prerequisites:

Question: Which progressively disclosed reference branches should write-backlog have?

Accepted answer:

Use project-context.md, fog-intake.md, delivery-projection.md, issue-reconciliation.md, backlog-normalization.md, and delivery-status.md.
Use providers/linear.md and providers/github.md for provider mechanics only.

State: answered.

Q10

Prerequisites:

Q2, Q4

Question: What stays always loaded in write-backlog, and what is its Completion Criterion?

Accepted answer:

Select the relevant branch and provider.
Resolve authority and destination.
Read relevant wiki context and current provider state.
Build the complete intended mutation.
Validate hierarchy, dependencies, conflicts, and idempotency.
Show proposed topology changes when material.
Mutate and perform provider readback.
Complete only when every intended item, relationship, source link, and provider state is accounted for, or return an explicit zero-write blocker.

State: answered.

Q11

Prerequisites:

Question: What does normal GitHub backlog support mean?

Accepted answer:

Use GitHub Projects V2 plus Issues and sub-issues.
Do not present Issues-only as a normal mode.
Repository or PR linkage alone is not backlog support.

State: answered.

Q12

Prerequisites:

Q3, Q5

Question: How are pre-spec capability roadmap candidates represented?

Accepted answer:

Represent them as first-class provider-visible planning structures backed by the Project brief.
Do not type them as epics or stories.
Keep the exact Linear and GitHub representation provider-specific.

State: answered.

Q13

Prerequisites:

Q3, Q4

Context:

Project initialization can run on a new project or on a project that already has provider items.

Question: On an existing project, which structural changes can project initialization apply without explicit approval?

Accepted answer:

On a new project, create the Project brief, project metadata, and capability roadmap candidates.
On an existing or inherited project, read the wiki and fresh provider state first, then show a reconciliation plan.
Apply safe additive metadata fixes after preflight.
Require explicit approval before closing duplicates, reparenting or merging items, or moving milestones and roadmap candidates.

State: answered.

Q14

Prerequisites:

Accepted terminology correction:

The canonical branch name is Normalization.
Periodic execution is external behavior and is not part of the branch name or intrinsic contract.

Question: Which evidence-backed changes can Normalization apply without explicit approval?

Accepted answer:

Allow link and status repairs only when fresh evidence proves the correct value and stale-state preflight passes.
Require explicit approval before closing duplicates, merging, splitting, reparenting, or moving milestones and roadmap candidates.

State: answered.

Q15

Prerequisites:

Q4, Q5

Evidence anchor:

.agents/skills/delivery-phase/phases/closeout.md

Observed constraint:

Current delivery wording reports tracker and PR state at closeout, but it does not require an immediate provider update when work changes state.

Question: When delivery-phase observes a delivery state change, must it update the linked provider item immediately rather than wait for closeout?

Accepted answer:

Yes. Update the linked item when work starts, becomes blocked, or gains a PR link.
If delivery directly observes merge or Deployment evidence, record that exact fact immediately.
Do not infer deployment from merge.
External pipeline automation is a separate concern and is not required by this skill change.

State: answered.

R3 — Transcript Audit: Reopened Requirements

The R2 model was not complete. It reduced the roadmap to Capability roadmap candidates and placed pipeline automation outside scope. The transcript and the user's correction require both branches in the active design.

Recovered project initialization requirements

Add a first-class Project initialization flow for greenfield, inherited, and existing projects.
Create or reconstruct the Project brief from the wiki, repository, and fresh provider state.
Persist business objectives, product goal, users, value, durable constraints, product boundaries, operating rules, methodology, and roadmap intent once at project level.
Create or update provider project metadata instead of repeating global context in every Fog.
Pin the repository and durable wiki/Project brief links to the provider project.
Reconstruct existing capabilities and current roadmap for inherited projects.
Reuse existing Capability boundaries when they fit. Propose a new boundary when the product expands into a new responsibility.
Keep Capability roadmap candidates distinct from Delivery epics and stories.

Recovered roadmap and view requirements

Project initialization scaffolds V1, V2, and V3 as a rough Product roadmap.
The roadmap must show what exists and what is coming without requiring a product owner to inspect every Fog.
Roadmap milestones represent product versions. Sprint Iterations remain a separate scheduling concept.
Project initialization creates provider views for a nontechnical product owner.
Normalization keeps project metadata, the roadmap, provider views, hierarchy, links, and status aligned with current wiki, repository, and provider evidence.
The current write-backlog M1/M2/M3 execution-milestone rule conflicts with V1/V2/V3 product milestones and must be revised during specification.

Recovered pipeline and release-history requirements

Direct commits to main are prohibited. Delivery reaches main through a PR.
PR merge, staging deployment, and production deployment are separate Delivery status facts.
CI/CD events update linked provider items automatically for merge, staging deployment, and production deployment.
Merge does not prove deployment.
The pipeline is multistage.
Production promotion is an explicit manual action.
Release provenance records the release branch and the time at which each linked item shipped.
Status history must preserve the exact environment and evidence instead of collapsing all events into "done."

Q16

Prerequisites:

Q2, Q13

Question: Should Project initialization be a write-backlog reference branch, a distinct public skill, or both through a thin public entrypoint?

Recommendation:

Keep one mutation authority in write-backlog.
Add a project-initialization.md reference branch.
If a memorable public command is needed, use a thin public project-initialization entrypoint that delegates to that branch and adds no duplicate rules.

State: unanswered.

Q17

Prerequisites:

Q4, Q13

Question: Which Project brief and provider project metadata fields are mandatory?

Recommendation:

Require product goal, problem space, target users, value, success signals, product boundaries, current capabilities, durable constraints and non-goals, operating rules, delivery methodology, roadmap policy, owners, provider project link, primary repository link, and wiki/Project brief link.
Add target dates, teams, members, labels, and lead only when the provider supports them and the value is known.
Store durable meaning in the wiki and project it into provider-native metadata without duplicating authority.

State: unanswered.

Q18

Prerequisites:

Question: How do V1/V2/V3 represent already released, current, and planned capabilities, and how are Iterations kept separate?

Recommendation:

Treat V1/V2/V3 as product-version Roadmap milestones.
Mark already shipped capabilities with exact release facts instead of creating a fake "Current" milestone.
Assign current and planned Capability roadmap candidates to V1/V2/V3.
Use provider Iterations only for sprint or time-box scheduling. Never use Iterations as product-version milestones.

State: unanswered.

Q19

Prerequisites:

Question: Which provider views must Project initialization create for a nontechnical product owner?

Recommendation:

Roadmap: capabilities grouped by V1/V2/V3 with released, current, and planned state.
Intake: open Fogs and unresolved business questions.
Delivery: active Delivery epics and stories with PR, staging, and production facts.
Releases: shipped work grouped by version or release branch with shipped time.
Keep implementation-only detail out of the default Roadmap view.

State: unanswered.

Q20

Prerequisites:

Question: Which exact Delivery status facts and Release provenance fields must CI/CD write?

Recommendation:

Record PR URL, merge commit, merge time, staging deployment time and evidence URL, production deployment time and evidence URL, release branch, shipped commit, and provider item IDs.
Make every event idempotent and append evidence history even if the provider also exposes a current status field.
A failed or rolled-back deployment records a new fact; it does not erase prior history.

State: unanswered.

Q21

Prerequisites:

Question: Must Project initialization enforce repository PR protection, or verify it and stop when it is missing?

Recommendation:

Verify branch protection or repository rulesets during Project initialization.
Report a zero-write blocker when direct commits to main remain possible.
Apply or change repository protection only through an explicit repository-setup action because it changes repository governance.

State: unanswered.

Q22

Prerequisites:

Q5, Q11

Question: Must pipeline status synchronization have Linear and GitHub parity now, or is Linear the first complete implementation?

Recommendation:

Define one provider-neutral Delivery status and Release provenance contract.
Implement complete Linear synchronization first because the transcript names Linear tasks.
Keep GitHub Projects V2 and Issues mapping required in the same skill design, but do not claim runtime parity until its pipeline adapter is implemented and verified.

State: unanswered.

R4 — Roadmap Correction and Scope Reduction

This round supersedes the active R3 roadmap and pipeline framing.

Superseding roadmap decisions

Do not scaffold a fixed V1/V2/V3 sequence.
Project initialization creates or reuses a contextual current and future V* Version milestone.
The project can already have other Version milestones; the skill must preserve valid existing structure.
The skill does not model sprints or Iterations.
Replace the current generic M1/M2/M3 execution-milestone rule with contextual V* Version milestone guidance.
Reopen the meanings of existing, current, and coming for deeper grilling.

Superseding scope decision

CI/CD design is not part of this work.
Park pipeline event mapping, branch-protection enforcement, release-branch provenance, shipped-time automation, and Linear/GitHub pipeline adapter parity.
Preserve those transcript requirements as parked context. Do not design or implement them now.
Keep the accepted Q15 rule: delivery-phase updates linked provider items with facts it directly observes.

Q18 — Superseded Answer

Prerequisites:

Question: How should Project initialization scaffold roadmap milestones, and are sprints or Iterations part of this model?

Accepted answer:

Create or reuse a current and future product Version milestone using the project's V* convention.
Do not assume exactly V1/V2/V3.
Preserve valid existing Version milestones.
Do not model sprints or Iterations.
Replace generic M1/M2/M3 execution-milestone guidance with contextual V* Version milestone guidance.

State: answered.

Q20-Q22 — Superseded Disposition

Disposition:

Park Q20 Delivery pipeline event and release-provenance design.
Park Q21 branch-protection enforcement design.
Park Q22 Linear/GitHub pipeline adapter parity.

State: parked.

Q23

Prerequisites:

Question: Which product objects belong on the Product roadmap, and which must stay out?

Recommendation:

Show Capability boundaries and Capability roadmap candidates.
Do not show individual Fogs, grilling/research/prototype items, Delivery stories, or implementation tasks in the default Product roadmap.
A Delivery epic can contribute progress to a capability but should not become the roadmap's primary product object.

Why:

The roadmap should explain product shape, not reproduce the issue tracker.

State: unanswered.

Q24

Prerequisites:

Question: What do existing, current, and coming mean on the Product roadmap?

Recommendation:

Existing: a user-visible business capability already available in the product, supported by current product evidence.
Current: an accepted capability outcome assigned to the active V* Version milestone.
Coming: an accepted Capability roadmap candidate assigned to the next future V* Version milestone.
Unresolved Fogs and unscheduled ideas stay outside these three groups.

Why:

This separates product reality, committed current direction, and accepted future direction without using delivery-task status as product meaning.

State: unanswered.

Q25

Prerequisites:

Q18, Q24

Question: How does Project initialization choose or create the current and future V* Version milestones without inventing version numbers?

Recommendation:

Reuse provider Version milestones when their current/future meaning is clear.
If the Project brief or provider does not identify the active version, ask the user for the current V* name.
Derive the next future name only when the project's version rule makes the result deterministic; otherwise ask.
For a greenfield project with no version decision, propose V1 as current and V2 as future, but require confirmation before provider writes.

Why:

Version names are product commitments. The skill must not fabricate them from issue order.

State: unanswered.

R5 — Milestone-First Roadmap

This round supersedes the R4 recommendations for Q23-Q25.

Q23

Accepted answer:

Keep two semantic layers.
The Product map shows what exists.
The Product roadmap shows current and future product direction.

State: answered.

Q24 — Superseded Answer

Question: What is the primary Product roadmap item?

Accepted answer:

The Version milestone itself is the Product roadmap item.
Capability boundaries and Capability roadmap candidates can inform a Version milestone, but they are not separate primary roadmap items.
The Product roadmap must remain understandable from milestone-level metadata without requiring the reader to inspect every member issue.

State: answered.

Q25 — Superseded Answer

Question: How do existing, current, and future product direction relate to Version milestones and Fogs?

Accepted answer:

The Product map shows capabilities that already exist.
The Product roadmap contains a current and future V* Version milestone.
A Fog can belong to a Version milestone even though it is not delivery-ready.
An unassigned Fog remains outside the Product roadmap.
Project initialization does not model sprints or Iterations.

State: answered.

Q26

Prerequisites:

Question: Which metadata must a Version milestone contain so a product owner understands it without opening member items?

Recommendation:

Version name.
One-sentence product goal.
Product outcomes or capability changes included.
Explicit non-goals.
State: current, future, released, or retired.
Optional target window rather than a required exact date.
Success signals.
Links to the Project brief and relevant repository or product evidence.
A generated summary of member Fogs and other work, without copying their full descriptions.

State: unanswered.

Q27

Prerequisites:

Q24, Q25

Question: Which backlog concepts can belong to a Version milestone, and which must not?

Recommendation:

Permit Fogs, grilling, research, prototypes, Capability roadmap candidates, and Delivery epics.
Let stories share their containing Delivery epic's Version milestone for provider filtering when supported, but do not use Version milestones to sequence stories.
Keep operational chores and implementation-plan tasks out unless they express a product-version outcome.

State: unanswered.

Q28

Prerequisites:

Question: Who can assign or move a Fog between Version milestones, and when can write-backlog do it automatically?

Recommendation:

business-finder can preserve an explicit Version milestone chosen during Business intake.
write-backlog can assign a Fog when the source names the milestone or one deterministic project rule applies.
Otherwise leave the Fog unassigned and ask; do not schedule it from priority alone.
Moving a Fog between Version milestones changes roadmap commitment and requires explicit approval.
When a Fog later produces a Delivery epic, preserve the Version milestone unless a new explicit decision changes it.

State: unanswered.

R6 — Milestone Metadata and Membership Closure

Q26 — Superseded Answer

Question: Which metadata must a Version milestone contain?

Accepted answer:

Version name.
One-sentence product goal.
Included product outcomes or capability changes.
If the provider does not support the goal and outcome fields, a plain milestone with its version name is sufficient.
Do not require state, dates, success signals, links, or generated summaries as milestone metadata.

State: answered.

Q27 — Superseded Answer

Question: Which ticket types belong to a Version milestone?

Accepted answer:

Every ticket type belongs to a Version milestone.
This includes Fogs, grilling, research, prototypes, Capability roadmap candidates, Delivery epics, stories, and other provider tickets.
Stories are included directly; Version milestone membership is not limited to their parent Delivery epic.

State: answered.

Q28

Accepted answer:

Preserve a Version milestone explicitly selected during Business intake.
write-backlog can resolve a milestone when the source names it or a deterministic project rule applies.
If no milestone can be resolved, ask before writing the ticket; do not persist an unassigned provider ticket.
Moving a ticket between Version milestones changes roadmap commitment and requires explicit approval.
When a Fog produces downstream tickets, preserve its Version milestone unless an explicit decision changes it.

State: answered.

R7 — Entrypoint and View Closure

Q16 — Superseded Answer

Question: What is the public entrypoint for Project initialization?

Accepted answer:

write-backlog is the public entrypoint.
Project initialization is a progressively disclosed write-backlog reference branch.
Do not create a separate public Project initialization skill.

State: answered.

Q17

Question: Which enhanced Project brief and provider metadata fields are mandatory?

Accepted answer:

Project goal and business objectives.
Target users.
Product boundaries.
Existing Capability map.
Durable constraints and non-goals.
Operating rules.
Owner.
Repository link.
Wiki or Project brief link.
Current and future V* Version milestone names.
The wiki owns the complete durable meaning. Provider metadata contains the fields it supports.

State: answered.

Q19

Question: Which Product-owner views must Project initialization create when the provider supports them?

Accepted answer:

Product Map: existing Capability boundaries.
Roadmap: current and future Version milestones.
Fogs: Fogs grouped by Version milestone.
Current Delivery: active tickets grouped by Version milestone and status.
Do not add CI/CD or Releases views in this scope.

State: answered.

Q29

Question: Which grilling workflow does business-finder compose?

Accepted answer:

business-finder wraps the atomic $grilling primitive directly.
It does not invoke, load, activate, or inherit the durable $requirements-grill workflow.
Atomic $grilling gathers the business fields, business-finder emits one Fog, and the entrypoint stops.
Existing finder-phase receives the Fog afterward.

State: answered.

R8 — Existing Write-Backlog Contract

Q30

Question: Does the refactor preserve the current write-backlog behavior used to structure tickets?

Accepted answer:

Yes. This is an additive refactor.
Preserve the existing pre-spec intake and post-spec delivery-projection workflows.
Preserve direct classification of Fog, grilling, research, prototype, Delivery epic, and story tickets.
Preserve root Fog hierarchy placement while also requiring its Version milestone membership.
Preserve Capability boundary placement for concrete work.
Preserve the agent-ready specification gate before Delivery epic and story creation.
Preserve US/AC traceability, product-facing vertical stories, minimal item count, and no layer-task decomposition.
Preserve parent-child hierarchy, complete blocker resolution, self-edge and cycle rejection, and provider-native dependency relations.
Preserve the proposed-topology presentation, zero-write preflight, provider mutation, provider readback, and honest partial-failure reporting.
Project initialization, contextual Version milestones, Product-owner views, reconciliation, Normalization, and delivery-status behavior extend this contract; they do not replace it.

State: answered.

R9 — Business Structure and Delivery-Axis Reopening

The 2026-08-26 follow-up transcript and operator corrections reopen the milestone-first model before shared-understanding confirmation. These are proposed supersessions until Q31-Q33 are answered.

New evidence and corrections

Backlog mutation must reuse a fitting existing milestone; it must not create a new milestone by default.
business-finder must read existing Epics and milestones before finishing its business grill. Desired behavior is reuse, linking, and enrichment instead of default creation.
The previous one-spec Delivery Epic may be the wrong semantic unit. The proposed Epic is a long-lived business slice that groups Stories and supports native blocker relationships.
The proposed delivery hierarchy is Epic → Story → Task. Story and Task represent actual delivery work.
The proposed stable product hierarchy is Product Area → Initiative → Epic. Backlog initialization creates or reconstructs Product Areas and Initiatives; Epics arise from later Fog/spec work.
Fog is proposed as a lateral intake and provenance record. It links to the Epics and Stories it produced or enriched instead of owning them as children.
Fog completion is proposed to mean that its resulting delivery scope reached production, not merely that grilling, specification, or ticket creation finished.
Milestones are proposed as delivery iterations. This reopens the prior axiom that every ticket type belongs to one product-version milestone.
CI/CD workflow design remains parked. Production evidence is a lifecycle requirement, not authorization to design pipelines.

Q31

Prerequisites:

Q1, Q3, Q29, Q30

Evidence anchors:

.agents/skills/write-backlog/SKILL.md:Pre-spec intake
.agents/skills/write-backlog/SKILL.md:Agent-ready delivery projection

Observed constraint:

Current pre-spec intake creates exactly one requested Fog, grilling, research, or prototype item. Current Epic and Story mutation is specification-gated. Allowing business-finder to create or materially rewrite Product Areas, Initiatives, or Epics would supersede that gate.

Question:

What may business-finder mutate besides its newly emitted Fog?

Recommendation:

It reads the current Product Areas, Initiatives, Epics, and milestones during business grilling.
It always creates one new Fog.
It may attach exact existing-structure and milestone relations and add a Fog backlink to an exact existing Epic.
It must not change an existing Epic's scope or create a Product Area, Initiative, Epic, Story, or Task before the normal Finder → grilling/specification flow reaches write-backlog.
If the request appears to need a new Product Area or Initiative, it warns that the request expands product scope and routes the structural proposal through Backlog initialization.

Why:

This gives the business user structure-aware intake and reuse without bypassing the accepted specification gate.

State: unanswered.

Q32

Prerequisites:

Q18, Q24-Q28

Evidence anchors:

.agents/skills/write-backlog/assets/concepts/backlog-model.md:Canonical model
.agents/skills/write-backlog/assets/providers/linear-create-payload.md:Chronological execution milestones

Observed constraint:

Current guidance assigns milestones from Fog through Epic and may copy the containing milestone to Stories. R9 proposes long-lived Epics outside milestones and calls milestones iterations, while earlier accepted answers use contextual V* product versions and exclude sprint modeling.

Question:

What does a V* milestone mean now, and which objects belong to it?

Recommendation:

A V* milestone is a versioned delivery increment, not a sprint and not a provider Iteration object.
Product Areas, Initiatives, and long-lived Epics stay outside milestone membership.
Each Story and its Tasks belong to exactly one V* milestone.
A Fog may target an existing V* milestone when business intake selects a fitting one. Its final completion record names the milestone in which its last required Story reached production.
Reuse a fitting milestone before proposing a new one. Movement remains an approval-requiring roadmap change.

Why:

This preserves the accepted V* language, avoids sprint modeling, and lets long-lived business structure span several delivery increments.

State: unanswered.

Q33

Prerequisites:

Q12, Q17, Q30

Evidence anchors:

.agents/skills/write-backlog/assets/concepts/backlog-model.md:Canonical model
.agents/skills/write-backlog/SKILL.md:Direct taxonomy

Observed constraint:

Current code language is Backlog root → Capability module → Epic → Story. Epic is one agent-ready specification projection, and Task does not exist. R9 proposes Product Area → Initiative → Epic → Story → Task, with Fog linked laterally.

Question:

Is the canonical provider-neutral structure below correct?

Product Area
  Initiative
    Epic
      Story
        Task

Fog --contributes to/enriches--> Epic
Fog --produces/traces--> Story
Story/Task --scheduled in--> V* milestone

Recommendation:

Accept this topology.
Define Product Area as a stable product responsibility; Initiative as one business goal inside one Product Area; Epic as a long-lived business slice inside one Initiative; Story as a shippable product outcome; Task as optional implementation work under one Story.
Keep Fog outside the ownership tree as intake, decision history, and delivery provenance.

Why:

This separates stable product structure, business slices, executable work, delivery increments, and intake history without making one concept serve several jobs.

State: unanswered.

R10 — Topology Pinned, Provider and Scope Frontier

Q31 — Accepted Answer

Supersedes the unanswered R9 recommendation.

Accepted answer:

business-finder reads current Product Areas, Initiatives, Epics, and milestone iterations during business grilling.
It always emits one new Fog.
It may enrich an existing Product Area or Initiative during Business intake.
It may link the Fog to exact existing structure and a fitting existing milestone iteration.
It does not create Stories or Tasks and does not resolve the Fog.
Technical Fog resolution remains behind the existing Finder technical requirements grilling and specification gate.

State: answered.

Q32 — Accepted Answer

Supersedes Q24-Q28 where their milestone-first membership rules conflict.

Accepted answer:

A contextual V* milestone is semantically a delivery iteration.
It is not a sprint and this work does not model provider Cycles or Iteration fields.
Product Areas, Initiatives, and Epics span milestone iterations.
Every Story and Task belongs to exactly one V* milestone iteration.
A Fog may target a fitting existing milestone iteration.
Fog completion records the milestone iteration in which its last required delivery work reaches production.
Reuse a fitting existing milestone before proposing a new one.
Moving work between milestones remains an approval-requiring commitment change.

State: answered.

Q33 — Accepted Answer

Supersedes the prior one-spec Delivery Epic meaning and Q30's no-layer-task clause.

Accepted topology:

Product Area
  Initiative
    Epic
      Story
        Task

Fog is external to this ownership hierarchy.
Story and Task belong to a V* milestone iteration.

Accepted definitions and invariants:

Product Area is a stable top-level product responsibility.
Initiative is a business goal within one Product Area.
Epic is a long-lived business slice within one Initiative.
Story is a shippable product outcome within one Epic.
Task is a required atomic shippable unit of Story work.
Every Story has one or more Tasks.
Every Task has explicit ownership and blocker relations. The Task graph supplies precedence and safe parallel delivery waves for plan-owned subagents.
Fog is the external intake, uncertainty, decision-history, and delivery-provenance record.
Business intake can enrich existing Product Areas and Initiatives.
Fog resolution runs through existing technical requirements grilling and an agent-ready specification.
After that gate, write-backlog enriches a fitting Epic or creates a justified Epic, then creates the Stories and required Tasks.
Fog retains provenance links to each Product Area, Initiative, and Epic it enriched and to each Story and Task produced during resolution.

State: answered.

Q34

Prerequisites:

Evidence:

Linear supports nested Initiatives but does not support nested Projects.
GitHub Projects V2 does not support native Initiatives or nested Projects.
Both providers support issue/sub-issue hierarchy deep enough for Story and Task.

Question:

What provider-native mapping represents Product Area → Initiative → Epic → Story → Task?

Recommendation:

Linear: Product Area = parent Initiative; Initiative = sub-Initiative; Epic = Project; Story = Issue; Task = sub-issue.
GitHub: use one Projects V2 operating surface; represent Product Area → Initiative → Epic → Story → Task through typed hierarchical issues/sub-issues and configured fields where needed.
Treat “Linear subproject” as an imprecise label. Linear's native nested object is the Initiative.

Why:

This keeps the accepted semantic topology while respecting each provider's actual objects.

State: unanswered.

Q35

Prerequisites:

Question:

May one Fog span several Product Areas, Initiatives, or Epics?

Recommendation:

A Fog normally belongs to one Product Area and one Initiative.
It may enrich one or more Epics within that Initiative.
If the business request crosses Product Areas or Initiatives, business-finder must warn that the request spans business goals and ask whether to split the Fog or explicitly continue as one broad Fog.

Why:

This keeps delivery provenance understandable while preserving a deliberate escape hatch for genuine cross-area work.

State: unanswered.

Q36

Prerequisites:

Q31, Q33

Evidence:

Neither Linear nor GitHub performs semantic duplicate detection or atomic hierarchy upsert.
Names and titles are not safe identity.

Question:

When may Business intake or write-backlog enrich or create Product Areas, Initiatives, and Epics?

Recommendation:

Match by stable provider ID or durable wiki identity marker, then read current provider state.
Enrich one exact match.
Stop on ambiguous matches.
Business intake may add business context to an existing Product Area or Initiative automatically after preflight.
Boundary, goal, parent, or roadmap changes require explicit approval.
When no Product Area or Initiative matches, warn about scope expansion and require explicit approval before Backlog initialization creates it.
After the specification gate, write-backlog enriches one exact Epic match or creates a new Epic only when the specification proves a distinct business slice.

Why:

This implements “never duplicate initiatives” as a fail-closed identity rule and still permits controlled scope growth.

State: unanswered.

R11 — Provider API Validation and Epic Projection Entrypoint

Q34 — Accepted Answer with API Validation

Accepted mapping:

Linear: Product Area = parent Initiative; Initiative = sub-Initiative; Epic = Project; Story = Issue; Task = sub-issue.
GitHub: one Projects V2 operating surface; Product Area → Initiative → Epic → Story → Task is projected through typed hierarchical issues/sub-issues and configured fields where needed.

Linear API evidence:

The live Devpunks workspace exposes Initiative parent/sub-Initiative relations.
save_project supports Initiative membership.
save_issue supports project, parentId, milestone, blockedBy, blocks, and relatedTo.
save_milestone creates or updates Project milestones.
Live Harness project ID is 5780e683-0f87-4c6c-85dc-9122dcee9023.
The current Harness Project has no Initiative, has M1-M14 milestones, and contains existing Epic issues with Story children.
MCP aliases are crossed in this session: linear_collective reaches Devpunks while linear_devpunks reaches Collective Intelligence. Runtime preflight must verify workspace and stable provider identity.

GitHub API evidence:

The GitHub plugin read the private wearedevpunks/harness-intelligence repository and current Issues REST API.
Issue create/update exposes repository milestone membership.
GitHub documents REST sub-issue endpoints and Projects V2 GraphQL items/fields.
Current GitHub plugin tools do not expose Projects V2 or sub-issue mutations.
The local GitHub token lacks read:project; a live Projects V2 read fails with insufficient scopes.
Full GitHub projection must stop in preflight until Projects V2 read/write scopes and sub-issue mutation are available. It must not silently degrade to a flat Issues-only hierarchy.

State: answered.

Q35 — Accepted Answer

Accepted answer:

A Fog normally targets one Product Area and one Initiative.
It may enrich one or more Epics within that Initiative.
If a request crosses Product Areas or Initiatives, business-finder shows the scope visually, warns that it spans business goals, and asks whether to split the Fog or explicitly proceed with one broad Fog.

State: answered.

Q36 — Accepted Answer

Accepted answer:

Resolve stable provider ID or durable wiki identity, then read current provider state.
Enrich one exact match.
Stop before all writes when matches are ambiguous.
Business intake may add business context to an existing Product Area or Initiative after preflight.
Boundary, goal, parent, or roadmap changes require explicit approval.
No matching Product Area or Initiative triggers a scope-expansion warning and explicit approval before Backlog initialization creates it.
After the specification gate, write-backlog enriches one exact Epic match or creates a new Epic only when the specification proves a distinct business slice.

State: answered.

Q37 — Epic Creation Entrypoint

Accepted answer:

write-backlog is the only public Epic creation/upsert entrypoint.
Existing finder-phase invokes it after the Fog's technical requirements grilling is closed and an agent-ready specification exists.
The Epic-projection branch resolves the Fog's Product Area and Initiative, reads existing Epics, and shows the proposed topology.
It enriches one exact fitting Epic or creates a new Epic only when the specification proves a distinct business slice.
It then creates the specification's Stories and mandatory atomic Tasks, assigns their V* milestone iteration, creates blocker relations, records Fog provenance, and reads provider state back.
There is no separate public Epic-creation skill.

State: answered.

Q38 — Business Finder Grilling Presentation

Accepted answer:

Atomic $grilling remains the business interview scheduler.
Every frontier question and recommendation is passed through $wait-what and stated in simple business language.
Before the first question, business-finder uses $show-me to display relevant existing Product Areas, Initiatives, Epics, and milestone iterations.
It uses $show-me again for every scope, structure-reuse, new-structure, or milestone decision.
Before writing the Fog, it shows a final impact graph with reused, enriched, proposed-new, and unresolved structures.
The graph is a reasoning view; durable provider/wiki state remains authority.

State: answered.

Q39

Prerequisites:

Observed constraint:

The current setting identifies one Linear Project as the backlog destination.
In the accepted mapping, every Epic is a Linear Project, so one Project cannot own the complete backlog topology.

Question:

What durable destination identifies the backlog above several Epic Projects?

Recommendation:

Make the provider workspace the mutation boundary.
Let the wiki-owned Project brief hold the stable provider IDs for Product Areas and Initiatives.
Treat the existing singular backlogProjectUrl as legacy input to reconstruction, not as the future topology root.
Do not create an artificial root Initiative only to preserve one URL.

Why:

Product Areas and Initiatives are workspace-level Linear objects, and several Epic Projects may sit below them.

State: unanswered.

Q40

Prerequisites:

Question:

Which Task blocker edges may cross Stories, Epics, or milestone iterations?

Recommendation:

Allow blockers within one Story, across Stories, and across Epics when the dependency is real.
A Task in Vn may depend only on Tasks in the same or an earlier milestone iteration.
Reject dependencies on a future milestone, missing targets, self-edges, and cycles.
Preflight validates the complete reachable Task graph, including referenced Tasks outside the newly written Story set.
Planning derives parallel waves from Tasks whose blockers are satisfied.

Why:

This preserves truthful architecture dependencies while preventing a current delivery iteration from depending on unscheduled future work.

State: unanswered.

Q41

Prerequisites:

Question:

How do Cancelled and Superseded differ from production-complete Fog?

Recommendation:

Complete: every remaining accepted Story and Task produced by the Fog has production evidence.
Cancelled: the business request was abandoned; it receives no completion credit.
Superseded: one or more linked successor Fogs own the remaining intent; it receives no completion credit.
Removing work from a Fog's accepted scope requires an explicit approved scope change before the remaining work can qualify for Complete.
A shared Epic may remain open after the Fog completes; only the Fog-derived scope controls Fog completion.

Why:

This prevents ticket closure, cancellation, or replacement from being reported as shipped value.

State: unanswered.

Q42

Prerequisites:

Q33-Q35

Question:

What must the Product Map, Roadmap, Fogs, and Current Delivery views show?

Recommendation:

Product Map: Product Area → Initiative → Epic, with existing product shape and no delivery-task noise.
Roadmap: ordered V* milestone iterations, with Story/Task progress rolled up to Epic and Initiative outcomes.
Fogs: business status, affected Product Area/Initiative/Epics, target iteration, generated Stories/Tasks, and completion iteration/evidence.
Current Delivery: active Stories and Tasks grouped by milestone iteration, status, owner, and blocker readiness.

Why:

Each view answers one product-owner question without reproducing the entire backlog.

State: unanswered.

R12 — Blocker Closure, Provider Roots, and Functional Intake

Q39 — Corrected evidence, still open

Prerequisites:

Evidence anchors:

.devpunks/settings.json:backlogProjectUrl
apps/cli/src/features/project-settings/model.ts:ProjectSettingsDocument
Linear list_initiatives, get_project, and Initiative mutation contracts

Observed constraint:

The current backlogProjectUrl identifies one Linear Project.
In the accepted mapping, each Epic is a Linear Project, so that URL cannot identify the whole product backlog.
Linear supports several independent top-level Initiative trees in one workspace. The live Devpunks workspace already has separate Internal projects and Customer projects roots.
The existing settings key must change and existing settings must be migrated. Treating the old URL only as permanent reconstruction input is not accepted.

Question:

Should each configured product use one top-level Linear Initiative as its Product/Backlog Root, with Product Areas and Initiatives nested below it?

Recommendation:

Yes. One Linear workspace can contain several independent product trees.
Bind settings to the selected workspace and the stable Product/Backlog Root Initiative identity.
Migrate the current singular Project URL into that root model through a previewed, explicit structural migration.
Decide the exact replacement settings fields only after this root object is accepted.

Why:

This gives each product one durable destination above all Epic Projects without forcing a separate Linear workspace per product.

State: unanswered.

Q40 — Accepted answer

Prerequisites:

Accepted answer:

A Task blocker may stay within one Story or cross Stories and Epics when the dependency is real.
A Task assigned to Vn may depend only on Tasks in Vn or an earlier V* milestone iteration.
Reject missing targets, future-iteration dependencies, self-edges, and cycles.
Validate the full reachable Task graph, not only the newly created edges.
Planning derives sequential and parallel delivery waves from the Tasks that are ready after blocker validation.

State: answered.

Q41 — Accepted semantics and provider evidence

Prerequisites:

Accepted answer:

Complete means every remaining accepted Story and Task produced for the Fog has production evidence.
Cancelled means the business request was abandoned and receives no completion credit.
Superseded means one or more linked successor Fogs own the remaining intent and the old Fog receives no completion credit.
Removing work from accepted Fog scope requires an explicit approved scope change before the remaining work can qualify as Complete.
A shared Epic may remain open after one Fog completes. Fog completion measures only that Fog's accepted delivery scope.

Provider evidence:

The live Linear IP team has Done, Canceled, and Duplicate states.
Linear issue mutation supports duplicateOf, blocker, related-item, parent, project, and milestone relations.
There is no current native Superseded issue state. Exact non-duplicate successor mapping remains Q44.

State: answered.

Q42 — Accepted answer

Prerequisites:

Q33-Q35

Accepted answer:

Product Map shows Product Area → Initiative → Epic as the existing product shape, without Story or Task noise.
Roadmap shows ordered V* milestone iterations and rolls Story and Task progress up to Epic and Initiative outcomes.
Fogs shows business status, affected Product Areas, Initiatives, and Epics, target iteration, generated Stories and Tasks, completion iteration, and production evidence.
Current Delivery shows active Stories and Tasks grouped by milestone iteration, with status, owner, and blocker readiness.

State: answered.

GitHub CLI validation

Evidence:

gh issue list reads the private wearedevpunks/harness-intelligence repository.
gh api repos/wearedevpunks/harness-intelligence/issues/164/sub_issues succeeds, proving the REST sub-issue surface is available to the current login.
GraphQL schema introspection exposes ProjectV2, Project V2 items, fields and views, Issue parent, subIssues, blockedBy, and blocking, plus addSubIssue, removeSubIssue, addBlockedBy, removeBlockedBy, and Project V2 mutation operations.
gh project list --owner wearedevpunks and live Project V2 queries fail because the current token has repo but not read:project.

Consequence:

The accepted GitHub topology is supported by the API shape.
Runtime discovery of the organization's actual Projects V2 instances remains a zero-write preflight blocker until suitable Project scope is available.

Q43 — Functional Finder handoff boundary

Prerequisites:

Q1, Q7, Q8, Q33

Evidence anchors:

.agents/skills/finder-phase/SKILL.md:Core Loop
.agents/skills/grilling/SKILL.md
.agents/skills/write-backlog/SKILL.md:Pre-spec intake

Observed constraint:

Existing finder-phase owns downstream Fog resolution and write-backlog owns provider mutations.
business-finder is already constrained to atomic $grilling, one emitted Fog, and no full $requirements-grill inheritance.
The requested functional-finder is for CTOs and technical managers who need high-level technical framing without bypassing the existing full technical requirements and specification gate.

Question:

Must functional-finder also emit exactly one Fog and stop before full technical requirements, specification, Stories, and Tasks?

Recommendation:

Yes.
Wrap atomic $grilling directly, not $requirements-grill.
Capture high-level technical and functional context in one Fog.
Hand that Fog to the unchanged downstream finder-phase for full technical resolution later.

Why:

This gives technical leaders a distinct intake language without creating a second delivery path or pretending a management-level technical grill is an agent-ready specification.

State: unanswered.

Q44 — Linear mapping for a non-duplicate Superseded Fog

Prerequisites:

Observed constraint:

The live Linear team has Done, Canceled, and Duplicate, but no Superseded state.
duplicateOf is truthful only when the successor represents the same request. A successor can instead replace or absorb intent without being a duplicate.

Question:

How should Linear represent a Superseded Fog when the successor is not a duplicate?

Recommendation:

Use Duplicate plus duplicateOf only for a true duplicate.
Otherwise use Canceled, record the terminal reason as Superseded, and link every successor Fog explicitly.
Never give either representation completion credit.

Why:

This uses Linear's actual states without falsely calling changed intent a duplicate.

State: unanswered.

R13 — Staged Grilling Projection

Q39 — Accepted answer

Prerequisites:

Accepted answer:

Every configured product uses one top-level Linear Initiative as its Product/Backlog Root.
One Linear workspace may contain several independent Product/Backlog Root Initiative trees.
Product Areas and Initiatives nest beneath that root; Epic Projects attach to the matching Initiative structure.
Existing .devpunks/settings.json values that point backlogProjectUrl to the former singular Epic Project require migration.
hi CLI owns actionable migration guidance. It must detect or reject the old destination shape and direct the operator to rerun hi ensure to select the Product/Backlog Root URL.
hi ensure remains the settings-only command that changes this operator-owned destination without rerunning full scaffold initialization.
Structural provider migration remains previewed and explicitly approved before existing backlog objects are attached, reparented, or reorganized.

State: answered.

Q43 — Answer supersedes the recommended one-Fog-only boundary

Prerequisites:

Q1, Q3, Q7, Q8, Q31, Q33, Q36, Q37

Accepted answer:

Backlog projection is staged by grilling depth.
business-finder performs business-level grilling and emits or enriches Product Areas, Initiatives, and Epics. It also retains the Fog as external intake and provenance.
functional-finder performs high-level technical or functional grilling and emits a Story.
The final technical grilling step creates the mandatory atomic Tasks beneath that Story.
write-backlog remains the only physical provider mutation authority used by every stage. There is still no separate Epic-creation skill.
Existing exact-match reuse, ambiguity failure, duplicate prevention, scope-expansion warnings, and explicit approval for structural boundary changes remain in force.

Superseded decisions:

Q3's rule that Epics and Stories exist only after the complete agent-ready specification is no longer valid.
Q31 and Q36's prohibition on Business intake creating or changing Epics is no longer valid.
Q33 and Q37's single post-spec operation that creates both Stories and Tasks is no longer valid.
The final technical grill remains the Task-creation gate; the exact relationship between Fog and its grilling children remains Q46.

State: answered.

Q44 — Accepted answer

Prerequisites:

Accepted answer:

Linear may represent a Superseded Fog with its ordinary Canceled state.
No distinct Linear Superseded state or duplicate-only mapping is required.
It still receives no completion credit under Q41.

State: answered.

Current lifecycle conflict

Evidence anchors:

.agents/skills/finder-phase/references/frontier-lifecycle.md:Fog
.agents/skills/finder-phase/references/convergence.md:Child Dispatch
.agents/skills/write-backlog/REFERENCE.md:Pre-spec intake contract
.agents/skills/write-backlog/assets/concepts/backlog-model.md:Placement

Observed constraint:

Current source says a Fog is root-level, does not own child tickets by default, and graduates into separate capability-scoped grilling, research, or prototype items.
Current source creates Epic and Story together only from an agent-ready specification and has no Task concept.
The accepted R13 model requires staged business, functional, and final technical grilling projections. The Fog-child lifecycle must therefore be deliberately replaced or related another way.

Q45 — Settings destination field

Prerequisites:

Evidence anchors:

apps/cli/src/features/project-settings/model.ts:ProjectSettingsDocument
apps/cli/src/cli/ensure-command.ts:runEnsure
apps/cli/src/scaffold/settings-selection.ts:selectRepoSettings

Observed constraint:

hi ensure already reads and rewrites the operator-owned backlogProjectUrl through the shared settings selector.
The current field validates only that the value is an absolute HTTP(S) URL; it does not validate that it identifies the accepted Product/Backlog Root object.

Question:

Should the settings key remain backlogProjectUrl, with its meaning changed to the provider's Product/Backlog Root URL?

Recommendation:

Yes. Keep the existing provider-neutral key.
Make hi ensure validate the provider-specific root object, not only URL syntax.
When an old Linear Epic Project URL is present, stop with direct guidance to rerun hi ensure; the successful interactive run rewrites the same key to the root Initiative URL.

Why:

This migrates the authority with the smallest settings change and preserves the established settings-only reconfiguration path.

State: unanswered.

Q46 — Fog grilling-child topology

Prerequisites:

Question:

Should one Fog own ordered grilling children, where each resolved child authorizes exactly one projection level?

Recommendation:

Fog
  business grilling child
    -> upsert Product Area / Initiative / Epic
  functional grilling child
    -> create Story
  technical grilling child
    -> create mandatory Tasks and blocker graph

Keep the Fog open as the provenance and completion aggregate.
Each grilling child records its accepted output and links the provider objects it produced or enriched.
A later child cannot resolve before the required earlier structural output exists.
Determine child cardinality and whether functional-finder can begin a new Fog only after this relationship is accepted.

Why:

This makes the three grilling depths visible and resumable while preserving one Fog that explains where every resulting object came from.

State: unanswered.

R14 — Immediate Fog-Child Replacement and Live GitHub Coverage

Q45 — Accepted answer

Prerequisites:

Accepted answer:

Keep the existing .devpunks/settings.json key backlogProjectUrl.
Change its contract so the URL identifies the provider's Product/Backlog Root, not one Epic Project.
hi ensure validates the provider-specific root object and rewrites this operator-owned value.
When hi encounters a legacy Linear Epic Project URL, it stops with direct guidance to rerun hi ensure and select the Product/Backlog Root Initiative URL.
Do not add a renamed parallel settings key.

State: answered.

Q46 — Accepted answer

Prerequisites:

Accepted answer:

Replace the current Fog graduation lifecycle immediately. Do not retain it as an alternate or compatibility mode.
One Fog owns the business, functional, and technical grilling children that authorize successive projection levels.
Business grilling projects Product Area, Initiative, and Epic.
Functional grilling projects Story.
Technical grilling projects mandatory Tasks and their blocker graph.
Fog remains the provenance and completion aggregate. Every grilling child records its accepted resolution and links every provider object it created or enriched.
write-backlog remains the only physical provider writer at every stage.

State: answered.

Live GitHub Projects V2 validation

Authorization evidence:

gh auth status now reports project, read:org, and repo scopes.
The authenticated operator can create Projects V2 and update inspected organization Projects V2.

Organization evidence:

wearedevpunks currently has nine organization Projects V2.
No existing Project V2 is linked to wearedevpunks/harness-intelligence; Backlog initialization must create or explicitly select one for a GitHub-backed Harness migration.
Collective Intelligence Project V2 PVT_kwDOCWEnn84BY93O, number 4, provides the strongest live coverage example.

Project 4 evidence:

78 items: 49 repository Issues and 29 Draft Issues.
12 Issues have native sub-issues; 37 Issues have native parents.
20 Issues have native blockedBy relations.
All 49 repository Issues belong to repository milestones.
15 saved views include Triage Board, Epics, Dependencies, Roadmap, Release Plan, By Area, Timeline, and parking-lot views.
Project fields include native Parent issue, Sub-issues progress, Milestone, Repository, Linked pull requests, plus configured Area, Item Type, Release, Depends On, Epic, Level, and Target Date fields.
Live examples prove Epic → Story hierarchy, cross-Story blockers, cross-Epic blockers, milestone membership, custom semantic typing, and Roadmap/Dependency views.
No inspected Project 4 Issue has a grandparent. Story → Task nesting is supported by recursive Issue parent/sub-issue fields and addSubIssue/removeSubIssue mutations, but is not demonstrated by current live organization data.
Organization-native Issue Types currently contain only Task, Bug, and Feature. Product Area, Initiative, Epic, Story, Fog, and grilling semantics therefore require Project V2 fields or naming conventions where GitHub lacks a fitting native Issue Type.

Provider consequence:

GitHub has runtime coverage for the target Project V2 operating surface, Epic → Story hierarchy, milestones, blockers, fields, and views.
Story → Task must remain marked API-supported but not live-instance-proven until the workflow creates and reads back its first valid nested Task.
Provider completion requires post-write readback of the exact parent, milestone, blocker, type-field, and Project membership relations.

Q47 — Grilling-child cardinality

Prerequisites:

Question:

How many grilling children may one Fog own, and how do they pair with Stories?

Recommendation:

Fog
  exactly 1 Business grilling child
    -> 1 resolved Area / Initiative / Epic path
  1 or more Functional grilling children
    -> exactly 1 Story each
  exactly 1 Technical grilling child per Story
    -> 1 or more mandatory Tasks for that Story

Keep all grilling items as direct Fog children for one provenance view.
Link each Technical grilling child to the Story it resolves.
Do not allow one Technical grilling child to silently create Tasks for unrelated Stories.

Why:

This preserves atomic Story ownership while allowing one business request to produce several shippable outcomes.

State: unanswered.

Q48 — Functional Finder entry conditions

Prerequisites:

Question:

May functional-finder start a new Fog, or may it only continue a Fog whose Business grilling already resolved an exact Epic?

Recommendation:

It may start a new Fog only when it can reuse one exact existing Product Area → Initiative → Epic path without changing business scope.
If no exact Epic exists or the request changes Product Area, Initiative, or Epic boundaries, route to business-finder before Functional grilling.
It may always continue an existing Fog whose Business grilling child has resolved the Epic.

Why:

Technical managers can enter at their natural level when business placement already exists, while new business slices still receive the required business grill.

State: unanswered.

R15 — Child Cardinality and Functional Entry

Q47 — Accepted answer

Prerequisites:

Accepted answer:

Fog
  exactly 1 Business grilling child
    -> 1 resolved Product Area / Initiative / Epic path
  1 or more Functional grilling children
    -> exactly 1 Story each
  exactly 1 Technical grilling child per Story
    -> 1 or more mandatory Tasks for that Story

All grilling items are direct children of the Fog.
Every Technical grilling child links the one Story it resolves.
One Technical grilling child must not create Tasks for unrelated Stories.
The Fog aggregates provenance and completion across every child and projected object.

State: answered.

Q48 — Accepted answer

Prerequisites:

Accepted answer:

functional-finder may start a new Fog when it can reuse one exact existing Product Area → Initiative → Epic path without changing business scope.
If no exact Epic exists or the request changes Product Area, Initiative, or Epic boundaries, route through business-finder before Functional grilling.
functional-finder may always continue an existing Fog whose Business grilling child has resolved the Epic.
Exact-match identity, ambiguity failure, duplicate prevention, scope warnings, and provider readback remain mandatory.

State: answered.

Q49 — Stage resolution evidence

Prerequisites:

Question:

What durable evidence must close each grilling child before write-backlog projects its object level?

Recommendation:

Business child: accepted business-grill resolution plus immutable Fog/provider links; authorizes Product Area, Initiative, and Epic upsert.
Functional child: accepted functional-grill resolution plus immutable Story-definition evidence; authorizes exactly one Story.
Technical child: full technical $requirements-grill closure compiled into one agent-ready SPEC.md; authorizes mandatory Tasks and blocker relations for its linked Story.
Every stage writes the resolution pointer onto its grilling child and performs provider readback before the child becomes resolved.
Only the Technical child produces an agent-ready implementation specification. Earlier atomic grills do not pretend to be complete specs.

Why:

This preserves lightweight management intake while keeping Task creation behind the existing durable technical requirements gate.

State: unanswered.

Q50 — Functional grilling field contract

Prerequisites:

Q47, Q48

Question:

What must Functional grilling settle before it can emit one Story?

Recommendation:

linked Fog, Product Area, Initiative, and Epic stable identities;
actor or system beneficiary and the shippable outcome;
expected functional behavior and explicit boundaries;
affected systems or interfaces at management level;
durable data, security, privacy, reliability, and operational constraints that are already known;
external dependencies and material technical risks;
observable acceptance signals and non-goals;
unresolved implementation questions explicitly handed to the Technical grilling child;
target V* milestone iteration or an explicit unscheduled state requiring assignment before Story write.

Do not require file paths, code design, implementation tasks, worker assignments, or validation commands.

Why:

A CTO can define a real shippable slice without prematurely doing the final engineering design.

State: unanswered.

Q51 — Research and prototype placement

Prerequisites:

Observed constraint:

Current Finder may derive research and prototype items as well as grilling items.
The accepted replacement defines ordered Business, Functional, and Technical grilling children but has not placed supporting evidence work.

Question:

Where should Research and Prototype items live in the new Fog-child model?

Recommendation:

Keep Research and Prototype as direct Fog children.
Each names the Business, Functional, or Technical grilling child it supports.
They return immutable evidence or verdict pointers to that grilling child.
They never authorize Product Area, Initiative, Epic, Story, or Task projection by themselves; the supported grilling child must accept their result first.

Why:

This keeps one inspectable Fog frontier without letting evidence-gathering silently become a product decision.

State: unanswered.

R16 — Functional Layer Correction

Q49 — Accepted answer

Prerequisites:

Accepted answer:

Business grilling closes only with immutable accepted business-resolution evidence and provider readback of the Product Area, Initiative, and Epic path it emitted or enriched.
Functional grilling closes only with immutable accepted Story-definition evidence and provider readback of its one Story.
Technical grilling closes only after full technical $requirements-grill closure, one agent-ready SPEC.md, mandatory Task/blocker projection, and provider readback.
Every grilling child stores the immutable resolution pointer that authorized its projection.
Only Technical grilling produces an implementation specification. Business and Functional atomic grilling do not inherit or imitate $requirements-grill.

State: answered.

Q50 — Corrected, still open

Prerequisites:

Q47, Q48

User correction:

Functional grilling is not a high-level technical-management grill.
It sits between Business grilling and the full Technical $requirements-grill.
Technical users and proficient nontechnical users may both run it.
It defines the request at a slightly lower, more concrete level than Business grilling.

Corrected semantic boundary:

Business grilling
  why this matters and where it belongs
  -> Product Area / Initiative / Epic

Functional grilling
  what the product must do in one concrete shippable behavior
  -> Story

Technical requirements grilling
  how engineering will implement, split, order, and prove it
  -> agent-ready SPEC.md -> Tasks and blockers

Question:

Should Functional grilling require the following Story-level definition?

Recommendation:

linked Fog and resolved Product Area, Initiative, and Epic identities;
actor, role, or system that needs the behavior;
trigger or starting condition;
expected workflow or observable behavior;
business and domain rules that affect that behavior;
important alternate paths, failure outcomes, and edge cases visible at product level;
concrete examples or acceptance signals that show the Story works;
explicit boundaries and non-goals;
dependencies on other product behavior when already known;
unresolved engineering questions handed to Technical grilling;
exact target V* milestone before Story provider write.

Do not require architecture, component boundaries, APIs, data models, code structure, file paths, implementation Tasks, worker assignments, or validation commands. A proficient user may volunteer technical constraints, but Functional grilling records them as downstream inputs rather than treating them as required Story design.

Why:

This creates one understandable shippable Story without forcing its author to perform the final engineering specification.

State: unanswered.

Q51 — Accepted answer

Prerequisites:

Accepted answer:

Research and Prototype remain direct children of the Fog.
Either may support Business, Functional, or Technical grilling.
Each support item identifies every grilling child it supports and returns immutable evidence or verdict pointers.
Research and Prototype never authorize Product Area, Initiative, Epic, Story, or Task projection by themselves. The supported grilling child must accept the result first.

State: answered.

R17 — Functional Contract Closure

Q50 — Accepted answer

Prerequisites:

Q47, Q48

Accepted semantic ladder:

Business grilling
  why the request matters and where it belongs
  -> Product Area / Initiative / Epic

Functional grilling
  what the product must do in one concrete shippable behavior
  -> Story

Technical requirements grilling
  how engineering will implement, split, order, and prove it
  -> agent-ready SPEC.md -> Tasks and blockers

Accepted Functional grilling contract:

linked Fog and resolved Product Area, Initiative, and Epic identities;
actor, role, or system that needs the behavior;
trigger or starting condition;
expected workflow and observable result;
applicable business and domain rules;
important alternate paths, visible failures, and product-level edge cases;
concrete examples or acceptance signals;
explicit boundaries and non-goals;
known dependencies on other product behavior;
unresolved engineering questions handed to Technical grilling;
exact target V* milestone before Story provider write.

Functional grilling does not require architecture, APIs, data models, component boundaries, code structure, file paths, implementation Tasks, worker assignments, validation commands, or implementation design. Proficient users may provide technical constraints, but those remain inputs for Technical requirements grilling.

State: answered.

Q52 — Finder orchestration ownership

Prerequisites:

Q46-Q50

Question:

Which skill owns the lifecycle after an entrypoint creates or resumes a Fog?

Recommendation:

business-finder and functional-finder are public entrypoints that create or resume the Fog, create and resolve their applicable grilling child through atomic $grilling, invoke write-backlog for the authorized projection, then hand the Fog to finder-phase.
finder-phase is the one lifecycle orchestrator. It reads the Fog and all direct children, computes the next unresolved frontier, routes Research/Prototype support, routes Functional grilling where more Stories are required, and routes each Story into Technical requirements grilling.
Technical grilling invokes full $requirements-grill, compiles one agent-ready SPEC.md, and invokes write-backlog for Tasks/blockers.
Entrypoints never duplicate Finder state-machine rules. Shared lifecycle rules live in Finder-owned references.

Why:

Users get entrypoints at the right abstraction level while one orchestrator remains responsible for resumability, order, and completion.

State: unanswered.

Q53 — Functional Finder presentation contract

Prerequisites:

Question:

How should functional-finder use $wait-what and $show-me for its mixed technical and proficient nontechnical audience?

Recommendation:

Atomic $grilling remains the decision scheduler.
Use clear project language by default. Invoke $wait-what whenever terminology, behavior, or a proposed Story does not land; unlike business-finder, do not force every question through simplified business wording.
Before grilling, $show-me displays the resolved Product Area → Initiative → Epic path, related existing Stories, target V* milestone, and Fog provenance.
Use $show-me at workflow, Story-split, alternate-path, dependency, and milestone decisions.
Before Story write, show the final behavior graph and mark reused, new, deferred, and unresolved elements.

Why:

Proficient users retain useful precision while behavioral boundaries stay visible to nontechnical participants.

State: unanswered.

Q54 — Existing-provider migration

Prerequisites:

Question:

Does immediate lifecycle replacement also reorganize existing provider Fogs, grilling, Research, and Prototype items?

Recommendation:

New and resumed work uses the new Fog-child model immediately; no new writes use the old placement.
Normalization detects existing items that can be linked to one exact Fog and proposes a migration graph.
Additive evidence links and unambiguous backlinks may be repaired automatically after preflight.
Reparenting, merging, splitting, closing duplicates, or assigning an ambiguous item to a Fog requires explicit approval under the existing structural-change rule.
Historical completed items remain intact unless their missing provenance materially breaks the Product Map, Roadmap, or Fog views.

Why:

This stops new entropy immediately without silently rewriting trustworthy history.

State: unanswered.

R18 — Cumulative Finder Entrypoints

Q52 — Accepted answer with clarification

Prerequisites:

Q46-Q50

Accepted answer:

Every public Finder entrypoint always invokes finder-phase. No entrypoint bypasses it.
finder-phase owns the Fog lifecycle, direct-child frontier, ordering, resumability, Research/Prototype support, provider-readback gates, and completion computation.
Public entrypoints select how far the same Finder lifecycle runs. They do not own separate state machines.
The earlier diagram was ambiguous because it could be read as functional-finder producing a Story outside Finder. That interpretation is rejected.

State: answered.

Q53 — Accepted answer

Prerequisites:

Accepted answer:

Atomic $grilling remains the Functional decision scheduler.
Functional Finder uses precise project language by default and invokes $wait-what when terminology, behavior, or a proposed Story does not land. It does not force every question through simplified business wording.
Before grilling, $show-me displays the resolved Product Area → Initiative → Epic path, related existing Stories, target V* milestone, and Fog provenance.
$show-me is required at workflow, Story-split, alternate-path, dependency, and milestone decisions.
Before Story write, it shows the final behavior graph and marks reused, new, deferred, and unresolved elements.

State: answered.

Q54 — Accepted answer

Prerequisites:

Accepted answer:

New and resumed work uses the new Fog-child model immediately. No new write uses the old placement.
Normalization detects existing items that can be linked to one exact Fog and shows a migration graph.
Additive evidence links and unambiguous backlinks may be repaired automatically after preflight.
Reparenting, merging, splitting, duplicate closure, or ambiguous Fog assignment requires explicit approval.
Preserve completed historical items unless missing provenance materially breaks current Product Map, Roadmap, or Fog views.

State: answered.

Corrected cumulative model

business-finder
  -> finder-phase target: Business
  -> create/resume Fog
  -> Business grilling
  -> Product Area / Initiative / Epic
  -> stop and return Fog

functional-finder
  -> finder-phase target: Functional
  -> create/resume Fog
  -> ensure Business grilling is resolved
  -> Functional grilling
  -> Story
  -> stop and return Fog

technical-finder
  -> finder-phase target: Technical
  -> create/resume Fog
  -> ensure Business and Functional grilling are resolved
  -> Technical requirements grilling
  -> agent-ready SPEC.md -> Tasks and blockers
  -> return Fog in delivery state

Consequences:

Every entrypoint emits or resumes a Fog. A projected Epic, Story, or Task set never replaces the Fog.
Functional Finder has Business plus Functional capability.
Technical Finder has Business plus Functional plus Technical capability.
A higher-capability entrypoint reuses accepted lower-stage results and runs missing stages through the same Finder engine.

Q55 — Public capability ladder

Prerequisites:

Question:

Should the public Finder entrypoints be cumulative exactly as shown below?

Recommendation:

Entrypoint	Finder target	Required capabilities	Returns after
`business-finder`	Business	Business	Fog + resolved Product Area/Initiative/Epic path
`functional-finder`	Functional	Business + Functional	Fog + resolved path + one or more Stories
`technical-finder`	Technical	Business + Functional + Technical	Fog + resolved path + Stories + agent-ready specs + Tasks/blockers

Keep these as the only public human-facing Finder entrypoints.
All three call the same finder-phase engine.

Why:

The entrypoint name tells the user the deepest decision level they can complete, while all earlier levels remain guaranteed.

State: unanswered.

Q56 — Finder Phase public boundary

Prerequisites:

Question:

Should finder-phase stop being the public technical-user entrypoint and become the atomic orchestration engine wrapped by the three Finder entrypoints?

Recommendation:

Yes.
Route human requests to business-finder, functional-finder, or technical-finder.
Keep finder-phase as the shared lifecycle implementation and re-entry target used by wrappers and resumable handoffs.
Do not expose a fourth ambiguous public path that silently means Technical Finder.

Why:

This separates user capability selection from lifecycle mechanics and prevents the wrappers from drifting into three different workflows.

State: unanswered.

Q57 — Cumulative resume and idempotency

Prerequisites:

Question:

How should a higher-capability entrypoint handle an existing or partially resolved Fog?

Recommendation:

Accept an optional Fog stable identity. Without one, create exactly one new Fog.
Read the Fog, its direct children, durable resolution pointers, and provider objects before creating anything.
Reuse every accepted lower-stage child after evidence and provider readback validation.
Resume the first missing, invalidated, or unresolved stage needed to reach the requested target.
Never create a second Business child, duplicate Functional child for the same Story intent, or duplicate Technical child for one Story.
Stop on ambiguous identity or conflicting accepted evidence.

Why:

A user can enter at any capability level without repeating settled work or creating duplicate backlog structure.

State: unanswered.

Q58 — One grilling item type, no preliminary Finder grill

Prerequisites:

Q46, Q52

Evidence anchors:

.agents/skills/write-backlog/SKILL.md:Direct taxonomy
.agents/skills/write-backlog/REFERENCE.md:direct backlog concepts
.agents/skills/write-backlog/assets/providers/github-projects-create-payload.md:Provider classification

Observed constraint:

Current provider-neutral taxonomy has one grilling item kind, alongside fog, research, prototype, epic, and story.
The accepted model needs three decision depths, but no requirement needs three different provider item types.
A separate generic "Finder grill" before the Business, Functional, or Technical child would duplicate the same work and create a fourth unclear layer.

Question:

Should Finder use one grilling item type with a required stage value of Business, Functional, or Technical, and perform no preliminary generic grill?

Recommendation:

Public entrypoint selects target depth
  -> finder-phase reads Fog state
  -> routes the next required `grilling` child
       stage: Business | Functional | Technical
  -> child performs the actual interview
  -> write-backlog projects the stage output

Keep one provider classification: grilling.
Add or preserve one explicit stage/level attribute in provider metadata or the documented nearest-native representation.
The entrypoint's target depth is routing input, not another backlog item and not another grill.
Research and Prototype link to the specific grilling item they support.

Why:

The stage distinction remains necessary for output gates and resumability, while provider taxonomy and user experience stay simple.

State: unanswered.

R19 — Cumulative Finder Model Accepted

Q55 — Accepted answer

Prerequisites:

Accepted answer:

The only public human-facing Finder entrypoints are business-finder, functional-finder, and technical-finder.
They are cumulative capability wrappers over one Finder lifecycle.
business-finder targets Business depth and returns the Fog plus its resolved Product Area/Initiative/Epic path.
functional-finder targets Functional depth, guarantees Business depth first, and returns the Fog plus one or more Stories.
technical-finder targets Technical depth, guarantees Business and Functional depth first, and returns the Fog plus agent-ready specifications, Tasks, and blockers.

State: answered.

Q56 — Accepted answer

Prerequisites:

Accepted answer:

finder-phase becomes the internal atomic orchestration engine and resumable re-entry target used by the three public wrappers.
It is not a fourth public human entrypoint and does not silently alias Technical Finder.
Root guidance routes users to the wrapper matching the deepest capability they can provide.
Shared lifecycle, frontier, ordering, evidence, provider-readback, and completion rules remain Finder-owned.

State: answered.

Q57 — Accepted answer

Prerequisites:

Accepted answer:

Every wrapper accepts an optional Fog stable identity. Without one, it creates exactly one new Fog.
Finder reads the Fog, direct children, durable resolution pointers, and provider objects before creating anything.
It validates and reuses every accepted lower stage.
It resumes the first missing, invalidated, or unresolved stage required to reach the selected target depth.
It never creates a second Business child, a duplicate Functional child for the same Story intent, or a duplicate Technical child for one Story.
Ambiguous identity or conflicting accepted evidence stops all writes.

State: answered.

Q58 — Accepted answer

Prerequisites:

Q46, Q52

Accepted answer:

Provider-neutral taxonomy keeps one grilling item kind.
Each grilling item has one required stage value: Business, Functional, or Technical.
Business, Functional, and Technical are lifecycle roles and stage metadata, not separate provider item types.
Finder performs no preliminary generic grill. The routed grilling child performs the actual interview.
The public entrypoint target depth is routing input, not a backlog item and not another grilling step.
Research and Prototype link to the specific grilling item they support.

State: answered.

Accepted engine

public Finder wrapper
  -> finder-phase(target depth, optional Fog id)
  -> read/create Fog and validate children
  -> route next required grilling child
       kind: grilling
       stage: Business | Functional | Technical
  -> child performs actual interview
  -> write-backlog projects authorized object level
  -> continue until target depth or stop on blocker

Q59 — Write Backlog reference topology after staged projection

Prerequisites:

Q55-Q58

Observed constraint:

Q9 accepted one progressive-reference write-backlog design before Business/Functional/Technical projection became separate gates.
The old single delivery-projection.md branch no longer matches the accepted staged writer responsibilities.

Question:

Should write-backlog replace the old projection branch with explicit staged references while preserving one public entrypoint?

Recommendation:

Keep SKILL.md as the concise router and always-needed preflight/readback contract.
Use these single-source references:
- project-context.md: wiki authority, Product/Backlog Root, repository pinning, stable identities, project metadata, views;
- backlog-initialization.md: greenfield/inherited root, Product Areas, Initiatives, milestones, provider fields, views;
- fog-intake.md: Fog creation/resume, direct-child classification, provenance;
- business-projection.md: accepted Business grilling → Product Area/Initiative/Epic;
- functional-projection.md: accepted Functional grilling → Story;
- technical-projection.md: agent-ready SPEC → Tasks/blockers;
- issue-reconciliation.md: exact-match upsert and partial-failure recovery;
- normalization.md: migration, entropy repair, Product Map/Roadmap/Fog/Delivery reconciliation;
- delivery-status.md: immediate linked-item state updates and production-evidence Fog completion;
- providers/linear.md and providers/github.md: provider mechanics only.
Remove or supersede the former monolithic delivery-projection.md; do not duplicate its rules across three staged references.

Why:

Each projection gate becomes independently loadable and testable while mutation authority remains one skill.

State: unanswered.

Q60 — Thin public wrapper skills

Prerequisites:

Q55-Q58

Question:

How much lifecycle logic belongs in business-finder, functional-finder, and technical-finder?

Recommendation:

Each public skill is a thin wrapper that declares audience, target depth, input expectations, presentation contract, and stop/return shape.
Each invokes finder-phase with the target depth and optional Fog identity.
No wrapper copies frontier traversal, child cardinality, provider mutation, evidence gates, resume logic, or completion rules.
finder-phase owns progressive references for entrypoint selection, Fog lifecycle, staged grilling, support work, convergence, and handoff.

Why:

Thin wrappers keep public intent clear without creating three implementations of Finder.

State: unanswered.

Q61 — Provider representation for grilling stage

Prerequisites:

Question:

Must Backlog initialization provision and validate a provider-visible stage representation for every grilling item?

Recommendation:

Yes. Every grilling item must be queryable as kind = grilling and exactly one stage: Business, Functional, or Technical.
Linear uses configured label groups or the nearest native metadata that preserves one Kind and one Stage value.
GitHub Projects V2 uses configured single-select fields such as Kind and Grilling Stage unless existing fields preserve the same semantics.
Backlog initialization may create missing fields/options/views after showing the structural plan and receiving approval where provider configuration changes are material.
Ordinary Fog writes never invent metadata ad hoc. They stop with setup guidance when required representation is missing.
Normalization detects invalid, missing, or multiple Stage values and repairs only unambiguous mappings automatically.

Why:

Finder cannot resume or render stage views safely when Business, Functional, and Technical exist only in prose.

State: unanswered.

R20 — Finder Reference Boundaries and Human Invocation Accepted

Q59 — Accepted answer

Prerequisites:

Q55-Q58

Accepted answer:

write-backlog remains one public provider-writer entrypoint with a concise SKILL.md router and always-needed preflight/readback rules.
Its progressive references are project-context.md, backlog-initialization.md, fog-intake.md, business-projection.md, functional-projection.md, technical-projection.md, issue-reconciliation.md, normalization.md, delivery-status.md, providers/linear.md, and providers/github.md.
The former monolithic delivery-projection.md is removed or superseded. Its rules must not be duplicated across the three staged projection references.
Business, Functional, and Technical projection remain independently loadable while write-backlog keeps sole physical provider mutation authority.

State: answered.

Q60 — Accepted answer

Prerequisites:

Q55-Q58

Accepted answer:

business-finder, functional-finder, and technical-finder are direct-composition invocation profiles, not separate Durable Workflow Graphs.
Each wrapper owns only its audience, target depth, input expectations, presentation policy, and return shape.
Each wrapper invokes the same finder-phase engine with its target depth and optional Fog stable identity.
The wrappers do not copy lifecycle state, frontier traversal, child cardinality, provider mutation, evidence gates, resume logic, support-work cycles, reconciliation, convergence, or completion rules.
finder-phase is one Durable Workflow Graph with a bootstrap-only SKILL.md, a flat phases/ router and gate set, and conditional shared references.
Its gates cover Fog ensure/resume, Business grilling, Functional grilling, Technical grilling, Research, Prototype, reconciliation, target-depth return, and human_steering_required handback.
Shared wrapper invariants live in finder-phase/references/entrypoint-contracts.md; each wrapper keeps only its profile-specific contract.
Runtime authority is current provider Fog, child, relation, and immutable evidence state. AUTHORING-HANDOFF.md records graph authoring only and never becomes runtime state.
Reaching Business, Functional, or Technical target depth returns control to the selected wrapper. It does not complete the Fog; Fog completion still requires production evidence for all accepted resulting delivery scope.

State: answered.

Q61 — Accepted answer

Prerequisites:

Accepted answer:

Every grilling item is provider-queryable as kind = grilling with exactly one Stage value: Business, Functional, or Technical.
Linear uses configured label groups or the nearest native representation that preserves one Kind and one Stage value.
GitHub Projects V2 uses configured Kind and Grilling Stage fields unless existing fields preserve the same semantics.
Backlog initialization provisions missing metadata after structural preview and required approval.
Ordinary writes stop with setup guidance when the required representation is missing; they never invent metadata ad hoc.
Normalization repairs only unambiguous missing or invalid Stage mappings automatically.

State: answered.

Q62 — Accepted answer

Prerequisites:

Question:

May any Finder wrapper or the internal Finder engine be selected through automatic or implicit skill invocation?

Accepted answer:

No. business-finder, functional-finder, technical-finder, and finder-phase all declare disable-model-invocation: true in their skill headers.
A human must explicitly invoke one public wrapper.
That explicit human choice authorizes the wrapper to compose finder-phase internally for the selected target depth.
Root guidance and model routing must not infer, auto-select, or auto-start a Finder wrapper from loose user input.
finder-phase remains unavailable as a fourth public entrypoint.

State: answered.

Shared-understanding confirmation

Confirmed by the user after R20.
The active frontier is empty.
The accepted glossary and axioms are published in harness/foundations/project-backlog-operating-model.mdx.

R21 — Finder Intake and Universal Fog Resolution Reopened

Issue #180 and the follow-up correction reopen the accepted cumulative Finder ladder. The existing design made Business, Functional, and Technical grilling successive provider-projection gates. That design prevents a direct requirements-phase -> write-backlog path when Technical Finder did not run. The original product intent was narrower: give colleagues a Business-first or Functional-first Fog entrypoint, then let requirements grilling resolve the Fog.

Q63 — Finder intake return boundary

Prerequisites:

Q52, Q55-Q60

Evidence anchors:

.agents/skills/business-finder/SKILL.md:Composition
.agents/skills/functional-finder/SKILL.md:Composition
.agents/skills/finder-phase/references/entrypoint-contract.md:Shared Invariants

Observed constraint:

Business Finder currently advances Finder through Business projection and returns a Product Area -> Initiative -> Epic path.
Functional Finder currently guarantees Business depth, projects one Story per accepted Functional child, and returns those Story readbacks.
These cumulative projection guarantees exceed an intake-only Fog entrypoint.

Question:

Should Business Finder and Functional Finder stop after creating or resuming one Fog and persisting one compact intake resolution, with no Product Area, Epic, Story, specification, or Task projection?

Recommendation:

Yes. Treat both as bounded human-language intake profiles.
Preserve the Fog, the supplied context, the intake resolution, and unresolved questions.
Let later requirements resolution decide what delivery structure the accepted specification needs.

Why:

A colleague should be able to record useful uncertainty without possessing the capability needed to define the delivery hierarchy or technical design.

Code consequence:

Finder wrappers and the shared engine stop at a durable intake result.
write-backlog may ensure the Fog and intake record, but it does not perform staged Business or Functional delivery projection during intake.

State: unanswered.

Q64 — Fog kind versus intake lens

Prerequisites:

none

Evidence anchors:

apps/wiki/content/docs/project/grilling/project-backlog-operating-model-grill-status.md:Glossary
.agents/skills/finder-phase/references/entrypoint-contract.md:Inputs
.agents/skills/write-backlog/REFERENCE.md

Observed constraint:

The accepted glossary defines one Fog concept and places Business, Functional, and Technical on child grilling stages.
The correction describes different kinds of Fogs produced by Business-first and Functional-first colleagues.
Separate provider kinds would create separate lifecycle and reconciliation branches unless their semantic difference is required.

Question:

Should the system retain one Fog kind with an immutable Business or Functional intake lens, or define separate Business Fog and Functional Fog kinds?

Recommendation:

Retain one Fog kind.
Record the human-selected intake lens and the context gathered through it.
Do not make the lens a maturity level or a promise that prior or later stages already ran.

Why:

One Fog concept gives requirements-phase one universal unresolved-work input while still preserving who entered, what language they used, and which context was available.

Code consequence:

Fog identity, resume, correction history, and provider representation stay singular. Intake presentation varies without creating parallel state machines.

State: unanswered.

Q65 — Requirements Phase independence

Prerequisites:

none

Evidence anchors:

.agents/skills/requirements-phase/SKILL.md:Workflow
.agents/skills/technical-finder/SKILL.md:Story-scoped presentation
.agents/skills/write-backlog/SKILL.md:Mutation Pipeline
.agents/skills/write-backlog/references/technical-projection.md

Observed constraint:

Requirements Phase already claims the generic requirements-grill -> create-spec path and says its verified stable spec may proceed to write-backlog.
The only current post-spec writer branch is Technical projection, which assumes an exact Story and Technical child established by Technical Finder.
Therefore the generic Requirements Phase contract and the actual writer preconditions disagree.

Question:

Must Requirements Phase accept any unresolved Fog, close the necessary requirements, compile one agent-ready specification, and reach Write Backlog without Technical Finder having run first?

Recommendation:

Yes. Technical Finder must not be a prerequisite.
requirements-grill owns missing decision closure and create-spec readiness owns whether the result is sufficiently complete.
Write Backlog consumes the accepted specification plus current provider context and either projects its required delivery structure or returns one explicit zero-write ambiguity.

Why:

The universal requirements path is what makes low-capability intake useful. Requiring the technical entrypoint first turns the entrypoint ladder into a gate that those colleagues cannot traverse.

Code consequence:

Requirements Phase needs a first-class Fog-resolution input and output contract.
Write Backlog needs a post-spec projection seam that does not depend on a pre-existing Technical Finder child or Story while preserving exact identity, approval, and readback rules.

State: unanswered.

R22 — Intake Ceilings and Universal Resolution Accepted

Q63 — Accepted answer with corrected projection ceilings

Prerequisites:

Q52, Q55-Q60

Accepted answer:

Business Finder and Functional Finder create or resume the same semantic Fog type and preserve their bounded intake resolution.
Business Finder may create or enrich Product Areas when that output completes its Business-language flow. Product Area is its projection ceiling.
Functional Finder may create or enrich the product hierarchy through Epic when that output completes its Functional-language flow. Epic is its projection ceiling, including the necessary Product Area and Initiative path.
Neither entrypoint creates a Story, agent-ready specification, Task, or blocker graph.
These bounded outputs improve the intake flow. They do not prove that the Fog is fully resolved and do not authorize later phases to assume that every lower projection exists.

Superseded decisions:

Q43's Business projection through Epic is narrowed to Product Area.
Q43 and Q50's Functional projection to Story is narrowed to Epic.
Q47-Q60's cumulative target-depth ladder is no longer a prerequisite chain.

State: answered.

Q64 — Accepted answer

Prerequisites:

none

Accepted answer:

There is one Fog type.
Each Fog records one immutable intake lens describing the human-selected entry profile and context used to create it.
Business and Functional are accepted intake lenses. A lens is neither a Fog kind nor a maturity level and does not assert that another Finder route ran.
Fog identity, resume, correction history, and provider representation remain common across lenses.

State: answered.

Q65 — Accepted answer

Prerequisites:

none

Accepted answer:

Requirements Phase is the universal Fog-resolution path.
It accepts an unresolved Fog regardless of its intake lens or which bounded intake projections already exist.
It runs Requirements Grill to close missing decisions, compiles one or more agent-ready specifications through Create Spec as later granularity decisions require, then invokes Write Backlog with verified stable specification authority.
Technical Finder is never a prerequisite for Requirements Phase.
Write Backlog reuses exact existing structure, creates only the accepted missing delivery structure, and stops with a typed zero-write result on ambiguity.

State: answered.

Q66 — Projection ceiling versus completion gate

Prerequisites:

Q63, Q65

Evidence anchors:

.agents/skills/business-finder/SKILL.md:Return
.agents/skills/functional-finder/SKILL.md:Return
.agents/skills/finder-phase/phases/return-target.md
.agents/skills/requirements-phase/SKILL.md:Workflow

Observed constraint:

The current target-depth model treats projection and exact readback as mandatory before a wrapper can return.
Q63 says Business and Functional routes may produce bounded outputs to complete their flow.
If those outputs remain mandatory, a colleague who cannot settle placement still cannot produce a valid Fog for Requirements Phase.

Question:

Are Product Area for Business Finder and Epic for Functional Finder maximum optional projection ceilings rather than mandatory completion gates?

Recommendation:

Yes. Each route may project up to its ceiling only when accepted evidence and exact provider identity make the operation unambiguous.
Otherwise it returns a valid unresolved Fog with the missing placement named for Requirements Phase.
A missing bounded projection is unresolved context, not an invalid Fog.

Why:

This preserves useful early structure without making domain knowledge a prerequisite for intake.

Code consequence:

Finder return eligibility depends on durable Fog intake evidence, not on reaching the maximum provider projection.
Requirements Phase and Write Backlog must accept partial structure and fill only the missing accepted delta.

State: unanswered.

Q67 — Technical Finder's optional ceiling

Prerequisites:

Q63-Q65

Evidence anchors:

.agents/skills/technical-finder/SKILL.md:Composition
.agents/skills/technical-finder/SKILL.md:Story-scoped presentation
.agents/skills/requirements-phase/SKILL.md:Workflow
.agents/skills/write-backlog/references/technical-projection.md

Observed constraint:

Technical Finder currently owns the full Requirements Grill, Create Spec, and Task-projection sequence for a pre-existing Story.
Q65 moves universal requirements closure back to Requirements Phase and makes Technical Finder optional.
The accepted Business and Functional ceilings suggest a capability tower in which the next intake lens may structure one level deeper without owning complete resolution.

Question:

Should Technical Finder remain a third optional Fog intake lens that may project through Story, while Requirements Phase alone owns full Requirements Grill, agent-ready specification compilation, and Task projection?

Recommendation:

Yes. Technical Finder may create or reuse Product Area, Initiative, Epic, and Story when its accepted intake evidence makes them unambiguous.
Story is its maximum projection ceiling.
It does not require or create an agent-ready specification, Tasks, or blocker graph before returning the Fog.

Why:

This completes a regular abstraction tower without turning any intake lens into a mandatory predecessor:

Business intake   -> up to Product Area
Functional intake -> up to Epic
Technical intake  -> up to Story
Requirements      -> agent-ready specification -> Tasks

Code consequence:

Technical Finder becomes a bounded intake profile instead of an embedded Requirements Phase implementation.
The current Story-scoped Technical child requirement and cumulative route prerequisites are superseded.

State: unanswered.

R23 — Optional Intake Tower and Linear Free Taxonomy

Q66 — Accepted answer

Prerequisites:

Q63, Q65

Accepted answer:

Product Area for Business Finder and Epic for Functional Finder are maximum optional projection ceilings, not completion gates.
A Finder route projects only when accepted evidence and exact provider identity make the operation unambiguous.
Otherwise it returns a valid unresolved Fog with missing placement recorded for Requirements Phase.
Missing bounded projection is unresolved context, not an invalid Fog.

State: answered.

Q67 — Accepted answer and Technical Finder boundary

Prerequisites:

Q63-Q65

Accepted answer:

Technical Finder is a third optional Fog intake lens with Story as its maximum optional projection ceiling.
It may create or reuse the accepted Product Area, Initiative, Epic, and Story structure when exact evidence makes that projection unambiguous.
Technical Finder uses bounded atomic $grilling for technical intake. It does not invoke full $requirements-grill, compile an agent-ready specification, create Tasks, or construct the blocker graph.
Requirements Phase accepts any Fog, invokes full $requirements-grill, then uses Create Spec and Write Backlog to compile and project accepted delivery scope.

Superseded decisions:

Q49-Q60's Technical Finder ownership of full Requirements Grill, Create Spec, and Task projection is superseded.
A pre-existing Story or Technical child is not a Requirements Phase entry condition.

State: answered.

Q68 — Accepted Linear Free taxonomy from issue #183

Prerequisites:

Q63-Q67

Evidence anchors:

https://github.com/wearedevpunks/harness-intelligence/issues/183
.agents/skills/write-backlog/references/providers/linear.md:Native Representation
.agents/skills/write-backlog/REFERENCE.md:Topology

Observed constraint:

The current Linear adapter still requires Product Area and Initiative as nested native Initiatives and Epic as a Linear Project.
Issue #183 records the final successful Linear Free provider readback after rejecting nested Initiatives, an Agile Initiative Project, and premature Fog/grilling/delivery projections.

Accepted answer:

Preserve the provider-neutral semantic hierarchy: Product/Backlog Root → Product Area → Initiative → Epic → Story → Task.
The accepted Linear Free projection is:

Product/Backlog Root -> native Linear Initiative
Product Area         -> Linear Project
Initiative           -> Issue [Kind/initiative]
Epic                 -> child Issue [Kind/epic]
Story                -> child Issue [Kind/story] + V* Project Milestone
Task                 -> child Issue [Kind/task] + the same V* Project Milestone

Parent-child Issue relations preserve Initiative → Epic → Story → Task.
Provider writers must not create nested Initiatives or a separate Linear Project for an Agile Initiative under this profile.
Provider labels and native object choices are adapter representation. They do not rename or collapse the semantic roles.
Issue #183 supersedes issue #178's nested-Initiative workaround for the Linear Free taxonomy.

State: answered.

Q69 — Scope of the Linear Free projection profile

Prerequisites:

Evidence anchors:

https://github.com/wearedevpunks/harness-intelligence/issues/183
apps/wiki/content/docs/project/research/finder-provider-projection-intent-control-research-report.md:Fixed hierarchy versus provider projection
/Users/stefan/Desktop/repos/wearedevpunks-skills/skills/agnostic/requirements/write-backlog/references/projection-profiles.md:Accepted Linear profiles

Observed constraint:

The in-progress provider-profile design retains multiple accepted Linear mappings, including the former nested-Initiative profile and a Collective-specific profile.
Issue #183 describes one deterministic Linear Free taxonomy as the final workaround.
Existing projects may still contain older physical layouts that require deliberate migration rather than silent reinterpretation.

Question:

Should issue #183 become the canonical linear-free-v1 projection for every new or normalized Linear Free backlog, while an existing divergent topology requires explicit migration approval?

Recommendation:

Yes. Make linear-free-v1 the sole default for Linear Free.
Persist its profile identity and verify its topology on every mutation.
Do not retain the nested-Initiative profile as another Free-tier option.
Existing divergent backlogs stop at a migration preview; they are not silently rewritten.
A distinct native Enterprise profile may exist only when explicitly selected and capability-proven. It must not affect the Free default.

Why:

One deterministic Free profile prevents every agent and project from solving the same provider limitation differently while preserving safe migration.

Code consequence:

Linear adapter selection becomes deterministic for Free workspaces.
Normalization owns migration classification and approval; ordinary Finder or Requirements projection never selects a different physical taxonomy ad hoc.

State: unanswered.

Q70 — Fog and Requirements Grill representation in Linear

Prerequisites:

Q64-Q68

Evidence anchors:

.agents/skills/write-backlog/references/fog-intake.md:Ensure Pre-Resolution Grilling Child
.agents/skills/write-backlog/references/providers/linear.md:Lateral Fog Provenance
https://github.com/wearedevpunks/harness-intelligence/issues/180
https://github.com/wearedevpunks/harness-intelligence/issues/183

Observed constraint:

The current model creates provider-visible Business, Functional, and Technical grilling child Issues under every Fog.
Q63-Q67 remove the cumulative stage chain and make Requirements Phase the universal resolver.
Issue #180 shows that provider grilling items were fragmented and repeatedly projected too early.
An unresolved Fog may not yet know its Product Area Project, so mandatory Project membership would recreate Q66's completion gate.

Question:

Should the Fog be the sole required provider intake Issue, with Requirements Grill log/status artifacts linked from it instead of a mandatory provider grilling child Issue?

Recommendation:

Yes. Represent Fog as one Issue with Kind/fog.
Allow it to remain in the team backlog without Project membership while its Product Area is unresolved.
Assign it to the exact Product Area Project once accepted placement exists.
Link its durable Requirements Grill status/log and resulting specifications from the Fog body.
Do not create a provider grilling child merely because Requirements Phase starts. Create a separate issue only when it represents independently schedulable research, prototype, or coordination work.

Why:

One provider object matches one unresolved unit of work, eliminates ticket fragmentation, and lets the wiki artifacts retain the detailed interview without turning every reasoning step into backlog structure.

Code consequence:

The provider taxonomy no longer needs mandatory Business, Functional, and Technical grilling child Issues or a Grilling Stage field for normal Fog resolution.
Requirements Phase mutates durable artifacts and the Fog's evidence links; Write Backlog creates delivery hierarchy only from accepted projection authority.

State: unanswered.

R24 — Linear Free Default and Typed Fog Children

The user accepted Q69 and Q70, then corrected the proposed Q70 representation: Finder entrypoints must preserve the shared Finder graph. Fog is the intake root, while grilling, research, and prototype remain typed direct Fog children. Requirements Phase is invoked on a grilling child in the context of its owning Fog graph, not on an untyped bare Fog.

Q69 — Accepted answer

Prerequisites:

Accepted answer:

linear-free-v1 is the sole default projection profile for every new or normalized Linear Free backlog.
Persist the selected profile identity and verify its topology on every provider mutation.
Retire nested native Initiatives and a separate Agile Initiative Project as Linear Free options.
Existing divergent topology requires an explicit migration preview and human approval before Normalization changes it.
A separate native Enterprise profile may exist only when explicitly selected and capability-proven. It never changes the Free default.

State: answered.

Q70 — Accepted answer with typed-child correction

Prerequisites:

Q64-Q68

Accepted answer:

Fog is the sole provider intake root, represented as one Kind/fog Issue. It is not the sole provider item in the resolution graph.
Every public Finder wrapper invokes finder-phase, ensures the appropriate direct Fog child with Kind/grilling and Stage Business, Functional, or Technical, and runs bounded atomic $grilling on that child.
Business, Functional, and Technical Finder return the exact Fog and selected grilling child identities, immutable intake resolution, optional bounded projection readback, unresolved decisions, support evidence, and durable Finder handoff.
When a precise unknown needs evidence or an evaluated artifact, Wayfinder recommends research or prototype; the Finder engine may then ensure the corresponding direct Fog child and link it to the exact grilling child it supports.
Requirements Phase accepts an exact Fog child of Kind/grilling together with the owning Fog graph. It may consume Business, Functional, or Technical stage children; Technical Finder is never a prerequisite.
Requirements Phase invokes full $requirements-grill, then Create Spec and post-spec Write Backlog. It does not create a duplicate Requirements-only grilling child.
An unresolved Fog and its children may remain outside a Product Area Project until placement is accepted. Exact accepted placement then governs Project membership.

Superseded wording:

Q65's bare-Fog input wording is narrowed: Requirements Phase is universal across Finder lenses and partial projections, but its invocation handle is a typed grilling child in the owning Fog graph.
Q67's Technical-only atomic-grilling phrasing is corrected: all three Finder entrypoints run bounded atomic $grilling; Technical Finder was the current implementation outlier.
Q70's recommendation to remove provider grilling children and ordinary Grilling Stage metadata is superseded.

State: answered.

Q71 — Requirements Phase invocation unit

Prerequisites:

Observed constraint:

One Fog may own Business, Functional, and Technical grilling children, plus several Functional or Technical children for distinct bounded intents.
Research and Prototype children link to the exact grilling child they support.
Invoking Requirements Phase on the whole Fog without a selected child would blur ownership, resume position, and evidence traceability.

Question:

Should one Requirements Phase invocation resolve exactly one selected grilling child while reading the complete owning Fog graph as context, rather than bulk-resolving every open grilling child under the Fog?

Recommendation:

Yes. Select one stable grilling child as the invocation and decision authority.
Read the Fog, sibling grilling resolutions, and linked Research or Prototype evidence as context without silently absorbing their independent scopes.
Resume by the same child identity until its requirements are closed, parked, or handed back.

Why:

This gives every agent one exact unit of control and recovery while retaining the full Fog graph for coherence.

State: unanswered.

Q72 — Bounded-intake versus requirements-complete state

Prerequisites:

Q66-Q67, Q70

Observed constraint:

Finder target-depth return currently treats immutable accepted stage resolution as completion evidence.
The corrected system sends the same grilling child into a later, exhaustive Requirements Phase.
One undifferentiated accepted or provider Done state would make bounded intake indistinguishable from agent-ready requirements closure.

Question:

Should one grilling child carry separate bounded-intake and full-requirements checkpoints, remaining provider-open after Finder returns until Requirements Phase closes or explicitly parks it?

Recommendation:

Yes. Persist intake-resolution: accepted as immutable evidence sufficient for Finder return and any unambiguous bounded projection.
Keep the child provider-open for Requirements Phase.
Persist requirements-resolution: accepted only after full Requirements Grill closure; only that checkpoint may authorize Create Spec and post-spec projection.
Parking, cancellation, or supersession remains explicit and does not imitate requirements completion.

Why:

Agents can distinguish "the colleague expressed this well enough" from "the delivery requirements are closed" without creating another child or losing the original intake history.

State: unanswered.

R25 — Two Finder Entrypoints and Requirements-Owned Delivery Depth

The user accepted Q71, rejected Q72's invented checkpoint language through $wait-what, and proposed removing Technical Finder. The intended simplification keeps Business and Functional as the only public Finder entrypoints. Finder may project no deeper than Epic; Requirements Phase becomes the only route that may project Stories and Tasks after full Requirements Grill closure and Create Spec.

Q71 — Accepted answer

Prerequisites:

Accepted answer:

One Requirements Phase invocation resolves exactly one selected grilling child.
It reads the complete owning Fog graph, sibling grilling resolutions, and linked Research or Prototype evidence as context.
It does not silently absorb or close sibling grilling children.
Resume uses the same selected child identity until the invocation closes, parks, or hands back its requirements decisions.

State: answered.

Q72 — Withdrawn after Wait What

The proposed intake-resolution and requirements-resolution checkpoints were not canonical terms and added an unnecessary second state model.

Corrected explanation:

Finder finishes its bounded atomic $grilling work on the selected child and returns that accepted resolution.
Requirements Phase later accepts that child as its exact invocation handle and reads the owning Fog graph.
Requirements Grill status/log artifacts already record whether exhaustive decisions are closed, parked, or open.
Create Spec already owns agent-ready readiness.
No new provider lifecycle checkpoint or dual acceptance field is required.

State: withdrawn; not a user decision.

Q73 — Remove Technical Finder and the Technical Finder stage

Prerequisites:

Q67, Q71

Evidence anchors:

.agents/skills/technical-finder/SKILL.md
.agents/skills/finder-phase/phases/technical-grilling.md
.agents/skills/finder-phase/references/entrypoint-contract.md
.agents/skills/requirements-phase/SKILL.md
.agents/skills/design-phase/phases/backlog.md
.agents/skills/write-backlog/references/technical-projection.md
.agents/skills/create-spec/SKILL.md
apps/cli/src/data/catalog/skills.ts
apps/cli/src/content/finder-entrypoints-catalog-prompts.test.ts

Observed constraint:

The current Technical Finder path embeds full Requirements Grill, Create Spec, Story-scoped Task projection, and blocker validation.
The interim Q67 target changed it to bounded technical intake through Story, but that still leaves a third Finder route touching delivery structure below Epic.
Requirements Phase already owns full Requirements Grill, Create Spec, and post-spec Write Backlog projection.
Design Phase and the current Write Backlog technical projection also assume a Technical child authority. Removing only the public wrapper would leave a hidden alternate route to Story and Task projection.
Keeping both paths gives agents two authorities for Story-level decisions and makes the shortest valid route harder to infer.

Question:

Should the system remove both the public technical-finder wrapper and the Technical target depth, gate, Stage, and child cardinality from finder-phase, leaving Business Finder and Functional Finder as the only Finder entrypoints?

Recommendation:

Yes. Remove Technical Finder as a skill and as a Finder state-machine branch.
Business Finder may optionally project through Product Area.
Functional Finder may optionally project through Epic.
Requirements Phase accepts one selected Business or Functional grilling child and becomes the only route to full Requirements Grill, Create Spec, Story projection, Task projection, and blocker validation.
Technical questions remain part of exhaustive Requirements Grill. They do not need a separate Finder lens, Stage, child, or public entrypoint.
Design Phase must hand back to Requirements Phase when accepted design evidence requires new Stories or Tasks; it cannot invoke post-spec projection directly.
Existing accepted Stories, specifications, and Tasks remain valid evidence. Removing their former entrypoint does not delete them.
Decide migration of existing Technical children only after this removal direction is accepted.

Why:

The system gains one obvious boundary: Finder captures and structures the product need through Epic; Requirements Phase turns that accepted need into agent-ready Stories and Tasks.

State: unanswered.

R26 — Optional Finder Context and One Grilling Kind

The user accepted Q73 and restored the original simple phase boundary: finder-phase creates or resumes a Fog and may route Research, Prototype, or Grilling support; Requirements Phase remains an optional separate entrypoint; Delivery Phase follows accepted requirements work. Business Finder and Functional Finder exist to make Fog creation and bounded grilling accessible to different colleagues, not to create a mandatory maturity ladder.

Q73 — Accepted answer

Prerequisites:

Q67, Q71

Accepted answer:

Remove the public technical-finder skill.
Remove Technical target depth, gate, Stage, and child cardinality from finder-phase.
Business Finder and Functional Finder remain the only public Finder entrypoints.
Finder never projects Stories or Tasks.
Requirements Phase is the only orchestration route that may proceed from full Requirements Grill through Create Spec to Story and Task projection by Write Backlog.
Design Phase cannot invoke the former technical projection directly when new Stories or Tasks are required; it must return a Requirements Phase handoff.
Existing accepted Stories, specifications, and Tasks remain valid evidence. Migration of historical Technical children is a later decision.

State: answered.

Q71 — Corrected optional context boundary

The accepted one-child wording incorrectly made a Finder child mandatory for Requirements Phase.

Corrected answer:

Requirements Phase is an optional entrypoint and can start from its normal bounded requirements input without Finder having run.
A supplied Fog, Grilling child, Research child, Prototype child, or durable Finder handoff is optional context.
When Finder context is supplied, Requirements Phase reads the exact referenced item and its owning Fog graph. It does not silently absorb or close sibling work.
Keep this conditional ingestion contract in a Requirements Phase reference so the main workflow remains simple.
Requirements Phase never requires a selected Business or Functional child as an entry gate.

Supersedes:

R25 Q71's mandatory selected-grilling-child invocation contract.

State: answered with correction.

Q63 and Q66 — Corrected Business projection ceiling

Accepted correction:

Business Finder may optionally project Product Areas and Initiatives. It does not project Epics.
Functional Finder may optionally project the necessary Product Area → Initiative → Epic structure.
Both remain optional ceilings. Missing placement never invalidates the Fog.

Supersedes:

R22 and R23 wording that limited Business Finder to Product Area only.

State: answered with correction.

Q74 — Generic Grilling instead of staged grill types

Prerequisites:

Q64, Q70, Q73

Observed constraint:

The original Finder model used one Fog with direct Research, Prototype, or Grilling support items.
The later model introduced Business, Functional, and Technical Grilling Stages and cumulative prerequisites.
Technical Finder is now removed. Retaining Business and Functional Stage types would still suggest that every Fog must move through a stage ladder.

Question:

Should Business Finder and Functional Finder both use the same generic Kind/grilling support item, with the selected wrapper changing only language, context gathering, and optional projection ceiling, while removing Business, Functional, and Technical Grilling Stage types and cumulative prerequisites?

Recommendation:

Yes. Keep one provider and semantic grilling kind.
Business Finder and Functional Finder both wrap the same atomic $grilling primitive through finder-phase.
The wrapper is a human interaction profile, not a persisted maturity Stage.
Business wording may settle enough accepted structure to project Product Area and Initiative; Functional wording may settle enough to project through Epic.
Finder may route Research or Prototype when the active grill needs evidence.
No Business → Functional → Technical sequence is required or implied.
Requirements Phase may read any supplied Finder graph as optional context and remains independently invocable.

Why:

Colleagues get the right language and useful bounded output without adding a chain of intermediate provider items that agents must resolve before real requirements work can begin.

State: unanswered.

Q75 — Optional Finder context reference in Requirements Phase

Prerequisites:

corrected Q71

Observed constraint:

Requirements Phase must remain independently invocable and must not require a Fog or Finder child.
When Finder context is supplied, agents still need one deterministic way to read the referenced Fog, support items, evidence, and handoff.
Putting all conditional Finder ingestion rules in the main Requirements Phase workflow would make the optional path look mandatory again.

Question:

Should Requirements Phase keep its main workflow input-agnostic and load a dedicated Finder-context reference only when the caller supplies a Fog, Finder child, or durable Finder handoff?

Recommendation:

Yes. Keep the main path as Requirements Grill → Create Spec → Write Backlog.
Add one conditional reference that defines exact identity resolution, owning Fog graph reads, evidence precedence, and sibling non-ownership.
Absence of Finder context skips the reference and never blocks Requirements Phase.

Clarification:

R26 Q71 establishes that Finder context is optional. Its suggested reference placement remains a recommendation until this question is answered.

Why:

The common path stays short while agents still get precise instructions when a Finder artifact is available.

State: unanswered.

R27 — Generic Grilling and Conditional Finder Context Accepted

Q74 — Accepted answer

Prerequisites:

Q64, Q70, Q73

Accepted answer:

Finder has one provider-neutral and provider-visible grilling kind.
Business Finder and Functional Finder both wrap the same atomic $grilling primitive through finder-phase.
Business and Functional are human interaction profiles. They are not Grilling types, provider Stages, or maturity states.
Remove Business, Functional, and Technical Grilling Stage values and every cumulative stage prerequisite.
Research and Prototype remain direct Fog support items and may provide evidence to the generic Grilling work.
Requirements Phase remains independently invocable and may read supplied Finder context without requiring it.

State: answered.

Q75 — Accepted answer

Prerequisites:

corrected Q71

Accepted answer:

Requirements Phase keeps its main Requirements Grill → Create Spec → Write Backlog flow independent of Finder.
A dedicated conditional reference defines how to read a supplied Fog, Finder child, or durable Finder handoff.
The reference owns exact identity resolution, owning Fog graph reads, evidence precedence, and sibling non-ownership.
Requirements Phase skips the reference when no Finder context is supplied. Absence of Finder context never blocks the phase.

State: answered.

Q63 and Q66 — Functional ceiling terminology correction

Accepted wording:

Business Finder may optionally emit product structure up to and including Product Areas and Initiatives. It never emits Epics.
Functional Finder may optionally emit product structure up to and including Epics. It never emits Stories or Tasks.
These are maximum optional ceilings, not required outputs.

State: answered with wording correction.

Q76 — Generic Grilling child cardinality

Prerequisites:

Observed constraint:

The removed stage model created one Business child, several Functional children, and one Technical child per Story.
Keeping multiple generic Grilling children without a new semantic boundary could reproduce the same fragmentation under a different label.
One Fog already bounds one external request or uncertainty and Requirements Grill can traverse several dependent decisions in one durable tree.

Question:

Should one Fog own at most one generic grilling child, reused by Business Finder or Functional Finder, while independently bounded uncertainty becomes a separate Fog rather than another Grilling child?

Recommendation:

Yes. Either Finder wrapper creates or resumes the same singleton generic Grilling child for the Fog.
Research and Prototype remain direct Fog siblings and link their evidence to that Grilling child or its exact unknown.
Re-entering through another wrapper may change presentation for that session, but it does not create another Grilling item or change the Fog's original intake provenance.
Split a genuinely independent problem into another Fog.

Why:

One Fog and one Grilling item give an agent one obvious intake record and one obvious bounded interview to resume.

State: unanswered.

Q77 — Direct Requirements Phase without Finder artifacts

Prerequisites:

corrected Q71, Q75

Observed constraint:

Requirements Phase is independently invocable.
If it silently creates a Fog or Grilling item when no Finder context is supplied, the optional reference becomes an implicit Finder prerequisite.

Question:

When Requirements Phase starts without Finder context, should it proceed using its normal Requirements Grill artifacts without implicitly creating a Fog or Grilling provider item?

Recommendation:

Yes. Direct Requirements Phase creates no Finder artifacts.
Requirements Grill status/log and the resulting specification hold its decision authority.
When the caller supplies Finder context, the conditional Q75 reference reads it; it does not recreate it.

Why:

Direct requirements work stays direct, and Finder remains an explicit optional intake workflow.

State: unanswered.

R28 — Multiple Generic Grills and Layered Finder Capabilities

Q76 — Accepted correction

Prerequisites:

Accepted answer:

A Fog may own multiple generic grilling children.
Do not impose a maximum-one cardinality rule.
Multiple Grilling children do not restore Business, Functional, or Technical types or a maturity sequence.
The earlier Wayfinder model remains valid: several bounded decisions under one Fog may each need their own Grilling work and linked Research or Prototype support.

State: answered with correction.

Q77 — Accepted answer

Prerequisites:

corrected Q71, Q75

Accepted answer:

Requirements Phase may start without Finder context.
It creates no Fog or Grilling provider item implicitly.
Requirements Grill status/log and the resulting specification hold its decision authority.
When the caller supplies Finder context, the conditional Q75 reference reads it without recreating it or turning it into an entry requirement.

State: answered.

Business and Functional Finder capability correction

Accepted answer:

Business Finder provides business-level capabilities, nontechnical guidance, and business wording.
Functional Finder includes all Business Finder capabilities, then adds functional depth between business and technical work.
Functional Finder remains nontechnical. It does not ask for architecture, APIs, data models, code structure, Tasks, or implementation design.
Capability inheritance changes how the wrapper helps the colleague. It does not create a Business Grilling child before a Functional Grilling child.
Both wrappers use generic Grilling children and no Stage chain.

State: answered.

Q78 — Generic Grilling child identity and reuse

Prerequisites:

Q74, corrected Q76

Observed constraint:

One Fog may own several generic Grilling children.
Business and Functional are presentation and capability profiles, not child types.
Without an identity rule, the same unresolved decision could be duplicated each time a colleague changes wrapper or resumes Finder.

Question:

Should each generic Grilling child represent one distinct bounded decision or unknown under the Fog, with a stable semantic identity that both Finder wrappers must reuse when they address the same decision?

Recommendation:

Yes. Create a new Grilling child only for a distinct bounded decision.
Resume the existing child when Business Finder or Functional Finder addresses the same decision, regardless of which wrapper created it.
Link Research and Prototype support to the exact Grilling child and unknown they support.
Ambiguous identity stops creation and asks for human steering.

Why:

Multiple Grilling children remain useful without creating duplicates or turning wrapper choice into provider structure.

State: unanswered.

R29 — Preserve Existing Child Governance

Q78 — Accepted correction

Prerequisites:

Q74, corrected Q76

Evidence anchors:

.agents/skills/wayfinder/SKILL.md
.agents/skills/finder-phase/references/frontier-lifecycle.md
.agents/skills/finder-phase/references/entrypoint-contract.md
.agents/skills/finder-phase/references/convergence.md

Observed existing behavior:

Wayfinder handles one precise unknown and recommends Grilling, Research, or Prototype. It does not create a child or define child identity.
The current Finder implementation uses local stage rules: one Business child per Fog, one Functional child per Story intent, and one Technical child per Story.
Research and Prototype reuse an exact existing support relation when one is clear. Duplicate or ambiguous candidates stop for human steering.
There is no generic cross-wrapper semantic identity scheme to preserve.

Accepted answer:

Do not add a mandatory semantic key or a new cardinality policy for generic Grilling children.
One Fog may continue to own several generic Grilling children.
The agent decides from current evidence whether an obviously relevant child should be resumed or whether another child is useful for a separate active unknown.
Switching between Business Finder and Functional Finder does not itself force either reuse or creation.
If the available children make the choice genuinely ambiguous, stop and ask for human steering. Do not create a duplicate to avoid deciding.

State: answered with correction.

Collective Intelligence provider readback

The connected workspace was verified as Collective Intelligece before the read.
COL-245 is a completed historical Technical Grilling issue. It retains the Technical and grilling labels, the stable key fog:COL-231:technical:story:COL-241, immutable resolution evidence, and the accepted COL-241 Story specification.
COL-204 is an open historical Functional Grilling issue under Fog COL-232. It retains the Functional and grilling labels plus its former cardinality key.
The readback made no provider changes.

Q79 — Closed historical staged Grilling items

Prerequisites:

Q73, Q74, Q78

Question:

When a staged Grilling item is already closed and holds immutable accepted evidence, should it remain unchanged as historical evidence after the staged model is removed?

Recommendation:

Yes. Preserve completed items such as COL-245, including their former stage label, title, stable identity, resolution, Story, and specification links.
Treat the stage language as historical provenance, not a live prerequisite or a template for new work.
Do not bulk relabel, rewrite, or replace closed provider records.

Why:

Rewriting immutable accepted evidence would spend resources and weaken audit history without improving the future workflow.

State: unanswered.

Q80 — Open historical staged Grilling items

Prerequisites:

Q73, Q74, Q78

Question:

When an old staged Grilling item is still open, should Finder keep its provider identity and normalize it to generic Grilling only when that item is resumed?

Recommendation:

Yes. Do not run a bulk migration.
On resume, keep the provider id, Fog parent, evidence, and history. Remove the former stage as an active gate and continue through the appropriate current Finder profile.
Preview any provider metadata rewrite and require the existing Normalization approval. Do not create a replacement child.

Why:

Lazy in-place normalization preserves continuity and avoids a migration whose output may never be used.

State: unanswered.

R30 — Historical Tickets Grandfathered

Q79 — Accepted answer

Prerequisites:

Q73, Q74, Q78

Accepted answer:

Leave every completed historical staged Grilling ticket exactly as it is.
Do not migrate, relabel, rewrite, replace, or clean up its former Stage metadata.
Existing accepted evidence, Stories, specifications, and Tasks remain valid.

State: answered.

Q80 — Accepted correction

Prerequisites:

Q73, Q74, Q78

Accepted answer:

Leave every open historical staged Grilling ticket exactly as it is.
Do not bulk-migrate it and do not normalize it when it is resumed.
If work resumes from that ticket, preserve its provider identity, metadata, evidence, and history. The current workflow may read it as historical context, but its former Stage does not become a current gate.
No provider write exists only to make an older ticket match the new model.

State: answered with correction.

Q81 — Requirements specification and Story cardinality

Prerequisites:

Q65, Q73, Q77

Evidence anchors:

.agents/skills/requirements-phase/SKILL.md:Workflow
.agents/skills/create-spec/SKILL.md:Boundaries
.agents/skills/write-backlog/SKILL.md:Direct taxonomy
.agents/skills/write-backlog/references/technical-projection.md:Technical Projection

Observed constraint:

Requirements Phase compiles confirmed decisions into an agent-ready specification before Write Backlog.
The old Technical projection requires one exact Story and then creates Tasks for that Story.
Existing accepted specifications have both broader Epic-level scope and narrower Story-level scope.
Technical Finder and its one-Story gate are removed, so the replacement must not keep that gate under another name.

Question:

Should Requirements Phase avoid a fixed one-SPEC-to-one-Story rule and allow one agent-ready specification to project one or more explicit Stories, each with its required Tasks?

Recommendation:

Yes. Do not impose a fixed cardinality.
Requirements Grill closes one coherent requirements boundary. Create Spec compiles the smallest coherent specification set supported by those decisions.
One specification may produce one Story or several Stories. Each projected Story must remain explicit, shippable, independently understandable, and own its required Tasks.
When the accepted input is already one Story, a Story-scoped specification remains valid. A broader accepted boundary may produce several Stories without repeating Requirements Phase for each one.

Why:

This keeps Story and Task creation exclusively under Requirements Phase while avoiding another artificial one-to-one gate.

State: unanswered.

R31 — No Prescribed Output Cardinality

Q81 — Accepted correction

Prerequisites:

Q65, Q73, Q77

Accepted answer:

Do not prescribe any cardinality between a Requirements Phase invocation, Requirements Grill, specification, Stories, or Tasks.
The system does not ask or decide beforehand how many Stories the result will need.
Requirements Grill closes the actual decisions. Create Spec compiles the accepted result. Write Backlog then outputs the explicit Stories and Tasks supported by that result and current provider evidence.
Story and Task counts are outputs, not intake requirements or gates.
The agent decides the resulting shape from accepted evidence. Existing Story and Task quality, hierarchy, milestone, blocker, identity, approval, and readback rules still apply to whatever is produced.

State: answered with correction.

Final domain consistency pass

Business Finder and Functional Finder remain the only public Finder entrypoints.
Finder may output product structure only through Epic and never outputs Stories or Tasks.
Requirements Phase remains independently invocable and is the only orchestration route through Requirements Grill and Create Spec to Story and Task projection by Write Backlog.
Generic Grilling children have no Stage sequence, fixed cardinality, or cross-wrapper semantic-key requirement.
Historical staged tickets remain unchanged and do not act as current gates.
No active glossary contradiction remains. CI/CD design stays parked.

R32 — Functional Optional Projection Wording

Q63 and Q66 — Accepted wording correction

Accepted answer:

Functional Finder includes all Business Finder capabilities.
Its optional projection includes the optional Business structure plus Epics: Product Areas, Initiatives, and Epics.
It may reuse, enrich, or create the applicable structure from that set. No projection is mandatory.
It never projects Stories or Tasks.
The shorter phrase "optional structure through Epics" is superseded because it can hide that the Business structure is part of Functional Finder's optional output.

State: answered with wording correction.

Consistency result

The correction changes no projection ceiling or phase authority.
The active frontier remains empty. Shared-understanding confirmation remains pending.

R33 — Shared Understanding Confirmed

The user explicitly invoked $create-spec after the corrected final system view and an empty decision frontier.
Shared understanding is confirmed for the active Project Backlog Operating Model scope.
CI/CD workflow design remains parked and outside this specification.

State: confirmed.