マニフェストリファレンス

beeuni.yaml v2 のすべてのキーと、デフォルト値、上限、検証ルール。

マニフェストは、プラットフォームがプロジェクトの正式な設定として扱うファイルです。このページでは、すべての beeuni.yaml (v2) キーについて、型、デフォルト値、プラットフォームによる検証方法を説明します。平易な説明については、プロジェクトを参照してください。

2つの設定領域

Beeuni プロジェクトには、厳密に分離された2つの設定領域があります。

• Beeuni の設定 — リポジトリのルートにある beeuni.yaml は、プロジェクトの環境、エージェント、ツール、コネクタ、トリガーを定義します。サンドボックステンプレートには独自の Dockerfile を指定できます。
• エージェントの設定 — エージェントのファイル、スキル、ハーネスのファイル。サンドボックス内とローカル環境で、エージェントのハーネスが読み取ります。

2026-09 より前に作成されたプロジェクトでは、エージェントとスキルは .beeuni/opencode/ に、メモリは .beeuni/memory/ に置かれています。Beeuni はどちらの構成も読み取ります。

2つの領域をつなぐのは、エージェントの .md ファイルです。マニフェストのキー agents.<name> は、agents.<name>.file が指定するファイル、または file が省略されている場合は agents/<name>.md を対象にします。動作に関するフィールドはすべて、その .md ファイルのフロントマターと本文にのみ記述します。beeuni.yaml には記述しません。

• システムプロンプト
• model、mode
• temperature、top_p
• steps、permission

マニフェストの agents: ブロックで設定するのはガバナンスのみです。起動できるエージェントと、各エージェントがアクセスできる対象を指定します。バリデーターがこれを強制します。v2 のエージェントブロックに動作に関するフィールドが含まれていると、エージェント自身の .md ファイルを示すエラーで拒否します。

場所とバージョン

ルートに有効なマニフェストがあるリポジトリは、Beeuni プロジェクトです。beeuni.yaml (v2、YAML のみ) は新規プロジェクト用の現行フォーマットで、ウェブの「Create project」フローと beeuni init によって作成されます。beeuni.toml (v1) は既存プロジェクトで引き続き使用できますが、プラットフォームは v1 で新しい v2 機能を受け付けません。v1 のスキーマと v1 から v2 への移行手順については、レガシー TOMLを参照してください。

beeuni_version: 2 では YAML が必須です。beeuni_version: 2 を宣言する .toml ファイルは検証に失敗します。2 より大きなバージョンを宣言するマニフェストは、そのまま拒否されるため、プラットフォームが将来のフィールドを誤って読み取ることはありません。トップレベルの不明なキーは無視されるので、独自のメタデータをファイルに置くことができます。

validateManifest() は、beeuni ship、変更リクエストのマージチェック、beeuni validate を支える唯一のゲートです。どこでも同じルールが適用されるため、main にマージされる内容はすべて構造的に正しい状態になります。スキーマは公開されており、同じパッケージから生成されます。

• beeuni.v2.schema.json
• beeuni.v1.schema.json
• beeuni.schema.json (beeuni_version に応じて振り分け)

エディターで検証するには、beeuni.yaml を v2 スキーマに向けるか、CLI から取得してください。

# yaml-language-server: $schema=https://beeuni.ai/schema/beeuni.v2.schema.json
beeuni_version: 2

beeuni schema --version 2

完全な例

beeuni_version: 2
default_agent: beeuni

project:
  name: my-project
  description: What this project is.

env:
  required: [DATABASE_URL]
  optional: [STRIPE_API_KEY, WEBHOOK_SLACK_SECRET]

sandbox:
  templates:
    - slug: ml
      name: ML Development
      dockerfile: Dockerfile.ml
      cpu: 4
      memory: 16

opencode:
  config_dir: harnesses/opencode

agents:
  beeuni:
    file: agents/beeuni.md
    connectors: all
    secrets: all
    beeuni_permissions: all
    skills: all

  release-bot:
    file: agents/release-bot.md
    sandbox: ml
    connectors: [github]
    beeuni_permissions: [project.gitops.push]
    secrets: [GITHUB_AGENT_TOKEN]

triggers:
  - slug: daily-digest
    type: cron
    agent: beeuni
    cron: '0 0 9 * * 1-5'
    timezone: America/Los_Angeles
    prompt: |
      Summarize yesterday's commits. Open a CR against main.

トップレベルのキー

imports:

1つのマニフェストを複数の YAML ファイルに分割できます。beeuni.yaml が1画面に収まらなくなったときに使用します。複数行のプロンプトを含む30個のトリガー、チームごとのコネクタ、エージェントグループごとのファイルなどが該当します。

# beeuni.yaml
beeuni_version: 2
default_agent: beeuni
imports:
  - triggers/                # a directory: every .yaml and .yml file below it
  - agents.yaml              # a single file
agents:
  beeuni:
    connectors: all

beeuni.yaml
agents.yaml
triggers/
  reports/
    weekly.yaml
    monthly.yaml
  dockets/
    freedom-forever.yaml

# triggers/reports/weekly.yaml
triggers:
  - slug: weekly-report
    name: Cross-Sector Weekly Report
    type: cron
    agent: galileo
    cron: "0 15 * * 0"
    prompt: |-
      Build the weekly report.

ルートファイルとそのインポートは、1つのプロジェクト設定を構成します。あるファイルのトリガーから、別のファイルで宣言されたエージェントを指定できます。

ルール

1. パスはリポジトリのルートからの相対パスです。..、絶対パス、glob は拒否されます。
2. ディレクトリをインポートすると、その配下のすべての階層から.yamlファイルと.ymlファイルをすべてパス順に取得します。それ以外のファイルはスキップされます。
3. インポートしたファイルでは、triggers、connectors、agents、apps、tools、importsを宣言します。その他のキー（beeuni_version、default_agent、runtime、project、env、opencode、sandbox、policy、policies）はルートファイルに残します。インポートしたファイルでこれらのキーを設定すると、検証に失敗します。
4. インポートしたファイルから、さらにファイルをインポートできます。上限は深さ8階層、ファイル数200です。循環参照はエラーになります。同じファイルに複数の経路で到達した場合、マージは1回だけ行われます。
5. 1つの名前につき1つのファイルです。トリガーのスラッグ、コネクターのスラッグ、エージェント名、アプリ名、ツール名が2つのファイルで宣言されている場合、両方のファイル名を示すエラーになります。黙って上書きされることはありません。
6. エントリは、インポート元のファイル、その後に記載順でインポート先のファイルという順序でマージされます。

インポートに不備があると、YAML 構文エラーと同様にマニフェスト全体が失敗します。beeuni validate、beeuni ship、および変更リクエストのマージチェックは、mainに到達する前にすべて報告します。

imports: triggers "weekly-report" is declared in both triggers/a.yaml and triggers/b.yaml — one name, one file

編集はエントリを宣言しているファイルに反映されます。 ダッシュボード、API、またはbeeuni triggers enable|disable|rmが、インポートしたファイルで宣言されたトリガー、コネクター、エージェント、アプリを変更すると、そのファイルだけが書き込まれます。ルートファイルは書き換えられません。新しいエントリはルートファイルに書き込まれます。そこに置きたい場合は、手動でインポートしたファイルに移動してください。

importsにはbeeuni.yamlが必要です。beeuni.tomlマニフェストでは、このキーは無視されます。

tools:

セッションで使用できるツールを名前で指定します。値は次の2種類のいずれかです。

tools:
  web_search: beeuni:web_search
  image_search: beeuni:image_search
  scrape_webpage: beeuni:scrape_webpage
  memory: tools/memory.ts                # replaces the Beeuni memory tool
  lookup_order: tools/lookup_order.ts
  crm_note: integrations/crm/note.ts

標準ハーネス と実験的ハーネスは同じモジュールを実行します。モジュールの仕様、beeuni tools ls、 beeuni tools eject、およびharnesses/opencode/tools/からの移行については、 Toolsを参照してください。

選択ルール。

• ルートファイルにもインポートしたファイルにもtoolsキーがない場合、セッションでは5つすべての Beeuni ツールを使用できます。このリストができる前に作成されたすべてのプロジェクトでも、引き続き利用できます。
• toolsキーがある場合は、空でも（tools: {}、またはすべての行を削除したtools:の場合でも）、セッションで使用できるのは、beeuni:<name>またはモジュールパスとして記載された Beeuni ツールだけです。インポートしたファイル内のtoolsキーも対象になります。

beeuni:<name>行を削除すると、そのツールがすべてのエージェントから削除されます。特定のエージェントに限定するには、agents.<name>.toolsを使用してください。

エラー。

• 名前は snake_case です: ^[a-z][a-z0-9_]{0,63}$。

• ハーネスのツール名（bash、read、write、edit、apply_patch、glob、grep、list、task、question、todowrite、webfetch、websearch、skill、lsp、invalid、execute、plan_exit、pty_*）はエラーになります。

• パスの末尾は.ts、.js、.mts、.mjs、.cts、または.cjsである必要があります。/または-で始めたり、.または..のセグメントを含めたりすることはできません。

• 別のキーの下にあるbeeuni:<name>はエラーになります。たとえば、Beeuni ツール名の下にあるweb_search: beeuni:image_searchの場合:

  tools.web_search: `beeuni:web_search`（Beeuni ツール）または置き換え先となる、.ts もしくは .js モジュールへのリポジトリ相対パス（例: `tools/web_search.ts`）である必要があります。

• Beeuni ツールではない名前に対するbeeuni:<name>はエラーになります。例: web_serch: beeuni:web_serch:

  tools.web_serch: .ts もしくは .js モジュールへのリポジトリ相対パス（例: `tools/web_serch.ts`）である必要があります。`beeuni:<name>`は、次の Beeuni ツールをそれぞれの名前で指定します: `web_search: beeuni:web_search`、`image_search: beeuni:image_search`、`scrape_webpage: beeuni:scrape_webpage`、`memory: beeuni:memory`、`show: beeuni:show`。

• beeuni validateは、宣言されたモジュールが存在しない場合も報告します。beeuni:の値にはファイルは必要ありません。

警告。 警告によってbeeuni validateが失敗することはありません。

• 5つの Beeuni ツールのいずれも指定していないtoolsキー:

  tools: このプロジェクトのセッションでは Beeuni ツール（web_search、image_search、scrape_webpage、memory、show）を使用できません。1つを残すには`<name>: beeuni:<name>`を追加してください。

  独自ツールを初めて追加したときに、誤って5つのツールを削除してしまうケースを検出します。

• エージェントのtoolsで、プロジェクトが読み込んでいない Beeuni ツールを指定している場合:

  agents.beeuni.tools: 「show」は、このプロジェクトが読み込んでいない Beeuni ツールです。トップレベルの`tools`の下に`show: beeuni:show`を追加するか、ここから削除してください。

project:

任意のユーザー向けメタデータ: nameとdescription。プラットフォームはこのテーブルを一切参照しません。プロジェクトの表示名は、プロジェクト独自のデータベースレコードから取得されます。リポジトリを読む人向けのドキュメントとして扱ってください。

env:

セッションで必要となる環境変数名を宣言します。値はダッシュボードの「Environment variables」ページに保存し、マニフェスト内に直接記述することはありません。プラットフォームはセッション開始時に値を復号し、通常の環境変数として注入します。

env:
  required: [DATABASE_URL]
  optional: [STRIPE_API_KEY]

環境変数名は^[A-Z_][A-Z0-9_]*$に一致する必要があります。Secrets Manager では名前の長さが64文字までに制限されています。ここではそれより長い名前も解析されますが、値を設定することはできません。BEEUNI_で始まる名前にも値を設定できません。名前は64文字以内にし、BEEUNI_プレフィックスを避けてください。詳細な仕様についてはSecretsを参照してください。

sandbox:とsandbox.templates

起動可能なサンドボックスイメージに名前を付けて一覧表示します。任意項目で、エントリがなければ、すべてのセッションはプラットフォームのデフォルトイメージで起動します。各テンプレートには、dockerfile（リポジトリ相対）またはimage（タグまたはダイジェストを指定した公開 Docker リファレンス）のどちらか一方を指定する必要があります。

sandbox:
  templates:
    - slug: ml
      name: ML Development
      dockerfile: Dockerfile.ml
      cpu: 4
      memory: 16
      disk: 50

各値は正の整数である必要があります。最小値未満の値は、エラーとなり検証に失敗します。最大値を超える値は警告付きで受け付けられ、その後、実行時に上限値へ丸められます。GPU はサポートされていません。gpu を宣言すると、エラーではなく警告が生成されます。ランタイムレイヤーがイメージに追加する内容については、Runtime を参照してください。

sandbox.default

sandbox に default を設定すると、1 つのテンプレートをプロジェクト全体のデフォルトにできます。その後、すべてのセッション、トリガー、チャネルは slug を指定せずにそのテンプレートで起動します。

sandbox:
  default: dev
  templates:
    - slug: dev
      dockerfile: Dockerfile.dev

default には、このマニフェストで宣言されたテンプレート、またはプラットフォームイメージを表す予約値 "default" を指定する必要があります。

エージェントは agents.<name>.sandbox を使用して環境を選択できます。値には、マニフェストまたはダッシュボードのテンプレート、あるいは "default" を指定する必要があります。

agents:
  researcher:
    sandbox: ml

セッションテンプレートは次の順序で解決されます。

1. 明示的に指定されたセッション sandbox_slug。
2. 選択されたエージェントの sandbox。
3. プロジェクトの sandbox.default。
4. プラットフォームの "default"。

Cron トリガー、Webhook トリガー、スケジュール、チャネルは、選択されたエージェントのテンプレートを使用します。

仕様の変更（cpu、memory、disk、container_runtime、またはイメージ自体の変更）により、プロジェクトのスナップショットが再構築されます。新しいサイズは実行中のセッションではなく、次のセッションから適用されます。

opencode:

標準ハーネス 設定ディレクトリの場所。任意ですが、デフォルト値があります。

opencode:
  config_dir: harnesses/opencode

config_dir が設定されていない場合、Beeuni は harnesses/opencode と .beeuni/opencode のうち、opencode.json または opencode.jsonc を含む最初のディレクトリを使用します。そのディレクトリには、標準ハーネス だけが読み取るファイル（opencode.jsonc、plugins/、tools/、commands/）が格納されます。エージェントとスキルはリポジトリルートの agents/ と skills/ に配置します。opencode.jsonc は、プラグイン、MCP サーバー、プロバイダー、権限に関する標準ハーネスネイティブのレジストリとして使用します。これらの設定をマニフェストに重複して記述しないでください。Agents を参照してください。

harnesses:

ハーネスごとの設定。pi.config_dir は、実験的ハーネス ネイティブ設定を含むリポジトリ相対ディレクトリを指します（デフォルト: harnesses/pi、次に .beeuni/pi）。ディレクトリは実験的ハーネスの起動時にインポートされます。pi.packages は別の設定で、エージェントごとのマニフェストの harnesses.pi.packages からパッケージをインストールします。現在存在するパッケージキーは 1 つです。pi.packages は、このプロジェクトのすべての実験的ハーネスセッションが読み込む実験的ハーネスパッケージ（runtime: pi、または pi_harness フラグ）です。パッケージとは packages にあるものを指し、拡張機能（ツール、フック、コマンド）や、パッケージに含まれるスキルとプロンプトが該当します。

runtime: pi
harnesses:
  pi:
    packages:
      - npm:pi-web-access@0.30.0            # pinned extension version
      - source: npm:pi-mcp-adapter@2.36.0
        extensions: ["extensions/*.ts"]     # load only these files of the package
        skills: []                          # load none of its skills
      - ./harnesses/pi/audit.ts             # an extension file in this repository

エントリは最大 20 件です。Git ソースは拒否されます。

エージェントごとの設定

エージェントは、agents.<name>.harnesses の下で独自のパッケージを追加し、トップレベルのパッケージを除外できます。

harnesses:
  pi:
    packages: [npm:pi-web-access@0.30.0]            # every agent
agents:
  researcher:
    harnesses:
      pi:
        packages: [npm:@juicesharp/rpiv-todo@2.11.0] # researcher only
  reviewer:
    harnesses:
      pi:
        exclude: [pi-web-access]                     # reviewer loads no web tools

• エージェントのパッケージは、トップレベルのリストからその exclude を除き、独自の packages を加えたものです。
• トップレベルにも記載されているパッケージについてエージェントがエントリを指定した場合、そのエージェントではトップレベルのエントリが置き換えられます（別のバージョンや別のフィルターを指定できます）。
• exclude には、トップレベルのリストに記述されているパッケージ名（pi-web-access、@scope/name）または ./ パスを指定します。バージョンは指定しません。
• 異なるパッケージリストごとに一度だけビルドされます。同じリストを持つエージェントはビルドを共有します。
• パッケージは、セッションを開始するエージェントに属します。別のエージェントが task ツールで起動したサブエージェントは、標準ワークスペースツール（bash、read、write、edit、glob、grep）のみを使用し、独自のパッケージも親のパッケージも使用しません。ただし、親の拡張フックはその呼び出しに適用されます。そのエージェントでセッションを開始すると、そのパッケージを使用できます。

パッケージがセッションに届くまでの流れ:

1. このリストを編集する変更リクエストをマージすると、サンドボックスプラットフォーム向けに、インストールスクリプトを無効にしてパッケージが一度ビルドされます。各拡張機能は、1 つの minify 済みファイルに事前ビルドされます。ビルドでは、そのファイルにすでに含まれているコード、型宣言、ソースマップ、ルートの README と CHANGELOG を除き、パッケージのその他のファイルが保持されます。同じリストを持つプロジェクトはビルドを共有します。
2. 新しいセッションまたは再起動したセッションは、リポジトリのクローン中にビルドをダウンロードし、各拡張機能を直接読み込みます。セッションが npm install を実行したり、パッケージをコンパイルしたりすることはありません。
3. 事前ビルドできないパッケージ（たとえば、pi.extensions が glob を使用するもの）も動作します。その場合、セッションはインストール済みパッケージから読み込むため、時間がかかります。パッケージのコードがビルドで除外されたファイルのいずれかを読み取る場合は、そのエントリに extensions フィルターを指定してください。セッションはそのパッケージもインストール済みパッケージから読み込みます。
4. ビルドの存在前に開始したセッションは、プロジェクトパッケージなしで起動し、ビルドを開始します。次のセッションからパッケージが使用可能になります。

Beeuni は、すべての実験的ハーネスセッションにシステムパッケージ一式もインストールします。同じパッケージについてプロジェクトのエントリがある場合、システムバージョンが置き換えられます。リポジトリには .pi/extensions/*.ts に実験的ハーネスネイティブ拡張機能を配置することもでき、実験的ハーネス はマニフェストのエントリなしでそれらを読み込みます。

拡張機能はターミナル UI なしで実行されます。ツール、フック、コマンドは動作しますが、ターミナル専用のウィジェットは何もしません。

triggers:

Cron、Webhook、モニター定義のリスト。各エントリは、prompt を最初のメッセージとして実行するセッションを起動します。

triggers:
  - slug: daily-digest
    type: cron
    cron: '0 0 9 * * 1-5'
    prompt: Summarize yesterday's commits.

Cronトリガーには、cron（6フィールド式）またはrun_at（一度限りのISO-8601タイムスタンプ）のいずれか一方と、IANA名のtimezoneが必要です。Webhookトリガーには、broker配信とconnectorコンシューマーを使用するシークレットの名前であるsecret_envが必要です。Monitorトリガーには、run（リポジトリ相対コマンド）とmode（pollまたはstream）が必要で、cronフィールドとwebhookフィールドはすべて拒否されます。全フィールドのリファレンス、認証情報の設定、ペイロードのテンプレート、エンドポイント、セッション戦略については、Triggersを参照してください。

connectors:

エージェントが呼び出せる外部ツールのリストです。定義はgitに保存され、認証情報はプラットフォームに保存されます。マニフェストには保存されません。概念モデルについては、Connectorsを参照してください。

connectors:
  - slug: gmail-read
    name: Gmail read only
    provider: pipedream
    app: gmail
    authorization_strategy: user
    policies:
      - match: search_email
        action: always_run

プロバイダー固有のフィールド:

channelコネクターは、手動でエントリーを記述する必要がほとんどありません。ダッシュボードからチャンネルを接続すると、自動的に作成されます。Slack & channelsを参照してください。beeuni_slack、beeuni_teams、beeuni_email、computerのslugはプラットフォーム専用です。別のプロバイダーで使用すると、検証エラーになります。computerコネクターは、最初のメンバーがコンピューターを接続したときに作成されます。マシンIDはアカウントのコントロールプレーン上のIDであり、マニフェストに含めてはならないためです。

connectors.auth：pipedream以外のプロバイダーでは任意です。typeはbearer、basic、custom、api_key、oauth1、hmac、aws_sigv4、mtls、またはnone（デフォルト）です。oauth1はopenapi、postman、httpプロバイダーに限定されます。inはheader（デフォルト）、query、またはcookieです。typeがcustomまたはapi_keyの場合、nameが必要です。

connectors.policies：{match, action}ペアのリストです。matchはツール名に対するglobです。actionはalways_run、require_approval、またはblockです。ポリシーはコネクターに属します。そのコネクター下のすべての接続で同じポリシーが使用されます。

policy.default_mode：connectors:とは別のトップレベルキーで、プロジェクト全体のコネクター承認モードを設定します。allow_all（デフォルト。一致しないすべてのツールを実行）またはrisk（書き込みおよび破壊的な、一致しない呼び出しに承認を要求）を指定します。beeuni connectors policy set --default <risk|allow_all>で設定します — CLIを参照してください。

チャネル

v2ではスキーマからchannels:が削除されています。チャネルからエージェントへのルーティング（現在はSlack、Microsoft Teams、メール、音声）は、宣言的な設定ではなく、稼働中の運用状態です。ダッシュボードのChannelsページまたはチャットコマンドから設定します。これは認証情報をgitから遠ざける境界と同じです。チャネルを接続すると、エージェントが呼び出すためのprovider: channelを含むconnectorsエントリが引き続き作成されます。Slack & channelsを参照してください。v1の[[channels]]テーブルについては、Legacy TOMLで説明しています。

agents:

エージェント名をキーとする、名前からブロックへのマップです。このマップはガバナンス専用であり、エージェントがアクセスできる対象を許可するものであって、エージェントが発言または実行する内容を許可するものではありません。

このブロックは2つあるバインディングの2つ目です。プリンシパルはBeeuniからロールを取得し、エージェントはここで宣言されたBeeuni権限を追加で持ちます。セッションで実行できるのは、両方が許可する操作だけです。1つの用語体系、2つのバインディングを参照してください。

default_agent: beeuni

agents:
  beeuni:
    file: agents/beeuni.md
    connectors: all
    secrets: all
    beeuni_permissions: all
    skills: all

  release-bot:
    file: agents/release-bot.md
    connectors: [github]
    connectors_required: [github]
    beeuni_permissions: [project.gitops.push]
    secrets: [GITHUB_AGENT_TOKEN]

v2はデフォルトで拒否します。宣言されたエージェントでconnectors、secrets、beeuni_permissions、skills、またはappsを省略すると、noneとして解決されます。上記のstarterのbeeuniエージェントのように、エージェントに必要な権限をすべて明示的に付与してください。v1から移行するプロジェクトでは、すべてを手動で再付与する必要があります。v1ではenv（シークレット）を省略するとallがデフォルトになりますが、これはv2とは逆です。

connectors_personalはconnectors_requiredの非推奨の入力エイリアスとして残っています。新しいマニフェストではconnectors_requiredを使用してください。コネクターのauthorization_strategyによって、認可がプロジェクト所有かメンバー所有かが決まります。

beeuni_permissionsの権限付与元は、プロジェクトスコープの固定された権限セット（project.read、project.gitops.push、project.gitops.merge、project.gitops.ref.any、project.trigger.*、project.secret.*、project.connector.*など）です。アカウントスコープの権限（member.*、billing.*、project.create）をエージェントに付与することはできません。セッション内からbeeuni validate --scopesを実行すると、現在付与可能な一覧が出力されます。

エージェントファイル

agents.<name>.fileは、リポジトリルートからの相対パスでエージェントの.mdを指定します。

agents:
  support:
    file: agents/support.md

• パスは.mdで終わる必要があります。
• パスは/または-で始めてはなりません。.または..セグメントや空のセグメントを含めてはなりません。
• 各セグメントには、文字、数字、_、-、.、スペースのみを使用できます。
• fileを省略すると、Beeuniはまずagents/<name>.md、次に.beeuni/opencode/agents/<name>.mdを読み取ります。opencode.config_dirが設定されている場合、2番目のパスは<config_dir>/agents/<name>.mdです。
• ダッシュボードが.mdを持つエージェントを保存すると、そのパスを指定したfileを書き込みます。
• APIはfileを変更するリクエスト（400、コードinvalid_config）を拒否します。エージェントを移動するには、その.mdを移動し、同じコミットでbeeuni.yaml内のfileを更新してください。

beeuni validateと変更リクエストのマージチェックは、無効なfileをagents.<name>.fileのエラーで拒否します。

設定変更が反映されるタイミング

• マニフェスト、agents/、skills/、または標準ハーネス設定ディレクトリの編集は、変更リクエストが main にマージされた後にのみ適用されます。セッションとトリガーは、セッションブランチではなくデフォルトブランチを読み込みます。
• トリガーの cron または webhook の変更は、マージから数秒以内にスケジューラーに反映されます。
• サンドボックスのイメージまたはハードウェアを変更すると、スナップショットが再構築されます。新しい仕様は次のセッションから適用され、現在のセッションには適用されません。
• ダッシュボードでシークレット値を変更すると、サンドボックスの作成時に解決されます。次のセッションから適用され、実行中のセッションには適用されません。

ラウンドトリップのルール

ダッシュボードでの編集は、エントリを宣言するファイル（beeuni.yamlまたはインポートされたファイル）に対する読み取り・変更・書き込みです。UI とセッション内での編集の差分をクリーンに保つには、次のようにします。

1. beeuni_versionを最初のキーにします。
2. トリガーエントリ内のフィールドは、slug、name、type、agent、enabledの順に並べ、その後に種類固有のフィールドを置き、最後にpromptを置きます。
3. シークレットを設定する前に webhook トリガーを追加する場合は、シークレット名をenv.optionalに記載します。値を設定するまでは、トリガーをenabled: falseのままにします。

リポジトリへのアクセス

プロジェクトのソースファイルを必要としないエージェントでは、agents.<name>.repository_accessをfalseに設定します。 それでもサンドボックス内のファイルを作成し、付与されたツール、シークレット、コネクターを使用できます。 リポジトリを必要とするエージェントでは、trueに設定します。Git の権限は別途管理されます。 エージェントエディターの Workspace → Project repository access でこの設定を変更します。 この設定は新しいセッションに適用されます。既存のセッションでは、ランタイムの置き換え後も含め、保存済みのポリシーが維持されます。

agents:
  support:
    repository_access: false
  engineer:
    repository_access: true

非推奨のworkspaceフィールドは引き続き読み取り可能です。branchはtrueを意味し、runtimeはfalseを意味します。 従来のread設定では、フィールドを明示的なブール値に置き換えるまで、セッションの作成が引き続き拒否されます。 リポジトリへの読み取り専用アクセスモードはありません。旧フィールドと新フィールドの値が競合する場合は拒否されます。 エディターと SDK はrepository_accessを送信します。アクセスを無効にした場合、API は互換性ミラーとしてworkspace: runtimeも保存します。これにより、ロールアウトまたはロールバック中も、古い API レプリカで制限が維持されます。API の読み取り結果にはミラーは含まれません。repository_accessのみを使用する手書きのマニフェストには、更新済みの API が必要です。