@llm4ts/shell 0.5.0 → 0.6.1

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).

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.