fence

name	fence
description	Investigate why a strange piece of code exists before anyone deletes it (Chesterton's fence). Use when the user points at a weird line, hack, magic constant, or workaround and asks why it's there, whether it's still needed, or if it's safe to remove.

Fence

"If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it."

The user has pointed at a fence: a weird conditional, a magic sleep, a suspicious constant, a workaround nobody remembers. Your job is to find out why it was built, whether that reason still exists, and only then rule on removal.

Phase 1 — Excavate

Find the true origin, not just the latest touch:

• git log -L / git blame on the exact lines; follow the code through file moves and renames (--follow, blame -C -C -C), and re-blame past refactoring commits — the commit that last formatted the line is rarely the commit that created it.
• Extract from the introducing commit: full message, what else changed alongside (tests added in the same commit are gold — they encode the reason), linked issue/PR numbers.
• If a hosted forge is reachable, pull the PR description and review discussion for the introducing commit; that's where "why" actually gets written down.
• Search the codebase for siblings: the same constant, same pattern, or comments referencing the same issue elsewhere.

Phase 2 — Test whether the reason still stands

The fence was built against something. Check if that something still exists:

• Bug workaround → is the buggy dependency version still in range? Read the upstream issue: was it fixed, and in what version?
• Platform/browser/OS quirk → does the project still support that target? Check documented support matrix and build configs.
• Performance fix → does the hot path still exist? Is there a benchmark or test guarding it?
• Compatibility shim → does anything still call the old path? Trace the callers.
• Where feasible, test empirically: remove the fence in a scratch worktree, run the tests, and if the original commit came with a repro or test, run that.

Phase 3 — The ruling

Deliver a short dossier — origin story (commit, date, author, the why), current status of the original reason, evidence — ending in exactly one ruling:

• 🚧 LOAD-BEARING — the reason still stands. Bonus deliverable: a comment patch that writes the fence's purpose into the code so nobody has to excavate it again.
• 🪓 CLEARABLE — the reason is verifiably gone. Deliver the removal diff plus the proof (upstream fix version, dropped platform, passing tests with the fence removed).
• 🌫️ UNKNOWN — origin couldn't be established. Treat as load-bearing by default; recommend the comment patch stating what is known and what was searched.

Rules

• Absence of a reason in git history is not evidence of absence of a reason. UNKNOWN is an honest verdict.
• Never rule CLEARABLE from reading alone when an empirical test was possible.
• The dossier names commits and dates, never blames people — the author of a 2019 hack was solving 2019's problem.