# HOME23 Drift Analysis from Session History

Last updated: 2026-03-31
Purpose: explain, from actual session history plus durable workspace docs, where implementation drifted from the original HOME23 harness brief.

## Blunt answer

The project did **not** fail because the original ask was vague.
The original ask was clear enough, and a durable supporting doc already existed:
- `cosmo-home_2.3/workspace/HOME23_COSMO23_EVOBREW_REUSE_AUDIT_AND_EXTRACTION_PLAN.md`

The drift happened because active implementation momentum became organized around:
- wave completion
- canonical platform build-out
- visible runtime/control-plane progress

more than it remained organized around:
- explicit source-system parity with Evobrew / COSMO 2.3

## What the session history showed

- the surviving active COZ conversation thread begins after compaction with a wave-heavy scaffold summary
- implementation then proceeds through Waves 5–10 using a strong build cadence
- explicit re-anchoring to Evobrew / COSMO 2.3 parity appears later as a corrective user move
- this exposed that the project looked more complete than it actually was in the hardest parity dimensions

## What the broader workspace docs proved

The source-law already existed on disk. It explicitly said HOME23 should:
- reuse hard: provider schema, OAuth/token flow, model catalog, run continuation concepts, setup validation
- adapt carefully: settings UX, launch/run generation, security posture, OpenClaw seam, web control plane
- rebuild new: instance creation, bootstrap generation, operator/front-door IA, HOME23 execution contract

So the problem was not lack of intent or lack of planning.
The problem was failure to keep that law as the live acceptance framework for every tranche.

## Practical drift pattern

1. scaffold/contracts/control-plane work created real substrate
2. substrate progress started to substitute for parity progress
3. provider/runtime work initially used simplified abstractions
4. only later did the project re-assert the need to inherit mature source-system behavior

## Correction now in force

Future work should not be declared complete unless it names:
- which source-system capability it matches or advances
- whether the work is reuse, adaptation, or new HOME23 build
- what parity remains incomplete

## Bottom line

The project is not fucked.
The drift was real, understandable, and recoverable.
The fix is disciplined source-parity execution from here forward.
