@xenonbyte/da-vinci-workflow 0.1.10 → 0.1.12

package/CHANGELOG.md

@@ -4,6 +4,22 @@
 
 - No unreleased changes yet.
 
+## v0.1.12 - 2026-03-27
+
+### Changed
+- visual-adapter resolution now documents that the resolved primary adapter must actively lead the first design pass instead of being recorded only for traceability
+- complex redesign guidance now requires anchor-first Pencil generation: design 1-3 anchor surfaces, review screenshots, then expand the rest of the product
+- design-checkpoint guidance now explicitly blocks placeholder-heavy repeated scaffolds and broad multi-screen generation that starts before anchor surfaces are compositionally stable
+- prompt presets for mobile, desktop, web, and tablet surfaces now include `Simple redesign`, `Complex redesign`, `Design-only`, and `Continue` variants in both English and Chinese
+
+## v0.1.11 - 2026-03-27
+
+### Changed
+- Da Vinci now documents `design-source checkpoint` between design review and page-to-Pencil mapping so project-local `.pen` persistence is verified before implementation work proceeds
+- project-local `.pen` paths in `design-registry.md` are now defined more explicitly as workflow-owned state rather than user-authored config
+- Pencil workflow guidance now requires the registered `.pen` path, the active editor source, and the shell-visible project file to reconcile before mapping or implementation is treated as safe
+- workflow examples and mode guides now show project-local `.pen` reconciliation as part of redesign execution rather than an optional cleanup step
+
 ## v0.1.10 - 2026-03-27
 
 ### Changed

package/README.md

@@ -27,10 +27,14 @@ This workflow is intended for:
 
 Latest published npm package:
 
-- `@xenonbyte/da-vinci-workflow@0.1.10`
+- `@xenonbyte/da-vinci-workflow@0.1.12`
 
 Release highlights:
 
+- visual-adapter resolution now requires the resolved primary adapter to actively lead the first design pass
+- complex redesigns now default to anchor-first Pencil generation: design 1-3 anchor surfaces, review screenshots, then expand
+- design checkpoint now explicitly blocks placeholder-heavy repeated scaffolds and premature broad multi-screen generation
+- prompt presets for mobile, desktop, web, and tablet now include `Simple redesign`, `Complex redesign`, `Design-only`, and `Continue` variants
 - `redesign-from-code` now states explicitly that existing code is behavior truth, not layout truth
 - complex pages are now expected to decompose into subpages, overlays, materially different states, and implementation surfaces before broad Pencil redesign
 - design-checkpoint guidance now explicitly blocks skin-swap redesigns, generic card mosaics, weak visual anchors, and decorative clutter
@@ -147,6 +151,9 @@ Selection rules:
 
 - keep `ui-ux-pro-max` first for dense app and dashboard surfaces when the visual bar is moderate
 - move `frontend-skill` to the first slot when art direction, composition quality, and premium visual hierarchy matter more
+- when `Preferred adapters` are configured, the resolved primary adapter should actively lead the first design pass instead of being recorded only for traceability
+- use Pencil guides as platform/buildability constraints, not as the main art-direction source
+- on complex redesigns, design 1-3 anchor surfaces first and review screenshots before broad multi-screen generation
 - keep `Fallback: native-da-vinci` unless you explicitly want missing adapters to block the workflow
 - keep `Require Adapter: false` by default and raise it to `true` only for design-critical work
 - keep `Scope` limited to presentation quality; do not use it to delegate behavior, routes, or state truth
@@ -252,9 +259,10 @@ Da Vinci uses these checkpoints:
 1. `discovery checkpoint`
 2. `spec checkpoint`
 3. `design checkpoint`
-4. `mapping checkpoint`
-5. `task checkpoint`
-6. `execution checkpoint`
+4. `design-source checkpoint`
+5. `mapping checkpoint`
+6. `task checkpoint`
+7. `execution checkpoint`
 
 Checkpoint outcomes:
 
@@ -299,6 +307,10 @@ Rules:
 - `pencil-bindings.md` is the source of truth for implementation page -> Pencil page mapping
 - in `redesign-from-code`, existing code is behavior truth, not layout truth
 - complex pages should be decomposed into subpages, states, overlays, and implementation surfaces before Pencil redesign is treated as final
+- the preferred `.pen` path recorded in `design-registry.md` is workflow-owned state, not user-authored config
+- when Pencil work starts, Da Vinci should use or create that exact project-local `.pen` path instead of relying on whichever Pencil document happens to be active
+- if Pencil MCP edits a live document but does not materialize the shell-visible project file automatically, the workflow should reconstruct and write the `.pen` file under the registered path before treating the design pass as traceable
+- before `pencil-bindings.md` or implementation tasks are treated as safe, `design-source checkpoint` should confirm that the registered path, the active Pencil source, and the shell-visible `.pen` file converge on the same project-local source
 
 Optional visual-adapter policy:
 
@@ -318,18 +330,19 @@ When a relevant mapping already exists:
 
 - iterate on the mapped Pencil source
 - prefer the project-local `.pen` path already registered in `design-registry.md`
+- do not silently switch to a different active editor path without reconciling `design-registry.md`
 
 When mappings do not exist but local code exists:
 
 - reconstruct the baseline from the local project
 - rebuild inventory, page map, and design registry
 - decompose complex containers into real design surfaces before broad Pencil generation
-- save or export the rebuilt Pencil baseline into `.da-vinci/designs/` when possible
+- resolve an exact project-local `.pen` target and materialize that file under `.da-vinci/designs/`
 
 When neither mappings nor usable design sources exist:
 
 - create a new Pencil baseline from the current local source of truth
-- persist that baseline under `.da-vinci/designs/` when possible and record the exact path in `design-registry.md`
+- persist that baseline under `.da-vinci/designs/` and record the exact path in `design-registry.md`
 
 ## Design input collection
 
@@ -508,6 +521,8 @@ Continue into full-delivery.
 See:
 
 - `docs/prompt-entrypoints.md`
+- `docs/prompt-presets/`
+  - includes `Simple redesign`, `Complex redesign`, `Design-only`, and `Continue` variants in each surface file
 - `docs/codex-natural-language-usage.md`
 - `docs/visual-adapters.md`
 - `docs/visual-assist-presets/`
@@ -519,6 +534,8 @@ See:
 Chinese companion documents are included in this repository:
 
 - `README.zh-CN.md`
+- `docs/zh-CN/prompt-presets/`
+  - each surface file also includes `Simple redesign`, `Complex redesign`, `Design-only`, and `Continue`
 - `docs/zh-CN/visual-adapters.md`
 - `docs/zh-CN/visual-assist-presets/`
 - `docs/zh-CN/`

package/README.zh-CN.md

@@ -29,10 +29,14 @@ Da Vinci 是一个把产品需求一路推进到结构化规格、Pencil 设计
 
 最新已发布 npm 包：
 
-- `@xenonbyte/da-vinci-workflow@0.1.10`
+- `@xenonbyte/da-vinci-workflow@0.1.12`
 
 已发布版本重点：
 
+- visual adapter 解析现在要求“解析出来的主 adapter 必须真正主导首轮设计”，而不是只登记在工件里
+- 复杂重设计现在默认采用 anchor-first 的 Pencil 生成策略：先做 1 到 3 个 anchor surface，截图审查后再扩展
+- design checkpoint 现在会明确拦截大量空占位、重复模板和过早的大批量多页面脚手架
+- 移动端、桌面端、Web、平板的提示词模板现在都包含 `Simple redesign`、`Complex redesign`、`Design-only`、`Continue`
 - `redesign-from-code` 现在明确写清：现有代码只是真相行为，不是真相布局
 - 复杂页面现在明确要求在大规模 Pencil 重设计前拆成 subpage、overlay、明显不同 state 和 implementation surface
 - design checkpoint 现在明确会拦截旧 UI 换皮、通用卡片拼贴、弱视觉锚点和装饰性噪音
@@ -152,6 +156,9 @@ Da Vinci V2 支持四种模式：
 
 - 高密度 app、dashboard、工具型界面，且视觉要求中等时，优先把 `ui-ux-pro-max` 放第一位
 - 如果更重视 art direction、构图和高级感，就把 `frontend-skill` 放第一位
+- 一旦配置了 `Preferred adapters`，解析出来的主 adapter 应该真正主导首轮设计，而不是只登记在工件里
+- Pencil 的 guide 只应该约束平台布局和可实现性，不应该替代主 adapter 成为设计方向来源
+- 面对复杂重设计时，先做 1 到 3 个 anchor surface，并完成截图审查，再扩展到更多页面
 - 默认保留 `Fallback: native-da-vinci`
 - `Require Adapter` 默认保持 `false`，只有设计要求很高时再改成 `true`
 - `Scope` 只管 presentation 质量，不要拿它去定义 behavior、route 或 state truth
@@ -252,6 +259,10 @@ project/
 - `pencil-bindings.md` 是实现页面到 Pencil 页面绑定的真相源
 - 在 `redesign-from-code` 里，现有代码只是真相行为，不是真相布局
 - 复杂页面在 Pencil 重设计前应该先拆成 subpage、state、overlay 和 implementation surface
+- `design-registry.md` 里登记的首选 `.pen` 路径属于工作流自动维护的状态，不应该依赖用户手工填写
+- 一旦进入 Pencil 设计，Da Vinci 应该使用或创建这个项目内 `.pen` 路径，而不是继续沿用当前随手打开的 Pencil 文档
+- 如果 Pencil MCP 修改了 live 文档但没有自动把项目内 `.pen` 文件落到磁盘，工作流应该先把该 `.pen` 文件补写到登记路径，再把这轮设计当成可追踪结果
+- 在进入 `pencil-bindings.md` 和实现任务前，应该先通过 `design-source checkpoint`，确认登记路径、当前设计源和 shell 可见 `.pen` 文件已经收敛成同一个项目级来源
 
 可选 visual adapter 规则：
 
@@ -271,18 +282,19 @@ project/
 
 - 优先复用已绑定的 Pencil 设计源
 - 如果 `design-registry.md` 里已经登记了 `.da-vinci/designs/` 下的本地 `.pen` 路径，优先使用它
+- 不要在没有同步 `design-registry.md` 的情况下，悄悄切到另一个当前活动编辑器路径继续设计
 
 当已有代码存在但还没有映射时：
 
 - 先从当前项目重建设计基线
 - 重建 inventory、page-map、design-registry
 - 先把复杂容器拆成真实的设计 surface，再进入大规模 Pencil 设计
-- 在可行时把新的 Pencil 基线保存或导出到 `.da-vinci/designs/`
+- 先解析出明确的项目内 `.pen` 目标路径，再把新的 Pencil 基线真正落到 `.da-vinci/designs/`
 
 当既没有映射也没有可用设计源时：
 
 - 基于当前本地真相源创建新的 Pencil 基线
-- 在可行时把基线保存到 `.da-vinci/designs/`
+- 把基线落到 `.da-vinci/designs/`
 - 并在 `design-registry.md` 里记录准确路径
 
 如果项目声明了 visual adapter：
@@ -422,6 +434,8 @@ Continue into full-delivery.
 
 - `docs/codex-natural-language-usage.md`
 - `docs/prompt-entrypoints.md`
+- `docs/prompt-presets/`
+  - 每个场景文件都包含 `Simple redesign`、`Complex redesign`、`Design-only`、`Continue`
 - `docs/visual-adapters.md`
 - `docs/visual-assist-presets/`
 - `docs/workflow-examples.md`
@@ -431,6 +445,8 @@ Continue into full-delivery.
 中文文档：
 
 - `README.zh-CN.md`
+- `docs/zh-CN/prompt-presets/`
+  - 每个场景文件也都包含 `Simple redesign`、`Complex redesign`、`Design-only`、`Continue`
 - `docs/zh-CN/visual-adapters.md`
 - `docs/zh-CN/visual-assist-presets/`
 - `docs/zh-CN/`

package/SKILL.md

@@ -185,7 +185,9 @@ Do not repeatedly ask for inputs that are already stable in the artifacts.
 Treat visual adapters as optional design-assist layers.
 
 - resolve them from the user request first, then `DA-VINCI.md`, then locally available skills
+- when `DA-VINCI.md` or the request declares `Preferred adapters`, the resolved primary adapter must actively lead first-pass design reasoning instead of being recorded only for traceability
 - use them to improve visual contract quality, composition, hierarchy, spacing, and motion guidance
+- use Pencil guides and platform constraints as buildability aids only; they must not replace the resolved primary adapter as the art-direction source
 - do not let them redefine behavior, page truth, route truth, or acceptance rules
 - if a requested adapter is unavailable locally, continue with native Da Vinci design rules and record the fallback
 
@@ -400,6 +402,18 @@ Use `design-registry.md` as the project-level inventory of `.pen` sources.
 
 Use `.da-vinci/designs/` as the default project-local location for persisted Pencil files when the workflow creates or updates them.
 
+Treat the project-local `.pen` path recorded in `design-registry.md` as workflow-owned state.
+
+- users may provide external references or existing `.pen` files
+- the workflow, not the user, resolves and maintains the preferred project-local `.pen` path
+- do not treat `design-registry.md` as a user-authored config file
+
+Resolve one exact project-local target before broad Pencil work begins:
+
+- `.da-vinci/designs/project-baseline.pen` for shared baseline reconstruction
+- `.da-vinci/designs/<change-id>.pen` for change-specific redesign work
+- `.da-vinci/designs/<change-id>/main.pen` only when the project truly needs a nested design bundle
+
 Use `DA-VINCI.md` as the project-level visual source of truth for:
 
 - theme and palette
@@ -420,6 +434,7 @@ When a relevant mapping already exists:
 - iterate on the mapped Pencil source
 - prefer the project-local `.pen` file under `.da-vinci/designs/` when one is already registered
 - do not create a new design baseline unless there is a reason
+- do not silently keep designing in an unrelated active Pencil document when `design-registry.md` already names a preferred path
 
 When `DA-VINCI.md` already exists:
 
@@ -431,6 +446,7 @@ When page-to-Pencil bindings already exist:
 
 - update the mapped Pencil page for the affected implementation page
 - keep the exact `.pen` file path recorded in `design-registry.md`
+- if the active Pencil editor path differs from that recorded path, switch to the recorded path or explicitly reconstruct the project-local file before continuing
 
 When project mappings do not exist but existing code exists:
 
@@ -438,27 +454,30 @@ When project mappings do not exist but existing code exists:
 - reconstruct `project-inventory.md`
 - reconstruct `page-map.md`
 - create or rebuild `design-registry.md`
+- resolve the exact project-local `.pen` target path before broad Pencil work starts
 - generate a new Pencil baseline only after the inventory is stable
-- save or export that baseline into `.da-vinci/designs/` when possible
+- materialize that baseline into the resolved `.da-vinci/designs/` path and record the exact file in `design-registry.md`
 
 When neither mappings nor usable design sources exist:
 
 - state that the project is entering baseline reconstruction
 - create a new Pencil baseline from the current local source of truth
 - generate `DA-VINCI.md` from inferred or user-provided design rules before generating many unrelated pages
-- persist the resulting `.pen` file in `.da-vinci/designs/` when possible and record the path in `design-registry.md`
+- persist the resulting `.pen` file at the resolved `.da-vinci/designs/` path and record that exact path in `design-registry.md`
 
 When a Pencil session cannot yet be exported locally:
 
 - record the live or external source in `design-registry.md`
-- record why local persistence is pending
-- do not hide the lack of a project-local `.pen` path
+- reconstruct and write the project-local `.pen` file from MCP-readable document data before closing mapping or implementation work
+- if the project-local file still cannot be materialized, record the reason and treat the missing file as a checkpoint issue instead of silently continuing
 
 When visual adapters are requested:
 
 - resolve them from local availability when possible
 - choose one primary adapter when multiple helpers are available
 - record the requested adapters, resolved primary adapter, any secondary helpers, and fallback status in `design-registry.md`
+- treat the resolved primary adapter as the design lead for the first Pencil pass, especially on anchor screens and quality-critical surfaces
+- if `Require Adapter: true` and the requested adapter is unavailable, treat that as a blocker instead of silently downgrading the visual bar
 - continue with native Da Vinci design rules when no adapter is available unless the user explicitly requires a specific adapter
 
 If the request is too vague to design or implement safely, ask a short clarification question before generating artifacts.
@@ -499,32 +518,45 @@ When creating or editing Pencil designs:
 - Build the pages required by the current scope, not an abstract moodboard
 - follow `page-map.md` as the canonical page list
 - follow `design-brief.md` for form factor and visual direction when it exists
+- use the workflow-owned `.pen` path from `design-registry.md` as the active design target
+- do not keep designing in whichever Pencil document happens to be open unless it already matches the registered project-local path
 - use the resolved visual adapter, when available, for composition, hierarchy, restraint, and motion guidance
+- on complex redesigns, design only 1-3 anchor surfaces first before broad multi-screen generation
+- make each anchor surface fully composed with real hierarchy and content structure before expanding the rest of the product
 - before broad page generation, write a visual thesis, a content plan, and an interaction thesis for the current surface
+- use screenshot review after each anchor surface and revise before cloning or expanding variants
 - Keep page names, section names, and labels aligned with the specs
 - Make important states explicit when they change implementation: empty, loading, success, error, restricted, unavailable
 - Prefer layout clarity and information hierarchy over decorative complexity
 - Reject generic UI patterns such as dashboard-card mosaics, weak visual anchors, decorative clutter, or motion with no hierarchy value
+- reject placeholder-heavy scaffolds; unresolved placeholder rectangles are not acceptable substitutes for real screen composition
 - For `redesign-from-code`, redesign from page responsibilities and state decomposition, not by recoloring or slightly rearranging the old UI
 - After changes, inspect the result visually before treating it as implementation-ready
 
 When multiple pages exist:
 
+- derive the remaining pages from approved anchor surfaces and shared primitives rather than from an empty repeated template
 - keep one canonical Pencil page or screen per implementation page
 - record the `.pen` file in `design-registry.md`
 - record the mapping in `pencil-bindings.md`
-- persist the active `.pen` file into `.da-vinci/designs/` before closing design work when possible
+- ensure the active Pencil design is materialized into the registered `.da-vinci/designs/` file before closing design work
 
 ## Pencil MCP Rules
 
 When Pencil is available through MCP:
 
 - Prefer the project-local `.pen` file under `.da-vinci/designs/` when one is registered
+- Treat the registered `.pen` path as authoritative; do not rely on the current active editor if its path does not match `design-registry.md`
+- If the registered file exists, read and edit that exact file
+- If the registered file does not yet exist, create or reconstruct the project-local file before treating the design pass as traceable
 - Read the active `.pen` file and page structure before coding
 - read the bound Pencil page for the current implementation page
 - Use Pencil data to extract layout, text, hierarchy, panels, buttons, and content regions
 - Use screenshots only as a secondary visual check
 - Treat Pencil as the design data source for presentation, spacing, and layout grouping
+- Before mapping or implementation closes, verify both:
+  - the `.pen` path is readable through MCP
+  - the same path exists as a shell-visible file inside the project
 
 When Pencil is not available:
 
@@ -564,15 +596,19 @@ Run these checkpoints:
    - after Pencil design exists, before implementation tasks are locked
    - verify the design covers the required pages, states, and key interactions
 
-4. `mapping checkpoint`
+4. `design-source checkpoint`
+   - after `design-registry.md` resolves the preferred project-local `.pen` path and active Pencil work exists
+   - verify the registered `.pen` path, the active Pencil editor, and shell-visible persistence agree before mapping continues
+
+5. `mapping checkpoint`
    - after `design-registry.md` and `pencil-bindings.md`
    - verify implementation pages and Pencil pages are bound correctly
 
-5. `task checkpoint`
+6. `task checkpoint`
    - before implementation starts
    - verify tasks cover both requirements and Pencil-backed UI work
 
-6. `execution checkpoint`
+7. `execution checkpoint`
    - after each top-level task group during implementation
    - verify code still matches requirements and Pencil structure
 

package/docs/codex-natural-language-usage.md

@@ -69,6 +69,17 @@ Supported modes:
 
 ## Scenario Recipes
 
+For surface-specific prompt starting points, also see:
+
+- `docs/prompt-presets/`
+
+Each surface file includes:
+
+- `Simple redesign`
+- `Complex redesign`
+- `Design-only`
+- `Continue`
+
 ### 1. New project with clear requirements
 
 ```text

package/docs/mode-use-cases.md

@@ -129,7 +129,7 @@ Generate DA-VINCI.md, proposal, specs, page map, Pencil-backed launch pages, bin
    - define the canonical pages and page responsibilities
 
 6. create `design-registry.md`
-   - register the active `.pen` source once Pencil work starts
+   - resolve the workflow-owned project-local `.pen` path once Pencil work starts
    - prefer a project-local `.pen` path under `.da-vinci/designs/`
 
 7. create `design.md`
@@ -137,7 +137,7 @@ Generate DA-VINCI.md, proposal, specs, page map, Pencil-backed launch pages, bin
 
 8. create `pencil-design.md`
    - record the generated Pencil screens
-   - save or export the active `.pen` file into `.da-vinci/designs/` when possible
+   - ensure the active design is materialized into the registered `.pen` path under `.da-vinci/designs/`
 
 9. create `pencil-bindings.md`
    - map implementation pages to Pencil pages
@@ -226,7 +226,7 @@ First synthesize the product direction, then generate DA-VINCI.md, specs, page m
    - `pencil-design.md`
    - `pencil-bindings.md`
    - `tasks.md`
-   - persist the active `.pen` file into `.da-vinci/designs/` when possible
+   - persist the active design into the registered `.pen` path under `.da-vinci/designs/`
 
 ### Where this mode differs from `greenfield-spec`
 
@@ -313,6 +313,7 @@ Register the design sources, extract DA-VINCI.md from them, bind covered pages,
 
 3. create or update `design-registry.md`
    - register old and new `.pen` sources
+   - resolve one workflow-owned project-local `.pen` path for the redesign
    - mark the preferred project-local `.pen` file under `.da-vinci/designs/` when available
 
 4. create or update `page-map.md`
@@ -323,7 +324,9 @@ Register the design sources, extract DA-VINCI.md from them, bind covered pages,
 
 6. create or update `pencil-design.md`
    - build the new redesign baseline in Pencil
-   - persist that baseline into `.da-vinci/designs/` when possible
+   - design 1-3 anchor surfaces first before broad multi-screen expansion
+   - let the resolved primary visual adapter lead that first pass
+   - persist that baseline into the registered `.da-vinci/designs/` file
 
 7. create or update `pencil-bindings.md`
    - bind pages to redesign screens
@@ -338,6 +341,11 @@ Register the design sources, extract DA-VINCI.md from them, bind covered pages,
 
 ### Critical rule in this mode
 
+- treat the resolved primary visual adapter as the first-pass design lead when `Preferred adapters` are configured
+- do not let Pencil guides or generic style packs replace that adapter as the art-direction source
+- do not start broad redesign work by scaffolding many empty screens
+- for complex products, get 1-3 anchor surfaces through screenshot review before expanding the rest of the redesign
+
 For redesign work:
 
 - current code decides behavior
@@ -351,6 +359,12 @@ Fresh-layout rule:
 - do not treat the old UI as the design baseline unless the user explicitly asks to preserve the layout skeleton
 - a recolor, light rearrangement, or minor spacing pass on the old UI is not enough for a true redesign
 
+Project-local `.pen` rule:
+
+- the preferred `.pen` path in `design-registry.md` is owned by the workflow, not by user hand-editing
+- do not keep redesign work inside an unrelated active Pencil editor just because it is currently open
+- if Pencil MCP does not materialize the registered shell-visible file automatically, reconstruct and write that `.pen` file before mapping or implementation is treated as complete
+
 Complex-surface rule:
 
 - if one screen contains multiple fragments, tabs, overlays, or materially different states, split it into multiple design surfaces

package/docs/prompt-entrypoints.md

@@ -76,6 +76,10 @@ Do not default this sequence to `build`.
 
 ## Platform Syntax
 
+For ready-to-copy surface-specific starting prompts, see:
+
+- `docs/prompt-presets/`
+
 ### Codex
 
 Use:

package/docs/prompt-presets/README.md

@@ -0,0 +1,35 @@
+# Prompt Presets
+
+Use these presets when you want a copy-ready starting prompt for a specific product surface.
+
+These presets are designed to pair with:
+
+- `docs/visual-assist-presets/`
+
+Recommended flow:
+
+1. choose the prompt preset closest to the product surface
+2. choose the matching `Visual Assist` preset
+3. choose the prompt variant that matches project complexity and delivery intent
+4. copy both into your workflow setup
+5. tighten the prompt further only when the project has unusual truth sources or platform constraints
+
+Available presets:
+
+- `mobile-app.md`
+- `desktop-app.md`
+- `web-app.md`
+- `tablet-app.md`
+
+Design rule:
+
+- prompt presets define workflow intent, decomposition rules, and truth-source handling
+- visual-assist presets define UI-design helper preferences
+- use both together for the strongest result
+
+Each scene preset should now include:
+
+- `Simple redesign`
+- `Complex redesign`
+- `Design-only`
+- `Continue`

package/docs/prompt-presets/desktop-app.md

@@ -0,0 +1,84 @@
+# Desktop App Prompt Preset
+
+Recommended when the product is a desktop-first tool or workspace.
+
+Pair with:
+
+- `docs/visual-assist-presets/desktop-app.md`
+
+Use this when the workflow needs:
+
+- dense workspace hierarchy
+- clear primary and secondary working regions
+- disciplined panel, dialog, and inspector treatment
+
+## How To Choose
+
+- Use `Simple redesign` when the desktop surface is narrow, mostly single-workspace, or has limited state branching.
+- Use `Complex redesign` when the product has multiple workspaces, side panels, overlays, inspectors, or materially different states.
+- Use `Design-only` when you want the design chain and task readiness without code changes yet.
+- Use `Continue` when the workflow already created artifacts and needs to resume.
+
+## Simple Redesign
+
+```text
+$da-vinci use redesign-from-code to redesign this existing desktop product.
+
+Existing code is the behavior source of truth, not the layout truth.
+Preserve current behavior, flows, integrations, and validation rules unless explicitly required otherwise.
+Inventory the current workspaces, dialogs, overlays, and important states before Pencil work.
+Use the Visual Assist preferences declared in DA-VINCI.md.
+Do not pass design checkpoint if the result is just a boxed-up recolor of the old UI or if workspace hierarchy remains unclear.
+Persist project-local Pencil files under .da-vinci/designs/.
+```
+
+## Complex Redesign
+
+```text
+$da-vinci use redesign-from-code to redesign this existing desktop product.
+
+Existing code is the behavior source of truth, not the layout truth.
+Preserve current behavior, flows, integrations, and validation rules unless explicitly required otherwise.
+Inventory primary workspaces, side panels, inspectors, dialogs, settings flows, overlays, and materially different states before broad Pencil work.
+Decompose complex screens into primary surfaces, secondary surfaces, overlays, and implementation surfaces.
+Use the Visual Assist preferences declared in DA-VINCI.md.
+Treat the resolved primary visual adapter as the first-pass design lead.
+Use Pencil guides only as workspace constraints, not as the design direction.
+Do not start with broad multi-screen scaffolding.
+Design 1-3 anchor surfaces first, review screenshots, then expand.
+Do not pass design checkpoint if the result is a repeated placeholder scaffold, flat panel soup, or a recolor of the old desktop shell.
+Persist project-local Pencil files under .da-vinci/designs/.
+```
+
+## Design-Only
+
+```text
+$da-vinci use redesign-from-code to redesign this existing desktop product.
+
+Existing code is the behavior source of truth, not the layout truth.
+Preserve current behavior, flows, and integrations.
+Inventory workspaces, side panels, dialogs, overlays, and important states.
+Decompose complex screens into real design surfaces before Pencil work.
+Use the Visual Assist preferences declared in DA-VINCI.md.
+If the product is complex, design 1-3 anchor surfaces first, review screenshots, then expand.
+Stop after DA-VINCI.md, design-registry.md, page-map.md, proposal.md, specs, design.md, pencil-design.md, pencil-bindings.md, and tasks.md.
+Do not start code changes yet.
+```
+
+## Continue
+
+```text
+$da-vinci use continue for this existing desktop-product redesign workflow.
+
+Use the existing Da Vinci artifacts in this project.
+Do not restart discovery unless an artifact is missing or clearly wrong.
+Keep the registered project-local Pencil source under .da-vinci/designs/ as the design source of truth.
+If the redesign is complex, continue from the approved anchor surfaces instead of restarting broad scaffolding.
+Continue into the next unfinished stage and do not stop at tasks.md when the active intent is full-delivery.
+```
+
+## When To Switch To Intake First
+
+- workspace boundaries are unclear
+- there are multiple truth sources or mixed product surfaces
+- the first workflow prompt is still hard to phrase cleanly

package/docs/prompt-presets/mobile-app.md

@@ -0,0 +1,84 @@
+# Mobile App Prompt Preset
+
+Recommended when the product surface is a phone-first app.
+
+Pair with:
+
+- `docs/visual-assist-presets/mobile-app.md`
+
+Use this when the workflow needs:
+
+- touch-first hierarchy
+- clear handling of tabs, sheets, dialogs, and nested flows
+- state decomposition that matches real app behavior
+
+## How To Choose
+
+- Use `Simple redesign` when the app surface is small, mostly contained, or has only a few canonical screens.
+- Use `Complex redesign` when the app has multiple activities, fragments, tabs, overlays, or materially different states.
+- Use `Design-only` when you want the full design chain but do not want code changes yet.
+- Use `Continue` when `.da-vinci/` artifacts already exist and the workflow needs to resume.
+
+## Simple Redesign
+
+```text
+$da-vinci use redesign-from-code to redesign this existing mobile app.
+
+Existing code is the behavior source of truth, not the layout truth.
+Preserve business logic, navigation, permissions, integrations, validations, and state transitions unless explicitly required otherwise.
+Inventory the current screens and important states before Pencil work.
+Use the Visual Assist preferences declared in DA-VINCI.md.
+Do not pass design checkpoint if the result is a skin-swap of the old UI, a generic card grid, or a weak mobile hierarchy.
+Persist project-local Pencil files under .da-vinci/designs/.
+```
+
+## Complex Redesign
+
+```text
+$da-vinci use redesign-from-code to redesign this existing mobile app.
+
+Existing code is the behavior source of truth, not the layout truth.
+Preserve business logic, navigation, permissions, integrations, validations, and state transitions unless explicitly required otherwise.
+Inventory activities, fragments, tabs, dialogs, bottom sheets, nested flows, overlays, and materially different states before broad Pencil work.
+Decompose complex screens into subpages, overlays, materially different states, and implementation surfaces.
+Use the Visual Assist preferences declared in DA-VINCI.md.
+Treat the resolved primary visual adapter as the first-pass design lead.
+Use Pencil guides only as layout constraints, not as the design direction.
+Do not start with broad multi-screen scaffolding.
+Design 1-3 anchor surfaces first, review screenshots, then expand.
+Do not pass design checkpoint if the result is a skin-swap of the old UI, a generic card grid, repeated placeholder templates, or weak visual anchors.
+Persist project-local Pencil files under .da-vinci/designs/.
+```
+
+## Design-Only
+
+```text
+$da-vinci use redesign-from-code to redesign this existing mobile app.
+
+Existing code is the behavior source of truth, not the layout truth.
+Preserve current behavior and navigation.
+Inventory screens, tabs, dialogs, bottom sheets, nested flows, overlays, and important states.
+Decompose complex screens into real design surfaces before Pencil work.
+Use the Visual Assist preferences declared in DA-VINCI.md.
+If the app is complex, design 1-3 anchor surfaces first, review screenshots, then expand.
+Stop after DA-VINCI.md, design-registry.md, page-map.md, proposal.md, specs, design.md, pencil-design.md, pencil-bindings.md, and tasks.md.
+Do not start code changes yet.
+```
+
+## Continue
+
+```text
+$da-vinci use continue for this existing mobile-app redesign workflow.
+
+Use the existing Da Vinci artifacts in this project.
+Do not restart discovery unless an artifact is missing or clearly wrong.
+Keep the registered project-local Pencil source under .da-vinci/designs/ as the design source of truth.
+If the redesign is complex, keep the anchor-first flow until the design checkpoint passes.
+Continue into the next unfinished stage and do not stop at tasks.md when the active intent is full-delivery.
+```
+
+## When To Switch To Intake First
+
+- the project has multiple truth sources
+- the UI stack is unclear
+- the first workflow prompt is still hard to phrase cleanly