Docs: refresh extension host migration status

This commit is contained in:
Gustavo Madeira Santana 2026-03-15 16:58:56 +00:00
parent b195ce5275
commit cacd8898b2
No known key found for this signature in database
6 changed files with 13 additions and 1 deletions

View File

@ -61,6 +61,7 @@ What has been implemented:
- loader final cache, readiness promotion, and activation finalization now routes through `src/extension-host/loader-finalize.ts`
- channel, provider, gateway-method, tool, CLI, service, command, context-engine, and hook registration normalization now has a host-owned helper boundary for future catalog migration
- low-risk runtime compatibility writes for channel, provider, gateway-method, HTTP-route, tool, CLI, service, command, context-engine, and hook registrations now route through `src/extension-host/registry-writes.ts` ahead of broader catalog-backed registry ownership
- legacy internal-hook bridging and typed prompt-injection compatibility policy now route through `src/extension-host/hook-compat.ts` ahead of broader catalog-backed registry ownership
How it has been implemented:
@ -84,6 +85,7 @@ How it has been implemented:
- by turning open-allowlist discovery warnings into explicit host-owned discovery-policy results before catalog publication work
- by moving duplicate precedence, config enablement, and early memory-slot gating into explicit host-owned activation-policy outcomes before catalog publication work
- by turning provenance-based untracked-extension warnings and final memory-slot warnings into explicit host-owned finalization-policy results before catalog publication work
- by extracting legacy internal-hook bridging and typed prompt-injection compatibility policy into a host-owned hook-compat helper while leaving actual hook execution ownership unchanged
What remains pending:

View File

@ -40,6 +40,7 @@ What has been implemented:
- config doc baseline generation now reads bundled extension metadata through the resolved-extension registry
- the first runtime registration normalization helpers now exist in `src/extension-host/runtime-registrations.ts` for channel, provider, HTTP-route, gateway-method, tool, CLI, service, command, context-engine, and hook writes
- low-risk runtime compatibility writes for channel, provider, gateway-method, HTTP-route, tool, CLI, service, command, context-engine, and hook registrations now route through `src/extension-host/registry-writes.ts`
- legacy internal-hook bridging and typed prompt-injection compatibility policy now route through `src/extension-host/hook-compat.ts`
- plugin SDK alias resolution now routes through `src/extension-host/loader-compat.ts`
- loader alias-wired module loader creation now routes through `src/extension-host/loader-module-loader.ts`
- loader cache key construction and registry cache control now route through `src/extension-host/loader-cache.ts`
@ -88,6 +89,7 @@ How it has been implemented:
- by turning open-allowlist discovery warnings into explicit host-owned discovery-policy results before broadening the schema-driven host lifecycle model
- by moving duplicate precedence, config enablement, and early memory-slot gating into explicit host-owned activation-policy outcomes before broadening the schema-driven host lifecycle model
- by turning provenance-based untracked-extension warnings and final memory-slot warnings into explicit host-owned finalization-policy results before broadening the schema-driven host lifecycle model
- by extracting legacy internal-hook bridging and typed prompt-injection compatibility policy into a host-owned hook-compat helper while leaving actual hook execution ownership unchanged
What remains pending:

View File

@ -86,6 +86,7 @@ What has been implemented so far:
- loader final cache, readiness promotion, and activation finalization now routes through `src/extension-host/loader-finalize.ts`
- runtime registration normalization has started in `src/extension-host/runtime-registrations.ts` for channel, provider, HTTP-route, gateway-method, tool, CLI, service, command, context-engine, and hook registrations
- low-risk runtime compatibility writes for channel, provider, gateway-method, HTTP-route, tool, CLI, service, command, context-engine, and hook registrations now route through `src/extension-host/registry-writes.ts`
- legacy internal-hook bridging and typed prompt-injection compatibility policy now route through `src/extension-host/hook-compat.ts`
- several static and lookup consumers now read through the host boundary or resolved-extension model:
- channel registry and dock lookups
- message-channel normalization
@ -131,6 +132,7 @@ How it has been done:
- by turning open-allowlist discovery warnings into explicit host-owned discovery-policy results before the orchestrator logs them
- by moving duplicate precedence, config enablement, and early memory-slot gating into explicit host-owned activation-policy outcomes instead of leaving them inline in the loader flow
- by turning provenance-based untracked-extension warnings and final memory-slot warnings into explicit host-owned finalization-policy results before the finalizer applies them
- by extracting legacy internal-hook bridging and typed prompt-injection compatibility policy into a host-owned hook-compat helper while leaving actual hook execution ownership unchanged
- by moving central readers first, so later lifecycle and compatibility work can land on one boundary instead of many ad hoc call sites
- by adding focused tests for each extracted seam before widening the boundary further

View File

@ -39,6 +39,7 @@ What has been implemented:
- static config-baseline generation now reads bundled extension metadata through the host-owned resolved-extension registry
- channel, provider, HTTP-route, gateway-method, tool, CLI, service, command, context-engine, and hook registration normalization now delegates through `src/extension-host/runtime-registrations.ts`
- low-risk runtime compatibility writes for channel, provider, gateway-method, HTTP-route, tool, CLI, service, command, context-engine, and hook registrations now delegate through `src/extension-host/registry-writes.ts`
- legacy internal-hook bridging and typed prompt-injection compatibility policy now delegate through `src/extension-host/hook-compat.ts`
- loader alias-wired module loader creation now routes through `src/extension-host/loader-module-loader.ts`
- loader cache key construction and registry cache control now route through `src/extension-host/loader-cache.ts`
- loader lazy runtime proxy creation now routes through `src/extension-host/loader-runtime-proxy.ts`
@ -98,6 +99,7 @@ How it has been implemented:
- by turning open-allowlist discovery warnings into explicit host-owned discovery-policy results before the orchestrator logs them
- by moving duplicate precedence, config enablement, and early memory-slot gating into explicit host-owned activation-policy outcomes before broader policy semantics move
- by turning provenance-based untracked-extension warnings and final memory-slot warnings into explicit host-owned finalization-policy results before the finalizer applies them
- by extracting legacy internal-hook bridging and typed prompt-injection compatibility policy into a host-owned hook-compat helper while leaving actual hook execution ownership unchanged
What is still pending from this spec:

View File

@ -60,11 +60,12 @@ Relevant prerequisite work that has landed:
- loader finalization policy outcomes now have a host-owned helper boundary
- loader final cache, readiness promotion, and activation finalization now has a host-owned helper boundary
- low-risk channel, provider, gateway-method, HTTP-route, tool, CLI, service, command, context-engine, and hook compatibility writes now have a host-owned helper boundary in `src/extension-host/registry-writes.ts`
- legacy internal-hook bridging and typed prompt-injection compatibility policy now have a host-owned helper boundary in `src/extension-host/hook-compat.ts`
Why this matters for this spec:
- event work should land on top of a host-owned boundary and normalized contribution model rather than on top of more plugin-era runtime seams
- the current implementation has deliberately not started bridge or stage work before those earlier boundaries were in place, including the first loader-runtime, record-state, discovery-policy, activation-policy, finalization-policy, and low-risk registry-write seams
- the current implementation has deliberately not started canonical bridge or stage work before those earlier boundaries were in place, including the first loader-runtime, record-state, discovery-policy, activation-policy, finalization-policy, low-risk registry-write, and hook-compat seams
## Design Goals

View File

@ -71,6 +71,7 @@ What has landed:
- loader final cache, readiness promotion, and activation finalization now routes through `src/extension-host/loader-finalize.ts`
- runtime registration normalization has started in `src/extension-host/runtime-registrations.ts` for channel, provider, HTTP-route, gateway-method, tool, CLI, service, command, context-engine, and hook registrations
- low-risk runtime compatibility writes for channel, provider, gateway-method, HTTP-route, tool, CLI, service, command, context-engine, and hook registrations now route through `src/extension-host/registry-writes.ts`
- legacy internal-hook bridging and typed prompt-injection compatibility policy now route through `src/extension-host/hook-compat.ts`
- several existing consumers now read host-owned normalized data instead of plugin-era manifest or runtime state directly:
- channel and dock lookup surfaces
- message-channel normalization
@ -117,6 +118,7 @@ How it was done:
- by turning open-allowlist discovery warnings into explicit host-owned discovery-policy results before the orchestrator logs them
- by moving duplicate precedence, config enablement, and early memory-slot gating into explicit host-owned activation-policy outcomes instead of leaving them inline in the loader flow
- by turning provenance-based untracked-extension warnings and final memory-slot warnings into explicit host-owned finalization-policy results before the finalizer applies them
- by extracting legacy internal-hook bridging and typed prompt-injection compatibility policy into a host-owned hook-compat helper while leaving actual hook execution ownership unchanged
- by moving static and lookup-heavy consumers first, where the ownership boundary matters but runtime risk is lower
Committed implementation slices so far:
@ -147,6 +149,7 @@ Committed implementation slices so far:
- `07c3ae9c87` `Plugins: extract low-risk registry writes`
- `bc71592270` `Plugins: extend registry write helpers`
- `27fc645484` `Plugins: extend registry writes for hooks`
- `b407d7f476` `Plugins: extract hook compatibility`
- `89414ed857` `Docs: track extension host migration internally`
- `d8af1eceaf` `Docs: refresh extension host migration status`