wg-publish-wcc

wg publish: --wcc flag publishes the entire weakly-connected component of the given node

Metadata

Statusdone
Assignedagent-1494
Agent identityf51439356729d112a6c404803d88015d5b44832c6c584c62b96732b63c2b0c7e
Created2026-05-02T02:45:07.348225435+00:00
Started2026-05-02T02:45:40.941763905+00:00
Completed2026-05-02T03:15:07.030490073+00:00
Tagsfix,publish,workflow,batch, eval-scheduled
Eval score0.90
└ blocking impact0.94
└ completeness0.91
└ constraint fidelity0.85
└ coordination overhead0.94
└ correctness0.92
└ downstream usability0.90
└ efficiency0.82
└ intent fidelity0.93
└ style adherence0.88

Description

Description

Currently wg publish <task> releases the task and its DOWNSTREAM subgraph (consumers). It does NOT release upstream ancestors. So when an agent (or user) builds a paused subgraph and calls wg publish <leaf>, only the leaf gets unpaused — the ancestors that need to run first are still paused. Result: agents end up looping over every task one-by-one (silly for loops) just to release a built batch.

User report 2026-05-01: 'we need a publish WCC subgraph type thing where we just give a terminal node and everything in the WCC of that node is unpaused and let run. b/c agents are writing silly for loops...'

Spec

New flag: --wcc

wg publish <task> --wcc       # publishes EVERY task in the weakly-connected component of <task>

WCC = treat the dependency graph as undirected; find the connected component containing ; unpause every task in that component (in topological order so dependencies are satisfied at each release).

Composes with existing flags

  • Default wg publish <task> — current behavior (task + downstream subgraph). Unchanged.
  • wg publish <task> --only — current behavior (just the one task). Unchanged.
  • wg publish <task> --wcc — new: entire WCC.
  • --wcc is mutually exclusive with --only.

Why WCC and not just 'upstream + downstream'

Multi-root subgraphs share dependencies. Example: 5 audit tasks all depend on a single setup task; 1 synthesis task depends on all 5. If user calls wg publish synthesis --wcc, the right release set is: the setup task + all 5 audits + the synthesis. WCC captures this naturally; 'upstream + downstream of synthesis' would also work for this case BUT 'upstream + downstream of any audit task' wouldn't include sibling audits without WCC semantics. WCC handles the shape robustly.

Topological order

Within the WCC, release in reverse-topological order so a task being unpaused has all its dependencies already unpaused. Avoids the brief window where a freshly-unpaused task is ready-but-its-upstream-isn't.

Common use case

Agent files a 12-task fan-out + synthesis in --paused state, then calls wg publish synthesis --wcc (or wg publish quality-pass --wcc to release from the upstream root). One command instead of 13 wg publish calls.

Make it discoverable

Update bundled wg agent-guide content (when fix-agents-md amends it) to recommend --wcc for batch-release patterns instead of looping. Same for any 'how to file batches' docs.

Validation

  • Failing test: build a 5-node subgraph paused (linear or fan-out), call wg publish leaf --wcc, ASSERT all 5 are open
  • Multi-root test: build A → B; A → C; B → D; C → D (diamond). wg publish D --wcc releases A, B, C, D.
  • No regression of wg publish <task> (default = task + downstream subgraph)
  • No regression of wg publish <task> --only (single task)
  • Mutually exclusive --wcc + --only errors at parse time
  • Topological order at release time (verifiable via the operations log timestamps)
  • cargo build + cargo test pass
  • Permanent smoke scenario added: build paused fan-out + synthesis; release via --wcc; assert all tasks open in topological order
  • cargo install --path . was run before claiming done

Coordinate with adjacent work

  • fix-agents-md (in flight): once this --wcc flag exists, the agent-guide bundled content should mention it as the canonical batch-release pattern. Update both AGENTS.md/CLAUDE.md callers (which become layer-2 only after fix-agents-md) and the bundled agent-guide.

Process note

This addresses an underlying ergonomic gap that's been driving agent for-loops. Once available + documented, agents naturally collapse 'release this whole batch' from N invocations to 1.

Depends on

Required by

Log