The system, mapped
Session lifecycle · the six-layer map · observe / judge / execute · the anti-drift loop. The same architecture the deep-dive explains in prose — here as one picture.
When each primitive activates over a single working session. Anchors are loaded the whole time; hooks fire deterministically at lifecycle events; policies load only when their trigger fires; skills run on demand; memory is read at the start and written at the end. The same shape every session — which is what makes the reconstruction tax go to zero.
Every folder in the workspace performs one of six roles. The three middle layers — hooks, policies, skills — are the observe / judge / execute primitives. They’re bookended by the anchors that frame every session and the memory and governance that make it compound and stay honest. Color-coded to the lifecycle bars in §1.
target-userwho we’re building forcore-jobthe one job the product doespull-sourcerefresh reference material — never staledrift-checkdid the folder map change? warn at startload-memoryre-load cross-session memory into contextstrategy-alignmentPR touches strategy → walk the signalsregister-everywherenew primitive → update every registrydoc-syncbehaviour change → update its spec in the same PR/interview-to-briefraw research → cited problem brief/feature-critiquea feature → a structural critique/strategy-sync-auditflag where the roadmap drifted from strategylearnings-lognon-obvious insights, appended after real workbacklogdeferred decisions and whyepisode-indexrolling summary of the last ~20 sessionsfeedback-loopimprovements to the system itselfregistry-syncevery name updated in lockstepreview-gatemismatch → merge blockedownership + cadencewho merges what · a recurring upkeep passThe three primitives people most commonly blur together — different in who runs them, when, and what they’re best for. Keeping them distinct is what makes the system legible, and what makes designing the human↔AI division of labour an actual, demonstrable skill.
| Dimension | Hooks | Policies | Skills |
|---|---|---|---|
| Tripwire | Checklist | Playbook | |
| What it is | A deterministic shell script | A plain-language markdown rule | A packaged multi-step workflow |
| Who runs it | The harness, automatically | The agent, when a trigger fires | A person, on demand |
| When it fires | Lifecycle events (start / end / prompt) | Only when its situation arises | When invoked by command |
| Its job | Observe & surface — never decide | Judge a situation — guide the call | Execute a procedure — carry it out |
| Example | “Pull latest source & flag if the structure changed.” | “If this touches strategy, check the alignment signals.” | “Turn this interview into a structured brief.” |
The rule that makes the system durable: any new primitive must update every registry that names it — including this diagram — or the change fails its own audit. Adding a skill, for example, forces all four steps below. Skip one and the loop blocks the merge.
A new skill (or hook, policy, folder) is added in its own place in the workspace.
The register-everywhere policy triggers: “this exists now — register it in every place that lists it.”
The index, the capabilities map, and the self-portrait diagram all update to include it. Map = territory again.
A structural-drift check at session start, plus a review gate before merge, compare the diagram to reality. Mismatch → blocked.
The payoff: six months on, the map is still the territory. A newcomer can trust the system’s description of itself, because the system can’t let that description go stale. That’s the difference between a project that decays the moment its author leaves and one that explains itself to the next person — and it’s why this very page can be trusted as a current map, not a stale screenshot.
The cadences and automations that keep the workspace current and its description honest — the “self-improvement layer” that turns a docs folder into an operating system.
Hooks pull the latest source, run the structural drift-check, and re-load memory — so the agent starts informed against current anchors, every time.
The matching policy loads only when its situation arises — consistent judgement exactly when it’s needed, without bloating context the rest of the time.
A new primitive must update every registry that names it, including this diagram. A review-gate blocks the merge on mismatch — drift is caught before merge, not in review.
A non-obvious insight from real work is appended to the learnings-log — and re-loaded next session, so the same lesson isn’t re-learned twice.
A scheduled pass prunes the learnings log, retires orphaned folders, and refreshes stale specs — the unglamorous rigor that keeps a system honest over time.
Governance closes the loop: ownership decides who merges what, and the anti-drift audit (§4) ensures the map can never quietly fall out of sync with the territory.
This is the system at a glance. For the why behind each layer, or the real code behind a primitive: