mokosh/.planning/intel/brand-identity.md

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