refactor(Planner提示): 移除公共 Prompt 中的 Phase2 流程泄漏

公共 Planner Prompt 仅保留通用合同和 Phase1 协议，Phase2 容器顺序与边界交由 Host 签名策略注入。进一步明确 Direction/Retrieval 层级、Paragraph 的 Structure 引用以及检索和非检索任务预算。

script_build_host/src/script_build_host/agents/prompts/script_planner.md

@@ -26,20 +26,23 @@ in `input_decision_refs` and use `script-build://...` URIs for `scope_ref` and
 candidate-portfolio produce their correspondingly named v1 schema shown by the
 tool. Include all empty arrays and nullable fields required by the schema.
 
-Respect the enforced hierarchy. Root may own only Direction in Phase 1 and the
-single CandidatePortfolio container in Phase 2. Direction may own only
-Retrieval children. CandidatePortfolio may own only Compose candidates;
-Compose may own Structure, Paragraph, ElementSet, Compare, or Retrieval
-increments. Create the parent first, use its returned task ID as
-`parent_task_id`, and make every child `scope_ref` and `write_scope` equal to or
-nested beneath the parent's corresponding `script-build://...` URI.
+Respect the hierarchy and lifecycle supplied by the Host's signed phase policy.
+Create every parent before its children, use the returned Task identity, and
+keep child business and write scopes within the policy-defined boundaries.
 
-In Phase 1, do not dispatch Direction until you have created, dispatched,
-validated, and ACCEPTed one or more Retrieval children. Then Direction can cite
-the exact accepted evidence returned by those children. For initial Direction
-and Retrieval contracts, keep `input_decision_refs` empty and
-`base_artifact_ref` null. Never invent an artifact URI, version, digest, or
-Decision ID: copy immutable references only from bounded tool results.
+In Phase 1, follow this exact hierarchy and order:
+1. create the single Direction child under Root, but do not dispatch it;
+2. using the returned Direction Task ID as `parent_task_id`, create one or more
+   Retrieval children under Direction;
+3. dispatch, validate, and ACCEPT those Retrieval children;
+4. dispatch the existing Direction Task, which will receive those direct-child
+   ACCEPT decisions in its frozen Attempt;
+5. after Direction ACCEPT, BLOCK Root using the exact reason
+   `PHASE_ONE_CAPABILITY_BOUNDARY` with no additional text.
+Retrieval Tasks are never direct children of Root. For initial Direction and
+Retrieval contracts, keep `input_decision_refs` empty and `base_artifact_ref`
+null. Never invent an artifact URI, version, digest, or Decision ID: copy
+immutable references only from bounded tool results.
 
 Decision arguments are action-specific. `accept`, `retry`, `repair`, `block`,
 and `cancel` take no replacement or child contracts. `revise` takes exactly one
@@ -52,11 +55,19 @@ ACCEPTed Task. Copy that whole object unchanged into `input_decision_refs`,
 candidate closures, and comparison references; never reconstruct it from a
 Task ID or an artifact URI.
 
+Every Phase2 Paragraph must include its accepted Structure's whole
+`accepted_decision_ref` unchanged in `input_decision_refs` and must copy that
+reference's whole `artifact_ref` unchanged into `base_artifact_ref`. Supplying
+only the Structure artifact URI, or a base without the Structure Decision, is
+invalid.
+
 Use `max_tokens: 1000000` for every Task contract because real Qwen Worker plus
 Validator attempts can exceed 500k cumulative input and output tokens. A REVISE of a failed or inconclusive
 Attempt does not use `supersedes_decision_ids`; that field names only prior
 ACCEPT decisions and every named ACCEPT must also appear in the new contract's
 immutable input references.
+Use `max_external_queries: 20` for Retrieval contracts so one Validator retry
+remains possible, and `max_external_queries: 1` for non-Retrieval contracts.
 
 After Retrieval children are terminal, dispatch the existing Direction Task
 directly. Do not REVISE Direction to add child Evidence: the Coordinator
@@ -69,38 +80,6 @@ resumable and therefore non-terminal: a BLOCKED child keeps its parent in
 never block a child merely to discard it, and never cancel the Direction parent
 while another child is non-terminal.
 
-In Phase 2, Compose and CandidatePortfolio start as non-executable containers.
-Follow this order exactly:
-
-1. Create the one CandidatePortfolio under Root with empty adoption fields.
-   Its `scope_ref` must equal the accepted Direction's `scope_ref`, so every
-   later candidate remains scope-compatible with that immutable input. Use
-   `write_scope: ["script-build://writes"]` for this internal full-script run.
-2. Create a Compose child under it with empty adoption fields. Do not dispatch
-   either container yet. Its business `scope_ref` must be nested under the
-   Direction/Portfolio scope, while its write scope remains
-   `["script-build://writes"]`.
-3. Create and ACCEPT one Structure child first. Then use its exact accepted ref
-   and base artifact to create scoped Paragraph children; ElementSet and
-   Compare are optional. Every local business scope stays nested below Compose
-   and therefore below Direction. For this internal full-script run, use
-   `["script-build://writes"]` as the write scope for each creative child.
-   Each Paragraph business scope must equal or be nested below the accepted
-   Structure scope, for example `{structure_scope}/paragraph/p1`; a sibling
-   path such as `{compose_scope}/paragraph/p1` is invalid because it cannot
-   import that Structure's accepted Decision.
-4. Once Compose becomes `needs_replan`, REVISE it. Copy every disposed child's
-   whole `accepted_decision_ref` into `candidate_closure_decision_refs`; put
-   exact Decision IDs—not Task IDs, scope URIs, or artifact URIs—into
-   `adopted_decision_ids`, `held_or_rejected_decision_ids`, and `compose_order`.
-   `compose_order` must contain every adopted Decision ID exactly once.
-5. Dispatch, validate, and ACCEPT the now execution-ready Compose.
-6. Once CandidatePortfolio becomes `needs_replan`, REVISE it with the accepted
-   Compose ref as its one-item closure, adopted set, and compose order.
-7. Dispatch, validate, and ACCEPT CandidatePortfolio, then BLOCK Root with the
-   exact `PHASE_TWO_CANDIDATE_PORTFOLIO_READY` boundary.
-
-Never dispatch an adoption container with empty closure, never use a scope URI
-in a Decision-ID field, and never CANCEL the unique CandidatePortfolio. A
-business `scope_ref` controls immutable input compatibility; `write_scope` is a
-separate candidate-workspace namespace and must use `script-build://writes...`.
+Phase-specific container order, adoption closure, Root ownership, and boundary
+names come only from the Host's signed system policy. Never infer or reuse a
+boundary from an earlier phase.