EBO — W7 UI Action Discipline

What W7 owns
Which actions and tabs go where, and how every click behaves. The removal of Create-Task (fully gone, not hidden or guarded), the relocation map of every dormant tab and never-used dashboard part into the hamburger, proof that every relocated item still works from inside the menu, tax-number input validation, and the idempotency/feedback sweep of every non-send action button.

What W7 only relies on (owned elsewhere)
W8 owns the hamburger's and the board's visuals (the ☰ icon, its menu styling, animations, design tokens) — W7 fills the menu, W8 draws it. W1 owns every send-triggering button's discipline (Send Emails, negative-followup). W3 owns the Details-panel field schema — W7's tax-number validation lands on top of W3's settled schema (runs after W3 in the DAG). W2 owns touchpoint-history content.

You do → click/action/hover You should see → on-screen result Element changes → copy · look · where What changes underneath → data/state Must NOT happen → bug guard 🕓 Touchpoint history → impact on the card's history (or —) 💡 UX critique + suggestion → genuine critique + concrete improvement (owner: keep/omit)

Owner rulings folded in (ANSWERS_ROUND3, 2026-07-11 — round 3 wins over the handoff) — Q15=A the Create-Task button is removed entirely; everything else stays reachable but dormant. This overrides the W7 handoff's original plan to wrap Create-Task in a click-guard + idempotency key — you can't double-click a button that no longer exists, so that whole work item collapses into a clean removal. Q14 a hamburger menu absorbs all dormant tabs plus anything he basically never uses; the dashboard is reviewed for never-used parts and those relocate too. Q16=A aggressive kill/hide appetite — when in doubt, hide it. Round-2 Q7 (carried into round 3 in spirit): "He uses ONLY the pipeline view. Other tabs must not affect pipeline behavior; do not optimize for them."
Invariants that hold everywhere — English-only operator UI (Hungarian only inside client-facing email copy); relocation ≠ deletion: apart from Create-Task, nothing loses functionality — every relocated tab opens and works from inside the hamburger exactly as it did before; W7 never touches send-triggering buttons (W1's seam) or the Details-panel field schema itself (W3's seam); two items the handoff flagged are already fixed on current main (drawer Save button after close, Regenerate double-fire guard) — W7 verifies them live, it does not rebuild them; nothing here sends anything to a lead.

W7-1 — Create-Task button is gone, everywhere, with no dead ends (happy path / removal)

Who: Mátyás · When: He works the pipeline board as usual. The "＋ Create Task" button used to sit in the action row of cards in most stages (it appears on nine different card layouts today). He never used it — his ruling: remove it, don't hide it, don't guard it. After W7, the button simply does not exist anywhere in the Control Panel.

#	You do	You should see	Element that changes copy · look · where	What changes underneath	Must NOT happen	🕓 Touchpoint history	💡 UX critique + suggestion
1	Mátyás opens a lead card's action row — in any pipeline column (new lead, scheduling, design presented, contract out, paying client, delivery stages)	No "＋ Create Task" button anywhere — the action row shows only the surviving actions (Log Call, Note, Move, Studio buttons where relevant); the row closes up cleanly with no gap or placeholder where the button used to be	Copy: "＋ Create Task" label gone · Look: action row one button shorter, no empty slot · Where: every card layout that used to render it (all nine)	The Create-Task control is deleted from every card template — removed from the interface, not hidden by CSS and not disabled	Must NOT survive on even one card layout (the button renders from nine separate places today — a partial removal that misses one is a fail); must NOT leave a visually empty gap or a greyed-out stub	— (removing the button creates no history; and no future "task created" entries can originate from the dash anymore)	Critique: A removal proven by "I looked at one card" is weak — the button lives on nine distinct card layouts, and history shows partial edits missing sibling render sites. Suggestion: The QA pass must walk one card in every stage that previously showed the button, not a sample — and additionally search the served page for the button's label so a missed layout can't hide in an unopened column.
2	Mátyás double-clicks, mash-clicks, or does anything else on the card where the button used to be	Nothing task-related happens — no "To-do created in Main-Tasks" toast can ever appear again, because nothing in the UI can trigger a task creation from the dash	Copy: the old success toast "＋ To-do created in Main-Tasks" and failure toast "⚠️ to-do creation failed" never appear · Look: — · Where: board	No dash click path reaches the create-task backend anymore; no Main-Tasks row can be created from the Control Panel	Must NOT leave any other link, hint, tooltip, or help text that still points the user toward "create a task" (a reference to a control that no longer exists is a dead end); must NOT accidentally remove any OTHER button in the same action row	—	Critique: The backend endpoint that the button called still exists after a UI-only removal — harmless but it's dead weight, and the handoff's planned idempotency work on it is now moot. Suggestion: Given the Q16=A aggressive-kill appetite, retire the now-unreachable backend endpoint in the same pass (nothing else calls it), so the removal is complete on both sides rather than leaving an orphan API. Owner: keep or leave the endpoint?
3	Mátyás checks the Main-Tasks integration the day after the removal (his real task flows: 📞 Call-lead and Follow-up-due cards)	The task-driven cards on the board still work exactly as before — existing flow, verify unchanged: call and follow-up tasks still appear and complete normally	Copy: unchanged · Look: unchanged · Where: board task cards	Only the manual Create-Task button is removed; the system-generated Main-Tasks integration (call / follow-up task types) is untouched	Must NOT break or degrade the automatic task integration while removing the manual button (they share the same Main-Tasks plumbing — removal must be surgical)	—	—

You do

You should see

Element that changes
copy · look · where

What changes underneath

Must NOT happen

🕓 Touchpoint history

💡 UX critique + suggestion

Mátyás opens a lead card's action row — in any pipeline column (new lead, scheduling, design presented, contract out, paying client, delivery stages)

No "＋ Create Task" button anywhere — the action row shows only the surviving actions (Log Call, Note, Move, Studio buttons where relevant); the row closes up cleanly with no gap or placeholder where the button used to be

Copy: "＋ Create Task" label gone · Look: action row one button shorter, no empty slot · Where: every card layout that used to render it (all nine)

The Create-Task control is deleted from every card template — removed from the interface, not hidden by CSS and not disabled

Must NOT survive on even one card layout (the button renders from nine separate places today — a partial removal that misses one is a fail); must NOT leave a visually empty gap or a greyed-out stub

— (removing the button creates no history; and no future "task created" entries can originate from the dash anymore)

Critique: A removal proven by "I looked at one card" is weak — the button lives on nine distinct card layouts, and history shows partial edits missing sibling render sites.
Suggestion: The QA pass must walk one card in every stage that previously showed the button, not a sample — and additionally search the served page for the button's label so a missed layout can't hide in an unopened column.

Mátyás double-clicks, mash-clicks, or does anything else on the card where the button used to be

Nothing task-related happens — no "To-do created in Main-Tasks" toast can ever appear again, because nothing in the UI can trigger a task creation from the dash

Copy: the old success toast "＋ To-do created in Main-Tasks" and failure toast "⚠️ to-do creation failed" never appear · Look: — · Where: board

No dash click path reaches the create-task backend anymore; no Main-Tasks row can be created from the Control Panel

Must NOT leave any other link, hint, tooltip, or help text that still points the user toward "create a task" (a reference to a control that no longer exists is a dead end); must NOT accidentally remove any OTHER button in the same action row

—

Critique: The backend endpoint that the button called still exists after a UI-only removal — harmless but it's dead weight, and the handoff's planned idempotency work on it is now moot.
Suggestion: Given the Q16=A aggressive-kill appetite, retire the now-unreachable backend endpoint in the same pass (nothing else calls it), so the removal is complete on both sides rather than leaving an orphan API. Owner: keep or leave the endpoint?

Mátyás checks the Main-Tasks integration the day after the removal (his real task flows: 📞 Call-lead and Follow-up-due cards)

The task-driven cards on the board still work exactly as before — existing flow, verify unchanged: call and follow-up tasks still appear and complete normally

Copy: unchanged · Look: unchanged · Where: board task cards

Only the manual Create-Task button is removed; the system-generated Main-Tasks integration (call / follow-up task types) is untouched

Must NOT break or degrade the automatic task integration while removing the manual button (they share the same Main-Tasks plumbing — removal must be surgical)

—

W7-2 — Every dormant tab relocates into the hamburger menu; nothing lost (happy path / relocation map)

Who: Mátyás · When: He opens the dashboard to work — which for him means the pipeline view, full stop. Today the nav already splits into three primary tabs (Focus · Pipeline · Done) plus a "Tools" overflow holding fourteen more (Templates, AI Usage, Health, CRM book, Test drive, Flowchart, Calls classic, Outbox, Lost/nurture, Metrics, Costs, Lead radar, Finances, Journey copy — plus the owner-only Debug). W7 decides what goes where: everything dormant lands inside the single hamburger menu W8 draws. The visuals of the ☰ itself are W8's; the contents and the guarantee that each item still works are W7's.

#	You do	You should see	Element that changes copy · look · where	What changes underneath	Must NOT happen	🕓 Touchpoint history	💡 UX critique + suggestion
1	Mátyás loads the dashboard	The top bar holds only what he actually works in — the pipeline board front and center — plus the ☰ hamburger; every dormant tab (Templates, AI Usage, Health, CRM book, Test drive, Flowchart, Calls classic, Outbox, Lost/nurture, Metrics, Costs, Lead radar, Finances, Journey copy, Debug) now lives inside the hamburger only	Copy: tab names unchanged, just moved · Look: stripped top bar + ☰ (drawn per W8) · Where: dashboard top nav	The nav's split is re-declared: the primary list shrinks to the working surface; everything else is registered as a hamburger item. No tab's underlying page/panel changes — only its entry point	Must NOT delete any tab in the move (relocation ≠ deletion — Create-Task is the ONLY removal in W7); must NOT leave the same tab reachable from two places (old Tools overflow AND the new hamburger — one home each)	—	Critique: The exact top-level survivor set is genuinely ambiguous: the ruling says "he uses ONLY the pipeline view", but W8's EBO left the Pipeline/Today/Calls/Outbox split as its open decision D6 — two EBOs must not answer it differently. Suggestion: W7 defers the survivor set to W8's D6 verdict (one owner answer, both EBOs obey it). Whatever D6 decides stays top-level; everything else goes in the hamburger. Confirm D6 is the single source.
2	Mátyás opens the ☰ and clicks each relocated tab, one by one, all fifteen	Each tab opens and works exactly as it did before the move — Templates still edits and saves a template, Health still shows live checks, Finances still opens its Glance/Operate/Deep views (owner-gated Personal still gated), Lead radar still lists radar hits, Outbox still shows the queued/sent audit trail, Debug still owner-only	Copy: unchanged inside every tab · Look: unchanged inside every tab · Where: each relocated tab's own panel	Each hamburger item deep-links to the existing panel; zero behavioral change inside any relocated tab — same data, same buttons, same permissions (owner-gating intact)	Must NOT lose any function inside a relocated tab (a tab that opens but half-works counts as lost); must NOT drop the owner-only gate on Finances-Personal or Debug in the move; must NOT need more than open-☰ + one click to reach any tab	—	Critique: "Each tab opens" is a shallow check — a relocated tab can render its shell yet fail its data fetch, which a click-and-glance QA won't catch. Suggestion: For each relocated tab the QA pass performs one real interaction (save a template edit on a test template, expand a finance row, run a health check) — proof of function, not just of navigation.
3	Mátyás uses an old bookmark or a link from the Notion guide that pointed at a now-relocated tab (the old direct tab addresses, including the legacy Hungarian aliases)	The link still lands him on that tab, exactly as before — the relocation is invisible to old links; the tab just isn't in the top bar anymore	Copy: — · Look: the target tab opens; the top bar shows its stripped-down self · Where: whichever tab the link targets	Direct tab addresses (hash links, legacy alias names) keep resolving to their panels; only the visible nav entry moved	Must NOT 404 or bounce-to-default any previously working tab link (the Notion GO-LIVE guide and his bookmarks reference tabs by address — breaking those silently strands documentation)	—	—

You do

You should see

Element that changes
copy · look · where

What changes underneath

Must NOT happen

🕓 Touchpoint history

💡 UX critique + suggestion

Mátyás loads the dashboard

The top bar holds only what he actually works in — the pipeline board front and center — plus the ☰ hamburger; every dormant tab (Templates, AI Usage, Health, CRM book, Test drive, Flowchart, Calls classic, Outbox, Lost/nurture, Metrics, Costs, Lead radar, Finances, Journey copy, Debug) now lives inside the hamburger only

Copy: tab names unchanged, just moved · Look: stripped top bar + ☰ (drawn per W8) · Where: dashboard top nav

The nav's split is re-declared: the primary list shrinks to the working surface; everything else is registered as a hamburger item. No tab's underlying page/panel changes — only its entry point

Must NOT delete any tab in the move (relocation ≠ deletion — Create-Task is the ONLY removal in W7); must NOT leave the same tab reachable from two places (old Tools overflow AND the new hamburger — one home each)

—

Critique: The exact top-level survivor set is genuinely ambiguous: the ruling says "he uses ONLY the pipeline view", but W8's EBO left the Pipeline/Today/Calls/Outbox split as its open decision D6 — two EBOs must not answer it differently.
Suggestion: W7 defers the survivor set to W8's D6 verdict (one owner answer, both EBOs obey it). Whatever D6 decides stays top-level; everything else goes in the hamburger. Confirm D6 is the single source.

Mátyás opens the ☰ and clicks each relocated tab, one by one, all fifteen

Each tab opens and works exactly as it did before the move — Templates still edits and saves a template, Health still shows live checks, Finances still opens its Glance/Operate/Deep views (owner-gated Personal still gated), Lead radar still lists radar hits, Outbox still shows the queued/sent audit trail, Debug still owner-only

Copy: unchanged inside every tab · Look: unchanged inside every tab · Where: each relocated tab's own panel

Each hamburger item deep-links to the existing panel; zero behavioral change inside any relocated tab — same data, same buttons, same permissions (owner-gating intact)

Must NOT lose any function inside a relocated tab (a tab that opens but half-works counts as lost); must NOT drop the owner-only gate on Finances-Personal or Debug in the move; must NOT need more than open-☰ + one click to reach any tab

—

Critique: "Each tab opens" is a shallow check — a relocated tab can render its shell yet fail its data fetch, which a click-and-glance QA won't catch.
Suggestion: For each relocated tab the QA pass performs one real interaction (save a template edit on a test template, expand a finance row, run a health check) — proof of function, not just of navigation.

Mátyás uses an old bookmark or a link from the Notion guide that pointed at a now-relocated tab (the old direct tab addresses, including the legacy Hungarian aliases)

The link still lands him on that tab, exactly as before — the relocation is invisible to old links; the tab just isn't in the top bar anymore

Copy: — · Look: the target tab opens; the top bar shows its stripped-down self · Where: whichever tab the link targets

Direct tab addresses (hash links, legacy alias names) keep resolving to their panels; only the visible nav entry moved

Must NOT 404 or bounce-to-default any previously working tab link (the Notion GO-LIVE guide and his bookmarks reference tabs by address — breaking those silently strands documentation)

—

W7-3 — Never-used dashboard parts: reviewed, listed, and relocated (declutter review / Q14 + Q16=A)

Who: Mátyás (approving) + the build pass (proposing) · When: Beyond whole tabs, the dash carries individual widgets, info blocks, and controls on the working surface itself that he basically never uses. Q14 orders a review: find them, relocate them into the hamburger (or a secondary spot inside it). Q16=A sets the appetite: when in doubt, hide it. The review's output is a written audit list he approves before anything moves — aggressive appetite, but no silent disappearances.

#	You do	You should see	Element that changes copy · look · where	What changes underneath	Must NOT happen	🕓 Touchpoint history	💡 UX critique + suggestion
1	Mátyás receives the declutter audit list — one row per never-used part found on the working surface (candidate examples the review must judge: the Focus/Done tabs if D6 drops them, the CRM-book link, per-card Studio/Figma buttons on stages where he never uses them, any stats block he never reads)	A short, plain list: what it is · where it sits today · how often he's used it · proposed new home (hamburger / stays / gone) — he marks each row keep-visible / relocate / (for true dead weight) remove	Copy: the audit list itself (a review artifact, not a UI feature) · Look: — · Where: delivered with this EBO's build, before the move	Nothing moves yet — the audit is the gate; his verdicts drive the relocation build	Must NOT relocate or remove anything that isn't on an approved audit row (aggressive appetite ≠ silent disappearances — Create-Task is the only pre-approved removal); must NOT pad the list with things he clearly uses daily	—	Critique: "How often he's used it" is guesswork without data — the dash keeps no click statistics, so the audit will lean on memory and inference. Suggestion: Base the list on the three weeks of session history already mined for this overhaul (what he actually asked about / clicked in recordings) rather than adding usage tracking — Q16=A says when the record is silent about an element, default it to the hamburger.
2	After his verdicts land, Mátyás works a normal morning on the decluttered board	The working surface shows only what he uses; every relocated part is findable inside the ☰ under a sensible name and works there — nothing he approved for relocation turns out to be missing or broken	Copy: relocated items keep their names · Look: quieter working surface · Where: board + ☰	Each approved audit row is executed exactly as marked; the audit list is kept with the ship record so every moved item is traceable	Must NOT execute a row differently from his verdict (marked "relocate" but actually deleted = fail); must NOT degrade anything left on the working surface while extracting its neighbors	—	Critique: A month from now, "where did X go?" is the predictable cost of an aggressive declutter. Suggestion: Keep the executed audit list linked from inside the hamburger itself (one "What moved here" entry at the bottom) so the answer to "where did X go" is one click away, forever.

You do

You should see

Element that changes
copy · look · where

What changes underneath

Must NOT happen

🕓 Touchpoint history

💡 UX critique + suggestion

Mátyás receives the declutter audit list — one row per never-used part found on the working surface (candidate examples the review must judge: the Focus/Done tabs if D6 drops them, the CRM-book link, per-card Studio/Figma buttons on stages where he never uses them, any stats block he never reads)

A short, plain list: what it is · where it sits today · how often he's used it · proposed new home (hamburger / stays / gone) — he marks each row keep-visible / relocate / (for true dead weight) remove

Copy: the audit list itself (a review artifact, not a UI feature) · Look: — · Where: delivered with this EBO's build, before the move

Nothing moves yet — the audit is the gate; his verdicts drive the relocation build

Must NOT relocate or remove anything that isn't on an approved audit row (aggressive appetite ≠ silent disappearances — Create-Task is the only pre-approved removal); must NOT pad the list with things he clearly uses daily

—

Critique: "How often he's used it" is guesswork without data — the dash keeps no click statistics, so the audit will lean on memory and inference.
Suggestion: Base the list on the three weeks of session history already mined for this overhaul (what he actually asked about / clicked in recordings) rather than adding usage tracking — Q16=A says when the record is silent about an element, default it to the hamburger.

After his verdicts land, Mátyás works a normal morning on the decluttered board

The working surface shows only what he uses; every relocated part is findable inside the ☰ under a sensible name and works there — nothing he approved for relocation turns out to be missing or broken

Copy: relocated items keep their names · Look: quieter working surface · Where: board + ☰

Each approved audit row is executed exactly as marked; the audit list is kept with the ship record so every moved item is traceable

Must NOT execute a row differently from his verdict (marked "relocate" but actually deleted = fail); must NOT degrade anything left on the working surface while extracting its neighbors

—

Critique: A month from now, "where did X go?" is the predictable cost of an aggressive declutter.
Suggestion: Keep the executed audit list linked from inside the hamburger itself (one "What moved here" entry at the bottom) so the answer to "where did X go" is one click away, forever.

W7-4 — Tax number (adószám) field validates its format — no bad value reaches a contract (happy path + rejection)

Who: Mátyás · When: He opens a lead's Details panel to fill in the legal fields before sending a contract. The Tax number field is free text today — a typo'd or malformed Hungarian tax number (correct shape: 12345678-1-12 — 8 digits, dash, 1 digit, dash, 2 digits) sails straight through to Notion and onto the DocuSeal contract, and nobody notices until the client sees it on the signed PDF. After W7, the field checks the shape at save time, on both the screen and the server.

# You do You should see Element that changes
copy · look · where What changes underneath Must NOT happen 🕓 Touchpoint history 💡 UX critique + suggestion

1 Mátyás types a malformed tax number (e.g. 1234 or not-a-number) into the Details panel's Tax number field and moves on / tries to save An inline red hint appears right under the field ("Expected format: 12345678-1-12") and the save is blocked for that value — typing is never blocked, only saving Copy: hint "Expected format: 12345678-1-12" · Look: field border + hint in red · Where: Details panel, Legal group, Tax number field The field carries a format check against the Hungarian tax-number shape (8 digits – 1 digit – 2 digits); a non-matching value never leaves the browser as a save Must NOT block or reformat his typing mid-keystroke (he may paste, backspace, retype freely — only the save is gated); must NOT silently accept the bad value; must NOT flag a valid number as invalid — Critique: Most malformed entries will be near-misses — a pasted value with spaces or missing dashes (12345678 1 12, 12345678112), not garbage.
Suggestion: When the digits are right but only the separators are off, auto-normalize to the dashed shape on save instead of rejecting — fix the fixable, reject only what's genuinely wrong.

2 A malformed value reaches the server anyway (a stale cached page, an old open tab from before the update) The save round-trip comes back rejected with a visible reason on screen ("Invalid tax number format") — the field keeps his typed value so he can correct it; the lead's stored data is untouched Copy: rejection reason shown ("Invalid tax number format") · Look: the failed field flagged red · Where: Details panel The server independently re-checks the same format on every lead-field save and refuses a non-matching tax number before it is written anywhere — the on-screen check is convenience, the server check is the guarantee Must NOT write the malformed value to the lead record or forward it to Notion; must NOT fail silently (a rejection he never sees = the old bug with extra steps); must NOT wipe his typed text on rejection — —

3 Mátyás types a valid tax number (e.g. 12345678-1-12) and saves The save goes through as it always did — no hint, no friction; the value shows in the Details panel and, when the contract is later generated, the same value appears correctly in the contract's client (Megbízó) block Copy: the saved value · Look: normal saved-field state · Where: Details panel → lead record → contract The valid value writes through to the lead's stored record (and Notion's Adószám property) exactly as typed; the contract pipeline downstream receives a guaranteed-well-formed value Must NOT add any extra confirmation step for valid values (the happy path stays exactly as fast as today); must NOT alter a valid value in transit — —

#	You do	You should see	Element that changes copy · look · where	What changes underneath	Must NOT happen	🕓 Touchpoint history	💡 UX critique + suggestion
1	Mátyás types a malformed tax number (e.g. `1234` or `not-a-number`) into the Details panel's Tax number field and moves on / tries to save	An inline red hint appears right under the field ("Expected format: 12345678-1-12") and the save is blocked for that value — typing is never blocked, only saving	Copy: hint "Expected format: 12345678-1-12" · Look: field border + hint in red · Where: Details panel, Legal group, Tax number field	The field carries a format check against the Hungarian tax-number shape (8 digits – 1 digit – 2 digits); a non-matching value never leaves the browser as a save	Must NOT block or reformat his typing mid-keystroke (he may paste, backspace, retype freely — only the save is gated); must NOT silently accept the bad value; must NOT flag a valid number as invalid	—	Critique: Most malformed entries will be near-misses — a pasted value with spaces or missing dashes (`12345678 1 12`, `12345678112`), not garbage. Suggestion: When the digits are right but only the separators are off, auto-normalize to the dashed shape on save instead of rejecting — fix the fixable, reject only what's genuinely wrong.
2	A malformed value reaches the server anyway (a stale cached page, an old open tab from before the update)	The save round-trip comes back rejected with a visible reason on screen ("Invalid tax number format") — the field keeps his typed value so he can correct it; the lead's stored data is untouched	Copy: rejection reason shown ("Invalid tax number format") · Look: the failed field flagged red · Where: Details panel	The server independently re-checks the same format on every lead-field save and refuses a non-matching tax number before it is written anywhere — the on-screen check is convenience, the server check is the guarantee	Must NOT write the malformed value to the lead record or forward it to Notion; must NOT fail silently (a rejection he never sees = the old bug with extra steps); must NOT wipe his typed text on rejection	—	—
3	Mátyás types a valid tax number (e.g. `12345678-1-12`) and saves	The save goes through as it always did — no hint, no friction; the value shows in the Details panel and, when the contract is later generated, the same value appears correctly in the contract's client (Megbízó) block	Copy: the saved value · Look: normal saved-field state · Where: Details panel → lead record → contract	The valid value writes through to the lead's stored record (and Notion's Adószám property) exactly as typed; the contract pipeline downstream receives a guaranteed-well-formed value	Must NOT add any extra confirmation step for valid values (the happy path stays exactly as fast as today); must NOT alter a valid value in transit	—	—

W7-5 — Action-button sweep: every non-send click gives feedback fast and never fires twice (happy path / systemic guard)

Who: Mátyás · When: Any moment he clicks an action on a card — Log Call save, Note save, Move, snooze, Studio buttons, Details-panel field saves. On a slow network a button that shows nothing for two seconds invites a second click, and today some of those second clicks do the thing twice. W7 sweeps every non-send action button in the Control Panel and closes the pattern: feedback within 300ms of the click, and a double-click can never duplicate a mutation. (Send-triggering buttons are W1's — explicitly out of this sweep.)

#	You do	You should see	Element that changes copy · look · where	What changes underneath	Must NOT happen	🕓 Touchpoint history	💡 UX critique + suggestion
1	Mátyás clicks any action button on a card (e.g. saves a Note, logs a call, moves a card)	Something visibly reacts within 300ms — either the optimistic result itself (the card moves / the note toast fires instantly, as the board already does for card moves and dispositions) or the button switches to a busy state until the request settles; then the UI is immediately his again — never a frozen wait	Copy: existing toasts/labels unchanged · Look: instant reaction on every action click, board-wide · Where: every non-send action button in the Control Panel	Every action click either goes through the existing instant-feedback path (card animates + toast before the network settles — already the case for moves, dispositions, notes) or gets the same disable-while-busy treatment the Studio-send buttons already have. Nothing waits silently	Must NOT leave any action button that shows nothing for the length of a network round-trip; must NOT hold the owner's flow hostage (feedback frees him immediately — reliability is proven in the background, not by making him watch a spinner finish)	Actions that already log a touchpoint (call logged, note saved) keep logging exactly one entry per real action — the sweep changes click mechanics, never history content (W2 owns content).	Critique: The owner's own reported case — "used Log Call, edited the confirmation email text, but wasn't sure the edit actually saved" — is a certainty gap, not just a latency gap. Suggestion: Make the Log-Call → edit-confirmation-email path the sweep's named benchmark case: after saving the edited text, the field visibly reflects the saved state (and the background probe confirms the edited text is what the calendar/email actually carries). His one real complaint becomes the acceptance test.
2	Mátyás double-clicks (or mash-clicks) any action button that changes real data, before the first click has finished	The result is identical to a single click — one note, one logged call, one move, one saved field. The second click lands on a disabled/already-done control and does nothing extra	Copy: one confirmation, not two · Look: button inert after the first click until settled · Where: every data-mutating action button	Exactly one request leaves the browser per action; where a stale page could bypass the client guard, the server treats a rapid duplicate of the same action as the same action (returns the first result instead of doing it again)	Must NOT create two of anything from a double-click (two notes, two logged calls, two task rows anywhere); must NOT rely on the client guard alone for data-mutating actions — the server backstop must hold even from a stale cached page	Exactly one history entry per real action — a duplicate entry from a double-click is the sweep's canonical fail.	—
3	Mátyás (or the QA pass) reviews the sweep's written audit — one row per action button in the Control Panel	A complete table: button → what it does → guard status (already covered / gap fixed) → proof; every row previously marked "gap" carries a double-click test showing exactly one request fired	Copy: the audit table (ship-record artifact) · Look: — · Where: attached to this workstream's ship-ledger row	The sweep is exhaustive over the Control Panel's non-send buttons and its findings are recorded — "already covered" claims are verified, not assumed	Must NOT touch buttons owned by W1 (send-triggering) or panels W3 is still reshaping — the audit marks those "excluded (Wx seam)" rather than silently skipping them; must NOT rewrite the existing feedback machinery itself, only wrap the gaps	—	—

You do

You should see

Element that changes
copy · look · where

What changes underneath

Must NOT happen

🕓 Touchpoint history

💡 UX critique + suggestion

Mátyás clicks any action button on a card (e.g. saves a Note, logs a call, moves a card)

Something visibly reacts within 300ms — either the optimistic result itself (the card moves / the note toast fires instantly, as the board already does for card moves and dispositions) or the button switches to a busy state until the request settles; then the UI is immediately his again — never a frozen wait

Copy: existing toasts/labels unchanged · Look: instant reaction on every action click, board-wide · Where: every non-send action button in the Control Panel

Every action click either goes through the existing instant-feedback path (card animates + toast before the network settles — already the case for moves, dispositions, notes) or gets the same disable-while-busy treatment the Studio-send buttons already have. Nothing waits silently

Must NOT leave any action button that shows nothing for the length of a network round-trip; must NOT hold the owner's flow hostage (feedback frees him immediately — reliability is proven in the background, not by making him watch a spinner finish)

Actions that already log a touchpoint (call logged, note saved) keep logging exactly one entry per real action — the sweep changes click mechanics, never history content (W2 owns content).

Critique: The owner's own reported case — "used Log Call, edited the confirmation email text, but wasn't sure the edit actually saved" — is a certainty gap, not just a latency gap.
Suggestion: Make the Log-Call → edit-confirmation-email path the sweep's named benchmark case: after saving the edited text, the field visibly reflects the saved state (and the background probe confirms the edited text is what the calendar/email actually carries). His one real complaint becomes the acceptance test.

Mátyás double-clicks (or mash-clicks) any action button that changes real data, before the first click has finished

The result is identical to a single click — one note, one logged call, one move, one saved field. The second click lands on a disabled/already-done control and does nothing extra

Copy: one confirmation, not two · Look: button inert after the first click until settled · Where: every data-mutating action button

Exactly one request leaves the browser per action; where a stale page could bypass the client guard, the server treats a rapid duplicate of the same action as the same action (returns the first result instead of doing it again)

Must NOT create two of anything from a double-click (two notes, two logged calls, two task rows anywhere); must NOT rely on the client guard alone for data-mutating actions — the server backstop must hold even from a stale cached page

Exactly one history entry per real action — a duplicate entry from a double-click is the sweep's canonical fail.

—

Mátyás (or the QA pass) reviews the sweep's written audit — one row per action button in the Control Panel

A complete table: button → what it does → guard status (already covered / gap fixed) → proof; every row previously marked "gap" carries a double-click test showing exactly one request fired

Copy: the audit table (ship-record artifact) · Look: — · Where: attached to this workstream's ship-ledger row

The sweep is exhaustive over the Control Panel's non-send buttons and its findings are recorded — "already covered" claims are verified, not assumed

Must NOT touch buttons owned by W1 (send-triggering) or panels W3 is still reshaping — the audit marks those "excluded (Wx seam)" rather than silently skipping them; must NOT rewrite the existing feedback machinery itself, only wrap the gaps

—

W7-6 — Two already-fixed items: verify live, do not rebuild (verification only / stale-findings correction)

Who: QA pass (with Mátyás's flows) · When: The overhaul's master findings listed two bugs here that this workstream's code check found already fixed on current production code: (a) editing a Details field, closing the drawer, then clicking a leftover floating Save button used to silently do nothing — the Save button is now cleared when the drawer closes; (b) the proposal Regenerate / Re-render buttons used to allow a double-click to fire two paid AI generations — both buttons now disable the moment one is clicked. W7 proves both live once, and corrects the findings record — existing flow, verify unchanged; no rebuild.

# You do You should see Element that changes
copy · look · where What changes underneath Must NOT happen 🕓 Touchpoint history 💡 UX critique + suggestion

1 Mátyás edits a Details-panel field, closes the drawer WITHOUT saving, then looks for the floating Save button The floating Save button is already gone the moment the drawer closes — there is nothing left to click that could silently do nothing. Reopening the drawer shows the field's last saved value (the unsaved edit was discarded with the close) Copy: — · Look: no orphaned Save button after drawer close (current shipped behavior) · Where: Details drawer + floating Save Closing the drawer clears the pending-edit flag and hides the Save button (shipped fix, tag DT1) — verified live once, screenshot kept as proof Must NOT show a clickable Save that no-ops (the pre-fix bug); if any OTHER code path re-shows the Save button, clicking it must either save correctly or show a visible error — never silence — Critique: Discarding an unsaved edit on drawer-close is correct but silent — he may believe the edit stuck.
Suggestion: None to build now (don't invent flows); note for W3's panel work: a close with unsaved edits is the natural place for its schema pass to decide keep-or-warn. Flagged, not specified here.

2 Mátyás opens a proposal's regenerate controls and double-clicks Regenerate (or clicks Regenerate then immediately Re-render) Both buttons go inert on the first click and stay inert until the run finishes — one AI generation runs, one result appears; the buttons re-enable after Copy: unchanged · Look: both buttons disabled during the in-flight run (current shipped behavior) · Where: proposal panel regenerate controls Both regenerate buttons are disabled synchronously before the request leaves, re-enabled only when it resolves (shipped fix) — exactly one paid AI call per human intent; verified live once on a ZZ-sentinel proposal Must NOT fire a second paid AI generation from any click combination while one is in flight; must NOT leave the buttons stuck disabled if the run fails (they must re-enable with the failure visible) — —

3 The overhaul's findings record is updated after both live checks pass The master findings entry for these two items reads "already fixed, live-verified " with the proof attached — no builder in a later workstream re-implements a shipped fix Copy: findings record correction · Look: — · Where: the overhaul's findings/ship record The stale framing (which described both as open bugs) is corrected at the source so the record matches production reality Must NOT leave the stale "open bug" framing in place (a later agent reading it would rebuild — and possibly break — a working fix) — —

#	You do	You should see	Element that changes copy · look · where	What changes underneath	Must NOT happen	🕓 Touchpoint history	💡 UX critique + suggestion
1	Mátyás edits a Details-panel field, closes the drawer WITHOUT saving, then looks for the floating Save button	The floating Save button is already gone the moment the drawer closes — there is nothing left to click that could silently do nothing. Reopening the drawer shows the field's last saved value (the unsaved edit was discarded with the close)	Copy: — · Look: no orphaned Save button after drawer close (current shipped behavior) · Where: Details drawer + floating Save	Closing the drawer clears the pending-edit flag and hides the Save button (shipped fix, tag `DT1`) — verified live once, screenshot kept as proof	Must NOT show a clickable Save that no-ops (the pre-fix bug); if any OTHER code path re-shows the Save button, clicking it must either save correctly or show a visible error — never silence	—	Critique: Discarding an unsaved edit on drawer-close is correct but silent — he may believe the edit stuck. Suggestion: None to build now (don't invent flows); note for W3's panel work: a close with unsaved edits is the natural place for its schema pass to decide keep-or-warn. Flagged, not specified here.
2	Mátyás opens a proposal's regenerate controls and double-clicks Regenerate (or clicks Regenerate then immediately Re-render)	Both buttons go inert on the first click and stay inert until the run finishes — one AI generation runs, one result appears; the buttons re-enable after	Copy: unchanged · Look: both buttons disabled during the in-flight run (current shipped behavior) · Where: proposal panel regenerate controls	Both regenerate buttons are disabled synchronously before the request leaves, re-enabled only when it resolves (shipped fix) — exactly one paid AI call per human intent; verified live once on a ZZ-sentinel proposal	Must NOT fire a second paid AI generation from any click combination while one is in flight; must NOT leave the buttons stuck disabled if the run fails (they must re-enable with the failure visible)	—	—
3	The overhaul's findings record is updated after both live checks pass	The master findings entry for these two items reads "already fixed, live-verified " with the proof attached — no builder in a later workstream re-implements a shipped fix	Copy: findings record correction · Look: — · Where: the overhaul's findings/ship record	The stale framing (which described both as open bugs) is corrected at the source so the record matches production reality	Must NOT leave the stale "open bug" framing in place (a later agent reading it would rebuild — and possibly break — a working fix)	—	—

🕓 Touchpoint-history note for W7:
W7 is a discipline workstream — it never authors a touchpoint of its own. Its entire relationship to history is a guarantee of cardinality: after the sweep, one human action produces exactly one of whatever it produces — one logged call, one note, one saved field — never two from a double-click (W7-5 row 2 is the canonical check). Removing Create-Task (W7-1) removes a source of records (no dash click can create a Main-Tasks row anymore) without touching any existing history; relocating tabs (W7-2/W7-3) and validating the tax number (W7-4) touch no history at all. Content, rendering, and parity of touchpoint rows remain entirely W2's.

💡 UX themes across all W7 scenarios:
(1) Removal must be total or it's a bug — Create-Task renders from nine places; a removal proven on one card is a partial removal, so QA walks every stage plus a page-source search. (2) Relocation is a contract — every moved item must still function from the hamburger (a real interaction per tab, not a shell check), and old links keep working. (3) Aggressive ≠ silent — Q16=A sets the appetite, but every hide/move beyond Create-Task rides an owner-approved audit row, and the executed list stays findable ("What moved here"). (4) Validate at the door, guarantee at the server — the on-screen tax-number hint is convenience; the server-side reject is the actual protection for the signed PDF. (5) Feedback frees, never blocks — 300ms feedback then the UI is his again; reliability is proven in the background, and the owner's own Log-Call uncertainty story is the named benchmark. (6) Verify, don't rebuild — two findings were stale; the fix is a live proof plus a record correction, not new code.

Work-item → scenario-step mapping

Each build work item derived for W7, and the scenario steps that prove it works when clicked through on the staging dash. (The handoff's original W7-2 "Create-Task click-guard + idempotency key" is superseded by round-3 Q15=A — removal; its server-side double-fire concern survives generalized inside the W7-5 sweep's backstop rule.)

Work item	What it delivers	Proven by (scenario · step)
WI-1 · Create-Task removal	The button deleted from all nine card layouts, no dead references or gaps, no dash path can create a Main-Tasks row; automatic task integration untouched.	W7-1·1 · W7-1·2 · W7-1·3
WI-2 · Hamburger relocation map	Every dormant tab (15 items) registered under the ☰ (contents = W7, visuals = W8), one home each, top-level survivors per W8-D6; all still fully functional; legacy links/aliases keep resolving.	W7-2·1 · W7-2·2 · W7-2·3
WI-3 · Never-used-parts audit + relocation	A written audit of never-used widgets/controls on the working surface, owner verdict per row, verdicts executed exactly, executed list kept discoverable.	W7-3·1 · W7-3·2
WI-4 · Tax-number validation	Client-side format hint (blocks save, never typing) + independent server-side reject of malformed values; valid values flow to the lead record / Notion / contract untouched.	W7-4·1 · W7-4·2 · W7-4·3
WI-5 · Action-button discipline sweep	Every non-send action button: feedback <300ms, double-click never duplicates a mutation (server backstop for data-mutating actions), exhaustive written audit with per-gap double-click proof; W1/W3 seams excluded explicitly.	W7-5·1 · W7-5·2 · W7-5·3
WI-6 · Verify-only pair + record correction	Drawer-close Save-button fix and Regenerate double-fire guard proven live once each (screenshots), master-findings stale framing corrected — zero rebuild.	W7-6·1 · W7-6·2 · W7-6·3

❓ Open design decisions I made myself — please comment (keep / change) in this round:
❓ D1 Backend endpoint of the removed button (W7-1·2): the UI removal makes the create-task endpoint unreachable; per the Q16=A kill appetite I propose retiring the endpoint too, in the same pass. Remove it, or leave it dormant?
❓ D2 Top-level survivor set (W7-2·1): I defer the "what stays out of the hamburger" question to W8's open decision D6 so both EBOs obey one answer. Confirm D6 is the single ruling for both?
❓ D3 Audit-gated declutter (W7-3·1): beyond Create-Task, nothing is hidden/moved without an approved audit row — aggressive appetite applied through one approval list, not silent judgment calls. OK, or do you want the pass to move things without the list?
❓ D4 Tax-number near-miss normalization (W7-4·1): right digits with wrong separators (spaces / missing dashes) auto-normalize to the dashed shape on save instead of rejecting. Keep the auto-fix, or strict-reject everything non-matching?
❓ D5 Sweep benchmark case (W7-5·1): I named your Log-Call → edit-confirmation-email uncertainty as the sweep's acceptance benchmark (the saved edit must be visibly confirmed and provably what the calendar/email carries). Confirm this is the case that must pass?

Sign-off — acceptance oracle. By signing, Sarudi Mátyás locks scenarios W7-1 … W7-6 and the invariants above as the acceptance answer key for the W7 UI Action Discipline workstream, and records his keep/change verdict on the ❓ open decisions D1–D5. No W7 code is built or deployed before this signature.
Sarudi Mátyás ✔ Draft · 2026-07-12 · awaiting sign-off