Loop report

レポート作成手順

レポートは「昇り」の受け渡しであり、受け手(issue 起票者と統合ゲート)の待ち位置は契約の report フェーズの waiting_level である(要点は「要件⇔結果の対応表と結論。生データは添付リンクのみ」)。 生ログをそのまま貼る報告は TOO_CONCRETE として差し戻される。

必須構成(契約から引く)

欄の正は契約(.tasuki/profile.yaml)の report_required_fields であり、各欄の意味は契約の欄コメントが定める。 この skill に欄名を写さない(導入先が override で欄を足しうるため。ここに列挙すると、契約に欄を足したときに食い違う)。

契約の全欄を ## 見出し(欄名と完全一致)として書き、そのうえで次の共通規則に従う。

1. 対応表の欄がある契約では、表形式で N対1 に対応づける:issue 本文の要件の各項目(受け入れ条件、成功基準)に、結果を1行で対応づける。どの要件にも対応しない結果、どの結果にも対応しない要件(孤児要件)を残さない。要件 ID は issue 本文の並び順で受け入れ条件を AC-1、AC-2 …、成功基準を SC-1 … と採番し(欄が無い契約では、ある欄だけに適用する)、再出力時も同じ採番を維持する(振り直すと差し戻し履歴、発振検知との対応が壊れる)

   要件 ID	要件	結果	判定
   AC-1	(要件を引用)	(1行の結果)	達成 / 未達 / 部分達成

2. 結論の欄は冒頭で言い切る:成功基準を満たしたか、打ち切り条件に達したかを最初の一文にする

3. 成果の前提を辿る欄がある契約では、名前で列挙する:このタスクで読み込んだ skill(プロジェクト skill を含む)と、委譲したプロジェクト subagent を名前で列挙する(無ければ「なし」)。読み手が「この成果はどの規約と道具を前提に作られたか」を辿れるようにするためであり、承認材料の「どこで検められたか」の裏付けにもなる

出力衛生(観点「出力衛生」)

レポートと issue コメントは監査ログとして永続化するため、混入は取り消せない。

• 掲載可能なのは集計値のみ。生サンプル(個々のデータレコード)は貼らない
• secrets、API キー、個人情報を含む出力はマスキングしてから引用する
• エラーログを引用する場合は、該当行のみを抜粋し、環境変数やトークンが含まれていないか確認する

よくある差し戻し

差し戻し	原因
TOO_CONCRETE	生ログ、生データの本文貼り付け、テスト出力の全文引用
TOO_ABSTRACT	対応表なし、「うまくいった」だけの結論、契約の必須欄の欠落
差し戻し(観点「テストの信頼性」)	期待値が実装出力由来(仕様ではなく実装に合わせたテスト)の疑い