# Builder — complete overnight implementation

Execute `C:/ClaudeCode/projects/.mlm-work/max-lvl-website-builder/PLAN.md`, including the workspace audits it adopts, as one complete implementation assignment. Apply the corrections and completion requirements below. The branding direction supplied in my accompanying message belongs to this same run.

## Authorization and finish line

Carry this from the current application through the finished, integrated, tested and packaged candidate. All PLAN workspaces and their adopted audits are in scope. Phases are internal checkpoints within this assignment. Continue after each checkpoint without waiting for another prompt, approval of an intermediate layout, or a request to start the next phase. Choose sound solutions for routine product and implementation decisions, record consequential assumptions briefly, and keep working.

Substantial rewrites are authorized wherever the existing code or architecture holds back the requested experience. Change or replace layouts, components, state management, models, schemas, adapters, writers, queries and tests together where needed. Preserve existing user work and the meaning of real data; migrate affected callers and stored state instead of freezing the old implementation. A feature being present in some form does not establish that it exists in the form I want.

Build the interfaces and their supporting machinery as one effort. Missing data models, declarations or write paths are implementation work inside this assignment. They are not reasons to postpone the interface, reduce its ambition, or return the work to me. Develop independent workspaces in parallel where useful. Connect and verify the complete paths before calling them finished. The entire application must feel like distinct, capable creative tools working smoothly on one project.

Keep a concise durable progress record in the candidate with completed outcomes, active work, relevant decisions and remaining checks. Update it at meaningful checkpoints. If context is compacted, resume the same assignment from that record. Use available parallel agents for independent implementation and review, coordinate shared files, and integrate their work. Do not finish the response with a plan, an offer to continue, or only the first successful phase.

Use the candidate and fixture locations in PLAN. Preserve unrelated local changes, keep development servers off the real QMM checkout, and finish with a rebuilt candidate that I can open and use. A commit or push that triggers a site deployment remains a deployment; the overnight implementation request does not override PLAN's separately reserved shared-database migration or production actions. Prepare and verify those changes without holding up the rest of the application. Use existing authorized access for integration verification. If a required external credential, provider approval or separately reserved live action is actually unavailable, finish every unblocked part, test the integration at the available boundary, and identify the precise unverified effect. Missing implementation, hard work, and ordinary design decisions are not external blockers.

Rebuilding and verifying the local candidate package under its `release/win-unpacked` directory is explicitly part of this assignment. Use the isolated verification profile, registry and fixture runtime so testing preserves my ordinary preferences, project registry and production Builder. Manage only this run's candidate and fixture processes when rebuilding. The deliverable is the finished candidate, with production promotion handled under its existing authorization boundary.

## Corrections to apply while implementing PLAN

### Distinct tools, shared foundations

Keep the decided shared document canvas with the native site preview. Reuse panel chrome, graph interaction, controls and measurement definitions where they help. Let each workspace choose the arrangement, tools and editing behavior its job needs. The shared inspector must not force every discipline into another catalog-plus-facts screen.

Treat the quoted user outcomes as the test of the design. Exact gutter, header, typography and motion prescriptions are implementation starting points; refine them through the supplied branding direction and the actual application. Design primarily for the full-width 2560 × 1440 desktop experience. Catalogs and tables must use their allocated space before developing unnecessary internal scrollbars. Panel boundaries, resize affordances, focus and selection must be immediately readable. Verify both themes and sensible recovery at smaller window sizes.

Share the presentation of loading, empty and error states, while allowing each workspace to supply its own useful language and actions. Empty Email offers New message; empty Patterns offers New pattern; empty Interactivity offers New pipeline; empty Lists offers New list. Agent assistance is available within those workflows. It does not substitute for them.

### Complete creation and placement

Email must support creating a new reusable message, choosing its purpose and starting layout, composing and rearranging supported content, editing subject/preheader, previewing representative recipient data and variants, saving/reopening, and selecting that message from Automations. Deliver the required identity, content, rendering and write operations together. Cover both nurture and transactional messages described in the audit; a taller catalog and inline copy edits do not finish this tool.

Creative must support create/import → compare → approve → assign an existing or new role/placement → update affected previews → save/reopen → revert. The existing `assets.save` operation only writes an image file and provenance; implement the missing role/source binding and required derived outputs. Make Favicon and Make Social Image must produce and attach usable assets, including when the role did not previously exist. Branding and Creative must show the same current asset and history.

Pattern creation/scaffolding, pipeline creation and element-level Branding Link are already specified in the incorporated audits. Deliver them fully. Every creation tool must work from an empty catalog, rather than requiring an existing object to unlock creation.

### Real viewport dimensions and reliable context

Give Website a compact, visible Width × Height control in CSS pixels, useful desktop/tablet/phone presets, custom sizes, orientation swap, and a separate Fit / 100% display control. Preserve the selected page dimensions when its panel is too small; Fit changes presentation scale without changing responsive breakpoints. Persist the chosen settings per project and implement the planned second viewport, available when the operator opens it.

Distinguish selected object, focused region and the target of Link/Shot/Screen. Make the target apparent. Verify accurate preview editing, context and capture after panel resize, fold, scroll and viewport scaling; do not capture the agent conversation by accident.

### Connected lists, journeys and measurements

QMM has people, tags and audience memberships, but does not yet have the desired first-class list catalog and complete Lists experience. Build New list, independently existing empty lists, editable rules, manual membership, multiple simultaneous memberships, people detail, and automation relationships. Carry existing join/leave and suppression meaning through any necessary migration or rewrite. Scoring should be delivered as planned without requiring an operator to configure a score before creating a list.

Calculator runs do not all collect email. Record anonymous tool activity with the exact entry-tool identity, then connect earlier activity and appropriate memberships when a person identifies themselves. Do not add a forced email gate based on PLAN's mistaken assumption. Keep MYGA, Income Rider and Quote distinct even where they share calculation endpoints or result types.

Journey rules involving "not booked after N days" and inactivity decay require clock-driven evaluation as well as new-event evaluation. Handle repeated events, sequence order/windows, late identity and corrected links without duplicate membership or score inflation. Explain why a membership or score applies, and define historical results at the selected time.

Finish the measurement corrections across the UI and underlying queries together: source environment, time window, counting unit, cohort entry and ordered progression, conversion attribution and revenue allocation. Funnels must not independently count unrelated steps or assign every funnel all revenue. Tracking journeys must honor the selected range. Drill-down rows must explain the summary figures, and equivalent filters must mean the same thing in Reports, Tracking, Funnels and Advertising.

### Working state, graph meaning and readiness

The automation graph must round-trip branch, condition, action, merge and node identity through edit, save, reopen, build and the supported execution path. Expand or replace the current draft/build path where it flattens the graph. A palette item must have an implemented consequence. Verify the planned vocabulary against a defined inventory rather than interpreting "standard ActiveCampaign stuff" as an unlimited vendor feature list.

Preserve drafts, selection and scroll across workspace changes. Direct edits and undo must detect intervening file changes, including agent edits, and avoid silently overwriting unrelated work. Provide useful recovery for failed saves and partial operations without adding a confirmation ritual to ordinary editing.

Separate background preparation from mount and activation. Warm catalogs and expensive preview jobs, deduplicate pending work, refresh from the freshness system, dispose obsolete subscriptions, and recalculate geometry when a workspace becomes visible. Opening another tool should expose useful content and controls promptly, while preserving the work already in progress.

## Completion evidence

Work through all named workspaces and the global shell/Setup/Notes/Documents changes. For each, demonstrate its primary create or inspect workflow, the promised edits/actions, persistence and reopening, relevant undo or recovery, keyboard access, and cross-workspace consequences. Read-only analytical views prove filtering and drill-down; authoring views prove actual authoring. Check empty and populated states, not only a selected fixture object.

Use the packaged candidate tour and relevant gates in PLAN. Inspect the rendered full-width application in both themes and fix visible shortcomings. Retain Website's working behavior throughout. Update tests tied to deliberately replaced structures while preserving meaningful assertions about outcomes; passing old shape checks alone is insufficient. Exercise local records through real application routes and verify authorized real-data reads where available. Clearly distinguish local fixtures, real observations and unavailable live verification.

Finish with all implementable PLAN work integrated and source changes committed. Build the final candidate from that source, then run the applicable packaged checks and inspect the full-width result against that exact executable. If source or package changes afterward, rebuild and repeat affected verification. Report the package location and tested revision, the verification result, and only concrete remaining external dependencies if any. Do not call a placeholder, mock service or disconnected control complete.