1st class warded goal invokes should automatically create and manage an issue thread #1078

New issue

Open

opened 2026-07-10 20:22:25 +00:00 by coilysiren · 1 comment

coilysiren commented

2026-07-10 20:22:25 +00:00

Owner

The problem

Similar to how the (partially deprecated) freeform input modes post a router issue and then an issue on the destination

Proposed change

Post an issue on a KDL configured centralized location, then post a message for every brokered action, with the read more pattern that includes the logs for that brokered invoke. It should use the WARD-{WHATEVER} hypercurt preface into the read more, so mirror the syntax the comments have.

since this is giving directors an issue to anchor to... we can start naming the directors based on the issue number, same as we do with engineers. We just probably shouldn't give directors the full repo path in their name, just director plus this issue number. The idea is that the repo path is a global default, also it creates some visual difference

a divergence from the issue comments that exist right now - the director issue comments should include all the logs for the brokered action (short of the logs about posting the comment on the issue itself... that would be recursive obvs) - the issue comments only post the metadata

Alternatives considered

There's another issue about using host native tools to provide push notes about director progress. This composes with that, but in a way it supercedes that because I suspect refreshing an issue thread is more ergonomic than catching push notes.

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 Similar to how the (partially deprecated) freeform input modes post a router issue and then an issue on the destination ### Proposed change Post an issue on a KDL configured centralized location, then post a message for every brokered action, with the read more pattern that includes the logs for that brokered invoke. It should use the WARD-{WHATEVER} hypercurt preface into the read more, so mirror the syntax the comments have. since this is giving directors an issue to anchor to... we can start naming the directors based on the issue number, same as we do with engineers. We just probably shouldn't give directors the full repo path in their name, just director plus this issue number. The idea is that the repo path is a global default, also it creates some visual difference a divergence from the issue comments that exist right now - the director issue comments should include *all* the logs for the brokered action (short of the logs about posting the comment on the issue itself... that would be recursive obvs) - the issue comments only post the metadata ### Alternatives considered There's another issue about using host native tools to provide push notes about director progress. This composes with that, but in a way it supercedes that because I suspect refreshing an issue thread is more ergonomic than catching push notes. ### 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.

coilysiren commented

2026-07-10 20:23:54 +00:00

Author

Owner

Oh, and this all relies on an operating mode that doesn't yet exist - a mode where ward director starts up by invoking the harness's true first class goal API. For harnesses that supper that API, this replaces the manual triage mechanism.

coilysiren referenced this issue

2026-07-10 20:42:04 +00:00

Brokered comments should contain *all* the logs emitted for the brokered action that created the comment #1079