Axiom Meridian

目次

0. プロジェクト概要
1. 製品の概要
2. システムアーキテクチャ
3. データモデル
4. API 仕様
5. ユーザーストーリー
6. 作業チケット
7. プルリクエスト

---

0. プロジェクト概要

0.1. 氏名（フルネーム）：

Juan Manuel Rojas González ([email protected])

0.2. プロジェクト名：

Axiom Meridian — 「コードは漂流します。Meridian は漂流しません。」

0.3. プロジェクトの簡単な説明：

チームの技術的な組織知識（コーディング規約や学んだ教訓）を一元管理し、AI エージェントに毎回ナレッジベース全体を読ませるのではなく、現在のタスクに関連する部分だけを提供する MCP（Model Context Protocol）サーバーです。

0.4. プロジェクト URL：

該当なし（MCP）— Axiom Meridian はローカルで使用する MCP サーバー（stdio）で、必要に応じて 127.0.0.1 にバインドした HTTP/SSE も利用できます。インターネットからアクセス可能なデプロイ URL はありません。

0.5. リポジトリ URL または圧縮ファイル

https://github.com/abeljumanuel/axiom-meridian-project

---

1. 製品の概要

1.1. 目的：

AI コーディングエージェントを活用するチームでは、言語やフレームワークごとのコーディング標準、アーキテクチャ上の決定、本番環境のインシデントから得た「学んだ教訓」といった組織知識が、長大な Markdown ファイルとして蓄積されます。ファイルが小さいうちは問題ありませんが、増大するにつれて 3 つの問題が生じます。現在のタスクに適用されるルールが 2、3 個だけでも、エージェントのセッションごとにファイル全体を読み直す必要があること（コンテキストとレイテンシのコスト）、関連性の判断が二者択一であること（「このプロジェクトでは Quarkus を使い、あちらでは Spring Boot を使う」という区別ができないこと）、そしてガバナンスがないこと（レビューや追跡可能性なしに誰でもファイルを直接編集できること）です。

Axiom Meridian は、ルール（RN-*）と教訓（LL-*）をアトミックなブロック形式でインデックス化し、スコープ階層（project → framework → language → global）を解決して特定のプロジェクトに適用する内容を判断し、フィルタリングされたサブセットのみを、必要に応じて意味的関連性に基づいて順位付けしたうえで、型付き MCP ツールを通じて提供します。Markdown ファイルは引き続き唯一の信頼できる情報源であり、変更にはすべて人間による明示的な承認が必要です。

詳細はプロジェクト憲章と製品説明をご覧ください。

1.2. 主な機能と特徴：

1. スコープを限定したナレッジクエリ — query_rules / query_lessons は、プロジェクトに適用されるスコープ階層を解決し、カテゴリ／重大度／タグによるフィルターを適用して、有効な該当エントリーのみを返します。
2. アトミックで追跡可能な形式 — 各ルールまたはレッスンは、構造化フィールドを備えた自己完結型の Markdown ブロック（## RN-JAVA-011、## LL-PSP-003）であり、決定論的に解析してインデックス化できます。
3. ガバナンスに基づくライフサイクル — 抽出とレガシーファイルの移行で、有効なナレッジに直接書き込むことはありません。すべてまず pending_proposals に保存され、approve_proposal によって、Markdown ファイルと SQLite インデックスの両方に単一のトランザクションで変更が反映されます。
4. PR と機能の監査 — audit_pr はマージ前に関連するルール／レッスンを提示し、check_feature_against_rules は計画段階で同様の処理を行います。
5. 会議の文字起こしからの抽出 — extract_rules_from_transcript / extract_lessons_from_transcript は、会議メモから候補となる提案を作成します。
6. ハイブリッド検索（SQL + RAG） — 埋め込みが存在する場合、クエリは意味的類似度（ChromaDB 経由の BAAI/bge-small-en-v1.5）に基づいて順位付けされます。埋め込みがない場合は、ツールのシグネチャを変更せず、透過的に SQL フィルタリングへフォールバックします。
7. アクセス制御と監査ログ — すべてのツールにはアクセスレベル（read / analyze / write）による制限があり、機密パラメーターを除いて、すべての呼び出しが記録されます。
8. エコシステム向けスキルの生成 — generate_project_skills は、agentskills.io の規約に従った .claude/skills/ ファイルを生成します。

全機能の一覧は、製品説明 § 主な機能をご覧ください。

1.3. 設計とユーザーエクスペリエンス：

設計上、Axiom Meridian 独自のグラフィカルインターフェースはありません。画面を操作する人間のユーザーではなく、AI エージェント（Claude Code、VSCode、OpenCode、Kimi CLI）がツール呼び出しを介してプログラムから利用する MCP サーバーです。現在の「ユーザーエクスペリエンス」は、エージェントがツールを呼び出し、スコープでフィルタリングされた JSON 応答を受け取るものです。

人間（ナレッジキュレーターまたはプラットフォーム管理者）がスクリプトを書かずにサーバーの状態（サーバーの健全性、スコープ階層、ルール／レッスンの件数、保留中の提案、埋め込みプロジェクター）を確認できる読み取り専用のビジュアルパネルは、現在開発中です。これはバックログで明示的に検討されているコンポーネントであり、現時点のベースラインには含まれていません。US-H1 — Meridian のステータスと内容をビジュアルに確認する（エピック H）と、関連チケットの TICKET-017をご覧ください。

1.4. インストール手順：

Meridian は uv（リンク先）でインストールする Python 3.11 以降対応のパッケージ（axiom-meridian）です。uv が互換性のある Python を自動で取得します。標準的な MCP サーバーであるため、プロトコル互換の IDE または CLI であれば利用できます（Claude Code、VSCode、Cursor、OpenCode、Kimi CLI）。ただし、主に Claude Code 向けに最適化され、テストされています。

macOS / Linux — 1 行でインストール：

curl -fsSL https://raw.githubusercontent.com/abeljumanuel/axiom-meridian-project/main/scripts/install.sh | bash

Windows を含むすべての OS（PowerShell または uv をインストール済みのターミナル）：

uv tool install axiom-meridian
meridian setup     # detects and configures your MCP clients, creates the knowledge base
meridian doctor    # read-only check of the installation

Windows では、まず powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex" で uv をインストールしてください。meridian setup は通常の Python プログラムなので、インストーラースクリプトは必要ありません。

install.sh はこれらと同じコマンドを実行する簡易ラッパーです。必要に応じて確認してから uv をインストールし、uv tool install を実行した後、meridian setup に処理を引き継ぎます。meridian setup は検出された各クライアント（Claude Code、VSCode、Cursor、OpenCode、Kimi CLI）の設定前に確認を求めます。また、既存のナレッジベースファイルや、別のインストール先を指す登録情報を上書きせず、最後に meridian doctor を実行します。クローンしたディレクトリから実行すると（bash scripts/install.sh）、そのチェックアウトを編集可能モードでインストールします。

Claude Code プラグイン（サーバーと利用スキルをまとめて提供）：/plugin install meridian --marketplace abeljumanuel/axiom-meridian-project。

セマンティック検索はオプションです： 自由入力のクエリを意味に基づいてランク付けするには、axiom-meridian[rag]（ML ライブラリ約 900 MB）をインストールします。インストールしない場合、クエリは SQL フィルタリングにフォールバックし、generate_embeddings は RAG_NOT_INSTALLED エラーを返します。

KNOWLEDGE_BASE_PATH は任意です。設定されていない場合、Meridian はナレッジベースのディレクトリを自動作成します（Linux では ~/.local/share/meridian、macOS では ~/Library/Application Support/meridian、Windows では %APPDATA%/meridian）。クライアントごとの設定、アップグレード、ソースからのインストール、トラブルシューティングについては、docs/installation.md を参照してください。

---

2. システムアーキテクチャ

2.1. アーキテクチャ図：

Meridian は、MCP ツールの登録 → ドメインツール層 → パーサー／RAG／永続化という階層型アーキテクチャに従っています。単一の書き込み箇所（write_block）によって、SQLite インデックスを Markdown ファイルと同期させます。このパターンが選ばれたのは、プロジェクトにとって譲れない要件が、Markdown を信頼できる唯一の情報源とし、SQLite はインデックスおよび状態管理層としてのみ機能させることだからです。「データベースを信頼できる唯一の情報源とする」アーキテクチャのほうが実装は簡単だったでしょう。しかし、それではプロジェクトの存在意義そのものである、人間が確認しやすいという特長（差分を確認しやすく、Git でバージョン管理可能）を損なってしまいます。その代わりに受け入れたトレードオフは、同期されていない内容の提供を避けるために、鮮度検証層（indexed_files、mtime + sha256）を追加することです。

graph TB
    subgraph Clients["MCP Clients"]
        CC[Claude Code]
        VS[VSCode]
        OC[OpenCode]
        KC[Kimi CLI]
    end

    subgraph Meridian["Axiom Meridian (Python / FastMCP)"]
        SRV["server.py<br/>tool registration + security pattern"]
        subgraph Tools["tools/"]
            KM[knowledge_management]
            KCO[knowledge_consumption]
            AF[audit_flows]
            EX[extraction]
            KT[knowledge_templates]
        end
        subgraph Parsers["parsers/"]
            AP[atomic_parser]
            LP[legacy_parser]
        end
        subgraph RAGL["rag/ (optional)"]
            EMB[embedder]
            VEC[vector_store]
        end
        DBC["db/ (schema, migrations, connection)"]
        SEC["utils/security.py<br/>access levels"]
        SR["utils/scope_resolver.py"]
        RI["utils/read_index.py<br/>write_block + freshness"]
    end

    subgraph Storage["Storage (KNOWLEDGE_BASE_PATH)"]
        MD["Markdown files<br/>knowledge-base/*.md, lessons/*.md<br/>(source of truth)"]
        SQLITE[("SQLite<br/>meridian.db<br/>(index + state)")]
        CHROMA[("ChromaDB<br/>(optional vector store)")]
    end

    CC & VS & OC & KC -->|MCP stdio / HTTP-SSE| SRV
    SRV --> SEC
    SRV --> Tools
    KM --> AP
    KM --> LP
    KM --> RI
    KCO --> SR
    KCO --> RAGL
    RAGL --> CHROMA
    RI --> MD
    RI --> SQLITE
    Tools --> DBC
    DBC --> SQLITE

（図は、リファレンス実装のソースコード（src/meridian/）から直接推定したもので、以前は docs/03-system-architecture.md に記載されていました。）

2.2. 主なコンポーネントの説明：

コンポーネント	技術	担当
server.py	FastMCP	すべての @mcp.tool() を登録します。各ツールは _security_pattern(tool_name, params, project_id, impl) に処理を委譲します。連番のログ ID の割り当て → check_access() → 実装の実行 → access_log 行の書き込みを行います。
tools/	Python	knowledge_management（インデックス作成、提案のライフサイクル、昇格、埋め込み）、knowledge_consumption（クエリ、コンテキスト、タイムライン、監査ログ）、audit_flows（PR 監査、フィードバック分析、機能チェック）、extraction（トランスクリプト → 提案）、knowledge_templates（標準ブロックビルダー）。
parsers/	Python	atomic_parser は標準形式の ## RN-XXX-NNN / ## LL-XXX-NNN ブロックを読み取ります。legacy_parser は旧形式の自由記述ファイルを読み取ります。その内容が直接行になることはなく、必ず pending_proposal になります。
rag/（オプション）	sentence-transformers、ChromaDB	embedder は BAAI/bge-small-en-v1.5（384 次元、自動で CUDA／MPS／CPU を使用）を遅延ロードします。vector_store は meridian_rules / meridian_lessons コレクションをラップします。
db/	SQLite（WAL）	schema.sql（スキーマとシードスコープ）、migrations.py（PRAGMA user_version に基づくバージョン管理された NNN_*.sql の実行機能、自動バックアップ付き）、connection.py（WAL モードの接続）。
utils/	Python	security.py（アクセスレベル）、scope_resolver.py（階層解決と属性フィルタリング）、read_index.py（書き込みの単一の受付点とファイルごとの鮮度管理）、id_generator.py（アトミックな連番 ID）、privacy.py、serializers.py（JSON／TOON）、skill_generator.py（agentskills.io 向け出力）。

2.3. プロジェクトの概要とファイル構成

注： このリポジトリ（axiom-meridian-project）は、最終課題のドキュメント成果物であり、docs/、openspec/、prompts/ を格納しています。以下に示すソースコードの構成は、サーバーのリファレンス実装（作業用チェックアウト axiom-meridian/）に対応しています。この実装はこのドキュメントと並行して進化しており、納品済みのチケット（セクション 6）の基盤となっています。

axiom-meridian/
├── src/meridian/
│   ├── server.py              # MCP tool registration + security pattern
│   ├── config.py              # Configuration loading (env vars, paths)
│   ├── db/
│   │   ├── schema.sql          # Full schema + seed scopes
│   │   ├── migrations.py       # Versioned migration runner
│   │   ├── migrations/         # NNN_*.sql files
│   │   └── connection.py       # SQLite WAL-mode connections
│   ├── parsers/
│   │   ├── atomic_parser.py    # Canonical RN-*/LL-* format parser
│   │   └── legacy_parser.py    # Free-form file parser (migration)
│   ├── rag/
│   │   ├── embedder.py         # Lazy loading of BAAI/bge-small-en-v1.5
│   │   └── vector_store.py     # ChromaDB collection wrapper
│   ├── tools/
│   │   ├── knowledge_management.py    # Indexing, proposals, promotion
│   │   ├── knowledge_consumption.py   # Queries, context, timeline
│   │   ├── audit_flows.py             # audit_pr, check_feature_against_rules
│   │   ├── extraction.py              # Transcript extraction
│   │   └── knowledge_templates.py     # Canonical block templates
│   └── utils/
│       ├── security.py         # Access levels (read/analyze/write)
│       ├── scope_resolver.py   # Scope hierarchy resolution
│       ├── read_index.py       # write_block + freshness validation
│       ├── id_generator.py     # Atomic IDs via id_counters
│       ├── privacy.py          # Redaction of <private> tags
│       ├── serializers.py      # JSON/TOON serialization
│       └── skill_generator.py  # .claude/skills/ generation
├── tests/
│   ├── unit/                  # Parsers, resolver, migrations, security...
│   ├── integration/           # Full flows (index+query, proposals...)
│   ├── contract/              # MCP tool signatures
│   └── benchmarks/            # Performance regression guards
├── scripts/
│   ├── install.sh             # Linux/macOS installer
│   └── uninstall.sh
└── pyproject.toml

このリポジトリ（axiom-meridian-project）では、その構成にドキュメント優先の性質が反映されています。

axiom-meridian-project/
├── docs/                      # Baseline documentation (charter, architecture, data model...)
├── openspec/
│   ├── specs/                 # Baseline of already-delivered capabilities
│   └── changes/                # Active change proposals (backlog)
├── prompts/                   # Project working prompts
└── README.md

2.4. インフラストラクチャとデプロイ

Meridian にクラウドインフラストラクチャは不要です。MCP クライアントによってローカルプロセス（stdio）として起動するか、オプションで 127.0.0.1 のみにバインドする HTTP/SSE サーバー（meridian serve <port>）として起動します。0.0.0.0 にバインドすることはありません。HTTP モードでは、起動時にランダムなセッショントークンが発行され、すべてのリクエストで Authorization: Bearer <token> として指定する必要があります。トークンは永続化されず、再起動のたびにローテーションされます。

このリポジトリには、デプロイ／CI パイプラインはまだ記載されていません。現在の「デプロイ」は、セクション 1.4 で説明している scripts/install.sh によるローカルインストールです。ネットワーク経由のデプロイを強化するための対策（複数クライアント、TLS、レート制限）は、今後の作業として TICKET-015 で扱われます。

2.5. セキュリティ

アクセスレベル	許可される操作	一般的な呼び出し元
read	クエリのみ。何も永続化されません。	ナレッジを利用するだけのエージェント。
analyze（デフォルト）	read に加え、監査／提案の永続化（audit_pr、extract_*、create_pending_proposal）。	通常の開発セッション。
write	フルアクセス。インデックス作成、承認、埋め込み、スキル生成が可能です。	管理および移行。

• 上位のアクセスレベルには、すべての下位レベルが含まれます。
• アクセスレベルが不十分な場合、必要なレベルを示す構造化された ACCESS_DENIED エラーが返されます。
• 許可された呼び出しも拒否された呼び出しもすべて access_log に記録されます。ただし、機密性の高いパラメーター（pr_diff、feedback_text、text、proposed_text、new_text）は除外されます。
• すべての書き込み経路で、永続化の前に受信テキストから <private> タグが取り除かれます。
• HTTP/SSE トランスポートは設計上 127.0.0.1 にバインドされ、ベアラートークンが必要です（2.4 を参照）。

2.6. テスト

リファレンス実装のテストスイートは、pytest / pytest-asyncio で実行する4層のピラミッド構造に従っています。

• 単体（tests/unit/） — パーサー（atomic_parser、legacy_parser）、scope_resolver、id_generator、migrations、security、serializers、connection などを対象とします。各モジュールを個別に検証します。
• 統合（tests/integration/） — インデックス作成とクエリ、提案のライフサイクル、アクセス制御、RAG クエリ、スキル生成、外部ファイルの編集など、エンドツーエンドのフロー全体を対象とします。
• コントラクト（tests/contract/） — 公開されている MCP ツールのシグネチャが、後方互換性のない形で変更されていないことを検証します。
• ベンチマーク（tests/benchmarks/） — パフォーマンスのリグレッションを防止します。デフォルトの実行では除外され（pyproject.toml の addopts = "-m 'not benchmark'"）、-m benchmark を指定して明示的に実行します。

関連するバグ修正（システムアーキテクチャの ADR-003 から ADR-006 を参照）では、完了前にそれぞれリグレッションテストが追加されています。また、納品済みのチケット（セクション 6）には、受け入れ基準をカバーする具体的なテストファイルが記載されています。

---

3. データモデル

3.1. データモデル図：

erDiagram
    SCOPES ||--o{ SCOPES : "parent_id"
    SCOPES ||--o{ SCOPE_ATTRIBUTES : has
    SCOPES ||--o{ RULES : scopes
    SCOPES ||--o{ LESSONS : scopes
    SCOPES ||--o{ PENDING_PROPOSALS : "suggested for"

    RULES ||--o{ RULE_ATTRIBUTES : has
    RULES ||--o{ RULE_HISTORY : has
    RULES ||--o{ RULE_TAGS : has
    RULES ||--o{ RULE_LESSON_LINKS : links
    LESSONS ||--o{ LESSON_HISTORY : has
    LESSONS ||--o{ LESSON_TAGS : has
    LESSONS ||--o{ RULE_LESSON_LINKS : links
    RULES }o--|| LESSONS : originated_from

    SCOPES {
        text id PK
        text type
        text name
        text parent_id FK
    }
    SCOPE_ATTRIBUTES {
        text scope_id FK
        text key
        text value
    }
    RULES {
        text id PK
        text scope_id FK
        text code UK
        text text
        text category
        text severity
        text applies_to
        text status
        text file_path
        integer file_offset
        integer byte_length
        text originated_lesson_id FK
        text embedding_id
    }
    RULE_ATTRIBUTES {
        text rule_id FK
        text key
        text value
    }
    RULE_HISTORY {
        text id PK
        text rule_id FK
        text change_type
        text previous_text
        text new_text
        text reason
        text triggered_by
        text changed_at
    }
    RULE_TAGS {
        text rule_id FK
        text tag
    }
    LESSONS {
        text id PK
        text scope_id FK
        text code UK
        text project
        text date_occurred
        text severity
        text area_affected
        text what_happened
        text impact
        text root_cause
        text resolution
        text originated_rule_id FK
        text status
        text file_path
    }
    LESSON_HISTORY {
        text id PK
        text lesson_id FK
        text change_type
        text previous_text
        text new_text
        text reason
        text changed_at
    }
    LESSON_TAGS {
        text lesson_id FK
        text tag
    }
    RULE_LESSON_LINKS {
        text rule_id FK
        text lesson_id FK
        text link_type
    }
    PENDING_PROPOSALS {
        text id PK
        text type
        text scope_id FK
        text target_id
        text proposed_text
        text metadata
        text status
        text legacy_original
        text created_at
    }
    PROJECT_SCOPE_RESOLUTION {
        text project_id PK
        text resolved_scopes
        text updated_at
    }
    PR_AUDITS {
        text id PK
        text project_id
        text pr_ref
        text diff_hash
        integer rules_evaluated
        text violations_found
        text audited_at
    }
    PLANNING_CHECKS {
        text id PK
        text project_id
        text feature_description
        text conflicts_found
        text checked_at
    }
    ACCESS_LOG {
        text id PK
        text timestamp
        text tool_name
        text access_level
        text project_id
        text parameters
        text result
        text transport
    }
    ID_COUNTERS {
        text name PK
        integer next
    }
    INDEXED_FILES {
        text file_path PK
        real mtime
        text content_hash
        text updated_at
    }

(リファレンス実装の src/meridian/db/schema.sql にある実際のスキーマと照合し、ERD を検証済みです（17 テーブル、完全に一致）。)

3.2. 主なエンティティの説明：

テーブル	目的
scopes	プロジェクトに適用するルールを解決するための階層チェーンを形成するノード（global、global-<framework>、project-<id>）です。PK は id、parent_id は自己参照 FK です。
scope_attributes	スコープに設定する動的なキーと値の属性（framework=quarkus、component_role=gateway）で、AND 条件によるフィルタリングに使用します。
rules	スコープに紐付けられた有効または非推奨の技術ルール（RN-<TECH>-NNN）で、カテゴリ、重要度、適用可能性のメタデータを持ちます。text は detail="full" の読み取り時に返す、キャッシュ済みの本文です。FK は scope_id と originated_lesson_id、UK は code です。
rule_attributes	個々のルールに設定する動的な属性で、そのルールのスコープの属性に加えて適用されます。
rule_history	ルールの変更（CREATED、UPDATED、DEPRECATED、PROMOTED）をすべて記録する追記専用の監査履歴です。
rule_tags	完全一致フィルタリング用に、タグごとに1行で正規化したテーブルです（部分文字列の LIKE は使用しません）。
lessons	インシデント／教訓（LL-<TECH>-NNN）と、構造化フィールド（what_happened、impact、root_cause、resolution）を格納します。FK は scope_id と originated_rule_id、UK は code です。
lesson_history	教訓の変更をすべて記録する追記専用の監査履歴です。
lesson_tags	rule_tags と同様に正規化した、教訓用のタグです。
rule_lesson_links	ルールと、そのルールの起点となった、または参照する教訓との双方向リンクです。制約：(rule_id, lesson_id, link_type) の組み合わせは一意です。
project_scope_resolution	プロジェクトについて解決済みのスコープチェーンのキャッシュです。PK は project_id です。
pr_audits	すべての audit_pr() 呼び出しの記録です。評価されたルール、検出された違反、差分ハッシュを格納します。
planning_checks	すべての check_feature_against_rules() 呼び出しの記録です。
pending_proposals	人によるレビューを待つ、ルール／教訓候補（抽出、レガシー移行、手動作成）のステージング領域です。target_id は type="update" の提案に使用します。
access_log	セキュリティ監査履歴です。各ツール呼び出し、必要なアクセスレベル、および結果（success / denied / error）を記録します。機密性の高いパラメーターは記録しません。
id_counters	人が読みやすい連番 ID を生成するためのアトミックカウンターです。UPDATE ... RETURNING を使用し、MAX(id) は使用しません。
indexed_files	ファイルごとの鮮度フィンガープリント（mtime、content_hash）です。キャッシュ済みのテキストが、ディスク上の Markdown ファイルと一致することの検証に使用します。

アトミックブロック形式や ID 生成方式を含む詳細については、docs/04-data-model.md を参照してください。

---

4. API 仕様

Meridian は従来型の REST API を公開するのではなく、型付き MCP ツールのセット（リファレンス実装では 25 個以上のツール — query_rules、audit_pr、create_pending_proposal など）を公開します。これらは、動詞を使った HTTP ルートではなく、MCP プロトコル（stdio または HTTP/SSE）を通じて呼び出されます。このインターフェースに OpenAPI 3 仕様を無理に当てはめると、誤解を招きます。OpenAPI はリソースと HTTP 動詞をモデル化する一方、MCP ツールは入力／出力スキーマ（JSON Schema）を持つ関数であり、「モデルが呼び出せるアクション」という意味論を備えています。つまり、エンドポイントというより関数シグネチャに近いものです。

正式な代替案として、このプロジェクトでは 宣言型スキーマによるセマンティックツール定義、すなわちモデル指向ドキュメント を採用します。ツールごとに 1 つのドキュメントを作成し、入力パラメーター、必要なアクセスレベル（read／analyze／write）、応答の形式、呼び出し例を JSON Schema で定義します。これは、リファレンス実装の tests/contract/test_mcp_tool_signatures.py ですでに検証されているものと同種の契約ですが、テストだけでなく、製品ドキュメントとして公開します。この規約は特定されていますが、プロジェクトのドキュメントには まだ実装されていません。今後のリリースで対応し、少なくとも最もよく使われる 3 つのツール（query_rules、audit_pr、create_pending_proposal／approve_proposal）を文書化する予定です。

---

5. ユーザーストーリー

全カタログ（8 つのエピック、「As a / I want / so that」形式、MoSCoW 優先度）は docs/05-user-stories.md にあります。以下に代表的なものを 3 件示します。

ユーザーストーリー 1 — US-A1 — プロジェクトに関連するルールを照会する（エピック A、優先度 Must、ツール query_rules）。

ユーザーストーリー 2 — US-B3 — 提案をレビューして承認する（エピック B、優先度 Must、ツール list_pending_proposals／approve_proposal／reject_proposal）。

ユーザーストーリー 3 — US-C1 — 既知のルールに照らしてプルリクエストを監査する（エピック C、優先度 Must、ツール audit_pr）。

---

6. 作業チケット

全カタログ（完了分＋バックログ、OpenSpec とのトレーサビリティ付き）は docs/06-work-tickets.md にあります。以下に、バックエンド、データベース、フロントエンドのチケットを 1 件ずつ示します。

チケット 1（バックエンド） — TICKET-001 — MCP サーバーのひな形とコアツールの基盤。FastMCP サーバー、server.py のセキュリティパターン、SQLite スキーマ、初期ツールセットを構築します。ステータス：完了。

チケット 2（データベース） — TICKET-008 — ファイル単位の鮮度管理を備えたインデックス付き読み取りパス（ADR-005）。indexed_files、rule_tags、lesson_tags を追加し、単一の書き込み制御点として write_block を導入します。また、ファイル単位の鮮度検証を行う SQLite に detail="full" の読み取りを移行します。ステータス：完了。

チケット 3（フロントエンド） — TICKET-017 — 読み取り専用の可観測性ダッシュボード。US-H1 に対応します。knowledge_consumption をライブラリとして再利用し、別個のローカルプロセスとして実行する読み取り専用の Web ダッシュボード（サーバーのヘルス、スコープ階層、保留中の提案、埋め込みプロジェクター）です。ステータス：バックログ — これはプロジェクトで検討されている唯一のフロントエンドコンポーネントであり、正式な仕様は openspec/changes/add-observability-dashboard/ にあります。

---

7. プルリクエスト

ここでは、完全かつ検証可能な成果物を完成させるプルリクエストのみを参照しています。最初の有効な成果物は、ベースライン技術ドキュメント（プロジェクト概要シート、説明、アーキテクチャ、データモデル、ユーザーストーリー、作業チケット）です。つまり、この README と docs/ です。

プルリクエスト 1 — #1 — 重複の削除（マージ済み）。この成果物の提出に先立ち、ベースラインドキュメント内の重複コンテンツを整理しました。

プルリクエスト 2 — 保留中。 最初の成果物一式（「技術ドキュメント：プロジェクト概要シート、説明、アーキテクチャ、データモデル、ユーザーストーリー、作業チケット」）を含む PR が作成された時点で参照します。

プルリクエスト 3 — 保留中。

---

ライセンス

Axiom Meridian は Apache License, Version 2.0 のもとでライセンスされています。著作者表示については NOTICE をご覧ください。

「Axiom Meridian」と「Axiom JUMA」の名称およびそれらの標章は、Apache License（第 6 条「商標」）のライセンス対象ではありません。これらを使用するには、所有者の許可が必要です。

ライセンスの移行： Apache 2.0 への変更前に公開されたバージョンは MIT License のもとで宣言されており、その条件のもとで入手したコピーは引き続きその条件で利用できます。

サードパーティ： .claude/skills/openspec-* スキルは OpenSpec によって生成され、それぞれ独自の MIT License が適用されます。

貢献は、DCO のサインオフを添えて Apache License 2.0 のもとで歓迎します。詳細は CONTRIBUTING.md をご覧ください。