spec-inferlisted

# Spec: Infer ## Overview Infer recovers specs by reading the codebase. It is the highest-risk skill for silent misinterpretation — code reveals what was built, not what was decided. Every inferred decision is marked until the user confirms it. Nothing is promoted from implementation detail to spec entry without explicit rationale. ## Scope First Before reading any code, confirm scope with the user: > "I'll start with [capability area]. Is that the right scope, or do you want me to cover other areas? On a broad codebase I'll work one capability area at a time and check in after each." Do not start inferring across the whole codebase without confirmation. ## The Inference Rule For every candidate decision in the code, ask: **could this plausibly be accidental?** - If yes → mark as `> Inferred — please confirm` and surface the ambiguity - If no (unambiguously intentional and well-understood pattern) → write as a decision with rationale from context When in doubt, mark and ask. Unmarked inferences that turn out to be wrong are harder to find than marked ones. ## Output Format Write capability spec files following the format from `spec:core`. For every entry where rationale is missing or the decision could be accidental: ```markdown ### <Decision name> [What the code does.] > Inferred — please confirm: was this a deliberate decision? If so, what was the rationale? ``` For entries where rationale can be inferred with confidence (well-known security patterns, etc.):