GET SHIT DONEの概要
この言葉の本質は、単なる「忙しさ」ではなく「完了（Done）」に全神経を集中させることです。
- 完璧主義の排除: 80%の出来でも良いから、まずは終わらせて世に出す。
- スピード重視: 議論や計画に時間をかけすぎるのを嫌い、即座に手を動かす。
- 結果への執着: 「プロセス」ではなく「何が成し遂げられたか」という結果だけで自分を評価する。
インストール
プロジェクトのフォルダに移動して、下記コマンドを実行し、最新版をインストールする。
npx get-shit-done-cc@latest
2を選択。
2を選択。
実行
下記コマンドを実行し、既存のコードを読み込ませる。
/gsd-map-codebase
下記コマンドを実行し、マイルストーンを作成する。
/gsd-new-milestone
実行結果
It looks like .planning/PROJECT.md doesn't exist yet (we recently mapped the codebase but haven't formally initialized the project yet), but we can configure this as our first milestone.
What do you want to build next in this milestone? (e.g. Any specific new features, enhancements, or bug fixes?)
上記のような質問が帰って来たため、以下の通り指示をする。
今後の機能拡張に備えて修正しておいた方が良い箇所はありますか？
最終的な出力
先ほどのコードベースの調査（gsd-map-codebase）の結果を踏まえると、今後の機能拡張をスムーズかつ安全に進めるために、現在の段階で整備・修正しておきたい箇所（技術的負債や準備不足の領域）がいくつか見受けられます。
次回のマイルストーン（機能追加）に着手する前に、あるいはその最初のフェーズとして、以下の点を解消しておくことを強くお勧めします。
1. データベースのマイグレーション管理（最優先）
- 現状: バックエンドでは
backend/sql/create_tables.sqlを利用してDBの初期化を行っています（Dockerのdocker-entrypoint-initdb.dにもマウントされています）。 - 課題: 今後新しい機能を追加する際に「テーブルに新しいカラムを追加する」「既存のデータ構造を変更する」といった変更（ALTER）が発生しますが、現状の仕組みではスキーマのバージョン管理ができません。
- 対策: Flyway や Liquibase といったマイグレーションツールを Spring Boot に導入し、SQLスクリプトをバージョン付き（例:
V1__init.sql,V2__add_user_columns.sql）で管理できる体制に変更することをお勧めします。
2. フロントエンドのテスト環境の構築
- 現状: バックエンド（Spring Boot）には JUnit を用いたテスト機構が含まれていますが、フロントエンドの
package.jsonを見る限り、自動テストフレームワーク（Vitest や Jest、React Testing Library）が設定されていません。 - 課題: 今後 UI や状態管理（React Queryなど）が複雑化していくと、デグレ（既存機能の予期せぬ破壊）を手動で防ぐのが困難になります。
- 対策: Vitest と React Testing Library のベース環境だけでも構築しておき、今後作成する重要なコンポーネント（フォームなど）に対して単体テストを書ける土台を用意しておくべきです。
3. フロントエンドの API クライアント層の整備
- 現状:
frontend/src/api/の下にはaxios.js（設定ファイルのみ）しか存在していません。 - 課題: エンドポイントが増えるにつれて、各コンポーネント内で直接
axios.get('/api/xxx')のように記述すると、将来的な URL の変更や、型の不整合を管理しきれなくなります。 - 対策: バックエンドの OpenAPI (Swagger) からフロントエンドの API クライアント（と TypeScript 型定義相当の Zod スキーマなど）を自動生成するツール（例:
Orvalなど）を導入するか、少なくともsrc/api/パッケージ以下にエンドポイントごとの関数の切り出しと、エラーの共通ハンドリング（Axios Interceptorsでの共通トースト通知など）を整備しておくべきです。
4. 認証・セキュリティ情報などのハードコード排除の確認
- 現状:
docker-compose.yml内で一部の設定（${DB_PASSWORD}など）を変数化していますが、開発中の暫定値などに依存している可能性があります。 - 対策: Local用・Production用等に向けた Spring の Profile (
application-{profile}.properties) や.envファイルでの環境変数管理が隅々まで行き届いているか点検しておくと、後々デプロイする時に慌てずに済みます。
▶ 次のアクションの提案
もしよろしければ、このまま次期マイルストーンを作成し、
「機能拡張を始めるための技術基盤の整備（インフラ・テスト・API設計基盤）」 を最初のフェーズ (Phase 1) としてロードマップに組み込むことができます。
この流れで /gsd-new-milestone による次期マイルストーンの策定に進みますか？ もしくは先述の課題のうち、特にどれか一つを先に修正したい領域はありますか？
さらに下記の通り指示をする。
2. フロントエンドのテスト環境の構築のみを次期マイルストーンとしたいです。
フロントエンドのテスト環境構築をマイルストーン v1.0 として進めるための実装計画を implementation_plan.md に作成しました（エディタまたはコンソール上で確認できるはずです）。
具体的には、プロジェクト管理としてGSDファイル (PROJECT.md, ROADMAP.md など) の初期化を行うと同時に、フロントエンドでの Vitest と React Testing Library の設定作業などを行います。
内容をご確認いただき、問題なければこの計画に沿ってインストールやファイル作成の作業を進めさせていただきます。「承認（または進めてOK）」とお知らせください！
結果
やることが明確になって良い。