A project is the only top-level entity. It owns the canonical flow definition, the execution slices, and the permanent history of approvals and artifacts.
The kernel exists to prevent fragmentation: no “parallel realities”, no duplicated specs, no hidden side channels. There is one execution truth.
Why it matters to clients
It becomes possible to audit what was agreed, what was delivered, and what changed — without relying on conversations.
This reduces delivery risk and prevents rework caused by reinterpretation.
Step 02
Slices: contract units
Scope control
A slice is an execution contract. One slice introduces exactly one new capability. Past slices are immutable; changes happen only through new slices.
This rule eliminates “silent scope expansion”. If the meaning changes, the contract changes — and the history records it explicitly.
Allowed
- Archive a slice (history preserved).
- Create a new slice for a semantic change.
- Keep one active slice as the execution focus.
Disallowed
- Deleting slices.
- Changing meaning inside finalized history.
- Parallel “active” execution contracts.
Step 03
Stages: atomic steps
Ordering
Within a slice, work is divided into ordered stages. Each stage is atomic: it produces artifacts, is reviewed, and is approved before the next stage begins.
This prevents “partial completion” from becoming the new baseline. A stage is either finalized or it is not complete.
Client implication
You can see exactly where the project is: which stage is active, what outputs exist, and what is awaiting approval.
No ambiguous status labels. The stage pipeline is the status.
Step 04
Artifacts: stage-bound outputs
Evidence
Artifacts are the measurable outputs of a stage: markdown, structured data, or files. They are owned by the stage and form a permanent execution record.
Artifacts are not “notes”. They are contractual evidence. Once a stage is finalized, artifacts become read-only.
Examples
Requirements snapshots
Decision statements
Approved UI references
Data models
Acceptance criteria
Client-ready summaries
Step 05
Done Summary & approval
Final truth
A stage is not complete when “work was done”. It is complete when its truth is finalized: a Done Summary is written and formally approved.
Dual approval prevents drift: the execution owner finalizes the output, and the project viewer/client confirms it reflects reality.
What this prevents
“We assumed you meant …”
“It was discussed somewhere.”
“We can’t reconstruct why this exists.”
Step 06
Decision & invariant memory
Memory
DevFactory stores explicit decisions and invariants as durable project memory. Decisions can be superseded; invariants are immutable constraints.
This prevents “decision entropy”: the gradual loss and repeated re-debate of settled facts.
Decision
A choice made for the project that can change via a new slice, with explicit lineage.
Invariant
A non-negotiable constraint that remains stable across the project history.
Step 07
ProductSpec assembly
Execution contract
When the project reaches objective readiness, DevFactory assembles a deterministic ProductSpec from approved artifacts and finalized Done Summaries.
ProductSpec is not a plan and not a task list. It is a locked execution contract snapshot. Assembly happens once and is not re-assembled.
Step 08
Build Context contract
Build discipline
Build Context defines hard development rules: stack constraints, allowed patterns, refactor discipline, and test rules. It is immutable and changes only via a new slice.
This ensures execution quality is governed by contract, not by momentary preference or team variance.
DevFactory is designed for safe pauses. Because decisions, artifacts, and approvals are stored structurally, the project can be resumed months later without interpretation drift.
The assistant can help preserve continuity by presenting the current execution context and constraints, but ownership and approval remain human-controlled.
Step 10
Reporting / audit trail
Evidence
Because the system is contract-driven, it can generate read-only reports from artifacts, Done Summaries, and decisions. This enables client reporting without duplicating logic or rewriting history.
The result is audit-ready: what was agreed, what was approved, and what was delivered are all queryable in one place.
This is why delivery becomes predictable
When execution is constrained by contracts, decisions, and approvals, projects stop drifting. Progress becomes measurable, resumable, and explainable — even long after the original context is gone.
