@ankhorage/devtools 1.10.10 → 1.10.12

package/dist/tools/skills/assets/ankhorage-project-structure/SKILL.md

@@ -2,20 +2,19 @@
 name: ankhorage-project-structure
 description: >
   Design, review, or migrate the source structure of Ankhorage repositories and generated
-  applications. Use for directory ownership, package boundaries, architectural profiles,
-  ports and adapters, package CLI layout, repository skill distribution, public entrypoints,
-  or cross-repository cleanup.
+  applications. Use for directory ownership, package boundaries, package CLI layout, repository
+  skill distribution, public entrypoints, or cross-repository cleanup.
 ---
 
 # Ankhorage Project Structure
 
-Apply a repository profile instead of forcing one folder tree onto every package.
+Apply the general ownership rules first. Only Studio currently has a mandated source taxonomy.
 
 Before deciding structure:
 
 1. Read the repository `AGENTS.md`, `package.json`, exports, source tree, and representative tests.
 2. Load `ankhorage-coding-rules` as the complementary implementation and testing authority.
-3. Identify the repository's owning capability and its profile below.
+3. Identify the repository's owning capability.
 4. Identify current public subpaths and cross-package release boundaries.
 
 Repository-specific rules may refine this skill, but must not silently reverse package ownership
@@ -24,35 +23,23 @@ or dependency direction.
 ## Primary boundary
 
 An Ankhorage repository/package is the primary bounded capability and independently released
-unit. Do not create a generic `src/features/` layer that imitates package boundaries.
+unit. Do not force a Studio directory tree onto libraries, providers, tooling, or generated
+applications.
 
 - Independently bindable capabilities belong in standalone packages.
-- Substantial responsibilities inside a package use cohesive domain directories directly under
-  `src/`.
+- Substantial responsibilities inside a package use cohesive directories owned by the package.
 - Cross-package access uses published APIs and declared dependencies, never sibling source.
 - A package owns its application behavior; adapters belonging to another package are not copied
   or proxied locally.
 
-## Select a profile
-
-Read [repository-profiles.md](references/repository-profiles.md), select one primary profile, and
-apply only the references routed by that profile.
-
-| Profile                            | Typical repositories                                          | Required references                                                                                        |
-| ---------------------------------- | ------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- |
-| Application, engine, or hybrid     | Studio, Runtime, Orchestrator, Deploy, Infra                  | [hexagonal-architecture.md](references/hexagonal-architecture.md)                                          |
-| React Native / Expo application    | generated apps, Studio app host                               | [hexagonal-architecture.md](references/hexagonal-architecture.md), [expo-apps.md](references/expo-apps.md) |
-| Component or design-system library | ZORA, Surface                                                 | [ui-libraries.md](references/ui-libraries.md)                                                              |
-| Contracts or value library         | Contracts and other portable models                           | [repository-profiles.md](references/repository-profiles.md)                                                |
-| Utility library                    | Utility                                                       | [utilities.md](references/utilities.md)                                                                    |
-| Platform/provider adapter          | Expo Runtime, Supabase packages, orchestrator modules         | [repository-profiles.md](references/repository-profiles.md)                                                |
-| Tooling or CLI package             | Ankh, Doctor, Devtools and any package exposing Ankh commands | [cli.md](references/cli.md)                                                                                |
-
 When a package declares an Ankh provider or changes `src/cli/`, always read
-[cli.md](references/cli.md), regardless of its primary profile.
+[cli.md](references/cli.md).
+
+When classifying a local or cross-repository utility, also read
+[utilities.md](references/utilities.md).
 
 When the task is a structural cleanup or migration, also read
-[migration.md](references/migration.md). For Studio specifically, read
+[migration.md](references/migration.md). For `ankhorage/studio`, always also read
 [studio.md](references/studio.md).
 
 When adding, distributing, or synchronizing repository-local agent skills, read
@@ -63,13 +50,8 @@ When adding, distributing, or synchronizing repository-local agent skills, read
 - Keep only intentional package entrypoints and required declaration shims directly under `src/`.
 - Keep one abstraction level and responsibility among siblings.
 - Prefer domain ownership over technical dumping grounds such as `common`, `core`, `helpers`,
-  `misc`, or `shared`.
-- `app/`, `cli/`, `host/`, and `platform/` are package-level edges or composition areas, not
-  alternate owners of domain behavior.
-- Ports are owned by the application/domain code that requires the capability.
-- Adapters depend inward; domain/application code does not import concrete adapters.
-- Add a port only for a real external or replaceable boundary. Do not wrap every function in
-  architecture ceremony.
+  `misc`, or `shared`. `utils/` is the canonical local directory for genuine package-level
+  utilities.
 - Colocate focused unit tests. Put cross-domain acceptance, E2E, smoke infrastructure, and large
   fixtures outside production source.
 - Public package subpaths may point to nested source. Do not keep files at `src/` merely because
@@ -88,3 +70,10 @@ For every file or new symbol, decide in order:
 4. Is it reusable enough to belong in `@ankhorage/utility` instead?
 
 If any answer is unclear, resolve ownership before moving or creating code.
+
+## Studio enforcement
+
+Only `ankhorage/studio` has a mandatory source taxonomy and hexagonal feature architecture. Its
+complete allowlist, exceptions, port/adapter rules, and generated-app policy are in
+[studio.md](references/studio.md). Other repositories remain structurally unconstrained beyond the
+universal invariants until their owning repository is deliberately brought into scope.

package/dist/tools/skills/assets/ankhorage-project-structure/references/studio.md

@@ -3,8 +3,8 @@
 Read this only for `ankhorage/studio`. It is a structural target and ownership checklist, not a
 license to move every file in one change.
 
-Studio is an application/hybrid package. The Studio package is the bounded capability; its internal
-responsibilities are domains, not independently bound `features`.
+Studio is the bounded capability. `features/` is its internal organizational boundary; its contents
+are not independently bound packages.
 
 ## Target source tree
 
@@ -13,29 +13,31 @@ src/
   index.ts
   root.ts
 
-  app/                         # React/RN application edge and composition
   cli/                         # one Studio Ankh provider
   host/                        # Bun/Fastify/filesystem edges and host composition
-  platform/                    # Studio-local native/web implementations only
-
-  auth/
-  bindings/
-  canvas/
-  deploy/
-  diagnostics/
-  external-apis/
-  manifest/
-  media/
-  modules/
-  projects/
-  properties/
-  routes/
-  secrets/
-  selection/
-  templates/
-  workspace/
+  apps/                        # generated applications; Studio-only directory
+    <generated-app>/            # generated; never edited by hand
+    studio/                     # temporary exception until Studio is generated
+
+  features/                    # Studio-owned capabilities
+    auth/
+    bindings/
+    canvas/
+    deploy/
+    diagnostics/
+    external-apis/
+    manifest/
+    media/
+    modules/
+    projects/
+    properties/
+    routes/
+    secrets/
+    selection/
+    templates/
+    workspace/
 
-  utils/
+  utils/                       # the canonical Studio-local utility directory
 
 test/
   acceptance/
@@ -44,8 +46,20 @@ test/
   smoke/
 ```
 
-Substantial domains may contain `contracts`, `domain`, `application`, `ports`, and domain-local
-`utils` when those roles genuinely exist. Do not pre-create all role directories.
+`index.ts`, `root.ts`, `cli/`, `host/`, `apps/`, `features/`, and `utils/` are the complete Studio
+root taxonomy, apart from required declaration shims. Do not create `app/`, `platform/`, `common/`,
+`core/`, `helpers/`, or `shared/`.
+
+Substantial features may contain `contracts`, `domain`, `application`, `ports`, `adapters`, and
+focused colocated `tests` when those roles genuinely exist. Do not pre-create role directories.
+
+`apps/` contains complete generator-owned applications. Nothing under it is manually maintained.
+`apps/studio/` is a temporary exception while Studio is still hand-authored; it must disappear when
+the Studio app is generated.
+
+`utils/` is the one canonical local utility directory. It contains only reusable Studio-local,
+framework-neutral helpers; behavior with feature semantics remains in that feature, and behavior
+reused across repositories belongs in `@ankhorage/utility`.
 
 ## Studio CLI
 
@@ -73,41 +87,73 @@ ankh studio projects list    -> commands/projects/list.ts
 ankh studio projects sync    -> commands/projects/sync.ts
 ```
 
+`cli/commands/` contains inbound adapters only: parse command input, invoke a feature application
+operation, and render the result. It must not own feature rules or external-package integrations.
+
+## Studio host
+
+```text
+src/host/
+  createStudioHost.ts
+  middleware/
+  routes/
+    <feature>/
+```
+
+`host/` contains inbound HTTP, filesystem, and process adapters plus their composition. Route and
+middleware modules translate into feature application operations; they do not own feature rules.
+
 `ankh studio workspace install` is not part of the target. Generated apps are standalone and own
 their installation. Remove the obsolete command, handler, capability, tests, and documentation
 rather than relocating them.
 
 ## Current directory disposition
 
-- Root `binding*` modules move into `bindings/`.
-- Root `canvas*` and insert/placement behavior move into `canvas/`.
-- Root `projectDeploy*`, host deploy code, deploy routes, and deploy UI converge under the `deploy`
-  domain and package-level edges.
-- Root auth settings/health/OAuth behavior and host auth implementations converge under `auth` and
-  package-level edges.
+- Root `binding*` modules move into `features/bindings/`.
+- Root `canvas*` and insert/placement behavior move into `features/canvas/`.
+- Root `projectDeploy*`, host deploy code, deploy routes, and deploy UI converge under
+  `features/deploy/`, with host routes remaining in `host/routes/deploy/`.
+- Root auth settings/health/OAuth behavior and host auth implementations converge under
+  `features/auth/`, with host routes remaining in `host/routes/auth/`.
 - Root external API contracts/model code, host API services, routes, and UI converge under
-  `external-apis` and package-level edges.
-- Root media authoring code, host media implementations, and media UI converge under `media` and
-  package-level edges.
-- Root module admin code and host module integration converge under `modules` and package-level
-  edges.
-- Root project/workspace models, current app project screens, hooks, project store/generation
-  operations, and matching adapters converge under `projects`, `templates`, or `workspace` according
-  to actual ownership.
-- Root secret API/usage/response behavior, host secret implementations, routes, and UI converge
-  under `secrets` and package-level edges.
-- Route and admin-route behavior moves under `routes`.
+  `features/external-apis/`, with host routes remaining in `host/routes/external-apis/`.
+- Root media authoring code, host media implementations, and media UI converge under
+  `features/media/`.
+- Root module admin code and host module integration converge under `features/modules/`.
+- Root project/workspace models, project screens, hooks, project store/generation operations, and
+  matching adapters converge under `features/projects/`, `features/templates/`, or
+  `features/workspace/` according to actual ownership.
+- Root secret API/usage/response behavior and host secret implementations converge under
+  `features/secrets/`, with host routes remaining in `host/routes/secrets/`.
+- Route and admin-route policy moves under `features/routes/`; the corresponding host adapters stay
+  in `host/routes/`.
 - Selection, measurement, stationary selection, and canvas interaction behavior must be separated
-  between `selection` and `canvas` by actual invariant ownership.
-- The current generic `core/` directory disappears; each file moves to its owning domain or package
-  edge.
+  between `features/selection/` and `features/canvas/` by actual invariant ownership.
+- The current generic `core/` directory disappears; each file moves to its owning feature role or
+  package edge.
 - The current generic `runtime/` directory is reviewed symbol by symbol. Shared runtime behavior
-  moves to `@ankhorage/runtime`; Studio-specific application integration moves to `app/` or its
-  owning domain.
-- Feature-specific UI moves beside its owning domain. Only package-wide UI composition remains in
-  `app/`.
+  moves to `@ankhorage/runtime`; Studio-specific integration becomes a feature-local adapter.
+- Feature-specific UI becomes generated-app code under `apps/`; it is never rehomed in a generic
+  Studio UI directory.
 - Host smoke and acceptance infrastructure moves outside production source to `test/`.
 
+## External package integrations
+
+An Ankhorage or third-party package is connected in the owning feature, not in a global
+`platform/` directory. For example:
+
+```text
+src/features/templates/
+  ports/
+    templateCatalogPort.ts
+  adapters/
+    createAnkhorageTemplatesAdapter.ts
+```
+
+The port states the capability that Templates requires. The adapter imports
+`@ankhorage/templates`, translates its API, and implements that port. The composition root chooses
+the adapter. Do not duplicate an adapter in `host/`, `cli/`, or another feature.
+
 ## Utility gates
 
 The existing own-property helpers explicitly marked for Utility extraction should move through

package/dist/tools/skills/assets/zora-designer/SKILL.md

@@ -1,29 +1,33 @@
 ---
 name: zora-designer
 description: >
-  Design one application screen or an ordered screen series, audit a URL or supplied image
-  evidence, and author an Ankhorage Templates manifest or starter using installed ZORA metadata
-  and theme APIs. Use for category-driven design decisions, design audits and scoring, visual
-  reconstruction with ZORA elements, or template creation. Do not use for illustration-only work.
+  Configure an owner-backed application design, generate one screen or a coherent screen series,
+  audit supplied evidence, and author portable Ankhorage templates. Use for category-driven design
+  decisions, ZORA screen generation, visual audits, or template creation.
 ---
 
 # ZORA Designer
 
-Design, audit, and author through the target repository's released owner APIs. Keep
-`zora-designer.md` as review evidence; the application manifest and owner contracts remain runtime
-authority.
+Design, audit, and author through the target repository's released owner APIs. The complete
+`AppManifest` is runtime authority; `zora-designer.md` and generated screen images are design
+evidence.
 
 ## Route the request
 
-- `interactive`: resolve a design configuration without silently creating code or images.
-- `screen`: design one screen and, when requested, produce a concept image or implementation.
-- `screens`: design a coherent ordered series with shared navigation, state, and tokens.
-- `audit`: evaluate a URL, one supplied image, or an ordered image series with explicit evidence.
-- `template`: compose a canonical `AppManifest`; in Templates, scaffold the normal starter source
-  and registry entry.
-
-Natural language is enough. Ask only when an unresolved choice would materially change the output.
-Read [workflow.md](references/workflow.md) for the ordered process and capability gates.
+- `interactive`: run the progressive configuration conversation in
+  [workflow.md](references/workflow.md). Do not create code or images before confirmation.
+- `screen`: resolve the configuration, then read [screens.md](references/screens.md) and design one
+  screen.
+- `screens`: resolve the configuration, then read [screens.md](references/screens.md) and design an
+  ordered series with shared navigation, state, geometry, and tokens.
+- `audit`: read [audit.md](references/audit.md) and evaluate supplied image or runtime evidence.
+- `template`: resolve the configuration and screen model, then author one portable template through
+  the workflow below.
+
+Natural language is enough. Treat short replies as answers to the current question, not permission
+to infer later decisions. A reply such as “go on” advances to the next unresolved decision. Only an
+explicit request such as “accept all recommended values” resolves the remaining recommendations at
+once.
 
 ## Start with the owners
 
@@ -33,57 +37,60 @@ From the target repository, run:
 bun .agents/skills/zora-designer/scripts/owner-api.mjs inspect
 ```
 
-The helper loads public exports from installed `@ankhorage/templates`, `@ankhorage/zora/theme`, and
-`@ankhorage/zora/metadata`. If it reports a missing or outdated owner, update the released package
-through the repository's normal dependency workflow. Never copy a catalog, token inventory, color
-algorithm, theme compiler, component schema, or manifest implementation into this skill.
-
-Use owner terminology verbatim: `GeneratedColorRole`, `ThemeTokens.colors`, `ThemeSemantics`, and
-`SemanticColorToken`. Do not introduce aliases or naming cleanup here.
+Use its installed owner output for categories, recommendations, harmonies, tone pairs, navigation
+types, ZORA elements, events, recipes, and version provenance. Never copy owner catalogs, component
+schemas, token inventories, color algorithms, action types, or manifest implementations into this
+skill.
 
-## Preserve decisions and evidence
+Compile chosen values with the same helper before composing screens. Inspect both computed modes,
+including their resolved Surface themes and all owner diagnostics. Never hand-calculate a value the
+owner exposes.
 
-Resolve values in this order: current request, current session, verified project state, confirmed
-existing brief target, category preset, then safe global default. Record an origin for each value.
-Keep target design separate from observed runtime state and report drift rather than overwriting one
-with the other.
+## Preserve the complete UX
 
-For scoring, evidence limits, release gates, and finding rules, read
-[audit.md](references/audit.md). For deterministic `zora-designer.md` shape and serialization, read
-[artifact.md](references/artifact.md).
+For every screen region, prefer the exact semantic ZORA element supported by current metadata.
+Visual resemblance alone is insufficient. If no exact element exists, preserve the requested UX
+with an obvious supported placeholder such as a secondary-surface `Box`, and record the capability
+gap. Do not invent props, application components, or successful behavior.
 
-## Compose only supported ZORA elements
+Bind every interaction expressible by installed Contracts and ZORA event metadata. Leave an
+unsupported interaction visibly present and explicitly unbound without blocking unrelated design
+work. Release validation still decides whether the complete manifest is shippable.
 
-Inspect `ZORA_COMPONENT_META` and `ZORA_THEME_RECIPE_META`. Map a source region only when the
-element's semantic responsibility, structure, states/interactions, accessibility contract, props,
-events, and data requirements fit. Visual resemblance alone is insufficient.
+## Template output
 
-If no exact element fits:
+A Templates repository template is exactly one portable unit:
 
-1. use the metadata-backed `MissingElement` draft node at that location;
-2. record the evidence, warning, requested capability, and application blocker;
-3. create or link a ZORA owner issue;
-4. stop release application until a released real element replaces it.
+```text
+src/templates/categories/{appCategory}/{slug}/
+  createAppManifest.ts
+  assets/
+    screens/
+    images/
+```
 
-Never disguise the gap with a generic container, invented prop, or custom application workaround.
+`createAppManifest.ts` default-exports a function returning the complete `AppManifest`.
+`assets/screens/` contains design evidence only. Runtime media uses real application image regions
+under `assets/images/`; rebuild text, controls, icons, surfaces, and layout with ZORA.
 
-## Capability truthfulness
+Scaffold only a reviewed, release-valid manifest:
 
-- Concept image output requires an available image-generation capability.
-- URL intake and authoritative runtime screenshots require a browser/runtime capture capability.
-- Image audits require the supplied original image or ordered series.
+```text
+bun .agents/skills/zora-designer/scripts/scaffold-template.mjs scaffold-input.json
+```
 
-When a required capability or source is unavailable, report that deliverable or evidence scope as
-blocked. Do not simulate an image, browser observation, or runtime proof. Clearly distinguish
-generated concept images from authoritative runtime captures.
+The helper creates the template directory and regenerates discovery from the filesystem. Do not add
+category registries, seed definitions, fallback templates, compatibility paths, or per-template
+barrels.
 
 ## Validate before handoff
 
-- Compile the category design and both theme modes through installed owner APIs.
-- Validate manifest composition and preserve every owner diagnostic.
-- Confirm every manifest node and recipe against current ZORA metadata.
-- Run deterministic audit arithmetic when an audit is in scope.
-- Keep screenshot-only behavior `not-assessable`.
-- Require a ready application gate before release; a score never overrides a blocker.
-- Update `zora-designer.md` and report target/runtime drift, unsupported capabilities, and owner
-  issues.
+- confirm the interactive decision sequence completed or the user explicitly accepted remaining
+  recommendations;
+- compile light and dark independently through installed owner APIs;
+- validate selected ZORA nodes, props, events, actions, and complete manifest contracts;
+- run the screen composition gate from [screens.md](references/screens.md) before returning screen
+  output;
+- keep unsupported interactions and capability gaps explicit;
+- keep concept screens separate from runtime assets;
+- for deterministic artifact shape, read [artifact.md](references/artifact.md).

package/dist/tools/skills/assets/zora-designer/references/artifact.md

@@ -67,8 +67,10 @@ Aggregate validation in this order: blocker, failure, not run, pass with non-blo
 pass. Resolve the application gate separately. A runtime blocker affects aggregate status only when
 runtime application is in the requested scope.
 
-Every unresolved `MissingElement` records a blocker, owner issue link when one exists, and the
-condition for replacing it with a released real ZORA element.
+Every capability that lacks an exact metadata-supported ZORA element records a non-blocking
+capability gap and uses a visible `Box` placeholder in the concept composition. An owner diagnostic
+with `severity: error` is a blocker. Record an owner issue link when one exists and the condition
+for replacing the placeholder with a released real ZORA element.
 
 ## Deterministic audit fields
 
@@ -89,5 +91,5 @@ state that it was not persisted.
 
 Before returning, confirm the artifact matches the requested mode, every resolved value has an
 origin, owner identifiers were inspected, exact measurements came from tools, invisible behavior
-was not passed from screenshots, gaps block application, and the manifest remains canonical runtime
-authority.
+was not passed from screenshots, owner errors block release, capability gaps are explicit, and the
+manifest remains canonical runtime authority.

package/dist/tools/skills/assets/zora-designer/references/screens.md

@@ -0,0 +1,90 @@
+# Screen and Screen-Series Design
+
+Read this reference for `screen` and `screens` after the interactive configuration is confirmed.
+Generated images are concept evidence; the manifest and ZORA metadata remain implementation
+authority.
+
+## Preconditions
+
+Do not generate or implement a screen until these are resolved:
+
+- audience and primary task;
+- platform, input modes, theme coverage, and an explicit target viewport or responsive range;
+- primary color, harmony, per-mode tone pairs, typography/profile, and compiled owner themes;
+- ordered screen list with one purpose and primary action per screen;
+- navigator type, route topology, and back/cancel behavior.
+
+If the user supplies only `mobile`, recommend a neutral 390 by 844 logical-point portrait concept
+viewport. Ask about iOS- or Android-specific chrome only when it changes the requested result.
+
+## Compose the series before rendering
+
+For every screen record:
+
+1. purpose, primary task, primary action, and success outcome;
+2. content hierarchy and exact visible copy;
+3. default plus relevant loading, empty, partial, error, offline, disabled, pressed, selected, and
+   focus states;
+4. route relationship and continuity of selected item, filters, progress, drafts, or other state;
+5. exact metadata-backed ZORA elements, supported events/actions, data needs, and capability gaps;
+6. safe areas, keyboard/overlay behavior, scroll ownership, and narrow/wide behavior;
+7. real image content that must become an application asset rather than screenshot UI.
+
+Create one shared shell specification for a series: viewport, safe areas, gutters, header geometry,
+navigation geometry, surface treatment, type roles, icon family, content density, and state styling.
+Reuse it unchanged unless a screen has a documented immersive or modal exception.
+
+## Mobile geometry and typography gate
+
+Use compiled Surface/ZORA tokens when they define these values. Where the owner leaves a design-
+brief decision open, use these starting constraints and record them rather than asking an image
+model to improvise:
+
+- 16–24 logical-point horizontal gutters and preserved top/bottom safe areas;
+- at least 44 by 44 pt touch bounds, or the stricter target-platform convention;
+- screen title uses the semantic `h1` role, normally near 32/40 on mobile, one line when practical
+  and never more than two; reserve `display` for splash, onboarding, or genuine marketing moments;
+- section titles use `h2`/`h3`; body content normally starts near 16/24; metadata never becomes tiny
+  merely to fit more content;
+- prose measures approximately 45–75 characters per line, with reading surfaces optimized near the
+  comfortable middle of that range;
+- bottom navigation uses one stable height, label baseline, icon family, selected treatment, and
+  safe-area inset across the series;
+- a screen must expose its purpose, primary content, and primary action without competing giant
+  headings or decorative elements.
+
+Inspect the skill-owned design rules before rendering:
+
+```text
+bun .agents/skills/zora-designer/scripts/audit.mjs catalog
+```
+
+Apply every relevant `generation` rule from that catalog. The rubric belongs to this skill; owner
+catalogs and design-system algorithms do not.
+
+## Concept-image specification
+
+Generate one image per distinct screen or state. Every prompt must include:
+
+- exact logical viewport and portrait/landscape orientation;
+- shared shell and active navigator item;
+- resolved owner palette and type-role sizes, not only mood adjectives;
+- exact screen title, copy that must be legible, hierarchy, components, and primary action;
+- content quantity that fits the viewport at the declared type scale;
+- invariants shared with the other screens;
+- prohibitions against device frames, presentation boards, watermarks, illegible labels, invented
+  tabs, and oversized marketing typography on ordinary application screens.
+
+For a series, keep the resolved configuration and shell verbatim across prompts. Do not generate a
+single contact sheet as a substitute for individual screens unless the user explicitly requests one.
+
+## Review and iterate
+
+Inspect each output at its original dimensions. Reject and regenerate a screen when its title,
+navigation, copy, safe areas, hierarchy, component semantics, or geometry diverges from the brief.
+Use one targeted correction per iteration. Review the full ordered series together for shared shell,
+type scale, navigation, color allocation, state continuity, and visual rhythm.
+
+A visual review can validate visible composition only. It cannot prove runtime actions,
+accessibility semantics, focus order, text scaling, or responsive behavior; record those as
+not-assessable until implementation evidence exists.