@unson/brainbase-mcp 0.3.1 → 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,553 +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
- ## マニュアル
14
+ ## なぜ必要か
12
15
 
13
- 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.
16
+ 会社では、資料や議事録が残っていても、次のものは人の頭の中に残りがちです。
14
17
 
15
- 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.
18
+ - なぜこの顧客を優先したのか
19
+ - なぜ売上になる提案を断ったのか
20
+ - 何を守るために、その方針を選んだのか
21
+ - どこまでAIや別の担当者へ任せてよいのか
22
+ - 実行後の結果を見て、何を変えるべきなのか
16
23
 
17
- 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.
24
+ この状態では、AIに毎回同じ説明が必要になり、担当者が変わると判断品質が落ち、重要な判断が経営者へ戻り続けます。
18
25
 
19
- ## エージェントと始める
20
-
21
- BrainbaseはCodex、Claude Code、CodeCodeから導入できます。最初に目指すのは接続設定ではなく、自分の文脈を使った役立つ出力です。
22
-
23
- ```bash
24
- npm install
25
- npm run build
26
- npm run onboard:start -- --target codex
27
- ```
26
+ Brainbaseは「何を決めたか」だけでなく、**誰のために、何を優先し、何を守り、どの根拠から決めたか**を残します。
28
27
 
29
- `onboard:start`は日本語の初回導入コマンドです。最小ディレクトリだけを作り、本人、プロジェクト、関係者、判断、メール、カレンダー、ドライブ、タスクの事実は、利用者が承認するまで保存しません。通常表示は次の一手だけに絞り、全項目は`--details`で確認できます。
28
+ ## 具体例
30
29
 
31
- 公開CLIをインストール済みなら、次の5ステップです。
32
-
33
- ```bash
34
- brainbase onboard:start --target codex
35
- # 表示された onboard:seed を確認して実行
36
- brainbase onboard:install --target codex --dry-run
37
- # 設定を承認・反映し、Codexを再起動
38
- # 新しいCodexでBrainbaseのresolve_entity/get_context/searchを使って実際の依頼を試す
39
- ```
30
+ 会社の方針が「単発受託を増やさず、再利用できる資産になる案件を選ぶ」だったとします。
40
31
 
41
- リポジトリをcloneした場合も、`npm run onboard:start -- --target codex`から同じ順序で進めます。
32
+ 一般的なAIは、売上や利益率だけを見て受注を勧めるかもしれません。Brainbaseを参照するAIは、経営者の稼働、再利用性、既存方針、顧客との関係まで確認し、次のように判断できます。
42
33
 
43
- 利用者がBrainbaseの導入を依頼したら、エージェントはチェックリストを返すだけでなく、この公開CLIを実行します。承認された最小文脈を保存し、MCP設定を反映した新しい実エージェントで`resolve_entity`、`get_context`、`search`を使って現実の依頼へ回答します。その実回答を見た本人が「役立った」と判断して初めて初回価値です。`ready: true`、`cli_sample_ready`、CLIの処理時間、合成ペルソナ評価、Skillsやルーティンの生成、`onboard:install --dry-run`だけでは導入完了ではありません。
34
+ > 短期売上は得られますが、経営者の個別稼働が増え、再利用可能な資産も残らないため、現行方針には合いません。導入手順を標準化し、他の担当者でも実施できる条件なら受注候補になります。
44
35
 
45
- For a Google Workspace / Google Drive / local-notes setup, pass the known answers and let the command surface what still needs approval:
36
+ Brainbaseの価値は、情報を多く保存することではありません。**その人や会社なら、なぜそう判断するのかを次の人とAIへ渡すこと**です。
46
37
 
47
- ```bash
48
- node dist/cli.js onboard:start \
49
- --target codex \
50
- --name "Your Name" \
51
- --project "Current project" \
52
- --goal "What this project should achieve" \
53
- --status "Current state" \
54
- --role "Your role" \
55
- --email gmail \
56
- --calendar google-calendar \
57
- --drive google-drive \
58
- --drive-folder "<allowed-google-drive-folder-id>" \
59
- --tasks scattered-calendar-notes
60
- ```
38
+ ## 現在のOSS版
61
39
 
62
- 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.
40
+ このリポジトリは、Brainbaseの共通Judgment DAG基盤と、最初の入口であるローカル優先のPersonal Onboarding Kitを提供します。
63
41
 
64
- If you only want the raw interview protocol, use:
42
+ 現在利用できる主な範囲は次のとおりです。
65
43
 
66
- ```bash
67
- node dist/cli.js onboard:agent
68
- ```
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で実行する
69
49
 
70
- Paste the generated protocol into Codex or Claude Code. The agent should first ask what you do not want to explain repeatedly:
50
+ 組織向けのRBAC、承認、監査、マルチユーザー、managed connector、hosted runtimeは、共通の脳モデルを変えずに組織版で追加する領域です。
71
51
 
72
- - a work premise
73
- - a key relationship
74
- - a decision principle
75
- - an active project
52
+ 実装済み・develop・計画中の境界は、[現在の状態](https://brainbase.pages.dev/guide/status)を参照してください。
76
53
 
77
- Then approve the smallest facts that should become canonical local SSOT and seed them explicitly:
54
+ ## 10分で試す
78
55
 
79
56
  ```bash
80
- brainbase onboard:init
81
- brainbase onboard:seed \
82
- --name "Your Name" \
83
- --value "What should not be re-explained" \
84
- --project "Current project" \
85
- --relationship "Key Partner|collaborator|Context you want AI tools to remember"
86
- ```
87
-
88
- Optionally preview the saved context locally. This is not an onboarding completion signal:
89
-
90
- ```bash
91
- brainbase onboard:demo --scenario "Draft the first note I should send to Key Partner about Current project"
92
- ```
93
-
94
- `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.
95
-
96
- 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.
97
-
98
- After seed, install and verify MCP before asking for the human value judgment:
99
-
100
- ```bash
101
- brainbase onboard:install --target codex --dry-run
102
- brainbase doctor
103
- # restart Codex, use resolve_entity/get_context/search for the real request, then ask whether it was useful
57
+ git clone https://github.com/Unson-LLC/brainbase.git
58
+ cd brainbase
59
+ npm install
60
+ npm run build
61
+ npm run onboard:start -- --target codex
104
62
  ```
105
63
 
106
- 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.
107
-
108
- 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.
109
-
110
- Preview the MCP config before merging it into the real agent config:
64
+ 公開CLIをインストール済みの場合は次を使います。
111
65
 
112
66
  ```bash
67
+ brainbase onboard:start --target codex
68
+ # 表示された onboard:seed を確認して実行
113
69
  brainbase onboard:install --target codex --dry-run
114
- brainbase doctor
115
- ```
116
-
117
- 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:
118
-
119
- ```bash
120
- brainbase onboard:diagnose-sources \
121
- --email gmail \
122
- --calendar google-calendar \
123
- --drive google-drive \
124
- --drive-folder "<allowed-google-drive-folder-id>" \
125
- --tasks notion
126
- ```
127
-
128
- 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.
129
-
130
- 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:
131
-
132
- ```bash
133
- brainbase onboard:plan \
134
- --profile google-workspace-local \
135
- --host mac-mini \
136
- --email google-workspace \
137
- --secondary-email gmail \
138
- --calendar google-calendar \
139
- --drive google-drive \
140
- --drive-folder "<allowed-google-drive-folder-id>" \
141
- --local-folder "<allowed-local-notes-folder>" \
142
- --tasks scattered-calendar-notes \
143
- --inactive-task-tool notion
144
- ```
145
-
146
- 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.
147
-
148
- Candidate files are also optional post-demo review material. They do not count as canonical memory:
149
-
150
- ```bash
151
- brainbase onboard:candidates --write \
152
- --name "Your Name" \
153
- --value "What should not be re-explained" \
154
- --project "Current project" \
155
- --relationship "Key Partner|collaborator|Context you want AI tools to remember"
156
- ```
157
-
158
- Review candidates with the user, then promote only approved facts through `brainbase onboard:seed` or an equivalent explicit promotion flow.
159
-
160
- ### Register active projects
161
-
162
- 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.
163
-
164
- ```bash
165
- # Dry-run first: show the project registration plan without canonical writes
166
- brainbase onboard:projects \
167
- --name "Current project" \
168
- --goal "What this project should achieve" \
169
- --status "Current state" \
170
- --role "Your role" \
171
- --stakeholder "Key Partner|collaborator|Why this person matters" \
172
- --source "drive|Proposal folder|gdrive-folder-id" \
173
- --task-source "Calendar follow-ups" \
174
- --decision-principle "How AI should make tradeoffs in this project"
175
-
176
- # After user approval, promote it into canonical SSOT
177
- brainbase onboard:projects --name "Current project" --goal "Approved goal" --write
70
+ # 設定を承認して反映し、Codexを再起動
71
+ # 新しいセッションで resolve_entity / get_context / search を使う
178
72
  ```
179
73
 
180
- After `--write`, project context is stored in canonical local SSOT and becomes visible through Brainbase MCP `get_context`, `list_entities`, and `search`.
181
-
182
- ### Import collected sources and extract candidates
74
+ `onboard:demo`はローカルCLIのプレビューであり、初回価値の証明ではありません。実際のエージェントがBrainbaseを使った回答を返し、本人が役立つと判断して初めて完了です。
183
75
 
184
- 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.
76
+ 詳しい手順は[10分で試す](https://brainbase.pages.dev/guide/quick-start)にまとめています。
185
77
 
186
- ```bash
187
- # 1. Import collected provider JSON (metadata-first; bodies and file contents are dropped)
188
- gog gmail search "newer_than:90d" --json > /tmp/gmail.json
189
- brainbase onboard:import --source gmail --from /tmp/gmail.json
190
- brainbase onboard:import --source calendar --from /tmp/calendar.json
191
- brainbase onboard:import --source drive --from /tmp/drive.json
192
- brainbase onboard:import --source local --from /tmp/local-notes.json
193
-
194
- # 2. Extract reviewable candidates from sources/ (deterministic; exclude your own address)
195
- brainbase onboard:extract --self-email you@example.com --write
196
-
197
- # 3. Review the extracted candidate file, then promote only selected ids (dry-run by default)
198
- brainbase onboard:apply --from <candidate-file> --select <id> --write
199
- brainbase doctor
200
- ```
201
-
202
- `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`.
203
-
204
- ### Register the daily operating routines
78
+ ## エージェントと始める
205
79
 
206
- 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 に、繰り返し説明したくない文脈を聞き取らせる場合は、最初に次を実行します。
207
81
 
208
82
  ```bash
209
- # Codex host (emits per-file automation.toml documents)
210
- brainbase onboard:routines --target codex --cwd /path/to/brainbase \
211
- --ohayo-hour 7 --oyasumi-hour 22 --retro-dow FRI --retro-hour 17
212
-
213
- # Claude Code host (emits scheduled-task definitions with cron + prompt)
214
- brainbase onboard:routines --target claude --cwd /path/to/brainbase
215
-
216
- # Only some routines, written to a file
217
- brainbase onboard:routines --target codex --routines ohayo,retro --out ./routines.toml
83
+ brainbase onboard:agent
84
+ brainbase onboard:demo --scenario "<Brainbaseを使って答えてほしい実際の依頼>"
218
85
  ```
219
86
 
220
- `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.
221
-
222
- ### Public onboarding skillsを生成する
223
-
224
- Brainbaseには、コーディングエージェント向けの公開safeな最小skillsも入っています。これは内部Brainbase運用skillsではなく、個人オンボーディング、ソース取り込み、候補レビュー、日次ルーティンのための日本語instructionsです。
87
+ 最初の価値確認後に、必要なソースだけを段階的に追加します。エージェントは **diagnose the local source setup** を行い、候補をcanonical SSOTへ直接書き込みません。**Review candidates with the user, then promote only approved facts** を原則にします。
225
88
 
226
89
  ```bash
227
- # Codex-compatible skill paths に合わせて表示
228
- brainbase onboard:skills --target codex
229
-
230
- # Claude Code project skill paths に合わせて表示
231
- brainbase onboard:skills --target claude
232
-
233
- # portableなSKILL.mdをreview用ディレクトリへ書き出す
234
- brainbase onboard:skills --target portable --out ./brainbase-skills
235
-
236
- # 一部のskillsだけ生成する
237
- 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
238
92
  ```
239
93
 
240
- 標準のpublic skill ids:
241
-
242
- - `brainbase-personal-onboarding`
243
- - `brainbase-source-import`
244
- - `brainbase-candidate-review`
245
- - `brainbase-daily-routines`
94
+ **Register active projects** with `brainbase onboard:projects`; dry-runを確認してから、承認済みのプロジェクト文脈だけを`--write`で昇格します。
246
95
 
247
- `onboard:skills` はgeneration-onlyで、defaultはdry-runです。`--out` のときだけファイルを書き、既存の `SKILL.md` はoverwriteしません。live Codex / Claude Code configurationもcanonical SSOTも変更しません。
96
+ ### Google Workspace local-first adopter
248
97
 
249
- `onboard:recommend` remains available when you only want connector guidance:
98
+ 常時稼働のMac mini、Google Workspace、補助Gmail、許可したDrive/local folder、Calendar/notesに散在するタスクを対象にする例です。全Driveやhome directory全体は走査しません。
250
99
 
251
100
  ```bash
252
- brainbase onboard:recommend \
253
- --email gmail \
254
- --calendar google-calendar \
255
- --drive google-drive \
256
- --tasks notion
257
- ```
258
-
259
- External sources are staged as secondary material:
260
-
261
- ```text
262
- ~/.brainbase/personal-os/
263
- sources/
264
- gmail/
265
- calendar/
266
- drive/
267
- tasks/
268
- candidates/
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
269
102
  ```
270
103
 
271
- 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`.
272
-
273
104
  ## 30 Minute Setup
274
105
 
275
- ```bash
276
- npm install
277
- npm run build
278
- npm run onboard:init
279
- 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"
280
- node dist/cli.js onboard:demo --scenario "Draft the first note I should send to Key Partner about Current project"
281
- npm run doctor
282
- npm run onboard:install -- --target codex --dry-run
283
- ```
284
-
285
- The default data directory is:
286
-
287
- ```text
288
- ~/.brainbase/personal-os/
289
- ```
290
-
291
- It contains the canonical local SSOT:
106
+ 手動セットアップ、source allowlist、candidate reviewの詳細は[公開マニュアル](https://brainbase.pages.dev/guide/quick-start)を参照してください。
292
107
 
293
- - `graph.json`: canonical people, organizations, projects, and decisions, plus typed stable-ID edges between them.
294
- - `personal-kg.jsonl`: values, judgment criteria, experiences, and personal context.
295
- - `relationships.json`: relationship context that should survive across tools.
296
- - `decisions.jsonl`: decision records and principles.
297
- - `sources/`: optional raw notes, logs, mail, calendar, drive, and task exports. MCP tools prefer canonical files over these raw materials.
108
+ ## Judgment DAG
298
109
 
299
- 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.
300
- - `candidates/`: staging area for extracted facts before user approval.
301
- - `schemas/`: generated schema references for the local files.
110
+ Brainbaseの内部では、判断を次の流れとして扱います。
302
111
 
303
- For a local checkout, launch the built MCP server with:
112
+ ```text
113
+ Observation
114
+ -> Interpretation
115
+ -> Judgment
116
+ -> Commitment
117
+ -> Action
118
+ -> Outcome
119
+ -> Learning
120
+ -> Judgment update
121
+ ```
122
+
123
+ 公開packageから、Judgment DAGの型、事前検証、ローカルrunnerを利用できます。
124
+
125
+ ```ts
126
+ import { readFileSync } from 'node:fs';
127
+ import {
128
+ executeJudgmentDAG,
129
+ validateJudgmentDAG
130
+ } from '@unson/brainbase-mcp/judgment-dag';
131
+
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);
137
+
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
+ });
304
152
 
305
- ```bash
306
- BRAINBASE_PERSONAL_OS_DIR=/path/to/personal-os npm start
153
+ console.log(checked.execution_order, record.execution_order);
307
154
  ```
308
155
 
309
- The generated MCP client config uses the same idea explicitly: your current Node executable plus this checkout's built `dist/index.js`.
310
-
311
- When installed as a package, you can launch it with:
156
+ 機械可読の公開契約は次の4ファイルです。
312
157
 
313
- ```bash
314
- BRAINBASE_PERSONAL_OS_DIR=/path/to/personal-os brainbase-mcp
315
- ```
316
-
317
- ## 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`
318
162
 
319
- - `get_context`: returns initial AI context from the local Graph and Personal KG.
320
- - `list_entities`: lists `person`, `org`, `project`, `relationship`, and `decision` entities.
321
- - `search`: searches canonical Graph and Personal KG data.
322
- - `resolve_entity`: resolves mentions in text to canonical Graph v2 IDs and returns a privacy-safe evidence receipt.
323
- - `search_personal_kg`: searches owner-local Personal KG only.
324
- - `onboarding_status`: reports seeded areas, first value demo readiness, missing setup, and local connection status.
325
- - `get_ontology`: returns the immutable bundled active Ontology 2.0.0 release without reading Personal OS files.
326
- - `audit_ontology`: audits canonical local files and distinguishes verified violations from unavailable input.
327
- - `infer_decisions`: derives active, superseded, and conflicting decisions from explicit rules.
328
- - `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で拒否されます。
329
164
 
330
- ## Portable Ontology 2.0.0
165
+ `source-lock.sources`は入力契約の固定対象を列挙し、`digest.files`は配布物の各sha256を保持します。総合digestは、各行を`path + NUL + sha256 + LF`としてpath順に連結したcanonical bytesから計算します。
331
166
 
332
- Inspect the semantic contract and audit your local canonical files:
167
+ ## BrainbaseとMana
333
168
 
334
- ```bash
335
- brainbase ontology:show
336
- brainbase ontology:audit
337
- brainbase ontology:audit --ontology-version 0.0.0
338
- brainbase ontology:audit --ontology-version 1.0.0
339
- brainbase ontology:migrate
340
- # previewのexpectedInputDigestを確認してから適用
341
- brainbase ontology:migrate --write --expected-input-digest '<previewの値>'
169
+ ```text
170
+ Brainbase = 判断構造を記憶・整理・実行・再生・評価する
171
+ Mana = いつ動かすかを決め、優先順位を付け、継続的に追跡する
342
172
  ```
343
173
 
344
- `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.
345
- 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.
174
+ Brainbaseは実行可能な組織認知を担います。Manaは、その判断構造を継続的に起動し、仕事を前へ進める自律運営を担います。
346
175
 
347
- 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.
176
+ ## 安全なオンボーディング
348
177
 
349
- 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.
350
-
351
- ## CLI
352
-
353
- When installed as a package, Brainbase exposes two binaries:
354
-
355
- ```bash
356
- brainbase-mcp
357
- brainbase
358
- ```
359
-
360
- 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`.
361
-
362
- Installed package commands:
178
+ 生成物やdry-runだけを導入完了にしません。
363
179
 
364
180
  ```bash
365
- brainbase onboard:init
366
- brainbase onboard:seed
367
- brainbase onboard:demo
368
- brainbase onboard:install --target codex --dry-run
369
- brainbase onboard:import --source gmail --from /tmp/gmail.json
370
- brainbase onboard:extract --self-email you@example.com --write
371
- brainbase onboard:apply --from <candidate-file> --select <id> --write
372
- brainbase onboard:projects --name "Current project" --goal "What this project should achieve"
373
- brainbase onboard:routines --target codex --cwd /path/to/brainbase
374
181
  brainbase onboard:skills --target codex
375
- brainbase ontology:show
376
- brainbase ontology:audit
377
- 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
378
184
  brainbase doctor
379
185
  ```
380
186
 
381
- Local checkout equivalents:
382
-
383
- ```bash
384
- npm run build
385
- node dist/cli.js onboard:agent
386
- node dist/cli.js onboard:demo --scenario "Draft the first note I should send to Key Partner about Current project"
387
- 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
388
- node dist/cli.js onboard:diagnose-sources --email gmail --calendar google-calendar --drive google-drive --drive-folder "<folder-id>" --tasks notion
389
- node dist/cli.js onboard:candidates --write --name "Your Name" --project "Current project"
390
- node dist/cli.js onboard:projects --name "Current project" --goal "What this project should achieve"
391
- node dist/cli.js onboard:import --source gmail --from /tmp/gmail.json
392
- node dist/cli.js onboard:extract --self-email you@example.com --write
393
- node dist/cli.js onboard:apply --from <candidate-file> --select <id> --write
394
- node dist/cli.js onboard:routines --target codex --cwd "$(pwd)"
395
- node dist/cli.js onboard:skills --target codex
396
- node dist/cli.js onboard:recommend --email gmail --calendar google-calendar --drive google-drive --tasks notion
397
- node dist/cli.js judgment:install --target codex --dry-run
398
- npm run onboard:init
399
- npm run onboard:seed -- --name "Your Name"
400
- npm run onboard:install -- --target codex --dry-run
401
- npm run doctor
402
- ```
403
-
404
- Non-interactive seed example:
405
-
406
- ```bash
407
- brainbase onboard:seed \
408
- --name "Your Name" \
409
- --value "Clear ownership and durable decisions" \
410
- --decision-principle "Prefer canonical facts over chat memory" \
411
- --project "Personal AI operating system" \
412
- --relationship "Key Partner|collaborator|Works with me on AI adoption"
413
- ```
414
-
415
- ## Judgment Resolver Host for Codex
416
-
417
- 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.
418
-
419
- Preview the Codex `UserPromptSubmit`, `PostToolUse`, and `Stop` hook snippet:
420
-
421
- ```bash
422
- brainbase judgment:install --target codex --dry-run
423
- ```
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.
424
188
 
425
- 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.
426
190
 
427
- ```bash
428
- brainbase judgment:install --target codex --output /tmp/brainbase-judgment-hooks.json
429
- ```
191
+ ### Autonomy Gate canary
430
192
 
431
- Preserve unrelated hooks, then verify the installed bindings and start a new Codex task:
193
+ Autonomy Gateは既定で`off`です。最初は単一projectだけを明示してHook設定を生成し、出力を確認してからCodex設定へ反映します。
432
194
 
433
195
  ```bash
434
- brainbase doctor --dir ~/.brainbase/personal-os --judgment-hooks ~/.codex/hooks.json
435
- ```
436
-
437
- After installation, the Host instructs the AI to begin every user-facing response with an exact owner-visible audit line such as:
438
-
439
- ```text
440
- 🧠 判断参照: 直前の「ログイン後の白画面を直して」を参照 → 実装依頼として継続 ✓
196
+ brainbase judgment:install --target codex --autonomy-mode canary --autonomy-project brainbase --dry-run
441
197
  ```
442
198
 
443
- 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.
444
-
445
- 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.
446
-
447
- 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.
448
-
449
- 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.
199
+ canaryは、テスト・読取・調査・ローカルで可逆な作業の不要な確認だけを同じCodexターンへ戻します。外部送信、本番操作、破壊、権限変更、機密/個人情報、契約、支払、新しい価値判断は人間境界のままです。判定はローカルjournalへcase-boundなimmutable receiptとして記録されます。
450
200
 
451
- 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.
201
+ ## 公開説明の更新
452
202
 
453
- ## Install MCP Config
454
-
455
- Dry-run output:
203
+ 公開コピーは`docs/publication/public-message.json`から投影されます。マーカー内の文章を個別に手修正しないでください。
456
204
 
457
205
  ```bash
458
- npm run onboard:install -- --target codex --dry-run
459
- npm run onboard:install -- --target claude --dry-run
460
- npm run onboard:install -- --target codecode --dry-run
206
+ npm run docs:check
207
+ npm run docs:sync
461
208
  ```
462
209
 
463
- 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.
464
-
465
- `--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.
466
-
467
- Codex output is TOML for `~/.codex/config.toml` style configuration:
468
-
469
- ```toml
470
- [mcp_servers.brainbase]
471
- command = "/path/to/node"
472
- args = ["/path/to/brainbase/dist/index.js"]
473
-
474
- [mcp_servers.brainbase.env]
475
- BRAINBASE_PERSONAL_OS_DIR = "/path/to/personal-os"
476
- ```
477
-
478
- Claude and CodeCode output use the standard MCP `mcpServers` JSON shape:
479
-
480
- ```json
481
- {
482
- "mcpServers": {
483
- "brainbase": {
484
- "command": "/path/to/node",
485
- "args": ["/path/to/brainbase/dist/index.js"],
486
- "env": {
487
- "BRAINBASE_PERSONAL_OS_DIR": "/path/to/personal-os"
488
- }
489
- }
490
- }
491
- }
492
- ```
493
-
494
- 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.
495
-
496
- ## Migration From Prior Brainbase Repos
497
-
498
- 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.
499
-
500
- Use this repo when you want:
501
-
502
- - Local personal SSOT under `~/.brainbase/personal-os/`.
503
- - MCP access from Codex, Claude, or CodeCode.
504
- - No hosted backend, no Infisical requirement, and no Unson internal data.
505
-
506
- Keep or pin the internal `brainbase-unson` system when you need:
507
-
508
- - Brainbase UI, session runtime, terminal/xterm transport, workflow mission control, or social operations.
509
- - bb.unson.jp, Lightsail, Graph API, JWT/API-token flows, or hosted sync.
510
- - Legacy Graph API MCP tools such as `get_entity`.
511
- - VibePro runtime or internal 31013 operation surfaces.
512
-
513
- 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.
514
-
515
- ## Hosted Backends
516
-
517
- v1 does not support hosted Brainbase backends, Unson APIs, Infisical-managed secrets, bb.unson.jp sync, or Lightsail sync.
518
-
519
- Future hosted behavior should be separated behind an explicit option such as:
210
+ Brainbase Graphから公開説明を昇格する場合は、snapshot hashと人間の承認を含むcandidateを作り、次の順で進めます。
520
211
 
521
212
  ```bash
522
- 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
523
218
  ```
524
219
 
525
- Local MCP mode requires no secrets.
220
+ `public-message-promotion.yml`は同じ処理を行い、直接公開せずレビュー用PRを作成します。
526
221
 
527
- ## Development
222
+ ## 開発
528
223
 
529
224
  ```bash
530
- npm install
225
+ npm ci
531
226
  npm run build
532
227
  npm test
533
- npm pack --dry-run
228
+ npm run docs:check
229
+ npm run docs:build
230
+ npm run docs:smoke
534
231
  ```
535
232
 
536
233
  ### Maintainer release operation
537
234
 
538
- 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:
539
238
 
540
239
  ```bash
541
- RELEASE_REF="${RELEASE_REF:-develop}"
542
- 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"
543
242
  ```
544
243
 
545
- 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.
546
-
547
- 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.
548
245
 
549
- 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
+ ## ドキュメント
550
247
 
551
- 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)
552
256
 
553
- 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