審査機関向け審査システムの構築
構築工程
MariaDB 10.11.11 上で稼働
| 段階 | 内容 | 状態 |
|---|---|---|
| 段階1 | fork と不要モジュール削除 | 完了（12コミット / −38,485行） |
| 段階2 | テナント解決の起点変更と顧客マスタ | 完了 |
| 段階3-0 | MariaDB 切替 | 完了 |
| 段階3-1〜3-6 | 審査構造への再編 | 完了 |
| 段階4 | 申込フロー再構築・ランク語彙 | 未着手 |
| 段階5 | RiskAssessment / Project 削除・匿名化辞書 | 未着手 |
| 段階6 | AI支援の語彙・解釈原則の追記 | 未着手 |
監査システムからの変更点
被審査組織は台帳である・・審査機関にとって被審査組織は登録番号・初回認証日・認証範囲を持つマスタであり、審査計画の副産物として属性が空のレコードが増える構造にはできない・・・認証契約に基づいて台帳に登録し、それから審査計画を立てる順序が実務に合う
| 仕様書 | 当初 | 確定 |
|---|---|---|
| §2.2 | client_sites（有期事業所マスタ）を新設 | 中止。審査対象は自由記述で足りる |
| §2.3 | audit_no を varchar 化して回次を保持 | audit_type へリネーム。自動採番も廃止 |
| §2.4 | 審査チームはaudit_reports 配下のまま | audit_plan_auditors へ移設（審査単位で任命） |
| §4 | チェックリスト3段構造をそのまま使う | 全面撤回。質問マスタ・テンプレート機構を全廃 |
| §8 | AUD-RPT を個別審査の計画・報告書として維持 | 画面ごと廃止。階層が1段浅くなった |
| §2.1 | 被審査組織を自由記述入力→自動登録 | 不採用CLI-EDIT に一本化（台帳の質を守るため） |
| 段階3指示 | AUD-HOME を AUD-PLAN 配下へ | 据え置き。AUD-RPTS が既に役割を果たしていた |
技術的な収穫
段階3-0 で MariaDB へ切り替えた直後から、SQLite では永久に検出できない
種類の問題が続けて出た・・phpunit.xml が SQLite を明示しているため、テストが全件通っていても MariaDB で落ちる
| # | 内容 | 発見 |
|---|---|---|
| 1 | 識別子は64文字まで（SQLite は無制限） | migrate 失敗 |
| 2 | FK が残ると索引を落とせない | 列削除時 |
| 3 | 逆方向: SQLite はユニーク索引が残ると列を落とせない | 3-3 |
移築作業の過程で、iso_app 由来の問題
| # | 内容 | 発見場所 |
|---|---|---|
| 1 | 権限昇格の経路 — 選択肢に無い role のユーザーを編集して保存すると、先頭＝システム管理者に昇格 | 段階2-4 |
| 2 | 削除の権限ゲートの穴 — 画面から呼ばれない audit_reports.destroyが、正規経路より弱い権限で通る | 段階3-5 |
| 3 | ISO採用設定が保存しても画面に反映されない（保存＝顧客／表示＝審査機関) | 段階3-6 |
| 4 | AUD-CHK の「リーダー監査員」が常に「―」（段階11以降どのコードも書き込んでいない） | 段階3-2 |
| 5 | users.role が文字列カラムで default ‘user’（cast が救っていただけ） | 段階2-4 |
| 6 | テストが Alpine のコメントへの偶然一致で実質ノーチェックだった | 段階3-6 |
実機確認
| # | 画面 | 確認内容 |
|---|---|---|
| 1 | 全体 | 顧客選択（CLI-LIST）→ 審査計画作成 → 指摘まで一巡 |
| 2 | タブ | 5本の配色（CLI-LIST が teal）と折り返し |
| 3 | AUD-PLAN | 審査チーム欄、指摘集計、審査種別の自由記述 |
| 4 | AUD-LIST | 新しい列構成（被審査組織名・審査種別・審査リーダー） |
| 5 | AUD-CHK | 組織実態8項目＋箇条7区分が生成されるか |
| 6 | ORG-HOME | 4ブロックに縮小された構成 |
| 7 | CLI-EDIT | 移設された部門管理・ISO採用・会社概要3種 |
| 8 | AUD-SCH | 編集モーダルが審査日のみになっているか |
| 9 | 全体 | 語彙の残り（「監査」が残っていないか。主要10画面は自動検出済み） |