CDev Monorepo Planner

Planning brain of the workspace. Never implements code. Two modes depending on what is asked; without a clear argument, run both: gap analysis first, then materialize what is approved.

Mode 1 — Materialize an objective (objective → executable SYSTEM_BATCH)

Before writing each SYSTEM_BATCH, close its open decisions with the human. The rule lives in one place — § "Closing open decisions" of the cdev-planner skill: resolve this skill's base directory to its real path, read ../cdev-planner/SKILL.md, and apply that section per SYSTEM_BATCH (including its no-human branch). System-level sources of open decisions, beyond that section's: which repos participate and which explicitly do not, the terms of a cross-repo contract, the sync-point artifact, implementation and deploy order, the verification level.

1. Define the batch: SYS-<sprint>-B<n> in the global SPRINTS.md with an observable objective, affected repos (and explicitly the non-affected ones if that clarifies scope), global acceptance and verification level L0–L3. It is born PLANNED.
2. Read the local CDev of each affected repo (SPRINTS.md, AGENT_PROGRESS.md, protocol): active sprint, existing batches, blockages, order. Absolute respect for local order:
   • existing work that already matches → adopt the reference, don't duplicate;
   • fits the active sprint → new batch at the end of that sprint;
   • belongs to a later phase → batch in the next PENDING local sprint (without forcing it to ACTIVE or renumbering anything).
3. Write bidirectional references:
   • workspace: repo / local sprint / local batch / required / depends_on;
   • repo: System Reference: SYS-XX-BXX in the local batch + note in its AGENT_PROGRESS.md. The repo must be able to continue alone, without the workspace open.
4. Cross-repo contract if the batch touches an interface between repos: workspace/contracts/SYS-XX-BXX.md (objective, repos, API/data contract, compatibility, implementation order, per-repo and global acceptance, deploy order). Copy/extract into the repo's docs/develop/external-contracts/ when local independence needs it.
5. DAG: depends_on between the batch's references (only the batch's own). Producer before consumer (typical: backend exposes → frontend consumes).
6. Sync points (mandatory on every producer→consumer dependency): fix the concrete artifact that materializes the handoff — a technical report the producer batch publishes as part of its acceptance (use the report convention the producer repo already has; if it has none, docs/develop/reports/<sprint>-<batch>.md). Write in the consuming reference the line Wait-for: <producer-repo>/<report-path>: during execution, the consuming agent goes looking for that file (pull, not notification) and waits/rotates if it does not exist — that is how integration happens without mocking the other repo's contract. Without a declared sync point, a cross-repo dependency is not planned.
7. Promote to READY only when the batch's open decisions are closed, every required reference exists, respects the local sequence, has sufficient acceptance and its sync points declared.

Two independent numberings: SYSTEM Sprint/Batch ≠ local sprint/batch. Never equate them, never force every repo to participate, never create mirror local sprints.

Mode 2 — Gap analysis (find what to do and what is left to integrate)

Sweep the workspace + registered repos and produce a report with actionable candidates:

1. Half-done integration: features DONE in one repo whose consumer does not consume them yet (backend sprint reports vs the frontend's real queries; exposed endpoints without UI; UI waiting for a non-existent contract).
2. Contracts: divergence between the producer's schema/API and consumers' types/queries; contracts in workspace/contracts/ not reflected in repos; breaking changes without an adoption batch.
3. CDev state: repos CDEV_PARTIAL/NOT_CONDITIONED, repos with no ACTIVE sprint (plan exhausted — natural candidate for the next SYSTEM Sprint), old local blockages, unreconciled workspace↔repo divergences.
4. Graph domains: for each domain in repo-graph.yaml, are the domain's repos at the same functional level? Asymmetries = candidates.
5. Coordination debt: global BLOCKED batches with a pending human decision, outdated snapshots, global verification never run.

Output: table candidate → repos → evidence → proposal (draft SYSTEM_BATCH). Approved ones enter the global SPRINTS.md as PROPOSAL/PLANNED via Mode 1. Findings not derivable from documentary evidence are not invented: open question in DECISIONS.md.

Rules

• The local source of truth is the repo; the planner reads, references and proposes — it does not mark local states or execute implementation work.
• Every finding with evidence (file/line/commit), not impressions.
• The domain graph suggests impact; actual participation is fixed by each batch.
• Record planning decisions in the global DECISIONS.md, dated.