Typed capability interfaces per controller

[flyingrobots]

Migrated from Method backlog

GitHub Issues are now the live work tracker. Repository docs remain Method evidence.

Field	Value
Source backlog	docs/method/backlog/up-next/PROTO_controller-capability-interfaces.md
Archived source	docs/archive/backlog/github-issue-migration-2026-06-01/docs/method/backlog/up-next/PROTO_controller-capability-interfaces.md
Original lane	up-next
Original id	PROTO_controller-capability-interfaces
Original legend	PROTO
Original feature	api-capabilities

Original backlog card

Typed capability interfaces per controller

Effort: L

Idea

Each kernel controller currently accesses this._host which is the full
WarpRuntime — 20+ fields, every method. This defeats the purpose of
extraction: the controller can still reach anything.

Instead, each controller gets a typed interface with ONLY the fields
and methods it actually needs:

/** @typedef {{
 *   _persistence: CorePersistence,
 *   _graphName: string,
 *   _writerId: string,
 *   _codec: CodecPort,
 *   materialize: () => Promise<WarpState>
 * }} PatchControllerCapabilities */

class PatchController {
  constructor(capabilities) { /* ... */ }
}

This is the "port per controller" idea — Interface Segregation at the
controller level. Benefits:

• Each controller's dependencies are explicit and testable
• No accidental coupling to unrelated host state
• Tests can provide minimal stubs instead of full WarpRuntime mocks

Why not now

The field surface needs to stabilize first. More extractions (WorldlineSource,
strand materialization strategies) may shift which fields each controller
needs. Do this after the dust settles.