docs(intel): unlock creative decisions across brand + design + assets specs
Adds brand-identity.md (Brief #1: name + blurb + creative slate). Rewrites design-system.md and assets-spec.md to flip aesthetic prescriptions into options while keeping Chrome MV3 / WCAG / icon-size floors as binding (marked (FLOOR) inline). Mokosh codename is the only locked decision; every other creative choice delegated to brand + design teams with explicit ownership annotations. Three-file intel pack now consistent: - brand-identity.md: brand-team primary (naming, voice, blurb) - design-system.md: design-team primary (palette, type, components) - assets-spec.md: design-team primary (deliverables + floors) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
283
.planning/intel/brand-identity.md
Normal file
283
.planning/intel/brand-identity.md
Normal file
@@ -0,0 +1,283 @@
|
||||
# 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)
|
||||
Reference in New Issue
Block a user