yoi/.yoi/tickets/00001KTNQK1V8/item.md

6.5 KiB

title state created_at updated_at assignee queued_by queued_at
Profile feature flagsでtool surfaceを制御する closed 2026-06-09T08:22:09Z 2026-06-09T12:46:06Z null workspace-panel 2026-06-09T10:31:11Z

背景

最近追加した Ticket tools、Ticket orchestration tools、Pod orchestration tools などにより、Pod に渡される tool schema が増えている。すべての role にすべての tools を渡すと、コンテキストを圧迫し、tool choice の性能低下や role 外行動を誘発する。

現状は core tools、Task tools、Ticket tools、Pod orchestration tools などがかなり広く登録されており、role/profile から feature 単位で tool surface を選ぶ設定がない。

Coder は Ticket 管理や orchestration をしないなら、それらの tools を見るべきではない。SpawnPod などの Pod orchestration tools も、明示的に与えられた role/profile だけが使える optional capability にするべき。

ゴール

Lua Profile / resolved Manifest に feature 単位の tool selection を導入し、role ごとに不要な high-level tools を登録しないようにする。

要件

Profile syntax

  • Lua Profile に feature.<name>.enabled を追加する。
  • object の存在確認ではなく、明示 bool を見る。
    • feature.ticket = {} が true 扱いになるような挙動は避ける。
    • enabled = true / enabled = false を authority とする。
  • まず対応する feature groups:
    • task
    • ticket
    • ticket_orchestration
    • pods
    • memory
    • web
  • resolved Manifest では各 feature の enabled が concrete bool になるようにする。
  • Profile source layer では optional でもよいが、project role profiles は明示的に設定する。

Feature group semantics

  • feature.task:
    • TaskCreate
    • TaskUpdate
    • TaskGet
    • TaskList
  • feature.ticket:
    • Ticket の基本 lifecycle / review / state / close / doctor tools。
    • access level が必要なら access を追加する。
      • 候補: read_only, intake, reviewer, lifecycle
  • feature.ticket_orchestration:
    • Ticket relation / orchestration plan 系 tools。
    • 例: TicketRelationRecord, TicketRelationQuery, TicketOrchestrationPlanRecord, TicketOrchestrationPlanQuery
    • Orchestrator 専用に近い。
  • feature.pods:
    • Pod orchestration / communication tools。
    • 例: SpawnPod, SendToPod, ReadPodOutput, StopPod, ListPods, RestorePod, SendToPeerPod
    • disabled の場合は tool schema に出さない。
  • feature.memory:
    • Memory / Knowledge tools。
    • access level が必要なら後続または同 Ticket 内で read_only / write を検討する。
  • feature.web:
    • WebSearch, WebFetch
    • existing web provider config と連動する。
    • feature.web.enabled=false なら tools を登録しない。
    • provider config が不足している場合は、enabled でも existing fail-closed behavior を維持してよい。

Core tools

  • この feature grouping には core filesystem / shell tools を含めない。
    • Read
    • Write
    • Edit
    • Glob
    • Grep
    • Bash
  • これらは workspace scope / tool permission policy の制御対象として扱う。
  • Bash は将来的に別途 opt-in/tool permission refinement の対象になり得るが、この Ticket の first pass には含めない。

Registration behavior

  • disabled feature の tools は Worker に登録しない。
  • permission deny で失敗させるのではなく、tool schema から消す。
  • feature disabled によって normal prompt guidance も可能な範囲でその tool group を前提にしない。
  • FeatureRegistry / controller の無条件 registration を profile/resolved manifest に基づく conditional registration に変更する。

Role defaults

Project role profiles should set feature defaults explicitly.

  • Orchestrator:
    • ticket = enabled, lifecycle access
    • ticket_orchestration = enabled
    • pods = enabled
    • task = disabled unless explicitly justified
    • memory = enabled preferably read/query oriented
    • web = enabled if configured
  • Intake:
    • ticket = enabled, intake-oriented access
    • ticket_orchestration = disabled
    • pods = disabled
    • task = disabled
    • memory = enabled preferably read/query oriented
    • web = enabled if configured
  • Coder:
    • ticket = disabled by default
    • ticket_orchestration = disabled
    • pods = disabled
    • task = disabled
    • memory = enabled only if desired for read/query context
    • web = enabled if configured
  • Reviewer:
    • ticket = disabled or reviewer/read-only access depending on chosen review-report flow
    • ticket_orchestration = disabled
    • pods = disabled
    • task = disabled
  • Companion:
    • ticket = read_only if useful
    • ticket_orchestration = disabled
    • pods = disabled unless a specific Companion Pod-management UI/tool role is designed
    • task = disabled

Access granularity

  • If ticket.enabled=true is too broad, implement or design feature.ticket.access in the same change.
  • Existing TicketFeatureAccess::ReadOnly / Lifecycle should be reused or extended rather than ignored.
  • ticket_orchestration should be separable from basic Ticket read/show/list tools.

非目標

  • Redesigning core filesystem tools.
  • Removing permission policy.
  • Implementing user approval/ask flow.
  • Making feature object existence imply enabled.
  • Adding a plugin system beyond existing feature registry.
  • Changing the semantics of individual Ticket/Pod tools beyond whether they are registered.

受け入れ条件

  • Lua Profiles can explicitly set feature.<name>.enabled for the six initial feature groups.
  • Resolved Manifest has concrete feature enablement values.
  • Disabled features do not register their tools and therefore do not appear in tool schemas or greetings.
  • Project role profiles set explicit feature defaults.
  • Coder profile does not expose Ticket management, Ticket orchestration, Task, or Pod orchestration tools by default.
  • Orchestrator profile exposes Ticket lifecycle, Ticket orchestration, and Pod orchestration tools as intended.
  • Web tools are omitted when feature.web.enabled=false and still fail closed when enabled but provider config is insufficient.
  • Tests cover tool definition lists for at least Orchestrator, Coder, Intake, Reviewer, and Companion profiles.
  • Focused tests, cargo fmt --check, git diff --check, and target/debug/yoi ticket doctor pass.