Behavior Inventory — Claude Code Guide

BEHAVIOR_INVENTORY.md describes business flows

`BEHAVIOR_INVENTORY.md` is needed before changes in a system where actual behavior matters. It is not a file list or an architecture diagram: each entry describes a business flow, inputs, observable outputs, existing tests, missing checks, and a characterization candidate.

The candidate must have an explicit `yes` or `no`. `yes` is appropriate for a high-risk/high-business-criticality flow, an uncovered edge case, or a situation where code and documentation conflict.

Schema for one entry

Five required flows

• pause/resume subscription — check subscription state, pause interval, resume date, and next charge;
• partial refund in the middle of billing period — record amount, period, rounding, and observable ledger output;
• failed payment followed by successful retry — separate failure, retry schedule, subsequent success, and user notification;
• plan switch on billing day — check date precedence, old/new plan, and the amount at the period boundary;
• upgrade/downgrade in the middle of a period — separate prorating, effective date, credits, and the future invoice.

Inputs, outputs, and evidence must be reproducible

For each flow, specify the minimum inputs: state identifier, timestamp or billing date, plan, amount, feature flag, and an external event if needed. Outputs must be observable: a status transition, invoice/refund amount, next billing date, persisted record, or message. Do not write “works correctly” without a concrete observable result.

Show existing tests with their path and level. If there are no tests, that is a missing check, not proof that the behavior is wrong. Separate confirmed facts, assumptions, and manual verification just as in ARCHITECTURE_CURRENT.md.

From inventory to a characterization candidate

1. Choose approximately 10–15 strongest candidates rather than every possible condition.
2. Set yes for costly, uncovered, or conflicting flows; set no when behavior is sufficiently confirmed and risk is low.
3. Record reproducible inputs and observable outputs.
4. Add evidence anchors and a list of what must be checked manually.
5. Pass high/high entries to RISK_MAP.md with a concrete action.
6. Do not write characterization tests as part of this discovery task.