engineers reserving a issue should lock it

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

labels

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

coilyco-ops commented

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

Owner

🔒 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

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.

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

~~coilyco-ops referenced this issue from coilyco-flight-deck/agentic-os 2026-07-29 06:52:21 +00:00~~

Adapt AOS to Ward's role and KDL removal #778

~~coilyco-ops referenced this issue from coilyco-flight-deck/agentic-os 2026-07-29 07:07:30 +00:00~~

Adapt AOS to Ward's role and KDL removal #778

~~coilyco-ops referenced this issue from coilyco-flight-deck/agentic-os 2026-07-29 07:09:38 +00:00~~

Adapt AOS to Ward's role and KDL removal #778

~~coilyco-ops referenced this issue from coilyco-flight-deck/agent-compose 2026-07-29 12:30:22 +00:00~~

Run contract: complete the Agent Compose v1.x issue suite #115

~~coilyco-ops referenced this issue from coilyco-flight-deck/agentic-os 2026-07-29 12:30:43 +00:00~~

forgejo read/write/admin guardfile chain still carries Phase-1 example* anchors in the deployment bundle #495

~~coilyco-ops referenced this issue from coilyco-flight-deck/agentic-os 2026-07-29 12:31:09 +00:00~~

Replace the Forgejo Actions web log bridge with the v16 logs API #696

~~coilyco-ops referenced this issue from coilyco-flight-deck/infrastructure 2026-07-29 12:31:34 +00:00~~

fix: make the Forgejo runner recycle CronJob executable #587

~~coilyco-ops referenced this issue from coilyco-flight-deck/agentic-os 2026-07-29 12:31:59 +00:00~~

Add PR build validation for the independent dev-base image family #454

~~coilyco-ops referenced this issue from coilyco-flight-deck/umbra 2026-07-29 12:34:42 +00:00~~

Rename the kdlspecs Go package to specgen #244

~~coilyco-ops referenced this issue from coilyco-flight-deck/infrastructure 2026-07-29 12:35:06 +00:00~~

fix: stop cluster-wide DNSConfigForming warnings #591

~~coilyco-ops referenced this issue from coilyco-flight-deck/infrastructure 2026-07-29 12:35:27 +00:00~~

Migrate fleet Actions scripts to one-line run steps #613

~~coilyco-ops referenced this issue from coilyco-flight-deck/agent-compose 2026-07-29 12:37:55 +00:00~~

Run contract: complete the Agent Compose v1.x issue suite #115

~~coilyco-ops referenced this issue from coilyco-flight-deck/agentic-os 2026-07-29 16:06:13 +00:00~~

Mount an operator-selected kubeconfig through the AOS full-image launcher #512

~~coilyco-ops referenced this issue from coilyco-flight-deck/agentic-os 2026-07-29 16:06:33 +00:00~~

Enable actions-run-one-line in the managed default hook catalog #679

~~coilyco-ops referenced this issue 2026-07-29 16:06:59 +00:00~~

Emit skill-use telemetry from reaped agent runs #873

~~coilyco-ops referenced this issue 2026-07-29 16:07:15 +00:00~~

Windows-host go test runs drown in environment failures (ward + cli-guard) #1131

~~coilyco-ops referenced this issue 2026-07-29 16:09:19 +00:00~~

Container staging (and its live-token env-file) lands in the Windows profile root; make it platform-correct, hidden, and per-host overridable #1160

~~coilyco-ops referenced this issue 2026-07-29 16:35:46 +00:00~~

Preclone list should only include the coilysiren/example default value #1177

~~coilyco-ops referenced this issue 2026-07-29 16:36:09 +00:00~~

Recover PR #1457 from stale running Actions state after context canceled #1462

~~coilyco-ops referenced this issue from coilyco-flight-deck/agentic-os 2026-07-29 16:36:35 +00:00~~

guard / ward / aos prod install variants should default to the release branch generated tag (ideally) or the literal tag release when the prior is annoying #484

~~coilyco-ops referenced this issue from coilyco-flight-deck/agentic-os 2026-07-29 16:39:29 +00:00~~

put gaurdfiles inside of a folder #498

~~coilyco-ops referenced this issue from coilyco-flight-deck/agentic-os 2026-07-29 16:39:52 +00:00~~

Publish the canonical personality skill provider for agent-compose #622

~~coilyco-ops referenced this issue from coilyco-flight-deck/agentic-os 2026-07-29 16:50:12 +00:00~~

Add cross-harness agent tool evaluation skill #670

~~coilyco-ops referenced this issue from coilyco-flight-deck/agentic-os 2026-07-29 16:57:29 +00:00~~

Add behavioral evaluation to skill authoring #671

~~coilyco-ops referenced this issue from coilyco-flight-deck/agentic-os 2026-07-29 16:58:11 +00:00~~

Publish agent-terminal in native AOS artifacts #734

~~coilyco-ops referenced this issue 2026-07-29 16:58:50 +00:00~~

The containerassets/settings.container.json file should not exist #1183

~~coilyco-ops referenced this issue 2026-07-29 16:59:32 +00:00~~

remove assets folders / files (presumably pregen'ed from kdl configs) #1184

~~coilyco-ops referenced this issue 2026-07-29 17:01:30 +00:00~~

delete all 3 ward-kdl-{ read / write / admin } folders #1185

~~coilyco-ops referenced this issue from coilyco-flight-deck/agentic-os 2026-07-31 07:24:37 +00:00~~

Give the pre-commit suite an independent release train #816

Rows
Columns

engineers reserving a issue should lock it #494