Second Brain

Adopt Component-Removal 4-Artifact Rule: every component eradication produces (1) runtime stop, (2) slot/registration removal, (3) documentation cascade — grep all skills + memory + EA workspace + hoo

2 min read

Adopt Component-Removal 4-Artifact Rule: every component eradication produces (1) runtime stop, (2) slot/registration removal, (3) documentation cascade — grep all skills + memory + EA workspace + hoo

Decision

Adopt Component-Removal 4-Artifact Rule: every component eradication produces (1) runtime stop, (2) slot/registration removal, (3) documentation cascade — grep all skills + memory + EA workspace + hookify + scripts for component name + every alias, (4) automation-layer enumeration — crontab + systemd timers + Prometheus alerts + log-path consumers — and cleanup or migration. Without all four, eradication is INCOMPLETE and Tier 1 Directive 3 is violated. This session’s CIOS/Paperclip cascade-update sweep closed artifact 3; artifacts 4 (cron + Prometheus) deferred to AJ for authorization.

Rationale

First-principles decomposition revealed that 2026-05-06 eradication’s incompleteness was discipline-of-execution failure, not policy gap — Tier 1 Directive 3 already prescribed cascade-update. The 4-artifact framing makes the cascade testable: each artifact is a discrete grep/enumerate operation with a binary “found stale → fix” outcome, eliminating the ambiguity that allowed runtime-only “eradication” to be declared complete. Confidence anchored at 0.85 because the rule is a synthesis of an existing directive (high-confidence backing) but is being formalized for first time (untested as canonical pattern); will be validated when next eradication occurs.

Alternatives Rejected

Outcome

Pending

Graph View

Backlinks