← graph

synthesis-roadmap-from

Synthesis: roadmap from the rate-limit supervisor, telemetry, parallelism, and npm-distribution studies

Metadata

Statusdone
Assignedagent-805
Created2026-07-25T13:33:06.603816463+00:00
Started2026-07-25T20:48:42.809322605+00:00
Completed2026-07-25T21:00:40.908088806+00:00
Tagssynthesis, roadmap, planning
Tokens3158759 in / 35122 out

Description

Objective

Fan-in synthesis of the four sibling study design docs into ONE unified roadmap, then AUTONOMOUSLY decompose that roadmap into concrete implementation tasks and spawn them into the graph (create + publish), with correct dependencies. This task is the keystone planner — once the four studies are done, it runs without human intervention and stands up the implementation sub-graph.

Inputs (read all four)

  • docs/studies/supervisor-hard-agent-design.md (long-lived supervisor hard-agent)
  • docs/studies/ratelimit-cost-telemetry-design.md (rate-limit/cost detection from parsed pi output + OpenRouter surface)
  • docs/studies/adaptive-parallelism-budget-design.md (max_agents / cost-time budget controller)
  • docs/studies/wg-npm-distribution-design.md (cross-compile + npm distribution)

Step 1 — Synthesize the roadmap

Produce docs/studies/roadmap-rate-limit-and-distribution.md covering:

  • Cross-cutting themes and shared substrate across the four designs (e.g. the telemetry failure-signal is consumed by BOTH the supervisor and the parallelism controller — call out shared seams so they are built once).
  • Dependency-ordered build sequence with rationale: what unblocks what (telemetry/detection likely precedes the supervisor and the controller; the supervisor and controller share the max_agents authority fix; npm distribution is independent and can run in parallel).
  • Prioritization (what to build first for the most leverage), risk register, and explicit sequencing of the max_agents authority/reload-override fix (a shared prerequisite).
  • Clear mapping: each roadmap item → which study it came from.

Step 2 — Decompose into implementation tasks

Turn the roadmap into concrete, well-scoped implementation tasks. Each MUST have:

  • A clear objective and a ## Validation section with concrete checks (tests, files, behaviors).
  • Correct --after dependencies (on this synthesis task and/or on each other) so the sub-graph is buildable in order.
  • Tags appropriate to the work.
  • NO per-task model pin (let them route through the active zai profile/dispatcher — do not hard-pin models).

Step 3 — Spawn them autonomously (no human intervention)

For each implementation task: wg add "<title>" --independent --after <deps> -d "<description w/ ## Validation>" -t <tags> then wg publish <id> --only so the coordinator dispatches it on zai. Respect the max_child_tasks_per_agent guardrail (currently 10); if the roadmap needs more implementation tasks than the limit allows, create a follow-on planner task that continues the decomposition rather than silently dropping work.

Step 4 — Record what you did

Append a log entry on THIS task (wg log) summarizing: the roadmap path, the spawned implementation task IDs + one-line purpose each, and the dependency wiring. Also note anything the studies left unresolved or risky.

Constraints

  • Stay on the active zai profile — do not pin tasks to other models.
  • Do not create duplicate or overlapping implementation tasks; reconcile overlaps across the four studies into single tasks where they share substrate.
  • Keep each implementation task independently validatable (a reviewer/evaluator can check it on its own).
  • If any of the four input design docs is missing or clearly incomplete, still synthesize from what exists and flag the gap in the roadmap + log (do not block).

Deliverable

  • docs/studies/roadmap-rate-limit-and-distribution.md
  • The spawned implementation sub-graph (tasks created + published).

Validation

  • Roadmap doc committed at docs/studies/roadmap-rate-limit-and-distribution.md
  • Roadmap covers all four studies, sequences them, identifies shared substrate + ordering rationale, and includes a risk register
  • Implementation tasks spawned via wg add + wg publish --only, each with a ## Validation section and correct --after dependencies
  • No per-task model pins (all route through the active zai profile)
  • No duplicate/overlapping impl tasks; respects max_child_tasks_per_agent (spawns a follow-on planner if more are needed)
  • Summary log entry on this task listing spawned task IDs + purpose + dependency wiring

Depends on

Required by

Log