🧭 Project 6: the mindset
All of this is iterative. The closing module installs nothing: it gives you the habit that lets the five previous projects survive the next model switch — tracking what each provider requires, logging every failure in a single line, and no longer managing prompts.
🎯 The project on one screen
Turn what you built into a habit: a maintenance routine that absorbs changes of model, provider and harness without redoing everything.
A FALHAS.md at the project root with at least one real line, a written closing handoff, and the 7-item checklist for tomorrow.
Looking at FALHAS.md, you can say how many failures were prompt and how many were infra — and what the smallest fix was for each.
♻️ Every change improves one model and breaks another
The landscape keeps changing, and that is not a polite caveat at the end of the text: it is the permanent working condition. Every change you make to a skill, an AGENTS.md, a hook, can improve that skill for one model and break the same skill for another. You tighten the instruction for the model that was rambling and, in the same line, take away the room the other one needed.
That is why the right move is not to freeze the workspace once it is set up — it is to constantly track what each model actually needs. The agnostic workspace does not eliminate maintenance; it makes maintenance small and localized, instead of a full migration at every switch.
The cycle turns forever; what does not turn is the core. When a change breaks an executor, the fix happens at that executor's edge — never by rewriting the context the three share.
✓ Light maintenance
- ✓The change goes into the core; each executor's adapter is regenerated.
- ✓The readback runs on the runtimes you use, not just your favorite.
- ✓Broke on just one? Fix that one's edge, and the rest stays untouched.
- ✓Whatever broke becomes one line in the failure changelog.
✗ Maintenance by rewrite
- ✗"It broke on Codex" turns into "I'll redo my instructions from scratch".
- ✗Two versions of the skill, one per model, drifting further apart every week.
- ✗Testing only on the model you like best and discovering the rest in production.
- ✗No record: six months later you repeat the same mistake.
Key concepts
The landscape changes; the workspace keeps up instead of freezing.
The same change has opposite effects on different models.
The executor's adapter, never the shared core.
Readback on every runtime you actually use.
🔌 Keeping up with what each provider requires
"Model-agnostic" never meant "effortlessly provider-agnostic". The knowledge layer is portable; the edges still belong to the provider, and they change without warning you. The differences this whole course has shown aren't bugs: they're the price of using more than one executor.
📋 What the kit has already learned about the edges
- •Codex CLI has no import: there's no equivalent of Claude's
@arquivo.md. Whatever needs to be read has to be stated in text — "readcontext/overview.mdbefore answering" — or the content goes inline. - •Codex doesn't read a global
AGENTS.mdthe way Claude reads the globalCLAUDE.md: what counts is the project's (and the one in~/.codexwhen configured). Don't assume inheritance; prove it with readback. - •Hooks differ in every harness: name, event, format and firing moment don't match. A hook is always edge code — treat it as an adapter, not as part of the core.
- •Sandbox and permissions vary by machine: on this host, forcing
-s read-onlyoncodex execbroke because of AppArmor. The fix was to respect thesandbox_modeinconfig.toml, not to rewrite the script. - •What almost all of them share: Markdown.
agents.mdis understood by many;claude.mdis the Claude-specific exception. Practically everything else is portable.
💡 The weekly drift routine
Once a week, run the same readback on the runtimes you use and compare it with the previous week. It isn't paranoia: it's how you find out an update changed how instructions are loaded before a client does. Fifteen minutes a week versus an emergency migration.
Key concepts
Import, global file, hooks, sandbox: all provider-specific.
Tell it to read in text; don't count on @arquivo.
The difference that shows up on its own between two weeks.
The common denominator that outlives all of them.
🔮 Closed models may not need skills; local ones do
A real possibility for the future: closed models may, at some point, no longer need skills. If they're trained on conversations and absorb these capabilities, much of what is a skill today becomes default behavior. Meanwhile, local models may keep depending on them — and they do today.
The practical conclusion isn't to pick a side. It's the sentence that closes the source text: build your structure independently of any model, but keep up with what each provider requires over time. A skill that became unnecessary on the closed model is still the crutch that makes the local model work — and it's what gives you the option to leave.
✓ What survives the switch
- ✓Context, knowledge and decisions in Markdown.
- ✓Processes, handoffs and validation criteria.
- ✓Canonical skills, with adapters generated per executor.
- ✓Curated memory with source and date.
✗ What you lose in the switch
- ✗Prompts tuned for a specific model.
- ✗The runtime's native memory, which never leaves it.
- ✗Hand-written hooks and harness settings.
- ✗Interface habits — and none of that was ever your work.
💡 On building a "super-harness"
For Claude and Codex it isn't worth it: their harnesses are already well optimized, and the vendors do the work of adapting them to every new model. Where building your own pays off is where nobody does it for you — local models and your own pipelines. There, the harness is your product, not a reimplementation of something that already exists.
Key concepts
A capability the model gains without needing a file.
Local models still need explicit skills.
Build independently, but follow what each provider requires.
The real value of being agnostic: being able to switch without starting over.
🗂️ You stop managing prompts
This is the mindset shift that gives the module its name, and it fits in one sentence: you stop managing prompts and start managing context, state, tools, processes and validation criteria.
Managing prompts means optimizing the wording. It pays off quickly and evaporates with the next model version. Managing context means answering who owns each piece of information, what the current state of the task is, which tools the agent can use, what the process is and how you prove it's done — and that still holds when the model changes.
On the left, the work that disappears with the model version. On the right, the five blocks you manage that survive any switch — the last one, validation, is what keeps the other four from turning into fiction.
How this changes your day: when something goes wrong, the first question is no longer "how do I rewrite this prompt?" but "which of the five failed?". Was context missing? Was the state stale? Did the tool not exist in the session? Did the process skip the handoff? Or did nobody simply validate? Four of those five answers are file fixes, not wording fixes.
Key concepts
Facts with an owner, a source and a date.
tasks/current.md: what is being done now and the definition of done.
Handoff, prime, drift: the cycle you repeat.
Readback and canary; "the file exists" is not proof.
📓 The failure changelog: one line per failure
The cheapest maintenance tool in the course is a FALHAS.md file at the project root, with one line per failure: date, what broke, the smallest possible fix, and whether it was a prompt or an infra problem. No narrative. Most recent at the top.
After about ten lines the pattern becomes obvious — and you stop rebuilding things that only needed a safeguard. That's the thesis of the whole file: if the answer was to rewrite or rebuild, all that was probably missing was a safeguard — a cap, a retry, a guard, a validation. Recording that in the line is what prevents the next rebuild.
Code box 1 — the kit's real FALHAS.md
Goal: see the format in use, with the two real failures recorded while building this material. Copy the header into your project.
# Failures (most recent at the top)
| date | what broke | smallest fix | prompt \| infra |
|---|---|---|---|
| 2026-09-13 | readback-test.sh forced `-s read-only` on codex exec; bwrap fails due to AppArmor on this host | remove the flag, respect sandbox_mode from config.toml | prompt \| infra |
| 2026-09-13 | audit.sh summary counted lines from section 3 (73+17+4=94 ≠ 89) | restrict grep to section 2.1 | prompt |
How to check: wc -l FALHAS.md grows by one line per fixed failure, and grep -c 'infra' FALHAS.md tells you how many were environment-related. If a line turned into a paragraph, it's in the wrong file — the long detail becomes a separate file and gets linked.
✓ Useful line
- ✓Written right after you finish the fix, before the next task.
- ✓The smallest possible fix, not the one you made in anger.
- ✓Tagged as prompt, infra, or both when it's both.
- ✓One line. Long details go in a separate file, linked.
✗ Useless line
- ✗"Script threw an error, fixed it." — no what, no how.
- ✗Written at the end of the week, when you've already forgotten the cause.
- ✗"Rewrote the module" as the fix — that's the symptom, not the repair.
- ✗Three paragraphs of narrative nobody rereads.
💡 Prompt or infra?
Prompt = you asked in a way that led to the error, or the model misunderstood. Infra = machine, memory, network, service down, wrong key, unsupervised process. When it's both, tag both — like the first line in the kit, which was a badly written script and a host AppArmor issue. A failure that spans several projects goes in the hub's FALHAS.md, not in the one for the project where it happened to show up.
Key concepts
Date, what broke, smallest fix, classification.
The point of the exercise: the minimum that solved it.
Cap, retry, guard, validation — it almost always was one of these.
The file starts telling you where you always trip up.
🏁 In one sentence — and what to do tomorrow
If you close this page and keep just one sentence, make it this one:
"Don't migrate your brain from Claude to Codex; separate the brain from the model."
What needs to survive the switch isn't Claude, or Codex, or Gemini. It's your layer of context, knowledge, Markdown, processes, handoffs, memory and tools.
What to do tomorrow — 7 items
1. Run the doctor
See what's installed, which version, and what's broken today. Fifteen minutes before any decision.
2. Run the audit (MODE: audit)
Nothing gets written. You walk away with the proposed tree, the ownership rules and the acceptance checks — plus the list of what couldn't be inspected.
3. Write the global AGENTS.md
Your generic rules, no client names, no secrets. The global CLAUDE.md points to it.
4. Pick ONE pilot
One real project, with one representative task. Not five. A template is only a template once one has passed.
5. Do the handoff today
At the end of the first session, before closing. The cycle becomes real when the second session opens through the prime.
6. Schedule the weekly drift
A recurring reminder: same readback, same runtimes, compared with the previous week.
7. Create FALHAS.md
Empty, with the header ready. The first line shows up sooner than you think — and writing it there is what prevents the first rebuild.
Code box 2 — closing handoff (example)
Goal: close the course the way you'll close every session from now on. Save it as handoffs/latest.md in your pilot project and adapt the lines.
# Handoff — 2026-09-14 — end of the Claude → Codex course
## Project and scope
<my-pilot-project>: agnostic workspace. Scope: apply the 6 projects from track 3.
## Current goal
Run a full week with handoff + prime before migrating the second project.
## Accepted state
- Global AGENTS.md written; global CLAUDE.md points to it.
- context/{overview,current-state,sources}.md and tasks/current.md filled in.
- 3 facts promoted from raw memory, with source and two dates.
- FALHAS.md created (1 line: codex exec sandbox — infra).
## Checks run and result
- readback in Claude: passed (cited AGENTS.md and tasks/current.md).
- readback in Codex: passed (cited AGENTS.md; no import, explicit read).
- synthetic cross-client canary: NOT RUN (no client workspace yet).
## Open questions
- Is it worth setting up the third local executor now, or after the second project?
- Which skills become canonical first?
## Exact next action
`scripts/drift.sh` on Monday and compare with this week's report.
How to verify: open a new session, have it read only this file, and ask "what is the exact next action?". If the answer is the final line, the handoff is good. If the session needs you to understand it, the file is missing context — not the model.
Final reminder: nothing here requires you to abandon Claude, or Codex, or any runtime. It only requires that your part — context, state, tools, processes and validation — lives in files you can open, copy and take with you. Models may change. Your working structure should keep working.
Key concepts
The sentence that sums up the whole course.
The template is born from a project that worked.
The cycle only exists when the second session opens through the prime.
Weekly drift + FALHAS.md: cheap, ongoing maintenance.
Self-check (optional): one of your scripts failed because the model returned a huge response and hit the timeout. You rewrote the entire script. What goes in the FALHAS.md line?
🎯 Project summary
End of Track 3:
You've gone through all six projects. Tomorrow: doctor, audit, global AGENTS.md, a pilot, handoff today, weekly drift and the FALHAS.md created.