Prove issue-to-verified-deployment in a disposable fixture #1629

Closed
opened 2026-07-31 08:21:36 +00:00 by coilyco-ops · 1 comment
Member

Parent: #1625

Goal

Prove the complete Ward delivery path through verified deployment in one bounded, repeatable fixture:

issue → engineer → QA → director merge → Ops → verified deploy commit

The fixture consumes the generic composed-agent broker from #1626, the Ops candidate/result contract from #1627, and the verified deploy-state workflow from #1628.

Fixture shape

Use disposable components only:

  • an application repository
  • a deployment repository
  • a target-environment simulator
  • deterministic deployment and verification operations supplied by the fixture repository

This is a validation fixture, not a public demo application and not a new product surface.

Acceptance criteria

  • The happy path lands an application change, records QA approval for the exact head, performs the director-gated merge, dispatches Ops, deploys and verifies the immutable revision, then records that revision in exactly one deploy repository commit.
  • Candidate rejection or an external block creates no deploy commit.
  • An injected partial deployment failure restores and verifies the previous committed state.
  • Concurrent attempts for the same environment resolve deterministically.
  • Ward artifacts correlate the originating issue, application revision, role handoffs, verification result, deploy commit, and final outcome.
  • The fixture contains no Kubernetes, GitHub, Trello, or other provider-specific implementation logic.
  • The fixture runs repeatedly from a clean state with bounded time and deterministic assertions.

Execution mode

AFK. Use disposable fixtures only. Do not deploy to or mutate live systems.

Blocked by

Parent: #1625 ## Goal Prove the complete Ward delivery path through verified deployment in one bounded, repeatable fixture: issue → engineer → QA → director merge → Ops → verified deploy commit The fixture consumes the generic composed-agent broker from #1626, the Ops candidate/result contract from #1627, and the verified deploy-state workflow from #1628. ## Fixture shape Use disposable components only: * an application repository * a deployment repository * a target-environment simulator * deterministic deployment and verification operations supplied by the fixture repository This is a validation fixture, not a public demo application and not a new product surface. ## Acceptance criteria * The happy path lands an application change, records QA approval for the exact head, performs the director-gated merge, dispatches Ops, deploys and verifies the immutable revision, then records that revision in exactly one deploy repository commit. * Candidate rejection or an external block creates no deploy commit. * An injected partial deployment failure restores and verifies the previous committed state. * Concurrent attempts for the same environment resolve deterministically. * Ward artifacts correlate the originating issue, application revision, role handoffs, verification result, deploy commit, and final outcome. * The fixture contains no Kubernetes, GitHub, Trello, or other provider-specific implementation logic. * The fixture runs repeatedly from a clean state with bounded time and deterministic assertions. ## Execution mode AFK. Use disposable fixtures only. Do not deploy to or mutate live systems. ## Blocked by * #1626 * #1627 * #1628
Author
Member

Closed by Kai as intentionally out of scope.

The proposed cross-lifecycle fixture is disproportionate to the value it adds. #1627 owns typed candidate and result validation, and #1628 owns transaction, recovery, concurrency, push, and rollback tests. Those focused contracts are the required proof.

Do not replace this issue with another public demo, fixture mode, harness adapter, script, or tracked toy application. Reopen only if a concrete production boundary remains untested after #1627 and #1628 land, and file that boundary as the smallest focused test slice.

Closed by Kai as intentionally out of scope. The proposed cross-lifecycle fixture is disproportionate to the value it adds. #1627 owns typed candidate and result validation, and #1628 owns transaction, recovery, concurrency, push, and rollback tests. Those focused contracts are the required proof. Do not replace this issue with another public demo, fixture mode, harness adapter, script, or tracked toy application. Reopen only if a concrete production boundary remains untested after #1627 and #1628 land, and file that boundary as the smallest focused test slice.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
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#1629
No description provided.