Project Backlog Operating Model Grill Status

Branch Dashboard

Overall completion: 100%. The active frontier is empty and shared understanding is confirmed. CI/CD workflow design remains parked outside this specification.

Parked branches:

• CI/CD workflow design and pipeline-to-provider automation.
• Branch-protection and repository-ruleset enforcement.
• Release-branch provenance and automated shipped-time history.
• Automatic scheduling and prioritization.
• Exact cadence that invokes Normalization.
• Azure DevOps and monday.com support.

Glossary

Terms

• Product/Backlog Root: one provider-native product destination above Product Areas, Initiatives, and Epic Projects. In Linear it is a top-level Initiative; one workspace may contain several roots.
• Product Area: stable top-level product responsibility within one Product/Backlog Root.
• Initiative: business goal within one Product Area.
• Epic: long-lived business slice within one Initiative. It may be enriched by several Fogs and span several milestone iterations.
• Story: shippable product outcome within one Epic.
• Task: required atomic shippable unit of Story work with explicit ownership and blocker relations.
• Fog: external intake, uncertainty, decision-history, and delivery-provenance record.
• Finder intake lens: immutable human-selected Business or Functional entry profile that controls intake language and maximum bounded projection without representing Fog maturity.
• Grilling child: direct Fog support item with generic Kind/grilling for bounded atomic $grilling. Business and Functional Finder apply presentation profiles; they are not Grilling types or Stages.
• Business Finder grilling: use of the shared atomic $grilling primitive with business language and context.
• Functional Finder grilling: use of the shared atomic $grilling primitive with functional language and context.
• Business Finder: public nontechnical intake lens with business-level capabilities, guidance, and wording. It creates or resumes one Fog and may project Product Areas and Initiatives, but not Epics.
• Functional Finder: public nontechnical intake lens with all Business Finder capabilities plus functional depth between business and technical work. Its optional projection includes Product Areas, Initiatives, and Epics. It never projects Stories or Tasks.
• Requirements Grill: exhaustive branch-by-branch decision closure over a bounded requirements input. Supplied Finder context is optional. Requirements Grill persists accepted, rejected, superseded, parked, and open requirements without performing provider projection.
• Requirements Phase: independently invocable phase that composes Requirements Grill, Create Spec, and post-spec Story and Task projection by Write Backlog. It may read optional Finder context from a reference contract.
• Linear Free projection profile: deterministic adapter mapping that uses one native Initiative root, Product Area Projects, and labeled parent-child Issues for Initiative, Epic, Story, and Task.
• V milestone iteration*: contextual V* provider milestone used as a delivery iteration. It is not a sprint or provider Cycle.
• Product Map: Product Area → Initiative → Epic view of the existing product shape.
• Roadmap: ordered V* milestone iterations with Story and Task progress rolled up to Epic and Initiative outcomes.
• Current Delivery: active Stories and Tasks grouped by milestone iteration, with status, owner, and blocker readiness.
• Normalization: write-backlog branch that reconciles provider state with durable evidence. Invocation cadence is external.

Relationships

• One Product/Backlog Root contains Product Areas.
• One Product Area contains Initiatives.
• One Initiative contains Epics.
• One Epic contains Stories.
• Every Story contains one or more Tasks.
• Every Story and Task belongs to exactly one V milestone iteration*.
• Product Areas, Initiatives, and Epics span milestone iterations.
• Fog remains outside the ownership hierarchy and records every structure and work item it enriched or produced.
• One Fog has exactly one immutable original Finder intake lens and may own several generic Grilling children plus direct Research and Prototype support children.
• Research and Prototype children identify the exact unknown or Grilling child they support.
• A Finder intake lens may add accepted structure up to its projection ceiling, but it does not prove that another lens ran or that the Fog is resolved.
• Requirements Phase may start without Finder. When a Fog, Finder child, or handoff is supplied, it reads that exact Finder context without making it an entry prerequisite.
• Requirements Phase runs Requirements Grill, compiles accepted specifications, and is the only orchestration route that delegates Story and Task projection to write-backlog.
• A Task may block a Task in the same Story, another Story, or another Epic when the dependency is real.
• A Task in Vn may depend only on Tasks in Vn or an earlier V milestone iteration*.

Axioms

• business-finder and functional-finder reach bounded atomic $grilling through finder-phase; neither loads or inherits $requirements-grill.
• Every public Finder entrypoint always invokes finder-phase; no entrypoint bypasses the shared lifecycle.
• finder-phase is the internal orchestration engine and resumable re-entry target, not a fourth public human entrypoint.
• business-finder, functional-finder, and finder-phase declare disable-model-invocation: true. A human must explicitly select a public wrapper; that wrapper may then explicitly compose the internal engine. No model or root router auto-selects or auto-starts Finder.
• Finder wrappers are direct-composition intake profiles. They own audience, intake lens, bounded projection ceiling, input and presentation policy, and return shape; the engine owns typed child creation and routing.
• The graph-based finder-phase engine alone owns routing, durable resume, support-work cycles, reconciliation, convergence, and target-depth return.
• Reaching a wrapper's target depth returns control without completing the Fog. Fog completion remains production-evidence based.
• Finder uses direct Fog support items for generic Grilling, Research, and Prototype. Business and Functional remain presentation-only profiles and create no Stage or maturity chain.
• One Fog may own several generic Grilling children. Wrapper choice never determines their identity or type.
• Finder reuses an obviously relevant generic Grilling child or creates another when current evidence supports a separate active unknown. The agent decides; ambiguous candidates stop for human steering.
• Historical staged Grilling tickets remain unchanged. Their former Stage is historical metadata and never becomes a current gate.
• Finder entrypoints reuse accepted existing structure where possible, but no intake lens or lower-stage projection is a prerequisite for Requirements Phase.
• business-finder uses $wait-what language and $show-me before grilling, at structural decisions, and before writes.
• Business Finder may emit or enrich Product Areas and Initiatives through write-backlog; Initiative is its accepted projection ceiling.
• Functional Finder may optionally reuse, enrich, or create Business structure plus Epics through write-backlog: Product Areas, Initiatives, and Epics. It never projects Stories or Tasks.
• Functional Finder includes Business Finder's capabilities and adds functional depth. This capability inheritance does not require a prior Business Grilling child.
• Functional grilling settles actor, trigger, workflow, observable result, applicable domain rules, visible alternate/failure paths, acceptance signals, boundaries, known product dependencies, technical handoff questions, and target V* milestone.
• Functional grilling does not require architecture, APIs, data models, component boundaries, code structure, Tasks, workers, commands, or implementation design.
• Requirements Phase is independently invocable. It alone invokes full $requirements-grill, compiles agent-ready specifications, and authorizes Story, Task, and blocker projection through write-backlog.
• A Requirements Phase reference defines how to read an optional supplied Fog, Finder child, or durable Finder handoff. Finder context is never an entry requirement.
• When no Finder context is supplied, Requirements Phase creates no Fog or Grilling item implicitly.
• Business and Functional Finder grilling require immutable accepted resolution evidence but never produce or imitate an agent-ready implementation specification.
• Task projection requires Requirements Grill closure and an agent-ready SPEC.md; it does not require Technical Finder.
• write-backlog is the only physical provider mutation authority; there is no separate Epic-creation skill.
• No Business → Functional → Technical grilling chain exists as a Requirements Phase prerequisite.
• functional-finder may start a Fog and may create or enrich structure through Epic when accepted evidence makes the operation unambiguous.
• Finder never projects Stories or Tasks. Requirements Phase is the only orchestration route to those levels; write-backlog remains the physical writer.
• Design Phase hands back to Requirements Phase when accepted design evidence requires new Stories or Tasks.
• linear-free-v1 is the sole default Linear Free profile. Provider writers use one native Initiative root, Product Area Projects, and Kind-labeled parent-child Issues for Initiative → Epic → Story → Task. They do not create nested Initiatives or Agile Initiative Projects; divergent existing topology requires an approved Normalization migration.
• Research and Prototype are direct Fog children linked to the exact unknown or generic Grilling child they support. Neither authorizes backlog projection by itself.
• New and resumed work preserves one Fog identity and its immutable intake lens. Normalization may propose backlog-topology changes behind existing approval gates; historical staged Grilling tickets are excluded.
• Stable provider ID plus durable wiki identity is required for upsert. Titles alone never authorize a write; ambiguity stops all writes.
• Reuse fitting structures and milestone iterations before proposing new ones.
• Boundary, goal, parent, roadmap, duplicate closure, and reorganization changes require preview and explicit approval.
• Every Task is atomic, shippable, independently owned, and connected through blockers so planning can form ordered parallel delivery waves.
• Validate the full reachable Task graph. Reject missing targets, future-iteration dependencies, self-edges, and cycles.
• Fog completion requires production evidence for its accepted resulting delivery scope. Merge alone is insufficient.
• Cancelled and Superseded Fogs receive no completion credit. Linear may use Canceled for both.
• CI/CD design remains parked.

Flagged Ambiguities

• None active. CI/CD design remains parked outside this closure.

Provider API Validation

Linear

• Live Devpunks Harness Project: 5780e683-0f87-4c6c-85dc-9122dcee9023, HARNESS-INTELLIGENCE.
• Current Harness state: no attached Initiative; M1-M14 Project milestones; existing Epic issues with Story child issues.
• One workspace can host several independent top-level Initiative trees. Devpunks currently has separate Internal projects and Customer projects roots.
• Live MCP shapes support parent/sub-Initiatives, Project-to-Initiative membership, Project milestones, and Issue project, parentId, milestone, blockedBy, blocks, relatedTo, and duplicateOf.
• Issue #183 final Linear Free readback supersedes the former nested-Initiative mapping: Product/Backlog Root = native Initiative; Product Area = Project; Initiative = Issue Kind/initiative; Epic = child Issue Kind/epic; Story = child Issue Kind/story; Task = child Issue Kind/task; Story and Task share one Project Milestone.
• The live IP team has Todo, Backlog, In Progress, Done, Canceled, and Duplicate states. Superseded may use Canceled.
• MCP aliases are crossed in this session: linear_collective reaches Devpunks and linear_devpunks reaches Collective Intelligence. Provider preflight must verify stable workspace identity instead of trusting the alias.

GitHub

• GitHub connector and gh CLI can read the private wearedevpunks/harness-intelligence Issues API.
• REST supports repository milestones and sub-issues.
• GraphQL schema exposes Project V2 items, fields, views, Issue parent/sub-issue and blocker fields, addSubIssue, removeSubIssue, addBlockedBy, removeBlockedBy, and Project V2 mutations.
• The current GitHub token has project, read:org, and repo; live organization Projects V2 discovery is available.
• wearedevpunks has nine Projects V2. None is linked to wearedevpunks/harness-intelligence.
• Collective Intelligence Project V2 number 4 has 78 items, 24 fields, and 15 views. Its repository Issues prove Epic → Story parents/sub-issues, milestones, blockers, semantic fields, Roadmap, and Dependencies views.
• Project 4 has no Story → Task grandparent example. Recursive parent/sub-issue fields and mutations support that depth, but the first workflow-created Task needs provider readback before runtime coverage can be claimed.
• Organization Issue Types currently expose Task, Bug, and Feature only. Remaining canonical concepts require Project V2 fields or stable naming conventions.

Current-Code Grounding

Dispositions

Current Round

• Round: R33
• Current frontier: empty
• Shared-understanding confirmation: confirmed