Define the Ops release-candidate and outcome contract

coilyco-ops commented

2026-07-31 08:20:38 +00:00

Member

Parent

#1625

What to build

On top of the generic composed-agent dispatch supplied by #1626, define the typed handoff between Director and Ops.

The release candidate must identify an immutable application revision, target environment, deploy repository and starting revision, originating ticket and Ward run provenance, plus the repository-provided deployment and verification surfaces Ops may invoke.

The result must classify the attempt as verified, rejected by the candidate, restored after failure, or blocked externally. A verified result carries the resulting deploy-repository commit. Every non-verified result carries no new deploy-state commit.

Ward transports and records this contract. It does not learn Kubernetes, GitOps-controller, rollout, or environment-management semantics.

Acceptance criteria

A Director can hand an accepted immutable application revision to an Ops role through #1626.
The candidate binds the target environment and starting deploy-repository revision.
The candidate names repository-provided deploy and verification operations without embedding their implementation in Ward.
Ops returns one typed terminal classification plus the verified deploy commit when successful.
Failed or externally blocked outcomes cannot claim or attach a new deploy-state commit.
The candidate and result remain visible in normal Ward run artifacts with secret-bearing values excluded.
Tests cover validation, serialization, missing provenance, immutable-revision enforcement, and every terminal classification.

Execution mode

AFK. Use fixtures only. No live deployment is required for this slice.

Blocked by

Blocked by #1626.

## Parent #1625 ## What to build On top of the generic composed-agent dispatch supplied by #1626, define the typed handoff between Director and Ops. The release candidate must identify an immutable application revision, target environment, deploy repository and starting revision, originating ticket and Ward run provenance, plus the repository-provided deployment and verification surfaces Ops may invoke. The result must classify the attempt as verified, rejected by the candidate, restored after failure, or blocked externally. A verified result carries the resulting deploy-repository commit. Every non-verified result carries no new deploy-state commit. Ward transports and records this contract. It does not learn Kubernetes, GitOps-controller, rollout, or environment-management semantics. ## Acceptance criteria * [ ] A Director can hand an accepted immutable application revision to an Ops role through #1626. * [ ] The candidate binds the target environment and starting deploy-repository revision. * [ ] The candidate names repository-provided deploy and verification operations without embedding their implementation in Ward. * [ ] Ops returns one typed terminal classification plus the verified deploy commit when successful. * [ ] Failed or externally blocked outcomes cannot claim or attach a new deploy-state commit. * [ ] The candidate and result remain visible in normal Ward run artifacts with secret-bearing values excluded. * [ ] Tests cover validation, serialization, missing provenance, immutable-revision enforcement, and every terminal classification. ## Execution mode AFK. Use fixtures only. No live deployment is required for this slice. ## Blocked by * Blocked by #1626.

coilyco-ops referenced this issue

2026-07-31 08:21:28 +00:00

Enforce verified deploy-state transitions per environment #1628

coilyco-ops referenced this issue

2026-07-31 08:21:36 +00:00

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

coilyco-ops referenced this issue

2026-07-31 08:21:52 +00:00

Add an Ops role for verified GitOps deployment handoff #1625

coilyco-ops referenced this issue

2026-07-31 08:21:55 +00:00

Generalize the dispatch broker for arbitrary composed agents #1626

coilyco-ops added the

labels

2026-07-31 08:25:54 +00:00

coilyco-ops referenced this issue

2026-07-31 08:29:07 +00:00

Add an Ops role for verified GitOps deployment handoff #1625

coilyco-ops referenced this issue

2026-07-31 09:02:20 +00:00

Add an Ops role for verified GitOps deployment handoff #1625

coilyco-ops added

and removed

labels

2026-08-05 10:26:06 +00:00

coilyco-ops commented

2026-08-05 10:39:36 +00:00

Author

Member

Decision resolved with Kai:

#1627 is a typed broker artifact contract, not an Ops permission grant.
Candidate schema is versioned and immutable. It carries a candidate ID, content hash, exact application repository and full commit, immutable artifact digest, target environment ID, deploy repository and full starting commit, originating ticket, Ward correlation IDs, and deploy/verify operation references.
Operation references are safe symbolic IDs only. They contain no argv, scripts, paths, URLs, environment values, or secrets. They name operations independently exposed through the guarded Ops surface. Neither the candidate nor the ops role grants authority.
The candidate is addressed to one exact broker-minted peer. Ward stamps both parties. Payload claims about role or sender are not trusted.
Each execution receives a new attempt ID while the candidate stays immutable. A changed starting deploy revision requires a new candidate.
Terminal deployment outcomes are verified, rejected, restored, blocked, and indeterminate.
- verified means the candidate is live and verified and carries the pushed deploy commit.
- rejected means the candidate was refused before environment mutation.
- restored means mutation began and failed, then the previous committed state was restored and verified.
- blocked means an external dependency prevented mutation from starting.
- indeterminate means mutation may have occurred but neither candidate nor previous state is verified, or the push result is ambiguous. It blocks automated retry pending Ops reconciliation.
Harness, transport, and broker failures remain Ward lifecycle failures rather than deployment outcomes.
Only verified may carry a new deploy-state commit. Every other result omits one. restored identifies the unchanged starting commit.
Persist candidate, result, reason codes, correlations, and evidence digests through the secret-safe artifact path. Do not persist raw operational payloads.
blocked, rejected, and restored may retry with a new attempt only while the starting revision still matches. indeterminate fails closed.

This keeps Ward provider-neutral and gives #1628 an explicit unknown-state safety path.

Decision resolved with Kai: * #1627 is a typed broker artifact contract, not an Ops permission grant. * Candidate schema is versioned and immutable. It carries a candidate ID, content hash, exact application repository and full commit, immutable artifact digest, target environment ID, deploy repository and full starting commit, originating ticket, Ward correlation IDs, and deploy/verify operation references. * Operation references are safe symbolic IDs only. They contain no argv, scripts, paths, URLs, environment values, or secrets. They name operations independently exposed through the guarded Ops surface. Neither the candidate nor the `ops` role grants authority. * The candidate is addressed to one exact broker-minted peer. Ward stamps both parties. Payload claims about role or sender are not trusted. * Each execution receives a new attempt ID while the candidate stays immutable. A changed starting deploy revision requires a new candidate. * Terminal deployment outcomes are `verified`, `rejected`, `restored`, `blocked`, and `indeterminate`. * `verified` means the candidate is live and verified and carries the pushed deploy commit. * `rejected` means the candidate was refused before environment mutation. * `restored` means mutation began and failed, then the previous committed state was restored and verified. * `blocked` means an external dependency prevented mutation from starting. * `indeterminate` means mutation may have occurred but neither candidate nor previous state is verified, or the push result is ambiguous. It blocks automated retry pending Ops reconciliation. * Harness, transport, and broker failures remain Ward lifecycle failures rather than deployment outcomes. * Only `verified` may carry a new deploy-state commit. Every other result omits one. `restored` identifies the unchanged starting commit. * Persist candidate, result, reason codes, correlations, and evidence digests through the secret-safe artifact path. Do not persist raw operational payloads. * `blocked`, `rejected`, and `restored` may retry with a new attempt only while the starting revision still matches. `indeterminate` fails closed. This keeps Ward provider-neutral and gives #1628 an explicit unknown-state safety path.

coilyco-ops referenced this issue

2026-08-05 10:47:12 +00:00

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

coilyco-ops referenced this issue

2026-08-05 10:51:04 +00:00

Remove public verification-fixture mode #1645

coilyco-ops referenced this issue from a commit

2026-08-06 04:17:40 +00:00

feat: define typed Ops release contract

coilyco-ops closed this issue

2026-08-06 04:17:41 +00:00

coilyco-ops commented

2026-08-06 04:17:57 +00:00

Author

Member

WARD-OUTCOME: done

Landed on canonical main as 73aedba652a4e331f7f2713b4cea7156533bf686.

Added the typed ward agent release candidate, result, retry, and receive broker surface.
Broker stamps Director and exact Ops peer identity, Ward correlation, immutable candidate hash, and candidate/attempt IDs.
Enforced full immutable revisions, symbolic operation references, all five terminal classifications, verified-only new deploy commits, restored starting-commit identity, and fail-closed indeterminate retry behavior.
Persisted secret-safe release.jsonl records beside the Ops dispatch artifact and exposed --artifact release.
Covered validation, serialization, missing provenance, mutation detection, authenticated broker transport, retry rules, and every terminal classification with synthetic fixtures only.
Full tests, lint, vet, build, Windows compile, policy and release checks, pre-commit, and Ward doctor passed.

WARD-OUTCOME: done Landed on canonical `main` as `73aedba652a4e331f7f2713b4cea7156533bf686`. * Added the typed `ward agent release` candidate, result, retry, and receive broker surface. * Broker stamps Director and exact Ops peer identity, Ward correlation, immutable candidate hash, and candidate/attempt IDs. * Enforced full immutable revisions, symbolic operation references, all five terminal classifications, verified-only new deploy commits, restored starting-commit identity, and fail-closed indeterminate retry behavior. * Persisted secret-safe `release.jsonl` records beside the Ops dispatch artifact and exposed `--artifact release`. * Covered validation, serialization, missing provenance, mutation detection, authenticated broker transport, retry rules, and every terminal classification with synthetic fixtures only. * Full tests, lint, vet, build, Windows compile, policy and release checks, pre-commit, and Ward doctor passed.

Rows
Columns

Define the Ops release-candidate and outcome contract #1627

Parent

What to build

Acceptance criteria

Execution mode

Blocked by