# AWP Direction / Progress / Drift Audit — 2026-08-24 **Status:** independent current-state review; **not a completion claim** **Canonical source audited:** `origin/main@d7dddc24dc9113ed0d2ed7a7fcd392f50e70cab9` **Audit branch:** `audit/awp-direction-progress-20260824` **Live dogfood host inspected:** `debian3` **Previous review baseline:** pre-convergence audit that found false 30/30 completion, manual default Merge, missing ADR-0009 auth/session, incomplete DBOS transaction seam, branch divergence, and unproven dogfood. This review answers four owner questions: 1. Is AWP still going in the intended product/architecture direction? 2. Is current development doing what the approved I0/I1 plan says it should do? 3. What has materially improved since the last review? 4. What plan drift, vision drift, implementation gaps or premature-completion risks remain? --- # Executive verdict ## Direction **Yes — the core AWP product direction is still correct, and it is materially healthier than at the previous review.** The project is now much closer to the intended control-plane product: ```text Project -> Goal -> Plan -> Task/Queue -> one FactoryRun for the approved work graph -> AgentRun / immutable Attempt provenance -> durable Workspace / accepted WIP -> immutable ChangeSet candidate -> VerificationEvidence + repository-required checks -> independent reviewer AgentRun -> automatic trusted Merge -> next dependency-legal Task ``` The previously serious architecture drifts are no longer the dominant problem. Authentication, default delivery autonomy, DBOS durability, trusted repository boundaries, reviewer independence, WIP durability and branch convergence have all improved substantially and are now present on canonical `main`. ## Completion **No — I1 is not complete and should not be described as production/dogfood-ready yet.** The dominant remaining risk has shifted from **wrong implementation architecture** to **unfinished canonical proof, stale live deployment, and a smaller set of binding owner-semantic gaps**. The most important current facts are: ```text canonical source main: converged and green normal repository gate: 233 passed / 9 opt-in skipped GOLIVE registry structure: 30 / 30 criteria represented GOLIVE semantic readiness: 0 / 30 owner acceptance: 0 / 30 canonical live controller: not executable yet live debian3 topology: older pre-auth/public-bind deployment ``` That `0/30` state is **truthful and appropriate**. The project is making real progress without pretending that source-level proof equals owner acceptance. ## Current health scorecard | Area | Assessment | Current meaning | |---|---|---| | Product vision / domain model | **GREEN** | Still aligned to AWP as authoritative agentic delivery control plane. | | I0/I1 scope discipline | **GREEN** | No meaningful I2-I9 product creep found. | | Canonical branch truth | **GREEN** | Auth, durability and dogfood work converged to `origin/main`; GOLIVE is truthful 0/30. | | Authentication / trust boundary in source | **GREEN** | ADR-0009 implemented and canonical. | | Default full-chain autonomy in source | **GREEN** | Independent Review and trusted Merge are automatic; zero default Approval rows. | | Durable workflow / crash safety | **GREEN** | Binding marker/outbox seam and exact SIGKILL proof now exist. | | Native ACP / runner recovery | **GREEN / YELLOW** | Major FOUNDATION/N2 state-migration/recovery defects repaired and tested; live owner proof pending. | | Trusted repository / publication | **GREEN / YELLOW** | Exact identity and required-check gates are strong; autonomous merge-conflict recovery remains missing. | | Approved U1-U6 implementation | **YELLOW** | Visual hierarchy largely preserved; Attention and FactoryRun Review semantics have gaps. | | Configuration authority | **RED / YELLOW** | Binding Postgres/typed-config contract is not actually realized in production composition. | | Canonical GOLIVE harness | **RED** | Structurally sophisticated but logically non-executable and has proof-env binding mismatches. | | Live dogfood topology | **RED** | Debian3 still runs old public-bind/pre-auth deployment, not current source architecture. | | Governance / current plans | **YELLOW / RED** | Active-plan and binding-status documentation lags the implementation and can misdirect future agents. | ## Recommendation **Continue in the current architecture direction. Do not expand the product.** The right next phase is: ```text 1. repair the canonical GOLIVE readiness/controller + proof bindings 2. reconcile remaining I1 owner-pain gaps (config, VCS conflict autopilot, UI attention/review semantics) 3. reconcile binding docs with what is actually implemented 4. deploy the exact current architecture to dogfood 5. execute the one authenticated owner journey 6. advance 0/30 only from evidence produced by that journey ``` Do **not** start I2-I9 productization while those I1 obligations remain open. --- # 1. Audit basis and evidence This audit used the exact canonical tree rather than the stale local checkout: ```text /home/user/Projects/.worktrees/awp-direction-audit-20260824 HEAD = origin/main@d7dddc24dc9113ed0d2ed7a7fcd392f50e70cab9 ``` The workstation's ordinary `/home/user/Projects/awp` checkout was detected as materially behind `origin/main`; conclusions from that stale tree were discarded before this report was written. Evidence reviewed includes: - `docs/plans/I0-I1-AUTHORITY.md` - `docs/plans/AWP-GOVERNANCE-AMENDMENT-2026-08-21.md` - `docs/plans/AWP-PAIN-INVARIANTS.md` - `docs/plans/AWP-INCREMENT-REALIZATION-MATRIX.md` - `docs/plans/AWP-U1-PROJECT-HIGH-FIDELITY-BRIEF.md` - `docs/mockups/i1/` - ADRs `0001` through accepted `0009-authentication.md` - `docs/specs/architecture/durable-workflow-transaction-seam.md` - `GOLIVE.md` - canonical GOLIVE registry/orchestrator and every major proof family - current application/persistence/provider/web implementations - final convergence/durable-seam progress ledgers - exact source gate results already recorded on main - fresh Debian2 `pnpm test:golive:validate` / diagnostic output - read-only Debian3 process/listener/Tailscale/K3s inspection. --- # 2. What materially improved since the previous review ## 2.1 Canonical `main` is now truthful and actually converged The previous review's largest governance problem was simultaneous incompatible truths: old `main` advertised invalid 30/30 while repairs accumulated on side branches. That is now corrected. Current canonical state: ```text origin/main = d7dddc24dc9113ed0d2ed7a7fcd392f50e70cab9 ``` It contains: - the latest dogfood/GOLIVE work; - the default-autonomy repair; - ADR-0009 operator sessions; - DBOS durable-step / outbox remediation; - runner state migration/recovery repairs; - the latest published runner-image digest; - final convergence conflict resolutions. `GOLIVE.md` says: ```text Current: 0 / 30 (0%) re-proven after the I1 drift audit ``` That is correct. ## 2.2 ADR-0009 authentication/session is now canonical The accepted ADR is present on current main and the implementation matches its core boundary: - one operator credential; - Argon2id verification; - random 32-byte opaque session token; - SHA-256 token digest stored rather than plaintext token; - PostgreSQL session authority; - Secure + HttpOnly + SameSite=Lax `__Host-awp_session` cookie; - no caller-supplied Principal/capability authority; - Human Principal resolution in control-plane requests; - explicit System Principal for startup/reconciliation/Attempt callbacks; - revocation/logout; - idle + absolute expiry; - credential-hash rotation invalidates old sessions; - source topology defaults privileged control-plane and web listeners to loopback; - HTTPS/Tailscale Serve is the intended dogfood public ingress. The canonical GOLIVE contracts were also updated to require authentication rather than bypassing it. ## 2.3 Default full-chain autonomy is materially repaired The previous manual default Merge gate has been removed from the actual approved production detail renderer. Current source behavior: ```text coder completion -> trusted publication -> independent reviewer AgentRun / Attempt -> reviewer callback -> verification / required-check evaluation -> automatic trusted Merge continuation -> downstream dependency-legal Task dispatch ``` Important evidence: - independent reviewer role and AgentRun identity are separate from coder; - exact candidate digest is bound to Review; - stale reviewer/candidate identity fails closed; - default path creates zero Approval rows; - restart reconciliation can recover pending reviewer/merge work; - merge replay does not duplicate merge or downstream AgentRun; - current approved U5 production renderer says trusted Merge continues automatically. This is a strong correction toward the owner's “request pre-authorizes the whole default delivery chain” pain invariant. ## 2.4 The binding DBOS transaction seam is now implemented and proven The previous review identified this as an architecture ship blocker. It is now one of the strongest parts of the source. Current main contains: - `workflow_step_outcomes` persistence; - composite durable marker key `(operation_id, step_name, step_key)`; - application step-transaction runner; - replay returns recorded outcome without re-mutation; - marker-PK race rolls the losing transaction back and rereads the winner; - Task-dispatch DBOS workflow split into marked domain steps plus provider external steps; - auto-merge DBOS workflow split into required-check, trusted-merge, downstream-dispatch and cleanup steps; - at-least-once outbox dispatcher; - consumer receipts/dedupe by outbox message id; - exact production-inert `AWP_CRASH_AFTER_STEP_COMMIT` hook; - child-process real DBOS + real PostgreSQL SIGKILL crash-window proof; - replayed handler entry count increases while every domain/event/audit/outbox/marker effect remains one; - duplicate outbox delivery leaves one consumer effect. This closes a major prior correctness gap. ## 2.5 FOUNDATION/N2 runner and GOLIVE recovery defects are substantially repaired The old dogfood handoff still lists these as blockers, but canonical source has moved past them. Current runner/recovery work now includes: - immutable runner-state schema versioning; - compatibility limited to truly legacy unversioned state; - one-time legacy reattach/backfill to canonical `selectionKind` / failure-injection state; - strict post-backfill comparison; - modern explicit-none collision handling; - initial/retry/fallback recovery tests; - journey-scoped mutation lock; - exact dependency-chain recovery; - fail-closed authoring/approval closure checks; - recovery that accepts causally advanced valid FactoryRun state; - durable owner UI receipts instead of fabricating UI evidence from PostgreSQL alone; - strict shared GitHub repository canonicalization; - authoritative remote-default-branch parsing. The underlying code has improved; the old handoff document is simply stale. ## 2.6 Trusted publication / verification / WIP safety are materially stronger Current source now has: - repository-scoped trusted publication authority; - immutable publication reference + target reference/revision; - Project repository rebinding detection; - repository-required check observation bound to the published revision; - fail-closed required-check unavailability; - reserved provider evidence source protection; - candidate-bound VerificationEvidence; - reviewer findings bound to candidate; - Workspace checkpoint digest attestation; - retry using preserved WIP; - terminal cleanup only after collected checkpoint identity is present; - no untrusted AgentRun reusable Git publication credentials. This is materially closer to the approved trust model. ## 2.7 Scope discipline remains good A scan of production `apps/` and `packages/` did not find meaningful activation of deferred product scope such as: - Advisor product; - broad Cmd+K/Search product; - incident resolver; - Release/CD product; - machine enrollment; - multi-user/org/RBAC/OIDC; - notification product; - broad I3 policy editor. The project has spent its recent effort mostly on correcting I0/I1 semantics and proof infrastructure. That is the right priority. --- # 3. Current critical findings ## P0-1 — Canonical GOLIVE execution is structurally advanced but logically impossible to run ### Expected The canonical GOLIVE harness should eventually be the single owner-journey controller that executes the 30 binding criteria against one exact persisted lineage. ### Actual `tests/golive/criterion-registry.ts` defines: ```ts export type MigrationStatus = "planned" | "pending"; ``` There is no executable/ready semantic state. `semanticReadiness()` is currently hard-coded: ```ts return { ready: 0, total: EXPECTED_CRITERION_IDS.length, pending: units, }; ``` `validateExecutionPlan()` refuses live execution while any unit is pending. Then `executeJourney()` still ends with: ```text live controller unavailable until all proof migrations are ready ``` Fresh Debian2 output at exact canonical main: ```text registry structure: 30/30 semantic readiness: 0/30 owner acceptance: 0/30 ``` ### Assessment The harness is not useless. Its architecture is now much better: - one criterion registry; - exact proof IDs; - persisted journey manifest; - barriers/prerequisites; - strict repository preflight; - owner-lifecycle locking; - recovery closure; - UI receipts; - destructive-smoke isolation. But today it is **a safe contract skeleton, not an executable canonical acceptance controller**. ### Impact No real 30/30 owner journey can be launched through the declared canonical command without first changing the readiness lifecycle/controller. ### Required correction Implement a real proof-unit lifecycle such as: ```text planned -> migrated/pending -> semantically-ready -> executed -> receipt accepted ``` and implement `executeJourney()` so it: 1. validates the exact persisted lineage; 2. executes only semantically-ready units in dependency/barrier order; 3. persists receipts and manifest stage transitions; 4. resumes safely after interruption; 5. fails closed on missing/ambiguous evidence; 6. never treats source-test success as owner acceptance. Do not weaken the 0/30 truth just to make the controller run. --- ## P0-2 — GOLIVE proof-environment declarations do not match the proof files This is a convergence-level binding regression that must be fixed before the new controller is usable. ### Architecture `proofEnvironment()` intentionally passes only: - declared manifest selectors; - declared `runtimeInputs`; - a small OS necessity allowlist; - `AWP_GOLIVE_EXECUTION=1` in live mode. That is the right fail-closed architecture. ### Problem Several proof files now require environment values that their registry definitions do not declare or declare under a different alias. Confirmed examples include: | Proof | File expects | Registry currently supplies | |---|---|---| | AC-01 UI | `AWP_OPERATOR_PASSWORD` | not declared | | AC-04..09 owner authoring | `AWP_OPERATOR_PASSWORD` | not declared | | AC-10..11 owner approval | `AWP_OPERATOR_PASSWORD` | not declared | | AC-28 self Project | `AWP_OPERATOR_PASSWORD` | no runtime inputs | | AC-19 review/merge | `AWP_OPERATOR_PASSWORD` | not declared | | AC-22 plan completion | `AWP_OPERATOR_PASSWORD` | not declared | | AC-23 live transitions | `AWP_OPERATOR_PASSWORD` | not declared | | AC-30 GOLIVE progress | `AWP_OPERATOR_PASSWORD` | not declared | | AC-15 ChangeSet | `AWP_PROJECT_REMOTE_URL` / `AWP_PROJECT_CHECKOUT_PATH` | selectors emit `AWP_REPOSITORY_REMOTE_URL` / `AWP_REPOSITORY_CHECKOUT_PATH` | | AC-18/19/27/29 | `AWP_PROJECT_REPOSITORY` | registry uses repository checkout selector alias | | AC-27/29/30 | `AWP_SELF_REPOSITORY_URL` | registry does not declare the alias the file consumes | There are additional controller-owned/test-only variables that must be explicitly categorized rather than inherited accidentally. ### Impact Even after semantic readiness/controller code exists, isolated proof execution will fail or run with the wrong inputs unless this registry/file contract is reconciled. ### Required correction Make the registry the one truth: - every proof environment dependency must be declared; - prefer one canonical env alias per manifest selector; - eliminate legacy aliases from proof files where possible; - add a static/behavioral test that derives each proof's required runtime inputs and rejects registry omissions; - explicitly distinguish controller-generated flags from user/runtime inputs. --- ## P0-3 — Live Debian3 dogfood is not running the converged source architecture ### Source target Current source expects: ```text public HTTPS/Tailscale ingress -> apps/web loopback listener -> ADR-0009 session cookie -> control-plane loopback listener -> authenticated owner API ``` ### Live observation Read-only Debian3 inspection found: ```text control-plane process: node apps/control-plane/dist/server.js cwd: /home/user/services/awp-i1/repo listener: *:8787 web process: node apps/web/dist/server.js cwd: /home/user/services/awp-i1/repo listener: 0.0.0.0:4173 operator password hash file: missing Tailscale Serve status: {} ``` No current user systemd units for the new dogfood services were present. K3s still has AWP infrastructure/workspace namespaces and service pods, but the public/control-plane topology is the older deployment. ### Assessment This is not evidence that the new source architecture is wrong. It means it has **not yet been live-proven**. ### Impact - ADR-0009 is source-green, not dogfood-green; - HTTPS/loopback boundary is not live-proven; - authenticated owner GOLIVE cannot be credited; - current 0/30 remains correct. ### Required correction Only after the GOLIVE controller/bindings are coherent: 1. provision the owner-controlled Argon2id operator hash; 2. deploy the exact green main revision; 3. bind privileged processes loopback; 4. expose web via Tailscale HTTPS ingress; 5. verify callback ingress; 6. run the canonical authenticated owner acceptance journey. Do not invent/copy an operator credential automatically. --- # 4. Binding architecture / owner-pain gaps that remain ## P1-1 — Typed configuration/PostgreSQL authority is still mostly a specification, not the production mechanism ### Binding requirement The owner-pain configuration chain requires: - PostgreSQL as configuration authority; - typed definitions/overrides; - explicit bootstrap allowlist; - API/read/write/audit path for tunables; - Workspace projection rather than alternate authority; - every mechanism with a real off-switch. ### Actual `packages/config` currently contains a small in-memory registry and pure precedence resolver. It is imported by its own tests but is not the production configuration authority. There is no current production: - ConfigurationDefinition/Override persistence repository; - authoritative configuration API; - audit trail for setting mutation; - systematic off-switch registry. Control-plane composition continues to consume a broad set of environment variables. Some are legitimate bootstrap/secret plumbing, but several are runtime tunables rather than bootstrap identity, for example workspace/storage/profile, model/account defaults, delay/failure/fixture switches and project required-check defaults. The binding named regression arms are absent: ```text config-authority-is-postgres-only bootstrap-config-allowlist-is-closed no-config-surface-without-api workspace-config-is-projection every-mechanism-has-an-off-switch ``` ### Assessment This is a real architecture gap, but it should **not** be solved by dragging the full future Settings/policy product into I1. ### Required correction Implement the minimum I1 configuration authority necessary to satisfy the binding invariant, or make an explicit owner-authorized amendment narrowing which configuration surfaces are I1-active. --- ## P1-2 — VCS merge-conflict autopilot required by the pain invariant is not present ### What is strong Current repository/merge source correctly: - binds repository identity; - stores immutable publication/target identity; - rechecks target before merge; - fails closed when target changed; - reconciles ambiguous retryable provider outcomes; - protects trusted merge credentials; - keeps Git vocabulary out of the approved user surface. ### What is missing The binding VCS pain invariant says a merge conflict should become an AWP-owned resolution strategy/new Attempt with precise context rather than a user Git decision. Current merge helper reconciles retryable provider failures such as unavailable/rate/protocol ambiguity. A Git conflict / stale-target response is fail-closed but does not schedule a corrective conflict-resolution Attempt. No implementation/test was found for: ```text conflict-resolves-without-user branch-strategy-is-deterministic ``` ### Assessment “Safe refusal” is better than unsafe guessing, but it is not the approved autonomous user experience. ### Required correction Model a merge-conflict recovery result as execution work: ```text trusted merge detects conflict -> preserve exact candidate and target observations -> create typed correction/resolution Attempt -> provide conflict context without Git mechanics as owner decision -> produce new candidate revision -> rerun evidence / independent review / trusted Merge ``` --- ## P1-3 — FactoryRun detail tells the owner to review a stage that is actually automated This is a live product-semantic drift. `apps/web/src/approved-live.ts` currently maps Task `review` to: ```text kind: decision summary: Review action required humanActionRequired: true next action: Review the candidate ``` `render-factory.ts` then renders “Owner action required.” But the actual current lifecycle is: ```text Task enters review -> trusted publication -> ensureIndependentReview() -> reviewer AgentRun/Attempt created automatically -> reviewer callback -> required-check refresh -> automatic Merge continuation ``` Therefore generic Task status `review` is **not** itself an owner authority boundary. There is an additional internal inconsistency: `correction` is grouped into `humanActionRequired: true` while its own next action is automatic correction work. ### Required correction Attention must be derived from actual Decision/Approval/policy authority state, not from a generic lifecycle label. For default I1: ```text review -> AWP/reviewer agent owns next action correction -> AWP owns correction scheduling unless explicit policy pause exists ``` Only a real authority-bound Decision/Approval should render “Owner action required.” --- ## P1-4 — U1 “Needs Your Attention” is still a placeholder rather than an authoritative projection The approved U1 brief explicitly requires the Project overview to answer: ```text What needs my attention? ``` and each attention item should include severity/context/direct action. Current production Project renderer instead hardcodes: ```text count = 0 No owner action required C1 exposes no active Decision/Approval attention items. Full Attention projection activates with its application contract ``` The panel has the correct visual location but does not yet derive attention from authoritative application state. At the same time, other parts of the same screen can surface actionable conditions such as: - no Subrouter account available for a real FactoryRun; - draft Plan ready for owner approval/start. Those are not reflected in the Attention panel. ### Required correction Either: - project actual I1 Decisions/Approvals/blocking owner prerequisites into the panel, or - explicitly amend U1 semantic scope if Attention is not meant to be active in I1. Do not leave a binding panel permanently hard-coded to zero while actionable owner prerequisites exist elsewhere. --- ## P1-5 — Verification/Done pain contract and the increment roadmap still need an explicit scope reconciliation Current I1 evidence is substantially stronger than before: - exact candidate digest binding; - stale evidence rejected; - repository-required evidence owned by trusted provider boundary; - self-report cannot directly make Task Done; - Task completion requires verified/reviewed trusted Merge; - replay reuses the existing durable candidate/evidence rather than ritual duplication. However, the strongest owner-pain wording requires typed resolvable references to real CI execution and acceptance-run objects. Those typed entities/ports are not currently part of the I1 evidence model. The realization roadmap places the fuller verification/CI control plane later. ### Risk The project can end up with two incompatible binding interpretations: ```text Pain invariant: typed CI + acceptance refs are mandatory before Done Roadmap: richer CI/verification authority productizes later ``` ### Required correction Make the scope decision explicit: - implement the minimum typed references required in I1, **or** - amend the pain-invariant applicability so I1's exact-candidate/provider evidence is the temporary binding minimum and the richer typed references activate with the later increment. Do not silently claim the stronger invariant is already satisfied. --- ## P1-6 — Generic policy/HITL pain contract is stronger than the implemented I1 policy seam The important default behavior is already correct: - no invented owner Approval during default delivery; - automatic reviewer/merge/recovery path; - zero Approval rows in default full chain. But the generic pain-invariant arms are not fully realized: ```text request-preapproves-full-chain approval-points-are-policy-declared default-policy-has-no-hitl-hooks pause-requires-authority-boundary hitl-hooks-are-configurable-per-project ``` The roadmap puts broad Decisions/Approvals/Autonomy productization later. ### Required correction As with configuration/verification, resolve applicability explicitly rather than either: - ignoring the pain invariant, or - pulling the entire future policy editor into I1. --- # 5. Governance / specification drift ## P1-7 — The current execution plan is behind the actual project state `docs/plans/INDEX.md` still tells current agents to: ```text converge repaired autonomy + ADR-0009 reconcile dogfood/recovery work make canonical main truthful ``` Those steps are now complete. The real current sequence is closer to: ```text repair GOLIVE controller/readiness/bindings close remaining I1 pain gaps reconcile binding docs redeploy exact main run authenticated owner journey advance GOLIVE from fresh receipts ``` The same Plans Index also points “current durable review/gate context” to: ```text docs/progress/2026-08-23-awp-direction-drift-audit.md ``` That file does not exist on current canonical main. ### Impact A new agent following the binding Plans Index can waste effort re-converging work that is already landed or look for a nonexistent audit file. ### Required correction Update the current-execution section and point it to current durable sources, including this audit and `2026-08-24-final-main-convergence.md`. --- ## P1-8 — The binding durable-workflow architecture document falsely says the implementation is still missing The target rules in `durable-workflow-transaction-seam.md` remain correct. Its **Current Implementation State** is not. It still says the following are “still not present” and Required Proof remains open: - `workflow_step_outcomes`; - application step-transaction helper; - outbox dispatcher; - stronger transaction proof. All of those are now implemented and proven on canonical main. ### Impact This is particularly dangerous because the document is binding architecture. A future agent could “fix” already-correct source or conclude that I1 durability is still structurally absent. ### Required correction Update only the implementation-status section/evidence links. Do not weaken the target rules or Required Proof. --- ## P2-1 — The latest dogfood handoff is obsolete but is not marked superseded `docs/progress/2026-08-24-session-handoff-i1-dogfood.md` still says: - branch ahead of origin and dirty; - interrupted four-file WIP; - N2 state migration unapproved; - FOUNDATION recovery/repository identity open. Those conditions are no longer current. The work was preserved, repaired, tested, converged and landed to main. ### Required correction Keep the file as historical evidence, but add a prominent superseded header pointing to final convergence/current audit. --- ## P2-2 — Binding U5 visual reference still shows a manual Merge action after the autonomy amendment This is a design-authority contradiction rather than a current production bug. `docs/mockups/i1/u5-ready-to-merge.html` is declared FINAL / OWNER-APPROVED and still contains a primary **Merge** button / manual protected-transition copy. Current production renderer correctly follows the later default-autonomy authority and shows automatic trusted Merge instead. ### Impact Two binding authorities disagree: ```text old deterministic visual reference: owner clicks Merge later pain/governance authority: default full chain auto-merges current production source: auto-merges ``` ### Required correction Annotate/amend the U5 deterministic reference so the manual default Merge affordance is explicitly superseded. Do not regress production back to manual Merge simply to match the old HTML. --- ## P2-3 — Legacy `apps/web/src/live.ts` still contains manual Review/Merge forms The older renderer still contains: - `Approve ChangeSet` - `Merge approved ChangeSet` However, current production detail routes use `approved-live.ts` / approved renderers. `server.ts` imports only `renderLiveProjectList` from the legacy file for the Projects list. Therefore this is **not currently a live owner-path regression**. It is still semantic debt because tests/imports keep the old renderer alive and a future refactor could accidentally reactivate it. ### Required correction Quarantine/remove/rename the legacy detail renderer or make its non-production status mechanically explicit. --- ## P2-4 — AC-20 acceptance wording remains weaker than the implementation AC-20 currently focuses on reviewer identity differing from authoring identity. The implementation is correctly stronger: - reviewer role is `reviewer`; - reviewer AgentRun differs from coder AgentRun; - reviewer Principal differs from coder Principal; - assigned reviewer Attempt is required; - candidate digest must match exactly; - agent-assigned Review cannot be owner/coder-approved via the manual review endpoint. ### Required correction Strengthen the GOLIVE criterion so future implementations cannot satisfy independent Review with merely “a different Principal.” --- # 6. UI / vision alignment review ## 6.1 U1 structure is largely going in the right direction Current production Project surface preserves the important owner-approved hierarchy: ```text Current Goals / Needs Your Attention / Blockers Active Plans / FactoryRuns / Recently Completed five-column Queue / Next Up Project health/footer ``` It also preserves: - compact information density; - dark navy shell; - restrained accent treatment; - no hero/KPI dashboard drift; - direct Project tabs/navigation; - account selection for launching real Plans; - explicit no-fixture fallback when no account is available. The main U1 problem is not visual style drift. It is the incomplete semantic Attention projection described above. ## 6.2 U2-U6 source generally follows the intended lifecycle Strong source traits include: - FactoryRun / AgentRun / Attempt provenance; - failure/retry and WIP visibility; - ChangeSet exact candidate/evidence display; - independent Review provenance; - automatic trusted Merge in actual production source; - read-only terminal outcome. The notable semantic mismatch is FactoryRun `review` being presented as owner action required when the default architecture automatically assigns a reviewer AgentRun. ## 6.3 No broad visual/product redesign is needed Do **not** restart U1-U6 design from scratch. The required work is surgical semantic correction and final live parity proof. --- # 7. Architecture direction review ## 7.1 Domain authority remains correct The important separation still holds: ```text AWP owns: Project / Goal / Plan / Task lifecycle FactoryRun work-graph identity AgentRun / Attempt provenance ChangeSet identity VerificationEvidence / Review / findings trusted publication / merge decisions authoritative PostgreSQL lifecycle state providers own replaceable mechanics: Fabro Factory mechanics ACP agent session mechanics Subrouter account/model routing DBOS durable workflow mechanics Kubernetes isolated compute/workspaces GitHub repository and required-check mechanics ``` No evidence was found that provider-native identity has become business identity again. ## 7.2 Trust boundary is directionally strong Source correctly treats: - AgentRuns as untrusted execution; - reusable Git publication authority as trusted control-plane concern; - model/account authority through provider references; - browser identity as a session resolved in the control plane; - System authority separately from Human authority; - Workspace compute as disposable while accepted WIP persists. The main trust problem is now deployment lag, not the current source design. ## 7.3 Durability direction is now credible This is one of the strongest improvements since the prior review. The previously documented DBOS checkpoint/domain-commit crash window now has an explicit seam and exact fault proof instead of assumptions. ## 7.4 No architectural reason to abandon or redesign AWP was found The remaining issues are implementable within the approved design. They do not justify a new architecture or product rewrite. --- # 8. Done vs source-complete-but-unproven vs still missing ## Done / strongly implemented on canonical source - authoritative core domain/persistence foundations; - one FactoryRun per approved PlanRevision/work graph; - dependency-safe Task dispatch model; - attempt/account/model provenance; - real Subrouter/Fabro/ACP/DBOS provider composition seams; - native ACP runner state versioning/recovery corrections; - durable Workspace checkpoint/retry/cleanup logic; - trusted repository publication boundary; - repository-required checks fail closed; - independent reviewer AgentRun/Attempt; - automatic default trusted Merge; - ADR-0009 operator sessions; - DBOS step marker / outbox dedupe seam; - exact real PostgreSQL SIGKILL durability proof; - canonical branch convergence; - truthful GOLIVE 0/30; - no broad I2-I9 feature creep. ## Source-complete or materially implemented, but not live-proven - authenticated HTTPS owner ingress; - loopback privileged control-plane topology; - latest agent runner image/provenance; - canonical owner UI U1-U6 on the new topology; - selected real Subrouter account/model through the full owner journey; - native ACP failure/retry path in the one canonical owner run; - automatic independent review + Merge across actual dogfood restart; - current exact-main self-change through AWP itself. ## Still missing / incomplete - executable canonical GOLIVE controller/readiness lifecycle; - complete proof-registry environment bindings; - deployment of current exact source to dogfood; - real 30/30 owner acceptance; - production typed/Postgres configuration authority required by the binding pain contract; - autonomous merge-conflict corrective Attempt path; - correct default-autonomy semantics in FactoryRun Review attention; - authoritative U1 Needs Your Attention projection; - explicit I1 vs later-increment contract for typed CI/acceptance evidence references; - explicit I1 vs later-increment contract for generic HITL/policy configurability; - current-plan / binding-status document reconciliation; - strengthened AC-20 wording. --- # 9. Ordered next work ## Phase 1 — Make the acceptance control plane internally coherent 1. Add a real GOLIVE proof lifecycle/readiness state. 2. Reconcile every proof file's required inputs with the criterion registry. 3. Add a mechanical registry-vs-proof-input gate. 4. Implement the canonical `executeJourney()` controller. 5. Preserve journey locking, exact manifest identity, barriers and receipts. 6. Keep owner acceptance 0/30 until actual receipts exist. This is the immediate P0 source work. ## Phase 2 — Close remaining binding I1 semantic gaps 7. Implement/narrow the I1 Postgres/typed configuration authority. 8. Add autonomous merge-conflict correction Attempt behavior. 9. Correct FactoryRun Review/Correction owner-attention semantics. 10. Make U1 Attention authoritative or explicitly amend its I1 scope. 11. Reconcile Verification/Done typed-reference applicability. 12. Reconcile generic policy/HITL applicability without pulling the full future editor into I1. 13. Strengthen AC-20. ## Phase 3 — Repair governance truth before another autonomous implementation wave 14. Update `docs/plans/INDEX.md` current execution. 15. Update durable-workflow “Current Implementation State.” 16. Mark stale dogfood handoff superseded. 17. Amend U5 visual authority for automatic default Merge. 18. Quarantine/remove the legacy manual-Merge renderer. These are not just housekeeping: they prevent future agents from following obsolete authority. ## Phase 4 — Deploy and prove 19. Re-run exact-head buildbox/architecture/security gates. 20. Provision the owner-controlled operator password hash. 21. Deploy the exact candidate to Debian3 using loopback + HTTPS/Tailscale ingress. 22. Verify live source revision, image digest, Postgres migrations and provider configuration. 23. Execute the canonical authenticated owner journey. 24. Advance each AC checkbox only from fresh evidence from that same architecture. 25. Do not open I2 until 30/30 is genuinely earned. --- # 10. What should not happen next 1. Do not call I1 done because `pnpm check` is green. 2. Do not convert “registry structure 30/30” into acceptance 30/30. 3. Do not bypass the unfinished canonical controller by manually running disconnected proofs and aggregating them as completion. 4. Do not deploy the old public-control-plane topology again. 5. Do not invent/copy an operator password from another credential. 6. Do not reintroduce default owner Merge. 7. Do not interpret generic Task `review` as an owner decision without an actual authority boundary. 8. Do not leave GOLIVE proof env dependencies implicit. 9. Do not treat safe merge-conflict refusal as the final owner experience if the binding pain invariant requires autonomous correction. 10. Do not silently ignore the config-authority binding invariant. 11. Do not pull the full I3 policy editor or I5 CI product forward just to satisfy ambiguous cross-increment wording; resolve the contract explicitly. 12. Do not restart the U1-U6 visual design. 13. Do not treat stale historical handoffs as current execution instructions. 14. Do not let the binding durability document continue telling agents that already-implemented core machinery is missing. 15. Do not begin I2-I9 feature expansion before the I1 journey is live-proven. --- # 11. Final assessment ## Is AWP going in the right direction? **Yes.** The recent progress is substantive rather than cosmetic. The project corrected several of the hardest earlier architectural mistakes: - authentication is real; - default delivery is autonomous again; - independent Review is truly agent-backed; - DBOS crash safety has a concrete transaction seam and destructive proof; - accepted WIP is durable; - trusted publication is fail-closed; - source branches have converged; - canonical main no longer lies about acceptance. Those are exactly the kinds of corrections that make AWP more like the intended durable agentic software-delivery control plane. ## Is there vision drift? **No broad product-vision drift was found.** There are, however, **local semantic and authority contradictions** that should be corrected: - FactoryRun Review shown as owner action despite automated reviewer AgentRun; - U1 Attention is a placeholder rather than an authoritative projection; - U5 binding mockup still depicts manual Merge despite later automatic-Merge authority; - config and merge-conflict pain invariants are not fully realized; - cross-increment Verification/HITL wording needs explicit applicability decisions. These do not justify changing the architecture; they justify finishing it carefully. ## Is there plan drift? **Yes.** The plan/status documentation now lags the implementation materially: - current execution still tells agents to perform convergence already completed; - a referenced current audit file is missing; - the latest dogfood handoff describes obsolete dirty/open state; - the binding durable-workflow document says implemented/proven machinery is still absent. This should be fixed before the next large autonomous work wave. ## Is development doing what it is supposed to do? **Mostly yes at the core architecture level; not yet at the final owner-proof/live-operation level.** The current equation is: ```text GOOD: converged source + auth + autonomous trusted Merge + independent reviewer AgentRun + durable DBOS step markers + outbox dedupe + real crash proof + trusted publication/checks + preserved WIP + truthful 0/30 STILL REQUIRED: executable GOLIVE controller + coherent proof bindings + remaining owner-pain gaps + current binding docs + exact current deployment + real authenticated 30/30 owner journey ``` ## Bottom line **Continue this direction. Freeze feature expansion. Finish I1 convergence at the proof/live/semantic layer.** The project is in a substantially better position than at the previous review. The remaining problems are important, but they are now mostly **closure problems inside the intended architecture**, not evidence that the product itself is being built in the wrong direction.