LlamaCasty/TASKS/task-48-distribution-msix.md

TASK 48 — Distribution & packaging: route decision, MSIX, signing

⛔ THE ROUTE IN THIS FILE IS SUPERSEDED — 2026-10-31. Distribution is Steam exclusive: a free app on Steam with the paid edition as a Steam DLC; the monthly plan is sold off-Steam. There is no direct download, no winget and no Store submission. Live policy: docs/ai/commercial.md; mechanics: Distribution.md. The MSIX build steps below still work and are simply unused.

Catalog: TASKS.md — status and requirements live here. Research: TASKS/research-store-certification.md — the "why". Carved out of TASK 36 item 6 (release engineering) on 2026-09-27 so distribution has one owner instead of three scattered mentions.

Status: ⏸ DEFERRED 2026-10-26 (creator ruling) — revisit near v1, not now. This file is the record of what was decided and built, not an active queue: the remaining programming work is far from release and a complete UX redesign comes first. See TASKS.md → Open items → the ⏸ TASK 48 bullet for exactly what is frozen (items 6-8, signing, updater, and the route contradiction against ai.md). Do not start or re-litigate any of it before that revisit.

Historical status: 🔶 In progress — ✅ ROUTE DECIDED 2026-09-27: Microsoft Store MSIX + Store IAP. Polar is deleted; every licensing subsystem goes with it.

Goal: get LlamaCasty in front of a user without a SmartScreen scarewall, ideally without an annual certificate bill, and without breaking recording, capture, or audio.

---

0. ✅ THE DECISION — Microsoft Store, MSIX, Store IAP (creator ruling 2026-09-27)

Creator's stated criteria, verbatim: "zero headaches, minimal maintenance (for me) while still providing accountability and a reasonably easy upgrade flow."

Ruling: distribute as an MSIX package through the Microsoft Store, and take payment through Store IAP. All four criteria are satisfied by the same mechanism:

Criterion	How MSIX + Store IAP satisfies it
Zero headaches	$0/yr — Microsoft holds the signing certificate, the reputation, and the installer. No cert, no HSM, no annual renewal, no SmartScreen ramp
Minimal maintenance	Microsoft handles updates, payments, entitlements, refunds, and customer support. Nothing to run
Accountability	Microsoft reviews every submission — that is the accountability layer, and it is a real one
Easy upgrade flow	Store auto-update. Velopack, the update URL, and the DO droplet all go

The consequence that makes this cheap: the entire licensing subsystem is deleted

Choosing Store IAP over Store+Polar is what makes "minimal maintenance" real. Keeping Polar would have left the creator maintaining a licensing backend, a customer portal, activation limits, and an offline-grace machine — the exact burden the ruling was made to avoid.

Dead code / deleted concepts (TASK 10 is now a teardown, not a build):

• Services/PolarLicenseService.cs — HTTP validation, the swallowed network failures, the ignored expires_at
• Helpers/PolarLicense.cs — the record type
• ViewModels/MainViewModel.License.cs — PremiumUrl, the customer portal, the OfflineGracePeriod = 14 days subscription-era artifact, renewal/lapse copy
• Controls/OverlayHost.xaml — the incorrect "Polar unlocks alerts" copy resolves itself
• ytLive.csproj:92 Velopack PackageReference + App.xaml.cs:3,38-46 — see item 3
• The MONETIZATION.md provider sections (gitignored — local file)

What replaces it: IsPremium is derived from the Store entitlement instead of a remote HTTP call. One bit, locally cached, refreshed by the OS. The offline-grace machine disappears because the OS supplies license state — and with it the whole class of "network flaky → app thinks I'm expired" bugs.

⚠️ The watermarks posture is unchanged: free gets everything; the branding flash stays the ONLY paid delta (TASK 36 item 2). Store IAP changes how the bit is obtained, never what it gates.

Still to verify (does not block packaging work)

• ☑ Current Store revenue-share terms — VERIFIED 15%, subscriptions included. Read from the ADA v8.10 PDF (downloaded and text-extracted), §6(b): 15% for Apps and their In-App Products not listed in 6(b)(iii); 12% is Games-only; 30% is Xbox console / Xbox non-subscription IAP / Windows 8. LlamaCasty is a Windows PC App, so 6(b)(i) 15% governs ⇒ $8.50/mo net, $340 lifetime net. The agreement's own changelog (v8.0, Oct 26 2017) states it plainly: "implement the 85/15 revenue share for non-Game subscriptions." Smaller-indie better rates were not found in the standard terms. Microsoft also requires that any IAP products and their pricing be declared in Partner Center.
• ☑ Store IAP tier shape — ✅ DECIDED 2026-09-27: $10/mo subscription + $400 lifetime, no annual. Declare two products in Partner Center: one auto-renewing monthly subscription, one non-expiring lifetime IAP. ⛔ No .99 prices (settled). ⛔ No annual product — Microsoft does not pro-rate: "monthly subscriptions and initial (pre-renewal) purchases aren't eligible for a prorated refund", so an annual sub cancelled in year 1 forfeits the remainder and the developer cannot refund it. Net after the 15% Store Fee (verified, §6(b)(i) — applies to non-Game subscriptions too): $8.50/mo and $340. Note ADA §6(h): we must fulfil the subscription for the whole period, and raising the price disables auto-renew — so $10 is effectively locked for the product's life. ⛔ A discounted subscriber→lifetime upgrade SKU is not approved; do not declare one.
• ☐ Individual vs Company Partner Center account (10.8.3 / 10.14 — see research-store-certification.md §11 item 1). Get this right before enrolling; a Store+IAP product needing financial info for primary functionality would require Company, but a free product with a paid upgrade tier is the normal consumer shape and is fine on an individual account.

---

1. ☑ Bundle ffmpeg instead of downloading it — SHIPPED 2026-09-28

This is item 1 because it is genuinely first — it fixes a user-facing failure on its own and is a hard certification gate.

Services/Encoder/FfmpegLocator.cs used to pin a GitHub release URL, download it on first run, extract it, and execute the result. On a cold cache the app downloaded an unsigned executable from the internet and ran it.

• Store blocker: policy 10.2.2 forbids dynamic code inclusion (download-and-execute).
• Route-independent bug class: the previous daily pin aged out of GitHub retention and 404'd on the first real recording attempt (2026-09-01). Bundling kills this permanently and removes the startup network dependency.

What shipped (2026-09-28, eb0dd91 docs + this unit):

• scripts/fetch-ffmpeg.sh — populates ./ffmpeg from a pinned month-end BtbN LGPL-shared artifact, SHA-256 verified before extraction, idempotent, FFMPEG_ZIP= override. The binaries are gitignored (135 MB of DLLs would tax every commit on the 9p tree); the pinned URL + SHA-256 are the audit trail the LGPL written-offer actually needs.
• ytLive.csproj — copies ffmpeg\** to the output with CopyToPublishDirectory="Always" (the MSIX one), plus a GuardBundledFfmpeg target that fails the build if the folder is missing, so a fresh clone finds out before a take rather than during one.
• FfmpegLocator — downloader, zip extraction, and the %APPDATA%\ytLlive\tools cache are all gone. Order is now bundle → PATH (deliberately inverted from "the user's install wins": a PATH ffmpeg may be a different major version or a GPL build). A missing bundle throws a loud IOException naming the folder and the fetch script — the "found something on disk" path that could mask a missing bundle is deliberately deleted.
• ffplay.exe (18 MB) is not shipped; nothing calls it.
• THIRD-PARTY-NOTICES.txt — "downloads" → "bundled" throughout, and the stale build tag autobuild-2026-08-09-13-03 (the tag that 404'd) corrected to autobuild-2026-08-31-13-27 with the exact artifact name and archive SHA-256 recorded. OpenH264 item made precise: it is compiled into avcodec-63.dll, not a separate binary.

Immutable tag (licensing rule): autobuild-2026-08-31-13-27, artifact ffmpeg-N-126342-gf88b741dbf-win64-lgpl-shared.zip, SHA-256 46ea6521ed3877689d2ff0bd03640ac2637104415f6237d42625d13408767146. The URL is now a provenance record, not a runtime fetch. Month-end on purpose: BtbN keeps ~14 dailies but month-end builds ~2 years — a daily pin is what aged out.

Licensing: the LGPL-shared build was chosen for LGPL §6 compliance (dynamic linking = "license text + source offer"). That reasoning is unaffected, and the notices now cover the bundled copy explicitly.

Tests (16 facts, FfmpegLocatorTests, suite 379/379): the Good Dog integration test walks the real build output, asserts the 9 files ship, resolves via the locator with an empty PATH, and executes ffmpeg -version — running it is the part that matters, because a shared build only starts if every libav*.dll is a sibling. Plus: bundle-over-PATH, PATH fallback, zero-byte bundle, the loud failure, TheBuildRefusesToCompileWithoutTheBundle, and TheLocatorCarriesNoNetworkCapability — a source-level fact that no HttpClient/URL/downloader can reappear, so 10.2.2 cannot rot back.

Answering "were there other 3p binaries needing bundling?" (verified 2026-09-28): no. ffmpeg was the only download-and-execute. e_sqlite3.dll + WebView2Loader.dll already ship via NuGet into runtimes\win-x64\native\; OpenH264 is inside avcodec-63.dll; everything else is managed. The two real gaps are not bundling problems: the WebView2 Evergreen runtime is a machine prerequisite (item 2's manifest dependency + a graceful-failure path), and Velopack's updater downloads and executes — its teardown (item 3) is a compliance action, not just cleanup.

---

2. ✅ Package.appxmanifest — full trust, camera, microphone (DONE 2026-10-22)

There was no .manifest file in the repo at all, so this was purely additive.

Shipped: Packaging/Package.appxmanifest + Packaging/Assets/ (the four logo tiles) + scripts/package-msix.sh (publish → stage → makeappx pack, optional signtool via MSIX_PFX). The first real package was built on 2026-10-22: Package creation succeeded, 159 MB, 509 files in artifacts/LlamaCasty.msix (gitignored). The logos are generated from the app's own artwork by scripts/make-store-logos.py, so listing art and app art cannot drift.

• rescap:Capability Name="runFullTrust" — medium integrity, not AppContainer
• DeviceCapability webcam and microphone
• uap10:TrustLevel="mediumIL" and uap10:RuntimeBehavior="packagedClassicApp" on <Application> — the latter is what allows launching package executables (the bundled ffmpeg) as child processes
• English only (<Resource Language="en-US"/>) — 10.7: otherwise the description must be localized into every declared language
• Block map SHA2-256 is generated by makeappx; no StoreManifest is needed for a plain MSIX submission; 159 MB is far under the 25 GB cap
• x64 only (creator ruling 2026-10-09 — PlatformTarget=x64 already in both csproj files): ProcessorArchitecture="x64", published -r win-x64 --self-contained so only the win-x64 native folders ship (an RID-less build copies every RID's ONNX Runtime native, ~17 MB each) and the package carries its own .NET runtime. Store listing system requirements: "64-bit Windows 10 or 11".

Do NOT use appContainer — see the invariant in item 6.

Schema gotchas found the hard way (the packer rejects the manifest, one error at a time): Square310x310Logo and Wide310x150Logo are NOT attributes of uap:VisualElements in the Windows 10 schema — they belong on <uap:DefaultTile>, a child of VisualElements. And Assert.DoesNotContain("appContainer", manifest.ToString()) fails on the manifest's own comment: guard the attribute values, not the file text.

Guard: ytLive.Tests/StorePackagingTests.The_package_manifest_declares_full_trust_camera_and_microphone — identity (x64), full-trust application element, the three capabilities, no appContainer value, en-US only, and every referenced logo exists in Packaging/ (makeappx refuses to pack otherwise).

3. ✅ Remove Velopack — 3 edit sites (DONE 2026-10-22)

The Store handles updates, so this is simply deleted. Trivially removable; the code was written defensively for exactly this.

• ytLive.csproj:92 — <PackageReference Include="Velopack" Version="1.2.0" /> — REMOVED
• App.xaml.cs:3 — using Velopack; — REMOVED
• App.xaml.cs:38-46 — the sole call site (already try/caught and commented "(non-fatal) … when no URL is set, the check is a no-op") — REMOVED

Guard: ytLive.Tests/StorePackagingTests.cs — the ONE test asserts the app project references no updater package (Velopack/Squirrel/NetSparkle/AutoUpdater/WinSparkle) and that no app source file uses the updater API (matched as CODE — a using directive, a type usage — not as a bare word, so a file's prose may still name what it deliberately does not do). The app was smoke-tested after the removal: MainWindow loaded, no exceptions.

Retires: the pending "Velopack update URL" item (TASKS.md open items, task-10-monetization.md:43) and the self-hosted DigitalOcean droplet.

4. ☐ Windows App Certification Kit

Run before submission. Technical compliance is tested by WACK; it is not optional. Known relevant check: the app must start promptly, stay responsive, and shut down gracefully (10.4.2).

5. ☐ Certification notes + the three documentation artifacts

In Partner Center (submission):

• ☐ The IARC age-rating questionnaire (10.11.1) — general audience, 12+ territory
• ☐ A working YouTube demo account (10.3.1) — the app is useless to a reviewer without one. Must be a real, maintained account able to sign in and start a stream; a dead or credentials-lapsed account is a rejection. ⛔ This was accidentally dropped from this list during the Store-IAP edit — it is in research-store-certification.md §4 and must be done.
• ☐ Declare the IAP products and their pricing in Partner Center (required for Store IAP). ⛔ No .99 prices — creator ruling, and incoherent for a no-dark-patterns brand. Confirm the net after the revenue share, not the list.
• ☐ Note that the product is general audience, not directed at under-13s
• ☐ The 11.12 UGC position is less load-bearing now that Polar is gone — the strong part of the original argument was "we render transiently, persist nothing, and provide no user-to-user communication surface," which is unaffected. State it in full anyway; the reasoning and the Q1-2026 YouTube enforcement numbers are in research-store-certification.md §9
• ☐ The YouTube age-gate argument — the operator is 13+ by construction (§8)

On llamachile.shop:

• ☐ Privacy policy (10.5.1 — mandatory for Win32/Desktop Bridge). Must state: camera/mic access is user-directed and OS-gated; no retention of chat or reward payloads; no viewer data collected; ffmpeg is bundled and nothing is fetched at runtime
• ☐ Code of conduct + content guidelines (11.12 / 11.15)
• ☐ Confirm THIRD-PARTY-NOTICES.txt covers the bundled LGPL ffmpeg build

In Partner Center (listing):

• ☐ Title is exactly LlamaCasty — 10.1.1 forbids marketing text or extraneous keywords
• ☐ Search terms: max 7, no pricing terms, and no other product titles (10.1.3 — cannot list OBS or StreamYard)
• ☐ Real listing content — 10.1.4 requires an active, substantive presence
• ☐ Review the Individual vs Company account question before enrolling

6. ☐ The full-trust recording invariant — comment lands WITH this work

ViewModels/MainViewModel.Recording.cs:173-179 (DefaultRecordFolder()) writes to %USERPROFILE%\Downloads or SpecialFolder.MyVideos; ChooseRecordFolder() (line 151) uses Microsoft.Win32.OpenFolderDialog; the temp-write-then-move lifecycle stays in one directory (line 131-132).

This works only because the package is full trust. At mediumIL, user-profile writes pass through unvirtualized and OpenFolderDialog is an ordinary Win32 browser with no capability token. No broadFileSystemAccess needed.

⚠️ If anyone flips the manifest to appContainer, recording silently breaks — Directory.CreateDirectory and File.Move start resolving to a per-package virtualized location and output vanishes.

Add a comment at DefaultRecordFolder() in this task, not before. A comment describing a manifest that does not exist is worse than no comment.

Also verify on a real packaged build before trusting it with recordings — the docs say full trust passes writes through, but that is worth confirming with an actual package identity rather than an unpackaged run.

7. ☐ Confirm the disqualifiers stay clear after packaging

All four are currently clear (verified by grep 2026-09-27) — re-verify once the packaging project exists:

• No Windows driver installed (we consume DShow filters, we do not install one)
• No per-user Windows service
• No elevation / requireAdministrator / UAC manifest
• No shell extension, no in-process module loading by outside processes, no jump list

8. ☐ Pre-submission gates

• ☐ 0 warnings, full suite green
• ☐ Vertical-recording path verified end-to-end (compositor tier is proven by Render_VerticalTier_Outputs_1080x1920_From_The_Center_Crop; the record path has never been exercised — Services/Pump/FramePump.cs:645 flags off-size tiers as a known follow-up)
• ☐ The real-output confirmation the creator has been doing manually
• ☐ Camera/mic/wasapi capture verified from the packaged build, not just unpackaged
• ☐ Clean uninstall verified (10.2.7)
• ☐ Notification-disabled path leaves the app functional (10.9)

---

Not in this task (deliberately)

• Velopack hardening / obfuscation / assembly splitting — stays a GA-time decision per TASK 36 item 6's agreed ceiling. Compile flags max at HARDENED + MOCK_REWARDS, additive-only.
• EULA draft/review and the THIRD-PARTY-NOTICES gate — stay in TASK 36 item 6.
• Vertical-canvas feature work — the feature exists; only the record-path test above is missing.
• macOS / Avalonia port — deferred; would be a second app, not a port.