Synchronized with ROADMAP.md in the main repo (the source of truth). This page lists what is ahead; what the product already does is documented on the product pages.

Web track

•

Global state + performance budgets.

•

Real-time server push ([ServerEvent] over SignalR); Server Actions are request/response today.

•

Typed programmatic Navigator API for client-side navigation (the router itself is complete, and link-driven).

•

Statement-level source-map density; C# stack mapping is member-level today.

Native track (Photon)

•

Image decoding on the Android shell (Apple decodes through CoreGraphicsImageLoader into RGBA8 textures today).

Component track

•

ListView variable item extents (incremental measurement); v1 is fixed-extent vertical.

•

Spreadsheet: 2D scroll (wide sheets), formula engine, per-cell formatting, merges, frozen panes, all outside v1 scope.

•

Inline marked-text rendering in code surfaces during IME composition.

Track F: form factors (tablet, watch, TV)

A form factor is not a second project here: the same C# already runs on macOS, iOS and Android from one equantic-native. What differs is the SHELL at a given width, and what a device can do that a phone cannot.

Tablet already works. WindowSizeClass (Compact <600dp, Medium 600-839, Expanded ≥840) and AdaptiveNode are realized on both targets, and NavigationRail completed the vocabulary: one NavItem list, a bar under a phone and a rail down the leading edge of a tablet; ListDetail is the two-pane pattern as a component (the first adaptive one in the catalog).

•

Pre-built shells in the templates — shipped: `dotnet new equantic-native --shell blank|tabs|drawer| list-detail (and --shell blank|topnav|dashboard` on the web template), a CHOICE parameter on the two existing templates rather than one template per shape; every shape is adaptive.

•

Wear OS: round safe area, a size class below Compact (a watch is ~200dp), rotary input from the crown or bezel, swipe-to-dismiss. Fence: Tiles and Complications are not Activities, so write-once covers the watch app and not the tile.

•

Android TV: the central piece, arrow-key focus navigation, exists since the keyboard pass; what is missing is the leanback manifest, an overscan-safe area, the 10-foot type scale and a focus ring readable from three metres.

•

Out of scope, with the reason: Android Auto/AAOS makes the app assemble Google's approved templates instead of drawing what it wants, the opposite of this engine. XR sits on the same shelf.

Track W: Photon on the desktop

The fences between Photon today and a shippable desktop app platform, each verified in code: no arbitrary paths in the engine (nine SDF/texture commands — the ninth, FillAnnularSector, shipped in 0.2.0-preview.45), a deliberately periodic IClock whose own fence names the frame clock as the thing not yet built, rectangle-only hit-testing, no desktop shell surface (menus, tray, file dialogs, notifications, deep links), ad-hoc signing that breaks macOS TCC grants on every build, and one window per process.

What shrinks the work, found in the same sweep: a deterministic time channel already runs through native layout (TransitionStore), the 120 Hz driver and two-stop radial gradients exist, and the shader toolchain self-resolves — and the first engine shape, the annular sector, is DONE: an exact SDF with Reference↔Metal↔Vulkan parity, consumer-proven on a real 5.38-million-file sunburst.

Seven workstreams — engine shapes (the sector shipped; the polygon-vs-texture decision waits on the consumer's blob benchmark), frame clock + animation + a UI dispatcher, a custom drawing node with local-coordinate pointer events, the macOS shell surface, real packaging (signing, notarization, publish-based bundles, a minimal updater — sequenced first; the ad-hoc bundle already rebuilds from the payload, allowlists RIDs and fails the build on a bad signature, see Photon), the developer loop (one-command simulator/emulator runs, IDE profiles, redeploy-on-save), and the Windows/Linux shells that stay post-M5. Born from a real app migration (an Electron desktop product), and every piece is generic: the first consumer builds against the SDK from LOCAL packages (see Build Flow) and renders byte-identically from packages and from source. Full plan: docs/DESKTOP-PLAN.md in the main repo.

Track M: email rendering

Author an email in C# with the same components a page is written with, and get HTML an email client will actually render. Email is a third realizer beside web and Photon — a target whose engine is merely very restrictive, which is the same architectural shape as a target with no DOM.

Shipped in 0.2.0-preview.45 — eQuantic.UI.Email: nested tables with spacer cells for gaps, inline styles, literal colors, an absolute-URL guard, a 600px shell, a plain-text twin from the same tree, and build-time refusals for everything an email cannot do. Ahead: the real-client matrix (a generated sample against Gmail, Outlook and Apple Mail) and HTML pins once the output settles. The design and the fences are on Email Rendering.

Track I: editor intelligence (CodeEditor)

The framework ships a real code editor (document model, selection, history, highlighting, bracket matching, find, squiggles) and it currently cannot help you write. The missing half is intelligence, and the piece that makes it possible is proven: Roslyn answers semantic completions over the same compilation the page builds (proven in the playground, which compiles visitors' C# with the real eqc) (context. offers Theme; Col offers Column, because the using static surface is part of that compilation).

•

I1, the completion model in Primitives, beside CodeEditorController: items, selection, the span a commit replaces, open/filter/move/accept/dismiss. Write-once, testable headless.

•

I2, keys and the list in Components: the list is placed at the caret from the metrics the editor already computes (ContentTop, LineHeight, ContentLeft, ColumnWidth), the way the find bar already floats over the code.

•

I3, signature help: the parameter panel on (, on I1's plumbing and I2's placement.

The real problem is latency, not completions: fetch on a trigger (. or Ctrl+Space), filter locally while typing continues, cancel stale requests. Live diagnostics, squiggles as you type, are the same shape.

Track E: the "eQuantic UI" VS Code extension

A first-party visual editor on the SDK itself: live screen preview (the REAL web realizer in a webview), click-to-select in the viewer, a property panel that edits the C# source through Roslyn rewrites, up to full visual editing. Milestones E1 (live preview) → E4 (full editing).

Correction (2026-08-14): the V3 source maps cannot carry the selection. The whole Build body is emitted through a single call, so the finest position a map can name is the start of the method — one shipped module has a 942-character line. Identity comes instead from a target-neutral VisualNode.Origin stamped by a design-mode emission, which is exact rather than correlated, and which the native track inherits for free.

E1 (live preview of the unsaved buffer), E2 (click-to-select and jump-to-source), E3 (the property panel) and the structural half of E4 (insert, move, remove) have landed. See Visual Editor.

Standing directives

•

Zero third-party dependencies wherever the platform provides the capability (system frameworks, embedded toolchains, the Bun/slangc model).

•

Fail loudly: anything the SDK cannot faithfully realize is a build error, never silent divergence.

•

Everything pinned: conformance differentially, styles by byte-identical cross-pins, pixels by goldens, hydration by class identity (e2e).

PREVIOUSDebug

NEXTAnalytics-pt-BR

ON THIS PAGE

Web track

Native track (Photon)