FACTUAL ACTIVITY RECORD · 実際の作業をもとにした活動記録
Soshikizo Labの統合仕様書と監査基準を固定する
要件、設計、運用、受入条件を構築順の一つの正本へまとめる
目的
fresh production productを複数段階で構築する前に、要件、設計判断、trust boundary、検証条件を一つの正本で追えるようにする必要があった。
仕様の欠落、章順の入替え、監査scriptとの不一致を、人の目だけに頼らず検出できる基準が必要だった。
実装
文書統制からrelease完了までを11章に分け、monorepo、databaseとAuth、同期、Control Center、local service、Public Web、編集実行、IaC、end-to-end受入を依存順に記述した。各章は要件、要件を満たす設計、検証・受入条件の順に読む構造とした。
- fresh resourceだけで成立し、旧環境の移行やdual-writeを行わないsystem boundaryを固定する。
- Public、remote control、local control、content screeningのtrust boundaryを分離する。
- read-only参照元のlocal byteをcontent-addressed snapshotへ固定し、secretや生成物を除外する。
- brand designとproduct固有interactionの優先順位、accessibility、security、費用guardを規定する。
- 90件のrequirement IDと50件のend-to-end受入条件を監査対象として数える。
監査manifestには仕様書とcheckerのSHA-256、章番号と構築順、要件数、受入条件数を保存した。checkerは正本のhash、章の完全性と順序、requirement IDの一意性、受入条件数を検査する。
一次Commitで追加された仕様監査scriptから、chapter連番とboundaryを機械検査する部分を示す。digestやlocal参照pathは公開説明へ含めていない。
図を描画しています…
確認したこと
確認結果
11章が0から10まで構築順に揃い、90件のrequirement IDが収録された。
50件のend-to-end受入条件が監査対象として記録された。
仕様書と監査checkerそれぞれのSHA-256がmanifestへ固定された。
正本、manifest、監査scriptの3点が同時に作成され、仕様の自己整合を機械確認できる状態になった。
統合仕様書と監査基準は対象へ反映された。仕様に基づく各機能の実装はcutoff時点では未開始と明記されていた。
完了とした根拠
全11章、90件の要件、50件のend-to-end受入条件を一つの正本へ統合し、内容hash・章順・ID一意性・件数を監査するmanifestとcheckerを揃えたことをもって完了とした。