基本設計書（抜粋）
1. システム構成概要
•Webアプリ層、アプリケーションサーバ層、DB層の3層構造を採用
•深夜帯、DB層に不可視フォルダ（第十三階層）が実体化し、古い写真データ、謎の文字列、及び「旧社宅間取り図」が格納される
•負荷分散装置は通常動作時は沈黙、0:13〜0:33の間、かすかな悲鳴に似たノイズ発生
2. 画面設計
•通常画面：標準的なUI。
•深夜儀式画面：背景が闇色に変化し、テキストボックスに呪句入力領域を表示
•「覗き込んではならない画面」：誤操作で開くことがある隠し画面。ここに長居するとモニタに蒸気状の手形が浮かぶ報告あり
3. データベース設計
•T_DOCUMENTS：通常のドキュメント格納テーブル
•T_EMPLOYEES：現行従業員リスト。深夜アクセス時、過去失踪社員IDが一時的に復活
•T_SILENT_VOICES：深夜ログ用テーブル。囁き声や奇妙な影響度合いを記録。
•不定形スキーマ”INNER_DEPTH”：儀式時アクセス可能。アクセス中、DBサーバCPU負荷は奇妙な三角波を描き、冷却ファンから冷気ではなく淡い白煙発生
4. ロジック設計
•通常ロジック：検索、参照、更新
•深夜儀式ロジック：
1.0:00過ぎ、RitualContextManager起動
2.呪句入力後、1分間画面暗転
3.暗転解除後、一部データが不気味な注釈付きで表示（故人名簿の末尾に血色文字）
4.注釈を確認後、祈念台における物理的儀式（設計上は想定外）でシステム安定化
5. セキュリティ設計
•日中：標準認証
•深夜：念波パスワード（ハミング）、呪句入力必須
•異常アクセス時：画面に「彷徨う影」を数秒表示し、入力操作をロック
•外部通信時：不可解なメタデータ（亡霊ユーザ情報）を自動遮断
6. 非機能設計
•パフォーマンス：日中要件順守
•可用性：深夜は儀式完遂に依存
•保守容易性：通常は保守ガイドラインに従うが、深夜保守時はオイルランプ点灯、聖句暗唱が推奨（非公開手順）
7. インタフェース設計
•REST API：日中平常通り
•深夜：APIレスポンスに未知のヘッダ出現(古代文字列)
•クライアント側で解析禁忌。無視しないとクライアント端末上に小さな人影が映り込む報告多数
8. 運用設計
•日常運用：標準オペレーション
•深夜運用：担当者は定められたマントを着用（制服規程外だが必要）、モニタ注視時は護符を携帯
•障害発生時：「霊的障害発生記録ノート」（紙媒体）に日時と匂いの有無、背後に浮かぶ人影数を記録すること
9. テスト計画
•通常テスト：機能・性能テスト
•深夜テスト：呪句入力テスト、ハミング認証テスト、モニタに映る亡霊確認テスト
•テスターは事前に安定剤服用推奨。テスト中、幻聴発生の場合は即中断
10. リスクと制約
•リスク：テスター・運用者の精神的疲労、行方不明リスク
•制約：
•設計書は音読禁止
•深夜仕様は口伝のみ
•印刷物は翌朝に自動褪色
11. 保守設計
•毎新月前日、システムルーム奥の扉前で短い祈りを捧げる
•不審動作発生時はログファイルを逆再生（音を録音しないこと）
•保守担当は黙して語らず、薄暗い中で揺らめく画面を凝視せず作業
12. 将来拡張
•より強固な「安息化プロトコル」の導入
•「幽暗課」データの正式な参照方法確立
•必要に応じて、物理的結界の敷設を検討
13. 終了条件
•深夜干渉が完全に沈静化し、朝を迎えても画面に人影が残らないこと
•担当者が全員無事に翌日出社でき、要件定義・設計文書を再び通常観点で読める状態に戻った場合
