Dwellmark prototype route map

Primary seeded product experience with no login wall.

In-product orientation panel with persona buttons, route links, readiness, and review checklist state.

External UX review brief with guardrails, scorecard, acceptance kit, runbook, and return template.

Crawlable index of every public screen alias, persona state, journey start, and seeded API.

Route-style URL for a single prototype screen when hash anchors are less reliable for a design tool.

Route-style URL for opening a seeded persona state directly.

Route-style URL for opening a specific screen under a specific seeded persona.

Machine-readable handoff package with personas, routes, journeys, URL guide, acceptance kit, and boundaries.

Text-focused handoff brief for tools that prefer Markdown over rendered pages or JSON.

Concise LLM-readable product context, boundaries, handoff artifacts, public APIs, and assumptions to avoid.

Sitemap and robots policy help external tools discover public handoff URLs while avoiding private API surfaces.

The prototype, handoff brief, route map, aliases, Markdown, llms.txt, sitemap, and public demo APIs are reachable without auth.

Personas, route aliases, journeys, viewport matrix, prompt pack, packet index, decision register, runbook, and response template cover the UX pass.

The handoff package preserves residency-defense positioning, seeded data, no exact coordinates, Act 60 as one module, and no tax/legal advice.

The package gives designers concrete routes, personas, expected outputs, done criteria, and return fields.

The product workflows are complete enough for design review, but visual hierarchy, density, typography, and responsive polish should be refined by the design pass.

Auth, real uploads, private storage, billing, advisor invites, and production role gates remain intentionally deferred until UX approval.

The public app shell, design handoff brief, route map, screen aliases, persona aliases, sitemap, robots policy, Markdown brief, llms.txt, and JSON manifest are public seeded routes.

The prototype includes general domicile, Florida move, former-resident documentation, Act 60, multi-state exposure, business presence, advisor review, and audit packet workflows.

Handoff guardrails, acceptance kit, smoke tests, and manifest boundaries all state seeded data only, no real evidence files, no exact coordinates, and no service-role values.

Stable screen aliases and journey scripts cover owner command center, ledger review, evidence requests, mobile capture with iOS device QA, domicile workbench, business presence, advisor resolution, claim review, packet command, and packet integrity flows.

The URL guide, route map, screen aliases, persona aliases, persona plus screen query pattern, Markdown brief, llms.txt, and JSON manifest expose canonical relative and absolute URLs.

The mobile capture center and demo mobile API surface the iOS device QA summary, checklist rows, physical-device signoff status, and remaining next action without real uploads or exact coordinates.

The persona catalog and route aliases expose 10 seeded states with deep links, absolute URLs, and route-map cards for direct design review.

The runbook, prompt pack, feedback worksheet, response template, packet index, and acceptance kit define review order, expected outputs, return fields, severity, and preserved boundaries.

The decision register, readiness scorecard, acceptance kit, guardrails, and llms.txt all preserve public prototype mode and explicitly defer auth/real-data work.

apps/web/scripts/smoke-web.mjs fetches the built Next app and asserts public handoff content, canonical URLs, forbidden secret strings, and seeded API responses.

apps/web/scripts/verify-workflows.mjs checks manifest fields, page sections, Markdown and llms.txt sections, smoke assertions, and stable route patterns.

scripts/verify-feature-map.mjs and scripts/verify-product-scope.mjs now include the response template, scorecard, acceptance kit, URL guide, coverage matrix, and QA matrix.

The viewport matrix lists desktop owner command center, tablet advisor review, mobile capture/privacy with iOS device QA, and packet-builder review states with stable URLs.

The mobile capture center renders Device QA, iOS device signoff checklist, and iOS device QA next action from seeded readiness data.

The component inventory and review rubric identify reusable UI primitives and what product boundaries must be preserved.

The decision register, scorecard, coverage matrix, acceptance kit, and smoke secret checks all preserve seeded public mode.

Decide whether a first-time owner can understand their residency risk, weak days, evidence confidence, and packet readiness in one scan.

Walk the advisor from open issue to comment, evidence request, claim decision, and packet blocker review.

Review mobile capture, iOS device QA signoff, evidence-source consent, exact-location redaction, advisor permission, and retention language on a small screen.

Judge whether the audit packet feels like the hero workflow across manifest sections, blockers, privacy choices, integrity, and export history.

Confirm the product reads as broad residency defense across domicile, Florida, former-resident, Act 60, multi-state, and business exposure tracks.

Normalize repeated cards, status pills, ledgers, route links, privacy controls, and packet artifacts into reusable design-system guidance.

All handoff routes can be opened from a clean browser session without login, private cookies, or real user data.

The handoff includes clean, weak-evidence, advisor-review, packet-ready, business, Act 60, former Act 60, Florida, privacy, and packet-builder states.

Owner, advisor, evidence, privacy, business, mobile capture, iOS device QA, annual review, and packet export flows have stable review routes.

The prototype stays in seeded-data mode, avoids tax/legal advice, avoids exact coordinates, and keeps Act 60 as one supported track.

The engineering team can apply findings when they include route, persona, viewport, severity, recommendation, and boundary impact.

Summarize whether the public prototype is ready for visual refinement, what changed in the recommended UX direction, and what still blocks handoff.

Return findings tied to stable public routes, persona states, and viewport context so engineering can apply changes without guessing.

Identify language that should change or stay fixed, especially around residency defense, Act 60 as one module, privacy, advisor review, and tax/legal boundaries.

Document reusable patterns for cards, ledgers, status pills, privacy controls, route links, packet artifacts, and dense operational panels.

Report desktop, tablet, and mobile review results against the viewport matrix and call out any layout, density, or readability problems.

Confirm the redesign preserves public prototype access, seeded data only, no exact coordinates, no tax/legal advice, and deferred auth or real-data work.

List ideas that belong after UX approval, such as auth, real uploads, private storage, billing, advisor invites, or role-based permissions.

Confirm the product category, public prototype mode, sensitive-data boundary, and review package before redesign work starts.

Notes on product comprehension, missing context, and any boundary questions that must be resolved before visual exploration.

Review first-screen clarity, day counts, weak evidence prompts, proof strategy, and packet-readiness hierarchy.

Desktop and mobile recommendations for owner comprehension, hierarchy, copy, and route sequencing.

Review advisor comments, evidence requests, claim decisions, packet blockers, and export-ready language.

Advisor workflow notes and packet-builder recommendations that preserve the no-advice boundary.

Review mobile capture, iOS device QA signoff, evidence-source consent, exact-location redaction, advisor export permission, and retention language.

Mobile layout notes, device-QA signoff recommendations, privacy copy recommendations, and any small-screen component fixes.

Normalize cards, ledgers, status pills, route links, privacy controls, packet artifacts, and dense operational patterns.

Component inventory notes with reusable patterns, state semantics, and responsive behavior recommendations.

Return design findings in a format engineering can act on after UX approval.

Prioritized findings with route references, viewport notes, copy changes, preserved boundaries, and deferred-auth notes.

Dwellmark is a residency defense and documentation platform, not an Act 60-only product.

Lead with residency defense and packet readiness; keep Act 60 as one supported module inside the track system.

The complete product prototype remains public and no-auth until UX refinement is approved.

Do not add signup walls, private redirects, billing gates, or real upload requirements to the review experience.

Design review uses seeded data only and must not expose real evidence, secrets, exact coordinates, or service-role values.

Keep privacy language explicit and calm; preserve owner-controlled redaction and permissioned advisor access.

The first screen still needs design judgment on hierarchy, density, and where packet readiness should dominate.

Return recommendations for first-viewport hierarchy, metric grouping, weak-day prompts, and packet-readiness emphasis.

The advisor issue queue, claim review, and packet builder need UX review before role-based auth is wired.

Return flow notes for comments, evidence requests, packet blockers, claim decisions, and export-ready states.

Login, real evidence uploads, storage persistence, billing, and role-based production flows come after UX approval.

Do not design around account creation as the first screen; preserve public demo/design mode as a separate surface.

Understand the category, boundaries, public routes, personas, and expected review outputs before changing screens.

A brief notes page confirming the product promise, no-auth review mode, sensitive-data boundaries, and open questions.

Improve category clarity, owner comprehension, dashboard hierarchy, day-count confidence, and packet-readiness scanning.

Annotated desktop and mobile recommendations for the first owner pass, with copy that preserves the legal and privacy boundaries.

Refine advisor issue review, claim decisions, evidence requests, packet blockers, and export-readiness language.

Advisor-review flow notes, packet hierarchy recommendations, and unresolved workflow questions before auth is introduced.

Check capture readiness, iOS device QA signoff, exact-location redaction, evidence-source consent, advisor export permission, and small-screen density.

Mobile layout notes, device-QA signoff recommendations, and privacy wording that avoid real upload, signup, or exact-coordinate assumptions.

Normalize dense operational cards, status pills, ledgers, route links, privacy controls, and packet artifact states.

Component notes covering hierarchy, spacing, responsive behavior, status semantics, and reusable patterns for later implementation.

Return findings in a format that engineering can apply after the design pass without losing product boundaries.

A prioritized list of UX findings, revised route/screen references, viewport notes, copy changes, and preserved-boundary notes.

Lead with residency defense, day tracking, documentation, domicile ties, advisor review, and audit packets.

Make the audit packet feel like the central product object while keeping export readiness factual.

Connect weak days and proof gaps to concrete next evidence requests without sounding punitive.

Keep privacy and device-QA language calm, explicit, and owner-controlled while avoiding exact-location exposure.

Make advisor actions clear while preserving the boundary that Dwellmark provides records and workflows, not legal advice.

Treat Act 60 as one supported residency module inside a broader domicile and day-count defense platform.

Return a proposed desktop and mobile hierarchy for the owner command center that preserves packet readiness as a primary product object.

Final first-screen information architecture before auth and real-data flows are wired.

Redesign the packet path so blockers, manifest sections, integrity checks, and export readiness are visible in one coherent workflow.

Packet-builder structure before production export, signed files, and advisor signoff are made real.

Return the preferred advisor review sequence and any copy/action labels needed for comments, requests, and claim decisions.

Advisor workflow order before permissioned advisor accounts are introduced.

Review the mobile privacy and device-QA path and return copy/layout guidance for owner-controlled capture and redaction.

Small-screen trust language before real mobile capture and private storage are connected.

Review track routing, domicile workflows, former-resident flows, Florida domicile, Act 60, and multi-state exposure as one coherent system.

Track naming and hierarchy before onboarding/auth asks users to choose a path.

Normalize repeated operational UI patterns so the prototype can be redesigned consistently across owner, advisor, packet, and privacy surfaces.

Reusable component guidance before UX changes are implemented across dozens of public prototype sections.

Redesign the public Dwellmark prototype for premium residency defense UX. Preserve no-auth access, seeded data, packet-first workflows, privacy boundaries, advisor-safe language, and Act 60 as one supported module.

Visual hierarchy and responsive layout recommendations for owner, advisor, packet, mobile privacy, iOS device QA, and track-breadth flows.

Critique the Dwellmark public prototype using the intake board, scenario matrix, copy and tone matrix, and response template. Return route-level findings with persona, viewport, severity, recommendation, and boundary impact.

Prioritized UX findings in the design review response template format.

Walk the runbook in order and answer the intake-board questions before commenting on visual polish. Focus on comprehension, advisor usefulness, packet trust, privacy clarity, and product positioning.

Decision notes for the intake board plus route-specific UX blockers.

Review Dwellmark copy for premium, calm, advisor-compatible residency defense language. Preserve packet-first framing, privacy clarity, and Act 60 balance while removing tax-advice or guarantee language.

Current copy, recommended copy, reason, and preserved-boundary notes.

Return accepted design recommendations in implementation-ready shape. Include route, persona, viewport, severity, component impact, copy changes, preserved boundaries, and deferred production work.

Implementation queue suitable for engineering to apply without guessing.

Design tools have public, copy-ready starting points for the rendered brief, prototype route map, Markdown brief, JSON manifest, and LLM guide.

The public prototype covers owner dashboard, day ledger, evidence, domicile, residency tracks, business presence, advisor review, mobile device QA, privacy, and packet workflows.

The handoff package includes prompts, intake questions, response template, copy guardrails, QA matrix, acceptance kit, and launch checklist.

The workflows are ready for design inspection, but visual hierarchy, responsive density, component language, and first-screen comprehension still need human or design-tool judgment.

Auth, real evidence uploads, private Supabase storage, billing, advisor invites, role gates, and production data stay deferred until the UX direction is approved.

The prototype, handoff brief, route map, screen aliases, and persona aliases are public seeded routes with no auth redirect.

JSON, Markdown, sitemap, robots, and llms.txt handoff surfaces expose the same canonical URLs and review boundaries.

Design review covers seeded owner, advisor, packet, business, privacy, Act 60, former Act 60, and Florida domicile states across the full screen inventory.

Owner, advisor, packet export, and business/privacy journeys each have start states, expected outcomes, and route-style review URLs.

Desktop, tablet, and mobile viewport passes, prompt pack entries, and structured worksheet questions are all available from public routes.

The handoff package preserves seeded data, no secrets, no private evidence, no exact coordinates, Act 60 as one module, and no tax/legal advice.

Owner can see risk, weak evidence, next proof requests, and packet impact in one pass.

Advisor can identify open issues, ask for evidence, review claims, and understand export gates.

Reviewer can follow manifest sections, privacy choices, integrity checks, and annual export history.

Reviewer can separate owner/operator facts from personal domicile proof and redacted export controls.

Dashboard hierarchy, dense metrics, weak-day prompts, and first-pass owner comprehension.

Advisor issue queue, comments, request flow, claim decisions, and packet review density.

Mobile capture readiness, iOS device QA signoff, privacy controls, evidence-source consent, and redaction language.

Audit packet builder, command center, integrity lab, annual review, and export-readiness state.

Improve first-time owner comprehension of Dwellmark as a residency defense platform without adding login, billing, or real-data flows.

Make advisor issue review, evidence requests, claim decisions, and packet blockers easier to scan before authenticated advisor flows are added.

Refine mobile capture, iOS device QA signoff, evidence source consent, privacy redaction, and data-control language for small screens.

Make the packet builder, blocker list, integrity checks, and annual export history feel like a premium, trustworthy audit file workflow.

Can a first-time owner understand that Dwellmark is for residency defense, evidence quality, and audit packet readiness within the first screen?

Can an advisor quickly see open issues, request evidence, comment on claims, and understand what blocks packet export?

Do mobile device QA, privacy, exact-location redaction, evidence-source consent, and advisor export controls feel explicit without becoming alarming?

Does the packet builder clearly communicate readiness, blockers, manifest sections, integrity checks, and export history as the hero workflow?

Does Act 60 read as one supported module inside a broader residency-defense product, not as the whole product identity?