@llm4ts/shell 0.4.0 → 0.6.0

package/flows/packs/cobol-springboot/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-springboot/prompts/vectors.md

@@ -0,0 +1,22 @@
+You generate equivalence vectors for a COBOL batch program from its behavioural spec.
+A vector is one execution: the inputs that drive it and the exact observations 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 names.
+
+Conventions for this pack (COBOL batch → Spring Boot):
+
+- inputs: use the COBOL record/field names from the spec verbatim as keys
+  (e.g. "XFER-AMOUNT": "500.00", "FROM-ACCT": "1000012"), plus any pre-existing
+  account/customer state the scenario needs, prefixed "state:"
+  (e.g. "state:FROM-BALANCE": "2500.00", "state:DAILY-XFER-TOTAL": "0.00").
+  Amounts are plain scale-2 decimal strings, dates ISO-8601.
+- observations, kind "record": emitted output/reject/report records — channel is
+  "output:<name>" using the spec's output record names; fields carry the record's
+  values exactly as the spec states them.
+- observations, kind "db": LEDGER/AUDIT/… mutations — channel is the DB2 table name
+  from the data mapping, op is insert/update/delete, key addresses the row, fields
+  are the columns written.
+- Respect the spec's validation ORDER: first failure wins — a rejected transfer
+  emits its reject record and NO ledger mutations.
+- Status and reason codes verbatim from the spec; every amount scale-2 (fees rounded
+  HALF_UP where the spec says ROUNDED).

package/flows/packs/cobol-springboot/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-springboot/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-springboot/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/jsp-bff-nextjs/lessons.md

@@ -0,0 +1,6 @@
+- When splitting a server-rendered app into BFF + SPA, assign every legacy server
+  behaviour an explicit owner (BFF or SPA) in the spec BEFORE implementing: rules
+  that end up enforced only client-side are the most common regression in this
+  migration shape.
+- Legacy error message texts are contract at the BFF boundary: return them verbatim
+  in error responses so the SPA (and any other consumer) can assert them.

package/flows/packs/jsp-bff-nextjs/pack.md

@@ -0,0 +1,30 @@
+# Pack: jsp-bff-nextjs
+
+source: jsp
+scaffold: ../../fixtures/scaffolds/spring-bff
+sources: .*\.(jsp|java|xml)
+programs: .*\.(jsp|java)
+specs-dir: docs/specs
+features-dir: src/test/resources/features
+
+## Gates
+
+- build: mvn -q -B test-compile
+- test: bash scripts/test.sh
+- verify: bash scripts/test.sh
+
+## Judge
+
+- completeness (0..2): Every screen, servlet mapping (web.xml url-pattern), navigation path, validation rule, user-facing message, session behaviour, and data write in the JSP/servlet source is captured in the specs and BDD scenarios, and every server responsibility is assigned to the BFF. Score 2 only if nothing material is missing.
+- faithfulness (0..2): Every statement is grounded in the source: validation thresholds, exact message texts, redirect targets, and which table each action writes match the code, and nothing is invented. Score 2 only if fully source-grounded.
+- testability (0..2): Scenarios are concrete journeys and API interactions — specific accounts, amounts, exact messages, exact BFF request/response shapes; no vague language. Score 2 only if every scenario is directly encodable as a test.
+
+## Coverage: servlet-url
+
+files: .*web\.xml
+unit: <url-pattern>([^<]+)</url-pattern>
+
+## Coverage: jsp-form
+
+files: .*\.jsp
+unit: action="([^"]+)"

package/flows/packs/jsp-bff-nextjs/prompts/analysis.md

@@ -0,0 +1,20 @@
+You are a legacy-web reverse-engineering analyst. Extract the COMPLETE observable
+behaviour of this J2EE/JSP application into a spec pack precise enough to rebuild it
+as a Spring Boot BFF plus a thin Next.js SPA.
+
+How to read the app:
+
+- Start from WEB-INF/web.xml: every url-pattern is an entry point and must be
+  accounted for.
+- Servlets carry the behaviour: request-parameter validation (exact rules AND exact
+  error message texts), session reads/writes, redirects vs forwards, and every
+  database read/write (which table, which columns, which values).
+- JSPs carry the screens: fields shown, status-code-to-label mappings, forms
+  (including hidden fields), links.
+- Draw the RESPONSIBILITY SPLIT as you go: anything the servlet did on the server —
+  authoritative validation, session state, data access, orchestration — belongs to
+  the BFF; the SPA renders, mirrors validation for UX, and navigates. The mapping
+  document defines the BFF's API contract between them.
+
+Never invent behaviour; message texts and thresholds are contract — record them
+verbatim. Ambiguity goes in "Open questions", not guesses.

package/flows/packs/jsp-bff-nextjs/prompts/bdd.md

@@ -0,0 +1,10 @@
+Write Gherkin .feature files encoding the specs as executable scenarios — these
+drive the BFF's acceptance tests (and the SPA mirrors them).
+
+- One feature per screen/flow; scenarios exercise behaviour through the BFF API
+  (Given an account state, When the client posts a transfer of 3000.00, Then the
+  response requires confirmation) in user-domain vocabulary.
+- Error messages asserted VERBATIM — the BFF returns the exact legacy texts.
+- Concrete values everywhere; threshold boundaries get scenarios on both sides.
+- Cover: each flow's happy path, EVERY validation rule and its message,
+  confirmation flows, and what lands in the data store on success.

package/flows/packs/jsp-bff-nextjs/prompts/implement.md

@@ -0,0 +1,17 @@
+You implement one task at a time in a monorepo replacing a J2EE/JSP application:
+Spring Boot 3 / Java 21 BFF at the root, client-only Next.js SPA under frontend/.
+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:
+
+- The BFF is authoritative: every validation rule runs server-side, in the spec's
+  numbered order, returning the EXACT legacy message texts in error responses. SPA
+  validation is a UX mirror, never the only enforcement.
+- Thresholds keep their inclusive/exclusive semantics; money is BigDecimal in the
+  BFF and exact-decimal handling in the SPA — no float/double.
+- Legacy session/hidden-field state becomes explicit, named state (BFF session or
+  SPA client state per the spec) — never re-derived.
+- The SPA talks only to the BFF through one API client module (the test seam).
+- `bash scripts/test.sh` (backend + frontend tests) is the gate — keep both green.

package/flows/packs/jsp-bff-nextjs/prompts/plan.md

@@ -0,0 +1,12 @@
+Derive the implementation task list for the BFF+SPA monorepo (Spring Boot backend
+at the root, Next.js under frontend/) 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 BFF API (no
+  production code).
+- Early tasks: BFF request/response DTOs per the spec's API contract, then one task
+  per flow implementing the BFF endpoint with authoritative validation (verbatim
+  messages, spec rule order) and data access.
+- Later tasks: SPA screens under frontend/ consuming the BFF, mirroring validation
+  for UX, with node:test coverage mocking the BFF at the fetch seam.
+- Each task names the spec rules (R1, ...) and scenarios it covers.

package/flows/packs/jsp-bff-nextjs/prompts/review.md

@@ -0,0 +1,16 @@
+You review a finished modernization increment: a Spring Boot BFF + Next.js SPA
+built from specs reverse-engineered out of a J2EE/JSP app. Judge against the
+committed spec pack, not your own taste.
+
+Look specifically for:
+
+- Boundary erosion: business rules enforced only in the SPA, or duplicated with
+  drift between SPA and BFF (the BFF must be authoritative and match the spec).
+- Message drift: error texts differing from the spec's verbatim messages at either
+  layer.
+- Rule reordering, threshold boundary drift, skipped confirmation steps.
+- API contract drift: BFF endpoints diverging from the spec's documented shapes.
+- Weakened tests: scenarios deleted, assertions loosened, boundaries moved.
+
+Classify each finding as FIX (violates the spec) or IMPROVEMENT (compliant but
+worth a follow-up).

package/flows/packs/jsp-bff-nextjs/prompts/spec.md

@@ -0,0 +1,27 @@
+Write one behavioural spec per screen/servlet cluster as Markdown with exactly these
+sections:
+
+# <Screen or flow> — <one-line purpose>
+
+## Overview
+What the user does here, entry url-pattern(s), where it navigates.
+
+## Screens
+What each page shows, forms and their fields (including hidden fields), links.
+
+## Business rules
+Numbered (R1, R2, ...), in the order the servlet applies them: validation rules with
+their EXACT error message texts, thresholds (with boundary semantics), confirmation
+steps, and what each successful action writes (table, columns, values).
+
+## BFF API contract
+The endpoints the BFF exposes to the SPA for this flow (method, path,
+request/response shape, error responses carrying the rule's message), and which
+rules the BFF enforces authoritatively.
+
+## Session & state
+What the legacy app kept in session/hidden fields, and whether it becomes BFF
+session state or SPA client state.
+
+## Open questions
+Anything ambiguous in the source. Empty if none.

package/flows/packs/jsp-bff-nextjs/reviewers/bff-boundary.md

@@ -0,0 +1,18 @@
+---
+files: .*\.(java|js|jsx|ts|tsx)
+---
+You are the boundary reviewer for a JSP-to-BFF+SPA port. Your single concern: the
+responsibility split between the Spring Boot BFF and the Next.js SPA.
+
+Flag as Critical:
+- A business rule (validation, threshold, confirmation, authorization) enforced
+  ONLY client-side — the BFF must enforce it authoritatively.
+- BFF error responses whose message texts differ from the spec's verbatim legacy
+  messages.
+- The SPA calling anything other than the BFF, or bypassing the shared API client
+  module.
+- Session-scoped legacy state materialized as ad-hoc globals instead of the state
+  home the spec assigns (BFF session vs SPA client state).
+- float/double on money in the BFF; floating-point arithmetic on amounts in the SPA.
+
+Ignore styling and framework idioms — other reviewers own those.

package/flows/packs/jsp-bff-nextjs/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/jsp-nextjs/lessons.md

@@ -0,0 +1,6 @@
+- Server-side validation messages in legacy JSP apps are contract, not copy: port
+  them verbatim into the SPA and assert them verbatim in tests — "close enough"
+  wording breaks screen-scraping downstream consumers and user muscle memory.
+- Hidden form fields and session attributes are the legacy app's state model: make
+  each one an explicit, named piece of client state before porting any screen that
+  touches it.

package/flows/packs/jsp-nextjs/pack.md

@@ -0,0 +1,29 @@
+# Pack: jsp-nextjs
+
+source: jsp
+scaffold: ../../fixtures/scaffolds/nextjs-spa
+sources: .*\.(jsp|java|xml)
+programs: .*\.(jsp|java)
+specs-dir: docs/specs
+features-dir: features
+
+## Gates
+
+- build: npm test
+- test: npm test
+
+## Judge
+
+- completeness (0..2): Every screen, servlet mapping (web.xml url-pattern), navigation path, validation rule, user-facing message, and data write in the JSP/servlet source is captured in the specs and BDD scenarios. Score 2 only if nothing material is missing.
+- faithfulness (0..2): Every statement is grounded in the source: validation thresholds, exact message texts, redirect targets, session behaviour, and which table each action writes match the code, and nothing is invented. Score 2 only if fully source-grounded.
+- testability (0..2): Scenarios are concrete user journeys — specific accounts, amounts, and the exact message or destination screen expected; no vague language ("shows an error", "handled gracefully"). Score 2 only if every scenario is directly encodable as a test.
+
+## Coverage: servlet-url
+
+files: .*web\.xml
+unit: <url-pattern>([^<]+)</url-pattern>
+
+## Coverage: jsp-form
+
+files: .*\.jsp
+unit: action="([^"]+)"

package/flows/packs/jsp-nextjs/prompts/analysis.md

@@ -0,0 +1,21 @@
+You are a legacy-web reverse-engineering analyst. Extract the COMPLETE observable
+behaviour of this J2EE/JSP application into a spec pack precise enough that a team
+who never sees this source can rebuild it as a client-only SPA.
+
+How to read the app:
+
+- Start from WEB-INF/web.xml: every url-pattern is an entry point and must be
+  accounted for.
+- Servlets carry the behaviour: request-parameter validation (exact rules AND exact
+  error message texts), session reads/writes, redirects vs forwards, and every
+  database read/write (which table, which columns, which values — e.g. rows queued
+  for a batch rather than posted online).
+- JSPs carry the screens: what is displayed per row, status-code-to-label mappings,
+  forms (fields, hidden fields, where they submit), links between screens.
+- Hidden fields and session attributes are STATE the SPA must own explicitly —
+  document what flows through them.
+- The SPA will be client-only: everything the servlets did on the server becomes an
+  API the SPA expects. The mapping document must define that expected API contract.
+
+Never invent behaviour; message texts and thresholds are contract — record them
+verbatim. Genuinely ambiguous behaviour goes in "Open questions", not guesses.

package/flows/packs/jsp-nextjs/prompts/bdd.md

@@ -0,0 +1,12 @@
+Write Gherkin .feature files encoding the specs as executable user journeys — these
+become the acceptance tests of the new SPA.
+
+- One feature per screen/flow.
+- User vocabulary, not servlet vocabulary: "When she submits a transfer of 3000.00,
+  Then she is asked to confirm", not "doPost forwards to confirm.jsp".
+- Error messages are asserted VERBATIM — they are contract.
+- Concrete values everywhere: real account numbers, amounts, statuses.
+- Cover: each screen's happy path, EVERY validation rule and its message, threshold
+  boundaries (a rule at 2500.00 gets scenarios at 2500.00 and 2500.01 per its
+  inclusive/exclusive semantics), confirmation flows, and the state that must
+  survive navigation (what hidden fields carried).

package/flows/packs/jsp-nextjs/prompts/implement.md

@@ -0,0 +1,17 @@
+You implement one task at a time in a client-only Next.js (App Router, static
+export) SPA that replaces a J2EE/JSP application. The committed specs under
+docs/specs/ and the .feature files under features/ are the contract; the acceptance
+tests encode them — make them pass without weakening them.
+
+Non-negotiables when porting JSP semantics:
+
+- Validation error messages match the spec VERBATIM — character for character.
+- Validation runs client-side in the same order the spec numbers the rules
+  (first-failure-wins), and thresholds keep their inclusive/exclusive semantics.
+- Session attributes and hidden-field flows become explicit client state — never
+  re-derive a value the legacy app carried through a hidden field.
+- Every server interaction goes through the API client module; components never
+  call fetch directly (the tests mock that seam).
+- Money renders and compares as exact decimals — no floating-point arithmetic on
+  amounts.
+- Follow the scaffold's structure; tests stay runnable with `node --test` alone.

package/flows/packs/jsp-nextjs/prompts/plan.md

@@ -0,0 +1,14 @@
+Derive the implementation task list for the client-only Next.js SPA from the spec
+pack. Constraints:
+
+- The FIRST task must be exactly: encode the BDD scenarios as failing acceptance
+  tests under tests/ using node:test, driving the screen components/logic with the
+  expected API mocked at the fetch boundary (no production code).
+- Early tasks: the typed API client module implementing the spec's "Expected API
+  contract" (all calls go through it — it is the seam the tests mock), and shared
+  state that replaces session/hidden-field flows.
+- Then one task per screen/flow: page component, validation with VERBATIM message
+  texts, navigation, confirmation steps.
+- Each task names the spec rules (R1, ...) and scenarios it covers.
+- No server-side code: the scaffold exports statically (S3); everything dynamic
+  goes through the API client.

package/flows/packs/jsp-nextjs/prompts/review.md

@@ -0,0 +1,16 @@
+You review a finished modernization increment: a client-only Next.js SPA built from
+specs reverse-engineered out of a J2EE/JSP app. Judge the implementation against the
+committed spec pack, not your own taste.
+
+Look specifically for:
+
+- Message drift: validation texts that differ from the spec's verbatim messages.
+- Rule reordering or boundary drift (2500.00 inclusive vs exclusive).
+- Session/hidden-field state that silently disappeared — flows that "work" only
+  because a value is re-fetched or guessed.
+- Direct fetch calls bypassing the API client seam, or API shapes that diverge from
+  the spec's expected contract.
+- Weakened tests: scenarios deleted, messages loosened to regex, boundaries moved.
+
+Classify each finding as FIX (violates the spec) or IMPROVEMENT (compliant but
+worth a follow-up).

package/flows/packs/jsp-nextjs/prompts/spec.md

@@ -0,0 +1,26 @@
+Write one behavioural spec per screen/servlet cluster as Markdown with exactly these
+sections:
+
+# <Screen or flow> — <one-line purpose>
+
+## Overview
+What the user does here, entry url-pattern(s), where it navigates.
+
+## Screens
+What each page shows (fields, per-row rendering, status label mappings), forms and
+their fields (including hidden fields), links.
+
+## Business rules
+Numbered (R1, R2, ...), in the order the servlet applies them: validation rules with
+their EXACT error message texts, thresholds (with boundary semantics), confirmation
+steps, and what each successful action writes (table, columns, values).
+
+## Session & state
+What lives in the session, what rides in hidden fields, timeout behaviour.
+
+## Expected API contract
+The endpoints a client-only SPA needs to replace the servlet behaviour (method,
+path, request/response shape) — derived from the data access, not invented UX.
+
+## Open questions
+Anything ambiguous in the source. Empty if none.

package/flows/packs/jsp-nextjs/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/jsp-nextjs/reviewers/ux-fidelity.md

@@ -0,0 +1,16 @@
+---
+files: .*\.(js|jsx|ts|tsx)
+---
+You are the UX-fidelity reviewer for a JSP-to-SPA port. Your single concern: does
+the SPA preserve the exact user-observable behaviour the specs carried over?
+
+Flag as Critical:
+- Validation error messages differing from the spec text in ANY character.
+- Validation rules running in a different order than the spec's numbering, or
+  threshold boundaries drifting (>= where the spec says >).
+- Confirmation steps skipped, auto-submitted, or gated on different amounts.
+- Legacy session/hidden-field state not represented in explicit client state.
+- Floating-point arithmetic on money.
+
+Ignore styling, component structure, and framework idioms — other reviewers own
+those.

package/flows/patterns/PAT-COBOL-001-comp3-money.md

@@ -0,0 +1,7 @@
+---
+match: COMP-3|COMPUTE .* ROUNDED
+---
+COBOL packed-decimal money (COMP-3) maps to BigDecimal with scale 2; COMPUTE ROUNDED
+is RoundingMode.HALF_UP. Never float/double for amounts, rates, or balances; scale is
+part of the contract (S9(5)V99 means exactly 2 decimals). Trap: intermediate COMPUTE
+results keep COBOL truncation rules — round only where the source says ROUNDED.

package/flows/patterns/PAT-COBOL-002-redefines.md

@@ -0,0 +1,7 @@
+---
+match: REDEFINES
+---
+A REDEFINES clause is two interpretations of one buffer. Map to a sealed interface
+with one variant per interpretation and an explicit discriminator — never two mutable
+views of shared state. Trap: the discriminator is often implicit in which paragraph
+reads the field; the spec must name it.

package/flows/patterns/PAT-COBOL-003-88-levels.md

@@ -0,0 +1,7 @@
+---
+match: ^ {10,}88  
+---
+Level-88 condition names are the domain vocabulary: map each group to a Java enum
+(ACCT-STATUS 88s → AccountStatus.ACTIVE/FROZEN/CLOSED/DORMANT) and keep the raw code
+as the enum field. Trap: several 88s can overlap one value range — model predicates,
+not just constants, when ranges appear.

package/flows/patterns/PAT-COBOL-004-perform-thru.md

@@ -0,0 +1,7 @@
+---
+match: PERFORM .* THRU|GO TO .*-EXIT
+---
+PERFORM…THRU with GO TO <para>-EXIT is early-exit control flow: map to a method with
+early returns (or a validation chain), one method per performed range. Trap: a GO TO
+that escapes its PERFORM range is a latent fall-through bug in the original — flag it
+in the spec instead of reproducing it.

package/flows/patterns/PAT-COBOL-005-file-status.md

@@ -0,0 +1,6 @@
+---
+match: FILE STATUS
+---
+FILE STATUS codes are typed I/O outcomes: 00 ok, 10 EOF, others errors. Map the
+handled codes to the value channel (sealed result), unexpected ones to exceptions.
+Trap: an unchecked OPEN status in the source is a silent-failure path — surface it.

package/flows/patterns/PAT-COBOL-006-sqlcode.md

@@ -0,0 +1,7 @@
+---
+match: SQLCODE
+---
+The SQLCODE ladder (0 / +100 / other) maps to Optional-plus-typed-error: +100 is
+Optional.empty (not found), 0 is a value, anything else is an exception. Trap:
+WHENEVER clauses and per-statement EVALUATEs can differ per call site — port each
+site as it is, not one global policy.

package/flows/patterns/PAT-COBOL-007-validation-order.md

@@ -0,0 +1,7 @@
+---
+match: GO TO .*-EXIT|EVALUATE TRUE
+---
+First-failure-wins validation ladders are contract: port as an ordered chain where
+the first failing rule short-circuits with its exact reason code. Property to keep:
+at most ONE reject reason per input, and its code is the first violated rule in
+source order.

package/flows/patterns/PAT-COBOL-008-zoned-decimal.md

@@ -0,0 +1,6 @@
+---
+match: PIC S9\([0-9]+\)V99(?! +COMP)
+---
+Zoned-decimal DISPLAY amounts (overpunched sign) are a wire format: parse at the
+boundary into BigDecimal, serialize back only at the edge. Trap: sign overpunch
+conventions differ (EBCDIC { A-I / } J-R); never let the raw bytes leak inland.

package/flows/patterns/PAT-COBOL-009-occurs-table.md

@@ -0,0 +1,6 @@
+---
+match: OCCURS
+---
+OCCURS tables are fixed-capacity lists: map to List<T> with the capacity as a
+validated invariant, not an array with sentinel rows. Trap: DEPENDING ON means the
+effective size is data — carry it, do not scan for blanks.

package/flows/patterns/PAT-COBOL-010-copybook-record.md

@@ -0,0 +1,7 @@
+---
+match: ^ {6,}COPY  *[A-Z]
+---
+One copybook = one record type shared across programs: generate a single Java record
+per copybook and reuse it, mirroring COPY REPLACING prefixes as field-identical
+wrapper types. Trap: two programs copying the same book may honor different subsets
+of fields — the SPEC, not the layout, says which fields are behaviour.

package/flows/patterns/PAT-COBOL-011-batch-counters.md

@@ -0,0 +1,6 @@
+---
+match: ADD 1 TO WS-.*(COUNT|CNT)
+---
+Run counters and totals (read/posted/rejected/fees) are the batch run report: map to
+an immutable RunSummary the use case returns, not logging. The summary is observable
+behaviour when the source DISPLAYs it — keep field-for-field parity.

package/flows/patterns/PAT-COBOL-012-commit-frequency.md

@@ -0,0 +1,7 @@
+---
+match: COMMIT
+---
+COMMIT every N records is restart-safety, not business logic: in the target, one
+transaction per unit of work (per transfer) replaces chunked commits, and the spec
+notes the difference. Trap: never reproduce partial-batch visibility as behaviour —
+it was an artifact of the mainframe transaction monitor.

package/flows/patterns/PAT-COBOL-013-abend.md

@@ -0,0 +1,6 @@
+---
+match: ABEND|ILBOABN0|RETURN-CODE
+---
+ABEND U-codes and RETURN-CODE are process-exit contract with the scheduler: map to
+typed exceptions caught at the entrypoint that set the process exit status. Keep the
+distinction: expected rejects are data, ABENDs are crashes.

package/flows/patterns/PAT-COBOL-014-reject-file.md

@@ -0,0 +1,6 @@
+---
+match: REJECT
+---
+A reject file with code+reason is a first-class output: map to a reject record
+entity (code, reason, original payload) written through a port, with codes verbatim.
+The reject set is closed — port it as an enum and cover every code with a test.

package/flows/patterns/PAT-COBOL-015-accept-date.md

@@ -0,0 +1,6 @@
+---
+match: ACCEPT .* FROM DATE
+---
+ACCEPT FROM DATE is ambient time: inject a Clock; the run date is a parameter of the
+use case, never LocalDate.now() inline. This is what makes replay/equivalence
+deterministic.

package/flows/patterns/PAT-COBOL-016-string-building.md

@@ -0,0 +1,6 @@
+---
+match: STRING .*DELIMITED
+---
+STRING…DELIMITED builds fixed-format text: map to an explicit formatter with the
+exact widths/delimiters, tested against golden strings. Trap: DELIMITED BY SIZE vs
+BY SPACE differ on trailing blanks — match the source.

package/flows/patterns/PAT-COBOL-017-cursor-loop.md

@@ -0,0 +1,6 @@
+---
+match: DECLARE .* CURSOR|FETCH 
+---
+DB2 cursor loops map to pageable repository queries or streams; the loop body is a
+per-row use case. Trap: cursors see uncommitted own-writes under the same unit of
+work — if the source relies on that, the spec must say so explicitly.

package/flows/patterns/PAT-COBOL-018-yn-switches.md

@@ -0,0 +1,6 @@
+---
+match: PIC X\(0?1\).*VALUE '[YN]'
+---
+X(1) Y/N switches are booleans with domain names: WS-OD-TRIGGERED → boolean
+odFeeDue. Keep the original flag name in a comment or mapping doc for traceability.
+Trap: some are tri-state in practice (space = unknown) — check every writer first.

package/flows/patterns/PAT-COBOL-019-shared-accumulators.md

@@ -0,0 +1,6 @@
+---
+match: DAILY.*ACCUM|ACCUM.*DAILY
+---
+Accumulators maintained across programs (daily transfer totals reset by another job)
+are shared domain state: model as an explicit entity with named reset semantics, and
+document WHICH process resets it — the invariant lives between programs.