Handoff · 2 of 4 · states

Status system and component states

Every badge, banner and control here uses the same classes and icons as the prototype. Hover, pressed and focus are shown as forced states that copy the real :hover, :active and :focus-visible rules. Status never relies on colour alone: each one has its own icon and label.

Matches prototype build

Request lifecycle

Draft → Submitted → Needs your input → Ready to start → In progress → Ready for review → Changes requested → Completed. Fill colour shows who acts: amber = the client, accent = Weblerr is working, green = done.

StatusWhat it meansWho actsClient’s next actionCan move to
{{r.label}}{{r.explain}}{{r.who}}{{r.next}}{{r.to}}
On hold · In progressMarker, not a status: a request on a paused project keeps its last status underneath. Shown wherever the request appears, so paused work never reads as live.Weblerr (resume review)Request to resume the projectPrevious status after resume
Dates on completed requests. When a request is completed, the context panel shows Completed · Mon 9 Nov (the approval date) instead of “Estimate”. If an estimate had been agreed, it stays visible as Original estimate, both in the panel and in the scope summary, for reference only.

Website brief (project level)

A website brief isn’t a request and never enters the queue. It lives on its project. Confirming its scope creates milestone requests, and each milestone then follows the request lifecycle above.

Brief statusWhat it meansWho actsWhere the client sees it
DraftAutosaved on the project. Only the client sees it.ClientProject page; “Also needs you” on Overview
In reviewSubmitted. Weblerr is confirming the website scope and planning milestones.WeblerrProject page; note on the Work queue
Needs your inputWeblerr asked questions. The client updates the brief and resubmits it.ClientProject page with questions; “Also needs you”
ConfirmedScope agreed. The brief stays read-only on the project and lists the milestones created from it.No oneProject page; each milestone’s “Milestone details” links back

Projects and billing

{{p.label}}
Project status: Planning, Active, Paused, Completed. A paused project keeps its files, feedback and history. To resume, the client sends a request and Weblerr reviews the remaining scope and refreshes the estimate.
Subscription activePayment needs attention
Billing is a separate axis and never changes request or project status. While payment needs attention, new work can’t start and history stays readable. Open policy What happens to work already in progress is not defined.

Switch request

No switchNothing in production: the client can change mode after a confirmation dialog. Once work starts, a mode change is only possible through a switch request.
Pending reviewSent by the client. Nothing pauses and nothing activates. The client can withdraw it until Weblerr applies it. Settings links to it and can’t bypass it.
Approved and appliedWeblerr confirmed the stopping point and estimate changes. Current work is paused with its history and the target takes the one slot.
WithdrawnThe client cancelled it before it was applied. Work doesn’t change.

Work slot (one per workspace)

Slot stateWebsite modePage mode
OccupiedOne request or milestone of the focus website is in progress, in review or in revisions.One page request is in progress, in review or in revisions.
Held, nothing in productionThe focus website keeps the slot between requests until the client completes the website or a switch is approved.Not applicable
AvailableAfter explicit website completion. The client then picks the next website or Page mode.After a page is approved. The next page can be for any website.
Auto-start (off by default)Only reviewed, ready requests inside the focus website.The next reviewed, ready page from any website.

Buttons and links

DefaultHoverPressedFocus (keyboard)Disabled Primary Secondary GhostNo pressed style; uses the same hover fillNot used Icon buttonMoves down 1 px Link / danger linkNo pressed styleNot used

Each decision has one primary action. Minimum height is 44 px, or 36 px for compact buttons in dense desktop rows. On mobile, icon buttons grow to 44 × 40 px. Transitions take 180 ms; the pressed state moves down 1 px over 90 ms.

Fields and validation

A few things are needed before you can submit
  • Add a project name
  • Describe what you’d like us to build
Passwords don’t match.

Validation as built: an error summary at the top of the form section, plus inline error text for account and dialog forms. Field borders don’t turn red. Suggested Add field-level error borders and aria-describedby when this is built.

Choice cards, toggle and steps

Website mode CurrentSettings: read-only display
OffOn

The toggle always shows On/Off as text. Form steps are pills; on mobile only the current step shows its label, and the others keep an aria-label. Sections can be visited in any order.

Uploads

lookbook-spring.pdf
Uploading 62% · 4.2 MB
bouquets-hero.jpg
Upload failed · 6.8 MB
store-photos.zip
Uploaded · 48 MB

Uploads are simulated. The progress bar animates width over 160 ms steps.

Banners

{{b.t}}
{{b.d}}

Queue rows

{{r.i}}
{{r.title}}
{{r.sub}}
{{r.label}}{{r.why}}

Every queued item says why it can or can’t start. Items are never skipped silently.

Delivery versions

Latest version first. Each version keeps its own summary, files, attention items and feedback. Only the latest version can be approved, and silence never approves.

Mobile bottom navigation

Shown at 360 px wide, the narrowest supported width. Every item keeps a visible label (12/16 px, 600; current item 700 on an accent pill). The bar is 58 px tall and hidden only while a brief form is open. Files, Billing and Settings are under Account.

Toast

Switch request sent. Nothing changes until it’s approved.

Confirms an action and dismisses itself after 4.2 s. On mobile it sits above the bottom nav. Toasts are left out of the clean exports.

Dialogs vs mobile sheets

Approve v1?

Homepage design and Elementor build

Approving completes this request. Its versions, files and feedback stay saved.

  • dh icon, title, context
  • db consequences, in plain words
  • df secondary action left, primary right
  • Desktop and tablet: centred, max 580 px, 220 ms in / 160 ms out

Approve v1?

Body scrolls on short screens…
  • 390 / 360: bottom sheet, max height = screen − 16 px
  • Body scrolls inside the sheet; overscroll-behavior: contain
  • Action footer is sticky: the primary action and “Not yet” / Cancel stay visible
  • Tested at 844, 667 and 568 px (390 wide) and 780, 640 and 560 px (360 wide)
  • 240 ms slide in / 170 ms out