🏛️ Compose prompt authorship through a reusable `<Plan>` component

[taras]

Story

As an Executable Markdown author, I want to reuse the standard xmd prompt authorship policy from a Markdown component, so I can add explicit project context without copying the generation, validation, repair, review, and approval flow.

Illustrative shape:

---
props:
  request: { type: string }
returns:
  type: string
---

<Plan request={props.request} as="approved">
Project context written here.
</Plan>

<Return value={approved} />

Product boundary

Issue #260 intentionally ships one exact checked-in first-party Markdown value root. It does not expose <Plan>, arbitrary custom planning roots, repository component search, read-only <File> or <Glob> context, --plan, or --plan-eval.

This issue owns that deferred customization surface. It is not a prerequisite for #260.

Architecture required before implementation

A public <Plan> cannot be treated as ordinary registration or documentation:

• The packaged policy needs an exact, inspectable Markdown identity that cannot be replaced by a repository component while being described as the standard policy.
• Projected wrapper content may perform effects before approval.
• Expression props execute as ambient JavaScript today.
• <File> is form-sensitive, and a paired write expands its children before the Files provider receives the write.
• Existing generated-XMD admission is whole-fragment and form-aware, but it is a workflow evaluator boundary rather than a general root-document admission boundary.

Before implementation, settle whether custom planning documents are trusted authored programs or are admitted through a new whole-root, form-aware constrained-execution boundary. Do not describe component omission, a syntax catalog, provider refusal, or documentation as arbitrary-code confinement. #536 records the larger constrained/untrusted execution boundary.

Invariants to preserve

• <Prompt> remains one Agent turn; authored Markdown owns every loop and branch.
• One enclosing <Session> carries the initial draft, automatic repairs, and human revisions unless the custom policy explicitly chooses another supported contract.
• Candidate source remains inert data throughout planning.
• The trusted host performs final validation after the planning scope and provider teardown.
• Only the exact returned bytes may be saved or executed.
• The final document executes through the ordinary run profile and owns its own journal.
• Caller-source property failures escape planning rather than becoming repair prompts.
• A public wrapper cannot silently widen the authority its host promised.

Decisions this issue owns

• The packaged Markdown component delivery and identity mechanism.
• The authority model for custom roots and projected content.
• Whether read-only <File> and <Glob> context is supported and how their forms are admitted.
• The public component props, projected-content contract, and return schema.
• Whether CLI selectors such as --plan and --plan-eval accompany the component.
• The relationship between the host-owned syntax catalog/system instruction layer and component-authored prompt text.
• Required architecture and specification terminology.

Acceptance direction

• A wrapper adds visible context while reusing the checked-in policy without copying it.
• A replacement custom policy observably changes a review or retry decision.
• The standard policy remains readable Markdown.
• Every authority claim is enforced before its prohibited effect, including expression, component-form, projected-content, and native-Agent boundaries.
• Final validation prevents a custom policy from returning unvalidated source for save or execution.
• Cancellation and teardown complete before final validation, save, or execution.
• The focused Add xmd prompt: generate an executable markdown program from a request, approve it, run it #260 command remains unchanged when this feature is absent.

Dependencies

• Add xmd prompt: generate an executable markdown program from a request, approve it, run it #260 supplies the standard checked-in policy and the two-root host lifecycle.
• 🏛️ Least-authority execution for xmd workflows #536 is the existing architecture umbrella for constrained/untrusted execution if this issue chooses that stronger authority model.