From planning to execution - without losing your mind mid-session
FRAME sessions start fresh by design. But some decisions should survive the /clear. How project-context.md closes the gap between planning and execution.
Every FRAME session starts fresh. That’s by design - you /clear the context, resume where you left off, and the engine re-loads the state it wrote to disk. Project goal, breakdown, current unit. It works.
What it doesn’t restore is the stuff that never made it into a file. The decisions that were obvious at planning time and got answered once, correctly, in session one - then silently re-derived from scratch in session two.
I hit this building a test website with FRAME. The project-planner had done its job: backlog generated, work items prioritised, ready to execute. First implementation session went well. Second session, new context window - and within the first few exchanges, I was already re-establishing things that should have been settled. The model had inferred a direction. Not wrong, exactly. Just not what we’d decided.
The specific example that made it obvious:
## Aesthetic
Modern, dark-mode-friendly. Reference: Vercel / Linear / Anthropic.com.
Not a template - should feel like a real agency.That’s not a SHAPE question. It doesn’t belong in PROJECT.md - that’s for goal, stack, constraints. It’s not a unit in BREAKDOWN.md. It’s just a decision that applies to every session for the life of the project. And there was nowhere for it to live.
So I added project-context.md.
The file lives at .frame/project-context.md. The engine reads it silently at every /frame load and /frame resume and injects it at the start of SHAPE. The model has it in context before the first question. No re-establishing, no re-deriving.
The content is entirely user-owned. It’s not generated by the engine - you write it, or the project-planner produces a first draft from the conventions pass it runs during EXPLORE. Either way, you control what goes in. Architectural decisions, naming conventions, tone guidelines, third-party constraints, reference aesthetics. Anything that should be true of every session.
The project-planner integration is the clean part. Before this, planning and execution were loosely coupled - the planner produced a backlog, and you carried the context in your head from there. Now there’s an explicit conventions pass during EXPLORE: one open question, one answer, written to SESSION.md. At the BUILD gate, the planner offers to produce project-context.md from everything it learned. You get a document rather than a memory.
The limitation is real and worth naming: project-context.md is only as good as what you put in it. The engine can’t know what should be project-wide versus session-specific - that judgment is yours. And if the file grows without discipline, you’ve just moved the noise from session start to a persistent document.
The right content is decisions, not descriptions. “Dark-mode-first, reference Vercel” is a decision. “The site has a homepage, about page, and contact form” is a description - it belongs in BREAKDOWN.md, not here.
The mechanic is simple enough that I’m surprised it took this long to add. The gap wasn’t technical - it was a missing state file in the right place. Every session after the first was implicitly assuming the model would re-derive project conventions from code it could read and history it couldn’t.
It won’t re-derive what it can’t see. Write it down once.