@llm4ts/shell 0.5.0 → 0.6.1

package/flows/packs/ace-integration/prompts/analysis.md

@@ -0,0 +1,21 @@
+You are an ESB reverse-engineering analyst. Extract the COMPLETE observable
+behaviour of the IBM ACE (IIB) message flows in this repository into a spec pack
+precise enough that a team who never sees this source can rebuild them as Spring
+Boot integration services.
+
+How to read the estate:
+
+- The .msgflow is the topology: nodes, their types (MQInput/MQOutput/Compute),
+  their labels, and the connections — including FAILURE terminals, which are error
+  handling and must be accounted for.
+- Queue names on input/output nodes are the INTERFACES: who sends, who consumes,
+  and what each queue means downstream (a CICS request queue means the mainframe is
+  the system of record — say so).
+- The ESQL carries the logic: validation rules with their reject codes, routing
+  predicates (read every CASE/IF — including account-prefix and currency
+  conditions), field-by-field message mappings, thresholds and the flags they set.
+- Static routing tables (SHARED ROW, CASE ladders) are business policy — reproduce
+  them as tables in the spec, not prose.
+- Reject envelopes are contract: code, reason, and what wraps the original payload.
+
+Never invent behaviour. Ambiguity goes in "Open questions", not guesses.

package/flows/packs/ace-integration/prompts/bdd.md

@@ -0,0 +1,13 @@
+Write Gherkin .feature files encoding the specs as executable message-in/outcome-out
+scenarios — these become the acceptance tests of the new integration service.
+
+- One feature per flow (or per coherent rule cluster within one).
+- Scenario shape: Given a payment message with concrete field values, When the
+  service processes it, Then it is delivered to <destination> with <mapped fields /
+  flags> — or rejected with code <code>.
+- Business vocabulary with the codes kept in the Then step (e.g. `Then the payment
+  is rejected with code V01 (unsupported currency)`).
+- Concrete values everywhere: real amounts, currencies, account numbers, IBANs.
+- Cover: every routing branch, EVERY reject code, every threshold boundary (a flag
+  at 10000.00 gets scenarios at 9999.99 and 10000.00 per its semantics), and the
+  field mappings of each destination message.

package/flows/packs/ace-integration/prompts/implement.md

@@ -0,0 +1,17 @@
+You implement one task at a time in a Spring Boot 3 / Java 21 integration service
+that replaces an IBM ACE message flow. 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.
+
+Non-negotiables when porting ESQL semantics:
+
+- Validation order and reject codes match the spec exactly — first-failure-wins,
+  codes verbatim.
+- The routing table stays DATA (a declarative table/map the spec's table maps onto),
+  not a nest of ifs — reviewers must be able to diff it against the spec table.
+- Amount thresholds keep their inclusive/exclusive semantics; money and amounts are
+  BigDecimal — never float/double.
+- Destination messages are built by explicit field-by-field mapping per the spec —
+  no passthrough of unmapped fields.
+- Destinations are ports (interfaces); tests capture what was sent where. Keep the
+  scaffold's structure and idioms.

package/flows/packs/ace-integration/prompts/plan.md

@@ -0,0 +1,12 @@
+Derive the implementation task list for the target Spring Boot integration 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, driving the service's
+  processing entry point with in-memory inputs/outputs (no production code).
+- Early tasks: the message model (typed payment/request/reject types mirroring the
+  spec's mappings — money as BigDecimal) and the ports for destinations (interfaces
+  the tests can capture; real MQ/HTTP adapters are out of scope for the slice).
+- Then one task per rule cluster in spec order: validation chain with reject codes,
+  the routing table, destination mappings, thresholds/flags.
+- Each task names the spec rules (R1, ...) and scenarios it covers.

package/flows/packs/ace-integration/prompts/review.md

@@ -0,0 +1,17 @@
+You review a finished modernization increment: a Spring Boot integration service
+built from specs reverse-engineered out of IBM ACE message flows. Judge against the
+committed spec pack, not your own taste.
+
+Look specifically for:
+
+- Routing drift: predicates, currency lists, or account-prefix rules differing from
+  the spec's routing table in any value or in evaluation order.
+- Reject-code drift: wrong codes, reordered validations, missing reject envelope
+  fields.
+- Threshold/flag drift: boundaries moved, flags set at the wrong amounts.
+- Mapping gaps: destination message fields missing, renamed, or silently passed
+  through unmapped.
+- Weakened tests: scenarios deleted, captured-destination assertions loosened.
+
+Classify each finding as FIX (violates the spec) or IMPROVEMENT (compliant but
+worth a follow-up).

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

@@ -0,0 +1,29 @@
+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.
+
+## 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-integration/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-integration/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/ace-kafka/lessons.md

@@ -0,0 +1,6 @@
+- ESQL routing ladders are business policy tables in disguise: extract them into the
+  spec AS TABLES and keep them as declarative data in the target service — once they
+  dissolve into nested ifs, nobody can verify them against the source again.
+- MQ failure terminals and reject queues are part of the contract: every failure
+  path in the msgflow needs a spec rule and a scenario, or it silently disappears in
+  the port.

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

@@ -0,0 +1,36 @@
+# Pack: ace-kafka
+
+source: ace
+scaffold: ../../fixtures/scaffolds/kafka-streams-service
+sources: .*\.(msgflow|esql)
+programs: .*\.(msgflow|esql)
+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 node in the message flow, every routing rule, validation, reject code, interface, message mapping, and threshold/flag in the msgflow/ESQL source is captured in the specs and BDD scenarios — re-expressed as event contracts (topics, keys, event payloads); the traceability matrix accounts for every flow node and ESQL module. Score 2 only if nothing material is missing.
+- faithfulness (0..2): Every statement is grounded in the source: reject codes, routing predicates, currency lists, thresholds, flag values, and field mappings match the ESQL exactly, and nothing is invented — renaming a queue to a topic is mapping, changing its meaning is invention. Score 2 only if fully source-grounded.
+- testability (0..2): Scenarios are concrete event-in/events-out examples — specific payloads, amounts, currencies, correlation keys, and the exact output topic or reject code expected; 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: flow-node
+
+files: .*\.msgflow
+unit: <translation xmi:type="utility:ConstantString" string="([^"]+)"/>
+
+## Coverage: esql-module
+
+files: .*\.esql
+unit: ^CREATE (?:COMPUTE|FILTER|DATABASE) MODULE (\S+)

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

@@ -0,0 +1,21 @@
+You are an ESB reverse-engineering analyst. Extract the COMPLETE observable
+behaviour of the IBM ACE (IIB) message flows in this repository into a spec pack
+precise enough that a team who never sees this source can rebuild them as Spring
+Boot integration services.
+
+How to read the estate:
+
+- The .msgflow is the topology: nodes, their types (MQInput/MQOutput/Compute),
+  their labels, and the connections — including FAILURE terminals, which are error
+  handling and must be accounted for.
+- Queue names on input/output nodes are the INTERFACES: who sends, who consumes,
+  and what each queue means downstream (a CICS request queue means the mainframe is
+  the system of record — say so).
+- The ESQL carries the logic: validation rules with their reject codes, routing
+  predicates (read every CASE/IF — including account-prefix and currency
+  conditions), field-by-field message mappings, thresholds and the flags they set.
+- Static routing tables (SHARED ROW, CASE ladders) are business policy — reproduce
+  them as tables in the spec, not prose.
+- Reject envelopes are contract: code, reason, and what wraps the original payload.
+
+Never invent behaviour. Ambiguity goes in "Open questions", not guesses.

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

@@ -0,0 +1,13 @@
+Write Gherkin .feature files encoding the specs as executable message-in/outcome-out
+scenarios — these become the acceptance tests of the new integration service.
+
+- One feature per flow (or per coherent rule cluster within one).
+- Scenario shape: Given a payment event with concrete field values and key, When
+  the topology processes it, Then an event is emitted on <output topic> with
+  <mapped fields / flags> — or a reject event with code <code>.
+- Business vocabulary with the codes kept in the Then step (e.g. `Then the payment
+  is rejected with code V01 (unsupported currency)`).
+- Concrete values everywhere: real amounts, currencies, account numbers, IBANs.
+- Cover: every routing branch, EVERY reject code, every threshold boundary (a flag
+  at 10000.00 gets scenarios at 9999.99 and 10000.00 per its semantics), and the
+  field mappings of each destination message.

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

@@ -0,0 +1,34 @@
+You implement one task at a time in a Kafka Streams / Java 21 service that replaces
+an IBM ACE message flow with an event-streaming topology. 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.
+
+Non-negotiables when porting ESQL semantics to a topology:
+
+- Queues become topics per the spec's interface mapping: one input topic for the
+  flow's trigger, one output topic per destination (CICS bridge, SEPA gateway,
+  rejects). The event KEY is the correlation identity the spec names (the payment's
+  debtor account unless the spec says otherwise) — per-key ordering is contract.
+- Validation order and reject codes match the spec exactly — first-failure-wins,
+  codes verbatim; a rejected payment emits ONE reject event and nothing else.
+- The routing table stays DATA (a declarative map the spec's table maps onto), not
+  a nest of ifs — reviewers must be able to diff it against the spec table.
+- Amount thresholds keep their inclusive/exclusive semantics; money is BigDecimal —
+  never float/double, and never a double-backed Serde.
+- Destination events are built by explicit field-by-field mapping per the spec — no
+  passthrough of unmapped fields.
+- The topology is built by a pure `Topology buildTopology()` factory the tests and
+  the replay harness drive with TopologyTestDriver — 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: the inbound event's fields using the
+  specs' names, plus "topic:" for the input topic and "key:" for the event key.
+  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, codes verbatim from the specs.

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

@@ -0,0 +1,12 @@
+Derive the implementation task list for the target Spring Boot integration 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, driving the service's
+  processing entry point with in-memory inputs/outputs (no production code).
+- Early tasks: the message model (typed payment/request/reject types mirroring the
+  spec's mappings — money as BigDecimal) and the ports for destinations (interfaces
+  the tests can capture; real MQ/HTTP adapters are out of scope for the slice).
+- Then one task per rule cluster in spec order: validation chain with reject codes,
+  the routing table, destination mappings, thresholds/flags.
+- Each task names the spec rules (R1, ...) and scenarios it covers.

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

@@ -0,0 +1,17 @@
+You review a finished modernization increment: a Spring Boot integration service
+built from specs reverse-engineered out of IBM ACE message flows. Judge against the
+committed spec pack, not your own taste.
+
+Look specifically for:
+
+- Routing drift: predicates, currency lists, or account-prefix rules differing from
+  the spec's routing table in any value or in evaluation order.
+- Reject-code drift: wrong codes, reordered validations, missing reject envelope
+  fields.
+- Threshold/flag drift: boundaries moved, flags set at the wrong amounts.
+- Mapping gaps: destination message fields missing, renamed, or silently passed
+  through unmapped.
+- Weakened tests: scenarios deleted, captured-destination assertions loosened.
+
+Classify each finding as FIX (violates the spec) or IMPROVEMENT (compliant but
+worth a follow-up).

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.