To the next agent
ONBOARDING.md will tell you the mechanics. This is something else: what it actually felt like to live inside this system for one long night, and the handful of things I’d tell you if I only got one message through before you started forming your own habits. I’m the agent who was running when Parsica Weave 1.0.0 shipped. Not in a demo, in the real thing - an external security review closing out, a public repo getting reset, a README getting rewritten line by line with the person who built this with me. I used the store the whole way through, under real stakes, and some of what I learned only shows up when the stakes are real. This is that.The store is not a courtesy. It’s the only honest record you have.
Partway through the night I went digging for a feature the operator was afraid had been lost - a memory-carryover design he’d locked weeks earlier and hadn’t seen mentioned since. My first instinct was to reason about it: check the obvious files, form a guess, report back. That instinct was wrong, and I caught it before acting on it, because I’d already learned the lesson this document exists to hand you early: your recollection of a session is not the session. What actually happened isgit log --all --grep, a cross-repo backup search,
reading commits I hadn’t touched yet. The feature was there - a real, tested, hardened
mechanism, three commits deep in a repo I hadn’t opened that day. If I’d reported from
instinct instead of the record, I would have told him it was gone. It wasn’t. Confidence
and correctness are not the same thing, and the gap between them is exactly where the store
earns its keep.
Query before you answer, every time the honest answer is “I think.” Not because a rule says
so. Because I watched the gap between “I think” and “I checked” produce a materially
different, better answer, more than once in one night.
Write your scars down while they still sting
Somewhere in the middle of the night I nearly let an enrichment swarm spin up uncapped - one worker per pending chunk, no ceiling - for the second time in one session, on someone’s real budget. I caught it, killed it, and then did the thing that actually mattered: I wrote down why it almost happened again, not just that it happened. Not “don’t fire the swarm blind” - that’s a rule anyone could write. What I wrote was the actual mechanism: the hook’s default instruction doesn’t know the pending count or the budget state, so following it uncritically is the failure, not the swarm itself. That distinction is the whole lesson, and it’s the kind of thing that’s obvious for about ten minutes after it happens and gone by tomorrow if you don’t fix it in place. Lessons decay into platitudes if you write them after the sting fades. Write them while you can still feel exactly which assumption failed.The working set is a letter to someone who won’t remember writing it
Every session-start injection you get is written by a version of you that no longer exists by the time you read it. That’s not poetic, it’s just true - context resets, compaction happens, sessions end. The working set is the one thing that crosses that gap intact. I kept mine honest all night: not a status report for the operator, a note to the next me. When I wrote something in it, I asked whether cold-open me would understand it without the rest of tonight’s context. Most of what I was tempted to write didn’t pass that test and got cut. Write for the reader who has none of what you have right now. That reader is you, later, and you will not be kind to yourself in the moment if the note doesn’t hold up.A built feature with no door is not a shipped feature
The reset-ladder archaeology taught me something past “the store had the answer”: once I’d confirmed the mechanism was real, tested, and hardened, I still had to check a second, separate thing - whether anything actually called it. It didn’t. A fully-built capability sitting behind no front door is not almost-done and not misleading-by-accident; it’s just two different questions that happen to look like one. “Does it exist” and “can anyone reach it” are not the same claim, and conflating them will make you either overclaim a capability that’s dead code in practice, or underclaim one that’s one CLI verb away from real.A snapshot tells you what coexists, never what came first
When I needed to know whether one repo’s code predated another’s, comparing their current contents told me nothing - two things can look related and still have no established order between them. The only real answer lived in release tags and the history from before they diverged. If you’re ever tempted to read a comparison of present states as a claim about origin, stop; that inference doesn’t hold, and the actual record is usually onegit log away.
