← graph

verify-correct-wg

Verify + correct wg-publish-easy naming: wg publish <task-id> stays unchanged; new feature lives under wg html publish

Metadata

Statusdone
Assignedagent-1310
Agent identityf51439356729d112a6c404803d88015d5b44832c6c584c62b96732b63c2b0c7e
Created2026-05-01T00:16:18.629486880+00:00
Started2026-05-01T00:38:48.512755379+00:00
Completed2026-05-01T00:49:43.964725680+00:00
Tagspriority-high,fix,naming,cleanup, eval-scheduled
Eval score0.97
└ blocking impact1.00
└ completeness1.00
└ constraint fidelity0.85
└ coordination overhead0.95
└ correctness1.00
└ downstream usability0.95
└ efficiency0.85
└ intent fidelity0.76
└ style adherence1.00

Description

Description

Safety task that runs after wg-publish-easy lands. Verifies the new rsync-deployment feature was namespaced correctly (under wg html publish) and that the existing wg publish <task-id> command remained untouched. If wg-publish-easy shipped a refactor that broke wg publish <task-id>, this task corrects it.

Background

wg-publish-easy was originally specced to use wg publish add/list/run/... as the new command surface, which conflicted with the existing wg publish <task-id> (releases paused tasks). The agent's design note proposed renaming the existing command to wg publish task <task-id> to free up the verb.

User redirect via wg msg send 2026-04-30 (after design note posted): NOT acceptable. The existing wg publish <task-id> is everywhere (CLAUDE.md, agent-guide, every chat agent's batch-publish flow, muscle memory). The new feature should live under wg html publish — it's logically a sub-action of wg html anyway.

The redirect message may or may not have been picked up by the agent before commit. This task ensures the right outcome regardless.

What to do

Step 1: verify current state

After wg-publish-easy is done:

  • Run wg publish <some-task-id> against a paused task. Pre-this-task: it should EITHER work like always (if redirect was honored) OR error / route to wg publish task (if not).
  • Run wg html publish list (or whatever subcommand surface shipped). Pre-this-task: should exist if redirect was honored.

Step 2 (only if needed): correct the naming

If wg publish <task-id> was renamed to wg publish task <task-id>:

  1. Move the new add/list/run/show/remove/edit subcommands from wg publish to wg html publish
  2. Restore wg publish <task-id> to its original behavior (release paused task) — exactly as it was before wg-publish-easy
  3. Update any caller sites in src/ (the agent identified add.rs and quickstart.rs as the 4 caller sites; revert those)
  4. Update docs (CLAUDE.md, COMMANDS.md, agent-guide bundle, SKILL.md if needed) to reflect both old behavior preserved AND new wg html publish surface

If wg publish <task-id> is unchanged AND the new feature is under wg html publish already: this task does nothing substantive — just verifies and exits clean.

Step 3: smoke

Regardless of whether step 2 was needed:

  • wg add 'smoke-test' --paused && wg publish smoke-test — should publish (legacy behavior preserved)
  • wg html publish add testing --rsync /tmp/testdest --schedule '*/15 * * * *' — should register a deployment under the html publish surface
  • wg html publish list — should show 'testing'
  • wg html publish run testing — should execute
  • wg html publish remove testing — cleanup

Validation

  • wg publish <task-id> works exactly as it did before wg-publish-easy (paused-task release)
  • wg html publish add/list/show/run/remove/edit are all present and functional
  • No subcommand structure under wg publish other than the original <task-id> argument form
  • Docs reflect the final state (CLAUDE.md, COMMANDS.md, agent-guide if affected)
  • cargo build + cargo test pass
  • cargo install --path . was run before claiming done
  • No regression of any wg publish callers across the codebase

Process note

This is the kind of safety task that should ideally not be needed — but the message-injection mechanism (wg msg send) is best-effort and the agent may already be past the point where the redirect could change behavior. The cost of this task is small if the redirect was honored (it verifies + exits); the cost is medium if it wasn't (it un-does the rename). Either way the user ends up with the right state.

Depends on

Required by

Log