project-bootstrap

プロジェクトのブートストラップ

ユーザーが依頼したリポジトリのセットアップに、Jess のデフォルトを適用します。アプリケーションや小規模なプロトタイプの依頼だけでは、フルテンプレートが求められているとは限りません。移行が依頼に含まれていない限り、既存のツールは維持します。

スコープを選択する

タスクから、言語、成果物の種類、求められているセットアップを推測します。最小限の実行可能なプロジェクトと、配布を目的としたリポジトリを区別します。重要なインフラの選択は、実装前に明示します。ユーザー自身が決めるべき事項に影響する情報が不足している場合に限り、質問します。

• 最小限のセットアップ：ソースのレイアウト、依存関係マニフェスト、プロジェクトの実行と検証に必要なコマンド。
• リポジトリのツール：フォーマッター、リンター、型チェック／ビルドチェック、CI。
• 配布：製品に適したリリースの自動化と、コントリビューター向けのファイル。
• Jess フルテンプレート：リポジトリのツール、該当する配布用ファイル、エージェントルールとレビューのインフラ。フルテンプレートや、それらのゲートが求められている場合にのみ使用します。

ツールのデフォルト

言語	フォーマッター	リンター	型／ビルドチェック
Rust	rustfmt	clippy	cargo build / cargo test
Go	gofmt / goimports	staticcheck + go vet	go build / go test
TypeScript	oxfmt	oxlint	tsc --noEmit
Python	ruff format	ruff check	mypy または pyright

言語ごとに、フォーマッター設定とリンター設定をそれぞれ1つにします。対応している場合は、厳格な型チェックから始めます。境界でのパースを可能にするため、unknown 型の入力、実行時の型の絞り込み、正当な React のエフェクトを全体的に禁止しないでください。必要に応じて、言語固有のガイダンスには code-craft を使用します。

新しい TypeScript アプリケーションまたはフルテンプレートでは、プロジェクトで使用する code-craft の証明の階段に基づいてスタックをセットアップします。型チェックでは言語サービスの診断を使う Effect、境界では Effect Schema または Zod、名前付きワークフローでは xstate、リンタープリセット付きの gdp-ts、@effect/vitest を使う Vitest、プロバイダーテスト用の Vercel Emulate、そしてdatabase-craftに従った Postgres を含めます。リンターでは、any、チェックされていない as、非 null の !、未処理の Promise、理由のない抑制がある場合に失敗するようにします。プロトタイプには、使用するものだけを導入します。

新しい Rust サーバーでは、code-craft のRust リファレンスに記載されたサーバースタックをセットアップします。tokio、axum、snafu、aerosol、sqlx、disallowed_methods と disallowed_types を含む [workspace.lints] の deny リスト、tests/it にテストクレートを1つ設けてライブラリとバイナリの各ターゲットに test = false を設定する nextest、CI での cargo sqlx prepare --check を含めます。

CI とローカル開発で共有する1つのレシピに、チェック一式を定義します。フックが求められている場合は、同じレシピか、対象を絞った高速なサブセットを使用します。CI と重複するだけの目的で、すべてのコミット時に低速な全チェックを実行しないでください。

エージェントのインフラ

エージェントルールの適用や AI レビューが求められている場合は、各ルールを忠実に表現できる最も強力なレイヤーに配置します。新しいエージェントルールシステムより、コンパイラーやリンターによるチェックを優先します。同じゲートを複数のレイヤーに重複して設けないでください。

適用が必要なエージェント固有のルールには、可能であれば構造的マッチングを使い、エージェントの編集に依存しない CI チェックを用意します。AI レビューのゲートでは、レビュアーの定義をレビュー可能な状態に保ち、リポジトリの所有権ルールで保護します。必須のゲートで、評価に失敗したときに黙って合格することがあってはなりません。

配布とプロジェクトファイル

バイナリー配布を目的とする CLI では、対応プラットフォーム向けのチェックサム付きアーカイブを用意し、タグをトリガーとするリリースを優先してください。バージョンはタグから取得します。インストーラーは、要望がある場合、または配布計画上必要な場合にのみ含め、インストール前にチェックサムを検証する必要があります。

対応プラットフォームとパッケージレジストリは、想定するユーザーに合わせてください。未公開のプロトタイプ向けにプラットフォームのマトリックスを作成しないでください。

公開配布を目的とするリポジトリには、ライセンス、コントリビューション手順、非公開のセキュリティ報告窓口を含めてください。フルテンプレート、またはそれぞれの具体的な目的が求められた場合は、行動指針、イシューテンプレート、依存関係の更新、リリースワークフローを追加してください。

新しいライセンスを選ぶ場合、Jess の選択肢は AGPL-3.0-or-later または Apache-2.0 です。ユーザーがすでに選んでいない限り、新しいプロジェクトにどちらを使用するか確認してください。AGPL を使用する場合、ドキュメントには CC-BY-SA-4.0 を使用するのが Jess のデフォルトであり、NOTICE に記録します。既存のライセンスとサードパーティの告知は維持してください。

検証と報告

生成したセットアップと必要なチェックを実行してください。CI が保守されているチェック用レシピを呼び出していることを確認してください。設定した内容と、検証できていないプラットフォームや外部サービスを報告してください。許可なく公開したり、リモートリポジトリを作成したり、有料サービスを設定したりしないでください。