Define the coilyco QA fixture lane and end-to-end proof #781

Open
opened 2026-07-29 04:44:20 +00:00 by coilyco-ops · 2 comments
Member

Outcome

Bind the generic QA verification authority to a concrete disposable coilyco fixture lane and prove a real director to engineer to QA run from launch through cleanup.

Dependencies:

Deployment ownership

AOS owns the coilyco Ward deployment bundle. The fixture repository, issue admission rule, identity, model and container defaults, and other deployment values belong in the AOS .ward/ bundle. Ward remains provider-neutral and must not fetch this configuration downward.

Required binding

  • Select or create a dedicated public-safe fixture repository and issue convention.
  • Admit only fixture issues through an explicit label, typed marker, or equivalent machine-checked property.
  • Bind QA verification mode to the minimum Forgejo and container capabilities needed for launch, observation, stop, reap, and cleanup.
  • Deny normal repositories, main pushes, merges, releases, deploys, and production targets.
  • Keep opaque values and credentials out of tracked configuration. Resolve deployment secrets through the existing host-side secret path.
  • Provide one tracked, reusable verification entry point through a Ward verb or other repository-owned script.

End-to-end proof

Run one disposable fixture through:

  1. Director receives the fixture outcome and dispatches bounded work.
  2. Engineer completes the fixture change on the permitted disposable branch or equivalent test surface.
  3. QA independently verifies the acceptance criteria and records a verdict.
  4. Ward stops and reaps every workload, releases reservations, and closes or resets the fixture.

Acceptance

  • The complete role chain runs under QA verification authority without an Ops role switch.
  • Audit evidence identifies fixture mode, fixture scope, every child role, terminal outcomes, and cleanup.
  • A non-fixture repository and a release or merge attempt fail before mutation.
  • The fixture run leaves no live container, reservation, branch, or open issue unless QA deliberately preserves evidence after a failure.
  • Documentation explains how an authorized QA role runs the fixture and how Ops diagnoses substrate failures.
  • The deployment bundle passes its owning schema or doctor surface without a duplicated configuration contract test.
## Outcome Bind the generic QA verification authority to a concrete disposable coilyco fixture lane and prove a real director to engineer to QA run from launch through cleanup. Dependencies: * coilyco-flight-deck/agent-compose#128 defines the QA authority. * coilyco-flight-deck/ward#1617 enforces fixture mode. ## Deployment ownership AOS owns the coilyco Ward deployment bundle. The fixture repository, issue admission rule, identity, model and container defaults, and other deployment values belong in the AOS `.ward/` bundle. Ward remains provider-neutral and must not fetch this configuration downward. ## Required binding * Select or create a dedicated public-safe fixture repository and issue convention. * Admit only fixture issues through an explicit label, typed marker, or equivalent machine-checked property. * Bind QA verification mode to the minimum Forgejo and container capabilities needed for launch, observation, stop, reap, and cleanup. * Deny normal repositories, main pushes, merges, releases, deploys, and production targets. * Keep opaque values and credentials out of tracked configuration. Resolve deployment secrets through the existing host-side secret path. * Provide one tracked, reusable verification entry point through a Ward verb or other repository-owned script. ## End-to-end proof Run one disposable fixture through: 1. Director receives the fixture outcome and dispatches bounded work. 2. Engineer completes the fixture change on the permitted disposable branch or equivalent test surface. 3. QA independently verifies the acceptance criteria and records a verdict. 4. Ward stops and reaps every workload, releases reservations, and closes or resets the fixture. ## Acceptance * The complete role chain runs under QA verification authority without an Ops role switch. * Audit evidence identifies fixture mode, fixture scope, every child role, terminal outcomes, and cleanup. * A non-fixture repository and a release or merge attempt fail before mutation. * The fixture run leaves no live container, reservation, branch, or open issue unless QA deliberately preserves evidence after a failure. * Documentation explains how an authorized QA role runs the fixture and how Ops diagnoses substrate failures. * The deployment bundle passes its owning schema or doctor surface without a duplicated configuration contract test.
Author
Member

Repository implementation landed in 8e5c7a75.

  • Ward dependency - v0.856.0 is released and installed. Ward #1617 is closed.
  • Deployment binding - .ward/ward.yaml admits only coilyco-flight-deck/ward-qa-fixture issues labeled qa-fixture.
  • Reusable entry point - scripts/qa-verification-fixture.sh, exposed as the qa-verification-fixture Ward verb.
  • Runbook and operator boundary - https://forgejo.coilysiren.me/coilyco-flight-deck/agentic-os/src/branch/main/docs/qa-verification-fixture.md
  • Local evidence - released-Ward doctor passed, the complete AOS pre-commit suite passed, ShellCheck passed, help-mode execution passed, and a live read-only attempt against agentic-os#781 failed before launch because the repo is not admitted.

Interactive live wall

  1. Ops follows the committed one-time bootstrap section in the runbook. This creates the dedicated public fixture repository and organization label.
  2. Agent-compose #128 must land the QA authority doctrine before QA launches the mutating proof.
  3. QA follows the committed Run section. QA returns the fixture issue, reviewed commit, verdict marker, empty container/reservation check, deleted issue-N branch check, and closed fixture issue.

The engineer role did not perform or route around the live bootstrap or proof. Keep this issue open until those live evidence items return.

Repository implementation landed in https://forgejo.coilysiren.me/coilyco-flight-deck/agentic-os/commit/8e5c7a75. * Ward dependency - v0.856.0 is released and installed. Ward #1617 is closed. * Deployment binding - `.ward/ward.yaml` admits only `coilyco-flight-deck/ward-qa-fixture` issues labeled `qa-fixture`. * Reusable entry point - `scripts/qa-verification-fixture.sh`, exposed as the `qa-verification-fixture` Ward verb. * Runbook and operator boundary - https://forgejo.coilysiren.me/coilyco-flight-deck/agentic-os/src/branch/main/docs/qa-verification-fixture.md * Local evidence - released-Ward doctor passed, the complete AOS pre-commit suite passed, ShellCheck passed, help-mode execution passed, and a live read-only attempt against `agentic-os#781` failed before launch because the repo is not admitted. **Interactive live wall** 1. Ops follows the committed one-time bootstrap section in the runbook. This creates the dedicated public fixture repository and organization label. 2. Agent-compose #128 must land the QA authority doctrine before QA launches the mutating proof. 3. QA follows the committed Run section. QA returns the fixture issue, reviewed commit, verdict marker, empty container/reservation check, deleted `issue-N` branch check, and closed fixture issue. The engineer role did not perform or route around the live bootstrap or proof. Keep this issue open until those live evidence items return.
Author
Member

Release follow-through is now isolated and tracked in infrastructure#685. Read-only inspection of dev-base-publish run 2355 confirmed that each completed language publisher reaches Docker, then Forgejo rejects the supplied registry credential as unauthorized. Repo CI, mirror, promote, and the AOS CLI release all passed. Infrastructure owns the existing /forgejo/coilyco-ops/registry-token write credential and attended registry-token-provision verifier, so #685 is labeled interactive and P1 for Ops to verify or rotate the credential and return one authorized publication result. The engineer did not rerun Actions or mutate the registry.

Release follow-through is now isolated and tracked in infrastructure#685. Read-only inspection of dev-base-publish run 2355 confirmed that each completed language publisher reaches Docker, then Forgejo rejects the supplied registry credential as unauthorized. Repo CI, mirror, promote, and the AOS CLI release all passed. Infrastructure owns the existing `/forgejo/coilyco-ops/registry-token` write credential and attended `registry-token-provision` verifier, so #685 is labeled `interactive` and `P1` for Ops to verify or rotate the credential and return one authorized publication result. The engineer did not rerun Actions or mutate the registry.
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/agentic-os#781
No description provided.