Extensibility — knowledge, not a plugin framework
The active plan
Extensibility prioritizes understanding over plugin architecture: the primary mechanism is giving the agent the knowledge to compose existing pieces — concepts, best practices, discovered facts ("AVIF re-encoding halves image size" becomes part of what the box knows) — plus small typed artifacts it can author: box-local schemas (src/schemas/ in the box), box skills, box-authored views. "No plugin framework" means no registry service, marketplace, or lifecycle framework, and no in-process hook API for third-party code.
What does exist (2026-10, plugins): a plugin is a typed library shipped inside the engine package, which a box activates by listing it in _config/box.json and completing through small box-owned stubs: a schema stub that extends the plugin's base type, a view stub that re-exports its view. Nothing new runs at runtime; the stubs are ordinary box schemas and views. That is the "small typed artifacts" half with a named source for the artifacts. The knowledge half, a wiki-style corpus of practice, still does not exist; the plugin README and skill are its stand-in for each plugin.
Status (ruling 18, revised 2026-10-10): the artifacts half exists in the form above; the knowledge half does not. Empirical support for the no-framework side: Activities, a built framework for reusable interaction containers, was removed because the unit of customization that emerged from real use was "a feature flag plus some prose, not a class hierarchy" (Activities retrospective).
Composition over new infrastructure
Build new infrastructure only when basic building blocks don't solve the problem. Want prompted journaling? Compose it (narration behavior + custom prompts), don't build it. Small additions — an AGENTS.md file with custom prompts — beat elaborate new structures. Introduce a new building block only when it unlocks reusable capability across multiple features. The payoff is familiarity and depth: a piece understood deeply works consistently everywhere. This also protects against AI-default homogenization: when the agent builds something unconventional inside the box, it should be a deliberate choice, not ignorance of the convention.
"Modes" — concept half-true, not user-facing vocabulary
The old vision named composable interaction modes (Narration Mode, Factual Mode) plus "chat instructions" as a triage-extension concept. Where that landed (ruling 19):
- Modes don't surface to users as a framework. (2026-10: the UI does use the words "narration mode" for the voice toggle and "Capture mode" for composer capture.) Narration shipped as three features plus a system-prompt overlay; the mode-container framework (Activities) was removed.
- The concept is half-true as a design instinct — mode-shaped ideas keep arriving (e.g. a Listening Mode idea the boxholder likes) and ship as composed features, which is the intended path.
- "Chat instructions" as a named concept appears nowhere in code; its job is done by rules/personality prose and triage category rules.