# 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) 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)