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.
1---2name: fence3description: 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.4---56# Fence78> "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."910The 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.1112## Phase 1 — Excavate1314Find the true origin, not just the latest touch:1516- `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.17- 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.18- 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.19- Search the codebase for siblings: the same constant, same pattern, or comments referencing the same issue elsewhere.2021## Phase 2 — Test whether the reason still stands2223The fence was built against something. Check if that something still exists:2425- **Bug workaround** → is the buggy dependency version still in range? Read the upstream issue: was it fixed, and in what version?26- **Platform/browser/OS quirk** → does the project still support that target? Check documented support matrix and build configs.27- **Performance fix** → does the hot path still exist? Is there a benchmark or test guarding it?28- **Compatibility shim** → does anything still call the old path? Trace the callers.29- 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*.3031## Phase 3 — The ruling3233Deliver a short dossier — origin story (commit, date, author, the why), current status of the original reason, evidence — ending in exactly one ruling:3435- **🚧 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.36- **🪓 CLEARABLE** — the reason is verifiably gone. Deliver the removal diff **plus the proof** (upstream fix version, dropped platform, passing tests with the fence removed).37- **🌫️ UNKNOWN** — origin couldn't be established. Treat as load-bearing by default; recommend the comment patch stating what *is* known and what was searched.3839## Rules4041- Absence of a reason in git history is not evidence of absence of a reason. UNKNOWN is an honest verdict.42- Never rule CLEARABLE from reading alone when an empirical test was possible.43- The dossier names commits and dates, never blames people — the author of a 2019 hack was solving 2019's problem.
tokyubevoxelverse