diff --git a/docs/internals/README.md b/docs/internals/README.md
index 93bbccd41..a7b8bd9da 100644
--- a/docs/internals/README.md
+++ b/docs/internals/README.md
@@ -30,7 +30,7 @@ Internal docs are not all live architecture.
 - `specs/` records dated implementation designs; use them for rationale, not as current API truth.
 - `plans/archive/` records completed or abandoned execution plans.
 - `experimental/` records research inputs and methodology experiments.
-- `legacy/` preserves older position papers and boundary notes.
+- `legacy/` preserves older boundary protocols and design notes.
 
 When these documents conflict, prefer current code/tests and the live architecture
 docs. Historical terms such as `loushang-methods`, `methods/**`, Textual, or old
diff --git a/docs/internals/architecture/harness/plugin/README.md b/docs/internals/architecture/harness/plugin/README.md
index b5f8b3ed4..b8128b4b5 100644
--- a/docs/internals/architecture/harness/plugin/README.md
+++ b/docs/internals/architecture/harness/plugin/README.md
@@ -8,8 +8,10 @@
   independently reviewed and owner accepted under issue `#502`; incremental
   contracts record implemented slices; plans remain delivery records; baselines
   are implementation evidence.
-- Implementation status: partial, summarized by `architecture.md` and tracked
-  in the lifecycle plan.
+- Implementation status: PLC0--PLC8 are complete and terminally reviewed;
+  PLC9 is partially implemented through the explicit Linux and Windows AMD64
+  Coding Worker canaries. The remaining platform gaps are summarized by
+  `architecture.md` and tracked in the lifecycle plan.
 - Owner: `loushang.harness` Plugin architecture scope; contribution runtime
   authority remains with each exact domain owner.
 
@@ -45,7 +47,7 @@ Neither may silently override a narrower implemented owner contract.
   the current implementation, including the production `coding.lsp` route.
 - [Plugin Authoring Primitives Delivery Plan](plugin-authoring-primitives-delivery-plan.md)
   refines Definition/Provider/Consumer, Component Host, declaration builder,
-  admission, and future public SDK delivery.
+  admission, and the public SDK path delivered by PLC8.
 - [Resource Catalog And Source Pluginization Plan](resource-catalog-pluginization-plan.md)
   owns the Resource/Skill catalog convergence and the rule that mechanisms may
   be Plugin components while individual Skills remain Resources.
@@ -320,8 +322,9 @@ Neither may silently override a narrower implemented owner contract.
 - [PLC9C Local Worker Boundary](plugin-lifecycle-plc9c0-baseline.md) freezes the
   threat model and implements C1--C4's additive `local_worker` declaration,
   owner-only Process/Sandbox launch capability, bounded protocol/supervisor,
-  durable attempt journal, and default-dark read-only Capability adapter. C5
-  Product/native activation, author-SDK runtime owners, generation publication,
+  durable attempt journal, and default-dark read-only Capability adapter. C5.1
+  through C5.5c now add exact lifecycle/receipt ownership and explicit Linux
+  and Windows AMD64 Coding Product canaries; general author-SDK runtime owners
   and `remote_service` remain absent. The separate
   [HOST-H5 default-dark adapter](../../hosting/harness-worker-adapter-h5.md)
   supplies an atomic Hosting session seam and rollback selector but explicitly
@@ -332,10 +335,10 @@ Neither may silently override a narrower implemented owner contract.
   activation fence. The accepted
   [PLC9C5 C5.0 Product/Native Worker Activation Baseline](plugin-lifecycle-plc9c5-c50-baseline.md)
   and its source-backed
-  [Current inventory](plugin-lifecycle-plc9c5-c50-inventory.md) split C5 into
-  receipt/lifecycle, Linux native, Windows mechanics/rejection, and Linux
-  Product-convergence slices. C5.0 itself is design/guards only: every runtime
-  route remains default-dark and Product activation remains absent.
+  [Current inventory](plugin-lifecycle-plc9c5-c50-inventory.md) records the C5
+  progression from design/guards through receipt/lifecycle, Linux native,
+  Windows mechanics, and the two Product canaries. Product activation remains
+  explicit and default-dark; Current is still the default.
 - [PLC9C5 C5.1 Product Worker Receipt And Lifecycle Contract](plugin-lifecycle-plc9c5-c51-contract.md)
   implements the authority-free policy/receipt join, synchronous serialized
   freshness gate, deterministic publication/retirement lifecycle, durable
@@ -344,20 +347,24 @@ Neither may silently override a narrower implemented owner contract.
 - [PLC9C5 C5.2 Linux Native Profile Binding](plugin-lifecycle-plc9c5-c52-linux-native.md)
   adds the single request-bound POSIX contained-profile friend, exact
   policy/execution closure evidence, non-WSL Linux x86_64 rejection gate, and
-  retained native report. It remains default-dark and has no Product consumer.
+  retained native report. C5.2 had no Product consumer; C5.4 later added the
+  explicit Linux Coding canary while keeping Current as the default.
 - [PLC9C5 C5.3 Windows Mechanics And Product Rejection](plugin-lifecycle-plc9c5-c53-windows-mechanics.md)
   adds one Hosting-private OS-sourced trusted-payload builder, retains the
   restricted-token/Job/handle-list mechanics report, and proves explicit
-  Product required-containment rejection. Windows activation remains closed.
+  Product required-containment rejection at C5.3. C5.5b/c later accepted only
+  the LPAC-contained Windows AMD64 Coding canary.
 - [PLC9C5 C5.4 Linux Coding Product Canary](plugin-lifecycle-plc9c5-c54-linux-product.md)
   composes the one explicit Linux Coding canary over the retained Worker and
   Hosting capabilities, joins stable Session and shared-entrypoint evidence,
-  and closes ordered rollback/recovery and publication evidence. Current stays
-  default and G7 remains open on Windows.
+  and closes ordered rollback/recovery and publication evidence. G7 remained
+  open at C5.4; C5.5c subsequently closed its Windows gate for the exact canary.
 - [PLC9C5 C5.5 Windows Required-Containment Baseline](plugin-lifecycle-plc9c5-c55-windows-containment.md)
   freezes the LPAC threat model, immutable-material-versus-attempt lifetime,
   sole-writer boundaries, native/Product evidence matrices, and the C5.5a--c
-  rollout. C5.5a is design-only; Windows activation remains closed.
+  rollout. C5.5b implements the retained LPAC native containment path and C5.5c
+  implements the exact Windows AMD64 Coding canary; every unlisted Windows or
+  Product route remains closed and Current remains the default.
 - [Plugin Authoring Guide](plugin-authoring-guide.md) documents the minimum
   stable Provider, Skill package, validation, and developer-conformance flows.
 - [PAP4 Capability Admission Contract](plugin-capability-admission-pap4-contract.md)
@@ -386,8 +393,10 @@ Neither may silently override a narrower implemented owner contract.
   internal and does not authorize Product cutover.
 
 These contracts refine the architecture only inside their stated versions and
-implemented slices. An unimplemented Worker, Skill-action, remote-service, or
-public SDK shape cannot be inferred from them.
+implemented slices. The implemented public SDK, managed Skill actions, and
+explicit Worker canaries grant no unstated author/runtime authority; an
+unimplemented general Worker authoring path or `remote_service` shape cannot be
+inferred from them.
 
 ## Baselines
 
diff --git a/docs/internals/architecture/harness/plugin/architecture.md b/docs/internals/architecture/harness/plugin/architecture.md
index 536f5676e..a2e74ee87 100644
--- a/docs/internals/architecture/harness/plugin/architecture.md
+++ b/docs/internals/architecture/harness/plugin/architecture.md
@@ -7,15 +7,19 @@
 - Design status: accepted by the owner under issue `#502` after independent
   architecture, security, and developer-experience reviews passed following
   correction and same-reviewer re-review of their blocking findings.
-- Implementation status: partial. The strict manifest and declaration codecs,
-  immutable revision evidence, desired-state and Instance ledgers, execution
-  Approval consumption, exact Capability-owner admission, Provider selection,
-  Resource component foundations, the `coding.lsp` production path, the single
-  Resource Catalog cutover, the production `coding.base` lifecycle, and the
-  review-candidate `coding.arch` second-Provider path exist. The public SDK,
-  managed Skill actions, isolated Plugin Workers, and complete operations
-  projection remain PLC8 through PLC9 delivery work; PLC7 still requires its
-  terminal review gate.
+- Implementation status: partial. PLC0--PLC8 are complete: the strict manifest
+  and declaration codecs, immutable revision evidence, desired-state and
+  Instance ledgers, execution Approval consumption, exact Capability-owner
+  admission, Provider selection, the production `coding.lsp.default`,
+  `coding.base`, and `coding.arch.default` paths, the single Resource Catalog,
+  the stable public author SDK, and managed Skill actions are implemented and
+  terminally reviewed. PLC9 has also delivered the internal management
+  application/Product-routing contracts and explicit Linux and Windows AMD64
+  Coding `local_worker` canaries. Remaining platform closure includes one
+  complete CLI/RPC/UI/SDK management and repair projection, retained-version
+  GC and destructive-data policy, removal of compatibility enablement vetoes,
+  a general third-party Worker authoring/admission experience, and an
+  implemented `remote_service` topology.
 - Current-runtime authority: source, tests, and narrower accepted boundary and
   contract documents remain authoritative for implemented behavior. Target
   clauses in this document do not make an unimplemented execution shape or API
@@ -347,13 +351,14 @@ execution model, configuration reference, and source evidence. The currently
 implemented kinds are `resource_item`, `tool_pack`, `command_pack`,
 `capability_provider`, and the owner-scoped `continuity_provider`; the
 currently implemented execution models are `data_only`, verified `in_process`,
-and the additive internal `local_worker` declaration topology. `local_worker`
-is default-dark through PLC9C4: its owner-only launch, injected bounded
-protocol/supervisor, and read-only Capability adapter do not constitute Product
-activation or generation publication. `continuity_provider` is not a generic
-component SDK: its owner
-is exactly `harness.continuity`, and it enters the private process Continuity
-generation rather than a Runtime Profile slot or Session Graph.
+and the additive internal `local_worker` declaration topology. PLC9C1--C4
+provided a default-dark owner-only launch, bounded protocol/supervisor, and
+read-only Capability adapter. PLC9C5 C5.4/C5.5c later admitted only explicit
+Linux/Windows AMD64 Coding Product canaries; omitted policy still selects
+Current, and no general Worker authoring or Product route is published.
+`continuity_provider` is not a generic component SDK: its owner is exactly
+`harness.continuity`, and it enters the private process Continuity generation
+rather than a Runtime Profile slot or Session Graph.
 
 New contribution or execution-topology kinds require versioned codecs, explicit
 compatibility diagnostics, owner admission, lifecycle tests, and rollback or
@@ -478,11 +483,12 @@ declaration that binds:
 - required containment and network/filesystem ceilings; and
 - exact Tool/Policy/Approval/audit ownership.
 
-The catalog and Skill parser never execute scripts. Current scripts may be
-invoked through already authorized generic Tools; the target managed
-Skill-script facade is not public until PLC8 proves both native and packaged
-forms. Untrusted scripts require proven containment; a child process alone is
-not a Sandbox.
+The catalog and Skill parser never execute scripts. PLC8 publishes the stable
+native/package managed Skill-action declaration and binds execution to exact
+Resource-owner evidence, Approval, Process Host, and required containment. The
+currently admitted managed execution path is Linux-specific; other scripts may
+still be invoked only through already authorized generic Tools. A child process
+alone is not a Sandbox.
 
 ## Execution Architecture
 
@@ -494,8 +500,8 @@ does not follow a coarse label such as "destructive Plugin".
 | --- | --- | --- | --- | --- |
 | `none` | Resources and static declarations | no code execution | typed parser and exact owner | Implemented as `data_only` |
 | `in_process` | Narrow low-latency first-party/OEM Providers | separately established host-equivalent trust; process containment is impossible | verified Definition evaluator and Component Host | Partially implemented |
-| `one_shot` | Bounded scripts, formatters, generators, command helpers | exact action authorization; required containment for untrusted code | authorized Exec/Tool path | Generic substrate exists; managed Skill facade pending |
-| `local_worker` | Long-lived, stateful, streaming, native, dependency-conflicting, or third-party Providers | every non-host-equivalent executable requires proven non-downgradable containment plus narrow IPC | exact owner host over authorized Process Host | Internal declaration/launch/supervisor/read-only adapter implemented; Product/native activation pending PLC9C5 |
+| `one_shot` | Bounded scripts, formatters, generators, command helpers | exact action authorization; required containment for untrusted code | authorized Exec/Tool path | PLC8 native/package managed Skill facade implemented; managed execution currently admitted on Linux |
+| `local_worker` | Long-lived, stateful, streaming, native, dependency-conflicting, or third-party Providers | every non-host-equivalent executable requires proven non-downgradable containment plus narrow IPC | exact owner host over authorized Process Host | Declaration, lifecycle, supervision, recovery, and explicit Linux/Windows AMD64 Coding canaries implemented through PLC9C5 C5.5c; default remains Current and general third-party authoring/admission is not published |
 | `remote_service` | managed connectors or externally hosted Providers | authenticated narrow protocol, egress policy, tenant isolation, and remote trust evidence | exact domain owner over a Host-owned client binding | Target; protocol-specific |
 
 ### Supervised Worker model
@@ -627,9 +633,9 @@ that satisfies the requirement.
 
 | Level | Author input | Plugin identity? | Execution | Stable target |
 | --- | --- | --- | --- | --- |
-| L0 native Resource | conventional `SKILL.md`, prompt, theme, method, assets | No | declarative; optional managed action later | no SDK required |
+| L0 native Resource | conventional `SKILL.md`, prompt, theme, method, assets | No | declarative; an optional managed action uses a separate strict declaration | no SDK required |
 | L1 data package | `plugin.json` plus declaration documents and Resources | Yes only when independently managed | declarative | schema + validator |
-| L2 Product build facade | small typed Python build specification | optional built-in Plugin or embedded contribution | declarative by default; only in-process code requires separately proven host-equivalent trust | private before PLC8 |
+| L2 Product build facade | small typed Python build specification | optional built-in Plugin or embedded contribution | declarative by default; only in-process code requires separately proven host-equivalent trust | public facade deferred beyond PLC8; private Product composition only |
 | L3 Worker SDK | generated domain protocol interface | usually yes | contained supervised Worker | after Worker contract stabilizes |
 
 ### SDK design rules
@@ -797,17 +803,17 @@ model input.
 
 | Area | Current truth | Target decision | Delivery owner |
 | --- | --- | --- | --- |
-| Manifest | strict JSON/root/digest parser plus a manifest-free compatibility descriptor; fully closed Plugin schema pending | explicit Plugin identity requires canonical closed-schema `plugin.json`; native Resources stay manifest-free without Plugin identity | PLC8 |
-| Declaration | strict v2 IR; `data_only` and verified `in_process` | add execution topologies only through versioned codecs | PLC8/PLC9 |
-| Package materialization | directory verification is no-follow, but PyPI materialization may execute an sdist/PEP 517 build through `uv`/`pip` | verified wheel-only artifacts or a separately contained build service; bounded safe extraction and digest-locked dependency closure precede atomic publication | PLC9 package lifecycle |
+| Manifest | canonical closed-schema `plugin.json` and engine negotiation are stable for explicit Plugin identity; native Resources remain manifest-free and legacy internal descriptors remain migration-only | preserve the closed schema and remove migration-only compatibility inputs when their deletion gates pass | PLC8/PLC9 cleanup |
+| Declaration | strict v2 IR; `data_only`, verified `in_process`, and versioned `local_worker` declarations exist | add any further execution topology only through versioned codecs | PLC8/PLC9 |
+| Package materialization | PLC9B implements the bounded Source/quarantine owner, verified wheel-only extraction, digest-locked recursive closure, transaction pins, role-separated immutable publication, commit admission, crash recovery, and capability-poor Product routing; legacy non-Plugin materializers remain compatibility substrate | activate only through an explicit Product rollout and keep source builds, unsafe Plugin-bound fallback, retained-version GC, and compatibility deletion outside this transaction | PLC9B/PLC9 closure |
 | Management | durable desired state, update, retirement, Instance and cleanup foundations | one CLI/RPC/UI/SDK projection and repair workflow | PLC9 |
 | Enablement compatibility | `manifest.enabled` and `source.enabled` can still veto a Product-selected Plugin during preflight | `manifest.enabled` becomes at most an install-time author default, `source.enabled` becomes Source Authority availability, and `PluginManagementService` desired state is the sole runtime selection writer; remove the peer preflight veto after one-time migration | PLC6/PLC9 |
-| Capability Provider | exact admission/selection/binding foundation and first Coding LSP path | reuse unchanged for additional Providers | PLC6/PLC7 |
-| Resource Catalog | private shadow and composition foundations | one production Catalog and typed Skill projection; delete peer paths | RCP5/PLC6 |
-| Skill scripts | scripts may be referenced and generic authorized Tools can execute | strict native/package managed action facade | PLC8 |
-| Public SDK | internal authoring package exports no public SDK | tiered schema/builder/Worker SDK after production evidence | PLC8 |
-| Built-ins/embedded | Product-specific paths exist | compile to common IR; preserve identity distinction | PLC6/PLC8 |
-| Worker Plugins | Process Host and Sandbox substrates exist | contained supervised Worker declaration and owner protocol | PLC9 |
+| Capability Provider | exact admission/selection/binding plus production LSP and Arch Providers use one Product composition and Graph path | reuse unchanged for additional Providers | PLC6/PLC7 |
+| Resource Catalog | one production Catalog and typed Skill projection own the converged path | preserve the sole owner and remove only explicitly retained compatibility adapters | RCP5/PLC6 |
+| Skill scripts | strict native/package managed action declarations and the exact authorized execution path are public; managed execution is currently Linux-only | retain exact Approval, containment, revision, and Resource-owner binding; add platforms only with equivalent evidence | PLC8 |
+| Public SDK | stable data-only `loushang.plugin` authoring, validation, package, Provider, Resource, and managed Skill-action surface | keep management and future Worker authority out of the author SDK; add only versioned least-authority projections | PLC8/PLC9 |
+| Built-ins/embedded | selectable built-ins compile to common IR; the small embedded-without-Plugin-identity Product build facade remains deferred | preserve the identity distinction when the facade is delivered | PLC6/PLC8 follow-up |
+| Worker Plugins | declaration, supervised lifecycle, recovery, containment, and explicit Linux/Windows AMD64 Coding canaries exist | retain default-Current canary gating; publish a low-cost third-party authoring/admission path only after its own contract | PLC9C/PLC9 closure |
 
 Compatibility adapters may translate old inputs into the canonical contracts,
 but they may not parse manifests again, mutate owner state, bypass admission, or
diff --git a/docs/internals/architecture/harness/plugin/plugin-lifecycle-coding-pluginization-plan.md b/docs/internals/architecture/harness/plugin/plugin-lifecycle-coding-pluginization-plan.md
index a359fb5f1..a3bf3638e 100644
--- a/docs/internals/architecture/harness/plugin/plugin-lifecycle-coding-pluginization-plan.md
+++ b/docs/internals/architecture/harness/plugin/plugin-lifecycle-coding-pluginization-plan.md
@@ -61,14 +61,16 @@
   launch, bounded supervisor, and default-dark read-only Capability adapter.
   The accepted
   [PLC9C5 C5.0 baseline](plugin-lifecycle-plc9c5-c50-baseline.md) and
-  [Current inventory](plugin-lifecycle-plc9c5-c50-inventory.md) plan
-  receipt/lifecycle, Linux native, Windows mechanics/rejection, and final Linux
-  Coding Product-convergence slices while retaining every production
-  activation guard.
+  [Current inventory](plugin-lifecycle-plc9c5-c50-inventory.md) now record the
+  implemented C5.1 receipt/lifecycle, C5.2 Linux native, C5.3 Windows
+  mechanics/rejection, C5.4 Linux Coding Product canary, and C5.5b/c Windows
+  LPAC containment and Coding Product canary. Both canaries are explicit and
+  default-dark; Current remains the default and unlisted routes remain closed.
 - Scope: one delivery order for the common Plugin lifecycle, ordinary
   Definition / Provider / Consumer authoring primitives, `coding.lsp`,
   `coding.base`, `coding.arch`, management control, pre-LSP internal Resource/
-  Skill catalog convergence, and later public SDK stabilization.
+  Skill catalog convergence, the stable public SDK, and remaining PLC9
+  platform closure.
 - Authority: the canonical target
   [Plugin Architecture V2](architecture.md),
   [Capability Composition Lifecycle Authority Plan](../composition-lifecycle-authority-plan.md),
diff --git a/docs/internals/architecture/harness/plugin/plugin-lifecycle-plc7-contract.md b/docs/internals/architecture/harness/plugin/plugin-lifecycle-plc7-contract.md
index f95b8f55b..9181ae61a 100644
--- a/docs/internals/architecture/harness/plugin/plugin-lifecycle-plc7-contract.md
+++ b/docs/internals/architecture/harness/plugin/plugin-lifecycle-plc7-contract.md
@@ -6,8 +6,9 @@
   the accepted Capability dependency/mount lifecycle.
 - Baseline: PLC6 production validation on `main` at `7c542e59` plus the owner-
   accepted Plugin architecture baseline at `a76eb658`.
-- Delivery status: implementation candidate complete under issue `#507`;
-  terminal three-view review is pending.
+- Delivery status: implemented, terminally reviewed from architecture,
+  correctness/security, and Product/test perspectives, and merged under issue
+  `#507` before the PLC8 entry gate opened.
 - Scope: the first-party `coding.arch.default` Provider, its sibling Tool pack,
   private indexed state, and Coding Product composition. This contract does not
   publish the PLC8 author SDK or add a second Graph, Plugin, Tool, or state
diff --git a/docs/internals/architecture/harness/plugin/plugin-lifecycle-plc9-inventory.md b/docs/internals/architecture/harness/plugin/plugin-lifecycle-plc9-inventory.md
index 4dcb5c564..69a34178c 100644
--- a/docs/internals/architecture/harness/plugin/plugin-lifecycle-plc9-inventory.md
+++ b/docs/internals/architecture/harness/plugin/plugin-lifecycle-plc9-inventory.md
@@ -818,17 +818,18 @@ capability in a new scope cannot pass silently.
 | Resource owner generation | `src/loushang/harness/resource_catalog/generation.py::PreparedResourceOwnerGeneration` | Owns prepared Resource/Skill Catalog generation publication/rollback/retirement | Retain; Worker-derived Resource facts still publish through this owner path |
 | Continuity domain host | `src/loushang/harness/continuity/plugin_provider.py::PluginContinuityProvider` | Owns Continuity provider generation calls, mutation preparation, and domain deletion candidates | Retain; a Worker transport cannot become the Continuity owner |
 | Worker runtime identity and launch port | `src/loushang/harness/worker/contracts.py::{WorkerRuntimeBindingV1,WorkerLaunchIdentityV1,ManagedWorkerLaunchRequestV1,WorkerLaunchEvidenceV1}` and `src/loushang/harness/worker/launch.py::ManagedWorkerLaunchPort` | Captures contained regular executable/cwd identity and content digests, revalidates before spawn, exposes no arbitrary command/environment, and returns pathless launch evidence over the existing private managed Process substrate | Retain behind the Process/Sandbox composition root; native IPC/platform activation remains PLC9C5 |
-| Default-dark Hosting Worker seam | `src/loushang/harness/worker/session.py`, `src/loushang/harness/worker/hosting_adapter.py`, `src/loushang/harness/worker/owner_selection.py`, and `src/loushang/harness/worker/supervisor.py::WorkerSupervisor.start_session` | HOST-H5 adds an atomic process-plus-transport session shape, exact Worker-to-Hosting mapping, explicit Current/Hosting selection, pathless diagnostics, no-fallback routing, and future-attempt rollback; no non-Worker production module composes it | Retain as migration evidence only; the existing Sandbox sealed-descriptor preparation is not Hosting-consumable, so this is not PLC9C5 Product/native activation |
+| Hosting Worker seam | `src/loushang/harness/worker/session.py`, `src/loushang/harness/worker/hosting_adapter.py`, `src/loushang/harness/worker/owner_selection.py`, and `src/loushang/harness/worker/supervisor.py::WorkerSupervisor.start_session` | HOST-H5 added an atomic process-plus-transport session shape, exact Worker-to-Hosting mapping, explicit Current/Hosting selection, pathless diagnostics, no-fallback routing, and future-attempt rollback; PLC9C5 C5.4/C5.5c now compose it from the sole explicit Coding Product canary | Retain as the Worker mechanism for the accepted Linux/Windows AMD64 canaries; only their receipt-bound H6 friend profiles make native preparation available, while Current remains the default and unlisted Product routes stay closed |
 | Product-neutral Worker protocol and supervisor | `src/loushang/harness/worker/protocol.py`, `src/loushang/harness/worker/supervisor.py`, and `src/loushang/harness/worker/journal.py` | Exact bounded canonical-JSON frames over an injected byte transport; owns handshake, direction/state validation, correlation/tombstones, heartbeat, shutdown, process-exit fencing, and durable contiguous attempt epoch/restart budget | Retain as mechanism only; it owns no semantic action, contribution publication, rollback, or retirement |
 | Exact read-only Capability Worker adapter | `src/loushang/harness/worker/capability_query.py::{CapabilityQueryWorkerAdapter,bind_capability_query_worker_adapter}` | Binds one Plugin/contribution/Product/scope/owner generation to a sorted Capability allowlist, rechecks authority around every response, returns typed descriptors, and fences invalid/stale output; construction is disabled by policy unless explicitly enabled | Retain as the C4 low-authority canary; it has no publish, retire, mutation, credential, or arbitrary execution capability |
-| Product/native Worker activation | absent through PLC9C4 and PLC9C5 C5.0 | No production Product route connects a child to the injected byte transport, publishes a generation, or claims Linux/Windows native handle/containment conformance; the accepted C5.0 baseline adds only design, exact inventory, and guards | C5.1--C5.4 add receipt/lifecycle, Linux native, Windows mechanics/rejection, then exact Linux Product convergence evidence without weakening default-dark behavior; Windows Product activation remains closed pending a separate accepted required-containment profile; see the [C5.0 baseline](plugin-lifecycle-plc9c5-c50-baseline.md) and [inventory](plugin-lifecycle-plc9c5-c50-inventory.md) |
-| Remote-service topology | absent through PLC9C4 | No service identity, authentication, egress, tenant, residency, or remote revocation contract exists | Defer to a separate threat model; never add it as a `local_worker` compatibility arm |
-
-The internal Plugin `local_worker` declaration and supervised mechanism exist
-through PLC9C4, but no production Product/native activation route exists. There
-is also no accepted `remote_service` declaration/client topology. Process Host
-and Sandbox substrate existence alone still proves neither Worker admission nor
-domain publication.
+| Product/native Worker activation | explicit canaries implemented through PLC9C5 C5.5c | C5.1 owns receipt/lifecycle and durable cleanup evidence; C5.2/C5.4 bind the exact Linux native profile and Coding Product route; C5.3 retains rejected Windows mechanics; C5.5b/c add accepted Windows LPAC containment and the exact Windows AMD64 Coding route | Retain default-Current, explicit-policy, no-same-attempt-fallback behavior; general third-party authoring, other Products/domains/platforms, and `remote_service` remain closed; see the [C5.0 baseline](plugin-lifecycle-plc9c5-c50-baseline.md), [C5.5 contract](plugin-lifecycle-plc9c5-c55-windows-containment.md), and [current inventory](plugin-lifecycle-plc9c5-c50-inventory.md) |
+| Remote-service topology | absent through PLC9C5 C5.5c | No service identity, authentication, egress, tenant, residency, or remote revocation contract exists | Defer to a separate threat model; never add it as a `local_worker` compatibility arm |
+
+The internal Plugin `local_worker` declaration and supervised mechanism exist,
+and PLC9C5 adds only the two explicit Linux/Windows AMD64 Coding canary routes.
+There is still no general third-party Product/native activation path or accepted
+`remote_service` declaration/client topology. Process Host and Sandbox
+substrate existence alone proves neither Worker admission nor domain
+publication outside those exact canaries.
 
 ## Cleanup, Data, And Compatibility Seams
 
diff --git a/docs/internals/legacy/README.md b/docs/internals/legacy/README.md
index fb46e2b3e..895f4ad5c 100644
--- a/docs/internals/legacy/README.md
+++ b/docs/internals/legacy/README.md
@@ -4,8 +4,8 @@
 
 Legacy / historical.
 
-This directory preserves older position papers, boundary protocols, and design
-notes that are still useful for context. They are not current implementation
+This directory preserves older boundary protocols and design notes that are
+still useful for context. They are not current implementation
 contracts.
 
 ## Reading Rule
diff --git a/docs/internals/legacy/position-paper-software-as-system-science.md b/docs/internals/legacy/position-paper-software-as-system-science.md
deleted file mode 100644
index ea532de07..000000000
--- a/docs/internals/legacy/position-paper-software-as-system-science.md
+++ /dev/null
@@ -1,431 +0,0 @@
-# 从工程手艺到系统科学：面向智能时代的软件构造方法论
-
-> **Position Paper** | 面壁智能 (OpenBMB) · Loushang 项目组
-
-## Status
-
-Legacy position paper.
-
-本文保留产品愿景、方法科学和治理模型背景。文中的 `loushang-methods`、
-`methods/` 和旧 `docs/architecture/` 表述是历史术语，不代表当前包名、
-目录布局或实现状态。当前实现边界以 live architecture docs、代码和测试为准。
-
----
-
-## 摘要
-
-软件开发的演进本质上是一部"构造策略与利用方式"的演进史。从手工作坊式的个人编码，到工业化的敏捷流程，再到当今 AI 辅助的生成式开发，每一次范式跃迁都延伸和重构了前一阶段的构造策略，又演进出新的能力利用方式，从而推动软件系统复杂度的持续跃升。
-
-当前，以大语言模型（LLM）为代表的智能技术正在深刻改变软件构造的底层逻辑。然而，现有实践仍高度依赖个体经验、启发式规则与临时性协调，缺乏对软件构造全生命周期的系统化建模与协同治理。这种"工程手艺"模式在简单场景下尚可运转，但在面对复杂系统、长时演进、多角色协作与可审计交付时，已暴露出根本性瓶颈。
-
-本文认为，面向智能时代的软件构造正逐步迈入**"方法-运行-治理"协同演进**的新阶段。在这一范式下，我们探讨了实现**科学化软件构造**所经历的三个关键系统性转向：
-
-**（1）从经验驱动向方法论牵引的科学化转变**：通过将模糊的最佳实践转化为可度量、可运行、可验证的方法资产，为系统化的精细软件构造奠定理论基础；
-
-**（2）从粗放式任务执行向精细化分级治理转变**：通过构建 **P0–P4 分级构造体系**，根据系统不同演进阶段的需求实现构造策略的精准适配，避免了传统开发中"一刀切"的低效；
-
-**（3）从人工单向驱动向"人-机-方法"协同演进转变**：使智能体从被动的工具使用者转向主动的方法执行者，通过双向驱动与动态适配机制最大化方法对系统能力密度的增益贡献，实现方法质量与系统能力的闭环迭代。
-
-此外，我们还分析了新范式下软件构造在**基础设施（Infra）**与**安全可信**方面面临的挑战。我们希望能够通过构建的科学化和系统化的软件构造体系，推动软件开发从"个人手艺"走向"工程规范"，最终迈向"方法科学"，为智能时代复杂系统的可持续演进开辟新的发展路径。
-
----
-
-## 1 引言
-
-### 1.1 软件构造的范式演进
-
-纵观软件开发的发展历程，本质上是一部"构造策略与利用方式"的演进史。每一次范式跃迁既延伸和重构了前一阶段的构造策略，又演进出新的能力利用方式，从而推动软件系统复杂度的跃升与涌现。
-
-根据核心构造策略的不同，我们可以将软件开发的演进分为四个阶段：
-
-**（1）手工作坊时代**：最初的软件构造确立了个人技艺驱动的范式，依赖少数专家的直觉、经验与编码习惯。这种直接的能力应用思路，在当前许多初创团队的快速迭代中仍得以延续。
-
-**（2）工程化时代**：软件工程学科开启了流程与方法论驱动的范式，从瀑布模型演进到敏捷开发，软件质量取决于流程规范、工具链成熟度与团队协作效率的提升。在大模型时代，高质量流程的价值通过 DevOps 与持续交付被重新定义，用于精确引导系统的输出行为。
-
-**（3）平台化时代**：进入云原生与微服务时代，软件构造突破了对单一技术栈的完全依赖，进入以平台能力（Platform Capabilities）为驱动的自服务阶段。通过标准化接口与可复用组件，使系统能够深度压缩和内化领域知识，从而带来了跨团队泛化能力与系统涌现。
-
-**（4）智能体时代**：随着进入 AI 驱动时代，软件系统开始利用大语言模型与智能代理进行辅助构造（AI-Augmented Construction），通过持续的交互和优化，实现对输出行为的主动探索和能力强化。这一阶段不仅提升了系统在复杂场景下的构造与适应能力，也为通用智能软件（General Intelligent Software）的演进奠定了基础。
-
-### 1.2 当前瓶颈
-
-当前软件构造性能提升面临可持续发展的问题：传统经验主导的构造范式难以为继，亟需效率更高的构造方法。尽管当前研究已从代码生成、自动化测试、智能重构等方面探索了提升开发效率的途径，但相关工作多围绕具体问题和任务展开，缺乏贯穿软件构造全生命周期的系统化治理体系。
-
-当前软件构造策略与利用方式仍存在诸多问题：
-
-**（1）科学评估体系缺失**：现有方法仍高度依赖个人经验与启发式规则，缺乏对方法内在价值的科学化评估体系，容易受到认知偏差的影响，导致方法对系统能力提升的贡献难以被量化与解释，从而制约了治理效率与系统性能的可控性。
-
-**（2）构造模式粗放**：方法在构造流程中被视为"同质"资源，缺乏依据其对系统不同阶段与能力需求的差异化贡献进行精细划分与调度的机制，制约了方法对系统能力的最大贡献。
-
-**（3）人-机-方法难以协同优化**：当前的构造流程仍处于"人→工具→代码"的单向驱动模式，智能体对方法的反馈是离散且滞后的，缺乏动态、闭环的"人-机-方法"协同优化机制，难以实现系统能力的持续、自主跃迁。
-
-这些问题已成为提升系统能力密度的核心瓶颈，不再是单点优化或局部工程改进所能解决的，而是亟需对方法的价值评估、阶段化供给与持续利用机制进行系统性重构，构建一套更加科学化、规范化的软件构造理论体系。
-
-### 1.3 核心论点
-
-通过对这些问题的分析和探讨，我们认为软件构造策略和利用方式正逐步迈入**方法-运行-治理协同演进**（Method-Runtime-Governance Co-Evolution）阶段。
-
-首先，需要通过科学的方法价值评测将模糊的质量概念转化为可量化的价值指标；然后，基于方法价值密度实现精细化的治理体系，根据系统不同演进阶段的需求实现方法的精准适配；最终，通过智能体与方法的双向反馈实现闭环演进。
-
-在这一范式下，软件构造正经历三个关键的系统性转向：
-
-**（1）从工程经验主导向方法价值牵引的科学化转变。** 核心在于挖掘方法中蕴含的知识、逻辑与推理链条，通过评估单位方法为系统带来的"能力增益"，将方法质量从模糊的工程概念转化为可度量、可优化的科学指标。
-
-**（2）从粗放式规模扩张向精细化分级治理转变。** 强调"因材施教"的治理策略，即根据系统不同演进阶段的实际需求，对方法进行精细化分层与调度。通过构建 **P0–P4 分级治理体系**（P0 原始经验 → P1 过滤知识 → P2 精筛方法 → **P3 可运行方法元** → P4 编排方法体系），实现方法的精准适配。其中 P3 是整个体系的分水岭——方法从"被动消费的知识"跃迁为"主动驱动的资产"，可被智能体直接加载、执行与验证；P4 则将多个 P3 方法元编排为可治理、可演进的方法论。这一分级避免了传统治理中"一刀切"的低效，实现了更严谨的质量控制。
-
-**（3）从人工单向驱动向"人-机-方法"协同演进转变。** 这一转向使智能体自身成为方法生态的内生环节。智能体不再仅仅是方法的消费者，更能通过自身能力的反馈指导方法的筛选、生成与优化。这种"人机共生"的动态适配机制，实现了方法与系统的双向驱动与持续迭代。
-
----
-
-## 2 软件构造科学
-
-### 2.1 科学方法评估
-
-方法评估的重要性体现在三个方面：
-
-1. **支撑精细化方法治理**：优化高价值方法使用，指导低质量方法改进；
-2. **提升资源利用效率**：明确方法对系统能力的贡献，为构造提供科学指导；
-3. **驱动人机协同闭环**：支持动态构造优化，实现系统能力持续迭代。
-
-随着智能体辅助开发的发展，方法质量对系统性能的影响愈发显著，传统依赖人工经验或简单规则的评估方法已难以满足需求。方法评估正从"经验可用"向"价值度量"演进，通过量化方法的信息含量、可靠性与多样性，构建科学化、系统化的评估体系，实现先验与后验评估的动态闭环。
-
-当前，方法质量评估主要可以分为**先验（prior）**与**后验（posterior）**两类。值得注意的是，先验与后验的划分是**相对于方法执行**而言的：先验评估在方法运行前完成，后验评估在方法运行后基于实际效果反馈完成。这种划分与 P0–P4 分级体系形成正交关系——每一级方法都可以独立进行先验或后验评估。
-
-#### 2.1.1 先验评估方法体系
-
-先验评估是在系统构造开始前，基于方法的统计特征、结构属性或外部知识，对原始方法进行系统分析和价值预测的过程。
-
-**（1）专家主观评估**
-
-早期，方法的质量主要依靠专家的主观评估。然而，这种方法在实际应用中容易产生认知偏差，难以保证评估的一致性。同时，高昂的人力成本也限制了其在大规模系统上的可扩展性。
-
-**（2）基于特征的统计评估**
-
-针对主观评估的局限性，研究者开始采用基于方法特征的统计方法：
-
-- **方法相似度/重复度**：若方法重复度过高，系统在构造中反复接触相似内容，将导致有效学习信号密度下降。常用的评估方法包括代码克隆检测、语义相似性分析等。
-- **方法复杂度**：过高的复杂度往往预示着理解困难、维护成本高。圈复杂度、认知复杂度等指标被广泛用于评估。
-- **方法多样性**：方法多样性是确保系统具备通用泛化能力的关键，包括技术栈分布、设计模式覆盖等多个维度。
-- **方法时效性**：构造方法与当前技术环境之间的时间偏移会显著影响系统性能，尤其在快速演进的技术领域。
-
-**（3）基于模型的评估**
-
-为实现对方法质量的更细粒度评估，研究者借助大模型的语义表征与知识判别能力：
-
-- **困惑度（Perplexity）**：衡量模型对方法序列的预测困难程度，PPL 越高，方法质量越低。
-- **基于 LLM 的质量评分**：利用大型语言模型的零样本或少样本推理能力，通过精心设计的提示对方法在主观质量维度进行量化评分。
-- **LLM 辅助标注**：为海量方法生成结构化元数据，支持细粒度的评估与筛选。
-
-#### 2.1.2 后验评估方法体系
-
-后验评估是指在系统构造完成后，通过观察待评估方法对系统在基准测试上性能的实际影响，来反推其内在价值的评估范式。
-
-**（1）全量构造验证**
-
-全量构造验证是最直接的后验评估方式，能够验证方法/方法配比的真实增益。然而，这种策略的计算开销极为庞大，难以支撑细粒度的方法价值归因或高频迭代的评估需求。
-
-**（2）高效验证（Efficient Verification）**
-
-为降低评估成本，研究者提出了非全量/轻量化验证的替代方案：
-
-- **增量验证**：在已有系统基础上进行局部退火（decay）来快速评估方法质量。
-- **代理模型验证**：使用小规模代理模型快速验证方法效果。
-- **影响函数（Influence Functions）**：分析特定方法样本对模型参数的实际影响量。
-
-#### 2.1.3 方法价值牵引的科学化评估
-
-先验与后验评估方法各有优势，但当前缺乏系统化的理论框架与统一标准。未来的方法评估体系应兼顾效率、可靠性与可解释性，通过"方法价值"衡量方法的内在信息含量，实现先验与后验方法的动态闭环。
-
-未来方法评估的发展可聚焦于以下三个方向：
-
-- **面向方法价值的 Scaling Law 建模**：构建面向方法价值的 Scaling Law，深入推演方法内在价值密度与系统损失函数之间的数学映射。
-- **基于方法价值的评价体系**：依托智能体解析能力构建先验质检智能体，结合后验快速验证机制，建立完整的方法价值评价体系。
-- **方法价值风洞**：借鉴航空航天领域的"风洞实验"思想，通过构建小规模实验环境或轻量化代理模型，模拟大规模构造过程，快速评估方法价值。
-
-### 2.2 精细化方法分级治理
-
-分级方法治理的核心价值体现在以下三个维度：
-
-1. **重构方法治理逻辑**：确立以价值密度为核心的分级标准，驱动方法治理向精细化、可追溯的方向升级；
-2. **方法全生命周期治理**：建立基于 **P0–P4** 的分级体系，实现方法从采集、清洗、筛选与使用各环节的有序衔接与动态优化；
-3. **最大化资源利用率**：结合智能治理机制，通过递进式治理突出高价值方法，实现**方法价值密度**的系统化管理与持续提升。
-
-#### 2.2.1 现有方法分级治理体系
-
-现有的方法治理体系可以从两个维度进行归纳：基于系统演进阶段的治理体系和基于方法处理方式的治理体系。
-
-**（1）基于方法形态的治理体系**
-
-- **经验层治理**：面向 P0 原始经验，核心是采集、去重与初步结构化。
-- **知识层治理**：面向 P1 过滤知识，核心是格式规范化、质量筛选与版本管理。
-- **方法层治理**：面向 P2 精筛方法，核心是主题聚焦、逻辑校验与社区验证。
-- **资产层治理**：面向 P3 可运行方法元，核心是执行验证、输入/输出契约固化与自动化测试。
-- **体系层治理**：面向 P4 编排方法体系，核心是跨方法编排、依赖管理、版本治理与可信校验。
-
-**（2）基于方法处理方式的治理体系**
-
-- **经验解析（Experience Parsing）**：将异构原始经验（博客、笔记、对话记录）转化为机器可理解的结构化资产。
-- **知识过滤（Knowledge Filtering）**：通过低成本的工程化手段剔除噪声，保证知识质量的下限。
-- **方法筛选（Method Selection）**：通过模型分类器或社区投票对方法进行质量或维度筛选，从 P1 晋升到 P2。
-- **资产合成（Asset Synthesis）**：通过模型生成或人工编排，将 P2 方法升级为可直接执行的 P3 方法元（如 SKILL.md）。
-- **体系编排（Methodology Orchestration）**：将多个 P3 方法元编排为完整的 P4 方法体系，定义方法间的依赖、调用顺序与数据传递。
-- **执行验证（Execution Validation）**：对 P3/P4 进行实际运行验证，通过后验反馈驱动方法质量的持续改进。
-
-#### 2.2.2 精细化方法分级治理体系
-
-为了突破现有治理体系的局限，必须建立一套以"价值密度"和"可信度"为核心的精细化分级标准。因此，我们提出 **P0–P4 方法分级体系**：
-
-| 级别 | 名称 | 定义 | 治理手段 | 构造用途 |
-|------|------|------|---------|---------|
-| **P0** | 原始经验（Raw Experience） | 未经任何实质性处理的初始经验，规模庞大，包含大量重复、噪声与无效内容。如散落在各处的博客、个人笔记、会议记录、临时 gist | 采集、解析 | 仅归档，不直接构造 |
-| **P1** | 过滤知识（Filtered Knowledge） | 具有规范格式、可读性较强的知识，但语义质量参差不齐，可能包含过时或局部适用的内容。如团队 wiki、初步整理的规范文档、StackOverflow 回答 | 启发式过滤、去重、算子编排 | 大规模基础构造 |
-| **P2** | 精筛方法（Selected Method） | 具有高方法价值，主题明确与逻辑连贯的方法。如经过评审的设计模式、内部最佳实践集、稳定的 API 设计指南 | 模型打分、方法标签、社区验证 | 核心模块构造 |
-| **P3** | 可运行方法元（Runnable Method Element） | 结构化程度高、可直接驱动执行的方法资产。包含明确的输入/输出、前置/后置条件、执行步骤与验收标准，可被智能体直接消费。如 Loushang 的 **SKILL.md**、可执行的检查清单、自动化工作流模板 | 方法改写、方法合成、人工标注、执行验证 | 关键路径构造 |
-| **P4** | 编排方法体系（Organized Methodology） | 经过统一编排与规范化校验的完整方法体系，形成可检索、可组合、可演进的知识图谱。多个 P3 方法元在 P4 层面被编排为领域特定的方法论，支撑跨阶段、跨角色的协同治理。如完整的软件工程方法论、领域驱动设计体系、可运行的组织级规范 | 方法编排、可信校验、版本治理、依赖管理 | 知识库与规范索引 |
-
-**关键洞察：P3 是分水岭。** P0–P2 是"被动消费"的知识——人阅读、理解、再应用；P3 开始是"主动驱动"的资产——智能体可直接加载、执行、验证。P4 则是"体系化编排"——多个 P3 在更高层次上形成可治理的方法生态。
-
-#### 2.2.3 P3：可运行方法元——从"被动知识"到"主动资产"
-
-P3 是整个分级体系中最关键的**分水岭级别**。在 P3 之前（P0–P2），方法本质上仍是"被动消费"的知识——需要人阅读、理解、内化后再应用。从 P3 开始，方法转变为"主动驱动"的资产——可被智能体直接加载、解析、执行与验证。
-
-**P3 方法元的核心特征**：
-
-| 特征 | 说明 | 示例 |
-|------|------|------|
-| **结构化输入/输出** | 明确定义方法需要什么、产出什么 | `input: ["需求文档", "约束条件"]` / `output: ["架构图", "接口定义"]` |
-| **前置/后置条件** | 定义方法执行的前提与完成标准 | `preconditions: ["价值主张已明确"]` / `postconditions: ["整体结构已定义"]` |
-| **可执行步骤** | 包含具体的执行指令，可被智能体按序执行 | `steps: [{"step": "识别系统边界", "duration": "5-10m"}]` |
-| **角色绑定** | 明确由哪个元角色执行 | `meta-role: DESIGNER` / `role: DESIGNER.architect` |
-| **适用性声明** | 声明方法在什么场景下适用、不适用 | `applicability.when: ["需要设计新系统"]` |
-| **验收标准** | 定义方法执行成功的可验证条件 | `exit-criteria.must-have: ["结构设计已完成"]` |
-
-**P3 方法元的典型形态——SKILL.md**：
-
-```yaml
-# methods/software/task/architect/SKILL.md
-type: task
-meta-role: DESIGNER
-name: 架构设计
-
-input:
-  - "需求文档"
-  - "约束条件"
-output:
-  - "架构图"
-  - "接口定义"
-
-preconditions:
-  - "可行方案已确定"
-  - "关键约束已识别"
-
-steps:
-  - step: "理解需求"
-    description: "分析功能和非功能需求"
-  - step: "识别组件"
-    description: "识别系统核心组件"
-  - step: "定义交互"
-    description: "定义组件间接口和交互"
-  - step: "验证设计"
-    description: "验证架构是否满足需求"
-
-exit-criteria:
-  must-have:
-    - "结构设计已完成"
-    - "关键接口已定义"
-  nice-to-have:
-    - "详细设计文档"
-    - "风险应对策略"
-
-temperature: 0.5
-```
-
-**P3 的价值**：
-
-- **对智能体**：可直接解析执行，无需人工翻译
-- **对团队**：可复用、可版本化、可审计
-- **对组织**：可沉淀为可运行的知识资产，而非静态文档
-
-#### 2.2.4 P4：编排方法体系——从"单点方法"到"系统方法论"
-
-P4 是方法体系的最高级别，它不是单个方法元，而是**多个 P3 方法元在更高层次上的编排与治理**。P4 回答的问题是："如何组织多个方法元，使其协同工作，形成完整的方法论？"
-
-**P4 的核心特征**：
-
-| 特征 | 说明 |
-|------|------|
-| **方法编排** | 定义 P3 方法元之间的调用顺序、依赖关系与数据传递 |
-| **阶段定义** | 将方法元组织为价值流阶段（如 PLAN → EXPLORE → DESIGN → BUILD → VERIFY） |
-| **角色映射** | 定义每个阶段由哪个元角色执行，支持变体切换 |
-| **治理规则** | 定义方法体系的准入标准、升级路径与废弃策略 |
-| **版本管理** | 支持方法体系的版本化演进，保证向后兼容 |
-
-**P4 的典型形态——领域方法论**：
-
-```yaml
-# methods/software/methodology/tdd/SKILL.md
-type: methodology
-name: 测试驱动开发方法论
-
-phases:
-  - phase: PLAN
-    activities:
-      - task: understand-requirements
-        role: PLANNER
-  - phase: DESIGN
-    activities:
-      - task: design-interface
-        role: DESIGNER
-      - task: write-test-first
-        role: DESIGNER
-  - phase: BUILD
-    activities:
-      - task: red-green-refactor
-        role: DELIVER
-  - phase: VERIFY
-    activities:
-      - task: run-tests
-        role: VALIDATOR
-      - task: code-review
-        role: VALIDATOR
-
-orchestration:
-  type: sequential-with-feedback
-  rollback-rules:
-    - when: "测试失败"
-      to: BUILD
-    - when: "设计不可行"
-      to: DESIGN
-```
-
-**P4 与 P3 的关系**：
-
-```
-P4 方法体系（如"TDD 方法论"）
-  ├── 引用 P3: task/understand-requirements
-  ├── 引用 P3: task/design-interface
-  ├── 引用 P3: task/write-test-first
-  ├── 引用 P3: task/red-green-refactor
-  ├── 引用 P3: task/run-tests
-  └── 引用 P3: task/code-review
-
-P4 定义的是"如何编排"，P3 定义的是"具体做什么"。
-```
-
-#### 2.2.5 渐进式构造策略
-
-通过构建 P0–P4 的精细化分级治理体系，方法治理实现了从"粗放式堆量"向"精细化赋能"的范式转型。该体系支撑了**渐进式构造策略**，使系统能够在不同演进阶段精准匹配质量递增的方法资源：
-
-| 系统演进阶段 | 推荐方法级别 | 理由 |
-|-------------|------------|------|
-| **原型验证** | P1 + 少量 P2 | 快速试错，不需要严格编排 |
-| **MVP 开发** | P2 + P3 | 核心模块用 P3 保证质量，周边用 P2 |
-| **生产系统** | P3 + P4 | 关键路径用 P4 方法论，子任务用 P3 |
-| **架构治理** | P4 | 需要完整的体系化方法支撑 |
-| **知识库建设** | P2 → P3 → P4 | 逐步升级，形成可运行资产 |
-
-**升级路径**：
-
-```
-P0 原始经验 →[解析+过滤]→ P1 过滤知识
-  →[筛选+验证]→ P2 精筛方法
-    →[结构化+契约化]→ P3 可运行方法元
-      →[编排+治理]→ P4 编排方法体系
-```
-
-每一级升级都需要经过**先验评估**（是否符合本级标准）和**后验验证**（实际运行效果是否达标），形成完整的质量闭环。
-
-### 2.3 人机方法动态协同演进
-
-人机协同演化的核心价值体现在三个维度：
-
-1. **打破静态治理瓶颈**：突破传统"一次性方法配置"的局限，解决系统构造后期方法边际收益递减的问题；
-2. **构建动态反馈闭环**：利用系统构造过程中的实时反馈，驱动方法的动态选择、加权与生成；
-3. **实现资源精准匹配**：确保方法供给与系统能力发展阶段相适应，最大化方法利用效率与系统能力密度。
-
-#### 2.3.1 协同演化核心机制
-
-人机协同演化通过捕捉系统在构造过程中的动态反馈，实时调整方法供给策略。当前主要通过以下三种机制实现闭环：
-
-**（1）基于模型反馈的方法选择（Model-guided Method Selection）**
-
-系统在构造过程中产生的梯度范数、损失值变化及不确定性评估，是判断方法价值的重要信号。通过分析这些信号，可以精准识别出对当前系统最具信息量或挑战性的方法。
-
-**（2）动态方法采样与再加权（Dynamic Method Sampling and Reweighting）**
-
-为适应系统能力的动态变化，静态的采样配比往往难以维持全阶段的最优性。动态重加权机制主张根据系统在不同子集上的学习收益，实时调整采样频率。
-
-**（3）模型闭环的方法生成与增强（Model-in-the-loop Method Augmentation）**
-
-在协同演化的高级阶段，模型不仅选择方法，更主动参与方法的创造，形成"模型生成—方法训练—系统升级"的正反馈闭环。
-
-#### 2.3.2 "人-机-方法"协同演进
-
-为突破现有局限，未来的方法评估与治理应进一步向"人机孪生"方向演进：
-
-- **系统能力演化的实时监测与诊断**：建立细粒度的构造监控系统，动态追踪系统的学习曲线、遗忘率及在特定基准上的性能边界。
-- **基于能力反馈的策略自适应调整**：实现从"静态策略"到"自适应策略"的转变，确保系统在从"通用学习"向"专家能力"进化的过程中，始终获得最适宜的方法"养分"。
-- **自动化协同优化框架（Automated Co-optimization）**：设计类似工业控制系统的自动化闭环框架，将系统诊断、方法治理与构造调度有机整合。
-
----
-
-## 3 其他挑战
-
-### 3.1 基础设施挑战
-
-在迈向"人机方法协同演进"的过程中，底层基础设施面临着从支撑"结构化分析"向支撑"智能内化"的范式转型。
-
-- **异构方法空间的表征与吞吐挑战**：传统大数据处理框架主要针对结构化表格数据设计，难以高效兼容智能时代 PB 级的代码、文档、测试用例、设计图等高维非结构化方法。
-- **"模型即算子"带来的异构计算调度挑战**：随着治理逻辑的精细化，方法管线已不再是简单的规则过滤，而是深度集成模型推理的复杂流程，要求基础设施具备 CPU 与 GPU 的深度混合调度能力。
-- **工业级治理的可追溯性与可观测性**：面向智能系统的平台必须在工程层面实现全生命周期的可追溯性、可复现性与可观测性，建立"方法指纹"体系。
-
-### 3.2 安全可信挑战
-
-方法不仅是构造智能系统的底层燃料，更是承载知识产权、伦理安全与系统可信的敏感载体。
-
-- **大规模异构方法的合规确权与确源挑战**：在大规模采集与治理过程中，方法源的合法性合规、版权归属以及跨境传输限制构成了首要挑战。
-- **系统知识内化过程中隐私泄露与诱导风险的挑战**：系统在深度压缩和内化世界知识的过程中，极易由于构造方法中的敏感信息泄露而引发安全危机。
-- **"人机方法协同"闭环中的内生安全与治理失控**：当模型作为算子深度参与方法筛选与生成时，治理流程引入了新的动态风险，模型自身的偏见或对齐漏洞可能在方法管线中被非线性放大。
-
----
-
-## 4 总结
-
-本文针对高质量自然方法趋于枯竭和系统能力提升边际效益递减的双重挑战，系统分析了当前软件构造体系中存在的科学评估体系缺失、治理模式粗放以及"人-机-方法"单向驱动逻辑滞后等瓶颈。我们认为，面向通用智能软件的方法科学治理正逐步迈入人机方法协同演进的新阶段。
-
-在这一范式下，本文围绕**科学化方法评估、精细化方法分级治理以及人-机-方法协同演进**三个核心维度分别对现有工作进行了梳理，在此基础上总结我们认为的关键研究方向和解决措施。
-
-**（1）科学化方法评估**：通过构建先验指标与后验验证相结合的动态映射机制，将单位方法带来的"能力增益"转化为可度量、可预测的价值指标，为系统化的精细方法治理与人机方法协同演进奠定理论基础。
-
-**（2）精细化方法分级治理**：依托 P0–P4 精细化方法分级体系（P0 原始经验 → P1 过滤知识 → P2 精筛方法 → P3 可运行方法元 → P4 编排方法体系），强调依据系统不同演进阶段的特异性需求进行精准适配。其中 P3 可运行方法元是整个体系的分水岭——从"被动消费的知识"跃迁为"主动驱动的资产"；P4 编排方法体系则将多个 P3 方法元组织为可治理、可演进的方法论。在深度解耦治理挑战的同时，显著提升了单位方法的构造价值密度与资源利用效率。
-
-**（3）人-机-方法协同演进**：打破了智能体仅作为被动消费者的局限，构建了"监测—反馈—优化"的闭环，使智能体反馈成为驱动方法筛选与生成的内生动力，实现了方法质量与系统能力的协同飞跃。
-
-此外，本文还讨论了在大规模异构基础设施建设以及全生命周期方法安全与隐私保护方面面临的挑战。我们认为，未来通用智能软件的突破性增长将不再单纯依赖于参数规模的简单扩张，而更取决于能否构建一套系统化、规范化且具备自适应能力的方法科学治理理论体系。通过推动方法治理能力的提升，加速软件开发从被动的"知识学习"迈向主动的"知识协同"，为最终实现通用智能软件提供核心驱动力。
-
----
-
-## 附录：Loushang 实践映射
-
-本文的理论框架已在 **Loushang** 项目中得到系统性实践验证：
-
-| 理论概念 | Loushang 实践 |
-|---------|--------------|
-| P0–P4 分级体系 | `loushang-methods` 的方法元分层 |
-| P0 原始经验 | `spikes/` 中的探索性实验记录、`docs/` 中未整理的经验片段 |
-| P1 过滤知识 | `docs/architecture/` 中初步整理的架构决策、设计文档 |
-| P2 精筛方法 | 经过验证的 `component-interfaces/`、稳定的 `glossary` 与 `types` |
-| P3 可运行方法元 | `methods/` 目录下的完整 **SKILL.md**——包含输入/输出、前置/后置条件、执行步骤与验收标准，可被 Agent 直接加载执行 |
-| P4 编排方法体系 | `methods/` 中按领域组织的完整方法论（如 `software/task/tdd/SKILL.md` + `software/phase/DESIGN/SKILL.md` 的编排关系） |
-| 5+1 元角色 | `PLANNER`/`EXPLORER`/`DESIGNER`/`DELIVER`/`VALIDATOR` + `CONDUCTOR` |
-| 先验评估 | 方法元的 `applicability` 声明与适用性检查 |
-| 后验验证 | `VERIFY` 阶段的方法论有效性评估与持续改进闭环 |
-| 人机协同 | `loushang-agent` 的 Agent Loop 与 `loushang-ai` 的模型能力整合 |
-| 状态外置 | `session` 不等于 context window，事件日志与 work product 持久化 |
-| 能力治理 | `capability` 作为一等建模对象，独立于具体执行载体 |
-| 结构性安全 | 权限授予默认最小化，高风险操作支持独立审批 |
-
-Loushang 的架构分层（`ai` → `agent` → `channel` → `tui` → `methods` → `coding`）正是本文所倡导的"系统科学"在工程层面的具体落地——每一层都有明确的职责边界、稳定的接口契约与可验证的交付物。
-
----
-
-*版本: Position Paper v1.0 | 2026-05-31*