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

[taras]

Story

As an Executable Markdown author, I want to reuse the plan command document behind xmd plan 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 plan command document. It does not expose <Plan>, arbitrary custom authorship roots, repository component search, read-only <File> or <Glob> context, --plan, or --plan-eval.

This issue owns that deferred customization surface. It remains separate from xmd plan and is not a prerequisite for #260.

Architecture required before implementation

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

• The plan command document 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.

xmd plan runs the plan command document inside the authorship profile, the constrained trusted-host context defined by #260. Before implementation, settle whether custom authorship 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 Plan source remains inert data throughout authorship.
• The trusted host performs final validation after authorship-profile teardown.
• Only the exact returned bytes may be written to stdout or an output file, or executed.
• The final document executes through the ordinary run profile and owns its own journal.
• Caller-source property failures escape authorship 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 plan command document 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 output or execution.
• Cancellation and authorship-profile teardown complete before final validation, output, or execution.
• The focused xmd plan command remains unchanged when this feature is absent.

Dependencies

• Add xmd prompt: turn a request into an approved executable Plan #260 supplies the plan command document and authorship-profile 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.