Avalonia Blocks

Purpose and boundary

NexusScholar.Avalonia.Blocks turns a WorkspacePlan into controls for plan headers, research blocks, evidence references, validation findings, payload JSON, and action descriptors. It depends only on Avalonia and UiContracts.

This renderer is distinct from the Desktop product host. It has no workspace discovery, file I/O, command facade, domain records, persistence, or scientific authority.

Projection and rendering flow

WorkspacePlan or JSON
       |
       v
WorkspacePlanViewModel
  detects sample/non-authority label
       |
       +-- ResearchBlockViewModel[]
       +-- EvidenceRefViewModel[]
       +-- ValidationRefViewModel[]
       +-- BlockActionViewModel[]
       |
       v
WorkspacePlanView and child Avalonia controls

WorkspacePlanViewModel.FromJson deserializes through the shared options. FromWorkspacePlan preserves input order and projects each action into a BlockActionInvocation.

Public controls and callbacks

• WorkspacePlanView.Render: plan header, authority-status label, context evidence, and ordered blocks.
• ResearchBlockView: block badges, summary, evidence, validation, actions, and optional payload.
• EvidenceRefListView and ValidationRefListView: readable projections of traceability and findings.
• PayloadJsonView: displays supplied JSON; it does not interpret scientific meaning.
• BlockActionCallback: optional callback with workspace, block, action, command, target, confirmation, and destructive metadata.

Invoking an action calls only the supplied callback. The control itself never confirms, authorizes, or executes a Core command. Current action UI explicitly labels this as placeholder behavior.

Determinism and failure behavior

The renderer preserves plan and block ordering. Invalid JSON or an invalid UiContracts payload fails during deserialization/construction. Re-render clears and rebuilds the visual tree from the supplied view model. Authority status is a display warning derived from sample refs and descriptions; it is not cryptographic verification.

Consumers that need real commands must route callbacks through a trusted application boundary that revalidates authority, confirmation, and stale state. Connecting a button directly to a domain mutation is prohibited.

Tests and extension points

WorkspacePlanViewModelTests cover contract projection, authority labels, callbacks, and payloads. sample-host tests cover illustrative plan loading. Architecture tests prove the package does not reference domain modules.

New visual treatments belong here when they remain general renderings of UiContracts. Workspace workflows, file pickers, actor policy, and command confirmation belong in Desktop and Desktop.AppServices.

Explicit nonclaims

No product shell, scientific command execution, authority validation, persistence, accessibility certification, cross-platform qualification, AI execution, or PHP compatibility is claimed. Renderer isolation is architectural separation, not a security sandbox.