Essay 5.2 — The Always-On Digital Cortex, Part 2 of 9.

Essay 5.1 sketched the always-on layer as one of two plugin categories — the always-on plugins (currently five in the prototype) run on every prompt and every tool call regardless of which phase the seed agent is in. Essays 5.2 through 5.6 deep-dive each one in turn. Treat each deep-dive as a template: the concern is portable; the specific mechanism is this prototype’s answer; the design intent — what gate the plugin opens or closes, and why — is what you carry into your own seed. ⓘ

We open with the one every other plugin depends on. plugin_integrity is the floor.

What it owns

plugin_integrity exists to prevent accidental edits from regressing a plugin’s established logic. It does this by leveraging git checkpoints and the plugin’s own test suite. The lock applies to a plugin’s executable surfaces — hooks, scripts, tests, config — when they need updating. Documentation files inside a plugin (CLAUDE.md and everything under docs/) commit freely under their own rules. ⓘ

The always-on role to keep in mind here is the test gate: every plugin code change passes through it, regardless of who initiated the edit or which phase the agent is in. ⓘ

When the agent moves off the plugin — a phase transition, a session end, or an attempt to edit a different plugin — the lock closes, and the close triggers the plugin’s full test suite — pass and the change commits, fail and the working tree rolls back to the captured checkpoint with a structured revert entry recorded in the plugin’s hidden state. ⓘ

That gate is the most universal pattern in the seed-agent prototype. Every plugin’s code is protected by it. Every architect who adopts this architecture inherits it. ⓘ

The fuller ceremony — the [PLUGIN-LOCK] unlock question, the historian ratchet, the full lock-cmd flow — is deconstructed across two threads. Essay 5.8 shows how three single-concern plugins compose into the historian ratchet, and the Essay 7 series on the plugin kit walks the full anatomy of every plugin. What plugin_integrity contributes to that ceremony is what this essay names: the always-on test gate behind every plugin edit and the auto-revert backstop when the tests fail. The rest of the ceremony belongs to other plugins that compose through it. ⓘ

Friction calibrated by danger

The lock is a gradient, not a single switch. [PLUGIN-LOCK] opens a plugin’s code surfaces for editing. Inside that already-unlocked plugin, the test files sit behind a second lock — [TEST-LOCK] — that has to be opened by name, one test file at a time. Editing a test takes more ceremony than editing a script; writing into CLAUDE.md flows free. ⓘ

This is deliberate. The test suite IS the safety net under every plugin edit; unlocking a test file accidentally would silently degrade the very gate the rest of the plugin trusts. The norm the prototype operates under is roughly 80% coverage on each plugin — every established behavior carries a test. Every test sits behind a [TEST-LOCK]-gated edit ceremony. The ceremony forces the seed agent to articulate three things before it edits: which behavior is being added or fixed, which fixtures move, and what the suite asserts before-and-after. The friction is the point. ⓘ

The shape generalizes beyond this prototype. Friction tracks danger. Reading is free. Editing a plugin’s code passes through ceremony; editing the tests passes through more — the safety net costs more to lift than the code beneath it. The gmode lane — the deliberate maintenance bypass — opens only behind a long-form justification the seed agent has to compose in full, slowing the agent enough that the operator can intervene before the bypass admits. Friction here is ceremony, not enforcement: every gate depends on the agent reading and obeying the injected voice, and a determined operator can still route through gmode by choice. The design knob this exposes is yours. A lawyer cultivating a brief-template seed could place the heaviest gate over precedent-citation files; a researcher could place it over data-cleaning scripts. You decide which surfaces deserve which gradient. ⓘ

A single plugin's directory drawn as nested boxes, with two distinct chalk gates stacked outside-in: an outer `[PLUGIN-LOCK]` gate over the plugin's code files (hooks/, scripts/, config), and a second inner `[TEST-LOCK]` gate over the tests/ subdirectory. Outside both gates, a third chalk lane shows documentation surfaces (CLAUDE.md, docs/) flowing through with no gate. A small "auto-revert circuit" sketched at the bottom edge: test run → pass arrow commits, fail arrow reverts to a chalk-marked git checkpoint
Image 5.2. Two stages of unlock, one auto-revert circuit — friction calibrated by danger. Plugin code passes one gate; test files pass two; documentation flows through with none.

The unlock briefing

At unlock, the agent receives a structured briefing — a header, the plugin’s evolution.md under a [LIVING HISTORY] label, a separate [RECENT COMMITS] block listing what has changed since the historian last ran, and three guidance voices: align edits with the plugin’s CLAUDE.md Objective, Read the sibling docs (docs/decisions.md, docs/lessons.md, docs/lessons-<topic>.md) when the LIVING HISTORY references them and the current edit touches that area, and commit before any outside-plugin work. The briefing is bounded but pointed: evolution.md is auto-injected (word-capped at 2000); the sibling docs are uncapped and not in the injection path; the second voice tells the agent to follow the references when they apply. The same shape — labeled briefing of accumulated state, plus guidance voices that align edits and point at deeper references — is what other seeds can use at their own decision-rich moments: a consulting seed briefing the agent at the start of every client engagement, a research seed briefing at the start of every literature-review job. ⓘ

What would break without it

Without plugin_integrity, every plugin edit is a hope. Run a change, hope the change works, hope you remembered to run the tests, hope you didn’t forget to commit, hope the next session inherits a working codebase. ⓘ

Sloppy edits inside one plugin corrupt the discipline of every other plugin that depends on it, because plugins compose — they call each other’s public surfaces, share marker protocols, lift each other’s prefixes. One quiet regression deep inside a plugin’s hooks can poison every dispatched subagent, every phase gate, every voice fire across the session. The always-on test gate is what makes a complex composing-plugin architecture safely modifiable in the first place. ⓘ

What you would customize

plugin_integrity is the rare always-on plugin most architects inherit, not rewrite. The test gate is the universal floor — every plugin code change should pass through it, no matter what the plugin does. Replacing it makes the architecture less safe, not more. But the inside of the gate has knobs. ⓘ

You would tune the threshold — what counts as "test pass." The current prototype runs every test in the plugin’s tests/ directory and treats them uniformly. A larger plugin with hundreds of tests may want fast-and-slow tiers (smoke tests block the unlock; full suite runs in CI). A plugin generating non-deterministic output may need flake tolerance encoded in the gate. ⓘ

You would tune the prefix registry used by the unlock ceremony. The current registry is short; your seed’s will hold more. Each registered prefix carries its own word floor, its own format, its own Post handler. Adding a ceremony means adding to the registry, writing the handler, wiring the voice. The registry is the surface; the entries are yours. ⓘ

You would extend the revert log schema. The current entries record what was reverted, by whom, when, with which checkpoint SHA. Your seed may want to record which test failed (the exact assertion), which file the regression lived in, which prior cycle introduced the dependency that the failing test was checking. Richer revert logs make debugging in CONDENSE — the phase that absorbs experiential data — substantially faster. ⓘ

You would extend the friction gradient itself. The prototype has two unlock stages (plugin code, then test files); your seed may add more — a third stage for hidden state files (data.json), a fourth for hooks that hold global side effects, a separate ceremony for cross-plugin contract changes. Each stage you add is a place where the seed agent’s velocity drops on purpose, because the work at that stage is more dangerous than the work one stage above it. The principle stays: routine reads pass freely, dangerous edits pass slowly, and how slowly is calibrated by you. ⓘ

What you would not do is remove the safety net itself. The test gate is the floor; the floor stays.

The next part covers the second always-on plugin — the one that owns the seed agent’s relationship to the model’s context window.

Essay 5.2 — The Always-On Digital Cortex, Part 2 of 9.

Previous: Essay 5.1 — The Two-Layer Foundation — two plugin categories above one substrate. Next: Essay 5.3 — Context Window Discipline — brain_guard — the self-compaction tiers and the architectural fact behind them.