あなたの営業プロセスをコーディングエージェントに説明し、それが構築するCRMを所有する。
Claude Code、Codex、Gemini CLIが、あなたが所有するコードとしてCRMアプリケーションを生成するために使用するオープンソースフレームワーク — 決定論的ワークフロー、ポリシーゲート付きの人間による承認、監査とトレースが組み込まれている。
名前は選定され、ドメインは登録されている。npm create accordoは、公開されたcreate-accordo@0.1.0から動作するプロジェクトをスキャフォールドする。accordoパッケージ自体は、空の0.0.1の名前予約のままである — フレームワークをライブラリとしてインストールするものはない — そして@accordoスコープは主張されているが、意図的に空である。商標スクリーニングは実行されておらず、プロジェクトは本番環境にデプロイできない。それが正確に何を意味するかは停止する場所にあり、残りを読む前に読む価値がある。
Business request
↓ "Renewals of €50,000 or more need a manager's sign-off."
Claude Code / Codex
↓ reads AGENTS.md · 12 skills · MCP · `crm app inspect`
Modules + deterministic workflows + versioned policy
↓
API + Admin + trace + audit — in your repository, as code you reviewカスタムCRM: 営業プロセスが製品であり、結果が他の誰かのランタイム内の設定ではなくレビュー可能なコードであるべき場合。
Customer Hub: 「ハブ」が管理されたアクションを持つ1つのローカルな営業記録チェーンを意味する場合。AccordoはCDPのようにソースを取り込んだり、顧客IDを解決したりしない。
Smart CRM: コーディングエージェントがアプリケーションを構成し、バージョン付きポリシーと指名された人間がビジネス上の決定を保持する場合。エージェントが構築したソフトウェアであり、自律的な意思決定者ではない。
CDP + CRM: 外部のCDPが取り込み、ID解決、オーディエンスを所有し、Accordoがその隣で決定論的なCRMプロセスレイヤーを所有する場合。AccordoはCDP、コネクタ、インポーター、同期ランタイムを一切提供しない。
これらの隣接用語は検索パスであり、追加の能力の主張ではない。チェックされた推奨マップは、それぞれをフレームワークが証明するものと停止する場所に結び付けている。
Related MCP server: API Creator MCP
すべてのCRMは、最終的にあなたのプロセスをそのモデルに合わせて曲げるよう求める。通常の2つの逃げ道はどちらも何かを犠牲にする:
プラットフォームを設定する — 開始は速く、カスタマイズは誰か他のランタイム内のメタデータとして存在する。天井に達すると、モノレポをフォークすることになる。
ゼロから構築する — 完全な自由だが、すべてのチームが検証、パイプラインセマンティクス、承認、監査を再導出する。通常は遅く、通常はプレッシャーの下で。
このフレームワークは3つ目の選択肢だ: エージェントがアプリケーションを生成し、フレームワークがチームが締め切り下で常に間違える部分を提供する。どの開発者でも適用できるテストは「このプロジェクトが明日消えたら、私は何を残されるのか」という問いだ。ここでの答えは: サードパーティのランタイム依存関係がなく、どのクライアントでも開けるSQLiteファイルを持つ、あなたのリポジトリ内のNodeアプリケーションである。
以下の各行はマージ済みのテストに結び付けられている。完全な台帳 — 主張、証拠、そしてそれに伴う限界 — はsite/claims.jsonにあり、その背後にあるレビュー規律はdocs/QUALITY_GATES.mdにある。
機能 | 停止する場所 | 証拠 |
モジュールマニフェストが、ページコードなしでマイグレーション、サービス、RESTリソース、SDKメソッド、Admin画面になる | 生成されたCRUDのみ — カスタムオブジェクトのワークフローと承認はまだ手書き |
|
生成されたオブジェクトは相互に参照する: 外部キー、ランタイムターゲット検証、Adminセレクター | 生成されたもの同士の多対一のみ — 多対多、逆コレクション、カスケードはなし |
|
決定論的な承認ポリシー: しきい値以上の更新は指名された人間を待つ | 組み込みの更新オブジェクトと1つの値のしきい値 |
|
エージェントは人間の承認決定を下すことはできない — 慣例ではなくテストによって断言される | アクターは認証ではなく断言される。これは正直なエージェントに対しては成立するが、攻撃者に対しては成立しない |
|
オポチュニティは、サーバー権限のアクションの下でコードファーストのパイプライン段階を進む — クライアントが要求し、サーバーが決定する | 組み込みのOpportunityモジュールで証明済み。生成されたカスタムオブジェクトの設定可能なパイプラインは主張されていない |
|
リードのキャプチャ、エンリッチメント、説明可能なバージョン付きスコアリング、決定論的ルーティング、資格判定、コンバージョン | エンリッチメントはフィクスチャプロバイダーに対して実行される。実際のデータソースは接続されていない |
|
サーバー価格の複合見積もり、不変の見積もりバージョン、承認付きのバージョン付き割引ポリシー | フィクスチャカタログプロバイダー。FXなしの整数セント — 通貨は決して合算されない |
|
署名エンベロープ → 検証済みイベント → 署名済みアーティファクトの証拠 → 正確に1つの不変なOrder | フィクスチャ署名プロバイダー、テスト専用のwebhookキー、プロバイダー報告のアーティファクトハッシュ |
|
OrderのContractへのアクティベーション、不変バージョン、Subscription、保留中の義務 | 何も請求、更新、修正、キャンセルしない。スケジューラーはない |
|
ワークパッケージ、マイルストーン、任意のパートナーを持つプロジェクトへのデリバリーハンドオーバー。人間主導の実行 | 何もスケジュール、人員配置、受領、請求しない。デリバラブルはオブジェクトとして存在しない |
|
追記専用の時間と経費の証拠。バージョン付きポリシーでコスト化され、再現可能な貢献見積もり付き | 意図的にマージンではない: 収益認識なし、COGSなし、ARR/MRRなし、FXなし |
|
顧客が作成したドメインパッケージが、カーネルフィンガープリントを変更せずにアタッチおよびデタッチする | パッケージを開始するスキャフォールドは空のパッケージを書き込み、それ以外は何もしない。レジストリなし、公開なし、サンドボックスなし — パッケージコードはホストの権限で実行される |
|
| ビジネスロジックを発明せず、何も構成せず、グローバルIDの一意性を検証せず、インストールも公開も行わない |
|
| データベースを開かず、プロバイダーに連絡せず、シークレットを読まない — そしてその旨を出力で明言する |
|
| ドキュメントコントラクトであり、プランナーではなくランタイムでもない。プランを実行するものはない |
|
| カバレッジは発見ではなくシナリオによって主張される。行を昇格させず、ブラウザを駆動せず、各実行は1つの構成について語る |
|
生成されたモジュールは、明示的なリビジョンと追記専用の名前付きマイグレーションを通じて進化する | ソースのみ: 特定のデータベースが何を適用したかはここからは知ることができない |
|
スイート全体は、スモークテストとともに、すべてのプッシュで実行される。それが何件のテストだったか、そして測定されたコミットは、site/claims.jsonのmeasuredAgainstの下にある — このリポジトリでテスト件数が書き留められている唯一の場所であり、npm run gtm:checkが数値の出現を許可する唯一の場所である。
Node.js 22.16以降。サードパーティのランタイム依存関係はなく、ビルドステップもない。
npm run tour # compose the whole application and inspect it
npm run verify # source checks, then the whole test suite
npm run falsify # break five rules on purpose and watch the suite catch them
npm run demo # the approval slice, end to end
npm run dev # http://localhost:4000npm run tourは、これが実際に何であるかを確認する最も速い方法だ。リポジトリのデフォルト構成は意図的に空である — プロジェクトは自分が望む構成を書く — したがって、新しいクローンでのcrm app inspectは何も報告しない。ツアーはスターターインストーラー(CIが毎回のプッシュで実行するものと同じ)を保持するディレクトリに実行し、その後、結果を検査する:
modules 76 resources 71 policies 7
packages 9 actions 64 providers 1
production posture — local development only: no authentication, tenancy or RBAC
exists, and actor headers are not identityこれは、検査官が見ることができない11の項目で締めくくられる。なぜなら、良い半分だけを見せるツアーは、実行する価値がないからだ。npm run tour -- --keep ./demo は探索するプロジェクトを残し、--json は機械可読なレシートを出力する。
npm run falsify は逆の方向だ。テスト数はどれだけ書かれたかを示すが、テストがグリーンのままでいるために何が間違っていなければならないかは示さない。そこで、これは一度に1つのルールを削除する——承認に対する人間アクターのガード、承認閾値の境界、webhook署名検証、ポリシーバージョンの不変性、完全管理モジュールが公開書き込みを生成しないというルール——それを防御すべきスイートを実行し、それを捕捉したテストを指名する。未コミットの変更に対しては実行を拒否し、触れたすべてのファイルを復元する。生き残ったものはすべてギャップとして出力される。それが有用な出力だからだ
(docs/FALSIFY.md、tests/falsify.test.js)。
npm run demo は2つの更新を作成し、プッシュのたびに scripts/smoke.js によって検証される:
€20,000 → 直接 Proposal に移動する。
€80,000 → マネージャーが決定するまで Approval Pending で停止する。
Claude Code は CLAUDE.md、.mcp.json、.claude/skills/ を読み取る。Codex は AGENTS.md
と .codex/config.toml を読み取る。両方ともチェックインされ、相互に結線されている。
Read AGENTS.md, PRODUCT.md and docs/PROJECT_STATUS.md.
Run npm run crm -- app inspect --json.
Tell me which parts of my commercial process this already supports, and which it does not.ハーネスに必要なのは: コマンドの実行、stdout の読み取り、終了コードの読み取り、JSON の解析、ファイルの読み書きだけだ。MCP サーバーも、ネットワークも、認証情報も、データベースも、長時間稼働するプロセスも不要だ — docs/AGENT_HARNESS_COMPATIBILITY.md。
npm run crm -- app inspect --json # what this application contains
npm run crm -- solution check plan.json # is this plan still valid against it終了コードが契約だ: 0 有効 · 1 問題あり、レポートは出力される · 2 読み取り不能。
MCP サーバーは stdio 上で動作し（node --no-warnings packages/mcp/bin/server.js）、プロジェクト検査、機会一覧、ステージ変更リクエスト、承認決定、実行トレース、モジュールスキャフォールディングを公開する。コード生成ツールと破壊的ツールは、明示的な apply フラグを渡さない限りドライランだ（tests/mcp.test.js、tests/scaffold.test.js — docs/MCP.md）。
これは stdio のみ、ローカルのみだ: ホスト型や認証付きの MCP エンドポイントは存在せず、サーバーはそれを起動したプロセスの権限を継承する。
上記の何かを評価する前にこれを読むこと。docs/benchmarks/CRM_JTBD_MATRIX.md は、未サポートがデフォルトであり、そこから離れるには証拠が必要という保守的なステータス語彙で、すべての CRM ジョブを追跡する。
認証、テナント、RBAC はなし。 サーバーはローカル開発専用だ。アクターヘッダーはアサーションであり、アイデンティティではない。ネットワークに公開してはならない。
SQLite のみ。 PostgreSQL は Production Spine トラックにあり、実装されていない。
ビルドベンチマークは実行されていない。 Successful Agent Build Rate は存在しない。このプロジェクトに帰属するパーセンテージはすべて捏造だ —
docs/strategy/CRM_BUILD_BENCHMARK.md はプロトコルであり、結果ではない。
スケジューラーなし、リマインダーなし、タイマー上のものはなし。 フォローアップタスクとアクティビティタイムラインは1つの共有モデルとして存在し（docs/WORK_TASKS.md）、人がそれらのすべてを動かす: 期日は状態を変更せず、繰り返し発生するものは存在せず、割り当てや通知もなく、更新通知期間は記録されるだけで発火することはない。
メール、カレンダー、マーケティング統合はなし。 通知プロバイダー契約は存在するが、誰かに何かを送信するアダプターはない。
インポート、エクスポート、重複排除、マージ、一括編集、保存ビュー、グローバル検索はなし。 すべての商用 CRM で必須の基本機能であり、どれにもまだマイルストーンがない。
まだ実際の顧客データを入れることはできない。 認証も、テナントも、エクスポートも、消去パスもない — したがって、データ主体のアクセス要求や削除要求にはこれで対応できない。
docs/strategy/DATA_GOVERNANCE.md は設計のみだ。唯一保持されていること: リードスコアリングは決定的で、バージョン管理され、説明可能であり、人物に対するモデルの判断ではない。
これはフレームワークであり、サインアップする製品ではない。 ホスト型 CRM も、無料ティアも、アカウントもない。出力は、あなたが実行するアプリケーションだ。
所有とはベンダーソースを意味する: 依存関係として bump するフレームワークはない。
npm create accordo — 公開されている create-accordo@0.1.0 — は、起動し、app inspect から valid を報告し、project doctor から 0 で終了するプロジェクトを、フレームワークソースをコピーしてスキャフォールドする。同じブートストラップはチェックアウトからも実行される
（node packages/create-accordo/bin/create-accordo.js <dir> --apply、インストール不要、ネットワーク不要 —
tests/project-bootstrap.test.js）。レジストリが渡すのはスキャフォルダーであり、フレームワークではない: accordo パッケージは意図的に空の 0.0.1 名前予約だ。フレームワークはプロジェクトにベンダーソースされるため、結果を完全に所有できる — そしてアップグレードはバージョンの bump ではなくマージを意味する。
packages/core/ the runtime platform: registry, services, workflow engine, audit
packages/modules/ CRM domain primitives
packages/domains/ optional domain packages (contracts, delivery) on a public contract
packages/mcp/ tools and context exposed to coding agents
apps/ API server and generated Adminエージェントはデータベーステーブルに書き込むことはない。検証、アクターアイデンティティ、ポリシー、トレース、監査を保持するサービスメソッドと名前付きワークフローを呼び出す — ARCHITECTURE.md。
これを読む | 目的 |
コードを変更する前にエージェントが従わなければならないルール | |
製品が何であり、何でないか | |
技術モデルとその拡張ルール | |
決定ログ、ADR-001 … ADR-020 | |
今日のリポジトリで真であること | |
すべての CRM ジョブ、そのステータス、その証拠 | |
レビュー規律（敵対的レビューカテゴリを含む） | |
カテゴリ、ポジショニング、ロードマップ、メトリクス | |
これが人々にどう届くか、そして何が人間にゲートされているか |
MIT、ADR-023 によって確認済み。
Answer "can this framework do X?" against the CRM jobs-to-be-done index. Returns the matching jobs with their status (not supported / partially supported / technically supported / validated end to end), the tests that prove them, and an explicit answer when the truth is that the job is not supported.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | The job in plain words, or a JTBD id such as JTBD-CO-01. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds value by detailing output semantics: it returns statuses (not supported / partially supported / technically supported / validated end to end), supporting tests, and an explicit answer when not supported. This goes beyond annotations to set expectations about the response shape and edge-case handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The two-sentence description is dense with information, front-loading the core question and then detailing the output types. It is not overly verbose and conveys a lot in few words. A slight deduction for not being even more compact, but it remains appropriately sized for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only query tool with one required and one optional parameter, the description explains what the tool returns, including the status taxonomy and the explicit handling of unsupported jobs. It mentions tests as evidence, which provides completeness. There is no output schema to compensate for, so the description covers the essential aspects, though it could have mentioned pagination or limit behavior, which is minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documents 'query' fully, including an example, and 'limit' with constraints. Description coverage is 50%, and the description does not elaborate on parameters, but the schema already covers the main fields. The phrase 'against the CRM jobs-to-be-done index' adds retirement domain context to the query parameter. However, 'limit' remains semantically thin, and no new parameter information is provided in the description, so it neither helps nor hurts beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Answer') and identifies a precise resource ('the CRM jobs-to-be-done index'). It clearly differentiates the tool by describing the query format ('can this framework do X?') and enumerates the kind of results (jobs with statuses, tests, explicit answer for unsupported). This distinguishes it from generic search or capability tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the intended use clear: answering capability questions about a framework against a CRM index. However, it does not explicitly mention when to use this over siblings like get_capability or search_docs, though the specialized index and status taxonomy imply a niche. It lacks explicit exclusions or alternative guidance but provides clear contextual usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve a capability from the claims ledger by id (C-nn), by standing-limitation id (L-nn), or by topic. Every capability is returned together with the evidence that proves it and the limitation that bounds it — this tool cannot return one without the other.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | A claim id such as C-01, or a standing limitation id such as L-01. | |
| limit | No | ||
| topic | No | Free text, when the id is unknown. Matches claims and limitations. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavioral context beyond that: every capability is returned with its proving evidence and bounding limitation, and the tool cannot return one without the other. This is useful but does not describe not-found behavior or other edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with the first sentence stating purpose and lookup modes. The second sentence adds a valuable invariant, though the dash clause 'this tool cannot return one without the other' slightly restates the preceding point rather than adding new information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple read-only lookup: it identifies resource, lookup modes, and a key return invariant. However, with no output schema and one undocumented parameter (`limit`), it should clarify parameter interaction and behavior when no capability is found; it also does not offer guidance relative to the sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%; id and topic are documented in both schema and description, but the description adds little beyond what the schema already provides. The `limit` parameter is not explained semantically, and the description does not clarify whether id and topic are mutually exclusive or can be combined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Resolve' with a clear resource ('capability from the claims ledger') and names three supported lookup paths: claim id (C-nn), standing-limitation id (L-nn), or topic. It also distinguishes this from siblings like check_job and search_docs by emphasizing the claims-ledger domain and the evidence/limitation pairing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly communicates when to use the tool by specifying lookup by id (C-nn), limitation id (L-nn), or topic. It implies topic is useful when the id is unknown, though it does not explicitly name alternatives like check_job or search_docs or provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Keyword search across this framework's documentation set (README, AGENTS, ARCHITECTURE, PRODUCT, DECISIONS and everything under docs/). Returns the file path, the nearest heading and an excerpt for each hit. Read-only; it serves documentation, never customer records.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | Words that must all appear on the same line. Case-insensitive. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the output format (file path, nearest heading, excerpt per hit) and explicitly labels the tool as read-only and non-customer-data, matching the annotations. No contradictions or surprises.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that conveys the essential information without unnecessary fluff. It is perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains what the tool does, what it returns, and its read-only nature. It doesn't cover edge cases or error handling, but for a straightforward search tool, this is adequate. Minor lack of detail about the 'nearest heading' concept, but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not add any information about the parameters 'query' and 'limit' beyond what is already in the schema. Since the schema already describes both parameters, the description adds no value to parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Keyword search') and specific resource ('this framework's documentation set'), listing the included document types. It distinguishes itself from sibling tools (get_capability, check_job) by focusing on documentation search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states the tool is read-only and never serves customer records, implying it should be used for documentation queries. However, it doesn't provide explicit guidance on when to prefer this tool over alternatives, though the purpose is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0check_jobget_capabilitysearch_docsScored across 3 tools
Each tool targets a distinct concern: capability resolution, job support status, and documentation search. No two tools could easily be confused.
Consistent verb_noun pattern (get_capability, check_job, search_docs) with snake_case throughout.
Three tools is a compact set, each serving a clear purpose without redundancy; the count fits the narrow domain.
The tools cover the main query paths (specific capability lookup, job support checking, and doc search). A minor gap is the lack of a list-all or overview tool, but agents can likely work around it.
Design domain models and generate deterministic multi-stack code, driven by your coding agent.
Typed, deterministic tools on a live Salesforce or HubSpot copy, every write audited and reversible.
Build and publish full-stack apps from your coding agent: models, rules, pages, auth, per-app MCP.
CRM + visual automation builder AI agents can drive via MCP: contacts, tags, maps, email/SMS flows.