fix-wg-html — Workgraph live mirror

Metadata

Status	failed
Assigned	`agent-1391`
Agent identity	`f51439356729d112a6c404803d88015d5b44832c6c584c62b96732b63c2b0c7e`
Created	2026-05-01T19:22:24.328863456+00:00
Started	2026-05-01T19:47:03.291384010+00:00
Tags	`fix,html,deploy,ux`, `eval-scheduled`
Tokens	4196457 in / 18776 out
Failure reason	rescue eval unavailable after 2 attempts; falling back to terminal failure

Description

wg html publish remove <name> marks the corresponding .html-publish-<name> task as abandoned but doesn't delete it from the graph. As a result, attempting wg html publish add <same-name> fails with 'Task with ID already exists'.

User report 2026-05-01: removed a 'public-mirror' deployment, then tried to re-add with the same name, got error 'Task with ID .html-publish-public-mirror already exists'.

Two acceptable behaviors

A: remove fully deletes the task (recommended)

The user's intent with 'remove' is clear — they want it gone, including the scheduling task. Just abandoning it leaves a footgun for re-add. Make remove perform a full delete (graph entry + any worktree + any associated artifacts).

B: add reuses an abandoned task with the matching ID

If 'remove' must keep the abandoned task around for audit/history, then 'add' should either:

Detect an abandoned task with the same ID and reactivate it (status: abandoned → open, replace its config), OR
Fail with a clearer hint: 'Task .html-publish-X exists in abandoned state. Pass --force to overwrite, or use a different deployment name.'

Recommend A. 'Remove' should mean remove. The history of 'we had this deployment and removed it' is captured in the graph operation log already.

Validation

Failing test: register deployment foo; remove foo; re-add foo — succeeds without conflict
If A: wg list after remove shows NO .html-publish-foo task (entirely gone)
If B: wg html publish add foo after a prior remove succeeds AND reports 'reactivated previously-abandoned deployment'
No regression: deployments that ARE active can't be accidentally removed (require explicit confirmation OR --force)
cargo build + cargo test pass
cargo install --path . was run before claiming done

## Description
`wg html publish remove <name>` marks the corresponding `.html-publish-<name>` task as abandoned but doesn't delete it from the graph. As a result, attempting `wg html publish add <same-name>` fails with 'Task with ID already exists'.

User report 2026-05-01: removed a 'public-mirror' deployment, then tried to re-add with the same name, got error 'Task with ID .html-publish-public-mirror already exists'.

## Two acceptable behaviors

### A: remove fully deletes the task (recommended)
The user's intent with 'remove' is clear — they want it gone, including the scheduling task. Just abandoning it leaves a footgun for re-add. Make remove perform a full delete (graph entry + any worktree + any associated artifacts).

### B: add reuses an abandoned task with the matching ID
If 'remove' must keep the abandoned task around for audit/history, then 'add' should either:
- Detect an abandoned task with the same ID and reactivate it (status: abandoned → open, replace its config), OR
- Fail with a clearer hint: 'Task .html-publish-X exists in abandoned state. Pass --force to overwrite, or use a different deployment name.'

Recommend A. 'Remove' should mean remove. The history of 'we had this deployment and removed it' is captured in the graph operation log already.

## Validation
- [ ] Failing test: register deployment foo; remove foo; re-add foo — succeeds without conflict
- [ ] If A: `wg list` after remove shows NO `.html-publish-foo` task (entirely gone)
- [ ] If B: `wg html publish add foo` after a prior remove succeeds AND reports 'reactivated previously-abandoned deployment'
- [ ] No regression: deployments that ARE active can't be accidentally removed (require explicit confirmation OR --force)
- [ ] cargo build + cargo test pass
- [ ] cargo install --path . was run before claiming done

Depends on

done .assign-fix-wg-html

Required by

failed .flip-fix-wg-html

Log

2026-05-01T19:22:24.189345487+00:00 Task paused
2026-05-01T19:46:34.013482326+00:00 Task published
2026-05-01T19:47:00.438595826+00:00 Lightweight assignment: agent=Careful Programmer (f5143935), exec_mode=full, context_scope=task, reason=Careful Programmer is the only programmer agent available with proven track record (513 tasks, 0.80 score) - Careful tradeoff ensures correctness on a bug fix with explicit validation requirements; full access needed for code modification, testing, and binary installation.
2026-05-01T19:47:03.291389869+00:00 Spawned by coordinator --executor claude --model opus
2026-05-01T19:47:12.867146952+00:00 Starting: investigating wg html publish remove behavior
2026-05-01T20:38:15.741179106+00:00 Agent exited without wg done — entering failed-pending-eval for rescue evaluation
2026-05-01T20:41:30.673108512+00:00 FailedPendingEval → Failed (rescue eval unavailable after 2 attempts)