# Mokosh — Brand Identity (Brief #1: Name + Blurb + Open Creative Slate) First in a series of brand-foundation artifacts for the **design team** and the **brand team**. Engineering's role here is to enumerate what's mechanically locked (one item only) and inventory the options for everything else. **Every creative decision below is open.** Pick, override, or replace from a blank page. Sibling docs already shipped: - `design-system.md` — engineering's starting visual sketch (treat as draft, not contract) - `assets-spec.md` — concrete file deliverables (Chrome API technical floors are binding; aesthetic descriptions are open) Status: `draft` — authored 2026-05-17. Replace, rewrite, or scrap whole sections. --- ## What's locked vs what's open | Decision | Status | Owner | |---|---|---| | Internal codename **"Mokosh"** | **LOCKED** | Engineering (already wired through code, docs, commits, planning) | | Public display name (`manifest.json:name`) | OPEN | Brand team | | Design system name | OPEN | Both teams | | One-liner / blurb / long description | OPEN | Brand team | | Voice + tone + register | OPEN | Brand team | | Color palette (every hex) | OPEN | Design team | | Typography (face, scale, fallbacks) | OPEN | Design team — technical floor: Cyrillic must render | | Iconography style (solid/line/mixed, mark concept) | OPEN | Design team — technical floor: 16/48/128 px PNG, file-size floors per `assets-spec.md` | | Corner radii | OPEN | Design team | | Motion vocabulary | OPEN | Design team | | Welcome-tab layout + hero treatment | OPEN | Design team | | Localization defaults (RU-first or EN-first) | OPEN | Brand team + product | Anywhere this brief (or the sibling specs) cites a specific hex, font, or treatment, read it as **"what engineering currently ships in placeholder builds"** — not as direction. Engineering will rewire to whatever the teams decide. --- ## 1. The name — `Mokosh` *(LOCKED)* Only locked decision in this brief. The codename is already woven through the codebase (`src/`, `manifest.json`, planning docs, debug sessions, commit history), so changing it is a refactor, not a brand choice. Engineering owns the lock; the teams own everything downstream. | | | |---|---| | **Origin** | Мокошь — East-Slavic goddess of weaving, fate, and women's work; one of the few female deities in the pre-Christian Slavic pantheon. | | **Pronunciation** | English: **MOH-kosh** (first syllable stressed). Russian: МО́кошь, /ˈmokəʂ/. | | **Resonance (suggested, not prescriptive)** | The tool weaves session threads (video, DOM, events) into one artifact. Brand team is free to lean into or away from the etymology — it's a vessel, not a constraint. | --- ## 2. The public display name *(OPEN — brand team)* `manifest.json:name` is whatever the brand team writes. The placeholder shipping today is `"AI Call Recorder"` (a literal description from the original Russian SPEC). Candidate directions, all equally on the table: - **Just `Mokosh`.** Most minimal; codename surfaces externally. - **`Mokosh` + tagline lockup.** E.g. `Mokosh — Session Capture` or whatever the brand team writes. - **Keep `"AI Call Recorder"` or similar literal descriptor.** Most discoverable in a Chrome extension list for non-internal viewers. - **Bilingual lockup.** E.g. `"Mokosh / АИ Регистратор"` — addresses Russian-first audience explicitly. - **Something entirely different the brand team coins.** Open question: does the display name need to make sense to a Russian-speaking operator on first glance, or do operators get onboarded with the welcome tab before they ever read the toolbar tooltip? --- ## 3. The design system name *(OPEN — both teams)* Engineering needs *something* to call the visual language in design reviews and docs. Options without ranking: | Option | Name | Tradeoffs | |---|---|---| | A | **Mokosh** (extends the product codename) | One brand to remember. Mirrors Stripe→"Stripe Design" pattern. Ties the visual language tightly to this one product. | | B | A separate name coined by the design team (e.g. *Thread*, *Tracelight*, *anything*) | Lets the visual language travel beyond Mokosh if the org builds related operator tools. More naming overhead. | | C | Generic descriptor (e.g. *Operator Design Language*, *Support Tooling DS*) | Functional. Forgettable. | | D | No formal name at all — just "the Mokosh styles" | Pragmatic for a small system; defer naming until the system warrants it. | --- ## 4. The blurb *(OPEN — brand team)* Sketches below are conversation starters, not recommendations. Write fresh if none of these land. Brand team owns the final word. ### One-liner — ≤ 12 words Used in `manifest.json:description`, Chrome Web Store thumbnail (if ever published), welcome-tab subtitle. - *"One click. The last 30 seconds, packaged."* - *"Self-contained bug reports for operator workflows."* - *"Capture what happened. Send it. Move on."* - *"Quietly recording so you don't have to."* - *(or anything else)* ### Short blurb — 2–3 sentences Used on the welcome tab hero, internal one-pagers, README top. **Sketch A (operator-first framing):** > Mokosh sits quietly in your Chrome toolbar and remembers the last 30 seconds > of video, the last 10 minutes of page state, and the last 10 minutes of user > input — at all times. When something breaks, one click packs it all into a > single archive that support can open immediately. No server. No waiting. **Sketch B (support-first framing):** > Mokosh turns operator bug reports into something support engineers can > actually reproduce. A continuous in-browser ring buffer captures video, DOM > state, and user input; one click bundles it into a self-contained ZIP that > opens locally with no infrastructure required. **Sketch C (write your own).** ### Long blurb — one paragraph Sketch for the welcome tab and one-pagers. Treat as a strawman. > The hardest part of fixing an operator's bug is not the fix — it's > reconstructing what they were looking at when it happened. Mokosh closes > that gap. It runs as a background recorder that the operator never has to > think about: thirty seconds of screen video, ten minutes of page state, and > ten minutes of mouse-and-keyboard activity are always in memory, ready to > ship. When a bug strikes, the operator clicks once and walks away. Support > opens the resulting archive locally — no upload, no server, no third party, > no password leakage — and replays exactly what the operator saw, in their > own browser, frame for frame. --- ## 5. Voice / tone / register *(OPEN — brand team)* Engineering has no opinion. A few axis questions to help frame the decision: - **Warmth** — clinical / neutral / warm / friendly - **Formality** — system-message terse / professional / conversational / casual - **Humour** — none / dry / occasional / playful - **Emoji policy** — never / functional only (✓ × ⚠) / freely - **Punctuation** — sentence case + periods, all lowercase no punctuation, headline case, or other - **Two-register or single-register?** — does toolbar/notification copy share voice with welcome-tab copy, or do they diverge (system-message-ish for chrome surfaces, full-prose for onboarding)? Optional inspiration anchors — pick any, none, or replace: - **Linear, Loom, Notion AI, Duolingo, Salesforce, Stripe, Intercom, your-own-reference-here.** --- ## 6. Visual language *(OPEN — design team)* Engineering currently ships placeholders. Every choice below is open. ### Palette Current placeholder direction: dark-mode-native, monochrome with a single saturated accent for "recording" state. **This is one of many possible directions** — alternatives include: - Light-mode primary with dark-mode variant - Multi-accent (separate colors for record / save / error states beyond just green/yellow/red) - Warm/earthy (browns, ochres, off-whites) - Cool/clinical (blues, grays, white) - High-contrast monochrome (pure black/white + one accent) - Whatever the design team coins Technical floor (not creative): the toolbar badge supports text + a background color via `chrome.action.setBadgeBackgroundColor` — color encodes state there. That's a mechanism, not a palette constraint. ### Corner radii Current placeholder direction: sharp (2–4 px). Equally valid: pillow-rounded (8–16 px), mixed (sharp containers + rounded controls), fully circular for chips and badges, or any combination. Design team owns. ### Typography Current placeholder direction: system stack (`-apple-system, "Segoe UI", Roboto, "Noto Sans", sans-serif`) — chosen for zero-load and Cyrillic coverage. Equally valid: custom face (Inter, IBM Plex Sans, JetBrains Mono, or anything the design team licenses), variable font, type pairs. **Technical floor:** the chosen face(s) must render Cyrillic correctly (Russian operators are primary) and must not block the MV3 service worker (no remote `@font-face` from external CDNs — bundle locally if non-system). ### Iconography Current placeholder direction: solid-filled, 24 px grid, neutral mark + state via badge (the toolbar icon itself doesn't change between idle/recording — the badge does). Equally valid: line-only, mixed (solid for primary + line for secondary), per-state icon swaps via `chrome.action.setIcon`, animated icons, illustrated mark. **Technical floor:** sized PNGs at 16, 48, 128 px (the 128 px is required for `chrome.notifications.create`); minimum file size floors per `assets-spec.md` so Chrome doesn't silently reject. ### Motion Current placeholder direction: minimal — 200–300 ms opacity/transform fades, no bounce, no entrance animations on notifications. Equally valid: more expressive (spring-based), or completely static (no transitions at all). ### Welcome-tab layout Open. Could be hero + 3-step explainer, a single-column scrolling story, a modal dialog, a video walkthrough, anything. No engineering preference. --- ## 7. Hard technical constraints (these are not creative) These are floors imposed by Chrome MV3 and the deployment surface. Not brand decisions: - Manifest V3 CSP forbids `unsafe-eval` and remote scripts (no CDN web fonts that hot-load at runtime) - Notification icons must be ≥ 128 px PNG, with file sizes above silent-rejection floors (see `assets-spec.md`) - Toolbar icons required at 16 / 48 / 128 px - Cyrillic glyph coverage required for the chosen typeface(s) - Service worker has no DOM — any visual surface lives in popup, offscreen doc, or content-script-injected DOM - Welcome tab opens via `chrome.tabs.create` on install — must be a static HTML/CSS/JS page in `dist/` --- ## Any other notes? Engineering's working sketch is intentionally restrained — dark backgrounds, sharp corners, system fonts, one accent color, near-zero motion — because the product promise is *unobtrusiveness for operators under stress*. **That said, none of this is brand direction; it's just what engineering picked when no designer was in the room.** If the design and brand teams land on something warmer, more playful, more illustrative, or stylistically different in any direction, engineering will rewire to it. The placeholder palette and mechanics in `design-system.md` exist so the extension *runs*, not because they're right. **Before producing anything, please read these two specs in the same folder — they're the inventory of what currently ships and the technical floors you have to work within:** 1. **`design-system.md`** — engineering's current visual sketch (color tokens, type stack, components, motion). Treat the *aesthetic content* as draft you can override; treat the *technical content* (Chrome API mechanics, MV3 CSP, badge mechanics) as floor. 2. **`assets-spec.md`** — concrete file deliverables: paths, dimensions, file-size floors, formats, three pathway options (auto-placeholder / design-first / commission) per asset. If anything in this brief or those specs conflicts with the direction the teams land on, **the teams win** for creative decisions and the **specs win for technical floors** (file sizes, Chrome API minimums, MV3 limits). Flag any conflict and we'll resolve it together. --- ## Open creative questions (non-exhaustive) > **RESOLVED 2026-05-17** per designer handoff + user ack. See > `brand-decisions-v1.md` for the 9 resolutions (D-01..D-09). The list below > remains as historical context for what was open before the handoff. For both teams to work through in whichever order makes sense. None are blocking engineering today (placeholders ship), but each unlocks a polish pass when answered. 1. Display name policy — keep `"AI Call Recorder"`, switch to `"Mokosh"`, coin something new, or run a bilingual lockup? 2. Design system name — option A/B/C/D from §3, or other? 3. Localization defaults — Russian-first `manifest.json` with English override, or English-first with Russian override? 4. Voice register — one tone across all surfaces, or two (system-terse vs welcome-prose)? 5. Palette — keep monochrome-with-accent direction, or shift to multi-accent / warm / clinical / other? 6. Corner radii — sharp / soft / mixed? 7. Typography — system stack or custom face? If custom, what? 8. Iconography style — solid / line / mixed? Per-state icon swaps or fixed mark + dynamic badge? 9. Motion vocabulary — minimal, expressive, or none? 10. Welcome-tab layout — hero+steps, scrolling story, modal, video walkthrough, or other? 11. Hero treatment for the welcome tab — wordmark-only, mark+wordmark, or illustrative scene? --- ## Related - `design-system.md` — engineering's current visual sketch (override at will) - `assets-spec.md` — file deliverables + technical floors - `manifest.json` — where the display-name decision lands - `.planning/PROJECT.md` — engineering-level product framing (audience, technical constraints)