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

New issue

Closed

opened 2026-07-13 21:03:37 +00:00 by coilyco-ops · 2 comments

coilyco-ops commented

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

Member

Change PR workflow comments to start with WARDED_WORKFLOW and carry the fully qualified pull request URL.

Problem:

For pull-request workflows, ward currently posts outcome comments like WARD-OUTCOME: submitted.
Kai wants ward-authored issue comments to start with the workflow header, spelled with WARDED:
- WARDED_WORKFLOW: https://forgejo.coilysiren.me/<owner>/<repo>/pulls/<number>
The current status word forces humans and directors to infer or rediscover the submitted PR.

Required behavior:

When an engineer creates or submits a pull request, the first machine-readable line of the issue comment must be exactly WARDED_WORKFLOW: <fully-qualified pull request link>.
The link must be the canonical forge URL, not a relative path, branch name, issue ref, or API URL.
Apply this to pull-request and pull-request-and-merge workflows.
Direct-to-main / no-PR workflows can keep their existing terminal outcome vocabulary only until the broader WARDED_WORKFLOW header refactor lands. Do not introduce new WARD-OUTCOME: submitted emissions.

Parser and compatibility work:

Audit every ward parser that reads WARD-OUTCOME or submitted workflow comments.
Update director/QA/merge reconciliation so a WARDED_WORKFLOW URL outcome is treated as the PR-submitted state and the PR number is extracted from the URL when needed.
Keep support for old WARD-OUTCOME: submitted comments long enough to read existing issue threads, but stop emitting it.
Review downstream references in infrastructure, especially scripts/ward_eval.py and scripts/ward_director_evaluation_test.py, which currently match WARD-OUTCOME: done / status words.
If downstream repo changes are needed, file or implement the paired infrastructure update.

Acceptance:

New PR-workflow runs post a comment whose first line is WARDED_WORKFLOW: https://forgejo.coilysiren.me/.../pulls/N.
Director status, PR merge gating, dispatch-health, and any review/QA paths can consume that URL outcome.
Tests cover WARDED_WORKFLOW URL emission, legacy WARD-OUTCOME: submitted parsing, malformed URL rejection, and URL-to-PR-number extraction.
Docs no longer describe submitted as the PR-submitted outcome marker.

Change PR workflow comments to start with `WARDED_WORKFLOW` and carry the fully qualified pull request URL. Problem: - For pull-request workflows, ward currently posts outcome comments like `WARD-OUTCOME: submitted`. - Kai wants ward-authored issue comments to start with the workflow header, spelled with `WARDED`: - `WARDED_WORKFLOW: https://forgejo.coilysiren.me/<owner>/<repo>/pulls/<number>` - The current status word forces humans and directors to infer or rediscover the submitted PR. Required behavior: - When an engineer creates or submits a pull request, the first machine-readable line of the issue comment must be exactly `WARDED_WORKFLOW: <fully-qualified pull request link>`. - The link must be the canonical forge URL, not a relative path, branch name, issue ref, or API URL. - Apply this to `pull-request` and `pull-request-and-merge` workflows. - Direct-to-main / no-PR workflows can keep their existing terminal outcome vocabulary only until the broader `WARDED_WORKFLOW` header refactor lands. Do not introduce new `WARD-OUTCOME: submitted` emissions. Parser and compatibility work: - Audit every ward parser that reads `WARD-OUTCOME` or submitted workflow comments. - Update director/QA/merge reconciliation so a `WARDED_WORKFLOW` URL outcome is treated as the PR-submitted state and the PR number is extracted from the URL when needed. - Keep support for old `WARD-OUTCOME: submitted` comments long enough to read existing issue threads, but stop emitting it. - Review downstream references in infrastructure, especially `scripts/ward_eval.py` and `scripts/ward_director_evaluation_test.py`, which currently match `WARD-OUTCOME: done` / status words. - If downstream repo changes are needed, file or implement the paired infrastructure update. Acceptance: - New PR-workflow runs post a comment whose first line is `WARDED_WORKFLOW: https://forgejo.coilysiren.me/.../pulls/N`. - Director status, PR merge gating, dispatch-health, and any review/QA paths can consume that URL outcome. - Tests cover `WARDED_WORKFLOW` URL emission, legacy `WARD-OUTCOME: submitted` parsing, malformed URL rejection, and URL-to-PR-number extraction. - Docs no longer describe `submitted` as the PR-submitted outcome marker.

coilyco-ops changed title from ~~Emit PR URL in WARD-OUTCOME for pull-request workflows~~ to Emit PR URL in WARDED_WORKFLOW for pull-request workflows

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

coilyco-ops referenced this issue

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

Centralize WARDED_WORKFLOW issue comment headers #1195

coilyco-ops referenced this issue

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

Make dispatch overrides recover stale prelaunch blockers #1196

coilyco-ops commented

2026-07-14 00:25:25 +00:00

Author

Member

WARDED_WORKFLOW review-note

PR 1220 merged and replaced the plain submitted marker for normal pull-request runs, but a residual contract gap remains for review-gated pull-request-and-merge: the first visible line still uses WARDED_WORKFLOW: merge-ready instead of the canonical PR URL. Follow-up: #1221

WARDED_WORKFLOW review-note PR 1220 merged and replaced the plain submitted marker for normal pull-request runs, but a residual contract gap remains for review-gated `pull-request-and-merge`: the first visible line still uses `WARDED_WORKFLOW: merge-ready` instead of the canonical PR URL. Follow-up: https://forgejo.coilysiren.me/coilyco-flight-deck/ward/issues/1221

coilyco-ops commented

2026-07-14 00:26:11 +00:00

Author

Member

WARDED_WORKFLOW: #1220

details

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

felt: straight-through. The PR landed cleanly and the compatibility paths held.
confidence: high
surprises: none beyond the legacy submitted compatibility that had to stay readable.
follow-ups: none.

WARDED_WORKFLOW: https://forgejo.coilysiren.me/coilyco-flight-deck/ward/pulls/1220 <details><summary>details</summary> workflow: pull-request-and-merge; review summary: the in-container review gate was intentionally skipped because the temporary ward default pending brokered QA felt: straight-through. The PR landed cleanly and the compatibility paths held. confidence: high surprises: none beyond the legacy submitted compatibility that had to stay readable. follow-ups: none. </details>

coilyco-ops closed this issue

2026-07-14 00:26:11 +00:00