nocobase-portal-manage

目的

通常の NocoBase UI 作成リクエストを、明示的に解決した 1 つの Portal にすべて割り当て、環境の選択、ソースストレージの設定、変更後の明確な読み戻しを維持しながら Portal ワークスペースを管理します。

スコープ

• Portal の一覧と詳細を確認します。
• 通常の NocoBase のページ、メニュー、ブロック、フィールド、アクション、レイアウト、リアクションに関するリクエストはすべて、対象の環境と Portal の解決から始めます。
• nocobase-ui-builder スキルを使用して、ノーコードの Portal UI を作成します。
• Portal のソースディレクトリを特定するか取得した後、nocobase-ai-builder スキルを使用して AI Portal のソース開発を行います。
• テンプレートから Portal ワークスペースを作成します。
• Git リポジトリ、ブランチ、パスを含め、Portal のソースストレージを設定します。
• ローカルワークスペース、NocoBase ストレージ、Git ソースストレージ間で Portal のソースをプルおよびプッシュします。
• Portal をデプロイするか、Portal の開発モードを開始します。
• Portal CLI と Git ソースストレージの一般的な問題を診断します。
• 明示的な依頼と確認がある場合に限り、Portal を破棄します。

対象外

• このスキル内でノーコードの Modern UI ページ、ブロック、メニュー、リアクション、ページコンテンツを直接作成しないでください。Portal の環境とワークスペースのコンテキストを維持したまま、nocobase-ui-builder スキルを使用してください。
• このスキル内で AI Portal のソース変更を直接実装しないでください。ソースディレクトリを解決または取得し、同じリクエストを nocobase-ai-builder に引き継いでください。
• アプリのランタイムライフサイクル、CLI のセルフアップデート、環境設定、インストール済みスキルの更新は管理しないでください。nocobase-env-manage に引き継いでください。
• バックアップの復元や移行の公開は管理しないでください。nocobase-publish-manage に引き継いでください。
• ユーザーの表現、テンプレート、ソースの構成、現在のディレクトリ、ローカルファイルから Portal の種類を推測しないでください。選択したレコードの portalType のみを使用してください。
• 通常の UI 構築で AI Portal が選択された場合、その構築リクエストは、ソースプロジェクトで変更を実装してテストする権限も与えます。ソースコードの変更について別途許可を求めないでください。
• 公開された nb portal コマンドの範囲外で、データベースや NocoBase の内部を変更しないでください。
• nb portal の代わりにラッパースクリプト、Docker の代替コマンド、直接 SQL を実行しないでください。
• nb portal が存在しないことを、プライベート API を介して Portal のライフサイクル、ソースストレージ、同期、デプロイ、破棄の各操作を模倣する許可と見なさないでください。

厳守事項

• nb portal ... コマンドを実行する前に、nb portal --help、nb --help、または同等のローカルコマンドヘルプ確認を使い、インストール済み CLI が Portal コマンド群を公開していることを確認してください。
• Portal のライフサイクル、ソースストレージ、同期、デプロイ、診断操作には、コマンド群が利用可能な場合、nb portal の直接コマンドを使用してください。
• nb portal が利用できない場合は、ライフサイクル／ソース／デプロイ／破棄タスクはインストール済み CLI バージョンでは実行できないと報告し、CLI の更新や環境関連の作業は nocobase-env-manage に引き継いでください。トランスポートを切り替えてはいけません。
• 「Portal」という単語が含まれていない場合でも、通常の NocoBase UI 作成リクエストすべてのエントリーポイントとして、このスキルを扱ってください。
• 通常の UI 作成で書き込みを行う前に、nb portal list -j を使って構造化 Portal インベントリを確認してください。enabled === true のレコードのみを数えてください。
• nb portal list -j の isDefault／デフォルトマーカーは、情報提供のみを目的とする読み取り結果として扱ってください。選択肢の一覧表示や読み取り結果の報告には含めますが、有効な Portal が複数ある場合の選択には決して使用しないでください。
• ユーザーが Portal を指定した場合は、構造化レコード内の CLI name と完全一致するものを照合してください。一致するレコードがちょうど1件あり、そのレコードが enabled === true の場合にのみ続行してください。一致なし、無効、一意でない場合は、代替の Portal を選ばずに停止してください。
• ユーザーが Portal を指定していない場合、有効な Portal が0件なら UI の構築を停止し、自動的に作成してはいけません。1件なら自動選択します。複数なら、ユーザーが明示的に選べるよう name と portalType を一覧表示してください。
• 有効な Portal が複数ある場合、isDefault === true のレコードを自動選択してはいけません。デフォルトマーカーを付けて一覧表示し、対象の Portal を明示するようユーザーに尋ねてください。
• 複数の Portal の中から対象を、cwd、アクティブなファイル、近くにある／最近使用した portal.config.json、localPath、同期状態、タイトルの類似性、Portal タイプの優先度から推測してはいけません。
• 選択した Portal の実装パスは、その portalType のみを根拠として決定してください。リクエスト、テンプレート、ソースツリー、ローカルワークスペースからタイプを推測してはいけません。
• portal.config.json、localPath、その他のローカルワークスペース情報は、AI Portal が選択された後に限り、また nocobase-ai-builder を実行する前にそのソースプロジェクトの場所を特定する目的に限って使用してください。
• 選択したレコードで portalType === "ai" の場合、nocobase-ai-builder の読み込みと実行は必須です。nb portal list -j または nb portal info <portal> -j が空の developmentPath／localPath／ローカルソースパスを報告する場合は、まず nb portal pull <portal> を実行し、その後 Portal の情報／一覧を再読み込みして、pull した開発ディレクトリに移動してください。解決済みの Portal 名、環境、ローカルソースパス、元のユーザーリクエストを渡してください。その場しのぎのソース編集ワークフローに置き換えてはいけません。
• ソースストレージ設定を AI Portal の作業ディレクトリとして使用してはいけません。sourceStorage、git_repo、git_branch、git_path、--git-path、リポジトリのサブディレクトリ、デプロイ／ストレージパスは、pull／push／deploy のためのリモートストレージ設定です。ローカル開発ディレクトリではありません。ソース編集は、選択した Portal の既存の developmentPath／localPath、または nb portal pull <portal> の結果を再読み込みした後に返されるローカルディレクトリでのみ行ってください。
• コマンドが不明な場合、または nb portal list -j がエンドポイント不在を示す明示的なシグネチャ 404／Not Found を返す場合は、nb portal を実行時に利用できないものとして扱ってください。通常の UI 作成に限り、以下のレガシー機能確認に進みます。Portal のライフサイクル／ソース／デプロイ操作は引き続き実行できません。
• Portal インベントリを実行時に利用できない場合、flow-surfaces list-navigation-targets を Portal インベントリとして使ったり、ノーコードか AI かを推測したりしてはいけません。nb api flow-surfaces list-navigation-targets -j は、capabilities.multiPortal の確認に限って実行してください。false ならレガシー UI Builder の経路を使用でき、true なら停止します。
• Portal 導入前の古いランタイムでは、list-navigation-targets が公開されていない場合があります。そのアクションが明示的に不明、または 404／Not Found を返し、ユーザーが Portal を指定していない場合に限り、次の両方の確認が成功した後でレガシー UI Builder の経路を使用できます。nb api flow-surfaces --help が apply-blueprint と list-templates を公開していること、および nb api flow-surfaces list-templates --body '{}' -j が構造化された成功レスポンスを返すこと。これは検証済みのレガシー Flow Surfaces シグネチャです。認証エラー、5xx、形式不正な出力、コアアクションの欠落、読み取りプローブの失敗があった場合は停止してください。これらをレガシーであることの証拠として解釈してはいけません。
• ユーザーが明示的な環境を指定していない場合は、現在設定されている CLI 環境を使用してください。
• 現在の環境と異なる可能性のある環境を明示的に渡す場合、ユーザーが非対話実行を要求した場合、または対象環境を明示的に確認した場合に限り、--yes を含めてください。
• destroy の前に、ユーザーから明示的な確認を得てください。
• pull --force、create --force、またはローカル Portal ソースを上書きする操作の前に、ユーザーから明示的な確認を得てください。
• 1リポジトリにつき1 Portal の Git ワークフローでは、--git-path . を優先してください。
• ユーザーが同じ Git リポジトリ内に複数の Portal やその他のコンテンツを置くことを希望する場合に限り、サブディレクトリの --git-path 値を使用してください。
• --git-path／git_path の値を、ローカル Portal プロジェクトのように扱って、その場所に移動したり編集したりしてはいけません。これはリポジトリ相対のストレージパスであり、pull した開発ディレクトリではありません。
• 既存の portal.config.json またはリモート Portal レコードに Git パスが設定済みの場合、現在の CLI のデフォルトによってそのパスが書き換えられると想定してはいけません。ユーザーから変更を求められた場合は、nb portal config <portal> --git-path . で明示的に変更してください。
• push では、ユーザーが指定した場合はそのコミットメッセージを使用し、指定がない場合は CLI のデフォルトを適用してください。
• ソースまたは UI の変更後に、push や deploy を自動実行してはいけません。ユーザーが Portal ソースの push／同期／コミットを強調して求めた場合に限り、push を実行してください。ユーザーが Portal のデプロイ／公開／リリースを強調して求めた場合に限り、deploy を実行してください。deploy のリクエストが、先行する push を意味するわけではありません。
• push と deploy の両方が明示的に要求された場合は、それぞれ独立した操作として扱ってください。push が失敗した場合は報告しますが、「push 成功後に deploy」「push が成功した場合にのみ deploy」など、deploy が push の成功を条件とする旨をユーザーが指定していない限り、明示的に要求された deploy を自動的に阻止してはいけません。
• コマンドが失敗した場合は、トランスポートを切り替えず、該当する CLI 出力と、次に実行する具体的な復旧コマンドを報告してください。

サポートされているタスク

• list
• info
• create
• config
• pull
• push
• deploy
• dev
• destroy
• diagnose
• build

入力仕様

入力	必須	デフォルト	検証	確認の質問
action	はい	推測	build/list/info/create/config/pull/push/deploy/dev/destroy/diagnose のいずれか	"どの Portal アクションを実行しますか？"
portal	list 以外のライフサイクルアクションで必須。build では任意	build の場合は有効な Portal が1つだけならそれを使用	CLI の name と完全一致	"どの Portal を対象にしますか？"
runtime_env_name	いいえ	現在の環境	設定済み CLI 環境名	"どの環境を対象にしますか？"
template	create のみ	CLI のデフォルト	npm パッケージ、ローカルパス、または file:// URL	"どの Portal テンプレートを使用しますか？"
title	create のみ	slug から生成	空でない文字列	"この Portal の表示タイトルを指定してください。"
source_storage	create/config のみ	create の場合は nocobase、config の場合は既存の設定	nocobase または git	"ソースストレージには nocobase と git のどちらを使用しますか？"
git_repo	Git の create/config	なし	Git リモートの完全な URL	"Portal のソースを保存する Git リモート URL を指定してください。"
git_branch	いいえ	main	空でないブランチ名	"どの Git ブランチを使用しますか？"
git_path	いいえ	.	リポジトリ内の相対パス。.. は不可	"Portal のソースを保存するリポジトリパスを指定してください。"
message	push のみ	CLI のデフォルト	空でないコミットメッセージ	"どのコミットメッセージを使用しますか？"
force	破壊的操作／上書き操作	false	明示的な確認が必要	"続行する前に、上書き／破壊を確認してください。"

ルール：

• 変更を伴うアクションに必要な入力が不足している場合は、処理を中断し、簡潔な確認の質問を1つしてください。
• ユーザーが「お任せ」と言った場合は、文書化されたデフォルトと直接的な nb portal の動作を使用してください。
• データ、ソース、またはデプロイ結果に実質的な影響がない限り、安全な CLI デフォルトがある任意の入力について質問しないでください。

必須の確認ゲート

• 確認ラウンドの上限：2。
• 1ラウンドあたりの質問の上限：3。
• 変更の前に、action、portal、明示された場合の環境ターゲット、および必要な Git の項目を確認してください。
• destroy の前に、追加の確認を求めてください。
• pull --force または create --force の前に、追加の確認を求めてください。
• git_repo がない状態で Git ストレージを設定する前に、Git リモート URL を尋ねてください。
• Git ソースストレージのエラーに空のリモート、存在しないブランチ、または設定済み Git パスの欠落が示されている場合は、手動の Git コマンドを勧める前に Git ソースストレージを参照して原因を調べてください。

ワークフロー

通常の UI 構築ワークフロー

「Portal」と明示されていない依頼も含め、通常の NocoBase ページ、メニュー、ブロック、フィールド、アクション、レイアウト、またはリアクションに関するすべての依頼には、この手順を使用してください。

1. nb env current と nb env info で現在の環境を確認します。
2. nb portal --help または同等のコマンドヘルプ出力で、Portal CLI のサポート状況を検出します。
3. nb portal が利用できない場合：
   • create/config/pull/push/deploy/dev/destroy/list/info のリクエストでは停止し、CLI 機能が不足していることを報告します。CLI／ランタイムのアップグレードまたは環境診断には nocobase-env-manage を推奨します。
   • 通常の UI 作成では、機能確認としてのみ nb api flow-surfaces list-navigation-targets -j を呼び出します。capabilities.multiPortal が明示的に false の場合は、nocobase-ui-builder のレガシーレーンを使用します。true の場合は停止します。アクションが明示的に不明であるか、404／Not Found が返された場合は、「Hard Rules」で定義された検証済みのレガシー Flow Surfaces プローブを使用します。この完全なプローブが成功した場合にのみ続行します。それ以外の不足、不明瞭、または失敗した結果では、CLI／ランタイムに関する案内をして停止します。
   • ナビゲーションターゲットを、ノーコード／AI Portal の一覧として扱ってはいけません。
4. コマンドのインターフェースが利用可能な場合は、nb portal list -j で構造化された Portal 一覧を確認し、enabled === true のレコードだけを残します。この一覧取得でエンドポイントが存在しないことが明示される（404／Not Found）場合は、Portal 一覧をランタイムで利用できないものとして扱い、通常の UI 作成では手順 3 を適用します。認証エラー、5xx、または不正な出力の場合は適用しません。
5. 対象の Portal を特定します。
   • ユーザーが Portal 名を指定した場合、name が完全一致し、enabled の値が true であるレコードが正確に 1 件必要です。一致するレコードがない、無効になっている、または一意でない場合は、ビルドを停止します。
   • Portal が指定されておらず、有効な Portal が 0 件の場合は、ユーザーに Portal を明示的に作成するよう伝えて停止します。自動作成してはいけません。
   • Portal が指定されておらず、有効な Portal が 1 件の場合は、自動的に選択します。
   • Portal が指定されておらず、Portal が複数ある場合は、それぞれの name、portalType、およびデフォルト状態（ある場合）を一覧表示し、明示的な選択を求めます。UI への書き込みは行いません。isDefault === true のレコードが 1 件だけでも、選択を決定してはいけません。
   • cwd、アクティブなファイル、portal.config.json、localPath、同期状態、タイトルの類似性、またはタイプの優先度から、対象を推測してはいけません。
6. 選択したレコードの portalType を読み取ります。ノーコードと AI の振り分けには、この値だけを使用します。
7. ノーコード Portal の場合は、ページ、メニュー、ブロック、フィールド、アクション、権限の作成に nocobase-ui-builder スキルを使用します。
8. AI Portal の場合は、nb portal info <portal> -j、選択した一覧レコードの developmentPath、localPath、portal.config.json、またはローカルのワークスペース状態を、すでに選択済みの Portal のローカルソースプロジェクトの場所を特定するためだけに使用します。ローカルの開発パスが空または存在しない場合は、先に nb portal pull <portal> を実行し、その後 nb portal info <portal> -j または nb portal list -j で読み直して、pull された開発ディレクトリに移動します。sourceStorage、git_repo、git_branch、git_path、--git-path、およびデプロイ／ストレージのパスは、編集場所として扱わないでください。これらは pull／push／deploy のために Portal ソースが保存されている場所を示すだけです。その後、解決した Portal 名、環境、ソースパス、元のリクエストを指定して nocobase-ai-builder を読み込み、実行します。元のリクエストは実装と検証を許可するものです。コード編集について別途許可を求めてはいけません。
9. portalType が存在しない、またはサポートされていない場合は、推測せずに停止します。
10. UI の変更後、nb portal push や nb portal deploy を自動的に実行してはいけません。ローカルでの検証に必要な場合、またはリクエストされた場合にのみ nb portal dev を使用します。push はソースのプッシュが明示的に意図されている場合のみ、deploy はデプロイが明示的に意図されている場合のみ実行します。

明示的な action=create リクエストは、Portal コマンドワークフローを引き続き実行します。Portal が 0 件の場合に停止する上記のルールは、通常の UI ビルドにのみ適用され、Portal を作成する明示的なライフサイクルリクエストを妨げてはいけません。

Portal コマンドのワークフロー

1. ユーザーのリクエストから Portal のアクションと対象環境を推測します。
2. 不慣れな形式のコマンドを実行する前、またはフラグを使ったコマンドを組み立てる際は、ランタイム契約を読みます。
3. Git ソースストレージの設定またはエラーについては、Git ソースストレージを読みます。
4. アクションを試す前に、nb portal が利用可能か確認します。
5. nb portal が利用できない場合は、フォールバックによる変更を行わずに停止し、利用できないコマンドの機能と、次に行う nocobase-env-manage への引き継ぎを報告します。
6. 不足している必須入力、または必須の確認事項だけを尋ねます。
7. nb portal コマンドを直接実行します。
8. dev を除く書き込みアクションでは、可能な場合は nb portal info <portal> で読み戻します。利用できない場合は nb portal list -j を使います。
9. push では、ソースの変更がコミットされたか、CLI が変更なしと報告したかを伝えます。
10. push と deploy を組み合わせたリクエストでは、指定されたアクションを順番に個別実行します。push が失敗した場合は、その失敗を記録したうえで、必要なデプロイ確認を得てから、リクエストされた deploy を続行します。ただし、ユーザーが push の成功を deploy の条件にしている場合を除きます。リクエストが deploy のみの場合は、push の手順を挿入しません。
11. 失敗した場合は、失敗したコマンド、CLI の主要な出力、考えられる原因、および次に実行するコマンドを返します。

アクションの振り分け

• 「ポータルを表示」「有哪些 portal」「portal 一覧」には list を使います。
• 「portal の詳細」「portal の設定を確認」「現在の git 設定」には info を使います。
• 「portal を作成」「新しい Portal ワークスペース」「テンプレートから」には create を使います。
• 「portal の git を設定」「source storage を変更」「git リポジトリ／ブランチ／パスを設定」には config を使います。
• 「portal のソースコードを取得」「リモートからローカルに同期」には pull を使います。
• push は、「portal のソースコードをプッシュ」「ソースを push」「portal push」「ソースを Git にコミット」「Portal のソースを同期」など、ソースのプッシュが明示されている場合にのみ使います。一般的なビルド、完了、公開、デプロイ、リリースのリクエストから push を推測してはいけません。
• deploy は、「portal をデプロイ」「deploy」「オンラインで公開」「Portal をリリース」など、デプロイが明示されている場合にのみ使います。ユーザーがソースのプッシュも明示的に求めていない限り、先に push を実行してはいけません。
• 「portal dev を起動」「ローカルで Portal を開発」には dev を使います。
• 明示的に削除または破棄を求められた場合にのみ destroy を使います。
• ユーザーがエラーログを提示した場合、または Portal コマンドが失敗した理由を尋ねた場合は、diagnose を使います。
• Portal に言及しているかどうかにかかわらず、通常の NocoBase のページ、メニュー、ブロック、フィールド、アクション、レイアウト、リアクションのリクエストには build を使います。
• UI リクエストに Portal 名がない場合は、まず構造化された環境インベントリを確認します。対象が 0 件なら停止し、1 件だけなら自動的に選択し、複数ある場合は、1 つがデフォルトとしてマークされていても、明示的な選択を求めます。
• ノーコードの Portal ビルドリクエストでは、UI 作成に nocobase-ui-builder スキルを使います。
• AI Portal のビルドリクエストでは、Portal のローカルソースディレクトリを特定します。CLI が開発パスはまだないと報告した場合は、まず nb portal pull <portal> を実行し、その後、取得したディレクトリで nocobase-ai-builder を実行します。git_path／--git-path などのソースストレージパス内で開発してはいけません。

リファレンスの読み込み一覧

リファレンス	使用する場面	備考
ランタイム契約	nb portal コマンドを直接組み立てる、または確認する場合	コマンド一覧、環境フラグの配置、読み戻しのルールが記載されています。
Git ソースストレージ	Git ソースストレージを設定する場合、または Git の push／pull エラーを診断する場合	ルートパスのデフォルト、空のリポジトリ、ブランチ／パスの復旧方法について説明しています。
テストプレイブック	スキルを検証する場合、または機能チェックを計画する場合	テストの追加やスキルの先行テストを行う前に読みます。

Safety Gate

影響の大きい操作：

• nb portal destroy
• nb portal pull --force
• nb portal create --force
• 共有または本番 Portal の Git ソースストレージの設定
• 本番環境に類似した環境への nb portal deploy

二次確認用テンプレート：

• 破棄：Confirm execution: destroy Portal <portal> in env <env>. Expected impact: Portal record/workspace may be removed. Reply confirm to continue.
• ローカルソースの上書き：Confirm execution: overwrite local Portal source for <portal> in env <env>. Reply confirm to continue.
• 本番デプロイ：Confirm execution: deploy Portal <portal> to env <env>. Reply confirm to continue.

ロールバックの指針：

• config の失敗：nb portal info <portal> で確認し、以前の値がわかっている場合は nb portal config を再実行します。
• pull --force の失敗：上書きされたローカルファイルは Git またはバックアップからの復元が必要な場合があります。ロールバック方法を推測してはいけません。
• push の失敗：Git のエラーを確認し、ブランチ、認証、リポジトリ、パスの問題を修正してから再試行します。
• deploy の失敗：CLI の出力を報告し、nb portal info <portal> または利用可能な場合はデプロイ固有の読み戻しを実行します。

検証チェックリスト

• コマンドのインターフェイスが要求された操作をサポートしている場合、操作と Portal の対象を特定します。
• nb portal が利用可能な場合は、直接 nb portal コマンドを使用します。
• Portal コマンドを実行する前に、nb portal が利用可能か確認します。
• 明示的な env の指定を維持します。
• 破壊的な操作または上書き操作の前に、必要な確認を得ます。
• Git ソースストレージのコマンドで必要な場合は、完全なリモート URL を指定します。
• Portal ごとに 1 つのリポジトリを使うワークフローでは、デフォルトの Git パスに . を使用します。
• 書き込み操作後は、nb portal info または nb portal list -j で読み戻しを行います。
• 通常の UI 構築リクエストでは、nb portal list -j を使用し、enabled === true で絞り込み、isDefault は表示または読み戻しにのみ使用してから、実装方法を選ぶ前に Portal を 1 つだけ特定します。
• 明示的な Portal 名は name と完全一致させます。複数の Portal がある場合、選択にローカルコンテキストを使用してはいけません。
• 複数の Portal がある場合、選択にデフォルト状態を使用してはいけません。デフォルト状態はマーカーとしてユーザーにのみ表示します。
• Portal の種類は portalType のみから取得します。
• ノーコードの Portal UI 作成には nocobase-ui-builder スキルを使用します。
• AI Portal UI の作成には、対応する Portal のローカルソースディレクトリで nocobase-ai-builder を使用します。developmentPath / localPath が空の場合は、先に nb portal pull <portal> で取得します。また、git_path / --git-path などのソースストレージパスを編集ディレクトリとして扱ってはいけません。
• UI／ソースの編集後に push や deploy を自動追加してはいけません。ソースの push リクエストでは push のみ、デプロイリクエストでは deploy のみを実行します。両方を明示的に求められた場合は、それぞれ独立して実行します。
• push と deploy の両方を求められた場合は、両方の操作を独立して実行します。push が失敗した場合もその失敗を報告しますが、deploy が push の成功を明示的な条件としていない限り、deploy を妨げてはいけません。
• 失敗時の出力には、失敗したコマンドと関連する CLI の行を含めます。
• 最終回答では、コマンド、結果、読み戻しの状態、前提、残存するリスクを報告します。

最小テストシナリオ

1. list は nb portal list -j を使用し、Portal 名を尋ねません。
2. Git ストレージを使用する config では git_repo が必須で、git_path のデフォルトは . です。
3. 空の Git リポジトリで push を実行すると、ブランチ作成のサポート、または実行可能な復旧方法が提示されます。
4. デプロイのみを求めるリクエストでは deploy のみを実行し、push ステップを挿入しません。
5. ソースのプッシュのみを求めるリクエストでは push のみを実行し、デプロイしません。
6. push と deploy の両方を求めるリクエストでは、両方の操作が独立して要求されている場合、プッシュが失敗してもデプロイを続行します。デプロイをプッシュ成功の条件付きにした場合に限り、デプロイ前に停止します。
7. pull --force は明示的な確認があるまで停止します。
8. destroy は明示的な確認があるまで停止します。
9. 有効な Portal が 0 件の場合、暗黙に作成することなく、通常の UI 作成を停止します。
10. コード不要の Portal がちょうど 1 件の場合は、nocobase-ui-builder スキルを使用します。
11. AI Portal がちょうど 1 件の場合は、そのローカルソースディレクトリを特定します。開発パスがない場合は、まず nb portal pull <portal> を実行し、その後、元のリクエストを添えて nocobase-ai-builder を呼び出します。
12. Portal が複数ある場合は、利用可能であれば name、portalType、デフォルト状態を一覧表示し、cwd、デフォルトマーカー、ローカルファイルから推測せずに、明示的な選択を求めます。
13. 明示的に指定された Portal 名が存在しない、無効である、または一意でない場合は、代わりを選ばずに停止します。
14. アプリの起動／更新リクエストは nocobase-env-manage に引き継ぎます。
15. nb portal がない場合は、ライフサイクル／ソース／デプロイの操作を明確な CLI 機能レポートとともに停止し、非公開 API による代替手段は使用しません。
16. Portal ランタイムのサポートがない場合、list-navigation-targets が capabilities.multiPortal: false を明示的に返すとき、またはアクションが明示的に存在せず、検証済みのレガシー Flow Surfaces シグネチャが成功するときは、レガシー UI Builder の経路を使用できます。true、認証エラー、5xx、不正な形式の出力、コアプローブの失敗が発生した場合は停止します。

出力形式

Portal コマンドを直接実行するタスクでは、必ず以下を返します。

• request
• capability
• commands
• env
• portal
• default
• result
• readback
• assumptions
• next_steps

自然言語による UI 構築タスクでは、以下を返します。

• request
• env
• portal
• default
• capability
• portal_type
• implementation_path
• build_summary
• verification
• next_steps

参考資料

• ランタイム契約
• Git ソースストレージ
• テストプレイブック
• NocoBase Portal CLI ドキュメント：公式コマンドリファレンス。[検証済み：2026-07-28]