Good post. I have taken the clause.md file usage a step further, by telling Claude to update that file you can help keep important context through the conversation and between sessions. It gives you a silver thread to pull on as you continue your work and allows the system to be even more helpful faster.
The claude.md file is used by Claude code to load the context of the work that you were doing in that session when you created the Claude MD file. you can create a cloud MD file by running the /init command so if you tell your Claude code to regularly update that claude.md file it will then load and maintain a record of all the context that you accumulate during the work session when you lsunch the next session. so essentially, if you use it right, yeah you can avoid some level of context rot
I really agree the Max Plan is a no-brainer. I have been using the $200 Max plan for at 3 months now.
And the $200 Max plan is more than enough for me. I have been closely monitoring my limit usage, and sometimes I ran into almost 50% of the limit with $200 Max plan. Since 20% of the limit on $200 plan would equivalent to the $100 plan limit, $100 would not have been enough for me.
for 2 months, I have trying initially just use $100 plan, then quickly switch up to $200 plan.
MIFT-C0 is my admissibility-first framework for governed state transition.
The central distinction is simple:
Generated possibility is not committed reality.
A system may generate candidate states, proposed actions, memory updates, or artifact transitions — but persistence should require closure.
That means a candidate state should not become operational authority unless it satisfies admissibility, boundedness, continuity, tamper resistance, and rollback constraints.
This is where I think a lot of AI governance work is still looking at the wrong layer.
The problem is not only whether an output is acceptable.
The deeper problem is whether a generated state is allowed to persist.
That is the commit boundary.
MIFT-C0 treats persistence as something that must be governed, not assumed.
It also introduces the Morrison Null-Space Principle:
compressed observation is incomplete by construction.
If a system observes less than the full state, hidden drift directions can exist. The question is not whether hidden drift exists. The question is whether hidden motion is allowed to become committed authority without closure.
That is the point of MIFT-C0.
Proposal ≠ commitment.
Generation ≠ authority.
Observation ≠ completeness.
Continuity ≠ assumption.
Persistence must be governed.
Preferred BibTeX citation:
@misc{morrison2026miftc0,
author = {Morrison, Kemar Armando},
title = {{MIFT-C0}: Admissibility-Enforced Dynamics and the Closed Commit Law},
What happens when the agent manages its own context instead of you managing it for the agent? That's where claude.md and MCPs hit their ceiling — they're static. The context problem isn't solved by better onboarding docs, it's solved by memory that evolves with the session.
Great breakdown of the Claude Code ecosystem. The MCP section especially resonated — Context7 alone changed how I work with docs. One thing I'd add: combining Planning Mode with a well-structured claude.md creates a feedback loop where Claude's plans actually get better over time because it understands your preferences. The Max plan point is real — once you stop worrying about tokens, your entire workflow changes.
Coming to this late but the 20% framing holds even now. I'd argue hooks are one of the biggest overlooked pieces. MCPs get all the attention but hooks are what make the workflow actually reliable. A PostToolUse hook that formats after every edit, a Stop hook that runs tests. Deterministic, no tokens wasted asking the agent to remember.
Since you wrote this, Codex CLI shipped lifecycle hooks too. Only two events (SessionStart and Stop) but the same principle. I compared the approaches here https://reading.sh/codex-cli-has-hooks-now-stop-stuffing-agents-md-c181465fe271 and it's interesting how different tools are betting on different levels of granularity. Claude Code gives you 17 hook events. Codex gives you 2 and bets on simplicity. Cursor sits in between.
Great breakdown! The planning mode tip is especially useful.
Good post. I have taken the clause.md file usage a step further, by telling Claude to update that file you can help keep important context through the conversation and between sessions. It gives you a silver thread to pull on as you continue your work and allows the system to be even more helpful faster.
I have seen others reference a link that contains whats written on their .md file, is that a way of avoiding context rot?
The claude.md file is used by Claude code to load the context of the work that you were doing in that session when you created the Claude MD file. you can create a cloud MD file by running the /init command so if you tell your Claude code to regularly update that claude.md file it will then load and maintain a record of all the context that you accumulate during the work session when you lsunch the next session. so essentially, if you use it right, yeah you can avoid some level of context rot
Excellent insights on Claude's capabilities. Very practical tips for optimization.
I don't even code but it all sounds really good 💪
I really agree the Max Plan is a no-brainer. I have been using the $200 Max plan for at 3 months now.
And the $200 Max plan is more than enough for me. I have been closely monitoring my limit usage, and sometimes I ran into almost 50% of the limit with $200 Max plan. Since 20% of the limit on $200 plan would equivalent to the $100 plan limit, $100 would not have been enough for me.
for 2 months, I have trying initially just use $100 plan, then quickly switch up to $200 plan.
Very interesting
+++ Very interesting post
Great post, Claude Code is truly a revolutionary tool.
Excellent post. In my work with Claude Code, "Always plan before coding" has evolved into a discussion or "productive meandering". I am describing this process in a concrete example here: https://wernerglinka.substack.com/p/the-missing-piece-how-i-built-the
++ Good Post, Also, start here Compilation of 100+ Most Asked System Design, ML System Design Case Studies and LLM System Design
https://open.substack.com/pub/naina0405/p/important-compilation-of-most-asked?r=14q3sp&utm_campaign=post&utm_medium=web&showWelcomeOnShare=false
MIFT-C0 is my admissibility-first framework for governed state transition.
The central distinction is simple:
Generated possibility is not committed reality.
A system may generate candidate states, proposed actions, memory updates, or artifact transitions — but persistence should require closure.
That means a candidate state should not become operational authority unless it satisfies admissibility, boundedness, continuity, tamper resistance, and rollback constraints.
This is where I think a lot of AI governance work is still looking at the wrong layer.
The problem is not only whether an output is acceptable.
The deeper problem is whether a generated state is allowed to persist.
That is the commit boundary.
MIFT-C0 treats persistence as something that must be governed, not assumed.
It also introduces the Morrison Null-Space Principle:
compressed observation is incomplete by construction.
If a system observes less than the full state, hidden drift directions can exist. The question is not whether hidden drift exists. The question is whether hidden motion is allowed to become committed authority without closure.
That is the point of MIFT-C0.
Proposal ≠ commitment.
Generation ≠ authority.
Observation ≠ completeness.
Continuity ≠ assumption.
Persistence must be governed.
Preferred BibTeX citation:
@misc{morrison2026miftc0,
author = {Morrison, Kemar Armando},
title = {{MIFT-C0}: Admissibility-Enforced Dynamics and the Closed Commit Law},
year = {2026},
institution = {Codex Sovereign Research},
note = {Public proof surface. Private derivation withheld. Source-bound to KAM-0x∇∞.},
keywords = {MIFT-C0, admissibility, governed persistence, closed commit law, agentic AI, state transition governance}
}
Source anchor:
Kemar Armando Morrison (KAM-0x∇∞)
Codex Sovereign Research
ORCID: 0009-0008-9904-9790
Existence is not authority.
Persistence must be governed.
What happens when the agent manages its own context instead of you managing it for the agent? That's where claude.md and MCPs hit their ceiling — they're static. The context problem isn't solved by better onboarding docs, it's solved by memory that evolves with the session.
https://mbachaud.substack.com/p/agentome
Great breakdown of the Claude Code ecosystem. The MCP section especially resonated — Context7 alone changed how I work with docs. One thing I'd add: combining Planning Mode with a well-structured claude.md creates a feedback loop where Claude's plans actually get better over time because it understands your preferences. The Max plan point is real — once you stop worrying about tokens, your entire workflow changes.
Coming to this late but the 20% framing holds even now. I'd argue hooks are one of the biggest overlooked pieces. MCPs get all the attention but hooks are what make the workflow actually reliable. A PostToolUse hook that formats after every edit, a Stop hook that runs tests. Deterministic, no tokens wasted asking the agent to remember.
Since you wrote this, Codex CLI shipped lifecycle hooks too. Only two events (SessionStart and Stop) but the same principle. I compared the approaches here https://reading.sh/codex-cli-has-hooks-now-stop-stuffing-agents-md-c181465fe271 and it's interesting how different tools are betting on different levels of granularity. Claude Code gives you 17 hook events. Codex gives you 2 and bets on simplicity. Cursor sits in between.
Well summarized and extremely helpful thx
Loved this! We're big fans of Claude (especially Opus 4.6 right now), and this was a great read 🙌