# 内部再鑑ゲート基盤 本開発依頼プロンプト タスク管理アプリ（`task_app` / cscnet-syntask.com）を開発しているClaude Codeプロジェクトに、そのまま貼り付けて本開発（Phase 1 MVP）に着手してもらうためのプロンプトです。添付として、①UIデザイン・操作感の参考実装（`内部再鑑ゲート_3案比較プロトタイプ.html`）、②これまでの開発計画書（`内部再鑑ゲート基盤 開発計画`アーティファクト）を一緒に共有してください。 --- ## 背景（経緯の要約） プロジェクトレビュー工程で「クライアント再提出前の内部再鑑チェック」が形骸化し、抜け漏れが発生する課題があった。これに対し、Kanban（チケット管理）形式のWebアプリで解決する方針を固め、以下の順で検討を進めてきた。 1. 課題整理・要件定義 2. 開発計画（アーキテクチャ）の立案とレビュー 3. UIデザイン案の作成（ClaudeDesignで3案作成）と、操作感を確認するための実装（3案切り替え可能なプロトタイプ） この結果、**デザインは「案A｜余白と静けさ（ミニマル）」を採用**することが決定した。今回は、Phase 1（強制ゲート付き単一プロジェクトのMVP）の本開発に着手してほしい。 ## 採用するUIデザイン 添付の`内部再鑑ゲート_3案比較プロトタイプ.html`を開き、画面上部タブの「案A｜ミニマル」を選択した状態が、目指す画面デザイン・操作感の参照実装です。ロールを切り替えると操作可能範囲が変わる挙動、ドラッグ&ドロップでの工程移動、滞留時間の警告表現、操作ログ表示などはこのファイルのJSロジックにそのまま実装されています。 **重要**：このプロトタイプの遷移可否判定はすべてクライアントサイド（ブラウザのJavaScript）で行っている簡易シミュレーションです。本開発では、この判定ロジックを**サーバー側API**に移し、UIはあくまで補助的な先回りフィードバックとする設計（後述）に置き換えてください。見た目・レイアウト・配色・フォント・カード構成・ログ表示の体裁は、このプロトタイプに忠実に実装してください。 ## アーキテクチャ方針（レビュー済み計画書ベース） 以前作成した開発計画書（「内部再鑑ゲート基盤 開発計画」）の内容をベースに進めてほしい。特に以下の設計判断はそのまま踏襲する。 - ステータス遷移はサーバー側APIで権限判定し、`PATCH /tickets/{id}/transition` が「現在ステータス→申請先ステータス」のエッジ定義と実行者ロールを検証、不許可なら409を返す。UIのドラッグ&ドロップはあくまで申請であり、確定はAPI判定を経て初めて成立する。 - データストアはJSONファイルではなくRDB（開発:SQLite／本番:PostgreSQL、SQLAlchemy + Alembic）を採用し、承認履歴・複数ロールの同時操作・行ロックに耐える構成とする。 - 承認履歴（`APPROVAL_LOG`）は追記専用（immutable）とし、更新・削除APIを設けない。 - Webフレームワークは既存`task_app`の資産（Flask、`run_scheduler.py`パターンの別プロセススケジューラ、i18n）を踏襲する。 ## 計画レビューで挙がった論点（Phase 1に組み込むこと） 計画書レビューの結果、以下3点はPhase 1のMVPスコープに含めることとした。将来検討への先送りにはしない。 1. **代理承認者の指定機構**：再鑑者が不在・兼務で身動きが取れない場合に、システムがクライアント提出を完全にブロックしてシステム外の運用（メール等での処理）に逃げられてしまうことを防ぐため、代理承認者を一時的に指定できる仕組みをPhase 1に含める。 2. **ロール割当の管理画面**：どのメンバーがどのロール（担当者／レビュアー／再鑑者／PMO・管理者）を持つかを設定する最低限の管理画面を、実運用トライアルが成立する範囲でPhase 1に含める。 3. **権限×遷移の検証**：強制ゲートがこの計画の価値の核であるため、ロール×遷移の組み合わせを網羅したテスト（許可されるべき遷移が通ること、許可されるべきでない遷移が403/409で拒否されることの両面）をPhase 1の完了条件に含める。 ## Phase 1 スコープ（MVP：強制ゲート付き単一プロジェクト） - チケットCRUD、ワークフローエンジン、遷移API（権限判定・409応答含む） - カンバンビュー（案Aデザイン準拠。ドラッグ&ドロップ、ゲート工程のロック表現、滞留時間の警告表示） - ロール・メンバー割当の管理画面（上記論点2） - 代理承認者の指定機能（上記論点1） - 権限×遷移のテスト（上記論点3） - 単一プロジェクトでの実運用トライアルができる状態 滞留アラート、承認履歴タイムラインUI、複数プロジェクト対応・PMO横断ダッシュボード、フロアモニター表示は、計画書通りPhase 2以降でよい。 ## 依頼したいこと 上記を踏まえ、Phase 1のMVPの実装に着手してほしい。まずはローカル環境で動作確認できるところまで進めてほしい。不明点や、計画からの変更が必要な判断が生じた場合は、実装を進める前に確認してほしい。 --- *作成日：2026年9月3日*