[Feature]: Complete the authoring loop — authoring UI, canvas, and real-IPC E2E

[Dencyuman]

Use case

The Desktop UI currently provides no way to author anything: no view creation control, no entity or relation forms. The VIEWS sidebar is permanently empty for new projects and the center pane shows "Select a view to begin." with nothing selectable. Meanwhile the sanctioned building blocks already exist and pass their tests but are wired to nothing: packages/composer edit builders (buildEntityEdit, buildRelationEdit, …), QueryViewComposer, DocumentOutline, SemanticInspector, SourceNavigationList in packages/react. This issue connects the authoring path end to end.

Suggested shape

• View creation UI: create/edit a view (layer selection, entity/relation type filters, root entity, depth) producing Engine semantic operations.
• Entity/Relation authoring: add and edit entities and relations through forms driven by the schema (entity types, relation types, columns), composed via packages/composer builders.
• Structure navigation: wire DocumentOutline / SemanticInspector into the workspace panes so authored structure is visible and inspectable.
• All edits flow: composer semantic operations → client-sdk BrowserEditor facade → engine.preview_operations / runtime.commit_operations, with the existing preview/apply/undo/redo surface operating on real content.

Acceptance criteria

• From a fresh project, a user can create a view, add entities and relations of schema-defined types, and see them in the outline/inspector — entirely through the UI.
• Committed edits persist: restarting the app and reopening the project restores the authored structure.
• Preview/apply/undo/redo operate on these edits through the existing capability path.
• Reused components remain in packages/react/packages/composer; the Desktop app contributes wiring and desktop chrome only.

Constraints

• Prohibited: generating or manipulating LDL source text in TypeScript, or introducing any LDL/Query/View semantics in the presentation layer. Every edit must be expressed as Engine Protocol semantic operations via composer (docs/architecture.md 11.2). Any PR that templates source text in TS or Go adapters will be rejected.
• Authoring Grant / capability gating must use the existing access decision surface; do not bypass it.

Assignment

Claude Code.

Dependency

Blocked by #172. Weak dependency on #169 for views whose queries use where/traverse; clause-free views must work regardless.

Inspector interaction model (added by owner direction)

The entity inspector's attribute editing follows the Notion database property model, not a static form:

• Each attribute is a property row: label left, inline-editable value right; click-to-edit in place with type-appropriate controls (enum select with colored options, number, text, boolean toggle).
• Schema-permitted property addition/removal from the inspector (subject to Authoring Grant): "+ Add property" appends a column where the effective grant allows schema edits; otherwise the affordance is hidden, not disabled without explanation.
• Property rows show the column type; enum values render as colored chips consistent with visualization tokens.
• Relations render in the same property-row grammar (relation type as the property, targets as linked chips).

---

Consolidated: canvas reachability (was #174)

Use case

The diagram canvas and the Three.js 2.5D viewer are implemented (packages/render, packages/viewer, apps/desktop/src/viewer-three.ts) and verified to produce correct SVG from real Engine ViewData, but no user path reaches them: with no views creatable until now, the center pane has only ever shown a placeholder. Once views exist, selecting one must materialize and display the diagram.

Suggested shape

• Selecting a view in the sidebar triggers materialization (engine.materialize_view capability path) and renders the resulting ViewData through packages/render onto the center canvas (SVG).
• Provide the 2D ⇔ 2.5D toggle wired to the existing Three.js viewer surface with the layer-stacked presentation.
• Meaningful states: loading, empty view (no matching entities) with actionable guidance, and materialization failure with reason.
• Re-materialize on committed edits so the canvas reflects current structure.

Acceptance criteria

• Selecting a view renders its diagram as SVG on the canvas from live Engine ViewData.
• The 2.5D toggle presents the layer-stacked Three.js view of the same ViewData.
• Empty and failure states show actionable messages, never a silent gray pane.
• After an applied edit, the selected view reflects the change without app restart.

Constraints

• Rendering consumes Engine-produced ViewData/RenderData only; no projection or layout semantics reimplemented in the app layer (docs/architecture.md).

Assignment

Claude Code.

Dependency

Blocked by #173.

Canvas stack decision (owner, 2026-07-22)

• View preview / export surfaces render the deterministic SVG produced by packages/render directly — no client-side layout library may be inserted into the View path.
• The Structure editor's interactive 2D canvas uses @xyflow/react (React Flow) as the interaction engine (pan/zoom/drag/connect/selection), with fully custom node and edge rendering styled exclusively by visualization.* tokens. The 2.5D surface remains the existing Three.js viewer.

---

Consolidated: real-IPC E2E gate (was #175)

Use case

Existing Desktop end-to-end coverage asserts against mock IPC call records (window.desktopWorkflow.calls in apps/desktop/test/browser-e2e.mjs) and self-reported packaged probe JSON, so an application whose UI cannot author anything still passed "conformance". The authoring loop milestone requires an E2E gate that drives the real application over real Wails IPC and fails when the user-visible loop breaks.

Suggested shape

• An E2E suite that launches the actual built Desktop binary (packaged or wails dev equivalent) and drives the UI: create project → create view → add entities/relations → diagram appears on canvas → close → relaunch → project restores with authored content.
• Assertions observe user-visible outcomes (rendered DOM/SVG content, persisted files), not internal call records.
• Runs in CI on at least one platform in the existing desktop workflow; the mock-IPC assertions are removed or demoted to component tests explicitly labeled as such.
• Failure output captures screenshots and backend logs for diagnosis.

Acceptance criteria

• E2E completes the full authoring loop against the real binary over real IPC, including restart/rehydration.
• Suite fails when any loop step regresses (verified by at least one intentional mutation during development).
• Mock-IPC E2E assertions no longer gate desktop conformance.
• CI runs the suite and publishes failure artifacts (screenshots, logs).

Constraints

• No self-reported success JSON as the source of truth; assertions must observe outcomes a user can see or a file the product persists.

Assignment

Claude Code.

Dependency

Blocked by #173 and #174.

---

Consolidation note (owner, 2026-07-22)

Authoring UI, canvas rendering, and the E2E gate are one tightly-coupled deliverable (create a view -> see the diagram -> the E2E walks it). They land as ONE PR closing this issue; #174 and #175 are closed as consolidated here. Dependency: blocked by #172 (shell foundation, its own PR).