Contract-only module

Extensibility

Minimal extension identity and capability-selection types. The current assembly is groundwork for FE-10; it is not a plugin host, invocation protocol, staged-output system, or sandbox.

Implemented surface

ExtensionManifest records an id, version, entry point, and requested capability set. Its factory validates non-blank identity fields and de-duplicates requests.

ExtensionCapability currently contains four coarse labels: ReadProtocol, ReadArtifacts, WriteStagedArtifacts, and RenderExport. CapabilitySelection represents a selected subset for one extension id.

Requested capability is not granted capability. The types do not currently validate that a selection is a subset, bind a project/invocation, scope resource handles, or enforce an operation.

Current data flow

ExtensionManifest.Create(...)
   id + version + entry point
   requested capability set
               |
               v
       CapabilitySelection
       approved subset shape
               |
               X
     no runtime host exists today

Workflow definitions can declare capability requirements, but the Workflow compiler does not resolve an ExtensionManifest, start a process, grant resources, or adopt output. The CLI’s project reference likewise does not imply extension execution.

FE-10 target—planned, not implemented

The roadmap requires a future accepted ADR before broadening these types. Planned FE-10 behavior includes richer manifests, explicit per-project or per-invocation grants, scoped data handles, separate-process third-party execution, constrained resources where supported, staged outputs, schema and digest validation, audit records, and a separate human/domain adoption command.

The planned manifest must eventually address input/output schemas, resource needs, data classification, network destinations, and credential handles. None of those fields or enforcement mechanisms exists in the current code.

Security boundary and failure states

The module-local working agreement assumes third-party extensions are untrusted, denies database credentials, unrestricted filesystem access, and raw secrets, and calls for validation before staged output enters canonical state.

Those are design requirements, not present runtime guarantees. There is currently no behavior for undeclared access, path traversal, symlink escape, process crash/hang, cancellation, resource exhaustion, oversized output, digest mismatch, version drift, or unauthorized adoption.

Dependencies, tests, and safe extension

The project depends only on Kernel. Architecture and package-smoke tests include the assembly, but there is no dedicated accepted FE-10 gate, direct runtime test suite, threat model, abuse-fixture suite, or conformance catalog yet.

Developers should not add an in-process loader or generic “write workspace” capability to this scaffold. FE-10 work must begin with the capability/manifest ADR, then invocation and staged-output contracts, then an outward host, then domain-owned adoption commands and security review.

The exact planned sequence is in the FE-10 roadmap.

Explicit nonclaims

No plugin discovery, installation, loading, execution, process isolation, filesystem/network restriction, credential brokerage, resource quota, staged artifact persistence, output validation, signing, marketplace, sandbox, arbitrary-code safety, scientific adoption, or PHP compatibility is implemented.