Wiki · Backlog
Extract goose — local extensibility, MCP/ACP, and session isolation
Shelf
Backlog
Source
docs/backlog/archive/WI-023-extract-goose.md
Status
done

Proposal (rationale)

The fixed corpus is predominantly Python and treats provider, tool, and composition protocols from inside libraries. It does not center a native local harness whose public contract spans desktop, CLI, API, model providers, agent-client providers, MCP extensions, reusable recipes, and session-isolated execution.

goose is selected to test that surface and add a Rust implementation. The earlier block/goose URL currently redirects to the Agentic AI Foundation organization; the extraction must pin and record the canonical ownership at read time rather than silently using an obsolete URL.

Decision

accepted — 2026-08-15. Accepted as the local extensibility child of WI-018, after WI-019.

Plan

Requirements

  • Pin canonical repository SHA, licence, date, measured scale, and the crates/UI boundary actually read.
  • Trace one local request from CLI or API through provider selection, tool discovery, an MCP extension call, result return, session state, and user-visible control.
  • Distinguish direct model providers from ACP-backed agents and MCP-backed capabilities, including who owns the loop and continuation in each case.
  • Trace permission, confirmation, secret, environment-variable, working-directory, and optional sandbox boundaries.
  • Examine one recipe or repeatable workflow and state what it persists, parameterizes, and isolates by session identity.
  • Map results to skills, neighbour, handoff, session, protocol escape-hatch, and agent-facing-interface candidates.

Impacts

  • One durable/local-product extraction and index row.
  • Implementation evidence that complements the normative MCP study in WI-025; neither item may substitute a product’s behaviour for the protocol contract.

Approach

Read the local CLI path as primary and use the desktop/API only to establish shared versus separate runtime state. Follow one first-party or minimal test MCP extension rather than surveying the extension ecosystem. Treat ACP as a change of loop ownership and make that boundary explicit.

Acceptance criteria / tests

  1. One request and MCP tool result are traced through named Rust symbols and executable tests.
  2. Provider, ACP, and MCP roles are distinguished by ownership, state, and failure propagation.
  3. Permission, secret, filesystem, and sandbox defaults are evidenced rather than inferred from UI labels.
  4. One recipe/session path establishes what prevents or permits cross-run collisions.
  5. Opinion is labelled; protocol and catalogue synthesis remain WI-025/WI-028; gates and site links pass.

Out of scope

  • Auditing third-party MCP extensions or provider implementations.
  • Comparing model quality or extension popularity.
  • Treating optional macOS sandbox behaviour as the cross-platform default.
  • Catalogue, module, or CLI changes.

Execution

Started 2026-08-15 on feature/WI-023-extract-goose. Read-only source snapshot is pinned to goose commit 3810898a7447ec3299be72e223d3570a7aabf0ab while the extraction is written.

Completed 2026-08-15. The extraction records the pinned Apache-2.0 source boundary, measured scale, direct-provider/MCP/ACP ownership, one calculator MCP request/result path, approval, secret/environment/working-directory boundaries, recipe persistence, and session isolation.

Review

Review complete 2026-08-15:

  • Criterion 1 — pass: products/goose.md names StateMachine::run, InferenceRunner, ToolExecutionOperation, ExtensionManager::dispatch_tool_call, McpClient::call_tool, SessionManager::apply_effects, and the calculator plus basic_tool_calling/ reconstruction tests.
  • Criterion 2 — pass: the ownership table distinguishes direct provider, ACP-backed provider, and MCP-backed extension loop/state/failure boundaries.
  • Criterion 3 — pass: permission, confirmation, keyring/file secrets, environment denylist, working-directory propagation, and absent general sandbox are labelled with source evidence.
  • Criterion 4 — pass: recipe persistence, parameterization, structured output, session ids, working directories, copy/reconstruction, and cross-session isolation are evidenced.
  • Criterion 5 — pass: opinions and deferred catalogue candidates are labelled; no module/CLI or catalogue changes were made; repository gates and site links pass.

Verification: node src/cli.ts check (20 pass); git diff --check; site/npm run build (83 pages); site/npm run check (0 Astro diagnostics, 1,059 internal links, 0 broken). The root npm run build/npm run check commands are not defined (known F-002 boundary); site warnings are the existing duplicate-content ids recorded by F-009.