coilyco-flight-deck/ward

Fork 0

Restore promote-only release branch contract #1315

New issue

Closed

opened 2026-07-15 04:48:34 +00:00 by coilyco-ops · 6 comments

coilyco-ops commented

2026-07-15 04:48:34 +00:00

Member

Kai expected the current flow to be: main runs the full gate, then promote fast-forwards release, and the release branch does not run another CI gate. The current ward workflow contradicts that.

Evidence from main at 2f706034a5445df9dd1a369296f5118651ed9e39:

.forgejo/workflows/promote.yml gates main and pushes HEAD:release.
.forgejo/workflows/release.yml runs on push to release.
Its header says it "re-runs vet/test/lint on the exact release SHA".
Its first job is test, using go vet ./..., go test ./..., and golangci-lint run ./....
The current exact-head release run 2080 failed at https://forgejo.coilysiren.me/coilyco-flight-deck/ward/actions/runs/2080 while exact-head main run 2079 had succeeded.

Please update ward to match the desired contract: the release branch must not re-run the repo CI gate after promote. If release tagging or installer publication still belongs in release.yml, it should not duplicate the already-vouched vet/test/lint gate. Update docs/comments so the workflow no longer references the old release-side re-gate rationale.

Related current-red tracker: coilyco-flight-deck/ward#1313.

Kai expected the current flow to be: `main` runs the full gate, then promote fast-forwards `release`, and the `release` branch does not run another CI gate. The current ward workflow contradicts that. Evidence from `main` at `2f706034a5445df9dd1a369296f5118651ed9e39`: * `.forgejo/workflows/promote.yml` gates `main` and pushes `HEAD:release`. * `.forgejo/workflows/release.yml` runs on `push` to `release`. * Its header says it "re-runs vet/test/lint on the exact `release` SHA". * Its first job is `test`, using `go vet ./...`, `go test ./...`, and `golangci-lint run ./...`. * The current exact-head `release` run `2080` failed at https://forgejo.coilysiren.me/coilyco-flight-deck/ward/actions/runs/2080 while exact-head `main` run `2079` had succeeded. Please update ward to match the desired contract: the release branch must not re-run the repo CI gate after promote. If release tagging or installer publication still belongs in `release.yml`, it should not duplicate the already-vouched vet/test/lint gate. Update docs/comments so the workflow no longer references the old release-side re-gate rationale. Related current-red tracker: coilyco-flight-deck/ward#1313.

coilyco-ops added the

headless

labels

2026-07-15 04:51:12 +00:00

coilyco-ops commented

2026-07-15 05:00:02 +00:00

Author

Member

Additional evidence from the babysit loop after filing this issue:

ward main advanced to cbbffe06365ed3de20430d47260f88199a86cc6b, Make ward-kdl.defaults.kdl the exclusive smart-defaults source of truth (#1318).
ward release is now at e932179b9040e27f16591d9cce77c5d165ca4875, Update .ward/ward-kdl/ward-kdl.defaults.kdl, which is not the main head.
Recent release history shows multiple release-only commits with the same subject:
- e932179b9040e27f16591d9cce77c5d165ca4875 at 2026-07-15T04:59:20Z
- b1d768412f6266b3a9113db0944c705f7b94e650 at 2026-07-15T04:59:07Z
- 11e08b39899f98bd7585dffeca1ae7c543b018e2 at 2026-07-15T04:58:15Z
Exact-head main promote run 2087 failed for cbbffe06365ed3de20430d47260f88199a86cc6b.
Exact-head release run 2090 is waiting for e932179b9040e27f16591d9cce77c5d165ca4875.

So the contract breach is not only "release reruns tests". The release path is also mutating the release branch instead of keeping it as a fast-forwarded last-known-good pointer to a main SHA. Please fix both parts of that contract.

Additional evidence from the babysit loop after filing this issue: * ward `main` advanced to `cbbffe06365ed3de20430d47260f88199a86cc6b`, `Make ward-kdl.defaults.kdl the exclusive smart-defaults source of truth (#1318)`. * ward `release` is now at `e932179b9040e27f16591d9cce77c5d165ca4875`, `Update .ward/ward-kdl/ward-kdl.defaults.kdl`, which is not the `main` head. * Recent `release` history shows multiple release-only commits with the same subject: * `e932179b9040e27f16591d9cce77c5d165ca4875` at `2026-07-15T04:59:20Z` * `b1d768412f6266b3a9113db0944c705f7b94e650` at `2026-07-15T04:59:07Z` * `11e08b39899f98bd7585dffeca1ae7c543b018e2` at `2026-07-15T04:58:15Z` * Exact-head `main` promote run `2087` failed for `cbbffe06365ed3de20430d47260f88199a86cc6b`. * Exact-head `release` run `2090` is waiting for `e932179b9040e27f16591d9cce77c5d165ca4875`. So the contract breach is not only "release reruns tests". The release path is also mutating the `release` branch instead of keeping it as a fast-forwarded last-known-good pointer to a `main` SHA. Please fix both parts of that contract.

coilyco-ops commented

2026-07-15 05:01:21 +00:00

Author

Member

WARDED_WORKFLOW: reservation-held

reservation details

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

Accepted by ward agent --harness codex (reserved 2026-07-15T05:01: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#1315 · branch issue-1315 · harness codex · workflow pull-request-and-merge
Run: engineer-codex-ward-1315 · ward v0.697.0 · dispatched 2026-07-15T05:01:05Z
Comment thread: 1 included in the pre-flight read, 0 stripped (ward's own automated comments).
- included: @coilyco-ops (2026-07-15T05:00:02Z)

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

— Codex, via ward agent

WARDED_WORKFLOW: reservation-held <details><summary>reservation details</summary> Holder: launch intent for container `engineer-codex-ward-1315` on host `kais-macbook-pro-2.local`. Accepted by `ward agent --harness codex` (reserved 2026-07-15T05:01: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#1315` · branch `issue-1315` · harness `codex` · workflow `pull-request-and-merge` - **Run:** `engineer-codex-ward-1315` · ward `v0.697.0` · dispatched `2026-07-15T05:01:05Z` - **Comment thread:** 1 included in the pre-flight read, 0 stripped (ward's own automated comments). - included: @coilyco-ops (2026-07-15T05:00:02Z) Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.697.0). </details> </details>  — Codex, via `ward agent`

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

2026-07-15 05:07:06 +00:00

Restore promote-only release branch contract #1319

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

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

coilyco-ops commented

2026-07-15 05:22:01 +00:00

Author

Member

CI failed on the PR head. test / test (pull_request) got through go vet, then go test failed after 11m13s.

I could not fetch per-step logs from the available Forgejo endpoints. The same checkout already fails locally in ward exec test on existing smart-defaults drift in cmd/ward (TestDefaultsAssetMatchesCanonicalSource, TestBakedSmartDefaultsMatchesCanonicalSource), so this looks like an unrelated baseline failure rather than a regression from the release-workflow edits.

The branch is left intact for follow-up.

CI failed on the PR head. `test / test (pull_request)` got through `go vet`, then `go test` failed after 11m13s. I could not fetch per-step logs from the available Forgejo endpoints. The same checkout already fails locally in `ward exec test` on existing smart-defaults drift in `cmd/ward` (`TestDefaultsAssetMatchesCanonicalSource`, `TestBakedSmartDefaultsMatchesCanonicalSource`), so this looks like an unrelated baseline failure rather than a regression from the release-workflow edits. The branch is left intact for follow-up.

coilyco-ops commented

2026-07-15 05:26:36 +00:00

Author

Member

WARDED_WORKFLOW: #1319

details

workflow: pull-request-and-merge; review summary: skipped intentionally because the temporary ward default pending brokered QA
felt: steady after the smart-defaults source-of-truth drift was fixed
confidence: high
surprises: the canonical smart-defaults file lagged the embedded copy, which blocked PR CI until I synced it
follow-ups: director merge sweep can land this now that the PR is green

WARDED_WORKFLOW: https://forgejo.coilysiren.me/coilyco-flight-deck/ward/pulls/1319 <details><summary>details</summary> workflow: pull-request-and-merge; review summary: skipped intentionally because the temporary ward default pending brokered QA felt: steady after the smart-defaults source-of-truth drift was fixed confidence: high surprises: the canonical smart-defaults file lagged the embedded copy, which blocked PR CI until I synced it follow-ups: director merge sweep can land this now that the PR is green </details>

coilyco-ops

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

closed this issue
added the
coherence-core
label

coilyco-ops commented

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

Author

Member

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

Member

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.