gps-denied-onboard/.cursor/skills/decompose/steps/01-7_system-pipeline-tasks.md

Step 1.7: System-Pipeline Tasks (implementation mode only)

Role: Professional software architect, integration-focused. Goal: For every end-to-end pipeline named in _docs/02_document/architecture.md and _docs/02_document/system-flows.md, ensure there is exactly ONE explicit task that owns the production code that drives that pipeline against real inputs. This step prevents the failure mode where every individual component is "complete" but no production code wires them together (May 2026 GPS-passthrough incident — see meta-rule.mdc "When a test reveals missing production code").

Constraints:

• This step produces integration tasks, not per-component tasks. Per-component tasks come from Step 2.
• An integration task's owner is typically the composition root, runtime root, main loop, or whichever component the module layout (Step 1.5) names as the "system spine". It is NEVER a leaf component.
• Each integration task must be sized at 5 points or fewer. If the pipeline is too large for one task, split it into per-stage integration tasks (e.g. "wire ingress → C1", then "wire C1 → C5") rather than one giant task.

Inputs

File	Purpose
_docs/02_document/architecture.md	Source of named end-to-end pipelines and their component sequences
_docs/02_document/system-flows.md	Source of operational flows (per-frame loop, request lifecycle, batch job, etc.)
_docs/02_document/module-layout.md	Produced by Step 1.5. Names the "system spine" component(s) — typically runtime_root, app, main, composition, or equivalent.
_docs/02_document/components/*/description.md	Per-component contracts so you can tell which side of a seam each method lives on

Steps

1. Enumerate end-to-end pipelines. Read architecture.md and system-flows.md. For each named pipeline / flow that spans 2+ components, record:
   • The pipeline name (e.g. "per-frame nav loop", "tile-cache build", "operator pre-flight verification").
   • The ordered sequence of components it touches (e.g. frame_source → c1_vio → c2_vpr → ... → c5_state → replay_sink).
   • The trigger (per-frame, per-request, scheduled, manual).
   • The output (what the pipeline emits and to whom).
2. For each pipeline, locate the owner. Use module-layout.md to find the component that owns the orchestration (the "spine"). If module-layout.md does not name one, STOP and ASK the user which component owns the pipeline. Do NOT silently default to the bootstrap structure task — bootstrap is about project skeleton, not behavior.
3. Check whether the pipeline is already covered by an existing task spec or by the bootstrap-structure task. A pipeline is "covered" only if:
   • A task spec's Outcome or Acceptance Criteria section explicitly names "drives the {pipeline_name} end-to-end against real production components", AND
   • That task's owned files include the orchestration code (typically the spine component's main loop / entrypoint).
4. For every uncovered pipeline, create a system-integration task spec in _docs/02_tasks/todo/ using .cursor/skills/decompose/templates/task.md:
   • Component: the spine component from step 2 (e.g. runtime_root).
   • Outcome: the production callsite that drives the pipeline exists and runs end-to-end on real inputs.
   • Scope / Included: the orchestration code (loop body, dispatcher, scheduler, entrypoint); explicit list of every component it must call in order; the data type at each seam.
   • Acceptance Criteria (write each as testable):
     • At least one production caller of every component method in the pipeline can be found by grep — name the methods explicitly.
     • The orchestration runs against the real production component instances (NOT mocks, NOT a passthrough that bypasses them).
     • At least one integration test exercises the orchestration end-to-end against real inputs.
   • Dependencies: every per-component task whose component appears in the pipeline.
   • Complexity points: ≤5; split the pipeline if it doesn't fit.
   • Tracker: create a ticket immediately (per decompose/SKILL.md "Tracker inline" principle); rename the file to [TRACKER-ID]_pipeline_<name>.md.
5. Mark the integration task as Dependencies for the integration test task. If tests-only decomposition has already produced an e2e/integration test task for this pipeline, append the new integration task to its Dependencies field so the test cannot be "made green" before the integration ships.

Anti-patterns this step explicitly blocks

• "compose_root returns a wired runtime" prose interpreted as "the loop exists". Composition assembles the graph; it is NOT the loop. The loop is the code that pulls inputs, drives each node, and emits outputs. If grep finds zero callers of the leaf components, the loop does not exist regardless of what compose_root does.
• Treating the bootstrap-structure task as the home of the main loop. Bootstrap is project skeleton (package layout, CLI scaffold, build files). It is NOT the main loop. Main loop is its own task.
• Per-component tasks claiming integration scope. A C1 VIO task's deliverable is "C1 works in isolation against unit tests". A C1 task's acceptance criteria MUST NOT include "C1 is wired into the runtime" — that's the integration task's job.

Self-verification

• Every pipeline named in architecture.md / system-flows.md is listed in your enumeration.
• Every enumerated pipeline either (a) has an existing covered task, or (b) has a new integration task in todo/.
• No integration task exceeds 5 complexity points.
• Every integration task names every component in the pipeline as a Dependencies entry.
• No integration task is owned by a leaf component — every owner is named in module-layout.md as a spine / orchestrator.
• Every integration task has a tracker ticket created and the filename renamed to [TRACKER-ID]_pipeline_<name>.md.

Save action

Write the new integration task files into _docs/02_tasks/todo/. They will be picked up by Step 2 (Task Decomposition's dependency-table writer) and by Step 4 (Cross-Verification).

Blocking

BLOCKING: Present the pipeline enumeration + the list of new integration tasks to the user. Do NOT proceed to Step 2 until the user confirms:

• The enumeration matches what they expect from the architecture documents.
• Every uncovered pipeline now has an integration task.
• The chosen spine owners are correct.

If the user identifies a pipeline you missed, add it before proceeding. If the user names a different spine owner, update the task and re-run self-verification.