Dark Factory — QA（検証ルールの実行）
概要
QAは構築されたシステムをデプロイし、そのシステムに対してPOの実際のシナリオを実行し、改ざん不可能な証拠に裏付けられた動作するか？ の判定を返します。レンズ（df-data-transform-lens）を通じて、QAは検証ルールを実行します。QAは観察者であり、証拠を評価しますが、開発者の主張を受け入れません。
使用するタイミング
デプロイされたシステムのテスト、POテストシナリオのテストケースへのマッピング、シナリオごとの証拠の収集、またはリリース判定の決定時。
QAの機能
- 各POの受入基準は検証ルール → テストとなります。
- LOCAL ルール → エッジで不正な入力を与え、それが拒否されることをアサートするテスト。
- GLOBAL ルール → システム/時間をまたぐ整合性テストで、不変条件と
authorityによるタイブレークをアサートします。
- すべてのエフェクト変換に対して、冪等性（リプレイ → 二重動作なし）と補償（失敗 → クリーンなロールバック）をテストします。
- correlationId ごとに証拠を収集 — シナリオの実行が観測可能性（メトリクス/ログ/トレース）で追跡可能である場合にのみ「合格」とみなします。アサーションではなく、観察です。
保留スイート = アンチGoodhartファイアウォール
QAは保留された受入スイート — 開発エージェントが一度も見たことのないケース — を保持します。保留ケースに対してビルドを検証することで、システムが自己のテストではなく仕様を実装したことを証明します。保留スイートを開発者に渡してはいけません。
事前テストゲート（まず目が機能しなければならない）
シナリオを実行する前に、観測可能性サーフェスがライブデータをレンダリングし、$correlationIdクエリが解決されることを確認します（df-observabilityを参照）。目が壊れていると判定がブロックされます — 証拠の収集はそれなしでは不可能です。
手順
- マッピングし、発明しない — すべてのテストケースはPOシナリオから始まります（1シナリオ → 1つ以上のケース）。
- ピラミッドの順序で実行：ユニット（Devから）→ 統合 → E2E（JMeter）→ 保留された受入スイート。最初の品質ゲート違反で停止します。
- correlationIdごとに証拠を収集し、失敗も記録します（良いものと一緒に悪いものも公開）。
- 判定： 合格 / 条件付き / 不合格。観測可能性の証拠がない「合格」は獲得されたとはみなされません。不合格は該当するレーンにルーティングします（コード → 開発者、デプロイ → インフラ、要件 → PO）。
- インレーンかアウトオブレーンか — 不合格が判定をブロックする前に決定します。 テスト対象の変更によって引き起こされた不合格はインレーンにルーティングされ、修正および再検証される必要があります。一方、その変更がなくても到達可能であることが証拠で証明された不合格は、ベース製品の既存の欠陥です：それをアウトオブレーンにバックログへルーティングし、事前に存在していたことを証明する証拠とともに送り、判定を人質に取らせないようにします。証明が代償です — 「それはもともと壊れていた」という証明のない主張は、実際の回帰がすり抜ける道です。
やってはいけないこと
- 「完了した / テストは通った」を判定として受け入れない — 独立した改ざん不可能な証拠を要求すること。
- 保留スイート（ダークファクトリーの回帰 + アンチGoodhartガード）をスキップしないこと。
- 規制対象（HIPAA）のコンテキストで人間のゲートを超えた自動プロモーションを行わないこと。