LlamaCasty/docs/ai/product.md

# Product: brand, licensing, monetization & distribution

What the product is called, what it promises, what it may never do legally, and how it ships.
Read before branding, marketing, pricing, licensing or packaging work.

## Brand

**The UI design standard is [`DESIGN.md`](../../DESIGN.md)** — colours, type scale, spacing, radii
and elevation, all normative, implemented by `Themes/Tokens.xaml`. Accent blue `#38bdf8` is the only
interactive accent; red `#ff5451` means live/record and nothing else. The old brand red `#e94560` is
retired from app chrome (the wordmark/logo artwork is unchanged).

Marketing palette, official assets and copy live in `MARCOM.md` (gitignored — read it before any
branding or marketing work).

### Product name vs repo/assembly branding (2026-09-14)

The product is **llamacasty** (llamacasty.com, llamachile.tube, `llgit.llamachile.tube`). The
repo path, csproj `AssemblyName`/`RootNamespace`, DB/log paths (`%APPDATA%\ytLlive\...`),
and most internal namings are the legacy **ytLive/ytLlive** — a re-brand that never renamed
the internals. Treat the two as separate: external/user-facing language says "llamacasty",
code/assembly/repo names stay `ytLive`. If a full internal re-brand is ever done, this note
and the UI locator (Premium/wordmark) are the checklists; it is NOT a goal pre-1.0.

**Say "LlamaCasty" when reporting to the creator** — never "ytLive" in prose. `ytLive` is
the internal repo/assembly/namespace name only. Exact current split:

| surface | name | note |
|---|---|---|
| product / site / marketing | **LlamaCasty** | llamacasty.com, llamachile.tube |
| repo dir, csproj file, `RootNamespace` | `ytLive` | 230+ files: `namespace ytLive.*` |
| `AssemblyName` → shipped exe | **`LlamaCasty`** | `LlamaCasty.exe` — renamed 2026-11-01 |
| app data dir | `%APPDATA%\ytLlive` | **capital L**, drifts from `ytLive` |

**Consequences, so nobody re-hunts them:**
- The assembly rename landed 2026-11-01 (before the first Steam depot, because Steamworks warns
  that renaming a live exe is painful). Namespaces stay `ytLive.*` — they are not user-visible
  and renaming them would churn every file for nothing.
- An assembly-qualified pack URI spells the assembly name, so the rename **hard-breaks silently**
  at runtime, not at compile time. Four carried it, not three:
  `MainWindow.xaml:14` (window icon — taskbar/Alt-Tab), `OverlayHost.xaml:96`,
  `RenameRecordingDialog.xaml:5`, and `KeepBroadcastDialog.xaml:5`.
  `ytLive.Tests/AssemblyIdentityTests.cs` now guards both halves: the assembly name is
  `LlamaCasty` and no source XAML still names the legacy assembly.
- `Packaging/Package.appxmanifest` (`Executable`) and `scripts/package-msix.sh` carry the exe
  name too; the MSIX is unused but must not lie about the artifact.
- Renaming the `%APPDATA%\ytLlive` folder is **breaking** — it would orphan every existing
  user's layout DB, `Assets` and settings. Never do it casually; needs a migration.
- No code compares its own assembly name (no `GetExecutingAssembly().GetName().Name` checks),
  so the assembly name is otherwise free to change.

### AI transparency

This project is built through AI-assisted pair-programming. All code is generated
under the supervision of an experienced developer with decades of coding experience.
Architecture decisions, product direction, and quality gates are human-owned;
AI accelerates implementation. This is a testimonial to successful human-AI
collaboration, not autonomous code generation.

## Licensing — proprietary since 2026-10-30

**LlamaCasty is closed-source commercial software.** `LICENSE` is the EULA; the paid tier exists
because output quality is the paid delta — the free tier is capped at a 720p30 profile (creator
ruling 2026-10-30, superseding free-forever). Prices, entitlement and channels:
[`commercial.md`](commercial.md).

- **Every GPL build already published stays GPL for that snapshot.** Attribution/§7 terms
  (`ADDITIONAL-TERMS.md`) are deleted and were GPL-only; the files are gone.
- **No GPL third-party component may be linked.** ffmpeg stays a separate subprocess (LGPL,
  relinkable via the shared build), OpenH264 ships as Cisco's binary, the rest are MIT/Apache/CC0.
  Never add a statically linked GPL library — that would make the commercial build undistributable.
- **Obligations that still bind** (they are third-party, not ours): keep `THIRD-PARTY-NOTICES.txt`
  shipped and shown in About, ship full licence texts at v1, keep the ffmpeg pin immutable and
  `lgpl-shared`, never use the `nonfree` variant, keep icon art CC0/public-domain, keep the ML model
  provenance clean (Google MediaPipe, Apache-2.0 — no model-zoo re-hosts).
- **Fonts:** Inter + JetBrains Mono are OFL-1.1, bundled as separate files with their licence text —
  allowed in a commercial product, but the fonts may not be sold on their own and must not be
  modified under the reserved names.
- **Brand artwork** (name, icon, logo) is the publisher's property; the EULA grants no trademark
  rights and forbids implying endorsement.
- **No source offer.** The GPL §6 source link is gone; the repo is private.

## Design Principle

> This software is so intuitive that even the most right-brained person can easily intuit and use it.

Apply this to every UI decision:
- One-click go-live with working defaults
- Prefilled YouTube defaults (RTMP URL, bitrate, resolution, latency)
- Visual/drag-and-drop scene building over property panels
- Every action produces a visible outcome — no dead ends
- **"We're not them" (2026-09-01):** assume the creator's hardware is mediocre, because it is.
  Every feature spends the machine's budget once — never twice for the same result (record OR
  stream, not both; one reusable stream; one webcam; two mixer inputs). If a feature only sings on
  a high-end chassis, it doesn't ship — the OBS escape hatch is open by design.

## Monetization — free tier + Pro output quality

**Every feature is free and ungated** (creator ruling 2026-10-08, TASK 54, kept by the 2026-10-30
freemium ruling): no feature lock, no watermark, and nothing licence-shaped in the output. The
paid delta is **output quality alone** — free is capped at a 720p30 profile, Pro unlocks the
higher tiers for **both the stream and the recording**. Prices, entitlement and channels:
[`commercial.md`](commercial.md). Support is email + GitHub issues; an in-app bug reporter is out
of product.

**The branding credit is retired as a paid delta and stays off.** `MainViewModel.ShowBrandFlash`
(internal static, default `false`) is the master switch; `BrandFlashEnabled => ShowBrandFlash &&
!IsPremium` feeds the presenter. The code is kept, not deleted — creator ruling: *"don't delete
it, just make it conditionally displayed."* Entitlement must never enable it.
`BrandFlashOutputTests` opts in by setting the switch before constructing a `MainWindow`;
`Credit_IsOffByDefault_EvenOnTheFreeTier` guards the default.

If it is ever enabled, the mechanics that matter:

- Full-frame neon "made with LlamaCasty!" at a **random position per presentation**, held **2s**
  (500ms in / 1000ms full / 500ms out), first ~5s after start then every `rand(30s)+30s`.
- Published to the frame pump and the preview from the **same** `VideoFrame`, so preview and
  broadcast cannot drift. Deliberately **not** folded into `SceneGraph.GetBakedBase` — the bake
  cache compares element ids and would freeze the credit in place.
- **App-lifetime cadence:** the presenter is `Start()`ed once in the `MainViewModel` ctor, not per
  go-live, because go-live and local recording share one `FramePump`. `IsPremium`'s setter therefore
  restarts the cadence timer when re-enabling (`IsCadenceTimerEnabled` is the test seam).
- **It composites into the recording and the stream** (reversed 2026-09-26 — the free tier must be
  honest advertising). Test arithmetic trap: `Advance(5.1)` in one call blows through the 2s window
  (it both opens and ages the presentation) — step in 1/30s increments like `BrandFlashOutputTests`.
- **A mid-credit downgrade** cuts the advertisement on the next tick: the presenter re-checks its own
  `Enabled` gate every frame rather than letting the credit finish.

Live prices, entitlement and channels: [`commercial.md`](commercial.md). Retired pricing, the
Store IAP plan and the rejected alternatives: [`decisions.md`](decisions.md).


**Monetization awareness (built-in, ungated, free — 2026-09-01; v1 SCOPE per the complete-v1
ruling — build order: capture → report → journey → Alerts):** the app is monetization-aware by
design, for **every** creator, free and ungated. It has three layers, all free — the capability no
competitor ships (the positioning order across features lives in `MARCOM.md`):

- **Reward-event capture (the data foundation).** The live-chat poll (`YouTubeChatService.Poll`)
  receives every reward event over `liveChat/messages` and — since TASK 43 (2026-09-24) —
  **decodes all six types**, not two: `superChatEvent`, `superStickerEvent`, `newSponsorEvent`,
  `membershipGiftingEvent`, `giftMembershipReceivedEvent`, `memberMilestoneChatEvent` land as
  `ChatMessage.Kind` (`ChatEventKind`) with their payload fields (display string, sticker
  description, gift count, gifter name, milestone months); free subscriptions emit NO event
  (API fact — a sub mention is a plain text row). The remaining half of the original capture
  plan stays open (TASK 3 item 20): persist each event to the canonical SQLite `RewardEvents`
  table (broadcastId, type, timestamp, amountMicros, currency, tier...) + `superChatEvents.list`
  (30-day lookback) backfill — that persistence is what the session report and the journey
  tracker read. Alerts did not wait on it: the shipped alert path (TASK 43) renders directly
  from the in-memory `ChatMessage` feed.
- **Session / broadcast report.** A session is created at Go Live; the poll + End roll that session's
  reward totals (new members, Super Chat $, stickers $, gifts, milestones). This is the in-app
  replacement for the emailed external "stream activity report" — the incumbents (Streamlabs et al.)
  email near-useless post-stream summaries; we track the same data natively and maintain it.
- **Journey tracker (TASK 39, slice 1 shipped 2026-09-22).** A **"YPP"** tab below the
  Stream Settings pull-out (Live screen right edge) shows the connected creator's position
  toward each YPP tier threshold. Slice 1 = current-scope data only: `channels.list?mine=true
  &part=statistics,contentDetails` (subs/views/videos + uploads-playlist id) +
  `playlistItems.list` for 90-day public uploads. Every refresh appends
  a `YppSnapshot` to SQLite (schema v10) — the history a later slice needs for velocity/ETA.
  **The `auditDetails` part is OUT (fixed 2026-09-23):** readding it 403s the WHOLE request —
  that part alone requires the `youtubepartner-channel-audit` scope no app for normal creators
  should request (the standing flags sat unreadable since slice 1 shipped; the app's `youtube` +
  `youtube.force-ssl` scopes were never sufficient for them — the "no re-consent" slice-1 claim
  was wrong for that part). Channel standing now deep-links to the Earn page; API stats come from
  `statistics,contentDetails` only. YPP/API failures log the response body's `error.reason`.
  **YPP thresholds are versioned, date-aware DATA, never constants** — the Tier-2 bar doubles
  for new applicants on **2027-02-01** (long-form 4,000 → 8,000 qualified hrs / 365d; Shorts
  10M → 20M / 90d), while the Tier-1 fan-funding bar (500 subs / 3,000 hrs / 3M Shorts) is
  unchanged. Hardcoding the pre-2027 numbers would ship the wrong ETA. Watch-hours / Shorts /
  velocity / ETA are **slice 2**: Analytics-API scopes (`yt-analytics.readonly`, additive
  `yt-analytics-monetary.readonly`) behind the `IChannelStatsProvider` seam (additive
  capability, requires an OAuth re-consent). Compliance items no API exposes (2FA, AdSense
  linkage) are in-app self-reported checkboxes with deep links; channel standing (exposed only
  via the partner-audit scope) deep-links to the Earn page. Slice 2's once-daily refresh gate +
  snapshot history were baked into slice 1.


## Auth gates Go Live, but not exploration

The app is fully usable without authentication: users can build scenes, add sources, compose
previews, and audition the software with zero commitment. But **going live requires authentication** —
it's the one capability gated behind YouTube sign-in. The sign-in should never pressure the user
("sign in (optional)", not a modal wall): the two-state top bar shows **Start Stream** (offline) /
**End Stream** (live), and the Start Stream dialog hosts the account — a saved session appears as
the default with "Change Account"; with none saved, a "Sign in to YouTube" button starts OAuth and
the Start button stays disabled until signed in.

## Account assumption (do not build an account setup flow)

Connecting uses Google OAuth ("Sign in with Google") to link an **existing** YouTube creator
account. ytLlive **never creates or sets up accounts** — that is YouTube's job. If the creator has no
YouTube channel, they go to YouTube first. This assumption is explicit and must never be silently
replaced by an in-app account-creation step. Zero state = the Start Stream dialog's "Sign in to
YouTube" button; going live is unreachable until an account is connected.

## Windows packaging & distribution (Steam only)

Live channel policy, the artifact and costs: [`commercial.md`](commercial.md). Build and depot
mechanics: [`Distribution.md`](../../Distribution.md). Retired routes and cause of death:
[`decisions.md`](decisions.md).

**One vector: Steam.** One paid app plus its associated free Demo. They use the same code; the Demo
checks ownership of the paid app to unlock higher output quality. No direct download, no GitHub
binary, no winget, no Microsoft Store, and no subscription.

**Consequences that are architecture, not packaging detail:**

- **⛔ There is no self-updater, and now no version banner either.** Steam delivers updates; the
  app keeps nothing that downloads or executes, for the same Store-policy reason it always had.
  `ytLive.Tests/StorePackagingTests.cs` must keep asserting that no self-updater returns.
- **⛔ `steam_api64.dll` is a functional dependency**, not the rejected "native helper DLL for IP
  protection" — Steam app ownership cannot be read without it. The app must start without Steam
  running and fall back to the free profile.
- **The MSIX package stays buildable but is now unused** — `scripts/package-msix.sh` (TASK 48
  slice 2) still produces `artifacts/LlamaCasty.msix` from `Packaging/Package.appxmanifest` +
  `Packaging/Assets/`. It was the Store channel's artifact; with Steam exclusive there is no
  submission target. The full-trust `packagedClassicApp` findings below remain true and are still
  worth reading before any packaged build is attempted.
- **⛔ Bundle ffmpeg — no runtime downloads** (was Store policy 10.2.2; still right for a Steam
  depot, and it fixes the 2026-09-01 404). See [`output.md`](output.md) → "FFmpeg locator".
- **⛔ 64-bit Windows only (creator ruling 2026-10-09).** Both csproj files set
  `<PlatformTarget>x64</PlatformTarget>` (the test project too — an AnyCPU test project
  referencing an x64 app raises MSB3270 and breaks the 0-warning gate). Why: the bundled ffmpeg
  is the win64 build, ONNX Runtime 1.31 ships no win-x86 native (only win-x64/win-arm64), and a
  32-bit address space can't hold the 1080p frame buffers. Windows 11 is 64-bit-only anyway.
  Public copy says "64-bit Windows 10 or 11".
- **Portable mode is a feature, not a channel:** `portable.txt` beside the exe keeps the layout DB
  and settings in `.\data\` (hung off `LayoutPathOverride`), so a copied install carries someone's
  scenes. Steam installs it; the marker is for afterwards.

**What does NOT change: no watermark and no feature gating.** The free tier is the whole app at a
720p30 profile. `Monetization` above governs.

### ⛔ Durable invariant: full trust, or recording silently breaks

MSIX packages run at one of two trust levels. A packaged WPF app declaring
`rescap:Capability Name="runFullTrust"` runs at **mediumIL — the same permissions as a
standard desktop app, NOT AppContainer** — and may spawn child processes, which is why
bundling ffmpeg is legal. Writes to user-profile locations (AppData, Downloads, MyVideos)
**pass through unvirtualized at mediumIL**; the package install folder is read-only.

**`ViewModels/MainViewModel.Recording.cs` writes recordings to
`%USERPROFILE%\Downloads` / `SpecialFolder.MyVideos` (`DefaultRecordFolder()`,
`ChooseRecordFolder()` via `Microsoft.Win32.OpenFolderDialog`), and the whole
temp-write-then-move lifecycle stays in one directory.** That works *only* because we are full
trust. No `broadFileSystemAccess` capability is needed, and none should be added.

⚠️ **If anyone flips the manifest to `appContainer`, `Directory.CreateDirectory` and
`File.Move` start resolving to a per-package virtualized location and output vanishes with no
error.** A comment at `DefaultRecordFolder()` is owed **when the manifest lands** (TASK 48
item 6) — not before; a comment describing a manifest that doesn't exist is worse than none.

### Signing — not needed, because Steam installs the app

Steam's client delivers the files, so there is no browser download, no Mark-of-the-Web and no
SmartScreen wall. **The certificate has no job in this channel.** It stays on the shelf for the day
a non-Steam download exists:

- **Azure Artifact Signing** (renamed from "Trusted Signing") — $9.99/month Basic, up to 5,000
  signatures, **requires a paid Azure subscription**; individual identity validation is the slow
  part and must be renewed.
- **Never EV** — Microsoft removed the EV SmartScreen instant-bypass in March 2024, so EV buys what
  OV buys. **Never a certificate with an HSM** for this product.
- **Steam does not sign the exe.** A UAC prompt for the app is elevation, not publisher trust.

### Distribution and licensing are independent — the channel never decides billing

Steam distributes the paid app and its associated free demo. They use the same code; the demo asks
Steam whether the current account owns the paid app, and the answer controls access to higher output
quality. The paid app is a one-time purchase: $79 during the announced launch period, then $99 on
the announced date. The app's EULA must expressly allow commercial and monetized streaming use.

### ⛔ "Only when the user says so" is enforced by Windows, not by us

Camera/mic consent is layered: Store policy **10.6** forbids circumventing OS checks; the
**Windows desktop-app camera/microphone toggle** (Settings → Privacy & security, since Win10
1903) is the gate; hardware lights and tray indicators are the OS's disclosure mechanism. So
**route everything through the standard MF/DShow/WASAPI paths and we never write that
certification ourselves** — the OS does it and gets neither our credit nor our blame.

⚠️ **Untested:** whether that toggle reliably gates a **DShow webcam and a capture card**.
Microsoft's own support page admits desktop apps "might still be able to access your camera
or microphone even when these settings are turned off." This is **not** a certification
failure (we declare `webcam` honestly and use supported APIs) but it is a real user-trust
issue — so **no privacy-forward marketing copy until it is measured.** Guard note added to
`MARCOM.md`.

### ⛔ Durable invariant: chat is rendered, never stored

`TASK 49`'s profanity filter is **local, on-device, opt-in, non-persistent**, with a
**user-supplied word list — never a hardcoded slur list baked into the binary** (unpleasant
artifact, false positives across dialects, extractable). It must **never match the SuperChat
amount or any reward field** — those are financial data under policy 10.5.5.

The non-persistence half is not just hygiene: it is the load-bearing half of the **11.12 UGC
certification answer** (mirrored YouTube chat is moderated at industrial scale upstream; ~1.6B
comments removed in Q1 2026 alone, child safety the #2 reason at 124.6M). **No future feature
— chat history, moderation logs, analytics, crash payloads — may quietly break that
assumption.** If one is ever proposed, the 11.12 position must be re-argued first.

### Minors

The **operator is 13+ by construction**, not by promise: LlamaCasty requires a YouTube
account to stream, and YouTube's ToS sets the account floor at **13** (regional variants reach
14; 13–17 need parent/guardian permission; under-13s are on supervised/YouTube Kids accounts).
So a COPPA theory premised on collecting PI from under-13s has no purchase against the
operator. The residual is **viewers** — still possible on supervised family accounts — and it
is weak: live chat is restricted there, YouTube moderates before we see it, and we persist
nothing. COPPA is very unlikely to bind (not child-directed), but note the enforcement trend
(FTC Sept 2025 *Apitor*: operators are responsible for what third-party components collect) —
so the answer is a documented inquiry, and ours is "no third-party analytics or ad SDKs, no
persisted chat or reward payloads."