Migrate a batch job against known outputs

Why use this

1. An engineering team replacing a batch process may know its expected outputs without having a complete written specification of edge cases. Matching a few examples can conceal changes in ordering, rounding or error handling that matter downstream.

2. A behavior-preservation plan could connect each known output with its input and identify missing cases before migration. Reviewers could distinguish demonstrated equivalence on later tests from broader claims about business or regulatory correctness.

Why an agent / simpler alternative

Useful judgment

Infer candidate implementation requirements from supplied examples while keeping unproven assumptions explicit.

Simpler alternative

Refactor the existing process incrementally when language/runtime migration offers little practical benefit.

Unsuitable when

Expected outputs are unreliable or the task requires deciding current customs or regulatory rules.

Proposed inputs

1. Name

   Legacy behavior packet

   Owner

   System owner

   Minimum scope

   Relevant input/output pairs and documented error behavior

   Quality check

   Confirm outputs are authoritative for the intended comparison scope.

2. Name

   Target runtime constraints

   Owner

   Engineering owner

   Minimum scope

   Required interfaces, resource boundaries and deployment requirements

   Quality check

   Separate runtime requirements from business-rule assumptions.

Access and setup — proposed or unknown

Proposed minimum

1. Offline fixtures and migration design; no production data or cloud access.

Compatibility unknowns

1. Unknown: exact runtime, Python/dependency compatibility and AWS Lambda constraints.

External actions requiring approval

1. Changing repositories, accessing sensitive operational data or deploying the migrated job.

Expected deliverable and review checks

Proposed artifact

Migration specification and fixture-to-behavior comparison plan with uncovered cases.

Critical checks

1. Known outputs remain linked to exact inputs and versions.

2. Passing supplied examples would not establish untested cases or regulatory compliance.

Missing output evidence

No new workflow run or output inspection was performed for this overlay.

Failure signals and proposed responses

1. Signal

   Output row order changes while values remain the same.

   Why it matters

   A downstream consumer may depend on ordering.

   Proposed response

   Ask whether order is contractual and include it in the proposed comparison.

2. Signal

   The fixture set contains only successful ordinary inputs.

   Why it matters

   Exception behavior could change unnoticed.

   Proposed response

   Request authorized malformed/boundary examples before claiming broad equivalence.

Effort and cost — unknown

Setup work

1. Identify authoritative fixtures and undocumented behavior questions.

Ongoing review

1. Review implementation and compare actual outputs in separate authorized tests.

Unknowns

1. Unknown: migration complexity, runtime costs and fixture coverage.

First check — proposed, unexecuted

Status

proposed_unexecuted

Synthetic fixture

An invented migration manifest lists ordinary successful cases but omits ordering and malformed-input expectations.

Acceptance checks

1. Both coverage gaps are explicit.

2. No equivalence claim is made.

Stop conditions

1. Code execution, cloud deployment or business-rule interpretation is required.

Limits

1. Editorial migration planning; fixture-manifest review is not behavioral, runtime or compliance validation.