musk-step-2-delete-parts

Step 2: Delete Any Part or Process You Can

Cut first. If you do not add back ~10%, you did not cut hard enough.

Part of the [[musk-algorithm]]. Second in the strict order.

Gate

Before this step, verify in the conversation or diff:

• [[musk-step-1-question-requirements]] has produced a list of named, surviving requirements.

If absent, stop. Run step 1 first. No exceptions.

Why this step exists

Smart engineers default to addition. Adding a part feels like progress. Removing one feels risky. The Musk algorithm inverts this default: every part is guilty until proven necessary by a surviving requirement from step 1.

Musk's calibration rule: if you do not end up adding back at least 10% of what you deleted, you did not delete enough. Adding back zero means the cuts were never load-bearing in the first place, which means the system has even more bloat than was just removed.

Protocol

For every part in scope (feature, endpoint, table, column, service, dependency, config flag, document, meeting, role, dashboard, report):

1. Inventory. List every part. If the list is incomplete, stop and request the rest.
2. Map each part to a surviving requirement. If no surviving requirement from step 1 justifies a part, default to delete.
3. Identify hidden invariants. Code, especially, can assert things that are not in the requirements. Before deleting, ask: what does this code assert? If the assertion matters and lives nowhere else, the assertion must be relocated before the code is cut.
4. Predict the add-back list. Before any deletion, name the parts you expect to restore once pain shows up. Zero predicted add-back means the cut is theatrical. Recut.
5. Execute the cut.
6. Audit the actual add-back over the relevant time horizon. Less than 10% means the cut was too soft. Recut deeper. More than ~25% means the cut was sloppy. Redo with more care.

Output format

Inventory: [list of all parts in scope]
Deletion list: [parts proposed for removal, with one-line justification each]
Justifications for kept parts: [each kept part tied to a named-owner requirement from step 1]
Predicted add-back: [parts you expect to restore, with reasoning]
Expected add-back percentage: [explicit number, target 10-25%]
Hidden invariants identified: [what kept code or processes assert]
Cut executed: [what was actually deleted]
Audit plan: [when and how the actual add-back will be measured]