Transfer Project Context — State, Not Transcript
Transferring a project means transferring its state: what's done, what's decided, what's frozen, what's left — at a fraction of the transcript's size.
Overview
The instinct when moving project context is to bring everything — and everything is exactly what doesn't fit and isn't needed. A project's transferable state is small: the pattern that was chosen, the schema that is frozen, the partitions already migrated, the runbook still unwritten. This setup loads a zero-downtime migration project in Detailed fidelity, where the package carries the expand-and-contract decision, both hard constraints, the night-window agreement, and the working assumption about schema caches — everything the next session must know, nothing it doesn't.
Workflow
-
Separate state from story
The journey to the decision stays behind; the decision travels.
-
Carry the constraints hardest
Frozen schemas and uptime rules are what new sessions violate first — the package locks them in.
-
Mark the phase boundary
Completed phases under CURRENT STATE, the rest under PENDING — progress is unambiguous.
Why This Works
- State transfers at a fraction of transcript size — and fits where transcripts don't
- Explicit constraints survive the session boundary that erases implicit ones
- Phase clarity prevents the new session from redoing finished work
Best for
- Long-running technical projects
- Work with hard constraints (frozen schemas, uptime requirements)
- Migrations, rollouts, and multi-phase plans
Not for
- Transferring the project's permanent conventions — that's the Project Context Builder's future territory
- Estimating whether the transcript would fit anyway — that's the Context Window Estimator
Use cases
- Moving an infrastructure project across sessions
- Carrying frozen constraints that must never be relitigated
- Compressing days of discussion into transferable state