# Plugin Edit Safety — plugin_integrity

Essay 5.2 of 8 — The Always-On Digital Cortex.

Essay 5.1 sketched the always-on layer as one of two plugin categories — five plugins, currently, that run on every prompt and every tool call regardless of which phase the seed agent is in. The next five parts of this essay tour those plugins, one paragraph each. Treat each tour as a template: the concern is portable; the specific mechanism is this prototype’s answer.

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 when a plugin’s code files need updating — documentation files inside a plugin (CLAUDE.md and docs/*.md) move under their own rules, with a few caveats. ⓘ

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 an edit lands inside a plugin and the unlocked state closes, the plugin’s full test suite runs — 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 documentation-edit caveats, the full lock-cmd flow — is deconstructed in Essay 7. For now, the always-on fact is enough: behind every plugin edit sits a test pass or a revert.

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 holds nine entries; your seed 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. ⓘ

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 of 8 — The Always-On Digital Cortex — Hadosh Academy series on agent architecture.

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.