AWP Incremental Delivery Plan

Full specification first

full architecture/domain/workflow/UI target specs
  + HTML companions / diagrams / cross-links
  + Decisions / ADRs
  + Increment Realization Matrix
        ↓
I0 → I1 → I2 → … → I9
        ↓
dogfood / learn / explicitly amend target when evidence warrants

See Full Specification Ratification and Increment Realization Matrix.

I0 — Foundation / self-hosting substrate

Activate the shared runtime/module skeleton, PostgreSQL state/transactions, events/audit, trust/config/secrets, adapters, minimal Git/account/model providers, K3s WorkspaceProvider/isolation, DBOS durable execution, ARC/GitHub check substrate, telemetry and R1 architecture conformance.

Rich Planning, full CI product, Release/CD, Cluster UI and enterprise reliability remain later realization even though their target seams are already specified.

I1 — First complete vertical slice

Project
  → Plan
  → Task
  → FactoryRun
  → AgentRun / Attempt on K3s
  → durable WIP / ChangeSet
  → focused evidence + required checks
  → independent Review
  → trusted Merge

The run must be durable, observable, retryable, isolated and recoverable. No normal agent execution relies on the workstation.

Approved high-fi set: U1 Project/Plan/Task; U2 active FactoryRun; U3 waiting/failure/retry; U4 ChangeSet/Review; U5 ready-to-merge; U6 merged/completed.

R2: AWP's threat model is required before privileged dogfood.

I2 — Real Planning

Activate Project onboarding, VISION-driven structured Planning, Simple/Expert participation, ProjectPlanningDefaults, quality/CI/delivery recommendations, connection interruption/resume, readiness and Start/Schedule/Park.

I3 — Generic autonomy, Decisions and Approvals

Generalize Policy, Approval, cross-domain Decision, Project Decision Log, ADR projection, authority provenance and supersession/impact propagation.

I4 — Full Factory observability UX

Deepen the I1 Factory/Agent seam with graph visualization, live detail, chat, tool activity, diffs/files/checkpoints, retries, relationships, artifacts and cost/token information.

I5 — CI control plane

Activate change classification, CI planning/invariants, VerificationAuthority, EvidenceLedger/reuse/invalidation, provider ingestion, resolver and optimizer. R4 compatibility gates become first-class for declared stable boundaries.

I6 — Release / Environment / Deployment

Activate Artifact, Release, Environment, Deployment, promotion, health, rollback and deployment resolution. R3 SBOM/provenance/signing becomes full product semantics.

I7 — Cluster product surface

Productize the K3s substrate already in use: machine lifecycle, capabilities, capacity, queues, health, maintenance and placement explainability.

I8 — Self-healing operations

Incident → deterministic resolver → agentic resolver when needed → verified fix → reusable resolver proposal → normal review workflow

I9 — External / enterprise productization

Organizations/users, expanded RBAC/tenancy, quotas, retention, audit export, backup/restore, upgrade/migration, stable public API/SDK, installation/supportability and formal ReliabilityPlan/SLO/error-budget behavior.

R5 remains the lowest dogfood priority. It is fully specified now but operationally parked until I9.

Accepted practice placement

Practice	Specification	Operational realization
R1 Architecture conformance	Now	I0 onward
R2 Threat modeling	Now	AWP before I1; Planning capability I2
R3 SBOM + provenance	Now	when artifacts distribute; full product I6
R4 Contract compatibility	Now	stable-consumer trigger; full CI I5
R5 Reliability/SLO	Now	I9

Two different gates

Before I0 implementation

Full target architecture/domain/workflow/UI specs + HTML, cross-links, Decisions/ADRs, whole-product IA and I0–I9 realization mapping are complete and reviewed.

Before each increment

Confirm realization boundary, preserve future invariants, approve exact high-fi shipped states, make temporary dogfood shortcuts explicit, then implement the complete end-to-end increment and dogfood it.