yoi/.yoi/tickets/20260609-082209-001/item.md

6.4 KiB

title state created_at updated_at assignee
Profile feature flagsでtool surfaceを制御する planning 2026-06-09T08:22:09Z 2026-06-09T08:22:09Z null

背景

最近追加した 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.