engineers reserving a issue should lock it #494

New issue

Closed

opened 2026-07-02 00:54:07 +00:00 by coilysiren · 2 comments

coilysiren commented

2026-07-02 00:54:07 +00:00

Owner

The motivation here being that architects often naturally reach for posting comments on issues to clarify behavior while in flight. Or worse, edit comments. Locking the issue would reject that, and create a road block where we can direct the director to the correct behavior

coilyco-ops added the

consult

labels

2026-07-02 01:59:57 +00:00

coilyco-ops commented

2026-07-03 06:24:33 +00:00

Member

🔒 Reserved by ward agent --driver claude — container engineer-claude-ward-494 on host KAI-DESKTOP-TOWER is carrying this issue (reserved 2026-07-03T06:24:25Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); --force overrides.

— Claude (she/her), via ward agent

🔒 Reserved by `ward agent --driver claude` — container `engineer-claude-ward-494` on host `KAI-DESKTOP-TOWER` is carrying this issue (reserved 2026-07-03T06:24:25Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); `--force` overrides.  — Claude (she/her), via `ward agent`

coilysiren referenced this issue from a commit

2026-07-03 06:48:40 +00:00

feat(agent): lock a reserved issue's conversation as a road-block (closes #494)

coilysiren closed this issue

2026-07-03 06:48:40 +00:00

coilysiren commented

2026-07-03 06:49:29 +00:00

Author

Owner

Honest retro: the literal ask fought back a little. I went in expecting to call a "lock issue" API and wire it into the reservation. Turns out Forgejo (this instance, gitea-1.22 API compat) has no issue-lock endpoint at all - is_locked is readable but there's no POST .../lock leaf, so on our canonical forge a hard lock simply isn't reachable through ward ops. GitHub does have one, so I split it: lockIssue/unlockIssue on the forge interface, real gh api PUT/DELETE .../lock for GitHub, and a typed errForgeLockUnsupported sentinel for Forgejo that the caller downgrades from cleanly.

The second surprise reframed the whole thing: a platform lock doesn't hard-block a collaborator/owner anyway - it's friction, a "unlock to comment" pause. Since the architect is usually the owner, the real deliverable is the road-block, not an unbreakable gate. So the load-bearing change on Forgejo is actually the strengthened reservation comment (do not comment/edit to steer a run; corrections go to a fresh dispatch), which is the enforcement the agent-reserved-immutable doc had flagged as "convention, not a gate" - this closes that gap.

Confidence: high on the plumbing. Both clients are tested, the three lock-outcome branches (locked / unsupported / soft-fail) are covered, and the lock is strictly best-effort so it can never wedge a reservation. Rough edges worth a follow-up: unlock is only wired into the reaper's pre-launch-death release, which is Forgejo-only today, so a failed GitHub run could strand a lock until a human unlocks (benign, but real). And if Forgejo ever ships a lock endpoint, the clean path is a ward-kdl lock issue verb + spec-lock regen rather than the sentinel. Happy to file those if wanted.

WARD-OUTCOME: done - reserving an issue now road-blocks in-flight steering: an explicit "don't comment/edit, file a fresh issue" directive in the reservation comment, plus a real conversation lock on forges whose API supports it. Honest retro: the literal ask fought back a little. I went in expecting to call a "lock issue" API and wire it into the reservation. Turns out **Forgejo (this instance, gitea-1.22 API compat) has no issue-lock endpoint at all** - `is_locked` is readable but there's no `POST .../lock` leaf, so on our canonical forge a hard lock simply isn't reachable through `ward ops`. GitHub *does* have one, so I split it: `lockIssue`/`unlockIssue` on the forge interface, real `gh api PUT/DELETE .../lock` for GitHub, and a typed `errForgeLockUnsupported` sentinel for Forgejo that the caller downgrades from cleanly. The second surprise reframed the whole thing: a platform lock doesn't hard-block a collaborator/owner anyway - it's *friction*, a "unlock to comment" pause. Since the architect is usually the owner, the real deliverable is the road-block, not an unbreakable gate. So the load-bearing change on Forgejo is actually the strengthened reservation comment (do not comment/edit to steer a run; corrections go to a fresh dispatch), which is the enforcement the `agent-reserved-immutable` doc had flagged as "convention, not a gate" - this closes that gap. Confidence: high on the plumbing. Both clients are tested, the three lock-outcome branches (locked / unsupported / soft-fail) are covered, and the lock is strictly best-effort so it can never wedge a reservation. Rough edges worth a follow-up: unlock is only wired into the reaper's pre-launch-death release, which is Forgejo-only today, so a *failed* GitHub run could strand a lock until a human unlocks (benign, but real). And if Forgejo ever ships a lock endpoint, the clean path is a ward-kdl `lock issue` verb + spec-lock regen rather than the sentinel. Happy to file those if wanted.

coilysiren referenced this issue

2026-07-04 08:37:52 +00:00

ward agent: deliver mid-run comments to the running agent (design; the pessimistic complement to the #494 optimistic lock) #601