1 つの 5-credit task が SaaS 全体をテストする理由

コミット b16b416 に基づきます。

多くの demo は button が API を呼ぶことだけを証明します。Browser replay、write 間の crash、provider accept 後の timeout、object success 後の DB failure、refund を一時記録できない場合は証明しません。

Sushi SaaS は意図的に単純な image task で接続部分をテストします。Image は local SVG で、周囲の workflow が reference です。

Request は same-origin、rate limit、Better Auth、organization、entitlement、quota、pooled ledger、task、durable queue、provider idempotency、private S3、signed URL、localized error、admin recovery、log、test を通ります。

Idempotency-Key と fingerprint が request を識別し、task UUID が transaction、job dedupe、provider identity、file、object key を導出します。そのため replay は既存 effect を発見して完了できます。

• insert 後 crash：deterministic spend を 1 回適用
• spend 後 crash：job を 1 回 dispatch
• object active で task 未完了：worker が link を修復
• refund 後 state 未完了：replay が既存 refund を発見

Failure 用の独立 retry budget

Provider は 5 attempts、job は 8 です。追加 3 回は refund 時の PostgreSQL failure を補償するためで、provider 再呼び出しではありません。Task は refunding に入り、deterministic refund 後だけ failed になります。

Mock は cost、credential、non-determinism を避けます。E2E は request replay、正確な 5-credit debit、worker、signed Garage object を確認し、DB test は terminal failure で 1 spend/1 refund を証明します。

実際の生成サービスは src/services/ai/image.ts に実装し、冪等キー、AbortSignal、公開エラーの契約を保ちます。本番への適用には、ページ、API、タスクサービスで明示的な受付条件も必要です。既存のデモ条件は本番で常に閉じています。現在の出力型は SVG と生成元 mock に限定されるため、実際の形式とファイル情報を定義して検証してください。その適用後も、クレジット、永続実行、非公開ストレージ、状態取得、復旧の契約はモデルから独立させられます。

これが production-minded の意味です。Clone の認証ではなく、高価な failure question を visible/testable にします。

画像 workflowとテスト・CIを参照してください。