coilyco-flight-deck/ward

Archived

Watch

Prove GitHub-backed warded runs satisfy the control-plane contract #1320

Closed

opened 2026-07-15 05:14:23 +00:00 by coilyco-ops · 4 comments

coilyco-ops commented

2026-07-15 05:14:23 +00:00

Owner

GitHub support exists, but this milestone needs a parity ratchet: GitHub-backed warded runs should satisfy the same control-plane expectations as Forgejo-backed runs.

This is coverage and contract work, not a new GitHub feature epic.

Acceptance:

Add executable coverage, tests, or a documented verification path for GitHub refs across the control-plane behaviors that matter for warded coherence.
Cover issue read/comment, PR creation, PR status or CI read, outcome comments, human comment blocking, open-PR backpressure, and merge/close behavior where supported.
Make intentional GitHub gaps explicit rather than silently Forgejo-only.
Tie the coverage to the same abstractions the Forgejo path uses, so future broker/director changes cannot accidentally skip GitHub.
Keep any live-token or public-surface requirement out of unit tests. Use fakes or documented acceptance evidence where live GitHub is required.

Context: this was identified while designing the warded control plane coherence milestone from open issue titles. The old GitHub feature work is done enough to close the launch milestone, but the new release needs confidence that the control plane works on GitHub too.

Decision for headless carry

This is a parity ratchet, not a live GitHub operations task. A headless engineer should implement fakes, fixtures, or a documented dry-run harness that exercises the GitHub code path through the same control-plane abstractions as Forgejo. Live GitHub evidence is optional follow-up, not required to land the issue.

Required shape:

Prefer table-driven tests that run the same control-plane cases against Forgejo and GitHub adapters.
Use fake clients or recorded fixtures for issue read/comment, PR creation, PR status, outcome comments, human-comment blocking, open-PR backpressure, and merge/close where supported.
If a behavior intentionally differs on GitHub, document the gap in the test name or docs.
Do not require a live token in unit tests.

GitHub support exists, but this milestone needs a parity ratchet: GitHub-backed warded runs should satisfy the same control-plane expectations as Forgejo-backed runs. This is coverage and contract work, not a new GitHub feature epic. Acceptance: * Add executable coverage, tests, or a documented verification path for GitHub refs across the control-plane behaviors that matter for warded coherence. * Cover issue read/comment, PR creation, PR status or CI read, outcome comments, human comment blocking, open-PR backpressure, and merge/close behavior where supported. * Make intentional GitHub gaps explicit rather than silently Forgejo-only. * Tie the coverage to the same abstractions the Forgejo path uses, so future broker/director changes cannot accidentally skip GitHub. * Keep any live-token or public-surface requirement out of unit tests. Use fakes or documented acceptance evidence where live GitHub is required. Context: this was identified while designing the `warded control plane coherence` milestone from open issue titles. The old GitHub feature work is done enough to close the launch milestone, but the new release needs confidence that the control plane works on GitHub too. --- ## Decision for headless carry This is a parity ratchet, not a live GitHub operations task. A headless engineer should implement fakes, fixtures, or a documented dry-run harness that exercises the GitHub code path through the same control-plane abstractions as Forgejo. Live GitHub evidence is optional follow-up, not required to land the issue. Required shape: * Prefer table-driven tests that run the same control-plane cases against Forgejo and GitHub adapters. * Use fake clients or recorded fixtures for issue read/comment, PR creation, PR status, outcome comments, human-comment blocking, open-PR backpressure, and merge/close where supported. * If a behavior intentionally differs on GitHub, document the gap in the test name or docs. * Do not require a live token in unit tests.

coilyco-ops added this to the warded control plane coherence milestone

2026-07-15 05:14:23 +00:00

coilyco-ops added the

labels

2026-07-15 05:14:23 +00:00

coilyco-ops commented

2026-07-15 07:16:42 +00:00

Author

Owner

WARD-TRIAGE: warded control plane coherence milestone

This issue is part of the warded control plane coherence sprint. The release thesis is to make warded feel like one dependable control plane for agent work: higher safe parallelism, coherent config defaults, reliable broker/container behavior, human-feedback gates, and enough structured evidence for the next actor after a paused or failed run.

For this sprint, headless means an engineer should be able to carry the issue from current issue context to a merged change without new human decisions. If the issue discovers a missing decision, split or demote the unclear part instead of guessing.

WARD-TRIAGE: warded control plane coherence milestone This issue is part of the `warded control plane coherence` sprint. The release thesis is to make `warded` feel like one dependable control plane for agent work: higher safe parallelism, coherent config defaults, reliable broker/container behavior, human-feedback gates, and enough structured evidence for the next actor after a paused or failed run. For this sprint, `headless` means an engineer should be able to carry the issue from current issue context to a merged change without new human decisions. If the issue discovers a missing decision, split or demote the unclear part instead of guessing.

coilyco-ops commented

2026-07-15 07:16:50 +00:00

Author

Owner

WARD-TRIAGE: coherence-core label

This issue is part of the coherence-core review set for the warded control plane coherence sprint. Treat it as release-spine work: it should directly improve the safety, capacity, configuration coherence, observability, or recovery loop that makes director burndown trustworthy.

Core does not mean broader scope. Keep the implementation narrow, verify current main before reusing prior failed PRs, and split any design fork or lower-confidence follow-up out of the core path.

WARD-TRIAGE: coherence-core label This issue is part of the `coherence-core` review set for the `warded control plane coherence` sprint. Treat it as release-spine work: it should directly improve the safety, capacity, configuration coherence, observability, or recovery loop that makes director burndown trustworthy. Core does not mean broader scope. Keep the implementation narrow, verify current `main` before reusing prior failed PRs, and split any design fork or lower-confidence follow-up out of the core path.

coilyco-ops commented

2026-07-15 07:54:21 +00:00

Author

Owner

WARDED_WORKFLOW: reservation-held

reservation details

Holder: launch intent for container engineer-codex-ward-1320 on host kais-macbook-pro-2.local.

Accepted by ward agent --harness codex (reserved 2026-07-15T07:54:20Z). Concurrent ward agent runs are blocked until this intent becomes visible or the intent is released. The stale-intent fallback is still TTL-bounded (3h TTL). --override-reservation 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/ward#1320 · branch issue-1320 · harness codex · workflow pull-request-and-merge
Run: engineer-codex-ward-1320 · ward v0.710.0 · dispatched 2026-07-15T07:54:15Z
Comment thread: 2 included in the pre-flight read, 0 stripped (ward's own automated comments).
- included: @coilyco-ops (2026-07-15T07:16:42Z), @coilyco-ops (2026-07-15T07:16:50Z)

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

— Codex, via ward agent

WARDED_WORKFLOW: reservation-held <details><summary>reservation details</summary> Holder: launch intent for container `engineer-codex-ward-1320` on host `kais-macbook-pro-2.local`. Accepted by `ward agent --harness codex` (reserved 2026-07-15T07:54:20Z). Concurrent `ward agent` runs are blocked until this intent becomes visible or the intent is released. The stale-intent fallback is still TTL-bounded (3h TTL). `--override-reservation` 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/ward#1320` · branch `issue-1320` · harness `codex` · workflow `pull-request-and-merge` - **Run:** `engineer-codex-ward-1320` · ward `v0.710.0` · dispatched `2026-07-15T07:54:15Z` - **Comment thread:** 2 included in the pre-flight read, 0 stripped (ward's own automated comments). - included: @coilyco-ops (2026-07-15T07:16:42Z), @coilyco-ops (2026-07-15T07:16:50Z) Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.710.0). </details> </details>  — Codex, via `ward agent`

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

2026-07-15 08:05:28 +00:00

Add GitHub control-plane contract coverage #1349

coilyco-ops commented

2026-07-15 08:07:56 +00:00

Author

Owner

WARDED_WORKFLOW: #1349

details

workflow: pull-request-and-merge; review summary: review gate intentionally skipped (temporary ward default pending brokered QA)

felt: narrow, mostly test-and-doc plumbing
confidence: high
surprise: GitHub PR context rides the issue thread, but PR workflow is still Forgejo-only
follow-up: keep the gap tests aligned if GitHub grows PR workflow support

WARDED_WORKFLOW: https://forgejo.coilysiren.me/coilyco-flight-deck/ward/pulls/1349 <details><summary>details</summary> workflow: pull-request-and-merge; review summary: review gate intentionally skipped (temporary ward default pending brokered QA) felt: narrow, mostly test-and-doc plumbing confidence: high surprise: GitHub PR context rides the issue thread, but PR workflow is still Forgejo-only follow-up: keep the gap tests aligned if GitHub grows PR workflow support </details>

coilyco-ops closed this issue

2026-07-15 08:09:41 +00:00

Commenting is not possible because the repository is archived.

No milestone

No project

No assignees

1 participant

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

coilyco-flight-deck/ward#1320

No description provided.

Rows
Columns