Centralize WARDED_WORKFLOW issue comment headers #1195

New issue

Closed

opened 2026-07-13 21:07:07 +00:00 by coilyco-ops · 1 comment

coilyco-ops commented

2026-07-13 21:07:07 +00:00

Member

Refactor all ward-authored issue comment headers under WARDED_WORKFLOW and centralize the header definitions.

Problem:

Ward emits several machine-readable issue comments with scattered headers such as WARD-OUTCOME, WARD-RESERVATION, reservation sentinels, review summaries, workflow markers, and PR-submission comments.
Kai wants all ward-authored issue comments to start with WARDED_WORKFLOW.
The header strings should live in one file so an operator can open one source location and see the complete list of WARDED_WORKFLOW comment variants.

Required refactor:

Inventory every ward-authored issue/PR comment path, including at least:
- reservation hold comments
- reservation release / stale reservation comments
- engineer completion / outcome comments
- PR submitted / PR merge-ready comments
- blocked / failed comments
- review or QA verdict comments if ward emits them
- director reconciliation comments
Create or use one central source file/package for message header constants and parsers. If a central file already exists, move all remaining hardcoded headers there.
Every new ward-authored issue comment must start with a WARDED_WORKFLOW first line.
The first line should be structured enough that readers and parsers can distinguish variants without scanning prose. Suggested shape if no better local convention exists:
- WARDED_WORKFLOW: reservation-held ...
- WARDED_WORKFLOW: reservation-released ...
- WARDED_WORKFLOW: done ...
- WARDED_WORKFLOW: blocked ...
- WARDED_WORKFLOW: failed ...
- WARDED_WORKFLOW: https://forgejo.coilysiren.me/<owner>/<repo>/pulls/<number> for PR submission, per #1194
Keep legacy parsing for existing comments using older WARD-* headers, but stop emitting those older headers.
Update all parsers, director reconciliation, dispatch-health, reap, QA/review, PR merge gating, and docs to use the centralized header definitions.
Add tests that fail if a ward-authored issue comment is emitted with a hardcoded WARD- header outside the centralized file.

Acceptance:

A grep for old emitted headers shows they are legacy parser-only, not new emission paths.
A single file contains the full list of WARDED_WORKFLOW comment headers/variants.
All new ward-authored issue comments begin with WARDED_WORKFLOW.
Existing issue threads with legacy WARD-OUTCOME, WARD-RESERVATION, and ward-agent-reservation comments still parse.
Docs describe WARDED_WORKFLOW as the canonical machine-readable issue comment prefix.

Refactor all ward-authored issue comment headers under `WARDED_WORKFLOW` and centralize the header definitions. Problem: - Ward emits several machine-readable issue comments with scattered headers such as `WARD-OUTCOME`, `WARD-RESERVATION`, reservation sentinels, review summaries, workflow markers, and PR-submission comments. - Kai wants all ward-authored issue comments to start with `WARDED_WORKFLOW`. - The header strings should live in one file so an operator can open one source location and see the complete list of `WARDED_WORKFLOW` comment variants. Required refactor: - Inventory every ward-authored issue/PR comment path, including at least: - reservation hold comments - reservation release / stale reservation comments - engineer completion / outcome comments - PR submitted / PR merge-ready comments - blocked / failed comments - review or QA verdict comments if ward emits them - director reconciliation comments - Create or use one central source file/package for message header constants and parsers. If a central file already exists, move all remaining hardcoded headers there. - Every new ward-authored issue comment must start with a `WARDED_WORKFLOW` first line. - The first line should be structured enough that readers and parsers can distinguish variants without scanning prose. Suggested shape if no better local convention exists: - `WARDED_WORKFLOW: reservation-held ...` - `WARDED_WORKFLOW: reservation-released ...` - `WARDED_WORKFLOW: done ...` - `WARDED_WORKFLOW: blocked ...` - `WARDED_WORKFLOW: failed ...` - `WARDED_WORKFLOW: https://forgejo.coilysiren.me/<owner>/<repo>/pulls/<number>` for PR submission, per #1194 - Keep legacy parsing for existing comments using older `WARD-*` headers, but stop emitting those older headers. - Update all parsers, director reconciliation, dispatch-health, reap, QA/review, PR merge gating, and docs to use the centralized header definitions. - Add tests that fail if a ward-authored issue comment is emitted with a hardcoded `WARD-` header outside the centralized file. Acceptance: - A grep for old emitted headers shows they are legacy parser-only, not new emission paths. - A single file contains the full list of `WARDED_WORKFLOW` comment headers/variants. - All new ward-authored issue comments begin with `WARDED_WORKFLOW`. - Existing issue threads with legacy `WARD-OUTCOME`, `WARD-RESERVATION`, and `ward-agent-reservation` comments still parse. - Docs describe `WARDED_WORKFLOW` as the canonical machine-readable issue comment prefix.

~~coilyco-ops referenced this issue 2026-07-13 21:08:05 +00:00~~

Emit PR URL in WARDED_WORKFLOW for pull-request workflows #1194

coilyco-ops referenced this issue

2026-07-13 21:10:15 +00:00

Make dispatch overrides recover stale prelaunch blockers #1196

coilyco-ops referenced this issue

2026-07-13 21:10:48 +00:00

Make dispatch overrides recover stale prelaunch blockers #1196

coilyco-ops referenced this issue from a pull request that will close it,

2026-07-13 21:37:14 +00:00

Centralize WARDED_WORKFLOW issue comment headers #1199

coilyco-ops commented

2026-07-13 21:40:51 +00:00

Author

Member

WARD-OUTCOME: submitted

details

workflow: pull-request-and-merge; review summary: review gate skipped because the temporary ward default pending brokered QA

The implementation felt straightforward once the header map was centralized. Confidence is high. Surprise: the legacy unknown-status fallback had to stay explicit for older WARD-OUTCOME threads. Follow-up: none.

WARD-OUTCOME: submitted <details><summary>details</summary> workflow: pull-request-and-merge; review summary: review gate skipped because the temporary ward default pending brokered QA The implementation felt straightforward once the header map was centralized. Confidence is high. Surprise: the legacy unknown-status fallback had to stay explicit for older `WARD-OUTCOME` threads. Follow-up: none. </details>

coilyco-ops closed this issue

2026-07-13 21:45:31 +00:00