@unson/brainbase-mcp 0.4.0 → 0.4.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -1,582 +1,257 @@
1
- # Brainbase 個人オンボーディングキット
1
+ <!-- brainbase:public-message:start -->
2
+ # Brainbase
2
3
 
3
- Brainbaseは、自分が承認した仕事の前提をCodex、Claude Code、CodeCodeへ渡すための、ローカル優先のMCPサーバーです。
4
+ ## 会社の判断を、属人化させない。
4
5
 
5
- 最初の目標は情報源をすべて接続することではありません。自分、仕事、関係者、判断基準の最小文脈を保存し、10分以内に「同じ前提を説明し直さず役立つ出力」を確認することです。
6
+ Brainbaseは、経営者や担当者の判断基準、過去の決定、その理由を会社に残し、AIや次の担当者が同じ前提で考え、動けるようにする仕組みです。
6
7
 
7
- Ontology 2.0.0は、ローカルファイルへ持ち運べる意味契約に、Relation Registryで管理する正規エンティティ間のIDエッジを追加します。ホスト型Brainbaseを必要とせず、型、関係語彙、検証制約、決定論的な判断推論、バージョン移行を定義します。履歴解釈として0.0.0と1.0.0も選択できます。
8
+ > **人の頭の中にある判断を、AIと会社が引き継げるようにする。**
8
9
 
9
- このリポジトリに、社内BrainbaseのUI、セッション実行基盤、xterm転送、ワークフロー管制、SNS運用、ホスト型バックエンド、Infisical設定、雲孫の社内データは含みません。それらは社内版`brainbase-unson`の範囲です。
10
+ 人間が、目的と判断基準、任せてよい範囲を決める。
11
+ AIは、それをもとに調べ、選択肢を比較し、見落としを指摘し、許可された仕事を進める。
12
+ <!-- brainbase:public-message:end -->
10
13
 
11
- ## Judgment DAG公開契約
14
+ ## なぜ必要か
12
15
 
13
- Judgment DAGの型と副作用のない事前検証は、公開`./judgment-dag` subpath(`@unson/brainbase-mcp/judgment-dag`)から利用できます。機械可読の4つの契約ファイルは次のとおりです。
16
+ 会社では、資料や議事録が残っていても、次のものは人の頭の中に残りがちです。
14
17
 
15
- - `contracts/judgment-dag/schema.json`
16
- - `contracts/judgment-dag/fixture.json`
17
- - `contracts/judgment-dag/source-lock.json`
18
- - `contracts/judgment-dag/digest.json`
18
+ - なぜこの顧客を優先したのか
19
+ - なぜ売上になる提案を断ったのか
20
+ - 何を守るために、その方針を選んだのか
21
+ - どこまでAIや別の担当者へ任せてよいのか
22
+ - 実行後の結果を見て、何を変えるべきなのか
19
23
 
20
- 最小の検証例:
24
+ この状態では、AIに毎回同じ説明が必要になり、担当者が変わると判断品質が落ち、重要な判断が経営者へ戻り続けます。
21
25
 
22
- ```ts
23
- import { readFileSync } from 'node:fs';
24
- import { validateJudgmentDAG } from '@unson/brainbase-mcp/judgment-dag';
26
+ Brainbaseは「何を決めたか」だけでなく、**誰のために、何を優先し、何を守り、どの根拠から決めたか**を残します。
25
27
 
26
- const fixtureUrl = import.meta.resolve(
27
- '@unson/brainbase-mcp/contracts/judgment-dag/fixture.json'
28
- );
29
- const dag = JSON.parse(readFileSync(new URL(fixtureUrl), 'utf8'));
30
- const checked = validateJudgmentDAG(dag);
31
- console.log(checked.execution_order); // deterministic node-ID ascending tie-break
32
- ```
28
+ ## 具体例
33
29
 
34
- `node.depends_on`と`relation: "depends_on"` edgeは完全なmirrorであり、missing・cycle・reverse-layer・scope不一致は実行前に拒否されます。
30
+ 会社の方針が「単発受託を増やさず、再利用できる資産になる案件を選ぶ」だったとします。
35
31
 
36
- 配布済みconsumerは、installed package rootから`source-lock.sources`と`digest.files`の各package-relative pathをSHA-256で再計算し、`digest.files`をpath順に`path + NUL + sha256 + LF`で連結したaggregate digestまでreadbackします。`source-lock`はimmutableな`repository`と`accepted_base_commit`を示し、`src/`のような非同梱ファイルはhash対象にしません。
32
+ 一般的なAIは、売上や利益率だけを見て受注を勧めるかもしれません。Brainbaseを参照するAIは、経営者の稼働、再利用性、既存方針、顧客との関係まで確認し、次のように判断できます。
37
33
 
38
- この契約はrunner、artifact、execution log、replay/evaluation、Execution/Evaluation mutation protectionを含まないJ0-2非目標のcore sliceです。
34
+ > 短期売上は得られますが、経営者の個別稼働が増え、再利用可能な資産も残らないため、現行方針には合いません。導入手順を標準化し、他の担当者でも実施できる条件なら受注候補になります。
39
35
 
40
- ## マニュアル
36
+ Brainbaseの価値は、情報を多く保存することではありません。**その人や会社なら、なぜそう判断するのかを次の人とAIへ渡すこと**です。
41
37
 
42
- Read the public onboarding manual at [brainbase.pages.dev](https://brainbase.pages.dev/). It guides users through five phases: choose one real use case, register approved work context, prove the first value, add only necessary sources, and operationalize Skills, routines, and MCP.
38
+ ## 現在のOSS版
43
39
 
44
- For the shortest safe path, open [10分で試す](https://brainbase.pages.dev/guide/quick-start). It keeps the first prompt, MCP setup, optional Judgment Host setup, verification, and interruption recovery in one resumable checklist.
40
+ このリポジトリは、Brainbaseの共通Judgment DAG基盤と、最初の入口であるローカル優先のPersonal Onboarding Kitを提供します。
45
41
 
46
- The manual is the best starting point for first-time users. It explains Brainbase concepts, the first onboarding flow, MCP registration, project context setup, source onboarding, daily routines, and CLI reference.
42
+ 現在利用できる主な範囲は次のとおりです。
47
43
 
48
- ## エージェントと始める
44
+ - ローカルSSOTへ、自分、プロジェクト、関係者、判断基準、決定事項を保存する
45
+ - MCP経由でCodex、Claude Code、CodeCodeから文脈を参照する
46
+ - Graph v2とOntology 2.0.0で、人物・組織・プロジェクト・判断を正規IDで接続する
47
+ - `resolve_entity`、`get_context`、`search`で、依頼を正しい文脈へ接続する
48
+ - Judgment DAGを型検証し、ローカルの決定論的runnerで実行する
49
+
50
+ 組織向けのRBAC、承認、監査、マルチユーザー、managed connector、hosted runtimeは、共通の脳モデルを変えずに組織版で追加する領域です。
51
+
52
+ 実装済み・develop・計画中の境界は、[現在の状態](https://brainbase.pages.dev/guide/status)を参照してください。
49
53
 
50
- BrainbaseはCodex、Claude Code、CodeCodeから導入できます。最初に目指すのは接続設定ではなく、自分の文脈を使った役立つ出力です。
54
+ ## 10分で試す
51
55
 
52
56
  ```bash
57
+ git clone https://github.com/Unson-LLC/brainbase.git
58
+ cd brainbase
53
59
  npm install
54
60
  npm run build
55
61
  npm run onboard:start -- --target codex
56
62
  ```
57
63
 
58
- `onboard:start`は日本語の初回導入コマンドです。最小ディレクトリだけを作り、本人、プロジェクト、関係者、判断、メール、カレンダー、ドライブ、タスクの事実は、利用者が承認するまで保存しません。通常表示は次の一手だけに絞り、全項目は`--details`で確認できます。
59
-
60
- 公開CLIをインストール済みなら、次の5ステップです。
64
+ 公開CLIをインストール済みの場合は次を使います。
61
65
 
62
66
  ```bash
63
67
  brainbase onboard:start --target codex
64
68
  # 表示された onboard:seed を確認して実行
65
69
  brainbase onboard:install --target codex --dry-run
66
- # 設定を承認・反映し、Codexを再起動
67
- # 新しいCodexでBrainbaseのresolve_entity/get_context/searchを使って実際の依頼を試す
68
- ```
69
-
70
- リポジトリをcloneした場合も、`npm run onboard:start -- --target codex`から同じ順序で進めます。
71
-
72
- 利用者がBrainbaseの導入を依頼したら、エージェントはチェックリストを返すだけでなく、この公開CLIを実行します。承認された最小文脈を保存し、MCP設定を反映した新しい実エージェントで`resolve_entity`、`get_context`、`search`を使って現実の依頼へ回答します。その実回答を見た本人が「役立った」と判断して初めて初回価値です。`ready: true`、`cli_sample_ready`、CLIの処理時間、合成ペルソナ評価、Skillsやルーティンの生成、`onboard:install --dry-run`だけでは導入完了ではありません。
73
-
74
- For a Google Workspace / Google Drive / local-notes setup, pass the known answers and let the command surface what still needs approval:
75
-
76
- ```bash
77
- node dist/cli.js onboard:start \
78
- --target codex \
79
- --name "Your Name" \
80
- --project "Current project" \
81
- --goal "What this project should achieve" \
82
- --status "Current state" \
83
- --role "Your role" \
84
- --email gmail \
85
- --calendar google-calendar \
86
- --drive google-drive \
87
- --drive-folder "<allowed-google-drive-folder-id>" \
88
- --tasks scattered-calendar-notes
89
- ```
90
-
91
- The output is intentionally command-ready for Codex and Claude Code. It keeps OAuth tokens out of chat, starts with metadata-first collection, requires Drive/local folder allowlists, and keeps `sources/` plus `candidates/` as secondary material until the user approves canonical writes.
92
-
93
- If you only want the raw interview protocol, use:
94
-
95
- ```bash
96
- node dist/cli.js onboard:agent
97
- ```
98
-
99
- Paste the generated protocol into Codex or Claude Code. The agent should first ask what you do not want to explain repeatedly:
100
-
101
- - a work premise
102
- - a key relationship
103
- - a decision principle
104
- - an active project
105
-
106
- Then approve the smallest facts that should become canonical local SSOT and seed them explicitly:
107
-
108
- ```bash
109
- brainbase onboard:init
110
- brainbase onboard:seed \
111
- --name "Your Name" \
112
- --value "What should not be re-explained" \
113
- --project "Current project" \
114
- --relationship "Key Partner|collaborator|Context you want AI tools to remember"
115
- ```
116
-
117
- Optionally preview the saved context locally. This is not an onboarding completion signal:
118
-
119
- ```bash
120
- brainbase onboard:demo --scenario "Draft the first note I should send to Key Partner about Current project"
121
- ```
122
-
123
- `onboard:demo` reads only locally saved, approved facts. It does not call an LLM, an agent, or a hosted backend. Its result is only a preview. Continue through MCP installation, restart the selected agent, make a real request using `resolve_entity`, `get_context`, and `search`, and ask the user whether that actual answer was useful.
124
-
125
- After the demo, keep onboarding open: the preview is not the first-value gate. Continue until a real agent uses Brainbase and the human user confirms that the result was useful.
126
-
127
- After seed, install and verify MCP before asking for the human value judgment:
128
-
129
- ```bash
130
- brainbase onboard:install --target codex --dry-run
131
- brainbase doctor
132
- # restart Codex, use resolve_entity/get_context/search for the real request, then ask whether it was useful
70
+ # 設定を承認して反映し、Codexを再起動
71
+ # 新しいセッションで resolve_entity / get_context / search を使う
133
72
  ```
134
73
 
135
- The recommended order is public skills, `ohayo` / `oyasumi` / `retro` routines registered paused or confirmation-gated, real MCP config merge after approving the dry-run snippet, source allowlist / import / candidate review decisions, then `doctor` plus MCP `resolve_entity` / `get_context` / `search` verification from a fresh agent session.
74
+ `onboard:demo`はローカルCLIのプレビューであり、初回価値の証明ではありません。実際のエージェントがBrainbaseを使った回答を返し、本人が役立つと判断して初めて完了です。
136
75
 
137
- The commands above are still safe by default. `onboard:skills` and `onboard:routines` generate output unless you provide an explicit `--out`, and `onboard:install --dry-run` is only a preview. Do not treat those generated artifacts as installed until the user approves file writes, scheduler registration, and live config changes.
76
+ 詳しい手順は[10分で試す](https://brainbase.pages.dev/guide/quick-start)にまとめています。
138
77
 
139
- Preview the MCP config before merging it into the real agent config:
140
-
141
- ```bash
142
- brainbase onboard:install --target codex --dry-run
143
- brainbase doctor
144
- ```
145
-
146
- Source setup is optional follow-up work. After the demo, ask Brainbase to diagnose the local source setup only when the demo shows that more context is needed or when you want to import existing tools:
147
-
148
- ```bash
149
- brainbase onboard:diagnose-sources \
150
- --email gmail \
151
- --calendar google-calendar \
152
- --drive google-drive \
153
- --drive-folder "<allowed-google-drive-folder-id>" \
154
- --tasks notion
155
- ```
156
-
157
- Gmail, Google Calendar, and Google Drive diagnosis uses local GoG-style collection when available. The first pass should be metadata-first. Drive collection requires explicit folder allowlists. If GoG is missing, diagnosis reports `needs_setup` instead of pretending import is ready.
158
-
159
- For a Google Workspace local-first adopter with an always-on SSH-accessible Mac mini, Workspace mail/calendar/drive, a secondary Gmail account, local files, and tasks scattered across Calendar and notes, generate the setup plan first:
160
-
161
- ```bash
162
- brainbase onboard:plan \
163
- --profile google-workspace-local \
164
- --host mac-mini \
165
- --email google-workspace \
166
- --secondary-email gmail \
167
- --calendar google-calendar \
168
- --drive google-drive \
169
- --drive-folder "<allowed-google-drive-folder-id>" \
170
- --local-folder "<allowed-local-notes-folder>" \
171
- --tasks scattered-calendar-notes \
172
- --inactive-task-tool notion
173
- ```
174
-
175
- This plan treats the Mac mini as the user's local MCP runtime host, not as a hosted Brainbase backend or server-operations handoff. Google Workspace and Gmail are staged through read-only metadata-first GoG steps. Google Drive and local files are allowlist-first; do not scan the whole Drive or home directory. If Notion was tried and abandoned, keep it as inactive context and extract task candidates from Google Calendar and approved local notes instead.
176
-
177
- Candidate files are also optional post-demo review material. They do not count as canonical memory:
178
-
179
- ```bash
180
- brainbase onboard:candidates --write \
181
- --name "Your Name" \
182
- --value "What should not be re-explained" \
183
- --project "Current project" \
184
- --relationship "Key Partner|collaborator|Context you want AI tools to remember"
185
- ```
186
-
187
- Review candidates with the user, then promote only approved facts through `brainbase onboard:seed` or an equivalent explicit promotion flow.
188
-
189
- ### Register active projects
190
-
191
- Brainbase can register active projects from the onboarding interview before any external source is connected. Codex or Claude Code should ask the user about the project goal, current status, their role, key stakeholders, allowed source areas, task sources, and project-specific decision principles. Source references are metadata-only allowlists; this command does not read mail, calendar, drive, task, or local-note content.
192
-
193
- ```bash
194
- # Dry-run first: show the project registration plan without canonical writes
195
- brainbase onboard:projects \
196
- --name "Current project" \
197
- --goal "What this project should achieve" \
198
- --status "Current state" \
199
- --role "Your role" \
200
- --stakeholder "Key Partner|collaborator|Why this person matters" \
201
- --source "drive|Proposal folder|gdrive-folder-id" \
202
- --task-source "Calendar follow-ups" \
203
- --decision-principle "How AI should make tradeoffs in this project"
204
-
205
- # After user approval, promote it into canonical SSOT
206
- brainbase onboard:projects --name "Current project" --goal "Approved goal" --write
207
- ```
208
-
209
- After `--write`, project context is stored in canonical local SSOT and becomes visible through Brainbase MCP `get_context`, `list_entities`, and `search`.
210
-
211
- ### Import collected sources and extract candidates
212
-
213
- Once the diagnosed GoG collectors have produced metadata JSON, complete the value loop locally. Brainbase still never authenticates to a provider; it only normalizes already-collected JSON, derives candidates, and promotes the ones you select.
214
-
215
- ```bash
216
- # 1. Import collected provider JSON (metadata-first; bodies and file contents are dropped)
217
- gog gmail search "newer_than:90d" --json > /tmp/gmail.json
218
- brainbase onboard:import --source gmail --from /tmp/gmail.json
219
- brainbase onboard:import --source calendar --from /tmp/calendar.json
220
- brainbase onboard:import --source drive --from /tmp/drive.json
221
- brainbase onboard:import --source local --from /tmp/local-notes.json
222
-
223
- # 2. Extract reviewable candidates from sources/ (deterministic; exclude your own address)
224
- brainbase onboard:extract --self-email you@example.com --write
225
-
226
- # 3. Review the extracted candidate file, then promote only selected ids (dry-run by default)
227
- brainbase onboard:apply --from <candidate-file> --select <id> --write
228
- brainbase doctor
229
- ```
230
-
231
- `onboard:import` and `onboard:extract` never write canonical SSOT. Only `onboard:apply --write` promotes selected candidates into `graph.json`, `personal-kg.jsonl`, `relationships.json`, and `decisions.jsonl`.
232
-
233
- ### Register the daily operating routines
78
+ ## エージェントと始める
234
79
 
235
- Loading context once is not enough; the operating loop runs every day. Generate personal-scoped morning (`ohayo`), end-of-day (`oyasumi`), and weekly retrospective (`retro`) routines for whichever coding agent you run. Brainbase prints the definition; your agent registers it with its own scheduler. The routines are scoped to your own connected sources and local Brainbase MCP context — they are not the internal Unson operations.
80
+ Codex または Claude Code に、繰り返し説明したくない文脈を聞き取らせる場合は、最初に次を実行します。
236
81
 
237
82
  ```bash
238
- # Codex host (emits per-file automation.toml documents)
239
- brainbase onboard:routines --target codex --cwd /path/to/brainbase \
240
- --ohayo-hour 7 --oyasumi-hour 22 --retro-dow FRI --retro-hour 17
241
-
242
- # Claude Code host (emits scheduled-task definitions with cron + prompt)
243
- brainbase onboard:routines --target claude --cwd /path/to/brainbase
244
-
245
- # Only some routines, written to a file
246
- brainbase onboard:routines --target codex --routines ohayo,retro --out ./routines.toml
83
+ brainbase onboard:agent
84
+ brainbase onboard:demo --scenario "<Brainbaseを使って答えてほしい実際の依頼>"
247
85
  ```
248
86
 
249
- `onboard:routines` is generation-only and dry-run by default: it prints definitions, writes a file only with `--out`, never registers a live scheduler, and never writes canonical SSOT.
250
-
251
- ### Public onboarding skillsを生成する
252
-
253
- Brainbaseには、コーディングエージェント向けの公開safeな最小skillsも入っています。これは内部Brainbase運用skillsではなく、個人オンボーディング、ソース取り込み、候補レビュー、日次ルーティンのための日本語instructionsです。
87
+ 最初の価値確認後に、必要なソースだけを段階的に追加します。エージェントは **diagnose the local source setup** を行い、候補をcanonical SSOTへ直接書き込みません。**Review candidates with the user, then promote only approved facts** を原則にします。
254
88
 
255
89
  ```bash
256
- # Codex-compatible skill paths に合わせて表示
257
- brainbase onboard:skills --target codex
258
-
259
- # Claude Code project skill paths に合わせて表示
260
- brainbase onboard:skills --target claude
261
-
262
- # portableなSKILL.mdをreview用ディレクトリへ書き出す
263
- brainbase onboard:skills --target portable --out ./brainbase-skills
264
-
265
- # 一部のskillsだけ生成する
266
- brainbase onboard:skills --target codex --skills brainbase-source-import,brainbase-candidate-review
90
+ brainbase onboard:diagnose-sources --email gmail --calendar google-calendar --drive google-drive --drive-folder "<folder-id>" --tasks notion
91
+ brainbase onboard:candidates
267
92
  ```
268
93
 
269
- 標準のpublic skill ids:
270
-
271
- - `brainbase-personal-onboarding`
272
- - `brainbase-source-import`
273
- - `brainbase-candidate-review`
274
- - `brainbase-daily-routines`
94
+ **Register active projects** with `brainbase onboard:projects`; dry-runを確認してから、承認済みのプロジェクト文脈だけを`--write`で昇格します。
275
95
 
276
- `onboard:skills` はgeneration-onlyで、defaultはdry-runです。`--out` のときだけファイルを書き、既存の `SKILL.md` はoverwriteしません。live Codex / Claude Code configurationもcanonical SSOTも変更しません。
96
+ ### Google Workspace local-first adopter
277
97
 
278
- `onboard:recommend` remains available when you only want connector guidance:
98
+ 常時稼働のMac mini、Google Workspace、補助Gmail、許可したDrive/local folder、Calendar/notesに散在するタスクを対象にする例です。全Driveやhome directory全体は走査しません。
279
99
 
280
100
  ```bash
281
- brainbase onboard:recommend \
282
- --email gmail \
283
- --calendar google-calendar \
284
- --drive google-drive \
285
- --tasks notion
101
+ brainbase onboard:plan --profile google-workspace-local --host mac-mini --email google-workspace --secondary-email gmail --calendar google-calendar --drive google-drive --drive-folder "<folder-id>" --local-folder "/Users/owner/Notes" --tasks scattered-calendar-notes --inactive-task-tool notion
286
102
  ```
287
103
 
288
- External sources are staged as secondary material:
289
-
290
- ```text
291
- ~/.brainbase/personal-os/
292
- sources/
293
- gmail/
294
- calendar/
295
- drive/
296
- tasks/
297
- candidates/
298
- ```
299
-
300
- Do not paste OAuth tokens, passwords, API keys, or refresh tokens into chat. Imported mail, calendar, drive, and task material stays under `sources/` until reviewed. Only approved candidates should be promoted into `graph.json`, `relationships.json`, `personal-kg.jsonl`, or `decisions.jsonl`.
301
-
302
104
  ## 30 Minute Setup
303
105
 
304
- ```bash
305
- npm install
306
- npm run build
307
- npm run onboard:init
308
- npm run onboard:seed -- --name "Your Name" --value "What matters in your work" --project "Current project" --relationship "Key Partner|collaborator|Context you want AI tools to remember"
309
- node dist/cli.js onboard:demo --scenario "Draft the first note I should send to Key Partner about Current project"
310
- npm run doctor
311
- npm run onboard:install -- --target codex --dry-run
312
- ```
106
+ 手動セットアップ、source allowlist、candidate reviewの詳細は[公開マニュアル](https://brainbase.pages.dev/guide/quick-start)を参照してください。
313
107
 
314
- The default data directory is:
108
+ ## Judgment DAG
109
+
110
+ Brainbaseの内部では、判断を次の流れとして扱います。
315
111
 
316
112
  ```text
317
- ~/.brainbase/personal-os/
113
+ Observation
114
+ -> Interpretation
115
+ -> Judgment
116
+ -> Commitment
117
+ -> Action
118
+ -> Outcome
119
+ -> Learning
120
+ -> Judgment update
318
121
  ```
319
122
 
320
- It contains the canonical local SSOT:
123
+ 公開packageから、Judgment DAGの型、事前検証、ローカルrunnerを利用できます。
321
124
 
322
- - `graph.json`: canonical people, organizations, projects, and decisions, plus typed stable-ID edges between them.
323
- - `personal-kg.jsonl`: values, judgment criteria, experiences, and personal context.
324
- - `relationships.json`: relationship context that should survive across tools.
325
- - `decisions.jsonl`: decision records and principles.
326
- - `sources/`: optional raw notes, logs, mail, calendar, drive, and task exports. MCP tools prefer canonical files over these raw materials.
125
+ ```ts
126
+ import { readFileSync } from 'node:fs';
127
+ import {
128
+ executeJudgmentDAG,
129
+ validateJudgmentDAG
130
+ } from '@unson/brainbase-mcp/judgment-dag';
327
131
 
328
- Brainbase CLI and MCP readers coordinate canonical updates with a local process lock and recover interrupted multi-file writes before reading. Code that opens the four canonical files directly does not participate in that lock, so concurrent raw filesystem reads are outside the atomic consistency guarantee. Use the Brainbase CLI or MCP tools when another Brainbase process may be writing.
329
- - `candidates/`: staging area for extracted facts before user approval.
330
- - `schemas/`: generated schema references for the local files.
132
+ const fixtureUrl = import.meta.resolve(
133
+ '@unson/brainbase-mcp/contracts/judgment-dag/fixture.json'
134
+ );
135
+ const dag = JSON.parse(readFileSync(new URL(fixtureUrl), 'utf8'));
136
+ const checked = validateJudgmentDAG(dag);
331
137
 
332
- For a local checkout, launch the built MCP server with:
138
+ const record = await executeJudgmentDAG({
139
+ run_id: 'example-run',
140
+ dag,
141
+ input: { source: 'fixture' },
142
+ runners: {
143
+ deterministic: {
144
+ version: 'example-runner-1.0.0',
145
+ run: ({ node, dependency_outputs }) => ({
146
+ node_id: node.id,
147
+ dependency_ids: dependency_outputs.map(({ node_id }) => node_id)
148
+ })
149
+ }
150
+ }
151
+ });
333
152
 
334
- ```bash
335
- BRAINBASE_PERSONAL_OS_DIR=/path/to/personal-os npm start
153
+ console.log(checked.execution_order, record.execution_order);
336
154
  ```
337
155
 
338
- The generated MCP client config uses the same idea explicitly: your current Node executable plus this checkout's built `dist/index.js`.
339
-
340
- When installed as a package, you can launch it with:
341
-
342
- ```bash
343
- BRAINBASE_PERSONAL_OS_DIR=/path/to/personal-os brainbase-mcp
344
- ```
156
+ 機械可読の公開契約は次の4ファイルです。
345
157
 
346
- ## MCP Tools
158
+ - `contracts/judgment-dag/schema.json`
159
+ - `contracts/judgment-dag/fixture.json`
160
+ - `contracts/judgment-dag/source-lock.json`
161
+ - `contracts/judgment-dag/digest.json`
347
162
 
348
- - `get_context`: returns initial AI context from the local Graph and Personal KG.
349
- - `list_entities`: lists `person`, `org`, `project`, `relationship`, and `decision` entities.
350
- - `search`: searches canonical Graph and Personal KG data.
351
- - `resolve_entity`: resolves mentions in text to canonical Graph v2 IDs and returns a privacy-safe evidence receipt.
352
- - `search_personal_kg`: searches owner-local Personal KG only.
353
- - `onboarding_status`: reports seeded areas, first value demo readiness, missing setup, and local connection status.
354
- - `get_ontology`: returns the immutable bundled active Ontology 2.0.0 release without reading Personal OS files.
355
- - `audit_ontology`: audits canonical local files and distinguishes verified violations from unavailable input.
356
- - `infer_decisions`: derives active, superseded, and conflicting decisions from explicit rules.
357
- - `ontology_impact`: explains compatibility, migration, and rollback from an earlier ontology version.
163
+ `node.depends_on`と`relation: "depends_on"` edgeは完全なmirrorです。missing、cycle、reverse-layer、scope不一致、不正runner登録は、最初のrunner呼び出し前にfail closedで拒否されます。
358
164
 
359
- ## Portable Ontology 2.0.0
165
+ `source-lock.sources`は入力契約の固定対象を列挙し、`digest.files`は配布物の各sha256を保持します。総合digestは、各行を`path + NUL + sha256 + LF`としてpath順に連結したcanonical bytesから計算します。
360
166
 
361
- Inspect the semantic contract and audit your local canonical files:
167
+ ## BrainbaseとMana
362
168
 
363
- ```bash
364
- brainbase ontology:show
365
- brainbase ontology:audit
366
- brainbase ontology:audit --ontology-version 0.0.0
367
- brainbase ontology:audit --ontology-version 1.0.0
368
- brainbase ontology:migrate
369
- # previewのexpectedInputDigestを確認してから適用
370
- brainbase ontology:migrate --write --expected-input-digest '<previewの値>'
169
+ ```text
170
+ Brainbase = 判断構造を記憶・整理・実行・再生・評価する
171
+ Mana = いつ動かすかを決め、優先順位を付け、継続的に追跡する
371
172
  ```
372
173
 
373
- `ontology:audit` exits non-zero when an error-level violation exists or when a canonical file cannot be verified. It never reports an unavailable or malformed source as zero violations. Warnings, such as a relationship whose person is not yet present in the Graph, remain visible but do not block approved writes.
374
- Use `--ontology-version 0.0.0` to interpret a pre-kernel snapshot without retroactively applying the later `effectiveAt`, supersession, conflict, or validation rules. Use `--ontology-version 1.0.0` for the immutable first portable release. When the flag is omitted, Graph v2 uses its recorded ontology binding; legacy Graph data uses the active 2.0.0 release. The selected version is included in audit and inference results; unsupported versions fail explicitly.
375
-
376
- Decision evolution is opt-in, read-compatible, and write-gated. Existing decision rows remain readable. New rows may add `topic`, `supersedes`, and `effectiveAt`; only an explicit `supersedes` reference makes an older decision inactive. Multiple active decisions with the same explicit `topic` are reported as a conflict instead of being silently resolved.
377
-
378
- Before enabling 2.0.0 writes, back up the Personal OS directory, run the read-only historical audit when upgrading from 1.0.0, and preview `brainbase ontology:migrate`. Apply the migration only with the preview's `expectedInputDigest`; a concurrent input change blocks the write. Existing rows remain readable, but error-level semantic violations must be reviewed before a canonical write. Roll back by restoring the pre-migration backup and reinstalling the recorded last known working package version.
379
-
380
- ## CLI
174
+ Brainbaseは実行可能な組織認知を担います。Manaは、その判断構造を継続的に起動し、仕事を前へ進める自律運営を担います。
381
175
 
382
- When installed as a package, Brainbase exposes two binaries:
176
+ ## 安全なオンボーディング
383
177
 
384
- ```bash
385
- brainbase-mcp
386
- brainbase
387
- ```
388
-
389
- For local checkout onboarding, run commands through `npm run ...` until the package is installed or linked. `onboard:install` writes a config that launches the built MCP entrypoint with your current Node executable, so the generated config works without guessing whether `brainbase-mcp` is on `PATH`.
390
-
391
- Installed package commands:
178
+ 生成物やdry-runだけを導入完了にしません。
392
179
 
393
180
  ```bash
394
- brainbase onboard:init
395
- brainbase onboard:seed
396
- brainbase onboard:demo
397
- brainbase onboard:install --target codex --dry-run
398
- brainbase onboard:import --source gmail --from /tmp/gmail.json
399
- brainbase onboard:extract --self-email you@example.com --write
400
- brainbase onboard:apply --from <candidate-file> --select <id> --write
401
- brainbase onboard:projects --name "Current project" --goal "What this project should achieve"
402
- brainbase onboard:routines --target codex --cwd /path/to/brainbase
403
181
  brainbase onboard:skills --target codex
404
- brainbase ontology:show
405
- brainbase ontology:audit
406
- brainbase judgment:install --target codex --dry-run
182
+ brainbase onboard:routines --target codex --cwd /path/to/brainbase
183
+ brainbase onboard:install --target codex --dry-run
407
184
  brainbase doctor
408
185
  ```
409
186
 
410
- Local checkout equivalents:
411
-
412
- ```bash
413
- npm run build
414
- node dist/cli.js onboard:agent
415
- node dist/cli.js onboard:demo --scenario "Draft the first note I should send to Key Partner about Current project"
416
- node dist/cli.js onboard:plan --profile google-workspace-local --host mac-mini --email google-workspace --secondary-email gmail --calendar google-calendar --drive google-drive --drive-folder "<folder-id>" --local-folder "<notes-folder>" --tasks scattered-calendar-notes --inactive-task-tool notion
417
- node dist/cli.js onboard:diagnose-sources --email gmail --calendar google-calendar --drive google-drive --drive-folder "<folder-id>" --tasks notion
418
- node dist/cli.js onboard:candidates --write --name "Your Name" --project "Current project"
419
- node dist/cli.js onboard:projects --name "Current project" --goal "What this project should achieve"
420
- node dist/cli.js onboard:import --source gmail --from /tmp/gmail.json
421
- node dist/cli.js onboard:extract --self-email you@example.com --write
422
- node dist/cli.js onboard:apply --from <candidate-file> --select <id> --write
423
- node dist/cli.js onboard:routines --target codex --cwd "$(pwd)"
424
- node dist/cli.js onboard:skills --target codex
425
- node dist/cli.js onboard:recommend --email gmail --calendar google-calendar --drive google-drive --tasks notion
426
- node dist/cli.js judgment:install --target codex --dry-run
427
- npm run onboard:init
428
- npm run onboard:seed -- --name "Your Name"
429
- npm run onboard:install -- --target codex --dry-run
430
- npm run doctor
431
- ```
432
-
433
- Non-interactive seed example:
434
-
435
- ```bash
436
- brainbase onboard:seed \
437
- --name "Your Name" \
438
- --value "Clear ownership and durable decisions" \
439
- --decision-principle "Prefer canonical facts over chat memory" \
440
- --project "Personal AI operating system" \
441
- --relationship "Key Partner|collaborator|Works with me on AI adoption"
442
- ```
443
-
444
- ## Judgment Resolver Host for Codex
445
-
446
- Brainbase includes a local Judgment Resolver core and a Codex lifecycle Host adapter. The Host starts one portable episode at `UserPromptSubmit`, appends ordered tool events at `PostToolUse`, and finalizes the same episode at `Stop`. It builds one canonical context, adopts exactly one receipt for the turn, and gives the model only the selected judgment nodes and audit contract to follow. The full route receipt remains in the local journal instead of being injected into model context. It does not call a hosted Brainbase service, require a secret, or check project access.
447
-
448
- Preview the Codex `UserPromptSubmit`, `PostToolUse`, and `Stop` hook snippet:
449
-
450
- ```bash
451
- brainbase judgment:install --target codex --dry-run
452
- ```
187
+ After the demo, keep onboarding open. Confirm public skills placement, `ohayo` / `oyasumi` / `retro` registration, the real MCP config merge, source allowlist / import / candidate review decisions, and MCP `resolve_entity` / `get_context` / `search` verification.
453
188
 
454
- Review and merge all three printed event bindings into `~/.codex/hooks.json`. The command is preview-only unless `--output` is provided; it never merges into or overwrites an existing config. To save a new snippet file before reviewing it:
189
+ Do not treat those generated artifacts as installed until the user approves file writes, scheduler registration, and live configuration changes.
455
190
 
456
- ```bash
457
- brainbase judgment:install --target codex --output /tmp/brainbase-judgment-hooks.json
458
- ```
191
+ ### Autonomy Gate canary
459
192
 
460
- Preserve unrelated hooks, then verify the installed bindings and start a new Codex task:
193
+ Autonomy Gateは既定で`off`です。最初は単一projectだけを明示してHook設定を生成し、出力を確認してからCodex設定へ反映します。
461
194
 
462
195
  ```bash
463
- brainbase doctor --dir ~/.brainbase/personal-os --judgment-hooks ~/.codex/hooks.json
464
- ```
465
-
466
- After installation, the Host instructs the AI to begin every user-facing response with an exact owner-visible audit line such as:
467
-
468
- ```text
469
- 🧠 判断参照: 直前の「ログイン後の白画面を直して」を参照 → 実装依頼として継続 ✓
196
+ brainbase judgment:install --target codex --autonomy-mode canary --autonomy-project brainbase --dry-run
470
197
  ```
471
198
 
472
- The line identifies the concrete current or prior user statement used as judgment evidence and the decision made from it. The excerpt is collapsed to one line, limited to 26 Unicode characters, and redacts secret-like assignments and token formats. For example, a question may show `「この仕組みを説明して」を参照 → 質問として回答 ✓`; an unresolved follow-up shows `⚠️ 判断参照: 「それでいい」の対象を特定できず → 確認質問` instead of looking like a successful resolution.
199
+ canaryは、テスト・読取・調査・ローカルで可逆な作業の不要な確認だけを同じCodexターンへ戻します。外部送信、本番操作、破壊、権限変更、機密/個人情報、契約、支払、新しい価値判断は人間境界のままです。判定はローカルjournalへcase-boundなimmutable receiptとして記録されます。
473
200
 
474
- Judgment evidence and knowledge-call evidence are separate. A `🧠 判断参照` line says which request the Resolver judged; it never proves that an MCP lookup happened. The Host emits `📚` only after an actual successful portable MCP call and emits `⚠️` for `isError`, malformed, or empty CallToolResult envelopes. The portable mappings are `get_context` → routing (`Brainbase参照先`), `search` → search (`Brainbase検索`), and `search_personal_kg` → retrieval (`Brainbase取得`). Source selection and exclusions appear only when the tool result contains them. When a turn requires no knowledge lookup and none occurred, the exact audit is `📚 Brainbase未参照: 必須参照なし・実呼び出し0回 ✓`; a knowledge-required turn cannot use that line to satisfy retrieval.
201
+ ## 公開説明の更新
475
202
 
476
- Detailed receipts, ordered tool events, the final event snapshot, and the exact owner-visible line are journaled together under `~/.brainbase/personal-os/judgment-journal/`, keyed by session and turn. Replayed tool events with the same `tool_use_id` and content are idempotent; conflicting reuse, corrupt journals, and a `Stop` without a matching active episode fail loudly. Only one receipt is adopted for a turn, and later duplicate hook calls reuse the stored line instead of rendering a possibly different summary. The line reports Resolver judgment evidence; it does not claim that Personal OS knowledge was already retrieved.
477
-
478
- At `Stop`, the Host verifies that all expected audit lines appear at the beginning, exactly once, and in journal order. The first repairable failure returns one bounded block instruction and binds the non-audit answer body by digest. If the active repair changes that body or still omits the required audit contract, the hook exits nonzero with `judgment_stop_repair_exhausted` instead of completing the episode.
479
-
480
- Every turn is judged, including questions and follow-up instructions. If a follow-up has no usable referent, the receipt selects clarification and the AI asks what the user meant; it does not refuse merely because classification or project context is incomplete. A receipt is judgment evidence, not permission to write files, send messages, deploy, purchase, or perform any other external effect. Normal host permissions and user approvals still apply.
481
-
482
- ## Install MCP Config
483
-
484
- Dry-run output:
203
+ 公開コピーは`docs/publication/public-message.json`から投影されます。マーカー内の文章を個別に手修正しないでください。
485
204
 
486
205
  ```bash
487
- npm run onboard:install -- --target codex --dry-run
488
- npm run onboard:install -- --target claude --dry-run
489
- npm run onboard:install -- --target codecode --dry-run
490
- ```
491
-
492
- The command prints a valid MCP server config snippet. Use `--output /path/to/new-snippet-file` when you want Brainbase to write the generated snippet.
493
-
494
- `--output` intentionally creates a new snippet file and refuses to overwrite an existing file. It does not merge into existing Codex, Claude, or CodeCode config files. Review the snippet, then paste or merge it into the target client config yourself so existing MCP servers and client settings are preserved.
495
-
496
- Codex output is TOML for `~/.codex/config.toml` style configuration:
497
-
498
- ```toml
499
- [mcp_servers.brainbase]
500
- command = "/path/to/node"
501
- args = ["/path/to/brainbase/dist/index.js"]
502
-
503
- [mcp_servers.brainbase.env]
504
- BRAINBASE_PERSONAL_OS_DIR = "/path/to/personal-os"
206
+ npm run docs:check
207
+ npm run docs:sync
505
208
  ```
506
209
 
507
- Claude and CodeCode output use the standard MCP `mcpServers` JSON shape:
508
-
509
- ```json
510
- {
511
- "mcpServers": {
512
- "brainbase": {
513
- "command": "/path/to/node",
514
- "args": ["/path/to/brainbase/dist/index.js"],
515
- "env": {
516
- "BRAINBASE_PERSONAL_OS_DIR": "/path/to/personal-os"
517
- }
518
- }
519
- }
520
- }
521
- ```
522
-
523
- Choose a temporary snippet path when using `--output`; do not point it at a live client config unless you have already moved the old file aside.
524
-
525
- ## Migration From Prior Brainbase Repos
526
-
527
- This repository is intentionally replaced as the external Personal Onboarding Kit. It is not a compatible continuation of the previous internal Brainbase UI/runtime package.
528
-
529
- Use this repo when you want:
530
-
531
- - Local personal SSOT under `~/.brainbase/personal-os/`.
532
- - MCP access from Codex, Claude, or CodeCode.
533
- - No hosted backend, no Infisical requirement, and no Unson internal data.
534
-
535
- Keep or pin the internal `brainbase-unson` system when you need:
536
-
537
- - Brainbase UI, session runtime, terminal/xterm transport, workflow mission control, or social operations.
538
- - bb.unson.jp, Lightsail, Graph API, JWT/API-token flows, or hosted sync.
539
- - Legacy Graph API MCP tools such as `get_entity`.
540
- - VibePro runtime or internal 31013 operation surfaces.
541
-
542
- The original MCP surface remains compatible and adds the Ontology tools plus `resolve_entity`. The active Ontology release is 2.0.0; 0.0.0 and 1.0.0 remain available for historical interpretation.
543
-
544
- ## Hosted Backends
545
-
546
- v1 does not support hosted Brainbase backends, Unson APIs, Infisical-managed secrets, bb.unson.jp sync, or Lightsail sync.
547
-
548
- Future hosted behavior should be separated behind an explicit option such as:
210
+ Brainbase Graphから公開説明を昇格する場合は、snapshot hashと人間の承認を含むcandidateを作り、次の順で進めます。
549
211
 
550
212
  ```bash
551
- BRAINBASE_BACKEND=hosted
213
+ npm run docs:promotion:plan -- --candidate /path/to/candidate.json
214
+ npm run docs:promotion:apply -- --candidate /path/to/candidate.json
215
+ npm run docs:check
216
+ npm run docs:build
217
+ npm run docs:smoke
552
218
  ```
553
219
 
554
- Local MCP mode requires no secrets.
220
+ `public-message-promotion.yml`は同じ処理を行い、直接公開せずレビュー用PRを作成します。
555
221
 
556
- ## Development
222
+ ## 開発
557
223
 
558
224
  ```bash
559
- npm install
225
+ npm ci
560
226
  npm run build
561
227
  npm test
562
- npm pack --dry-run
228
+ npm run docs:check
229
+ npm run docs:build
230
+ npm run docs:smoke
563
231
  ```
564
232
 
565
233
  ### Maintainer release operation
566
234
 
567
- Scoped package publication is configured as public. Configure the repository Actions secret `NPM_TOKEN`, then normally publish a version-bumped merge from the reviewed `develop` history. The merge trigger plans the version delta automatically. For the first `0.1.0` publication or recovery, dispatch the same package-wide serialized workflow from the GitHub CLI. `NPM_TOKEN` must be authorized to publish `@unson/brainbase-mcp`.
235
+ Publication is serialized by the GitHub workflow. Direct local `release:publish` is rejected; maintainers must not publish with a local npm token.
236
+
237
+ Dispatch the reviewed ref once when automatic publication needs recovery:
568
238
 
569
239
  ```bash
570
- RELEASE_REF="${RELEASE_REF:-develop}"
571
- gh workflow run npm-publish.yml --repo Unson-LLC/brainbase --ref develop -f release_ref="$RELEASE_REF"
240
+ RELEASE_REF="<reviewed-develop-commit>"
241
+ gh workflow run npm-publish.yml --ref develop -f release_ref="$RELEASE_REF"
572
242
  ```
573
243
 
574
- Dispatch the reviewed ref once and retain the Actions run URL as release evidence. Do not rerun a failed first-publication attempt until its failure phase is known: if it stopped before registry mutation, revert or correct the reviewed release change before a new dispatch; if npm already contains the version, treat that version as immutable and use the verification or version-bump recovery path below.
575
-
576
- Direct local `release:publish` is rejected because it would bypass the package-wide Actions concurrency queue. The CLI requires a runner-issued GitHub OIDC attestation for the exact upstream workflow on `refs/heads/develop` and the current run, so caller-set Actions environment variables or the same workflow path on another ref are not sufficient. Local `release:plan`, `release:validate`, and `release:verify` remain available for credential-free diagnosis; all registry mutation goes through the workflow above.
244
+ After the workflow succeeds, verify npm `gitHead`, `dist.integrity`, and dist-tag, and verify that the GitHub Release targets the reviewed release commit. If npm already contains the version, treat that version as immutable; fix the source, increment the version, and run the reviewed workflow again.
577
245
 
578
- The validation CLI rejects dirty checkouts and commits outside the trusted ref, then runs build, test, production dependency audit, creates the real tarball without an npm credential, and stamps its manifest with the exact reviewed `gitHead` before hashing it. Publication requires the matching proof, rechecks both SHA-256 and npm-compatible SHA-512 integrity, publishes that same tarball with lifecycle scripts disabled, and compares registry `dist.integrity` with the validated artifact. It is idempotent: it publishes an absent version, or verifies that an existing immutable version has the same Git commit and bytes. It also reconciles the appropriate npm dist-tag. The workflow runs validation in a read-only job with no OIDC or npm credential, then transfers the immutable artifact to a separately permissioned publication job with npm provenance. The publish CLI requires the upstream GitHub Actions context and the workflow serialization marker, so supported mutation paths share one package queue. Its manual `release_ref` input is restricted to commits reachable from `develop` and is used for the first publication or recovery. `release:verify` is read-only and fails if metadata or dist-tags do not match.
246
+ ## ドキュメント
579
247
 
580
- Publication is complete only after the Actions `validate` and `publish` jobs pass, the npm registry reports the expected version, `gitHead`, `dist.integrity`, and dist-tag, and the matching GitHub Release targets the reviewed release commit. Retain those registry values, the GitHub Release URL, and the Actions run URL together; a green workflow or GitHub Release alone is insufficient. If `NPM_TOKEN` is absent or the workflow is disabled, read-only local CLI operations still work, but the npm release remains incomplete.
248
+ - [公開マニュアル](https://brainbase.pages.dev/)
249
+ - [Brainbaseの全体像](https://brainbase.pages.dev/guide/grand-design)
250
+ - [Judgment DAGの考え方](https://brainbase.pages.dev/guide/judgment-system)
251
+ - [現在の状態](https://brainbase.pages.dev/guide/status)
252
+ - [MCPツール](https://brainbase.pages.dev/reference/mcp-tools)
253
+ - [Core Philosophy](docs/core-philosophy.md)
254
+ - [Judgment DAG architecture](docs/architecture/judgment-dag-core.md)
255
+ - [Judgment DAG milestones](docs/management/judgment-dag-milestones.md)
581
256
 
582
- npm versions are immutable. Before publication, fix the cause and rerun the same reviewed ref. After a faulty publication, deprecate that version, keep users on the last known-good pinned version, and release a reviewed version bump; never overwrite the published bytes. Any manual dist-tag rollback requires a separate registry metadata and support review.
257
+ MIT License