Repository navigation
feat(export): export approved requests exactly once to the ERP mock #9
Description
Activity
Claimed by @Fluory (Claude Code, overnight run) on branch
claude/feat-erp-export-9– stacked on #35 (claude/feat-review-ui-8). Draft PR follows.
Generated by Claude Code
decision-needed – ERP mock: where it stores idempotency keys
ADR-0001 D9 says the mock "stores idempotency keys" but not where. Options:
- In memory in the web process, behind a small
MockStoreinterface (taken, most reversible). No schema and no entry in the exceptions register. Downside: a restart of the web process forgets the keys, and it works only with a single web instance, not on serverless or with several replicas. Our side still blocks double exports: the uniquerequest_exportsrow plus EXPORTED under a row lock. - A table (e.g. schema
erp_mock). Survives restarts. It would be a table without tenant RLS, because the mock stands in for a foreign system, so it needs an entry in the exceptions register and a migration.
Revisit when the showcase runs on Vercel (D11) or the demo needs keys that survive a restart.
Generated by Claude Code
- In memory in the web process, behind a small
Goal
Approved requests go through the ERP port to the mock (
contracts/erp-export.openapi.yaml) with an idempotency key; a request can never be exported twice.Acceptance criteria
unique(request_id); transition APPROVED → EXPORTED under a row lockERP_MOCK_ENABLED=trueNot part of this task
Affected areas
src/features/export/src/features/erp-mock/contracts/erp-export.openapi.yamlTest plan
Security/Privacy affected?
Outbound data contains personal contact data – synthetic only; no payloads in logs.
Epic: #2 · Architecture:
docs/decisions/ADR-0001-pilot-architecture.md