The ward engineer supeevisor should restart engineers when new comments come in #1092

New issue

Open

opened 2026-07-10 22:18:26 +00:00 by coilysiren · 0 comments

coilysiren commented

2026-07-10 22:18:26 +00:00

Owner

The problem

If a human or a director makes a comment on a issue or PR mid run then it's often critical context

A human closing a PR or issue, same

warded engineers should (already?) run under ward supervision - although at present I think that supervision only managed preflight and reap

This is a new operating mode where the supervisor needs to learn how to interrupt the engineer mid run, which means it can't allow the docker process to fully foreground (if that's what it does at present)

The interrupts need to truly pause the container, docker has an API for that. I think pausing the container might drop memory but keep disk intact?

When the PR or issue is closed, the engineer should just stop. The supervisor should communicate that that has been done before it exits. Post both on the issue and the PR if it exists

If a comment rolls in, then the supervisor needs to make sure the engineer knows about it. If a harness supports mid run prompts via stdin, then use that. If it doesn't - you'll need to restart the engineer from scratch (without killing the container, there's a high chance that the primary use case here will be engineers that have run long doing something valuable that just needs a small adjustment). If pausing a container drops memory - we should just persist the volume. Instead of the full container.

Proposed change

Giving the engineers a volume that can be remounted after a full stop - then appending their startup message - is probably the option that's durable across container container techs and agent types

Alternatives considered

No response

Before filing

I searched existing issues and this is not a duplicate.
This stays within ward's scope (the dev-verb gate / agent driver), not a personal-infra or downstream-repo verb.

### The problem If a human or a director makes a comment on a issue or PR mid run then it's often critical context A human closing a PR or issue, same warded engineers should (already?) run under ward supervision - although at present I think that supervision only managed preflight and reap This is a new operating mode where the supervisor needs to learn how to interrupt the engineer mid run, which means it can't allow the docker process to fully foreground (if that's what it does at present) The interrupts need to truly pause the container, docker has an API for that. I think pausing the container might drop memory but keep disk intact? When the PR or issue is closed, the engineer should just stop. The supervisor should communicate that that has been done before it exits. Post both on the issue and the PR if it exists If a comment rolls in, then the supervisor needs to make sure the engineer knows about it. If a harness supports mid run prompts via stdin, then use that. If it doesn't - you'll need to restart the engineer from scratch (without killing the container, there's a high chance that the primary use case here will be engineers that have run long doing something valuable that just needs a small adjustment). If pausing a container drops memory - we should just persist the volume. Instead of the full container. ### Proposed change Giving the engineers a volume that can be remounted after a full stop - then appending their startup message - is probably the option that's durable across container container techs and agent types ### Alternatives considered _No response_ ### Before filing - [x] I searched existing issues and this is not a duplicate. - [x] This stays within ward's scope (the dev-verb gate / agent driver), not a personal-infra or downstream-repo verb.