• Date: 2026-06-04
• Status: Accepted (paradigm direction locked; mechanics in design — see Open engineering questions)
• Phase / Feature: Product paradigm pivot — reframes Phase 0-16 roadmap
• Builds on: ADR 0020 (Layout Grid), ADR 0023 (Deploy pipeline), ADR 0025 (Tokens publish), ADR 0027 (Composition zones), ADR 0030 (Page reconstruction), ADR 0031 (Workflow canvas), ADR 0034 (Design-system-first capture)
• Reframes (does not replace): ADR 0031 — workflow canvas becomes Layer 1 of the onion, not a standalone tab

Context

Session 2026-06-04 surfaced the underlying product thesis that the current roadmap (Phase 0-16) implements piece-by-piece but never names as a single paradigm. This ADR names it, fixes the direction, and identifies the engineering work remaining before the paradigm is shippable.

Trigger — daily designer reality

The conversation started from a deep-research question: "what does a designer do on Day-1 of a new sub-product when vision is approved?" Research (workflow w6ivlkpe9, 28 sources, 14 confirmed claims) returned discovery-phase artifacts (Hills, Job Stories, briefs, Sprint maps). The trigger correction was direct:

"У меня сценарий состоит из 20+ экранов. Каждый день я начинаю всё сначала — новый сценарий, новая ручная сборка экрана и всех его состояний — один, второй, третий, вот и сценарий. Вот ежедневная работа дизайнера. FigJam только для нестандартных и сложных фичей, Figma со сценариями для 90% времени работы. И большую часть времени я трачу на сборку всего этого через дизайн-систему — она глючит, её нужно пушить чтобы разошлось по всем макетам, потом проверять чтобы ничего не разъехалось — это занимает очень много сил."

This is the actual job-to-be-done. Not discovery (briefs/Hills are already done by the time designer opens the tool), not exploration (FigJam is 10% edge case). It is repetitive scenario assembly with brittle DS propagation. Figma serves this badly: every token edit requires manual push, manual verify, manual repair. The 80% of daily work is the 80% Figma neglects.

Why current ADRs don't yet name this

• ADR 0020 (Layout Grid) — builds the canvas primitive but doesn't position it against Figma's daily-work failure mode.
• ADR 0027 (Composition zones) — solves drift in deploy artifact, doesn't address designer-side DS cascade.
• ADR 0030 (Page reconstruction) — gives the capture path but doesn't say what the resulting canvas semantically is (FigJam? wireframe? hi-fi? all three? layered?).
• ADR 0031 (Workflow canvas) — defines a Figma-style infinite canvas but treats it as a tab parallel to library/component editors, not as Layer 1 of a multi-layer paradigm.
• ADR 0034 (Storybook-first capture) — gives the DS material but doesn't define how the designer composes from it.

This ADR is the connecting tissue: it states the paradigm these pieces serve.

Decision

ARNO is built around four interlocking principles. They are not features; they are the model the rest of the product must serve.

1. Onion-layered canvas — FigJam, wireframe, hi-fi screens as cumulative layers in one project

The canvas has three distinct layers, sharing one project space:

• Layer 1 — Flow (FigJam-mode): boxes, arrows, sticky annotations. Exploratory. For non-standard scenarios (10% of time) and for laying out the screen graph before wireframing.
• Layer 2 — Wireframe: default-described components arranged into screens. Designer edits variables, not behaviour. Low-fidelity by default, but components are not visual proxies — they are real DS nodes in placeholder paint.
• Layer 3 — Hi-fi screens: same components from Layer 2, painted with brand tokens. Production-ready visual.

Layers are cumulative, not parallel. A project starts at Layer 1. When the designer finishes Layer 1 and moves to Layer 2, the system automatically duplicates Layer 1's state into Layer 2 as the starting point, and Layer 1 freezes — it is preserved as an artefact, mutable only by manual unfreeze. Same handoff from Layer 2 to Layer 3.

This is not live-synchronized branching. Layers are layers of an onion: they coexist in one project but they are different layers, frozen in sequence. Updating an upstream layer does not automatically propagate downstream — propagation is opt-in and explicit.

This dissolves the "FigJam vs Figma vs wireframe-tool" tool-switching tax without inheriting the brittleness of live-linked multi-fidelity graphs (which is what every prior unified-canvas attempt — InVision Studio+Boards+Freehand, Framer-old, Adobe XD — broke on).

2. Default-described components — designer edits variables only

Every wireframe and screen component ships with system-managed defaults. An input acts like an input. A button acts like a button. The designer does not describe behaviour. They edit only the variables that make this instance unique — text content, state, size from the spacing scale, variant selection.

The behavioural and structural defaults live in code, in the DS layer. They cannot be redefined per-instance through pixel manipulation. They can only be extended by adding new components to the DS, which then become available with their own variables.

This is what makes Layer 2 (wireframe) fast: drop a default Input, type a label, done. No box-drawing, no "what does this component do" decisions. And it is what makes Layer 2 → Layer 3 transition near-automatic: same component, same variables, different paint.

3. Rule-locked DS cascade — code-enforced consistency, not push-and-pray

DS rules are authored in code, not in a UI that pushes to copies. Examples:

• spacing-input ∈ {20} — input padding is exactly 20px. Cannot be 24. Cannot be 18. The designer cannot drag it to a different value because the system does not expose the value as a draggable property.
• colour-text-primary = brand-token-1 — text colour is a token reference, not a hex. Token changes propagate by virtue of the reference being live, not because someone clicked "publish to library".
• corner-radius-button = brand-radius-md — radius is a token, not a number.

When the designer edits Layer 2's wireframe components, the rules are already in force. When they paint Layer 3 with brand tokens, the rules are still in force — they only change which tokens are referenced, not whether the references exist.

This is the moat against Figma: Figma's DS-cascade requires manual push and manual verification because Figma's components are copies with weak references that designers can override. ARNO's components are live nodes in a graph that cannot be overridden by pixel-drag because the graph defines the surface area of edits.

"Меньше работы руками — меньше правок — автоматизация на уровне системы. Если между инпутом и другим инпутом 20, то он никогда больше не станет 24 — потому что это задано на уровне системы. Никакой свободы, только правила которые мы сами создаём для того чтобы система работала. Мы так и делаем в Figma, но там система не идеальна и даёт сбои постоянно. Тут же — код, тут всё прибито."

4. Snapshot-on-handoff — version pinning instead of branching

The "designer changes mockup mid-development" drift problem is solved without exposing branching UX. Mechanic:

• When a developer takes a screen (clicks a copy-spec link, opens dev-mode URL, references it in a task), the system automatically freezes that state as an immutable snapshot. The developer's URL contains the snapshot id.
• The designer continues editing the live screen. The developer's URL still points to the frozen snapshot.
• A "Publish update" action on the designer side pushes a new snapshot and notifies the developer. The developer sees a diff against their previous snapshot.

No git checkout, no merge, no branch graph. Designers see only their canvas. Developers see only their snapshots. The branching topology lives invisibly under the surface.

This name-shift matters: do not call this branching. Branching is the failed paradigm (Abstract, Plant, Figma Branching — all niche-or-dead). Call it version pinning on handoff or snapshot-on-share. Same mechanic, different mental model.

Why this is moat — not retread

A research pass surveyed every prior attempt at "unified canvas + linked artifacts" and named why each failed or stayed niche:

The pattern: rule by specialization at the surface level + integration in the substrate. Figma won by being best-in-class at hi-fi screens and connecting cleanly with FigJam for flow. The substrate (Figma cloud) integrates; the surfaces specialize.

ARNO's claim is not "we integrate the surfaces." It is "we integrate the substrate so deeply that the surfaces become a continuum rather than separate tools." Specifically:

• The substrate is code-linked, rule-locked DS that lives outside any single layer.
• The surfaces (Layer 1 flow, Layer 2 wireframe, Layer 3 hi-fi) are views into the same underlying graph, not independent files.
• Freeze-on-progression preserves the specialized mental modes of each layer (FigJam-mode is loose; wireframe-mode is precise; hi-fi-mode is finalised) without forcing live coupling that breaks under edits.

This is ARNO's unfair advantage over Figma: Figma cannot retrofit code-linked rule-locked DS into a file-format that was designed around designer-overridable copies. They would have to break backward compatibility on the format. ARNO is greenfield on this dimension.

Conversation transcript (preserved per user request)

The full dialectic that produced this ADR. Read this if you want to understand why the paradigm landed where it did, not just what it is.

Round 1 — user proposal

"если FigJam и Wireframe самые частые то если их объединить у нас, можно получить конкурентное преимущество. Что если после создания нового проекта он открывается, там можно в workflow можно строить FigJam схемы. Это будет все экраны приложения — можно просто квадратики и кружочки, а можно сразу наполнять их компонентами из дизайн системы — в дизайн системе лежат все самые популярные компоненты в виде вайрфреймов. У вкладки вайрфреймы можно делать бранчирование и тогда можно работать параллельно и с FigJam схемами и с вайрфреймами и с экранами. Если ты собрал на вайрфреймах и согласовал, то в дизайн системе можно начать заносить уникальные сущности и эти вайрфреймы начнут краситься в цвета твоего бренда и все остальные токены туда же. Получается всё в одном месте и видно как оно растёт от фигджема до реальных экранов и все компоненты тоже растут и нет лишних копий и полная синхронизация."

Round 1 — Claude critique (9 cons, pros omitted for brevity)

1. Three cognitive modes in one canvas — compromise on each. FigJam, wireframe, hi-fi are different mental modes, not different fidelity levels of the same thing. Forcing them into one canvas means FigJam loses lightness (every sticker is a potential wireframe-node, scary to delete), wireframe loses focus (flow-noise nearby), hi-fi loses clean state.
2. Wireframe branching is the git-for-design trap. Abstract, Plant, Figma Branching all niche-or-dead because designers don't think in commits.
3. "Token-painting at the end" conflates two orthogonal axes. Visual fidelity (lo-fi → hi-fi) vs DS maturity (placeholder → finalized tokens). Auto-painting wireframes with new tokens doesn't make them screens — it makes painted wireframes (fake done).
4. Live sync = brittleness, not freedom. Three linked layers = three synchronized failure modes. CRDT-merge of visual content is an unsolved industry problem.
5. FigJam-first onboarding adds friction for delivery-mode designers who already know their screens.
6. Sync hides where work happens. When wireframe and hi-fi are one object of different fills, semantic state ("done vs in process") is lost.
7. Scope creep against master spec. Three new product surfaces to build before any is excellent.
8. "See how it grows" is a demo feature, not daily-work feature. In daily work, designer doesn't look at flow when working on hi-fi.
9. Competition isn't Figma+FigJam, it's status quo. Need 10x argument on one axis, not 1.5x on three. 10x = code-linked DS from capture (already being built), not unified canvas.

Round 2 — user rebuttal, point by point

1. (on cognitive modes) "Все компоненты вайрфреймов уже описаны базово — всем понятно что инпут это инпут. Просто у него есть переменные которые меняются и делают твой инпут уникальным. Вот их и меняй, а дефолтное описание оставь системе. Для дизайнера только дизайнерская работа — всё остальное автоматизировано." → Resolved into Decision §2 (default-described components).

2. (on live sync brittleness) "Они не должны быть связаны — это слои как у луковицы, они вместе, но они разные слои. Просто ты начинаешь с первого, когда заканчиваешь, делаешь его же копию и переходишь ко второму, первый замораживается и не меняется автоматически — остаётся как артефакт, меняется только вручную. И так далее." → Resolved into Decision §1 (onion layers with freeze-on-progression). This is the key insight that dissolves the live-coupling failure mode.

3. (on FigJam-first friction) "Если они знают, то сразу в этот FigJam-квадратик начнут добавлять компоненты и собирать вайрфреймы — это будет быстро. Потом когда они согласуют вайрфреймы, им не нужно будет пересобирать экраны уже на компонентах, им нужно будет перекрасить компоненты вайрфреймов и тогда все вайрфреймы преобразятся." → Resolved: FigJam-mode is the canvas, but is not a forced first step. Designer who already knows screens drops components into FigJam boxes directly, skipping pure-flow phase.

4. (on scope creep / no 10x) "В этом то и прелесть Арно — тут всё живёт как большой взаимосвязанный механизм, а не отдельные куски не связанные вместе. Сейчас в Figma это очень не идеально. Тут же правишь в одном месте а прорастает во все. Путь такой — собираешь 10 вайрфреймов из того что было по default — утверждаешь, идёшь в дизайн систему и начинаешь их делать красивыми и уникальными. По результату все 10 экранов стали hi-fi." → Resolved into Decision §3 (rule-locked DS cascade) as the actual 10x argument.

5. (on pivots/risk) "Ну пивоты случаются. Задача сделать так чтобы 30K захотели нами пользоваться — вот мы и экспериментируем." → Accepted as governance posture: paradigm is committed, mechanics will iterate.

6. (on "demo vs daily") The 20+ screen scenario quote at the top of this ADR. → Resolved: paradigm is daily-work first, demo-second. Reframed Claude's point 8 as wrong.

7. (on automation thesis) "Меньше работы руками — меньше правок — автоматизация на уровне системы. Вот что мы предлагаем! Те кто перейдёт будут разрабатывать продукты будущего, те кто останутся — будут двигать пиксели." → Adopted as positioning / tagline (see below).

Round 2 — Claude agreement + 2 remaining engineering questions surfaced

Model is internally more consistent than I read it. Onion-freeze solves brittleness without CRDT-merge. Default-described components remove cognitive load. Code-linked rule cascade is the real differentiation. Daily-work picture is correct.

Two remaining engineering tasks I must acknowledge honestly:

• "Repaint components → all screens become hi-fi" works only while brand reduces to token-swap. Custom layout, custom iconography, brand-specific spacing exceptions require manual work. UX must show this honestly, not promise full auto-transform.
• Rule-editor is a sub-product, not a feature. "If 20 — never 24" needs: rule authoring UI, consistency validator, conflict resolution between rules, designer-facing violation feedback. Without this foundation, "system holds the rules" is a slide.

Both elevated to Open Engineering Questions Q1 and Q2 below.

Round 3 — branching deep-dive

User pushed back on the "branching trap" framing: the v2/v3/v10 mockup-mess problem is real and worth solving, the failure was exposing git-topology in UI, not branching itself. Mechanic must be invisible.

Claude conceded, distinguished two sub-problems:

• Designer ↔ designer divergence — still a CRDT-merge problem, unsolved at the visual layer industry-wide. Out of scope for this paradigm.
• Designer ↔ developer handoff drift — solvable without CRDT-merge because the developer never writes to the canvas. Solution: snapshot-on-handoff.

→ Resolved into Decision §4 (snapshot-on-handoff).

Round 4 — cloud question

User asked what Figma Cloud and Adobe Creative Cloud are, and whether ARNO needs one.

Resolved: ARNO is already cloud-native by architecture (Cloudflare + Liveblocks + Neon). No separate "ARNO Cloud" SKU. Not a multi-app bundle. The substrate-integration claim above is the cloud-native answer.

Open engineering questions

These must be answered with concrete mechanics before this paradigm is shippable. They block this ADR from being fully "Accepted" on mechanics — only the direction is locked.

Q1 — "Repaint → hi-fi" failure modes (brand-specific layout / iconography / spacing exceptions)

Problem: "Approve 10 wireframes, paint tokens, all 10 become hi-fi screens" works while brand reduces to token-swap. It breaks when:

• Hero screen has custom layout that no wireframe template covers
• Brand uses custom iconography not in the wireframe component library
• Specific screen needs a spacing exception (e.g. dense data table with 12px row gap, outside the standard 8/12/16 scale)
• Brand requires a custom component variant that didn't exist at wireframe time

Required mechanic: UX must honestly show which screens auto-transformed cleanly and which need manual touch. Like a CI build status per screen: "Layer 3 — 8/10 screens auto-painted, 2 screens flagged for manual review." Not promising full-auto.

Design space: Per-screen transform-status. Per-component "rule violation" flag. "Stuck on wireframe" badge with reason.

Owner: Layer 3 design, post Phase 17.

Q2 — Rule-editor as a sub-product

Problem: "If spacing 20 — never 24" needs to be authored, validated, and enforced. This is a non-trivial sub-product:

• Rule authoring UI — how does a designer say "input padding ∈ {20}"? Visual? Textual? Per-component? Per-scope?
• Consistency validator — when a new rule is added, check against existing rules and flag conflicts.
• Conflict resolution — two rules say different things about the same property. Which wins? How is the conflict surfaced?
• Designer-facing violation feedback — when a designer drags something to a value the rule forbids, what does the system say? Red border? Snap to nearest allowed? Refuse the edit?

Required mechanic: Full rule-editor UI + storage model + validation engine + ergonomics for the designer who hits a rule wall.

Adjacent prior art: Tokens Studio (Figma plugin) covers token authoring but not enforcement. Style-Dictionary covers transformation but not authoring UI. None cover designer-facing rule violation feedback at edit time.

Owner: Phase 17 candidate. Likely 2-3 month sub-project on its own.

Q3 — Onion-freeze in multiplayer mode

Problem: Onion-layer freeze model works for a single designer. In Liveblocks-live mode with multiple designers:

• Who freezes Layer 1 → Layer 2 transition? First designer to click "advance"? Requires consensus?
• If designer A is on Layer 2 and designer B copies Layer 1 (creating a new Layer 2 instance), what happens to A's work?
• Per-layer ownership? Per-screen ownership?
• Concurrent edits on same Layer 2 screen — auto-merge (Liveblocks default) or conflict-resolve?

Required mechanic: Multiplayer semantics for layer transitions. Likely a project-level "current layer pointer" with explicit advance action requiring all editors to ack.

Owner: Phase 18 candidate.

Consequences for existing ADRs

This paradigm does not invalidate prior ADRs but reframes how they fit together. Status of existing ADRs:

ADR 0031 explicitly gets reframed: the "workflow canvas" is not a separate tab — it is Layer 1 of a three-layer single canvas. Implementation can continue along ADR 0031's plan, but UI labelling shifts: instead of "Workflow tab" the designer sees a layer-switcher within one project view.

Anti-patterns — explicit do-not-do list

These are not features that aren't included; they are decisions to actively avoid because prior art shows they kill the paradigm.

• Do not show branching topology to the designer. No commit graph, no branch tree, no merge UI. Snapshot-on-handoff and onion-freeze are the user-visible mechanics; the underlying versioning is invisible. (Killed Abstract, Plant.)
• Do not live-link layers. Layer 1 → Layer 2 → Layer 3 propagation is opt-in and explicit. Live coupling re-introduces the CRDT-merge problem and the brittleness problem. (Killed InVision Studio + Boards.)
• Do not expose component behaviour to the designer. Designer edits variables. Behaviour is system-managed. If a designer wants new behaviour, that is a DS extension (a separate ritual with code review), not an in-canvas edit.
• Do not promise full auto-transform from wireframe to hi-fi. UX must honestly show partial transform with explicit manual-review flags. (Avoids the "fake done" failure mode.)
• Do not build rule-editor as a side feature. It is a sub-product. Treating it as a side feature underestimates the surface area and produces a slide-deck demo instead of a working tool.
• Do not call this branching. Name is "version pinning on handoff" or "snapshot-on-share." Branching is the failed paradigm; the name carries baggage that primes designers to reject the feature.

Positioning

The user's framing, adopted verbatim as the tagline candidate:

"Меньше работы руками — меньше правок — автоматизация на уровне системы. Те кто перейдут будут разрабатывать продукты будущего, те кто останутся — будут двигать пиксели."

Target: enterprise designers / PMs / product owners who today live in Figma + FigJam + Linear + DS-management-spreadsheet, and who feel the daily friction of DS-cascade brittleness and scenario re-assembly. Not freelancers, not visual designers, not early-stage exploration tools. People who do the 80% repetitive work that Figma neglects.

Sequencing — what we build first

Order matters. Building Layer 1 alone would just be FigJam. Building Layer 3 alone would just be a worse Figma. The moat appears only when at least Layers 2-3 + Rule Cascade ship together.

1. Decision §3 (Rule-locked DS cascade) — Phase 17 candidate. This is the moat. Without it, the rest is decoration. Build the rule authoring + validator + cascade engine first.
2. Decision §2 (Default-described components) — Phase 17/18. Requires §3 (rules) to enforce defaults. Then ship a starter library of default components.
3. Decision §1 (Onion layers + freeze-on-progression) — Phase 18. UI mechanics for layer switching. Builds on existing ADR 0031 workflow canvas.
4. Decision §4 (Snapshot-on-handoff) — Phase 19. Versioning + dev-mode URL pinning. Can run in parallel with §1 from late Phase 18.
5. Q1 (Manual-touch flags for brand-specific layout) — Phase 19/20.
6. Q3 (Multiplayer layer-freeze semantics) — Phase 20+.

This sequencing places ADR 0035 paradigm work in Phases 17-20, after the current Phase 0-16 roadmap completes. It does not require pausing current work; the capture / reconstruction / workflow-canvas work in flight is the substrate this paradigm renders through.

References

• Deep research workflow run w6ivlkpe9 (2026-06-04) — Day-1 designer ritual research; 28 sources, 14 confirmed claims, 11 refuted
• Session transcript 2026-06-04 — preserved in §"Conversation transcript" above
• ADR 0031 — workflow canvas Figma-style design (now reframed as Layer 1)
• ADR 0034 — Storybook-first capture (fuels default-described components)
• ADR 0030 — Page reconstruction (initial source of Layer 2 components when capturing existing site)
• ADR 0025 — Tokens publish (cascade mechanism foundation)