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

作成

LocalTicketBackend によって作成されました。

---

Intake summary

既存 Ticket を再読し、duplicate/related work を確認した。これは既存の pod::feature registry、Task built-in feature、Ticket built-in feature、Ticket orchestration tools を前提に、Lua Profile / resolved Manifest から feature 単位で LLM tool surface を登録抑制する concrete implementation work item であり、新規 duplicate Ticket は不要。意図、対象 feature groups、core tools の非対象化、disabled feature は permission deny ではなく schema から消す方針、role default、受け入れ条件、検証が十分明確。blocking open question はなし。主な risk/reviewer focus は profile/manifest, feature-boundary, authority-boundary, tool-schema, prompt-guidance, web-config-fail-closed。feature.ticket.access / feature.memory.access の粒度は、既存 TicketFeatureAccess を再利用・拡張する範囲で実装中判断可能だが、silent broad grant になる場合は escalate する。

---

State changed

Intake が既存 Ticket の要件を確認し、Orchestrator が routing できる状態と判断したため planning から ready に遷移します。実装はまだ開始しません。

---

State changed

Ticket を workspace-panel が queued にしました。

---

Decision

Routing decision: waiting_for_core_tool_surface_stability

This Ticket remains queued for now, despite the updated parallelism preference.

Reason:

• This Ticket changes Profile/Manifest feature flags and conditional tool registration across Task/Ticket/Ticket orchestration/Pod/Memory/Web tool surfaces.
• 20260609-093050-001 is still under review and changes the core Tool execution API.
• Running both together would overlap deeply in ToolRegistry/tool surface registration and test expectations, not just create a small mechanical conflict.

State decision:

• Leave this Ticket queued.
• Re-read after ToolExecutionContext lands and active tool-surface branches settle.

---

State changed

Accepted queued implementation after prior active branches landed and workspace is clean. This Ticket changes Profile/feature/tool-surface gating and no longer overlaps with an active ToolExecutionContext branch. It can proceed in parallel with Ticket schema field cleanup because expected overlap is limited to normal tool registration/test surfaces and should be manageable.

---

Decision

Routing decision: implementation_ready_parallel

Reason:

• The earlier blocker (ToolExecutionContext active core tool API migration) is resolved.
• This Ticket changes Profile feature flags and tool-surface registration; it is mostly independent from the Ticket schema field cleanup now being accepted in parallel.
• User preference is to parallelize when conflict risk is absent or expected small/manageable.

IntentPacket:

Intent:

• Control available tool surfaces through Profile feature flags / configuration so roles can expose only the intended built-in capabilities.

Binding decisions / invariants:

• Tool surface enablement should be explicit and profile/config-driven, not inferred from role names or broad defaults.
• Keep Profile authoring reusable; avoid runtime-bound data such as concrete Pod names/sockets/session state in reusable profile config.
• Do not weaken host authority, scope, network, Ticket backend, or memory boundaries; feature flags may expose tools only when underlying authority/config allows them.
• Avoid adding compatibility aliases for old ad-hoc behavior unless a concrete current requirement exists.
• Preserve clear failure when a requested feature/tool surface lacks required configuration.
• Keep changes bounded to profile/manifest/tool registration/guidance/tests; do not redesign the plugin system.

Reviewer focus:

• Verify features gate tool registration without bypassing authority checks.
• Verify default/project role profiles expose intended surfaces and no unintended tools.
• Verify missing/invalid feature config fails clearly.
• Verify docs/prompts/guidance match the new feature flag model.

Validation:

• Focused profile/manifest/tool registry tests.
• Built-in tool surface/capability tests for affected Task/Ticket/Pod/Memory/Web tools.
• cargo fmt --check, git diff --check, cargo run -q -p yoi -- ticket doctor, cargo check --workspace, nix build .#yoi.

---

Implementation report

Implementation routing started in parallel with the Ticket action/attention field cleanup.

Worktree/branch:

• Worktree: .worktree/profile-feature-flags-tool-surface
• Branch: profile-feature-flags-tool-surface
• Base/routing commit: 41133e0 ticket: route feature flags and attention cleanup

Spawned sibling Coder Pod:

• coder-profile-feature-flags-tool-surface
• Scope: non-recursive read on parent workspace root plus recursive write limited to the child worktree.

Parallel-routing rationale:

• ToolExecutionContext, TicketList, Panel, and session analytics work have landed.
• This Ticket is mostly Profile/feature/tool-surface registration.
• It is expected to have only small/manageable overlap with the Ticket schema field cleanup running in parallel.

---

Implementation report

Implemented Profile feature flags for built-in tool-surface registration.

Summary:

• Added resolved feature config with explicit flags for task, memory, web, pod_management, ticket, and ticket_orchestration plus Ticket access = "read_only" | "lifecycle".
• Changed controller registration so optional built-in surfaces are registered only when enabled by Profile/config; core filesystem/process tools remain static and scope-gated.
• Kept safety boundaries: web tools still fail closed under web config, memory feature requires [memory], pod-management feature requires non-empty delegation scope, Ticket tools still use backend host authority.
• Split Ticket base and orchestration tool declarations so Ticket orchestration can be surfaced independently.
• Migrated project role profiles and builtin default profile to explicit feature settings.

Validation passed:

• cargo test -p manifest feature --lib
• cargo test -p pod feature --tests
• cargo test -p pod pod_management_feature_requires_delegation_scope --test controller_test
• cargo test -p tools --test integration
• cargo fmt --check
• git diff --check
• cargo run -q -p yoi -- ticket doctor
• cargo check --workspace
• nix build .#yoi

---