Geek out.
Stay dope.

情報を整え、モデルに渡し、出力を確かめる。アプリの仕事に合わせてAIの処理を組み立てる。

ノードを選ぶと、その役割がわかります。

• App task→Transformデータ・処理
• Transform→Generateデータ・処理
• Generate→Gateデータ・処理
• Gate→App resultデータ・処理
• Generate→Model provider利用・依存
• Model provider→Generate結果・応答

型がつながるStepでTransform、Generate、Gateを構成。モデル提供者とツールは境界の外に置き、アプリが権限と見せ方を決める。

02

AIへの依頼を、確かめながら進められる。

要約や抽出を、ひとつの回答を待つだけの操作から、途中で条件を確かめられる処理へ。アプリが検証する箇所を決めることで、人へ届ける結果の扱い方を設計できる。

利用場面を描いた生成画像です。実際の利用者や製品画面ではありません。

保存するだけで終わらない。検索、索引、グラフを組み合わせ、アプリが関係をたどれる土台へ。

ノードを選ぶと、その役割がわかります。

• App models→DatabaseKit利用・依存
• DatabaseKit→DBContext / Query利用・依存
• DBContext / Query→StorageEngine利用・依存
• StorageEngine→DBContext / Query結果・応答
• DBContext / Query→App / Relations結果・応答

アプリのモデル宣言をDatabaseKitで受け、実行層がクエリとトランザクションを処理する。物理保存は注入したStorageEngineが担う。

02

データのつながりが、次の判断を助ける。

ひとつの記録を見つけた先で、関連する記録やその関係をたどれる。検索とグラフを使うアプリの土台として、情報を点ではなく文脈として読めるようにする。

利用場面を描いた生成画像です。実際の利用者や製品画面ではありません。

話す、書く、添える。表現の入り口を、ひとつの自然な操作へ。

ノードを選ぶと、その役割がわかります。

• App state→ToolbarContainer利用・依存
• ToolbarContainer→Editor / Attach利用・依存
• ToolbarContainer→VoiceButton利用・依存
• Editor / Attach→App send / Voiceデータ・処理
• VoiceButton→App send / Voiceデータ・処理

ToolbarContainerにエディタ、添付、音声、送信を組み合わせる。状態と送信処理はアプリへ戻し、入力UIだけを責務にする。

02

言葉も声も、考えを届ける入口になる。

文章にする、声にする、資料を添える。そのときの考えに合う伝え方を、ひとつの入力面から選べる。受け取った入力をどう活かすかは、アプリが決める。

利用場面を描いた生成画像です。実際の利用者や製品画面ではありません。

アプリの呼び出しが、そばの機器の動きになる。接続先の役割を、Actorとして扱う。

ノードを選ぶと、その役割がわかります。

• Central→BLEActorSystemデータ・処理
• BLEActorSystem→BLETransportデータ・処理
• BLETransport→PeripheralActorデータ・処理
• PeripheralActor→Central結果・応答

Centralが役割を解決し、BLEActorSystemとBLETransportが呼び出しを転送・再構成する。PeripheralActorからの結果が戻る。

02

ソフトウェアの届く先が、画面の外へ広がる。

アプリの中で決めたことを、そばにある機器の反応につなげられる。互換性のある機器との呼び出しと応答を通じて、操作の結果を実物で確かめる道具をつくれる。

利用場面を描いた生成画像です。実際の利用者や製品画面ではありません。

読めるHTMLを先に。操作が必要な部分へ、Swiftのクライアント部品を足す。

ノードを選ぶと、その役割がわかります。

• Scene / Page→HTMLDocumentデータ・処理
• HTMLDocument→Browser / HTMLデータ・処理
• Scene / Page→ClientComponent選択する経路
• ClientComponent→Browser / HTML選択する経路

SceneとページのルーティングからサーバーHTMLを生成。選択したClientComponentだけをWASMでハイドレーションする、分岐した構成。

02

読みたい情報へ、まずたどり着ける。

ページの内容を読むことと、機能を操作することを分けて届ける。すべてのクライアント処理を読み始める条件にせず、必要な場所へ操作を足すウェブを組み立てられる。

利用場面を描いた生成画像です。実際の利用者や製品画面ではありません。

感じたことから、どう動くかへ。学習するCoreとReflexを、決定的な運動出力へつなぐ試み。

ノードを選ぶと、その役割がわかります。

• NerveBundle→Gating / Trunksデータ・処理
• Gating / Trunks→Core / Reflexデータ・処理
• Core / Reflex→MotorNerveデータ・処理
• Core / Reflex→Mojo runtime利用・依存
• MotorNerve→Plant / Worldデータ・処理
• Plant / World→NerveBundle結果・応答

NerveBundleからGatingとTrunksを通り、Core/Reflex、MotorNerve、Plantへ。Swiftが意図と寿命を、Mojoが数値処理を所有する。

02

機械の振る舞いを、環境との関係から考える。

感じたことが動きになり、その結果をまた感じる。この循環を学習と運動制御の両面から研究することで、環境に応じた機械の振る舞いを設計する基盤を目指している。

利用場面を描いた生成画像です。実際の利用者や製品画面ではありません。

寸法と拘束、作った順序をモデルに残す。見える三角形の手前に、編集できる形の理由を。

ノードを選ぶと、その役割がわかります。

• CADDocument→CADKernelデータ・処理
• CADKernel→B-rep / Meshデータ・処理
• B-rep / Mesh→Consuming appデータ・処理
• B-rep / Mesh→CADExchange選択する経路

CADDocumentのパラメータ、スケッチ、フィーチャー履歴をCADKernelが評価。B-repとメッシュは派生結果、交換形式は別の出力境界。

02

設計の意図が、次の変更を支える。

寸法や条件が変わったとき、形をつくった理由へ戻って調整できる。パラメータと拘束、作成履歴を残すことで、試行を積み重ねながら設計を育てられる。

利用場面を描いた生成画像です。実際の利用者や製品画面ではありません。

端末同士が見つかり、役割を持ってやり取りする。アプリのつながり方を組み立てる。

ノードを選ぶと、その役割がわかります。

• PeerID / Discovery→Selected Transport利用・依存
• Selected Transport→TLS / Crypto利用・依存
• Selected Transport→Mux / Protocolsデータ・処理
• Mux / Protocols→Peer appデータ・処理
• Peer app→PeerID / Discovery結果・応答

PeerIDと発見、選択したTransport、外部の暗号化層、ストリーム多重化を構成。用途に応じたプロトコルを、その上で動かす。

02

端末どうしの関係から、アプリを組み立てられる。

誰と、何を、どうやり取りするかを起点に、通信を組み立てられる。端末ごとの役割と用途に合わせて、相手の発見、通信経路、交換するプロトコルを選べる。

利用場面を描いた生成画像です。実際の利用者や製品画面ではありません。

物体と関節の関係から、動きと力を読み解く。機構を試すための実行基盤を育てる。

ノードを選ぶと、その役割がわかります。

• Body / Joint→Bounded loweringデータ・処理
• Bounded lowering→CompiledModelデータ・処理
• CompiledModel→Runtime evolutionデータ・処理
• Runtime evolution→Analysis appデータ・処理

BodyとJointの記録を制限付きの変換へ渡し、コンパイルしたモデルを実行時に進める。運動と診断は、幾何形状とは別の責務。

02

形の良し悪しを、動きから考える。

形ができた先で、力がどう伝わり、部品がどう連動するかを検討する。動きの振る舞いから機構の選択を考えられるよう、解析の実行基盤を開発している。

利用場面を描いた生成画像です。実際の利用者や製品画面ではありません。

大きなコードベースを、宣言とつながりの地図にする。AIエージェントが、必要な実装へたどり着くための索引。

ノードを選ぶと、その役割がわかります。

• Source files→Tree-sitterデータ・処理
• Tree-sitter→SkeletonIndexCoreデータ・処理
• SkeletonIndexCore→Declarations / rangesデータ・処理
• Declarations / ranges→CLI / MCPデータ・処理
• CLI / MCP→Coding agent / personデータ・処理
• Coding agent / person→Source files結果・応答

Tree-sitterで宣言を抽出し、SkeletonIndexCoreが型・メソッド・継承関係と元ファイルの行範囲をまとめる。CLIやMCPから地図を読み、気になる箇所の実装へ戻る。