# 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 HTTPS web UI, authenticate through the single-operator session boundary, and use the 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 the canonical production path. Binding verification hooks live under `tests/golive/`; after the I1 drift reset they must not use the deprecated synthetic workspace/provider path as proof. **Control plane and durable state** - [ ] AC-01: At the configured HTTPS base URL, an unauthenticated owner is sent to the login surface; after the operator password is exchanged for the `__Host-awp_session` HttpOnly/Secure/SameSite=Lax session, the AWP Project UI loads in under 3 seconds with zero browser console errors. Verification: Playwright `golive/01-ui-loads.spec.ts` signs in through `/login`, then asserts authenticated Project-list load time and an empty console-error collector; session-boundary tests assert cookie attributes and 401 fail-closed behavior. - [ ] 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 creates or reuses exactly one FactoryRun for the approved PlanRevision/work graph and causes the first dispatch-eligible Task to move to dispatched without any further human action; subsequent Tasks in that PlanRevision remain under the same FactoryRun. Verification: Playwright waits for the first Task status change; `psql` asserts exactly one FactoryRun for the PlanRevision and later AC-22 asserts the full three-Task run keeps that one FactoryRun identity. - [ ] 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: After trusted merge, producer and independent-reviewer compute plus PVCs are cleaned only after their exact Git-tree checkpoints and ChangeSet/review artifacts are durably collected. Verification: `golive/14-artifact-cleanup.spec.ts` requires both Workspace rows to retain checkpoint digest, collection time and `cleanedAt`, then asserts no matching Pod or PVC remains in `awp-workspaces`. **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: Trusted Merge is refused while the independent reviewer AgentRun, exact-candidate VerificationEvidence, repository-required checks, policy, or target-revision fidelity is incomplete; under the default full-chain Policy, once all gates pass the control plane performs trusted Merge automatically with no second owner action and no Approval record. Verification: `golive/19-review-merge.spec.ts` asserts pending refusal and coder/reviewer independence, then keeps the owner page open and requires the ChangeSet to become merged without clicking Merge or refreshing checks. - [ ] 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 project repository default branch advances only through AWP's repository-scoped trusted merge boundary, never through an AgentRun credential. Verification: AC-18 proves agents cannot push; `golive/19-review-merge.spec.ts` requires a durable trusted merge reference/resulting revision and independently reads the remote default-branch tip back as that exact resulting revision. - [ ] 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 after trusted ChangeSet publication but before merge; after restart the independent Review/required-check state reconciles and the default full-chain Policy completes trusted Merge automatically exactly once. Verification: `golive/27-merge-restart.spec.ts` starts from a durably published non-merged ChangeSet, restarts the control plane, performs no owner Merge action, waits for `merged`, and requires one durable merge identity/result revision with zero Approval rows. **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 FactoryRun, published through the repository-scoped trusted boundary with durable `AWP-FactoryRun` and `AWP-ChangeSet` trailers, merged by AWP, and remains in the actual remote default-branch history. Verification: `golive/29-self-change.spec.ts` fetches `origin/main` and requires those exact trailers for the merged self-project ChangeSet. - [ ] 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 full-chain policy — independent reviewer AgentRun and exact verification gates followed by automatic trusted Merge, with no extra owner approval. 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.