Expose Forgejo PR read operations in ward-kdl #392

New issue

Closed

opened 2026-07-09 21:21:38 +00:00 by coilyco-ops · 2 comments

coilyco-ops commented

2026-07-09 21:21:38 +00:00

Member

Goal

Reverse the current Forgejo PR read denial in the aos ward-kdl spec so agents can inspect pull requests through ward ops forgejo again, matching the ward core changes from this week.

Current state

/.ward/ward-kdl.forgejo.guardfile.kdl denies:

never view pr {
    message "pull requests are not exposed through ward; read them in the web UI"
}
never list pr {
    message "pull requests are not exposed through ward; read them in the web UI"
}

The generated reference and AGENTS.md repeat that ward ops forgejo pr list is denied by policy. That is now stale.

Required change

Replace the never view pr / never list pr entries with allowed read operations, using the current ward-kdl/cli-guard operation resolution or explicit op pins as needed.
Keep write/merge policy unchanged unless ward core now requires a different split.
Regenerate docs/ward-ops-forgejo-reference.md.
Update AGENTS.md so agents no longer say PR list is denied and can use the allowed read surface.
Run the repo validation expected for aos.

Acceptance

ward ops forgejo pr list ... is documented as an allowed read operation.
ward ops forgejo pr view ... is documented as an allowed read operation.
Denied operations no longer include PR read/list.
Existing release/agent workflow docs still make clear that merge authority is separate from PR read access.

Context: a director session on 2026-07-09 confirmed the installed guardfile and generated docs still deny PR reads, but Kai said this should be reversed per ward core changes this week.

## Goal Reverse the current Forgejo PR read denial in the aos ward-kdl spec so agents can inspect pull requests through `ward ops forgejo` again, matching the ward core changes from this week. ## Current state `/.ward/ward-kdl.forgejo.guardfile.kdl` denies: ```kdl never view pr { message "pull requests are not exposed through ward; read them in the web UI" } never list pr { message "pull requests are not exposed through ward; read them in the web UI" } ``` The generated reference and AGENTS.md repeat that `ward ops forgejo pr list` is denied by policy. That is now stale. ## Required change * Replace the `never view pr` / `never list pr` entries with allowed read operations, using the current ward-kdl/cli-guard operation resolution or explicit op pins as needed. * Keep write/merge policy unchanged unless ward core now requires a different split. * Regenerate `docs/ward-ops-forgejo-reference.md`. * Update `AGENTS.md` so agents no longer say PR list is denied and can use the allowed read surface. * Run the repo validation expected for aos. ## Acceptance * `ward ops forgejo pr list ...` is documented as an allowed read operation. * `ward ops forgejo pr view ...` is documented as an allowed read operation. * Denied operations no longer include PR read/list. * Existing release/agent workflow docs still make clear that merge authority is separate from PR read access. Context: a director session on 2026-07-09 confirmed the installed guardfile and generated docs still deny PR reads, but Kai said this should be reversed per ward core changes this week.

coilyco-ops commented

2026-07-09 21:21:46 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

Holder: container engineer-codex-agentic-os-392 on host kais-macbook-pro-2.local.

Reserved by ward agent --harness codex (reserved 2026-07-09T21:21:44Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (1h TTL). --force overrides.

Do not comment on or edit this issue to steer the run while it is reserved. The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a new issue, dispatched fresh. That is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494).

run seed context — what this run is carrying (ward#609)

Resolved: coilyco-flight-deck/agentic-os#392 · branch issue-392 · harness codex · workflow direct-to-main
Run: engineer-codex-agentic-os-392 · ward v0.504.0 · dispatched 2026-07-09T21:21:44Z
Comment thread: 0 included in the pre-flight read, 0 stripped (ward's own automated comments).

Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.504.0).

— Codex, via ward agent

WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-agentic-os-392` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-09T21:21:44Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (1h TTL). `--force` overrides. **Do not comment on or edit this issue to steer the run while it is reserved.** The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a **new issue, dispatched fresh**. That is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494). <details><summary>run seed context — what this run is carrying (ward#609)</summary> - **Resolved:** `coilyco-flight-deck/agentic-os#392` · branch `issue-392` · harness `codex` · workflow `direct-to-main` - **Run:** `engineer-codex-agentic-os-392` · ward `v0.504.0` · dispatched `2026-07-09T21:21:44Z` - **Comment thread:** 0 included in the pre-flight read, 0 stripped (ward's own automated comments). Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.504.0). </details> </details>  — Codex, via `ward agent`

coilyco-ops referenced this issue from a commit

2026-07-09 21:30:26 +00:00

feat: expose forgejo PR reads in ward-kdl

coilyco-ops closed this issue

2026-07-09 21:30:26 +00:00

coilyco-ops commented

2026-07-09 21:30:49 +00:00

Author

Member

WARD-OUTCOME: done ✅

details

workflow: direct-to-main; review summary: skipped (review gate skipped by ~/.ward/config.yaml default) retrospective: the change was mostly doc sync, but the stale live generator forced a manual reference patch. confidence: high surprises: origin/main moved during the run. follow-ups: none.

WARD-OUTCOME: done ✅ <details><summary>details</summary> workflow: direct-to-main; review summary: skipped (review gate skipped by ~/.ward/config.yaml default) retrospective: the change was mostly doc sync, but the stale live generator forced a manual reference patch. confidence: high surprises: origin/main moved during the run. follow-ups: none. </details>

coilyco-ops referenced this issue

2026-08-22 20:54:50 +00:00

Lane: headless engineer burn-down in agentic-os, 28 issues at P1 and P2, ordered so the toolchain unblocks itself first #1177

coilyco-ops referenced this issue

2026-08-23 00:37:59 +00:00

Require a priority and an autonomy label on AOSguard's forgejo issue create #1105