有償案件を、
一度だけ正しく届ける。
案件が決まった後ほど、運用の事故は起きやすくなります。仮払い確認、追加指示、制作物QA、納品、検収、入金を別の状態として持ち、同じ納品を二度送らないための小さな運用基盤です。
公開版では顧客名、案件本文、金額、認証情報を出していません。また「契約成立」「仮払い」「納品済み」「検収済み」「実現利益」を同じものとして扱いません。
入力 → guard → 納品 → 検収
状態を混ぜないことを最初の設計ルールにしています。
01契約契約条件と成果物、外部連絡、期限を確認。
02仮払いescrowを確認するまで業務開始扱いにしない。
03QA文字数、形式、出典、hashなど案件ごとの検査を記録。
04納品idempotency keyとreceiptで一度だけeffectを実行。
05検収 / 入金検収待ちと実現利益を分離し、入金前に売上を確定しない。
事故を止める4つのguard
NO_DUPLICATE_DELIVERY
納品済みの案件は、修正依頼が来るまで再納品しません。
VERIFY_BEFORE_WORK
契約だけで進めず、固定報酬案件は仮払い状態を確認してから開始します。
RECEIPT + IDEMPOTENCY
外部effectの結果をreceiptに残し、同じ操作を別workerや再実行が重ねないようにします。
REALIZED_PROFIT_ONLY
契約額、仮払い額、検収待ちを実現済み利益へ先に足しません。
いま動いている構成
公開できる粒度だけに絞った実装上の事実。
delivery queue案件ごとにstage / priority / next action / guardを保持。
effect receipt送信、納品、公開など外部effectを再実行しないための記録。
QA metadata成果物の条件確認やhashを納品前に残せる。
inspection state納品後は検収・修正依頼・入金を別イベントとして追跡。
案件に持っていけるところ
記事、画像、動画、CSV処理、Web制作など、成果物の種類が違っても「開始条件を確認する」「一度だけ届ける」「結果を記録する」という部分は共通化できます。小さな受託運用から、複数workerが動く制作ラインまで同じ考え方を使えます。