CONCEPT RUNTIME

Concept Runtime

DESIGN BEFORE CODE

要件・データフロー・検証を、実装前に。

コードを書く前に、誰が何を行い、どの状態を通り、どこで止まるかをModelとして動かします。

Concept Runtimeは、実装を一切始めない段階で、自然言語の要件をConcept Modelへ構造化し、 設計とデータフローを決められた条件で検証する開発環境です。Actor、Entity、State Machine、Flow、Permission、Invariant、Decisionを正本として扱い、 ローカルSQLiteへ保存します。

検証を通過した同じModelを、Excel、PDF、Markdown、実際のコード骨格へレンダリングできます。 ただし現行のCode出力は本番アプリケーションを自動完成させるものではなく、types・permissions・MODELの骨格です。 最終的な業務実装や外部作用は、別の実装・承認工程で確定します。

自然言語を一次入口にする

個別コマンドを順番に実行する代わりに、concept runへ自然言語の要求を渡せます。OrchestratorがConcept Model候補を作り、open decisionを確認質問として提示し、回答後にModelを保存、simulate、Quint、コード/設計View生成まで進めます。通常のmurasame TUIにも同じ対話を保守的に分岐するRouterを統合しています。

Model候補の生成はLLM応答を待つため、初回は数十秒〜数分かかる場合があります。CLIは経過秒数を表示し、Ctrl-Cで中断できます。Concept生成専用ターンは一般会話のRouterやread-only tool loopを経由せず、ツールを公開しない1回の構造化推論として実行します。生成中はModelを保存せず、未解決の確認や検査が残る場合も保存・実行へ進みません。生成直後にYes / Noの実効結果が同じno-op Decisionだけを診断付きで最大1回再生成し、それでも残る場合は保存前に停止します。要求本文に開始状態が明記されている場合は、対応Flowのpreconditionsへ直接反映し、不要な確認Decisionを増やしません。確認質問の表示では、安定参照用の英語Flow名ではなく、日本語descriptionがある場合はその説明を使います。

新規Modelへ明示的なIDを付けるときは--new --id ecommerceを使います。 既存Modelを改訂するときは--id ecommerceだけを指定し、存在しないIDを指定した場合は新規作成せず停止します。--answerは確認事項への回答、--yesは推奨回答の適用と保存・実行の最終承認です。非TTYで保存・実行する場合、個別回答を使ったときも--yesを追加します。--jsonではTTYでも確認質問を対話表示せず、Plan JSONをstdout、再実行案内をstderrへ出力します。--dry-run --yesなら推奨回答を適用して検証できますが、保存・実行・成果物生成は行いません。--dry-runだけで未回答のDecisionが残る場合はexit 2になります。LLM再実行ではModelを生成し直すためdecision IDが変わる場合があります。不明なIDで停止したら、その実行で表示されたIDを使ってください。推奨値のない確認事項、意味のないDecision、仕様検査の未解決事項はfail-closedで停止します。自然言語原文はsourceRequirementとして保存されます。

既存Modelの自然言語改訂では、既存Actor・Entity・State Machine・Transition・Flowと、既存の属性・開始前提・Flow stepを候補生成の揺れで失わないようにします。説明文の変更と新しい要素の追加は許容しますが、既存のID、参照関係、状態・遷移の意味、Flowの実行順序を保てない候補は保存前に停止します。既存仕様を意図的に変更する場合は、自然言語改訂で確定せず、notebook / applyの明示編集を使います。

止まったときの次の一手

Concept Runtimeは、不足した意味を推測して保存しません。未回答Decisionはexit 2で確認待ちとして止まり、semantic findingはexit 1で止まります。表示されたDecisionには回答し、findingには対応する役割・対象・状態・遷移・条件を自然言語の要求へ追記して再実行します。TUIでは↑で直前の要求を呼び出して修正できます。

停止時は、権限未定義・権限定義の曖昧さ・識別子の重複・所有者未決定・参照切れ・評価不能なInvariant・未作成Entityへの先行readなど、findingの種類ごとに要求へ追記する内容を表示します。効果のないDecisionは回答へ進みません。解消するには、Yes / Noで変わる二つの業務結果を要求へ明記してください。同じ要求の再実行はLLM候補の再抽選であり、そのDecisionが消える保証はありません。仕様検査のfindingを解消する再実行例には最終承認の --yes を付けず、要求を修正してから改めて確認・承認します。

リモートのGatewayを使う場合は、Concept Runtimeを開始する前に管理者発行のトークンで murasame login を実行し、murasame status がGatewayをreadyと表示することを確認します。ローカルdaemonへ直接接続する場合は、導入ガイドのセルフホスト手順を使います。

通常TUIからの自然言語入口

TUIで「社内のタスク管理システムを設計したい」のように、業務・仕様・設計を作る意図と対象が含まれる入力を送ると、確認質問付きのConcept対話へ自動分岐します。判定はLLMに再送せず、ローカルの保守的な語彙判定です。通常の質問、調査、エラー修正、コードレビューは通常会話の経路に残ります。

生成中はConcept Modelを保存せず、確認中はy / nで回答します。最終承認後にだけ保存・検証・成果物生成を行います。Planモードでは保存・実行を行いません。

Concept Model

Modelは version と任意の implVersion を持ち、Concept ModelとRender済みImplementationのずれを追跡します。 すべての構造はSchemaで検証され、壊れたLLM生成やファイル入力は受け入れません。

CLIのModelを、VS Codeで観測する

CLIが作るconcept.jsonを、読み取り専用のVS Code拡張で探索できます。Actor、Entity、State Machine、Rule、Decisionを確認し、選択したFlowではConcept Modelに存在するstepの順序だけを可視化します。Modelにない接続を推測せず、Concept DBへ直接接続せず、ネットワーク通信やファイル保存も行いません。ここでのread-onlyはVS Code Viewer自身の境界です。Concept RuntimeのCLIは、承認された保存・export・renderの操作として、Concept DBや指定出力先へ明示的に書き込みます。CLIをheadlessな設計フロントエンド、VS Codeを開発者向けのVisual Frontendとして分離します。

codeコマンドを使えない場合は、VS CodeのExtensionsビュー（Ctrl+Shift+X）からInstall from VSIX...を選び、取得したVSIXを指定してください。

Excel・HTML・Markdownにも、要求本文と前提の対応を確認するPreconditionAudit、transition / permission RuleのFlow被覆を確認するOperationCoverageを含めます。これは候補を正しいと証明する機能ではなく、inferred・unverified・uncoveredを人へ知らせる補助表示です。自動補完、保存、検証判定の変更は行いません。

一つのModelを、チームの使う形式へ

ExcelやPDFは共有・レビューのためのView、Markdownは編集の入口、Codeは実装へ引き渡す骨格です。 どの形式もConcept Modelを置き換えず、Model VersionとTraceをたどれるようにします。

現行コマンド

simulate

simulateは実行前にModelの参照先を検査し、曖昧なpermission Ruleや重複識別子があれば先頭要素を暗黙に選ばず停止します。問題がなければScenarioからFlowを決定論的に解決し、各StepでPermission、状態遷移、Invariantを確認します。結果はModel version、Entry、Check、State changeを含むSimulation Traceとして保存されます。

validate → decide

validateはmissing-permission、ambiguous-permission、duplicate-identifier、missing-owner、missing-precondition、unreachable-state、dangling-ref、評価不能な状態Invariant、意味のないDecision、open-decisionを検出します。同じsubject/actionのpermission Ruleが複数ある場合、RuntimeはRuleを合成せず最初のRuleだけを評価するため、保存前に停止します。複数のactorを許可する場合は、1つのRuleのallowedActorIdsへまとめます。Actor・Entity・Flowなど同じスコープの識別子が重複する場合も、Runtimeの参照先が一意に決まらないため保存前に停止します。Invariantは state_is / state_not の決定論的な exprs がない限り、statementから意味を推測せず質問前に停止します。期間・時間・重複、Actor間・レコード間の関係や排他、再申請禁止・履歴などを無関係な状態式へ置き換えた場合も評価不能として停止します。FlowのprimaryEntity以外のState Machine遷移を参照した場合は、別Entityの状態変更を1つのFlowへ混在させた参照範囲不整合として表示します。Decisionは推論結果を自動確定するものではなく、人が --yes または --no を指定してModelの状態を変えます。Yes/Noが同じ効果になるopen Decisionは質問前に停止し、Flowの実行前提も暗黙に補正しません。

verify と render

Formal Verification

verifyはConceptのState MachineをQuintへ射影し、InvariantとCounterexampleを検証資産として保存します。終端状態はstutterで扱い、明示的に非終端としたstuck状態を検査します。これはモデル化された状態機械の検査であり、現実の売上・品質・事故・組織行動を完全に予測するシミュレータではありません。

Specification / Skeleton View

renderはConcept Modelから types.ts、permissions.ts、MODEL.mdを生成します。生成物は骨格またはViewです。再Renderで上書きされるため、生成後の本番実装を双方向に維持するコンパイラではありません。

PDFはローカルのChrome / Chromiumを使って生成します。見つからない環境では MURASAME_CHROME_PATH で実行ファイルを指定するか、PDFを除いた --format html,xlsx,json,markdown で先に検証できます。verifyのQuintは MURASAME_QUINT_BIN を指定して使うか、未指定なら初回取得を伴う npx --yes @informalsystems/quint を実行します。PATH上のQuintを使う場合も、MURASAME_QUINT_BIN で明示してください。

既存コードの取込と継続検証

importは既存コードまたはRender後のコードをImplementation Observationとして保存します。checkは前回の観測をベースラインにして、ファイル変更、Entity、属性、状態、Render markerの差分を検出します。

コードから観測できないIntent、Decision、Constraint、Evidence、業務上のActor / Flowは自動確定しません。 取込結果は差分レポートに留まり、Concept Modelの変更は既存のProposalと明示承認を経由します。

現在の限界

• 通常TUIのRouterは、仕様形成の意図を取りこぼさず全て理解する汎用分類器ではありません。誤ってConcept保存へ入れないことを優先した語彙判定であり、曖昧な要求は通常会話へ残ります。
• Knowledge、Evidence、Work RuntimeとConcept Runtimeを結ぶ共通Trace契約は実装済み。Concept Runtimeへの完全接続は次の統合段階。
• 任意Domainの自然言語から、Review・Conflict・Evidenceを統合した完全なModel Completionは未実装。
• 外部API、ファイル変更、公開などの不可逆作用はCoreの出力をそのまま確定せず、Tool / Approval層の責務。
• Render後のコードはEntity、属性、状態まで観測して再検証できますが、Intent、Decision、Constraint、Evidenceを完全に逆コンパイルする機能ではありません。