Visual system: Inter type base, button variants & empty states

[aselim31]

Context

The v4 design spec introduces a dual type base — 14px Inter for stakeholder surfaces and 13px mono for operator surfaces — along with refined button variants, module spacing, and dispatch-voice empty states.

Current state

Item	Status
Task row density — colour + shape + label	⚠️ Partial — PR #115
14px Inter stakeholder / 13px mono operator type base	❌ Not done
Sentence-case Inter text button variant for stakeholder contexts	❌ Not done
Module padding 20-24px	❌ Not done
Modal widths: 720px stakeholder / 900px operator	❌ Not done
Empty states with Morse dispatch voice (— M)	❌ Not done
— M byline on all dispatch-voice strings	❌ Not done
Grid intensity: 6% shell / 4-5% content panels	❌ Not done

What needs to be done

• Apply 14px Inter to all stakeholder surfaces; retain 13px mono on operator surfaces
• Add sentence-case Inter text button variant
• Increase module padding to 20-24px across all panels
• Standardise modal widths: 720px (stakeholder) / 900px (operator)
• Write empty state copy in Morse dispatch voice with — M suffix
• Reduce scanline grid to 6% on shell, 4-5% on content panels

References

• Spec: docs/DOTBOT-v4-DESIGN-IDEAS.md

[IBondarenko-iwg]

@aselim31 @carlospedreira This issue is labeled NOW, but it appears to depend on #551, which isn't.
Most of #552's deliverables key off a stakeholder-vs-operator distinction that doesn't exist in code yet — no data-surface flag, no role detection, no per-element classification of which modals/buttons are stakeholder-facing. That boundary is #551's deliverable ("stakeholder layer as default; operator overlay via ⌘K"), and the type-base split is still an open recommendation pending the ADR in #554.

Sorting this issue's checklist by what that boundary gates:

Deliverable	Depends on surface boundary (#551)?
Module padding 20–24px	No — global
— M empty-state copy	No — dispatch voice (but high-touch: ~17 JS files, no central component)
Scanline 6% shell / 4–5% content	No persona dep — but the "shell" target assumes #551's top-bar + rail; today only a global body scanline exists
Modal widths 720/900	Yes — needs to know which modals are stakeholder vs operator
Sentence-case text button variant	Yes — "stakeholder contexts"
14px Inter / 13px mono type base	Yes — surface-wide default = root persona

Only the first three look implementable in isolation; the other three (including the headline "Inter type base") need the operator/stakeholder boundary from #551 defined first. Right now the dependency and the labels point opposite directions — might be worth either promoting #551 to NOW or re-scoping #552.

[aselim31]

Hi @IBondarenko-iwg I will mark #551 NOW and add it for the Milestone for V4.1.0

[aselim31]

@IBondarenko-iwg do you prefer to split the issue into multiple issues or keep them all together?

[IBondarenko-iwg]

@aselim31 Lean towards split, though happy to go either way - keen to hear other thoughts. With #551 also NOW, the two run in parallel — but the dependency falls into two distinct buckets, which makes a clean cut:

552-A — parallel-safe, keep NOW

• Module padding 20–24px (modules.css)
• — M empty-state copy (content JS modules)

No dependency on #551's surface model; lives in content files, not the shell. (Minor note: empty states touch sidebar.js, which #551's rail work also touches — small coordination point, not a blocker.)

552-B — depends on #551 (+ #554 for the type-base ADR)

• Modal widths 720/900 — needs the stakeholder/operator classification Navigation Shell — Top Bar, Icon Rail & Studio→Mothership Merge #551 defines
• Sentence-case text button variant — same ("stakeholder contexts")
• 14px Inter / 13px mono type base — surface-wide default = Navigation Shell — Top Bar, Icon Rail & Studio→Mothership Merge #551's root persona
• Scanline 6% shell / 4–5% content — the "shell" target needs Navigation Shell — Top Bar, Icon Rail & Studio→Mothership Merge #551's top-bar + rail to exist first

A and B don't fight over files (#551 restructures the shell — sidebar.css, responsive.css, the new dotbot-shell.css — while 552-A stays in content CSS/JS), so A can ship alongside #551 and B picks up once the shell + surface model land.

One exception: if the same person takes #551 and #552, keep-together is fine — they hold the shell context and can sequence internally.

[IBondarenko-iwg]

@aselim31 Let me work on this one.

[aselim31]

@IBondarenko-iwg assigned

Just checking if #551 is done or you are blocked on something ?

[IBondarenko-iwg]

@aselim31 #607 (ticker behaviour, persona split, preset reshuffle) - plan finalized, implementation in progress on a branch stacked on #640; PR follows shortly after #640 merges (just a rebase).

I'll ping you when all four R1 parts are merged - then we can move #551 to the V4.2.0 milestone for the R2 scope, as discussed when we set up the sub-issues.