Topic · Empty-start replacement
How do I safely replace a legacy component that has no specs and no tests?
Do not write the spec from the code and call that a bar. Recover shalls the owners sign. Then the replacement has to carry that ledger.
proof audit --check mirror_completeGolden-master tests still pin observed output. They cannot tell intended behavior from incidental bugs. A mirror of an empty ledger copies the holes.
01 · The empty start
No specs and no tests is not the same job as a rewrite with a suite.
Characterization testing assumes you can observe the old system and pin what it does. This page is the case where you cannot even do that honestly: nothing was written down, and the suite is empty or theatrical.
Two failures hide in the same sentence. One is a rewrite that drops a guard the old tree still had. That is the characterization page: source is the authority, proof audit --check mirror_complete fails if a cell vanished. The other is replacing a component that never had a ledger. There is nothing to characterize against except the code’s own assumptions.
Writing the spec from that code is circular. Phase 1 of a spec-from-code pass describes what the implementation already does. Analyses go green. Zero bugs found. That is expected: every defect already in the code becomes a clause the spec blesses. The owners have to sign what the component is for before either tree is the bar.
02 · The exhibit
Observed bytes are not an approved shall.
Same replacement. Three oracles. Only one of them fails because the owners never signed the clause.
| Job | Golden master / characterization | Proof |
|---|---|---|
| What it needs | Observed output you can capture. | Shalls the component owners approve. |
| Empty start | You write tests against whatever it does, bugs included. | Recover intent. Sign it. Then the replacement carries that ledger. |
| Green means | Bytes match the recording. | The shall still has a witness. Exit 0 on proof audit. |
| Stops the merge? | If you wired the golden file into CI. | Yes, when mirror_complete is on the audit and status is complete. |
| What it cannot do | Tell intended behavior from an incidental bug in the recording. | Prove identical output. That is proof differential fuzz, a different tool. |
We have not run a golden-master suite against proof audit --check mirror_complete on a frozen corpus. The loss is named, not scored. Approval testing and back-to-back testing still pin bytes. They stay. They are not a substitute for a signed shall.
proof mirror add --id MIR-001 \
--source "./old-component/**" \
--target "./new-component/**" \
--status in_progress
proof audit --check mirror_complete
proof mirror status MIR-001Declare the mirror only after the owners have signed the shalls. Status in_progress tracks gaps as warnings. Status complete turns remaining gaps into errors that gate the audit. Extra cells on the target never fail. A vanished cell does.
03 · Honest loss
Proof does not invent the missing specs.
If nobody will sign what the component is for, there is no bar to hold the replacement to.
A mirror of an under-covered source copies the holes. Characterization tests still have a job: they pin observed output, including bugs you meant to drop. A golden master that records a wrong answer will fail the rewrite that finally corrects it. You still need a requirement to say which behaviors were intended.
Jama still authors the programme. Proof does not replace an ALM. It does not produce identical input-output agreement by itself. It does not write the shalls for you from the tree. After week four the gate is in your CI. The engagement can stop. The bar does not. That install is the audit.
04 · Next
What people type next.
How do I rewrite a legacy system without introducing regressions? That is the rewrite that already has a ledger. Characterization testing and mirrors.
How do I verify a rewrite behaves identically to the old system? Identical output is proof differential fuzz on a declared transform, not mirror_complete. Same URL as characterization. Do not mint a twin.
How do I migrate from one language to another and guarantee the same behavior? Same mirror. Names can change. The cell cannot vanish. On the characterization page.
What's the safest way to modernize legacy software that nobody fully understands? Owners still have to sign the shalls. “Nobody understands it” is not a reason to skip that step. It is the reason the spec-from-code pass is circular.