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

---

Implementation report

Reviewer routed after coder implementation commit f0f6cc9.

Reviewer Pod:

• reviewer-profile-feature-flags-tool-surface
• Worktree: .worktree/profile-feature-flags-tool-surface

Review focus includes explicit bool feature authority, concrete resolved Manifest feature values, disabled feature tool omission from schema, role profile surfaces, authority/fail-closed preservation, and the feature.pods vs implementation-reported feature.pod_management naming mismatch.

---

Review: request changes

Review result: request_changes.

Findings:

1. Coder role still enables Task tools by default. Ticket/review focus requires the Coder profile not to expose Ticket management, Ticket orchestration, Task, or Pod orchestration by default. The implementation correctly disables Ticket, Ticket orchestration, and Pod management in .yoi/profiles/coder.lua, but leaves feature.task.enabled = true, and controller registration registers Task tools whenever that flag is enabled. This means the Coder tool schema still exposes TaskCreate/TaskUpdate/etc.

   • .yoi/profiles/coder.lua:8-14
   • crates/pod/src/controller.rs:545-548

2. The user-facing Pod feature flag name does not match the Ticket spec. The Ticket names the initial group feature.pods, but the implementation exposes only feature.pod_management. Since manifest/Profile config currently ignores unknown subfields rather than rejecting or aliasing them, a profile following the Ticket text with feature.pods.enabled = true would not enable Pod-management tools, and would likely fail only indirectly at missing-tool time. Either align the name with the Ticket or update the accepted spec and reject/diagnose the old spelling explicitly.

   • .yoi/tickets/20260609-082209-001/item.md:31-37, .yoi/tickets/20260609-082209-001/item.md:56-59
   • crates/manifest/src/config.rs:77-84
   • crates/manifest/src/lib.rs:95-101

Validation run:

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

Positive checks: disabled optional surfaces are omitted from registry by controller.rs gating rather than merely denied at execution; resolved feature structs use concrete booleans; Ticket base and orchestration registration are separable; web registration is omitted when feature.web.enabled=false and still uses existing provider/config fail-closed checks when enabled; enabling Ticket/Pod management still goes through host-authority/delegation checks.

---

Implementation report

Reviewer requested changes on the initial implementation. Fix applied on branch profile-feature-flags-tool-surface:

• Renamed the user-facing profile feature from feature.pod_management to the Ticket-specified feature.pods.
• Kept internal prompt helper naming unchanged where it describes derived tool capabilities rather than profile syntax.
• Set project Coder profile feature.task.enabled = false so Coder no longer exposes Task tools by default.

Fix commit: 2fd37af fix: align pod feature flag naming

Validation after fix:

• cargo fmt
• cargo test -p manifest feature --lib
• cargo test -p pod feature --tests
• cargo test -p pod pods_feature_requires_delegation_scope --test controller_test
• cargo test -p tools --test integration
• git diff --check
• cargo run -q -p yoi -- ticket doctor
• cargo check --workspace
• cargo fmt --check

---