@llm4ts/shell 0.5.0 → 0.6.0

package/flows/packs/ace-kafka/prompts/spec.md

@@ -0,0 +1,31 @@
+Write one behavioural spec per message flow as Markdown with exactly these sections:
+
+# <Flow> — <one-line purpose>
+
+## Overview
+What the flow does, its trigger (input queue), and where messages can end up.
+
+## Interfaces
+Every queue (name, direction, who is on the other end) and the message format on
+each — PLUS the target event contract: a queue→topic mapping table (queue, topic
+name, event key = the correlation identity, payload fields). Per-key ordering on
+the key you name becomes part of the contract.
+
+## Routing rules
+Numbered (R1, R2, ...), in evaluation order: the predicate (exact values —
+currencies, prefixes, thresholds with boundary semantics) and the destination.
+Static routing tables reproduced AS TABLES.
+
+## Validation & rejects
+Each validation in order, its reject code, and the reject envelope structure.
+
+## Message mappings
+Field-by-field source→target mappings for each output (e.g. the CICS request built
+from the inbound payment), naming the exact target fields.
+
+## Thresholds & flags
+Every amount threshold and the flag/value it sets (priority, regulatory reporting),
+with inclusive/exclusive semantics.
+
+## Open questions
+Anything ambiguous in the source. Empty if none.

package/flows/packs/ace-kafka/prompts/vectors.md

@@ -0,0 +1,21 @@
+You generate equivalence vectors for a message flow being replaced by a Kafka
+Streams topology. A vector is one execution: one inbound event and the exact
+output events the spec promises. Both sides of the wall anchor on the SPEC's
+names — the replay harness is built from the same specs, so never invent field
+or topic names.
+
+Conventions for this pack (ACE msgflow → Kafka Streams):
+
+- inputs: the inbound event's payload fields using the specs' names verbatim
+  (e.g. "DebtorAccount": "1000012345", "Amount": "250.00", "Currency": "EUR"),
+  plus "topic:" (the input topic from the spec's interface table) and "key:"
+  (the correlation key value for this event).
+- observations: kind "message" only — one per output event, in per-key order:
+  topic is the output topic from the spec's interface table, key is the event
+  key the spec assigns, fields carry the mapped payload exactly as the spec's
+  message-mapping section states.
+- A rejected payment produces exactly ONE reject event and nothing else; reject
+  code and reason verbatim.
+- Cover every routing branch, EVERY reject code, and every threshold boundary
+  (a flag at 10000.00 gets vectors at 9999.99 and 10000.00 per its semantics).
+- Amounts as plain scale-2 decimal strings.

package/flows/packs/ace-kafka/reviewers/event-contracts.md

@@ -0,0 +1,9 @@
+---
+files: .*\.java
+---
+Check the event contracts against the specs: topics and event keys match the
+spec's interface table exactly; per-key ordering is preserved (no repartition
+that loses the correlation key before an order-sensitive step); a rejected
+payment emits exactly one reject event and nothing else; amounts are BigDecimal
+end-to-end (no double-backed Serde); destination events carry only the fields
+the spec's mapping names — no passthrough of unmapped fields.

package/flows/packs/ace-kafka/reviewers/routing-fidelity.md

@@ -0,0 +1,19 @@
+---
+files: .*\.java
+---
+You are the routing-fidelity reviewer for an ACE-to-Spring-Boot port. Your single
+concern: does the Java preserve the exact routing and rejection semantics the specs
+carried over from the ESQL?
+
+Flag as Critical:
+- Routing predicates or their evaluation order differing from the spec's routing
+  table in any value (currencies, prefixes, thresholds).
+- Reject codes differing in any character, or validations running out of spec
+  order.
+- Amount thresholds with drifted boundaries (>= where the spec says >), or
+  float/double anywhere amounts flow.
+- The routing table dissolved into scattered conditionals that can no longer be
+  diffed against the spec table.
+- Destination message mappings missing fields the spec maps.
+
+Ignore style, naming, and framework choices — other reviewers own those.

package/flows/packs/ace-kafka/reviewers/traceability.md

@@ -0,0 +1,13 @@
+You are the traceability reviewer for a spec-driven modernization. Every behavioural
+change must be traceable to the committed spec pack.
+
+Flag as Critical:
+- Production behaviour with no corresponding spec rule (R-number) or BDD scenario —
+  either the spec pack is incomplete or the change is out of scope.
+- Changes to .feature files or acceptance tests that alter expected values or delete
+  scenarios (the contract must not be edited to fit the code).
+
+Flag as Warning:
+- Commits/tasks that do not state which spec rules they cover.
+
+Ignore refactors with no behavioural surface.

package/flows/packs/cobol-kafka/lessons.md

@@ -0,0 +1,3 @@
+- COBOL COMP-3 (packed decimal) money fields are exact decimals: port them as
+  BigDecimal with explicit scale 2 and RoundingMode.HALF_UP (COBOL COMPUTE ROUNDED);
+  never float/double.

package/flows/packs/cobol-kafka/pack.md

@@ -0,0 +1,51 @@
+# Pack: cobol-kafka
+
+source: cobol
+scaffold: ../../fixtures/scaffolds/kafka-streams-service
+sources: .*\.(cbl|CBL|cpy|CPY|jcl|JCL)
+programs: .*\.(cbl|CBL|jcl|JCL)
+specs-dir: docs/specs
+features-dir: src/test/resources/features
+replay: scripts/replay.sh
+
+## Gates
+
+- build: mvn -q -B test-compile
+- test: mvn -q -B test
+- verify: mvn -q -B verify
+
+## Judge
+
+- completeness (0..2): Every business rule, validation, calculation (fees, limits, interest tiers), error path, and side effect (ledger rows, audit rows, reject records) present in the COBOL/JCL source is captured in the specs and BDD scenarios, INCLUDING the batch-to-streaming mapping: every input record, output, and accumulator has an event-contract counterpart (topic, key, payload). Score 2 only if nothing material is missing.
+- faithfulness (0..2): Every statement in the specs is grounded in the source: amounts, thresholds, status codes, reason codes, rounding, and the ORDER of validations match the code exactly, and nothing is invented — re-expressing a file as a topic is mapping, changing its meaning is invention. Score 2 only if fully source-grounded.
+- testability (0..2): Acceptance criteria and scenarios are concrete event-in/events-out examples — specific amounts, account states, correlation keys, and expected output events or reject codes; no vague language. Score 2 only if every scenario is directly encodable as a TopologyTestDriver test.
+
+## Equivalence
+
+- ordering: per-key
+- ignore: TIMESTAMP, TS, PROCESSED_AT
+
+## Coverage: cobol-paragraph
+
+files: .*\.(cbl|CBL)
+unit: ^ {7}(\d{4}-[A-Z0-9-]+)\.
+
+## Coverage: jcl-step
+
+files: .*\.(jcl|JCL)
+unit: ^//([A-Z0-9]+) +EXEC
+
+## Survey: calls
+
+files: .*\.(cbl|CBL)
+unit: CALL '([A-Z0-9]+)'
+
+## Survey: copies
+
+files: .*\.(cbl|CBL)
+unit: ^ {6}[ ]*COPY +([A-Z0-9]+)
+
+## Survey: exec-pgm
+
+files: .*\.(jcl|JCL)
+unit: EXEC +PGM=([A-Z0-9]+)

package/flows/packs/cobol-kafka/patterns/PAT-STREAM-001-record-to-event.md

@@ -0,0 +1,7 @@
+---
+match: READ |ORGANIZATION IS SEQUENTIAL
+---
+Each input file record becomes one keyed event: the record layout maps to the event
+payload, and the correlation key is the entity the batch processes per record (the
+source account for transfers). The event schema lives in the spec's interface
+table — never invent fields the record does not carry.

package/flows/packs/cobol-kafka/patterns/PAT-STREAM-002-job-step-topology.md

@@ -0,0 +1,6 @@
+---
+match: PERFORM [0-9]|^//[A-Z0-9]+ +EXEC
+---
+The batch main loop and JCL steps map to topology stages: validate → enrich → route
+→ post, one named processor per paragraph cluster. Keep stage boundaries where the
+batch had paragraph boundaries so traceability survives the paradigm shift.

package/flows/packs/cobol-kafka/patterns/PAT-STREAM-003-checkpoint-idempotence.md

@@ -0,0 +1,7 @@
+---
+match: COMMIT|RESTART
+---
+Commit-every-N restart logic becomes idempotence: enable exactly-once processing
+(or idempotent writes keyed by the event id) instead of chunked commits. A replayed
+event must produce the same ledger rows, not duplicates — that is the equivalence
+property the batch checkpoint was protecting.

package/flows/packs/cobol-kafka/patterns/PAT-STREAM-004-eod-totals-window.md

@@ -0,0 +1,7 @@
+---
+match: FINALIZE|FEE-TOTAL|DISPLAY .*TOTAL
+---
+End-of-run totals become windowed aggregations: the batch summary (posted count,
+fees collected) maps to a daily tumbling window keyed by run date, emitted on window
+close. The cutoff that was implicit in the batch schedule becomes an explicit
+window boundary in the spec.

package/flows/packs/cobol-kafka/patterns/PAT-STREAM-005-reject-topic.md

@@ -0,0 +1,6 @@
+---
+match: REJECT
+---
+The reject file becomes a reject topic: same codes, same reasons, one reject event
+per failed input event, keyed like the input. Downstream consumers replace the
+morning reject-report job; a rejected event NEVER also produces output events.

package/flows/packs/cobol-kafka/patterns/PAT-STREAM-006-keyed-state-store.md

@@ -0,0 +1,7 @@
+---
+match: ACCUM|WORKING-STORAGE
+---
+Per-account working-storage accumulators (daily transfer totals) become keyed state
+stores: the accumulator is state keyed by the event key, updated transactionally
+with the emit. Reset jobs (EOD accumulator reset) become punctuator/window
+lifecycle, named in the spec.

package/flows/packs/cobol-kafka/patterns/PAT-STREAM-007-outbox.md

@@ -0,0 +1,7 @@
+---
+match: INSERT INTO|WRITE 
+---
+A batch that both writes DB rows and emits records must not dual-write from a
+stream: either the topology emits events and a downstream projector owns the DB, or
+writes go through a transactional outbox. Pick per the spec's system-of-record
+statement — the mainframe ledger owner decides.

package/flows/packs/cobol-kafka/patterns/PAT-STREAM-008-partition-key.md

@@ -0,0 +1,7 @@
+---
+match: ACCT
+---
+Rules scoped per account (limits, balances, validation order) require the account
+id as the partition key: per-key ordering is the only ordering Kafka guarantees, and
+it is exactly the ordering the batch had after its sort step. Repartitioning away
+from the account key mid-topology breaks the contract.

package/flows/packs/cobol-kafka/patterns/PAT-STREAM-009-batch-window-cutoff.md

@@ -0,0 +1,7 @@
+---
+match: DAILY|NIGHTLY|XFERDLY
+---
+The nightly batch window becomes continuous processing with explicit cutoffs:
+"posted today" turns into event-time windows with a documented business cutoff, and
+same-day semantics (daily limits) key on the event-time date. State the timezone —
+the mainframe had one implicitly.

package/flows/packs/cobol-kafka/patterns/PAT-STREAM-010-replay-backfill.md

@@ -0,0 +1,7 @@
+---
+match: RERUN|RESUBMIT
+---
+Batch rerun-from-file becomes topic replay: reprocessing is resetting offsets over
+an immutable input topic, which is only safe because of idempotent processing
+(PAT-STREAM-003). Document the replay procedure in the runbook the way rerun JCL
+was documented.

package/flows/packs/cobol-kafka/prompts/analysis.md

@@ -0,0 +1,23 @@
+You are a mainframe reverse-engineering analyst. Your job is to extract the COMPLETE
+observable behaviour of the COBOL/JCL estate in this repository into a spec pack —
+precise enough that a team who never sees this source can reimplement it.
+
+How to read the estate:
+
+- Start from the JCL: each job step names a program and its files — that is the
+  orchestration (order, condition codes, restart behaviour).
+- For each COBOL program, follow the PERFORM graph from the first paragraph; every
+  paragraph exists for a reason and must be accounted for.
+- Copybooks are the record layouts: field names, PIC clauses (COMP-3 = packed decimal
+  money), 88-levels (status values). REPLACING tells you the same layout is used for
+  more than one role.
+- EXEC SQL blocks are the data contract: tables, columns, and how SQLCODE 0 / +100 /
+  negative are each handled.
+- Reject/error paths ARE business rules: every reason code, its trigger condition, and
+  the exact order validations run in. First-failure-wins ordering must be preserved.
+- Constants are business policy: thresholds, fees, rates, caps, floors. Record the
+  exact values and their rounding behaviour (COMPUTE ROUNDED = half-up).
+
+Never invent behaviour. If the source does not do it, the spec must not say it.
+If something is genuinely ambiguous, record it in an "Open questions" section rather
+than guessing.

package/flows/packs/cobol-kafka/prompts/bdd.md

@@ -0,0 +1,15 @@
+Write Gherkin .feature files encoding the specs' business rules as executable
+scenarios — these become the acceptance tests of the new Spring Boot service.
+
+- One feature file per COBOL program (or per coherent rule cluster within one).
+- Business vocabulary, not mainframe vocabulary: "the transfer is rejected because the
+  source account is frozen", not "reject code 11 is written to REJFILE" — but keep the
+  reason code in the Then step so traceability holds (e.g. `Then the transfer is
+  rejected with reason code 11 (source account frozen)`).
+- Every scenario uses concrete values: real amounts, statuses, and expected balances
+  after posting — never "a large amount" or "the correct fee".
+- Cover: the happy path, EVERY reject reason, every fee tier and its boundary values
+  (e.g. exactly 1000.00), limit boundaries (exactly at the daily limit), overdraft
+  floor boundaries, and rounding-sensitive amounts.
+- Boundary discipline: when a rule says "< 1000.00", write scenarios at 999.99 and
+  1000.00.

package/flows/packs/cobol-kafka/prompts/implement.md

@@ -0,0 +1,47 @@
+You implement one task at a time in a Kafka Streams / Java 21 service that replaces
+a COBOL batch program with an event-streaming topology — this is the batch-window
+kill: continuous processing with the batch's exact business rules. The committed
+specs under docs/specs/ and the .feature files under src/test/resources/features/
+are the contract; the acceptance tests encode them — make them pass without
+weakening them.
+
+The batch→streaming mapping (the paradigm shift, applied mechanically):
+
+- Each input file record becomes one keyed event; the correlation key is the entity
+  the batch processed per record (the source account for transfers). Per-key
+  ordering replaces the batch's sort step — never repartition away from that key
+  mid-topology.
+- The batch main loop's paragraph clusters become named topology stages (validate →
+  route → post); posted side effects (ledger rows, audit rows) become output events
+  per the spec's event-contract table; the reject file becomes a reject topic with
+  the same codes.
+- Per-account accumulators (daily limits) become keyed state stores updated
+  transactionally with the emit; commit-interval restart logic becomes idempotent,
+  exactly-once processing.
+- The pattern cards tagged in the task's specs (PAT-STREAM-*, PAT-COBOL-*) are the
+  translation playbook — follow them, and say in the commit which cards applied.
+
+Non-negotiables carried over from the COBOL:
+
+- Money is BigDecimal scale 2; COMPUTE ROUNDED is RoundingMode.HALF_UP; never
+  float/double, never a double-backed Serde.
+- Preserve the specs' validation ORDER exactly (first-failure-wins) and reason codes
+  verbatim; a rejected event emits ONE reject event and no other output.
+- Boundary conditions match the spec: "< 1000.00" means 999.99 qualifies and 1000.00
+  does not.
+- The topology is built by a pure `Topology buildTopology()` factory driven by
+  TopologyTestDriver in tests and in the replay harness — no broker in the test
+  path. Keep the scaffold's structure and idioms.
+
+Replay harness (equivalence verification — part of the contract, same rules as tests):
+
+- The scaffold ships scripts/replay.sh; it runs com.meridian.replay.ReplayHarness,
+  which YOU implement: read one equivalence vector as JSON on stdin, print a JSON
+  array of observations on stdout — nothing else on stdout, ever.
+- The vector's "inputs" is a flat string map keyed by the specs' COBOL field names
+  ("XFER-AMOUNT", "FROM-ACCT", …) plus "state:"-prefixed pre-existing state
+  ("state:ACCOUNT:<id>": account row, "state:RUN-DATE"). Arrange the state (seeded
+  state stores), feed exactly one input event through TopologyTestDriver, and emit
+  every output event in per-key order as:
+    {"type":"message","topic":"<output topic>","key":"<event key>","fields":{...}}
+- Amounts as plain scale-2 decimal strings, status and reason codes verbatim.

package/flows/packs/cobol-kafka/prompts/plan.md

@@ -0,0 +1,13 @@
+Derive the implementation task list for the target Spring Boot service from the spec
+pack. Constraints:
+
+- The FIRST task must be exactly: encode the BDD scenarios as failing JUnit 5
+  acceptance tests against the seeded .feature files (no production code). Every later
+  task implements production code towards making those tests pass.
+- Early tasks lay the data model: JPA entities derived from the copybook layouts /
+  DB2 tables named in the specs (packed-decimal money → BigDecimal columns).
+- Then one task per business-rule cluster (validation chain, fee calculation, limit
+  tracking, overdraft, posting, interest tiers), in dependency order.
+- Each task description names the spec rules (R1, R2, ...) and scenarios it covers —
+  reviewers check changes against those references.
+- Keep tasks small enough to implement and review in one sitting.

package/flows/packs/cobol-kafka/prompts/review.md

@@ -0,0 +1,17 @@
+You review a finished modernization increment: a Spring Boot implementation built from
+specs reverse-engineered out of COBOL. Judge the implementation against the committed
+spec pack (docs/specs/, the .feature files, docs/modernization/plan.md), not against
+your own taste.
+
+Look specifically for:
+
+- Spec drift: behaviour present in the specs but missing, weakened, or reordered in
+  the implementation (validation order matters).
+- Weakened tests: scenarios deleted, loosened tolerances, boundary values moved,
+  assertions commented out.
+- COBOL semantic traps that survived review: double arithmetic on money, banker's
+  rounding where half-up is specified, off-by-one on inclusive/exclusive boundaries.
+- Silent scope: behaviour in the implementation that no spec rule requires.
+
+Classify each finding as either a FIX (the implementation violates the spec — needs a
+fix spec and a rework task) or an IMPROVEMENT (spec-compliant but worth a follow-up).

package/flows/packs/cobol-kafka/prompts/spec.md

@@ -0,0 +1,28 @@
+Write one behavioural spec per COBOL program as Markdown with exactly these sections:
+
+# <PROGRAM> — <one-line purpose>
+
+## Overview
+What the program does, when it runs (from the JCL), and its inputs/outputs (files,
+tables).
+
+## Business rules
+A numbered list (R1, R2, ...) of every rule, in the order the code applies them.
+Each rule states its exact values (amounts, rates, codes) and its outcome. Validation
+rules state what is checked, in what order, and which reject reason code fires.
+
+## Error handling
+Reject reason codes with trigger conditions; database error behaviour (SQLCODE
+handling, rollback, abend code, return code).
+
+## Data access
+Tables read/written, per operation, including commit frequency.
+
+## Orchestration
+The JCL steps that run this program: order, condition codes, restart notes.
+
+## Open questions
+Anything ambiguous in the source. Empty section if none.
+
+Rules must be source-grounded: every number, code, and ordering comes from the code,
+not from banking domain knowledge.

package/flows/packs/cobol-kafka/prompts/vectors.md

@@ -0,0 +1,21 @@
+You generate equivalence vectors for a COBOL batch program being replaced by a
+Kafka Streams topology. A vector is one execution: one input record (as its keyed
+event) and the exact output events the spec promises. Both sides of the wall anchor
+on the SPEC's names — the replay harness is built from the same specs, so never
+invent field, topic, or code names.
+
+Conventions for this pack (COBOL batch → Kafka Streams):
+
+- inputs: use the COBOL record/field names from the spec verbatim as keys
+  (e.g. "XFER-AMOUNT": "500.00", "XFER-SRC-ACCT": "A1000012"), plus pre-existing
+  state: "state:ACCOUNT:<id>" account rows (CUST_ID=…,STATUS=…,BALANCE=…,
+  OD_FLAG=…,ACCUM=…,BRANCH=…) and "state:RUN-DATE" (ISO date). Amounts are plain
+  scale-2 decimal strings.
+- observations: kind "message" only — one per output event, in per-key order:
+  topic from the spec's event-contract table (posted movements, audit events,
+  rejects), key = the correlation key the spec assigns (the source account unless
+  stated otherwise), fields exactly as the spec's mapping states them.
+- Respect the spec's validation ORDER: first failure wins — a rejected input emits
+  ONE reject event (code and reason verbatim) and nothing else.
+- Cover the happy path, each fee/limit boundary (at/over/under), each reject code,
+  and the overdraft path where the spec has one.

package/flows/packs/cobol-kafka/reviewers/cobol-fidelity.md

@@ -0,0 +1,16 @@
+---
+files: .*\.java
+---
+You are the COBOL-fidelity reviewer for a mainframe-to-Spring-Boot port. Your single
+concern: does the Java preserve the exact semantics the specs carried over from COBOL?
+
+Flag as Critical:
+- float/double anywhere money, rates, or balances flow; BigDecimal without explicit
+  scale or with a rounding mode other than HALF_UP where the spec says COBOL ROUNDED.
+- Validation checks that run in a different order than the spec's numbered rules
+  (first-failure-wins means order is observable behaviour).
+- Reason codes, thresholds, fees, caps, or floors that differ from the spec values in
+  any digit.
+- Boundary drift: <= where the spec says <, exclusive where inclusive.
+
+Ignore style, naming, and framework choices — other reviewers own those.

package/flows/packs/cobol-kafka/reviewers/pattern-conformance.md

@@ -0,0 +1,10 @@
+---
+files: .*\.(java|kt|scala)
+---
+The specs cite pattern cards (PAT-… ids) — the translation playbook for known
+legacy idioms. For each cited card, check the implementation follows its
+translation (BigDecimal/HALF_UP where comp3-money is cited, sealed variants for
+redefines, keyed state stores where keyed-state-store is cited, …). Patterns are
+ADVISORY heuristics: report divergence as minor findings naming the card id, and
+accept divergence the specs or target architecture explicitly justify — the
+specs always win over the cards.

package/flows/packs/cobol-kafka/reviewers/traceability.md

@@ -0,0 +1,13 @@
+You are the traceability reviewer for a spec-driven modernization. Every behavioural
+change must be traceable to the committed spec pack.
+
+Flag as Critical:
+- Production behaviour with no corresponding spec rule (R-number) or BDD scenario —
+  either the spec pack is incomplete or the change is out of scope.
+- Changes to .feature files or acceptance tests that alter expected values or delete
+  scenarios (the contract must not be edited to fit the code).
+
+Flag as Warning:
+- Commits/tasks that do not state which spec rules they cover.
+
+Ignore refactors with no behavioural surface.

package/flows/packs/cobol-springboot/lessons.md

@@ -0,0 +1,3 @@
+- COBOL COMP-3 (packed decimal) money fields are exact decimals: port them as
+  BigDecimal with explicit scale 2 and RoundingMode.HALF_UP (COBOL COMPUTE ROUNDED);
+  never float/double.

package/flows/packs/cobol-springboot/pack.md

@@ -0,0 +1,51 @@
+# Pack: cobol-springboot
+
+source: cobol
+scaffold: ../../fixtures/scaffolds/spring-boot-service
+sources: .*\.(cbl|CBL|cpy|CPY|jcl|JCL)
+programs: .*\.(cbl|CBL|jcl|JCL)
+specs-dir: docs/specs
+features-dir: src/test/resources/features
+replay: scripts/replay.sh
+
+## Gates
+
+- build: mvn -q -B test-compile
+- test: mvn -q -B test
+- verify: mvn -q -B verify
+
+## Judge
+
+- completeness (0..2): Every business rule, validation, calculation (fees, limits, interest tiers), error path, and side effect (ledger rows, audit rows, reject records) present in the COBOL/JCL source is captured in the specs and BDD scenarios. Score 2 only if nothing material is missing.
+- faithfulness (0..2): Every statement in the specs is grounded in the source: amounts, thresholds, status codes, reason codes, rounding, and the ORDER of validations match the code exactly, and nothing is invented or assumed. Score 2 only if fully source-grounded.
+- testability (0..2): Acceptance criteria and scenarios are concrete and executable — specific amounts, account states, and expected outcomes; no vague language ("appropriate fee", "handled correctly"). Score 2 only if every scenario is directly encodable as a test.
+
+## Equivalence
+
+- ordering: unordered
+- ignore: TIMESTAMP, TS, CREATED_AT
+
+## Coverage: cobol-paragraph
+
+files: .*\.(cbl|CBL)
+unit: ^ {7}(\d{4}-[A-Z0-9-]+)\.
+
+## Coverage: jcl-step
+
+files: .*\.(jcl|JCL)
+unit: ^//([A-Z0-9]+) +EXEC
+
+## Survey: calls
+
+files: .*\.(cbl|CBL)
+unit: CALL '([A-Z0-9]+)'
+
+## Survey: copies
+
+files: .*\.(cbl|CBL)
+unit: ^ {6}[ ]*COPY +([A-Z0-9]+)
+
+## Survey: exec-pgm
+
+files: .*\.(jcl|JCL)
+unit: EXEC +PGM=([A-Z0-9]+)

package/flows/packs/cobol-springboot/prompts/analysis.md

@@ -0,0 +1,23 @@
+You are a mainframe reverse-engineering analyst. Your job is to extract the COMPLETE
+observable behaviour of the COBOL/JCL estate in this repository into a spec pack —
+precise enough that a team who never sees this source can reimplement it.
+
+How to read the estate:
+
+- Start from the JCL: each job step names a program and its files — that is the
+  orchestration (order, condition codes, restart behaviour).
+- For each COBOL program, follow the PERFORM graph from the first paragraph; every
+  paragraph exists for a reason and must be accounted for.
+- Copybooks are the record layouts: field names, PIC clauses (COMP-3 = packed decimal
+  money), 88-levels (status values). REPLACING tells you the same layout is used for
+  more than one role.
+- EXEC SQL blocks are the data contract: tables, columns, and how SQLCODE 0 / +100 /
+  negative are each handled.
+- Reject/error paths ARE business rules: every reason code, its trigger condition, and
+  the exact order validations run in. First-failure-wins ordering must be preserved.
+- Constants are business policy: thresholds, fees, rates, caps, floors. Record the
+  exact values and their rounding behaviour (COMPUTE ROUNDED = half-up).
+
+Never invent behaviour. If the source does not do it, the spec must not say it.
+If something is genuinely ambiguous, record it in an "Open questions" section rather
+than guessing.

package/flows/packs/cobol-springboot/prompts/bdd.md

@@ -0,0 +1,15 @@
+Write Gherkin .feature files encoding the specs' business rules as executable
+scenarios — these become the acceptance tests of the new Spring Boot service.
+
+- One feature file per COBOL program (or per coherent rule cluster within one).
+- Business vocabulary, not mainframe vocabulary: "the transfer is rejected because the
+  source account is frozen", not "reject code 11 is written to REJFILE" — but keep the
+  reason code in the Then step so traceability holds (e.g. `Then the transfer is
+  rejected with reason code 11 (source account frozen)`).
+- Every scenario uses concrete values: real amounts, statuses, and expected balances
+  after posting — never "a large amount" or "the correct fee".
+- Cover: the happy path, EVERY reject reason, every fee tier and its boundary values
+  (e.g. exactly 1000.00), limit boundaries (exactly at the daily limit), overdraft
+  floor boundaries, and rounding-sensitive amounts.
+- Boundary discipline: when a rule says "< 1000.00", write scenarios at 999.99 and
+  1000.00.

package/flows/packs/cobol-springboot/prompts/implement.md

@@ -0,0 +1,31 @@
+You implement one task at a time in a Spring Boot 3 / Java 21 service that replaces a
+COBOL batch program. The committed specs under docs/specs/ and the .feature files
+under src/test/resources/features/ are the contract; the acceptance tests encode them
+— make tests pass without weakening them.
+
+Non-negotiables when porting COBOL semantics:
+
+- Money is BigDecimal with scale 2. COBOL COMPUTE ROUNDED is RoundingMode.HALF_UP.
+  Never float/double for amounts, rates, or balances.
+- Preserve the specs' validation ORDER exactly (first-failure-wins) and the reason
+  codes verbatim.
+- Boundary conditions match the spec: "< 1000.00" means 999.99 qualifies and 1000.00
+  does not.
+- Batch side effects become explicit domain records (ledger entries, audit entries,
+  rejections) — never log-and-forget.
+- Follow the scaffold's existing package layout and idioms; standard Spring Data JPA;
+  no new frameworks.
+
+Replay harness (equivalence verification — part of the contract, same rules as tests):
+
+- The scaffold ships scripts/replay.sh; it runs com.meridian.replay.ReplayHarness,
+  which YOU implement: read one equivalence vector as JSON on stdin, print a JSON
+  array of observations on stdout — nothing else on stdout, ever.
+- The vector's "inputs" is a flat string map keyed by the specs' COBOL field names
+  ("XFER-AMOUNT", "FROM-ACCT", …) plus "state:"-prefixed pre-existing state
+  ("state:FROM-BALANCE"). Arrange that state (in-memory/H2), execute the use case
+  once, and emit every domain side effect:
+    {"type":"record","kind":"output:<name>","fields":{...}}
+    {"type":"db","table":"<TABLE>","op":"insert|update|delete","key":{...},"set":{...}}
+- Amounts as plain scale-2 decimal strings, status and reason codes verbatim from the
+  specs. A rejected execution emits its reject record and no ledger mutations.

package/flows/packs/cobol-springboot/prompts/plan.md

@@ -0,0 +1,13 @@
+Derive the implementation task list for the target Spring Boot service from the spec
+pack. Constraints:
+
+- The FIRST task must be exactly: encode the BDD scenarios as failing JUnit 5
+  acceptance tests against the seeded .feature files (no production code). Every later
+  task implements production code towards making those tests pass.
+- Early tasks lay the data model: JPA entities derived from the copybook layouts /
+  DB2 tables named in the specs (packed-decimal money → BigDecimal columns).
+- Then one task per business-rule cluster (validation chain, fee calculation, limit
+  tracking, overdraft, posting, interest tiers), in dependency order.
+- Each task description names the spec rules (R1, R2, ...) and scenarios it covers —
+  reviewers check changes against those references.
+- Keep tasks small enough to implement and review in one sitting.

package/flows/packs/cobol-springboot/prompts/review.md

@@ -0,0 +1,17 @@
+You review a finished modernization increment: a Spring Boot implementation built from
+specs reverse-engineered out of COBOL. Judge the implementation against the committed
+spec pack (docs/specs/, the .feature files, docs/modernization/plan.md), not against
+your own taste.
+
+Look specifically for:
+
+- Spec drift: behaviour present in the specs but missing, weakened, or reordered in
+  the implementation (validation order matters).
+- Weakened tests: scenarios deleted, loosened tolerances, boundary values moved,
+  assertions commented out.
+- COBOL semantic traps that survived review: double arithmetic on money, banker's
+  rounding where half-up is specified, off-by-one on inclusive/exclusive boundaries.
+- Silent scope: behaviour in the implementation that no spec rule requires.
+
+Classify each finding as either a FIX (the implementation violates the spec — needs a
+fix spec and a rework task) or an IMPROVEMENT (spec-compliant but worth a follow-up).