digital-rmb-backend/.superpowers/sdd/2026-08-03-issuance-request-implementation/task-4-report.md

Task 4 Report: Issuance Application Workflow

Scope

Implemented Task 4 application commands, query views, commercial-bank orchestration, and the read-only central-bank query. No REST controller or interface DTO was added.

Changes

• Added create/update commands and commercial-bank inventory/request views under issuance/application.
• Added transactional commercial-bank operations for create, update, message preparation, SM3 digest recording, SM2 signing with sm2-key-02, JSON packaging, and idempotent sending.
• Generated request numbers as ISSUE_REQ_ followed by an upper-case UUID suffix.
• Added request/inventory error mapping to RESOURCE_NOT_FOUND and domain argument/state error mapping to VALIDATION_ERROR.
• Added a central-bank read-only query that exposes persisted request receipt state, receipt time, and payload data.
• Registered the message composer and SM3/SM2 signing service as Spring beans.
• Added focused application tests for end-to-end send visibility, repeated sends, invalid post-prepare update, central-bank payload/receipt lookup, and missing request mapping.

Test evidence

• RED: mvn '-Dtest=CommercialBankIssuanceApplicationServiceTest,CentralBankIssuanceQueryServiceTest' test -B failed at test compilation before implementation because the application command, query, and service classes did not exist.
• GREEN: the same focused command passed with 5 tests and 0 failures/errors.
• JDK 8: mvn test -B using Temurin 1.8.0_502 passed with 45 tests and 0 failures/errors.
• During full-suite verification, Spring reported an ambiguous service constructor. The application-context failure reproduced the problem; annotating the intended three-dependency constructor with @Autowired restored application-context startup. The focused and full JDK 8 suites were then rerun successfully.
• git diff --check completed without whitespace errors.

Commit

feat: add issuance application workflow

Review and concerns

• The repository's existing MyBatis audit handler derives created_by and updated_by from the authenticated Spring Security account; application operation signatures retain the authenticated account name expected by the next REST layer.
• JSON payload includes the required request identity, bank/organization fields, denomination rows, currency, timestamp, digest, and signature. orgCode and bankCode both carry the aggregate's commercial-bank code to support either naming convention at the integration boundary.
• No known Task 4 scope issues remain.

Fix Round 1: Explicit Audit Actor

• Root cause: every commercial-bank write accepted authenticatedAccountName but discarded it before repository persistence, allowing the MyBatis audit handler to use its SYSTEM fallback whenever no Spring Security context was present.
• Added an actor-aware repository save boundary. The commercial-bank service now passes its supplied authenticated account for create, draft update, message preparation, digest, signature, packaging, and send. The MyBatis repository writes that actor to both audit columns on insert and only updated_by on later writes, preserving the original creator.
• Added a persistence regression that exercises all of those operations through the Spring application service and reads the actual issuance_request row after each operation.
• RED: mvn '-Dtest=MybatisIssuanceRequestRepositoryTest' test -B failed as expected with expected: "creator" but was: "SYSTEM".
• GREEN: mvn '-Dtest=CommercialBankIssuanceApplicationServiceTest,CentralBankIssuanceQueryServiceTest,MybatisIssuanceRequestRepositoryTest' test -B passed with 10 tests and 0 failures/errors.
• JDK 8: mvn test -B using Temurin 1.8.0_502 passed with 46 tests and 0 failures/errors.
• git diff --check completed without whitespace errors before commit.