# GOLIVE — AWP **Date:** 2026-08-21 **Status:** Active finish line for AWP. Supersedes commit counts, lane progress notes and agent "done" reports as the project's progress measure. **Scope:** This file is the R1 finish-line artifact for AWP's own repository, per `/home/user/Projects/0 DOCS/2026-07-12-finishing-gap-diagnosis.md`. Inside the AWP product, a go-live target is not a primitive — it is a Goal with launch-oriented criteria, per `docs/plans/AWP-INCREMENTAL-DELIVERY-PLAN.md`. The two are not in conflict: this document is AWP taking its own medicine on its own repo. ## The one journey ```text I open the AWP web UI, create a project, make a small plan, a factory run executes it in a K3s pod, the changeset is reviewed and merged by the control plane, and I watched every step live. ``` Refined for precision, this is the journey that must pass: As the owner, in a browser, I open the AWP web UI backed by a running control plane on PostgreSQL. I create a Project bound to a real Git repository, write a compact ProjectVision and one Goal, and build a Plan of at least three Tasks with at least one hard dependency between them. I approve the Plan. AWP dispatches the first dispatch-eligible Task to a FactoryRun, which starts an AgentRun in a pod on the K3s cluster — not on my workstation. The agent edits code in an isolated durable workspace and produces a real ChangeSet against the project repository. The agent has no credential that can write to the project remote. AWP publishes the ChangeSet, an independent Review is recorded, and the control plane — not the agent — performs the merge. The next Task in dependency order then dispatches automatically until the Plan is complete. Throughout, every stage transition is visible to me live in the UI without a manual page reload, and if the control plane is killed mid-run, the run resumes or reconciles correctly when it comes back. Anything not required to make that paragraph literally true is out of v1. ## 2026-08-22 acceptance reset after deployed-I1 audit The historical 30/30 run is retained in Git history as evidence of the earlier harness, but it is **not accepted as proof that I1 is complete**. Deployment exposed a split between fixture/prototype paths and the actual product runtime, and the subsequent whole-slice audit found the same pattern in multiple backend/provider seams. All criteria below are reset to unchecked. They must be re-proven against the **same canonical production path the owner uses**, with no alternate UI renderer, fake provider client, synthetic coding agent, disposable substitute for AWP's real Git history, or fixture-only lifecycle standing in for the product requirement. This reset is an acceptance-evidence reset, not a claim that no implementation exists. Salvageable implementation and blocking drift are recorded in `docs/progress/2026-08-22-i1-drift-audit.md`. ## Acceptance criteria Rules: each criterion is finite, user-visible and verifiable by a named script or E2E test. No criterion is satisfied by "code exists for X" — only by "X observably works" on a running system. A box is checked only when its named verification passes on a clean run against a freshly provisioned environment. Verification hooks will live under `tests/golive/`; none exist yet. **Control plane and durable state** - [ ] AC-01: The AWP web UI loads for the owner at its configured base URL in under 3 seconds with zero browser console errors. Verification: Playwright spec `golive/01-ui-loads.spec.ts` asserting load time and an empty console-error collector. - [ ] AC-02: The control plane reports healthy against a real PostgreSQL instance with all migrations applied and no pending migration diff. Verification: `curl` of the health endpoint asserting `status: ok` plus a Drizzle migration-drift check that exits non-zero on any pending migration. - [ ] AC-03: Killing and restarting the control plane process with no in-flight work leaves every Project, Plan, Task and FactoryRun row present and identical. Verification: script snapshots an explicit non-volatile column projection of those tables ordered by id, excluding `created_at`/`updated_at`, restarts the process, re-snapshots and asserts the two projections are equal. **Project, plan and task creation through the UI** - [ ] AC-04: The owner creates a Project through the UI, bound to a real Git repository URL, and the Project appears in the project list after reload. Verification: Playwright spec drives the create form; a `psql` query asserts exactly one new Project row with the submitted repository URL. - [ ] AC-05: The owner writes a compact ProjectVision through the UI and it is persisted as a versioned record readable back on the Project page. Verification: Playwright spec plus `psql` query asserting one `project_vision_version` row whose text matches the submitted text. - [ ] AC-06: The owner creates one Goal with at least one written launch criterion through the UI, and the Goal is displayed on the Project page. Verification: Playwright spec asserting the Goal title and criterion text are rendered. - [ ] AC-07: The owner creates a Plan with at least three Tasks through the UI, and all three Tasks are listed on the Plan page in creation order. Verification: Playwright spec asserting three named Task rows. - [ ] AC-08: The owner declares a hard dependency between two Tasks through the UI, and the dependent Task is rendered as blocked while its prerequisite is incomplete. Verification: Playwright spec asserting the blocked state badge and the named unsatisfied prerequisite. - [ ] AC-09: An attempt to create a dependency cycle through the UI is rejected with a readable error naming the cycle path, and no Task dependency row is written. Verification: Playwright spec asserting the error text plus a `psql` count assertion that the dependency table is unchanged. - [ ] AC-10: The owner approves the Plan through the UI and the Plan moves to an approved state that is visible after reload. Verification: Playwright spec plus `psql` assertion on the Plan status column. **Dispatch to a K3s pod** - [ ] AC-11: Approving the Plan causes the first dispatch-eligible Task to move to dispatched without any further human action. Verification: Playwright spec waits for the Task status change; `psql` asserts a FactoryRun row referencing that Task. - [ ] AC-12: The dispatched AgentRun executes inside a pod on the K3s cluster from an immutable OCI image digest without per-node image preload/import or image-readiness labels. Verification: the ExecutionProfile and rendered Pod both reference the same `ghcr.io/...@sha256:` image; the workspace namespace has the system-scoped pull secret; a clean eligible worker with no preloaded AWP runner image can schedule the probe/AgentRun and reach `Running` by normal registry pull; `kubectl get pods -l awp.agent-run-id=` returns exactly one pod on a cluster node, not the workstation. - [ ] AC-13: The blocked dependent Task is never dispatched before its prerequisite Task reaches a completed state. Verification: script polls Task status transitions for the whole run and asserts the prerequisite's completion timestamp precedes the dependent's dispatch timestamp. - [ ] AC-14: When the AgentRun reaches a terminal state, its pod and workspace are cleaned up only after the ChangeSet and run artifacts are durably recorded. Verification: script asserts the ChangeSet row and artifact records exist at the moment `kubectl get pod` first returns `NotFound`. **Real ChangeSet from a real agent run** - [ ] AC-15: The AgentRun produces a ChangeSet containing a non-empty diff against the project repository, recorded in the control plane. Verification: `psql` asserts a ChangeSet row whose stored diff is non-empty and applies cleanly with `git apply --check` on the project repository. - [ ] AC-16: The ChangeSet records the account, provider and model used for the Attempt that produced it. Verification: `psql` asserts non-null account, provider and model provenance columns on the Attempt joined to the ChangeSet. - [ ] AC-17: A failed Attempt produces a new Attempt on the same AgentRun, and both Attempts remain visible with their outcomes. Verification: test forces one Attempt failure via an injected non-zero agent exit, then asserts two Attempt rows and two entries rendered in the UI run timeline. **Review and trusted merge — the agent never pushes** - [ ] AC-18: From inside a running agent pod, `git push` to the project remote fails with the credentials actually present in that pod. Verification: script records the project remote's default-branch tip SHA, runs the push via `kubectl exec` into the pod, and asserts both a non-zero exit code and that the remote default-branch tip SHA is unchanged afterwards. - [ ] AC-19: The merge is refused while the ChangeSet's Review is pending, and proceeds after the owner records an approving disposition through the UI under the single default review-before-merge policy. Verification: script requests the merge with the Review pending and asserts refusal; a Playwright step then drives the owner's approval in the UI and the script asserts the merge succeeds. - [ ] AC-20: The Review's recorded reviewer identity is not the identity of the agent that authored the ChangeSet. Verification: `psql` asserts the Review reviewer identity differs from the authoring AgentRun's agent identity. - [ ] AC-21: The merge commit on the project repository's default branch is committed by the control plane identity, not by any agent identity. Verification: `git log -1 --format='%cn <%ce>'` on the project repository's default branch asserts the configured control-plane committer identity. - [ ] AC-22: After the merge, the next dispatch-eligible Task dispatches automatically and the Plan reaches a completed state with all Tasks completed. Verification: end-to-end script runs the full Plan unattended and asserts the terminal Plan status plus completion of every Task. **Live observability** - [ ] AC-23: Every journey stage transition — Task dispatched, FactoryRun started, AgentRun started, ChangeSet created, Review recorded, Merge completed — appears in the open UI within 5 seconds of occurring, with no manual page reload. Verification: Playwright spec holds one page open for the whole run and asserts each of the six transitions with a 5-second timeout. - [ ] AC-24: The agent's tool-use log and the ChangeSet diff are viewable in the UI as a readable timeline and a rendered diff, not a raw JSON dump. Verification: Playwright spec asserts at least one named tool-call entry and a diff view containing added and removed line elements. - [ ] AC-25: A run that is waiting or failed is visibly distinguished in the UI from a run that is progressing, and states the reason. Verification: Playwright spec against the forced-failure run from AC-17 asserts the failure badge and a non-empty reason string. **Survivability across a control-plane restart** - [ ] AC-26: The control plane is killed while an AgentRun is in flight; after restart the run resumes or reconciles to a correct terminal state with exactly one ChangeSet and no orphaned pod. Verification: script kills the process mid-run, restarts, waits for terminal state, asserts a single ChangeSet row for the AgentRun and that `kubectl get pods` shows no pod for it. - [ ] AC-27: The control plane is killed between ChangeSet publication and merge; after restart the merge completes exactly once and the default branch contains exactly one merge commit for that ChangeSet. Verification: script asserts `git log --grep=` returns exactly one commit. **AWP dogfooding itself** - [ ] AC-28: AWP's own repository is registered as Project number one in AWP, with a ProjectVision derived from `docs/VISION.md`. Verification: `psql` asserts a Project row whose repository URL is AWP's own remote and which has at least one ProjectVision version. - [ ] AC-29: A real change to AWP's own repository is authored by an AWP factory run and merged by the AWP control plane, and is present in AWP's git history. Verification: `git log` on AWP's default branch finds a commit whose trailer records the originating AWP FactoryRun id, with the control-plane committer identity. - [ ] AC-30: AWP's own GOLIVE percentage, computed from this file, is rendered on AWP's Project page inside AWP and matches the checkbox count in this file. Verification: script parses checked/total boxes from `GOLIVE.md` and asserts the same fraction is displayed by the Project page. Total: 30 criteria. ## Explicitly NOT in v1 (the cut list) Everything below is deferred in writing. Each item returns to the roadmap only after the one journey above passes end-to-end. Deferring these is a decision, not a loss, and none of them may be re-opened as "small" work while any acceptance criterion is unchecked. - **Advisor personas.** Specced and deferred — `docs/plans/AWP-ADVISORY-PERSONAS-AND-SEARCH-DESIGN.md`, `docs/plans/AWP-ADVISOR-SEARCH-DEPENDENCY-DECISIONS.md`. Returns only after the journey passes. - **Cmd+K global search.** Specced and deferred in the same two documents. Returns only after the journey passes. - **Cluster management UI.** K3s is execution substrate only in v1; no cluster product surface, capacity views, scheduler UX or placement explainability. Returns only after the journey passes. - **Machine enrollment.** No `+ ADD MACHINE`, no SSH preflight, no node provisioning primitive. The cluster is provisioned by hand for v1. Returns only after the journey passes. - **CI optimizer agent.** No redundant-check detection, no invariant proposals, no historical CI performance analysis. Returns only after the journey passes. - **Incidents and self-healing.** No Incident primitive, no deterministic resolver library, no agentic resolver, no resolver-proposal workflow. Returns only after the journey passes. - **Release and CD.** No Artifact, Release, Environment, Deployment, Flux adapter, rollback or deployment health. Returns only after the journey passes. - **ARC migration of AWP's own CI.** AWP's own repository checks stay on their current runner arrangement for v1. Returns only after the journey passes. - **gVisor.** Pod-level isolation as configured is the v1 containment boundary; no sandboxed runtime class. Returns only after the journey passes. - **Multi-tenancy, RBAC and organizations.** Single owner, single tenant, no user management, no quotas, no tenant isolation. Returns only after the journey passes. - **Autonomy policy matrix beyond a single default.** One built-in default human-in-the-loop policy — review before merge. No configurable per-criterion autonomy levels, no policy editor, no resolver-model escalation. Returns only after the journey passes. - **Notification channels.** No communications primitive, no Botmaster or systray adapters, no email or webhook delivery. Returns only after the journey passes. ## Progress metric ```text % done = checked acceptance criteria / total acceptance criteria ``` Current: **0 / 30 (0%) re-proven after the I1 drift audit**. Rules for this number: - The checkbox state in this file is the single source of truth for AWP's completion percentage. It replaces commit counts, lane progress documents under `docs/progress/`, increment gate colours and any agent report as the answer to "how done is AWP". - A box flips to checked only when its named verification script or E2E test passes on a clean run. A passing verification is the only evidence accepted; a claim that the underlying code is finished is not. - A box flips back to unchecked the moment its verification fails. The percentage is allowed to go down. - Reported in three places: (1) this file, updated in the same commit as the verification that flipped the box; (2) once the suite exists, the `tests/golive/` summary line printed at the end of a full suite run, which must agree with this file; (3) once AC-30 passes, AWP's own Project page inside AWP, which becomes the display surface while this file remains the source of truth. - No AWP task is "done" if a verification it touches is failing.