Instruction file imported from menchan-Rub/Eidos (.cursor/rules/rule.mdc). Copyright stays with the author.

📘 Eidos 開発コード規約・設計ルール完全ガイド

📐 命名規約（Naming Convention）

ファイル／モジュール

• snake_case.eid：DSL本体、ライブラリ、ルール定義
• PascalCase.eid：型・構文定義ファイル（例：TypeSystem.eid）
• kebab-case.md：ドキュメント、設計メモ、RFC案など

コード内命名

📎 コード構成ポリシー

ディレクトリ構成（推奨）

/src
  /frontend         # 字句解析・構文解析
  /core             # 型システム・AST・EIR
  /dsl              # DSL拡張機構
  /backend          # LLVM/WASM/IR出力
  /stdlib           # 標準ライブラリ
  /tools            # CLI, LSP, ビルドシステム
/tests              # 単体・統合テスト
/docs               # ユーザー＆開発ドキュメント
/examples           # 言語の使用例・DSL例

💡 コーディングスタイル

一般ルール

• インデントは スペース4つ
• 行末に 不要な空白禁止
• 1関数＝最大40行（複雑な場合は内部関数に分割）
• 1ファイル＝最大500行 を超えない（分割必須）

コメントスタイル

• ドキュメントコメント：///（パブリックAPI）
• 実装メモ／注意点：// TODO: や // NOTE:
• バグ報告：// FIXME: 詳細 を明記

/// 再帰的にASTノードを構築
fn build_ast(tokens: TokenStream): ASTNode {
  // NOTE: 左再帰に対応済み（右再帰化済み）
  ...
}

🧠 設計原則

関数・構造体

• 1関数1責務：複雑なロジックは明示的に段階化
• すべての構造体・列挙型はClone/Debug/PartialEq 実装義務
• すべてのDSL要素はAST → EIR の一貫変換ルールを必須とする

型の原則

• 型は“表現”だけでなく“意味”を持つ（意味論情報を保持）
• DSL用の型も型拡張の定義がDSLごとに可能
• Null禁止（Option型を明示的に使う）

🧪 テスト規約

テスト命名

• 単体テスト：test_fnname_expected_behavior
• DSLテスト：dsl_math_parse_basic_addition
• CLIテスト：cli_build_success, cli_lint_warning_scenario

カバレッジ目標

• 100%型推論系テスト
• 80%以上の構文解析ルールに対するユニットテスト
• DSL構文追加時はAST/EIR/Evalテストをセットで追加

🛠️ Git 運用ポリシー

ブランチ戦略

• main: 安定版（CI必須）
• dev: 開発版（プルリクベース）
• feat/*: 機能追加
• fix/*: バグ修正
• lang/*: 言語仕様変更（RFC必須）

コミットメッセージ形式（Conventional Commits）

• feat: DSL構文にif式を追加
• fix: 型推論が失敗するケースを修正
• refactor: EIR生成器を分割
• docs: 型システムの解説追加

📄 ドキュメント整備ルール

必須ファイル

• /docs/spec/：仕様書（構文／意味／型／EIR）全体構成
• /docs/dev/：内部設計、実装構造、EIR設計、テスト構成
• /docs/tutorials/：DSL構築チュートリアル（レベル別）
• /docs/rfc/：言語変更提案フォーマット（RFC-0001.md など）

ドキュメント生成

• すべての型・関数に /// コメントを付けること
• eid docgen コマンドで自動ドキュメント生成可（予定）

✅ Eidos Linter ルール（自動チェック）

Eidosビルドツールに統合されるLinterルールの一部：

📢 コントリビュートルール

PR（Pull Request）の条件

• すべての変更はテスト付き
• Linterを通過していること
• 言語仕様への影響がある場合は /docs/rfc/ に説明があること
• 機能追加の場合、少なくとも1つのDSLサンプルが /examples/ にあること

🧩 RFC（言語仕様変更）の提出ルール

• ファイル名：rfc-XXXX-機能名.md
• 内容：目的、背景、構文変更案、型・意味への影響、後方互換性
• 評価期間：7日間、議論ログは /docs/rfc/logs/ に保存
• 採用条件：2名以上のレビュアーと作者の署名

🔒 安全性ルール

• Eidosコンパイラ・DSLで扱うあらゆるコードは決定論的であることが原則
• 外部コード埋め込みは禁止（FFIは@unsafe扱い）
• 共有メモリ／mutable aliasingは禁止（型で分離）
• 並列計算・IOは所有権に基づく制御を通すこと

✨ 開発信条（Philosophy）

Eidosは「言語を作る言語」である。
ゆえに、コードも言語であり、スタイルは構文であり、設計は意味である。
すべての定義は、構築者に明快さと予測可能性を提供するためにある。

仕様書 specification.md