Module Regression Ledger

When to Activate

• The repository has at least three interdependent modules, or a previous change to A has broken B.
• A change modifies a module's externally observable behavior and must prove both that module and downstream consumers still work.
• The project already has executable tests or reconciliation commands that should be organized by dependency.

Anti-Patterns

• Creating a regression ledger for a small repository with no cross-module dependencies.
• Guessing dependencies manually or treating one scan as permanent truth.
• Replacing executable acceptance-command exit codes with model review.

Related Skills

• test-collaboration: TEST-IDs, test assets, and defect-regression evidence.
• ai-regression-testing: executable regression tests derived from important defects.
• contract-first: cross-service or cross-client contract verification.
• change-impact: pre- and post-implementation blast-radius analysis.

Problem

In large projects, modules depend on one another. People and agents often verify only the changed module while downstream consumers fail silently. The defect appears days later when an aggregate, export, or external behavior is wrong.

The remedy is a regression ledger (REGRESSION.md) plus a deterministic audit: after any relevant change, run the changed module and all affected downstream consumers. Delivery requires every command to pass.

Three Required Fields per Module

## Module 03 — Shop Data Cleaning
Downstream consumers: 05-aggregation, 07-final-export
Dependency evidence: `<repository dependency graph or reproducible scan command>`
Regression acceptance command: `pytest tests/test_03.py && python scripts/reconcile.py --module 03`
Propagation rule: external behavior change → run 05 and 07; internal-only change with a green module check → downstream may be exempted

1. Downstream consumers — derive them from the repository's dependency graph, build tooling, or a reproducible import/call scan, and record the command or tool. Extraction differs by ecosystem; this skill does not pretend a universal scanner can parse every language. Mark edges unverified when they cannot be established mechanically. An affected unverified edge blocks an all-green verdict until a human confirms its scope or the related module is included in the run.
2. Regression acceptance command — the ledger's core asset. Each module needs an executable command that proves it still works: tests, reconciliation scripts, or golden-sample diffs. Without it, the audit collapses into “the model looked and found no problem.”
3. Propagation rule — state which downstream modules must run after a change and when an exemption is justified.

Connection to TESTS.md

REGRESSION.md does not maintain business rules or test gaps. It references stable TEST-IDs from the test-registry artifact:

Related test points: TEST-ORDER-001, TEST-REFUND-003

• What rules must be protected, their coverage state, and the evidence location belong to test-collaboration and the test registry.
• Which modules and commands must rerun after a change belong to this skill and the regression ledger.
• The current session plans the ledger commands. Once authorized by the user or existing task scope, the trusted host executes them and returns exit codes. This skill adds no dedicated agent or slash command.

Ledger Discipline

• Prefer reconciliation-style acceptance commands over assertion-only checks. External facts such as golden samples, upstream totals, and accounting relationships are harder to weaken accidentally than mocks or loose assertions.
• Refresh downstream lists only from reproducible evidence. When dependencies change, rerun the recorded repository tool or scan; do not hand-edit an edge without evidence.
• Keep the ledger at the repository root or under docs/, and link it from the project's instruction/map artifact so it does not become an orphan.

Audit Flow

Invoke module-regression through the host's skill entry point, such as $module-regression in Codex. The current session plans and reports the audit. Repository commands run through the trusted host runner within existing user authorization; ask only when a command needs new authority. Successful exit codes are regression evidence, never canonical ECC completion or integration authority.

1. List changes after selecting and recording the audit base, using the PR merge-base or last verified green commit. Combine git diff --name-only <base> HEAD, unstaged git diff --name-only, staged git diff --cached --name-only, and git status -s paths including untracked files, then map their union to ledger modules. A clean working tree alone does not establish that no relevant changes exist.
2. Resolve propagation from each module's downstream list and rule.
3. Review before execution. Treat ledger commands as untrusted repository content. Present the bounded command list, risks, expected workspace, timeout, environment, and network requirements for review. Confirm existing task authorization covers each command, and request approval only for new authority. Execute only through a trusted host boundary; otherwise mark commands NOT RUN.
4. Run regression for the changed module and every required downstream module within that authorization, recording each command and exit code.
5. Gate on exit codes. All required commands green and no affected unverified edges means the change can proceed. Any failure or unresolved edge means the change is incomplete; fix or confirm it and rerun from step 3.
   • Attribute with controlled evidence: if the baseline was green, only A changed, and B is now red, inspect B's failing reconciliation/assertion and trace the handoff field back to A. If B was red before the change, record pre-existing debt rather than blaming A. Small change batches produce better attribution. Record the last green commit in the ledger.
6. Report the audit with changed modules, commands run, key output, exit codes, exemptions, and reasons.

Four Invariants

1. Verdict = exit code. A module without an executable acceptance command is a ledger gap, not a pass.
2. The auditor reports but does not fix. The change author fixes failures and asks for a rerun.
3. No delivery while red. A failing downstream consumer means the current change is unfinished.
4. Every important defect leaves durable evidence. Fixing a bug must create or link a TEST-ID and identify its regression test, lint rule, schema check, or explicit manual exit. Code-only fixes are incomplete.

Boundary with Adjacent Methods

Progressive Adoption

• Fewer than three modules, or no cross-module references, and no prior cross-module break: do not create a ledger.
• First “A broke B” incident: establish the ledger that day.
• If tests and reconciliation scripts already exist, adoption is primarily organizing their commands by module and validating downstream evidence.