# First draft design plan ## Easy-win extension Extend the approved compact transactional system to six team/access notifications, two report-generation outcomes and two product-import outcomes. Use the existing navy/yellow palette, system type, 16px body text, 14px supporting copy, 96px proportional logo and Built-only footer. Preserve light/dark styles and the visible sidebar/footer behavior. Invitations lead with the business and exact relationship (collaborator versus accountant) and one accept action. Accepted/role/payroll notices are concise status messages with no invented button or role list. Report messages use a grouped details table for business, report title and date range; only completion has the existing report action and PDF instruction. Import messages use a count summary distinguishing processed, newly created and submitted items; failure explicitly says the counts are progress before the issue. Review removed proposed success badges, decorative handshake images and generic “View details” buttons. These would add visual noise or imply destinations the application does not supply. Failure copy retains retry/support instructions without invented failure reasons, processing guarantees or automatic-retry claims. All meaningful values remain visible without browser-only disclosure controls. Keep import outcome types separate even though they share InfoMail. Their structured design values come from ItemRepository callback data; the current Mailable only accepts title and a prebuilt body. Document a deliberate integration adapter at that caller, never runtime parsing of arbitrary HTML or an assumed global replacement of emails.info. CRM imports and externally authored campaigns stay excluded. ## Account batch extension Apply the existing Quiet Clarity system to five additional account types: welcome, verification, password reset, two-factor code and disable-two-factor request. Together with the existing sign-in alert, these form the first feature batch. Keep the invoice draft separately accessible. Do not redesign legacy duplicates, external CRM campaigns or team-access notices in this batch. Use one prominent dashboard action in the welcome; app-store and website destinations are secondary text links. Verification and security requests use one accurate action with a visible fallback link. Password reset preserves the three steps inside the email. The verification-code email uses a readable code panel, retains leading zeros and has no fabricated action button. Five-minute copy is fixed only where the source states it; verification and sign-in receive no invented expiry. Review against the brief removed a proposed generic “secure your account” label above each heading: it duplicated the heading and blurred different actions. Each email now leads with its own purpose. The original navy/yellow logo remains on its existing white backing in dark mode. Use the established table shell, readable details, system fonts and dark palette rather than a new visual theme per email. The rendering module continues to return complete HTML. Account content and text alternatives share a small internal module; fixture data and portable token data use the same rendering interface. The workspace reads all seven types from its manifest, with accounts grouped first. Desktop navigation can scroll independently while its footer remains available; compact navigation on phones avoids a tall seven-item header. Initial draft scope: invoice notification and new sign-in alert. The user approved Built navy `#0D2E57`, yellow `#F9E251`, and Built-led styling. Keep `invoice->invoice_color` in the integration contract, reserved for a later secondary treatment. Work lives in built-email-redesign beside simple-api-postgresql. ## Visual system | Token | Value | Role | | --- | --- | --- | | Built navy | `#0D2E57` | Primary action, headings, selected email | | Built yellow | `#F9E251` | Logo accent and small selection indicator; never small white-on-yellow text | | Paper | `#FFFFFF` | Email and workspace surfaces | | Canvas | `#F8FAFC` | Quiet email background and preview stage | | Divider | `#E2E8F0` | Table rules and card edges | | Ink | `#334155` | Body copy; supporting copy must remain readable | The first two colors are user-confirmed, supported by the actual Built wordmark. White and the canvas follow existing mail/SASS sources; divider and ink are proposed accessibility-conscious neutrals. Typography uses Segoe UI, Arial and system sans fallbacks. No remote font requests. Email headings 28px, body 16px/25px, detail labels 13px, invoice amount 34px; mobile headings 25px and amount 30px. Workspace headings use a restrained 24px scale so the email remains the main object. ## Layout exploration and review The workspace asks: which arrangement makes reviewing email content and states easiest? Three optional prototype layouts share the actual two email types, accessed with `?prototype=1&variant=studio|review|focus`. They change workspace structure, never the sendable HTML. ```text Studio (default) Review Focus sidebar | context sidebar | context compact sidebar | context | controls | preview | notes | controls | email | | | wide preview | notes | notes below ``` All keep the required email sidebar, selected state, viewport controls and download links. A floating keyboard-accessible prototype switcher exists only when prototype=1. It is an isolated design artifact, not a Laravel route. Open index.html directly; no server or framework is needed. The first sketch used a dark navigation rail and a large amount hero. Review against the brief removed the dark rail and hero treatment: the brand wordmark, financial summary, merchant identity and security details carry the identity. Amount is prominent inside the invoice summary, with no decorative growth statistics, gradients, status badges or unsupported payment claims. Cards have a purpose: one email surface, one grouped summary. Details use table rules rather than many separate cards. Headings and the logo are left aligned; the footer is centered. ## Email hierarchy ```text Built logo Built logo Invoice from merchant New sign-in detected Invoice number Hello first name + context Amount / due date Device / IP / country / city View invoice / view & pay Unrecognized sign-in instruction Optional merchant message Reset your password PDF attachment instruction Visible fallback reset link Merchant sign-off Built sign-off Centered Built footer Centered Built footer ``` Both emails prioritize one action. Invoice links open invoice details with payment options when can_pay is true; they are not represented as direct checkout links. The security action opens the existing password-reset workflow. No deadline or timestamp is invented. Merchant messages remain inside the email. Unknown geolocation and optional flags are explicit states. ## Code shape One rendering module exposes `renderEmail(type, values, options)` and returns a complete HTML string. This is the seam between fixture/placeholder data and sendable markup. The two real adapters are populated fictional data and portable token data. Shared table layout, inline style rules, escaping and URL checks stay within that implementation. Optional sections use explicit options; they never accept arbitrary HTML strings. The build command writes static documents plus a workspace manifest. The workspace itself consumes the manifest, so switching email or state cannot diverge from the exported populated previews. The prototype skill's branch/issue capture workflow is deferred: this standalone folder is outside the application Git tree, the user has not selected a winning workspace variant, and no issue or commit was requested. The design decision and source remain here for the next refinement pass. The brief's finished-draft validation requirements take precedence over the skill's generic instruction to skip polish and tests. ## Approved shared refinement The user approved activation-first welcome, transactional security voice/footer and compact security layouts. Welcome/invoice retain their larger header and product footer. Security uses a 96px logo, 20px logo-to-heading gap, 14px paragraph spacing, 28px/32px desktop card padding and 22px mobile top/horizontal padding. Body text stays 16px with 25px line height. Supporting security text uses 14px with 22px line height. The same original PNG and dark white backing remain. Reset action and expiry are grouped before the retained steps. Every source instruction, token and destination remains mapped.