Hare/yoi
1
1
Fork 0
Code Actions Packages Releases Activity
35fba2b6fb
yoi/.yoi/tickets/00001KSXRQ4G8/thread.md

7.0 KiB
Raw Blame History

Created

Created by tickets.sh create.

Decision

Initial decision note from user discussion:

  • The plugin surface should mainly expose Hooks and Tools.
  • MCP is related, but should be treated as one protocol-bound backend/bridge rather than the entire plugin model.
  • Planned plugin mechanisms:
    • MCP for protocol-constrained external capability providers;
    • TOML/config-only hooks for simple behavior that does not need arbitrary code;
    • WASM for programmable Hooks/Tools with explicit host capabilities.
  • General scripting languages were considered, but the initial direction is WASM because it offers a clearer sandbox/capability boundary.

Decision

Decision: split feature registry and Hook hardening from Plugin architecture

The Plugin architecture ticket remains the broad architecture surface for Tools, Hooks, runtime kinds, capability model, trust model, discovery/enablement, and MCP/WASM/declarative runtime mapping.

Two implementation-oriented prerequisite tickets are split out:

  • plugin-feature-contribution-registry: define and implement the Pod-layer feature contribution registry so built-in and future external capabilities register through existing Tool / Hook / Notify paths instead of ad hoc Pod code paths.
  • hook-public-surface-hardening: audit and harden pod::hook before exposing it as a feature/plugin contribution boundary, especially removing public access to raw internal action types that can inject model-visible Item values.

This preserves the desired detachable shape: feature state remains in the feature/extension module, while Pod interaction happens through existing durable host surfaces. WorkItem management should be implemented as a built-in feature contribution once the registry boundary is in place, rather than as a special Pod context-injection path.

Decision

決定:

  • pod::feature は API / contribution substrate として扱い、Plugin や MCP の権限管理を担わせない。
  • Plugin は pod::feature をユーザー向け package/config/runtime 形式で使わせる層であり、Plugin permission / trust policy は Plugin layer で定義する。
  • MCP は pod::feature 上に protocol-backed integration layer を構築するが、MCP server enablement / command-env-secret policy / trust boundary / MCP-specific permission は MCP layer が独自に持つ。
  • MCP local stdio server の OS-level side effects は Yoi feature authority では制御できないため、feature-layer authority / grant を MCP や Plugin の permission model に流用しない。

反映:

  • 00001KTR81P9X は authority ではなく provider lifecycle / dynamic contribution / normal ToolRegistry path / untrusted normalization に絞る。
  • 00001KTR82RB7 は MCP 固有の explicit config と trust model を持つ。
  • 00001KSXRQ4G8 と 00001KT0Z4BK8 は Plugin permission を Plugin layer として扱い、MCP を初期 Plugin packaging/runtime から分離する。

Decision

決定:

  • Durable terminology は Plugin runtime / Plugin surface / Plugin host API にする。contribution category は分かりづらいため設計語彙として使わない。
  • Plugin surface は Tool / Hook / Service / Ingress の4つに整理する。
  • Outbound は独立 surface にしない。Slack/Discord 送信など外部副作用は external_write metadata を持つ Tool として扱う。
  • Ingress は Plugin が Notify/Run を直接呼ぶ API ではなく、typed external event を host に submit する API とする。host routing policy が notify/run/drop を決める。
  • Web/FS/Secret/State/Timer/Diagnostics は Plugin surface ではなく Plugin host API。WASM などの runtime が surface を実装するために、Plugin-layer grant で明示的に許可された範囲だけ使える。
  • Chat bridge target は、Yoi が discord.js/Slack SDK process を起動する前提にしない。外部管理の bridge service に WASM Plugin が configured URL + SecretRef で接続する設計を first-class にする。

Decision

決定:

  • Initial Plugin surface は Tool / Hook を主軸にする。
  • Service / Ingress は将来候補として残すが、Submit/Notify/Run や lifecycle semantics を具体化する別 Ticket まで初期 contract には入れない。
  • Outbound は独立 surface にしない。外部副作用は external_write metadata を持つ Tool として扱う。
  • Plugin host API は初期は https と fs に絞る。web という広い API 名は使わず、HTTPS-only の bounded client と scoped FS として設計する。
  • WebSocket/SSE/long polling、timer、state、secret plaintext access、Ingress submit API は必要性が具体化した時点で追加設計する。

Decision

決定:

  • Service / Ingress は Plugin surface として必要なので初期設計対象に戻す。
  • Service は Pod-lifetime の Plugin work として具体化する。ただし Service という語は WebSocket/SSE/raw network support を含意しない。初期の外部通信は https host API の範囲に限定し、streaming API は別途設計する。
  • Ingress は host.ingress.submit(typed external event) として具体化する。Plugin が Notify/Run/context injection を直接選ばず、host routing policy が notify/run/drop/diagnostic を決める。
  • General-purpose host API は引き続き https と fs に絞る。ingress.submit と diagnostics は surface-intrinsic host calls として扱い、広い ambient capability にはしない。

State changed

Ticket を closed にしました。

完了

Closed as superseded by durable Objective and design documentation.

This Ticket was a broad Plugin runtime/surface/host API design record rather than a concrete implementation task. The useful design decisions have been moved into durable roadmap/design context:

  • Objective 00001KVG0HR9M (Plugin platform roadmap) now owns the overall Plugin roadmap and sequencing context.
  • docs/design/plugin-component-model.md records Component Model research and migration direction.
  • docs/design/plugin-packages.md records package/runtime metadata direction.

Concrete implementation work remains tracked by implementation Tickets such as package discovery, Tool registration, WASM runtime, permission grants, CLI inspection, https, fs, and Component Model runtime migration. Future Plugin work should be filed as concrete implementation Tickets, not broad design umbrella Tickets.