additive-bias-defense

name	additive-bias-defense
description	Inverts burden of proof for code additions. Use when reviewing PRs, planning refactors, or running unbloat to challenge every addition's necessity.
alwaysApply	false
category	quality-contract
tags	["additive-bias","burden-of-proof","scrutiny","cross-cutting","defense"]
dependencies	[]
tools	[]
provides	{"guidance":["additive-bias-scrutiny","burden-of-proof-verdict"]}
usage_patterns	["plan-review","pr-review","code-refinement","unbloat"]
complexity	foundational
model_hint	standard
estimated_tokens	800
role	library

The default answer to "should we add this?" is no. The burden of proof is on the addition.

Additive Bias Defense

Note (#444): Frontmatter declares provides.guidance, not provides.contract. The scrutiny questions are consumed by partner skills (pensive:code-refinement, conserve:unbloat, imbue:scope-guard) that voluntarily embed them; no validator or hook in leyline enforces them directly. If a future contributor adds enforcement, restore the contract label and link the validator path here.

When NOT To Use

• Removing bloat that already landed (use conserve:bloat-detector)
• Scoring whether a feature is worth building (use imbue:scope-guard)

The Problem

LLMs are additive by nature. They reinvent wheels, add unnecessary complexity, hallucinate issues and modify tests to justify them, and deviate from priorities. This contract provides a systemic defense.

The Scrutiny Questions

Applied to every proposed addition (code, files, abstractions, error handling, configuration):

1. Priority alignment: Is this a deviation from the current priority?
2. Criticality: Is it critical to implement at this juncture?
3. Simplicity: Does a simpler or more elegant solution exist?
4. Evidence: What evidence proves this is needed (not assumed)?
5. Consequence: What breaks if we do not add this?

If the proposer cannot answer questions 4 and 5 with concrete evidence, the addition is unjustified.

Anti-Pattern Detection

Pattern	Signal	Challenge
Wheel reinvention	New utility/helper overlapping existing code	"Does X already do this?"
Hallucinated issues	Fix for a bug with no reproduction evidence	"Show the failing test before the fix"
Test manipulation	Test changed to match behavior rather than spec	"Did the spec change, or did you change the test?"
Complexity creep	Abstraction introduced for single use case	"Is this the 3rd use, or the 1st?"