Docs: refresh extension host migration status

docs/.internal/extension-host-migration/openclaw-capability-catalog-and-arbitration-spec.md

@@ -48,6 +48,7 @@ What has been implemented:
 - loader post-import planning and `register(...)` execution now route through `src/extension-host/loader-register.ts`
 - 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 host process state now routes through `src/extension-host/loader-host-state.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`
@@ -72,6 +73,7 @@ How it has been implemented:
 - by extracting discovery, manifest loading, manifest diagnostics, discovery-policy logging, provenance building, and candidate ordering into a host-owned loader-bootstrap helper before catalog publication work
 - 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 shared discovery warning-cache state and loader reset behavior into a host-owned loader-host-state helper 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

docs/.internal/extension-host-migration/openclaw-extension-contribution-schema-spec.md

@@ -52,6 +52,7 @@ What has been implemented:
 - loader post-import planning and `register(...)` execution now route through `src/extension-host/loader-register.ts`
 - 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 host process state now routes through `src/extension-host/loader-host-state.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`
@@ -76,6 +77,7 @@ How it has been implemented:
 - by extracting discovery, manifest loading, manifest diagnostics, discovery-policy logging, provenance building, and candidate ordering into a host-owned loader-bootstrap helper before broader schema-driven lifecycle ownership changes
 - 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 shared discovery warning-cache state and loader reset behavior into a host-owned loader-host-state helper 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

docs/.internal/extension-host-migration/openclaw-extension-host-implementation-guide.md

@@ -73,6 +73,7 @@ What has been implemented so far:
 - loader post-import planning and `register(...)` execution now route through `src/extension-host/loader-register.ts`
 - 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 host process state now routes through `src/extension-host/loader-host-state.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`
@@ -119,6 +120,7 @@ How it has been done:
 - by adding explicit compatibility `lifecycleState` mapping on loader-owned plugin records before enforcing the loader lifecycle state machine
 - 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 shared discovery warning-cache state and loader reset behavior into a host-owned loader-host-state helper before shrinking the remaining orchestrator surface
 - 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

docs/.internal/extension-host-migration/openclaw-extension-host-lifecycle-and-security-spec.md

@@ -50,6 +50,7 @@ What has been implemented:
 - loader post-import planning and `register(...)` execution now route through `src/extension-host/loader-register.ts`
 - 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 host process state now routes through `src/extension-host/loader-host-state.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`
@@ -82,6 +83,7 @@ How it has been implemented:
 - by moving post-import planning and `register(...)` execution next while leaving entry-path and import flow unchanged
 - 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 shared discovery warning-cache state and loader reset behavior into a host-owned loader-host-state helper before shrinking the remaining orchestrator surface
 - 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

docs/.internal/extension-host-migration/openclaw-kernel-event-pipeline-spec.md

@@ -47,6 +47,7 @@ Relevant prerequisite work that has landed:
 - loader post-import planning and `register(...)` execution now have a host-owned helper boundary
 - loader per-candidate orchestration now has a host-owned helper boundary
 - loader top-level load orchestration now has a host-owned helper boundary
+- loader host process state 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

docs/.internal/extension-host-migration/openclaw-kernel-extension-host-transition-plan.md

@@ -58,6 +58,7 @@ What has landed:
 - loader post-import planning and `register(...)` execution now route through `src/extension-host/loader-register.ts`
 - 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 host process state now routes through `src/extension-host/loader-host-state.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`
@@ -105,6 +106,7 @@ How it was done:
 - by adding explicit compatibility `lifecycleState` mapping on loader-owned plugin records before enforcing the loader lifecycle state machine
 - 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 shared discovery warning-cache state and loader reset behavior into a host-owned loader-host-state helper before shrinking the remaining orchestrator surface
 - 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
@@ -139,6 +141,7 @@ Committed implementation slices so far:
 - `a98443c39d` `Plugins: extract loader execution setup`
 - `c9323aa016` `Plugins: extract loader preflight`
 - `0df51ae6b4` `Plugins: extract loader pipeline`
+- `e557b39cb2` `Plugins: extract loader host state`
 - `89414ed857` `Docs: track extension host migration internally`
 - `d8af1eceaf` `Docs: refresh extension host migration status`