refactor(ui): replace Cron response rendering and remove FunctionalUI

[calebeden]

Blocked by: #1110

Related: #1055, #1115

Problem

FunctionalUI has been removed from the production chat surface, but the library remains because one production path still depends on it.

The remaining production dependency chain is:

CronPage → FunctionalHostControl → ChatMarkdownRenderer → FunctionalUI

This path renders successful Cron run-history responses inside the “Full response” expander. Production chat uses a separate Reactor Markdown implementation.

Keeping the Cron path also retains:

• The FunctionalUI library and project reference.
• FunctionalUI-specific tests.
• FunctionalUI-specific CI and solution entries.
• ChatMarkdownRenderer.
• A separate Markdown AST and vendored parser that appear to exist only for that renderer.
• Theme-resolution compatibility code.
• Stale documentation and comments describing broader FunctionalUI usage.

Expected behavior

Cron full responses are rendered by a maintained Reactor or raw WinUI owner, with equivalent Markdown, security, accessibility, lifecycle, and theme behavior, and no production dependency on FunctionalUI.

Actual behavior

Successful Cron full responses still create a FunctionalHostControl and mount ChatMarkdownRenderer, retaining the FunctionalUI library, tests, CI lane, parser infrastructure, and compatibility resources.

Goal

Replace the remaining Cron FunctionalUI path using either Reactor or raw WinUI, add comprehensive tests designed for the selected implementation, and remove FunctionalUI completely.

The implementation approach is intentionally open. The chosen solution must have clear ownership, preserve current behavior, avoid introducing another UI abstraction layer, and eliminate all direct and transitive FunctionalUI dependencies.

After this work:

• No production code uses FunctionalUI, directly or indirectly.
• No unreachable or migration-only FunctionalUI production code remains.
• No tests exist solely to validate FunctionalUI behavior.
• Existing source-text contracts for the old Cron renderer are replaced with behavioral coverage where the behavior remains relevant.
• The replacement Cron implementation has new behavioral, integration, lifecycle, accessibility, security, and UI coverage.
• The FunctionalUI library and its dedicated test project are deleted.

Non-goals

• Mandating Reactor if maintainers and implementers determine that raw WinUI is a better fit. The rendering approach is left to their discretion, provided it satisfies the behavior, testing, lifecycle, and dependency-removal requirements below.
• Redesigning the Cron history list.
• Changing how Cron errors are presented.
• Changing production chat Markdown behavior.
• Introducing another custom UI framework or compatibility layer.
• Adding tests that merely assert deleted files or symbols are absent.
• Mechanically renaming or porting FunctionalUI implementation tests.

Current production behavior to preserve

Within the Cron run-history list:

• A history row may expose a “Full response” expander.
• Successful responses render sanitized Markdown.
• Error responses render as selectable plain text.
• Expanded row state is tracked across history refreshes.
• Full responses support text selection and wrapping.
• Markdown links, images, and raw HTML are rendered inertly.
• Rendering works under light, dark, and high-contrast themes.
• The expander is keyboard accessible.
• Expanded content remains available to UI Automation and screen readers.
• Focus remains predictable when the expander is opened, closed, or rebuilt.

Maintainer decision required

Before implementation begins, maintainers and the implementer should agree whether the replacement uses Reactor or focused raw WinUI. The decision should identify the rendering owner, lifecycle boundary, Markdown parser, and test location.

Implementation plan

1. Inventory the remaining dependency graph

• Confirm every production, test, project, solution, CI, documentation, and resource reference to FunctionalUI.
• Confirm that Cron full-response rendering is still the only production consumer.
• Identify unreachable or migration-only hosts, renderers, adapters, resources, comments, and helpers coupled to FunctionalUI.
• Identify existing source-text contract tests that describe the old FunctionalUI or Cron rendering implementation.
• Confirm whether the shared Markdown AST and vendored md4c parser have any consumer other than ChatMarkdownRenderer.
• Record the inventory and removal decisions in the PR description.

2. Design the replacement implementation

Use either Reactor or raw WinUI. Document why the selected approach fits the Cron history surface.

The replacement must:

• Avoid introducing another custom UI framework or compatibility layer.
• Have a focused owner for rendering successful Cron responses.
• Define explicit ownership for controls, hosts, subscriptions, handlers, and disposable state.
• Preserve keyboard, focus, and UI Automation behavior.
• Support:
  • Paragraphs and headings.
  • Ordered and unordered lists.
  • Nested lists.
  • Tables.
  • Blockquotes.
  • Inline and fenced code.
• Preserve selectable text and wrapping for long output.
• Resolve theme resources correctly under light, dark, and high-contrast themes.

If Reactor is selected:

• Reuse or extract safe Markdown behavior instead of duplicating ReactorChatTimeline.BuildSafeMarkdown.
• Define ownership and disposal for Reactor hosts created inside Cron history rows.

If raw WinUI is selected:

• Keep Markdown parsing and control creation in a focused renderer rather than growing CronPage.xaml.cs.
• Avoid creating a general-purpose replacement for FunctionalUI.
• Define ownership for generated controls, event handlers, subscriptions, and other state.

3. Preserve the shared Markdown security policy

The rendering architecture is open to implementer discretion, but the security behavior is not.

• Continue routing Cron response content through ChatMarkdownSanitizer, or extract the existing policy into a shared owner used by both Cron and chat.
• Do not introduce a separately implemented security policy without explicit maintainer approval.
• Keep links and image destinations inert.
• Prevent remote image fetching.
• Render raw HTML as inert text.
• Reject or neutralize unsafe URI schemes.
• Add a fixed malicious-input fixture corpus covering:
  • Inline links.
  • Autolinks and bare URLs.
  • Remote images.
  • Data and file URI images.
  • Raw HTML blocks.
  • Embedded HTML links and images.
  • Malformed Markdown intended to escape sanitization.
• Assert that the Cron and chat security paths produce equivalent inert behavior for the shared fixture corpus.

4. Migrate Cron history rendering

• Replace FunctionalHostControl in CronPage.BuildFullResponseExpander.
• Render successful responses through the replacement implementation.
• Preserve the existing selectable plain-text error path.
• Preserve expanded-row state when history is rebuilt or refreshed.
• Ensure replaced or discarded rows release hosts, controls, handlers, subscriptions, and other owned resources.
• Ensure repeated refreshes do not duplicate controls, handlers, subscriptions, or rendered content.
• Preserve keyboard expand and collapse behavior.
• Preserve logical focus when rows are expanded, collapsed, refreshed, or removed.

5. Add tests for the replacement implementation

Do not mechanically port the existing FunctionalUI tests. Delete tests that exist to validate FunctionalUI behavior, then design new coverage around the responsibilities and failure modes of the selected implementation.

Renderer behavior

• Commit a representative Markdown fixture corpus.
• Define expected rendered invariants for each fixture, including content structure, inertness, wrapping, and selectability.
• Cover:
  • Paragraphs and headings.
  • Ordered and unordered lists.
  • Nested lists.
  • Tables.
  • Blockquotes.
  • Inline and fenced code.
  • Empty content.
  • Malformed content.
  • Unusually large content.
• Verify links, images, unsafe URI schemes, and raw HTML cannot trigger navigation or network fetching.

Cron integration

• Successful history responses render through the new owner.
• Error responses remain selectable plain text.
• Expanding and collapsing a response preserves the correct row state.
• History refreshes retain the correct expanded rows.
• Removed rows release their owned resources.
• Repeated rebuilds do not duplicate rendered content or event handling.

Lifecycle verification

Add deterministic lifecycle tests rather than relying only on garbage collection timing.

• Exercise at least 10 create, replace, refresh, and remove cycles.
• Assert that every owned host or disposable owner is disposed exactly once.
• Assert that every owned event subscription is removed.
• Assert that registered host, handler, or subscription counts return to their baseline after teardown.
• Assert that steady-state object or handler counts do not grow across repeated refreshes.
• Use weak-reference collection checks only as supplemental evidence, not as the sole lifecycle test.

Accessibility verification

• The expander can be reached and operated using only the keyboard.
• Expanded content is exposed through UI Automation with useful text or accessible naming.
• Focus remains on a predictable element after expand, collapse, refresh, and removal.
• Selectable response text remains usable without a pointer.
• The changed Cron surface passes the repository accessibility audit.

Test ownership

• Tests exercise the replacement renderer and Cron integration directly.
• Existing source-text tests tied to FunctionalUI or the old Cron rendering implementation are deleted or replaced with behavioral tests.
• No new tests merely inspect source text or assert that FunctionalUI files and symbols are absent.
• New tests live in an existing mandatory CI test project, or the mandatory CI workflow is updated to execute their project.
• The PR validation section reports the exact commands and non-zero test counts for the new tests.

6. Remove FunctionalUI production code

• Delete src/OpenClawTray.FunctionalUI.
• Remove its project reference from OpenClaw.Tray.WinUI.csproj.
• Remove its entry from openclaw-windows-node.slnx.
• Delete ChatMarkdownRenderer.
• Remove remaining FunctionalUI hosts, adapters, factories, comments, imports, and resource workarounds.
• Remove unreachable or migration-only production code that depended on FunctionalUI.
• Confirm that no production assembly retains a direct or transitive dependency on the FunctionalUI assembly.

7. Remove exclusively retained Markdown infrastructure

The dependency inventory from section 1 determines whether this infrastructure is removed.

If no active production consumer remains:

• Delete ChatMarkdownAst.cs.
• Delete ChatMarkdownAstBuilder.cs.
• Delete the vendored OpenClaw.Shared/Markdown/Md4c parser.
• Delete tests specific to that AST/parser and its old renderer cache contract.
• Update Markdown documentation to describe the active production implementation.

If retention is proposed, the PR description must:

• Name each active production consumer.
• Explain why the infrastructure is still necessary.
• Explain why the existing Reactor Markdown parser cannot satisfy the requirement.
• Identify the new authoritative owner.
• Identify the behavioral tests protecting the retained implementation.

Historical or test-only use is not sufficient justification for retention.

8. Remove FunctionalUI-specific tests

• Delete OpenClawTray.FunctionalUI.Tests.
• Remove its solution entry.
• Remove FunctionalUI renderer, flyout, host, theme-callback, cache, and reconciler tests.
• Remove tests tied specifically to ChatMarkdownRenderer.
• Remove source-text contract tests tied to the old Cron renderer.
• Rewrite only still-required product behavior tests against the new owner.
• Do not retain tests whose only purpose is asserting that FunctionalUI files or symbols no longer exist.

9. Remove infrastructure and documentation

• Remove the FunctionalUI build and test lane from .github/workflows/ci.yml.
• Remove its coverage artifact configuration.
• Ensure every new required test is executed by a mandatory CI check.
• Update DEVELOPMENT.md.
• Update docs/TEST_COVERAGE.md.
• Remove stale comments that say chat or onboarding uses FunctionalUI.
• Remove obsolete architecture-ledger ownership entries or update them to the new owner.

10. Reassess theme-resource compatibility code

The app-level redeclarations of standard framework brush keys were introduced so FunctionalUI’s custom theme resolver could enumerate theme-correct values.

• Determine which declarations exist only for FunctionalUI.
• Remove FunctionalUI-only redeclarations.
• Retain resources independently required by Reactor or raw WinUI.
• Update comments to describe current ownership.
• Verify light, dark, and high-contrast behavior before and after cleanup.

Acceptance criteria

• No active production source, runtime path, project, or assembly dependency references OpenClawTray.FunctionalUI.
• No unreachable or migration-only FunctionalUI production implementation remains.
• OpenClawTray.FunctionalUI is deleted.
• OpenClawTray.FunctionalUI.Tests is deleted.
• FunctionalUI project, solution, CI, coverage, and active developer-documentation entries are removed.
• No tests remain solely to validate FunctionalUI.
• No tests merely assert that FunctionalUI files or symbols are absent.
• Existing source-text contracts for the old Cron renderer are removed or replaced with behavioral coverage.
• The replacement Cron implementation has new behavioral, integration, lifecycle, security, accessibility, and visible UI coverage designed for its selected architecture.
• New required tests run in mandatory CI and report non-zero test counts.
• Cron successful responses retain equivalent Markdown presentation against the committed fixture corpus and rendered invariants.
• Cron error responses retain their current selectable plain-text presentation.
• Production chat remains on its existing Reactor Markdown path.
• Links, images, unsafe URI schemes, and raw HTML remain inert.
• Repeated Cron history refreshes do not leak or duplicate hosts, controls, handlers, subscriptions, or rendered state, as demonstrated by deterministic lifecycle tests.
• Keyboard operation, focus behavior, text selection, and UI Automation semantics are preserved.
• Search of tracked production source, tests, project files, solution files, CI configuration, resources, and active developer documentation finds no active FunctionalUI dependency or runtime-path reference.
• Historical issue, PR, changelog, or migration-context references may remain only when clearly identified as historical.
• Any Markdown parser or AST retained after the migration has a documented active production consumer, authoritative owner, and behavioral coverage.

Validation

Required validation:

• ./build.ps1
• dotnet test ./tests/OpenClaw.Shared.Tests/OpenClaw.Shared.Tests.csproj --no-restore
• dotnet test ./tests/OpenClaw.Tray.Tests/OpenClaw.Tray.Tests.csproj --no-restore
• Exact focused command for the replacement Markdown renderer tests, with non-zero pass count.
• Exact focused command for Cron history integration tests, with non-zero pass count.
• Exact focused command for lifecycle tests, with non-zero pass count.
• Exact focused command for security fixture tests, with non-zero pass count.
• Exact focused command for accessibility tests, with non-zero pass count.
• Confirmation that all new tests execute in mandatory CI.
• Current-head visible proof from the actual Cron history list.
• Light, dark, and high-contrast proof using the committed representative Markdown fixtures.
• Visible proof of a long selectable response.
• Visible keyboard-only proof for expanding, reading, selecting, and collapsing the response.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed August 11, 2026, 8:06 PM ET / August 12, 2026, 00:06 UTC.

Summary
Keep open. Current main and the latest release still mount FunctionalUI for successful Cron full responses, while the paired chat cleanup deliberately retains that consumer; a maintainer must choose the replacement owner before this large removal can be safely scoped.

Reproducibility: yes. for the reported dependency: current main directly constructs FunctionalHostControl for successful Cron full responses. Runtime lifecycle and accessibility behavior still need implementation-time proof.

Root-cause cluster
Relationship: canonical
Canonical: #1118
Summary: This issue is the canonical remaining FunctionalUI-removal work for the active Cron renderer after the chat migration.

Members:

• adjacent_distinct: refactor(chat): remove the retired FunctionalUI chat surface #1110 - It removes retired FunctionalUI chat code but explicitly preserves the active Cron Markdown consumer.
• adjacent_distinct: test(chat): add Reactor runtime coverage for timeline behavior #1115 - It tracks Reactor chat timeline runtime coverage, not Cron rendering or FunctionalUI removal.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Maintainer decision needed

Question	Recommendation
Should Cron full responses use an extracted shared Reactor safe-Markdown renderer or a focused native WinUI renderer, and which owner is responsible for its lifecycle and security-equivalence tests?	Use shared Reactor safe Markdown: Extract the existing Reactor security policy into a focused reusable renderer and host it in Cron rows, with explicit disposal and refresh coverage.

Why: Both approaches can preserve the UI, but choosing one determines the renderer boundary, disposal semantics, Markdown behavior, and the deletion scope for FunctionalUI infrastructure.

Next step
A renderer and lifecycle ownership decision is required before a safe implementation boundary can be defined.

Security
Needs attention: The planned renderer migration handles untrusted gateway output and must retain the existing inert Markdown security boundary.

Review details

Best possible solution:

After the chat cleanup lands, extract the Reactor safe-Markdown policy into a focused Cron renderer, prove its lifecycle and accessibility on a real WinUI host, then remove only the library, parser, tests, CI, and documentation proven unused by the final inventory.

Do we have a high-confidence way to reproduce the issue?

Yes for the reported dependency: current main directly constructs FunctionalHostControl for successful Cron full responses. Runtime lifecycle and accessibility behavior still need implementation-time proof.

Is this the best way to solve the issue?

Yes, conditionally. Reusing the already-shipping Reactor safe-Markdown policy is the narrowest likely direction, but a maintainer must first confirm the rendering and lifecycle owner.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The paired chat cleanup is still open and merge-conflicted, so a Cron-only change cannot yet prove that FunctionalUI has no remaining production consumer.
• Cron output is untrusted content. The replacement must retain inert links, images, and HTML, plus prove disposal and focus behavior across history rebuilds.

Codex review notes: model internal, reasoning high; reviewed against 4206611f2b2e.

Label changes

Label changes:

• add issue-rating: 🦞 diamond lobster: Current issue advisory state selects this label.
• add clawsweeper:source-repro: Current issue advisory state selects this label.
• remove issue-rating: 🌊 off-meta tidepool: Current issue advisory state no longer selects this label.

Label justifications:

• P3: This is planned technical-debt removal with no reported current user-facing failure, but it needs deliberate UI and security ownership.

Evidence reviewed

Security concerns:

• [medium] Preserve inert Markdown rendering — src/OpenClaw.Tray.WinUI/Pages/CronPage.xaml.cs:1642
  Cron currently sanitizes successful output before rendering; the Reactor candidate additionally disables HTML and neutralizes links and images. A replacement must prove equivalent non-navigation and no-remote-fetch behavior.
  Confidence: 0.95

What I checked:

• Active production dependency: Successful Cron responses are sanitized, mounted in a FunctionalHostControl, and rendered by ChatMarkdownRenderer; error responses use a native selectable TextBlock. (src/OpenClaw.Tray.WinUI/Pages/CronPage.xaml.cs:1642, 4206611f2b2e)
• Existing maintained rendering direction: The Reactor chat timeline already renders sanitized CommonMark with HTML disabled, inert image text, inert links, and inert HTML-block text, providing a concrete reuse candidate rather than a new general UI layer. (src/OpenClaw.Tray.WinUI/Chat/ReactorChatTimeline.cs:499, 4206611f2b2e)
• Removal spans build and CI ownership: The WinUI project directly references FunctionalUI, and the solution and CI retain its dedicated test project, confirming that this is broader than one method substitution. (src/OpenClaw.Tray.WinUI/OpenClaw.Tray.WinUI.csproj:64, 4206611f2b2e)
• Paired cleanup remains open: The provided context for refactor(chat): remove the retired FunctionalUI chat surface #1110 says FunctionalUI remains for active consumers such as Cron Markdown rendering; that PR is open and merge-conflicted, so it does not yet supersede this work.
• Current-release and history check: The checked-out default branch is a shallow single-commit history, so deeper ownership provenance is unavailable locally; the current source and latest release tag v2026.7.1 both resolve to this revision. (src/OpenClaw.Tray.WinUI/Pages/CronPage.xaml.cs:1607, 4206611f2b2e)

Likely related people:

• karkarl: Authored merged feat(chat): migrate chat surface to Reactor #1055, which established the current Reactor chat rendering path whose safe Markdown behavior is the strongest reuse candidate. (role: Reactor chat feature introducer; confidence: medium; commits: 9acafa606a4d; files: src/OpenClaw.Tray.WinUI/Chat/ReactorChatTimeline.cs)
• Scott Hanselman: The shallow current-main history attributes the present Cron page and its active FunctionalUI dependency to the release revision; deeper file provenance is unavailable in this checkout. (role: current source snapshot author; confidence: low; commits: 4206611f2b2e; files: src/OpenClaw.Tray.WinUI/Pages/CronPage.xaml.cs)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.