FSE is a methodology, not a framework. There is nothing to install, nothing to configure, no SDK to import. The work of adopting FSE is reading three documents, copying three templates into your project, and changing how you run sessions. Most teams have it in place before the day ends.
This is the order. Skipping steps doesn't accelerate adoption — it produces the appearance of adoption without the underlying discipline.
Start with FSE.md in the core repository. It's the single document that defines what FSE is and how a session runs. Read it before you do anything else. If parts feel obvious, that's fine — the value of writing it down is that the obvious things stop getting skipped.
Copy FSE.md, FSE_STATE.md, and FSE_DISCOVERY.md from the templates/ folder into your project. These are your bedrock files. They live alongside your code and get read at the start of every session.
If you're using an AI assistant, paste the contents of ONBOARDING_PROMPT.md into your first session. It walks the assistant through auditing your current state and populating the bedrock files from what already exists. If you're working without an assistant, do the audit yourself with the same prompt as a checklist.
Document your current build state in FSE_STATE.md: error count (should be zero), warning count (this is your baseline), test count, and any known technical debt. From this point forward, every session is measured against these baselines.
Pick a small, real piece of work. Run it through the VERIFY → PLAN → EXECUTE → VALIDATE protocol. End with a session-state update and a clean commit. Don't pick something ambitious for the first session — the point is to feel the rhythm, not to ship a feature.
Things that aren't in the methodology document but that real adoption keeps surfacing.
The first few sessions feel slower because the protocol is unfamiliar. That's normal. Don't combine adoption with a deadline — adopt during a calmer week, then ride the discipline into the deadline.
They are operational state. They get updated every session. Treat them like build artifacts that happen to be human-readable, not like a wiki you write once and forget.
Mistakes that get logged stop repeating. Mistakes that don't get logged repeat forever. Be honest about what went wrong and add it the moment you correct it.
Skipping VERIFY because "I know what's there" is the single most common adoption failure. The point of VERIFY is not what you know — it's what's actually on disk right now. Read the files.
Not four. Not five. The fourth attempt is the same reasoning that produced the first three failures. Stop, report, switch approaches.
You don't need a separate police file or schema file on day one. Add them when the bedrock methodology document grows past readable size or when a domain accumulates enough rules to warrant its own file.
Don't fold .NET-specific or React-specific rules into your bedrock methodology document. Reference the appropriate stack folder in the extensions repository instead. Your bedrock stays portable.
Always. Even if the session was small. The git history becomes a parallel record of how the project actually moved, which is invaluable when you're trying to reconstruct context six months later.
No. FSE was developed alongside AI-assisted development and the protocol fits naturally with it, but the methodology is about how sessions are structured and how state is tracked. Both work without an assistant. The discipline is the same either way.
No. It was created by a solo developer managing eight production solutions, which is why it's heavy on documented state and structured sessions. Teams use it too. The bedrock files become shared context instead of tribal knowledge.
The session protocol applies regardless of architecture. The structural conventions in the methodology document are recommendations grounded in real practice — adapt them to your architecture and document the adaptation in your bedrock files. The point is to have an explicit answer, not to follow our specific answer.
That's a stack-specific rule, and it lives in the .NET extension, not the core. The reasoning is documented in the standing orders for that stack. If you're using a different stack, your migrations story can be different — what matters is that the rule is explicit and the failure modes are understood.
Three to five sessions for most people. The protocol feels heavy for the first two sessions because every step is conscious. By the fifth session it's faster than working without it because the cost of skipped steps has shown up at least once.
Yes. The templates are starting points. Add fields, rename sections, drop things you don't use. The only hard rule is that the structure of every session is VERIFY → PLAN → EXECUTE → VALIDATE and that bedrock state is maintained between sessions. Everything else is yours.
Documentation describes what the project is. FSE describes how the project moves. Bedrock files are operational, not historical. They're read at the start of every session because they reflect current state, not past decisions.
Yes. FSE describes how individual sessions of work are structured, which sits below the level Agile and Scrum operate at. They're orthogonal — your team can run sprints and standups while individual development sessions follow FSE.
Read why it exists first. Every rule in the methodology has a failure mode behind it, and the failure modes are documented. If after reading the reasoning you still disagree, document the deviation in your bedrock files with your reasoning. That's better than silently ignoring it.
The core repository on GitHub has issue templates for bug reports, feature requests, and methodology questions. Open an issue. Real questions from real adopters are how the methodology improves.
FSE isn't a framework you install. It's a way of running sessions that produces software you can trust six months from now.