Run `<Plan>` with `<TestAgent>` in Markdown tests

[taras]

Story

As an Executable Markdown author, I want a Markdown test to run a document that
uses <Plan> with a deterministic test agent, so I can verify planning
composition without launching a live coding agent or opening an interactive
review form.

Common path

A test runs the document through the production-shaped run child and supplies
the child’s agent behavior and review answer as declarations:

<Test name="a document captures its approved Plan">
 <Execution host="run" target="./uses-plan.md" as="run">
 <TestAgent>
  <TestAgent.Scenario session="planner" src="./agents/approved-plan.md" />
 </TestAgent>

 <Answers>
  <Answer value={{ decision: "Approve" }} />
 </Answers>

 <CollectOutput as="output" />

 <AssertEquals actual={run.result.ok} expected={true} />
 <AssertStringIncludes actual={output} expected="# Approved program" />
 </Execution>
</Test>

The child document uses the ordinary public component and a session the
scenario can address:

<Plan session="planner" as="approved">Write the release program.</Plan>

Approved source: {approved}

Current gap

<Execution host="run"> already accepts <TestAgent> and <Answers> as
trusted child configuration. The child receives the controlled ACP provider,
controlled launcher, and ordinary run-profile Agent components. But its
packaged <Plan> declaration was built before that configuration was known and
closes over no production Agent stack. <PlanAuthorship> therefore refuses at
its Agent context check even though the child has exactly the deterministic provider
Markdown tests use for Agent integrations.

TypeScript can exercise <Plan> through a private harness, but no checked-in
Markdown test can exercise the author-facing component workflow.

Contract

A canonical <TestAgent> declaration on one <Execution host="run"> lets that
child’s trusted host supply the Plan Agent context with the controlled
provider it created. The declaration supplies detached scenario data only; no
provider, scope, Context value, Api handler, or authority crosses from the test
document.

The test Agent context preserves the production Plan boundary:

• the controlled provider is installed inside <PlanAuthorship> for that Plan
  invocation, not inherited from the outer test or installed around the child;
• the Plan system instruction, deny-all permission mode, empty MCP-server set,
  empty native-tool set, prompt-failure policy, and document-capability refusals
  remain the production ones;
• the host owns an empty, test-private authorship root and removes it after the
  child settles, including named Plan session directories;
• <Answers> supplies review decisions through the child’s existing
  non-delegating matcher provider, so no browser or person is reached;
• the child uses the production run profile’s component catalog, includes,
  structural draft check, private Plan phases, output stream, journal selection,
  and teardown ordering; and
• sibling children receive distinct providers, session state, authorship roots,
  and Plan declarations.

Only the canonical child declaration recognized by the testing harness grants
this test path. A repository component named TestAgent, a provider installed
by the test document, middleware, props, or an unconfigured run child cannot
make an Agent context available.

Without <TestAgent>, a child that writes <Plan> keeps the existing refusal
before an authorship directory, provider, Agent turn, or review exists. A direct
xmd test root remains the test profile and does not become a Plan authorship
host.

The production xmd run and xmd plan authorship policies are unchanged. This story
supplies deterministic testing authority, not a new runtime provider-selection
surface.

Acceptance and evidence

#	Criterion	Discriminating evidence
PMT1	Configured Plan	A checked-in Markdown suite runs a child document containing <Plan session="planner" as="approved"> with one matching TestAgent scenario and one authored approval answer; the approved source reaches the child’s ordinary binding and output with no live Agent or browser.
PMT2	Draft inertness	The scripted approved source names an observable file effect; the Markdown test receives the source and proves that file was not created.
PMT3	Missing configuration	The same child without <TestAgent> is refused for want of an Agent context before a worker, directory, Agent turn, review, source, or binding exists; it does not fall through to the run profile’s live provider.
PMT4	Trusted installation	TypeScript host evidence records that the Plan invocation received the controlled provider under the production Plan restrictions and a test-private authorship root; changing any restriction or supplying the provider from document state fails the case.
PMT5	Isolation and teardown	Two configured sibling children use distinct provider/session state and authorship roots, and both roots are absent after success, failure, and cancellation.
PMT6	Canonical declaration only	A repository TestAgent component and an unrecognized declaration supply no Plan Agent context and reach no child Agent work.
PMT7	Profile boundaries	A direct test root still cannot use this authority, while an ordinary production run keeps its existing ACPX Agent context and behavior.

The author-facing successful path and inert-source assertion live in
packages/cli/tests/document-suites/plan/Plan.test.md, launched by the same thin
Markdown-tier runner pattern as the other CLI document suites. Host-only
provider construction, authority, early refusal, isolation, and teardown remain
in packages/cli/tests/testing-execution-host.test.ts because a document cannot
inspect or construct those internals.

Focused feedback evidence:

deno task test \
 packages/cli/tests/document-suites/plan/plan-markdown.test.ts \
 packages/cli/tests/testing-execution-host.test.ts \
 packages/cli/tests/plan-component.test.ts

After the focused cases pass, create the feedback commit and run
deno task test --changed. The complete runtime suites and required checks
remain delivery evidence.

Documentation

Update the testing-host and <Plan> boundaries in architecture.md, the
declared <Plan> and testing-profile sections of
specs/executable-mdx-spec.md, and the deterministic child-Agent and authority
sections of specs/testing-spec.md. Describe the test-only Agent context as present
behavior and keep production and test authority distinct.

Dependencies and delivery order

• Add the <Plan> component #660 and PR Add the <Plan> component to xmd run #685 supply the packaged <Plan> workflow and its production
  authorship ceiling.
• The existing <Execution host="run">, <TestAgent>, and <Answers> child
  configuration contracts supply the trusted deterministic test boundary.
• This story is a blocking prerequisite for Make <Plan> emit or capture approved XMD source #722. Resume Make <Plan> emit or capture approved XMD source #722 only after this
  story is delivered, then move its author-facing Plan behavior into the
  Markdown suite while retaining TypeScript evidence for presentation
  middleware and hostile durable records.
• This story is the first blocking item in Quest Quest: Preserve planned XMD programs for explicit execution #725.

Out of scope

• Changing <Plan> from its current value behavior; Make <Plan> emit or capture approved XMD source #722 owns text emission and
  capture.
• Making output normalization or terminal formatting installable by Markdown;
  those presentation boundaries remain TypeScript evidence.
• Letting an unconfigured test child use a live Agent or browser.
• Giving the direct xmd test root production-run authority.
• Changing retained-root replay, workflow-host testing (Add <WorkflowRun> and <Execution host="workflow"> to Markdown tests #547), or production
  Agent selection and permissions.