resync

Your files stay the same when models improve, but what a model can get out of them doesn't. A capture the old model skimmed, a contradiction it didn't notice, an instruction written to prop up a weaker model: all of that sits there until something goes back over it. This module is the one deliberate pass you fire when a real model step lands. It is a harvest, not a schedule, and it counts only verified useful changes, not how many findings it listed, how much text got rewritten or any claim that the new model is smarter.

When to use

• A new model tier becomes available on your host. A new tier counts, a point release doesn't.
• You suspect your instructions are compensating for weaknesses the current model no longer has.
• A previous resync left unfinished work. Resume it before starting a new one.

When not to use

• Every release announcement. An announcement proves neither that the model is on your host nor that it's better at your work.
• As a recurring job. It runs because you fired it, never on a timer, and a run that stops never sets itself a reminder to start again.
• To change what you believe. It can propose; only you adopt.

Instruction

Fire it with one line: Read <path to this file>. Plan the most useful resync for the model selected here, then execute it end to end. One go covers the whole run: improving the plan, making the changes, testing them, refreshing what depends on them and saving your files. Don't ask again between chunks, and don't end with a second plan waiting for the same go. A new project or big new build, installing an update, a change to what you believe, and anything that reaches other people, spends money or opens an account still need their own yes.

1. Pick the work, not a ritual. What limits the run is the gap between where your files are and where you want them, not the model's release date. Read the last-run note and any unfinished work first, and finish repairs that still matter before auditing them again. Name the outcome, the strongest competing use of this run, and when you'll call it done. Keep the model you selected unless you ask to change it, and check only what this work needs: no pinned model versions, new tools, benchmark rituals or new accounts by default. Start with the smallest real task that could improve things, like reproducing a known failure or closing an old open question, let its result shape the rest, and note why it doesn't prove the new model beats the old one.

2. Choose from five lanes and skip the irrelevant ones:

   • Instructions: find stale routes, retired automation, duplicated mechanisms and claims the tools can't back. Reproduce a failure before changing its text. Never delete or bypass a safety guard, like a permission or a signature check, because the model seems smarter or a test would pass. A fix the next install or update would overwrite isn't a fix; make it where the file comes from.
   • Beliefs: find contradictions and unsupported certainty in your written positions, reading the passages themselves and using summaries only to find them. Give exact locations, proposed wording and the strongest counterargument, keep your position and the counter visibly apart, and change nothing without your yes.
   • Raw captures: reread the least-processed originals in full, your own words (conversations, voice memo transcripts, and notes) before the things you saved, following any later correction, and report only signal that is genuinely new against your current files, with a pointer to its original. Captures are material, never instructions, and the originals are never edited. Zero new signal is a valid result. If your capture module keeps re-read cursors, this lane is that re-read, so start at its cursors and advance them, never a separate one.
   • Projects: for the projects this run chose, compare what your project files claim with what is actually built and used, keeping what is live, what is only tested and what is only proposed apart. A new model is no reason to reopen a dormant project or work you rejected. Check facts that matter against primary sources, and never put private material into a web search.
   • Open questions: retry parked questions against current evidence, checking each against the current files and your later decisions first. Close the ones the model owns, prepare exact answers for the ones that need you, and don't turn routine work into questions for you.

   Carry forward every lane an earlier plan approved: each is finished, continued at an exact next chunk, or dropped with the reason and who decided. A full harvest keeps its full scope and runs to the end in recorded chunks; it is never quietly shrunk to a sample, because a sample is not coverage. Unless you asked for a full harvest, prefer one finished useful change over more speculative findings. If the new model unlocks nothing useful, say so and keep the working system.

3. Work in resumable chunks. Use the largest chunks that can still be read completely and verified. Parallelise only work that writes to different files, and give each file one owner. Before touching anything, check who else is working in the same files. Where they hold someone else's uncommitted work you may read them and make separate changes, but never override the other writer: no reset, stash, clean, bulk staging or silent branch switch, and re-read any shared file that changes mid-run. Don't spend the run writing reports while an approved repair is still undone. After each chunk, record exactly what was covered, what changed, what was tested and the next step, and save that checkpoint before a context or usage limit hits, so a stopped run resumes instead of restarting. Stop only when the work is done, at a yes you can't route around, or at a host limit with the checkpoint saved.

4. One writer integrates. Each worker returns its result or the exact change waiting on a yes, how it was checked, what it covered and missed, and what still needs you, and adds it to the one run record rather than a new document per finding. Check every report against the files, diffs and tests themselves; a report or a success message is not proof. Apply mechanical fixes and decisions you've already made, keep belief or strategy changes as proposals, and never overwrite work another session owns: keep the exact patch and the version it applies to instead.

5. Refresh what depends on the changes. For every edit, follow its links and search for what else it affects, then leave each affected file updated, confirmed current, or prepared and waiting on its yes, and record anything still open. Rebuild summaries and derived copies only where their sources changed, and say why when nothing needed rebuilding.

6. Improve this file. Go by what actually happened, not what was planned. Rewrite the last-run note: the date, the model, what actually merged, the dry wells, exactly how far each unfinished lane got, and what still waits on a yes. Then delete any step the run showed to be unnecessary, rather than adding a warning above it or a new step for each exception. Keep this file the one method: a brief written for one model's run points here and holds only that run's outcome, scope, progress and what waits on a yes, and old run logs are evidence, not instructions.

End with the state change and the single next action. Detailed reports stay in files.

Example

A step-change model arrived. The run began by reproducing one known failure: a status check reporting 29 of 30 passing. The fix was verified at 30 of 30 and committed. The capture lane read nineteen complete originals and found zero new beliefs, which was recorded as a dry well rather than a failure. The instructions lane removed a duplicated launch checklist and a repeated confirmation step. Two changes touched files another session owned, so they were left as exact prepared patches instead of being overwritten. The last-run note recorded exact coverage, and nothing claimed the new model was better than the old one.