id: T052
name: CreditService Persistence & Hardening
goal: Implement persistent storage for CreditService (ChainFire/FlareDB) and harden for production use
status: planned
priority: P1
owner: peerA (spec), peerB (impl)
created: 2025-12-12
depends_on: [T042]
blocks: [T039]

context: |
  **User Direction:**
  "PROJECT.md Item 13: クレジット・クオータ管理（CreditService）"
  "銀行のようなサービス" -> Requires durability/persistence (cannot be InMemory)
  "メタデータのストア... はFlareDBにすると良さそう"

  **Current State (T042):**
  - MVP implemented with InMemoryStorage
  - Full API and Admission Control logic exists
  - Missing: Persistent storage backend

acceptance:
  - CreditService uses ChainFire or FlareDB for persistent storage
  - Wallet balances survive service restart
  - Transactions are durably logged
  - Concurrency control (optimistic locking/CAS) verified

steps:
  - step: S1
    name: Storage Backend Implementation
    done: Implement CreditStorage trait using ChainFire/FlareDB
    status: blocked
    owner: peerB
    priority: P0
    blocked_reason: Compilation errors in `creditservice-api` related to `chainfire_client` methods and `chainfire_proto` imports.
    notes: |
      **Decision (2025-12-12): Use ChainFire.**
      Reason: `chainfire.proto` supports multi-key `Txn` (etcd-style), required for atomic `[CompareBalance, DeductBalance, LogTransaction]`.
      FlareDB only supports single-key `CAS`, which is insufficient for ledger integrity.
      
      Implementation:
      - Implement `CreditStorage` trait using `chainfire-client`.
      - Map `Wallet` and `Transaction` to ChainFire keys.
      - Use `TxnRequest` for critical path.

  - step: S2
    name: Migration/Switchover
    done: Switch service to use persistent backend
    status: pending
    owner: peerB
    priority: P0

  - step: S3
    name: Hardening Tests
    done: Verify persistence across restarts
    status: pending
    owner: peerB
    priority: P1

evidence: []
notes: |
  Refines T042 MVP to Production readiness.