Docs: refresh extension host migration status

This commit is contained in:
Gustavo Madeira Santana 2026-03-15 16:46:57 +00:00
parent a8b3b1c008
commit e36d2136ea
No known key found for this signature in database
6 changed files with 12 additions and 0 deletions

View File

@ -49,6 +49,7 @@ What has been implemented:
- loader per-candidate orchestration now routes through `src/extension-host/loader-flow.ts`
- loader top-level load orchestration now routes through `src/extension-host/loader-orchestrator.ts`
- loader preflight and cache-hit setup now routes through `src/extension-host/loader-preflight.ts`
- loader post-preflight pipeline composition now routes through `src/extension-host/loader-pipeline.ts`
- loader execution setup composition now routes through `src/extension-host/loader-execution.ts`
- loader discovery and manifest bootstrap now routes through `src/extension-host/loader-bootstrap.ts`
- loader mutable activation state now routes through `src/extension-host/loader-session.ts`
@ -72,6 +73,7 @@ How it has been implemented:
- by extracting candidate iteration, manifest lookup, per-candidate session processing, and finalization handoff into a host-owned loader-run helper before catalog publication work
- by converting the compatibility record-state layer into an enforced loader lifecycle state machine before catalog publication work
- by extracting test-default application, config normalization, cache-key construction, cache-hit activation, and command-clear setup into a host-owned loader-preflight helper before catalog publication work
- by extracting post-preflight execution setup and session-run composition into a host-owned loader-pipeline helper before catalog publication work
- by extracting runtime creation, registry creation, bootstrap setup, module-loader creation, and session creation into a host-owned loader-execution helper before catalog publication work
- by moving mutable activation state into a host-owned loader session before catalog publication work
- by extracting shared provenance path matching and install-rule evaluation into `src/extension-host/loader-provenance.ts` so activation and finalization policy seams reuse one host-owned implementation

View File

@ -53,6 +53,7 @@ What has been implemented:
- loader per-candidate orchestration now routes through `src/extension-host/loader-flow.ts`
- loader top-level load orchestration now routes through `src/extension-host/loader-orchestrator.ts`
- loader preflight and cache-hit setup now routes through `src/extension-host/loader-preflight.ts`
- loader post-preflight pipeline composition now routes through `src/extension-host/loader-pipeline.ts`
- loader execution setup composition now routes through `src/extension-host/loader-execution.ts`
- loader discovery and manifest bootstrap now routes through `src/extension-host/loader-bootstrap.ts`
- loader mutable activation state now routes through `src/extension-host/loader-session.ts`
@ -76,6 +77,7 @@ How it has been implemented:
- by extracting candidate iteration, manifest lookup, per-candidate session processing, and finalization handoff into a host-owned loader-run helper before broader schema-driven lifecycle ownership changes
- by turning the compatibility record-state layer into an enforced loader lifecycle state machine before broadening the schema-driven host lifecycle model
- by extracting test-default application, config normalization, cache-key construction, cache-hit activation, and command-clear setup into a host-owned loader-preflight helper before broadening the schema-driven host lifecycle model
- by extracting post-preflight execution setup and session-run composition into a host-owned loader-pipeline helper before broadening the schema-driven host lifecycle model
- by extracting runtime creation, registry creation, bootstrap setup, module-loader creation, and session creation into a host-owned loader-execution helper before broadening the schema-driven host lifecycle model
- by moving mutable activation state into a host-owned loader session before broadening the schema-driven host lifecycle model
- by extracting shared provenance path matching and install-rule evaluation into `src/extension-host/loader-provenance.ts` so activation and finalization policy seams reuse one host-owned implementation

View File

@ -74,6 +74,7 @@ What has been implemented so far:
- loader per-candidate orchestration now routes through `src/extension-host/loader-flow.ts`
- loader top-level load orchestration now routes through `src/extension-host/loader-orchestrator.ts`
- loader preflight and cache-hit setup now routes through `src/extension-host/loader-preflight.ts`
- loader post-preflight pipeline composition now routes through `src/extension-host/loader-pipeline.ts`
- loader execution setup composition now routes through `src/extension-host/loader-execution.ts`
- loader discovery and manifest bootstrap now routes through `src/extension-host/loader-bootstrap.ts`
- loader mutable activation state now routes through `src/extension-host/loader-session.ts`
@ -119,6 +120,7 @@ How it has been done:
- by turning that compatibility `lifecycleState` field into an enforced loader lifecycle state machine with readiness promotion during finalization
- by moving the remaining top-level loader orchestration into a host-owned module so `src/plugins/loader.ts` becomes a compatibility facade instead of the real owner
- by extracting test-default application, config normalization, cache-key construction, cache-hit activation, and command-clear setup into a host-owned loader-preflight helper before shrinking the remaining orchestrator surface
- by extracting post-preflight execution setup and session-run composition into a host-owned loader-pipeline helper before shrinking the remaining orchestrator surface
- by extracting runtime creation, registry creation, bootstrap setup, module-loader creation, and session creation into a host-owned loader-execution helper before shrinking the remaining orchestrator surface
- by moving mutable activation state such as seen-id tracking, memory-slot selection, and finalization inputs into a host-owned loader session instead of leaving them in top-level loader variables
- by extracting shared provenance path matching and install-rule evaluation into `src/extension-host/loader-provenance.ts` so activation and finalization policy seams reuse one host-owned implementation

View File

@ -51,6 +51,7 @@ What has been implemented:
- loader per-candidate orchestration now routes through `src/extension-host/loader-flow.ts`
- loader top-level load orchestration now routes through `src/extension-host/loader-orchestrator.ts`
- loader preflight and cache-hit setup now routes through `src/extension-host/loader-preflight.ts`
- loader post-preflight pipeline composition now routes through `src/extension-host/loader-pipeline.ts`
- loader execution setup composition now routes through `src/extension-host/loader-execution.ts`
- loader discovery and manifest bootstrap now routes through `src/extension-host/loader-bootstrap.ts`
- loader mutable activation state now routes through `src/extension-host/loader-session.ts`
@ -82,6 +83,7 @@ How it has been implemented:
- by composing those seams into one host-owned per-candidate loader orchestrator before moving final lifecycle-state behavior
- by moving the remaining top-level loader orchestration into a host-owned module before enforcing the loader lifecycle state machine
- by extracting test-default application, config normalization, cache-key construction, cache-hit activation, and command-clear setup into a host-owned loader-preflight helper before shrinking the remaining orchestrator surface
- by extracting post-preflight execution setup and session-run composition into a host-owned loader-pipeline helper before shrinking the remaining orchestrator surface
- by extracting runtime creation, registry creation, bootstrap setup, module-loader creation, and session creation into a host-owned loader-execution helper before shrinking the remaining orchestrator surface
- by moving record-state transitions first into a compatibility layer and then into an enforced loader lifecycle state machine
- by moving cache writes, provenance warnings, final memory-slot warnings, and activation into a host-owned loader finalizer before introducing an explicit lifecycle state machine

View File

@ -48,6 +48,7 @@ Relevant prerequisite work that has landed:
- loader per-candidate orchestration now has a host-owned helper boundary
- loader top-level load orchestration now has a host-owned helper boundary
- loader preflight and cache-hit setup now has a host-owned helper boundary
- loader post-preflight pipeline composition now has a host-owned helper boundary
- loader execution setup composition now has a host-owned helper boundary
- loader discovery and manifest bootstrap now has a host-owned helper boundary
- loader discovery policy outcomes now have a host-owned helper boundary

View File

@ -59,6 +59,7 @@ What has landed:
- loader per-candidate orchestration now routes through `src/extension-host/loader-flow.ts`
- loader top-level load orchestration now routes through `src/extension-host/loader-orchestrator.ts`
- loader preflight and cache-hit setup now routes through `src/extension-host/loader-preflight.ts`
- loader post-preflight pipeline composition now routes through `src/extension-host/loader-pipeline.ts`
- loader execution setup composition now routes through `src/extension-host/loader-execution.ts`
- loader discovery and manifest bootstrap now routes through `src/extension-host/loader-bootstrap.ts`
- loader mutable activation state now routes through `src/extension-host/loader-session.ts`
@ -105,6 +106,7 @@ How it was done:
- by turning that compatibility `lifecycleState` field into an enforced loader lifecycle state machine with readiness promotion during finalization
- by moving the remaining top-level loader orchestration into a host-owned module so `src/plugins/loader.ts` becomes a compatibility facade instead of the real owner
- by extracting test-default application, config normalization, cache-key construction, cache-hit activation, and command-clear setup into a host-owned loader-preflight helper before shrinking the remaining orchestrator surface
- by extracting post-preflight execution setup and session-run composition into a host-owned loader-pipeline helper before shrinking the remaining orchestrator surface
- by extracting runtime creation, registry creation, bootstrap setup, module-loader creation, and session creation into a host-owned loader-execution helper before shrinking the remaining orchestrator surface
- by moving mutable activation state such as seen-id tracking, memory-slot selection, and finalization inputs into a host-owned loader session instead of leaving them in top-level loader variables
- by extracting shared provenance path matching and install-rule evaluation into `src/extension-host/loader-provenance.ts` so activation and finalization policy seams reuse one host-owned implementation
@ -136,6 +138,7 @@ Committed implementation slices so far:
- `234a540720` `Plugins: extract loader session runner`
- `a98443c39d` `Plugins: extract loader execution setup`
- `c9323aa016` `Plugins: extract loader preflight`
- `0df51ae6b4` `Plugins: extract loader pipeline`
- `89414ed857` `Docs: track extension host migration internally`
- `d8af1eceaf` `Docs: refresh extension host migration status`