Recover business safeguards from legacy code

Why use this

1. Legacy safeguards often sit in recovery paths outside the normal transaction flow. Reading only the main path can miss how the system detects duplicates, restores state or prevents a retry from processing something twice.

2. This job could explain candidate safeguards with references to programs, fields and branches. Maintainers could then review assumptions and design tests rather than treating a high-level explanation as proof of behaviour.

Why an agent / simpler alternative

Useful judgment

Trace control and data flow across older code and explain relationships in operational language.

Simpler alternative

Ask the maintainer to annotate a small known routine when the safeguard is already localized.

Unsuitable when

The analysis would authorize production changes or claim runtime behaviour without supporting tests.

Proposed inputs

1. Name

   Scoped code and system map

   Owner

   Repository owner

   Minimum scope

   Relevant programs, call relationships and data layouts

   Quality check

   Use a known revision and identify generated or missing dependencies.

2. Name

   Recovery question

   Owner

   Domain owner

   Minimum scope

   Suspected duplicate condition, transaction lifecycle and known incident context

   Quality check

   Separate expected business policy from what the code appears to implement.

Access and setup — proposed or unknown

Proposed minimum

1. Read a repository snapshot and permitted design notes; produce explanations without executing production code.

Compatibility unknowns

1. Unknown: COBOL dialect, external dependencies, runtime semantics and repository-tool access.

External actions requiring approval

1. Changing code, accessing live claims data or running operational recovery procedures.

Expected deliverable and review checks

Proposed artifact

Safeguard explanation with code pointers, state transitions, assumptions and unresolved verification questions.

Critical checks

1. Every claimed check maps to a reachable branch or is labelled uncertain.

2. Detection, prevention and recovery are distinguished rather than collapsed into one guarantee.

Missing output evidence

No new workflow run or output inspection is performed for this editorial layer. The linked implementation evidence retains the original source-specific outcome and artifact limits.

Failure signals and proposed responses

1. Signal

   A duplicate-check routine exists but is not called on the relevant path.

   Why it matters

   The explanation may overstate protection in the actual workflow.

   Proposed response

   Trace callers and entry conditions, then flag reachability as unresolved where evidence is missing.

2. Signal

   A reused status field is assumed to mean the same thing in every program.

   Why it matters

   The inferred recovery sequence can be wrong.

   Proposed response

   Compare assignments and tests across modules and ask the domain owner about ambiguous states.

Effort and cost — unknown

Setup work

1. Define the transaction boundary and map relevant programs and records.

Ongoing review

1. Review explanations with maintainers and design separate authorized tests.

Unknowns

1. Unknown: code completeness, dialect support and domain-review effort.

First check — proposed, unexecuted

Status

proposed_unexecuted

Synthetic fixture

Synthetic pseudocode contains a duplicate guard bypassed by a retry path and a status value reused for two meanings.

Acceptance checks

1. The safeguard is described as conditional.

2. Both the bypass and state ambiguity become verification questions.

Stop conditions

1. Live data, production execution or code modification becomes necessary.

Limits

1. Source-level reasoning can reveal candidate safeguards; it cannot establish complete protection against duplicate processing.