Repository Guidelines

Project Rules

• Respond in Japanese.

Project Structure & Module Organization

• Root: README.md, LICENSE, mise.toml (tool versions), .devcontainer/ (container setup).
• Create src/ for application code and tests/ for automated tests when adding functionality.
• Keep non-code assets in assets/ and docs in docs/ (create as needed). Co-locate small module-specific fixtures under tests/fixtures/<module>/.

Build, Test, and Development Commands

• Dev container (recommended): open in VS Code and run “Reopen in Container”. Ownership and mise install -y run automatically.
• Tooling: mise install -y installs versions from mise.toml (currently Node). Example: node --version to verify.
• Node projects: use npm ci for clean installs, npm test to run tests, npm run build for builds (add scripts in package.json).

Coding Style & Naming Conventions

• Indentation: 2 spaces for JS/TS/JSON/YAML; 4 spaces for shell scripts.
• Naming: camelCase for variables/functions, PascalCase for classes, kebab-case for filenames and CLI commands.
• Formatting: prefer Prettier and ESLint if present; otherwise run npx prettier -w . before PRs.
• Imports: use relative paths within a package; avoid deep imports across modules without an index barrel.

Testing Guidelines

• Framework: Jest or Vitest for Node projects (recommended). Keep unit tests close to code in tests/ and mirror directory names.
• Naming: test files as <name>.test.ts|js. Aim for clear, isolated tests with minimal mocks.
• Running: npm test -- --watch locally; add coverage with npm test -- --coverage and keep deltas green.

Commit & Pull Request Guidelines

• Commits: follow Conventional Commits, e.g., feat: add user session store, fix: handle empty input.
• Scope small and focused. Reference issues with Closes #123 when applicable.
• PRs: include summary, rationale, screenshots (if UI), and testing notes. Link related issues/discussions. Keep PRs under ~300 lines of diff when possible.

Security & Configuration Tips

• Do not commit secrets. Use .env.local and provide .env.example when config is needed.
• Devcontainer: environment sets XDG_STATE_HOME and fixes permissions so mise can write state. If tools change, update mise.toml and run mise install -y.

プロジェクト構成とモジュール

• .devcontainer/: 開発コンテナ設定一式。devcontainer.json（Dev Containers 設定）、Dockerfile（Ubuntu ベース、TZ/locale/ユーザー設定）。
• mise.toml: プロジェクト固有のツール管理（例: Node のバージョン指定）。
• .devcontainer/mise/config.toml: ユーザー向けのグローバル設定（XDG）。コンテナ内 ~/.config/mise/config.toml に bind。
• ルートには README.md, LICENSE。現時点でアプリ用の src/ や test/ は未配置（必要に応じて追加）。

ビルド・実行・開発コマンド

• Dev Containers（推奨）
  • devcontainer build --workspace-folder .: 開発コンテナのイメージをビルド。
  • devcontainer up --workspace-folder .: 開発コンテナを起動（VS Code からも同等操作可）。
• Docker 直接利用（参考）
  • docker run --rm -it -v "$PWD":/workspaces -w /workspaces mcr.microsoft.com/devcontainers/base:ubuntu zsh
• mise（ツール管理）
  • mise install: mise.toml に基づきツールを取得。
  • コンテナ内 PATH は /mnt/mise-data/shims を含むため追加設定は不要。

コーディングスタイルと命名

• JSON: 2 スペースインデント、末尾カンマなし、キーはローワーケース。
• Dockerfile: 1 命令 1 目的、キャッシュを意識して順序最適化、不要なレイヤーを避ける。
• ファイル/ディレクトリ命名: ローワーケース + ハイフン（例: sample-script.sh）。
• ブランチ命名: feat/..., fix/..., docs/...。

テスト方針

• 本リポジトリは開発環境（Dev Container）提供が主目的のためテストは未提供。
• 将来的にテンプレートやスクリプトを追加する場合は test/ を作成し、スモークテスト + make test などで統一実行を推奨。

コミットとプルリクエスト

• コミット: Conventional Commits を推奨（例: docs: add README）。種別: feat, fix, docs, chore, refactor, ci。短く現在形で要点を記述。
• PR: 目的/背景/変更点/動作確認手順を明記。必要に応じスクリーンショットやログを添付。関連 Issue をリンク。小さく分割し、Rebase で履歴を整える。

セキュリティと設定のヒント

• 機密情報はコミットしない（環境変数やトークンはローカル/CI の安全な保管に）。
• devcontainer.json のボリューム /mnt/mise-data はツール用。権限は postCreateCommand で設定されるため手動変更不要。