AWP Plans

Full-specification-first, incremental realization

Binding product-development policy: AWP specifies the complete target product and architecture before implementation materially begins, while Increment 0–9 remain the implementation and dogfooding boundaries.

Ratified2026-08-19Vision-drift protection
Core rule: increments decide when behavior becomes operational. They do not decide when the project is allowed to know what that behavior is supposed to become.

Ratified decision

FULL PRODUCT / ARCHITECTURE SPECIFICATION
  complete target-state behavior and seams
  + complete human HTML
  + cross-links / diagrams / Decisions
  + explicit Increment Realization boundaries

        ↓

INCREMENTAL IMPLEMENTATION
  I0 → I1 → I2 → … → I9

        ↓

DOGFOOD / LEARN / EXPLICITLY AMEND

This replaces the earlier interpretation that later domains could remain mostly unspecified until their implementation increment.

What “full specification” means

Before Increment 0 implementation materially begins, the specification system describes the complete intended target state across architecture, domains, workflows, UI/pages and machine-readable contracts.

AreaRequired target-state content
ArchitectureTopology, module boundaries, persistence authority, transactions, durable execution, trust, configuration, providers/adapters, execution, CI/release/deployment boundaries.
DomainsPrimitives, identity, ownership, relationships, lifecycle, invariants, authorization, persistence, failure/recovery, provider mappings.
WorkflowsEntry/exit, state transitions, actors/authority, failure/retry, evidence, handoffs and cross-domain effects.
UI/pagesInformation architecture, journeys, data truth, actions, complete material states, responsiveness, accessibility, URL truth and linked contracts.
Contracts/schemasOwnership, compatibility boundary, versioning/migration and adapter/provider mapping.

What may remain implementation-local

Private algorithms, SQL index tuning, provider-version request plumbing, measured concurrency constants, profiling-driven performance tuning and other details may remain later implementation decisions when they can change behind an already-defined seam without changing product behavior or architecture.

Test: if changing it later alters a behavior, domain seam, ownership rule, trust boundary, compatibility promise, workflow, page behavior or future-increment contract, it belongs in the full spec now.

Required structure in every canonical spec

Target State
Invariants From Day 1
Increment Realization
Current Implementation State
Deferred Realization
Temporary Dogfood Behavior
Decisions / ADRs

Early implementation is a compatible subset of the final model, never a separate temporary model.

Increment boundaries remain binding

IncrementOperational scope
I0Foundation / self-hosting substrate
I1Project → Plan → Task → FactoryRun → AgentRun → ChangeSet → Review → Merge
I2Real Planning
I3Generic autonomy / Decisions / Approvals
I4Full Factory observability UX
I5CI control plane
I6Release / Environment / Deployment / CD
I7Cluster product surface
I8Self-healing operations
I9External / enterprise productization + formal reliability/SLO machinery

See the Increment Realization Matrix for capability-level boundaries.

Human HTML authority

<spec>.md      canonical diff/agent source
<spec>.html    complete human-readable presentation

The HTML contains the complete contract, diagrams, stable links, increment mapping, Decision/ADR links and mockups where applicable. INDEX.html remains the human root.

UI and high-fidelity design

Full page behavior and product information architecture are specified now. The shared shell/navigation/design language must be coherent before the first user-facing implementation. Exact high-fidelity states are approved before the increment that implements them, including materially different failure, waiting, permission and responsive states.

Anti-drift rule

implementation discovers a conflict
  → open/supersede Decision
  → impact analysis
  → amend target spec
  → amend increment matrix if timing changes
  → update mockups if affected
  → implement

Code never silently becomes the new design authority.

Full-specification completion gate

Before Increment 0 implementation materially begins: full architecture/domain/workflow/UI target specs exist, all active specs have HTML companions, INDEX.html links them, increment mapping is explicit, Decisions/ADRs are linked, and Increment 0/1 operational boundaries are unambiguous.

Immediate next work

1. Complete the full spec inventory.
2. Write all target-state specs.
3. Generate linked HTML + diagrams.
4. Complete/cross-check the Increment Realization Matrix.
5. Run contradiction / missing-seam / traceability review.
6. Produce Increment-0/1 high-fi against the full baseline.
7. Consolidated spec + high-fi review.
8. Begin Increment 0.