Wallet-Marken-Landing vs. echte Extension-Scope (Wallet Marken Landing Vs Echte Extension Scope)

Ein Download-Button ist keine Signing-Engine

Die wallet-app verkauft die Marke Bare Wallet über Home und Download-Tabs (Chrome, Firefox, Opera, Brave, Edge). public/manifest.json ist CRA-Standard-PWA (short_name: React App, display: standalone) — kein manifest_version, kein Service Worker, kein chrome.runtime, kein Content Script. Diese Case Study verengt den Scope absichtlich: Produktoberfläche = Funnel; echte Browser-Wallet = anderes Architektur-Universum.

What shipped (Bare Wallet app)
  CRA React SPA
    Home (brand)
    Download tabs (install CTAs)
    public/manifest.json  ← PWA sample, NOT MV3

What a real extension needs
  MV3 manifest_version: 3
    background service worker
    contentscripts / injected provider
    permissioned RPC + keyring
    popup UI ≠ marketing landing

Dieser Teil schreibt das ADR, Marken-Landing nicht mit echter Extension-Scope zu verwechseln.

Begriffe, dort definiert, wo sie zuerst auftauchen

📦 Marketing-SPA
SPA, die Vertrauen und Download-CTAs verkauft, bevor eine Wallet installiert ist.

📦 PWA-Manifest
Hinweise für installierbare Web-Apps — nicht die Extension-API.

📦 MV3-Extension
Manifest-V3-Add-on mit Service Worker, Permissions und injiziertem Provider.

📦 Scope-Ehrlichkeit
Repo-Inhalt von Marketing-Implikationen trennen.

'Install for Chrome' in der UI heißt nicht, dass das Repo chrome.scripting enthält.

Was ist wirklich da?

Routen: Home und Download. DownloadPage zeigt Tab-CTAs; manche Labels wirken vertauscht — Funnel-Prototyp, keine Extension-Qualität. Kein Web3-Signing, kein Keyring, kein Chain-Switch.

PWA ≠ Extension

CRA-manifest.json hat Icons, start_url, display: standalone. Eine Chrome-Extension braucht manifest_version, background.service_worker, host_permissions, content_scripts.

ADR: Wallet product surface
  Decision: ship brand landing + download funnel only
  Non-goal: Chrome MV3 keyring / injected ethereum provider
  Why: marketing speed; wallet core is a different product
  Risk: users confuse CTA with installed extension
  Mitigation: honest copy + separate extension repo when real

Echte Extension-Architektur (Kontrast)

Production-Wallet: gesperrter Keyring, Confirm-Popup, Provider-Injection, Netz-Management, Phishing-Warnungen, Update-Kanal. Die Landing-SPA trägt nichts davon.

Dieselbe Ehrlichkeit wie beim Generator

Der vorherige Teil hält Trait-Vokabular explizit. Dieser Teil hält die Produktgrenze explizit: Bare Wallet = Funnel. Die Case Study bläht nicht auf.

Die am häufigsten verwechselten Zuordnungen

❌ CRA-Manifest = Chrome-Extension
✓ PWA-Hinweise ≠ MV3-Vertrag

❌ Download-CTAs beweisen eine Extension
✓ CTAs sind Marketing; Runtime-APIs sind Beweis

❌ 'Wallet' im Landing = Keyring
✓ Name ist Marke; Scope per ADR begrenzt

❌ Scope aufblähen fürs Portfolio
✓ Ehrlicher enger Scope ist vertrauenswürdige Case Study

Checkliste zur Prüfung des eigenen Systems

1. Kommt manifest_version oder chrome.runtime im Repo vor?
2. Führen Download-Buttons zu echten Store-URLs oder toten CTAs?
3. Welches Nutzerversprechen erfüllen PWA-Felder wirklich?
4. Welche Sicherheitsmissverständnisse entstehen bei 'installiert'?
5. Gibt es separates Repo/ADR für eine echte Extension?

Was aus diesem Teil bleiben sollte

1. Bare-Wallet-App ist Marken-Landing / Download-Funnel.
2. CRA-PWA-Manifest ist kein MV3-Beweis.
3. Ehrlicher Scope schlägt aufgeblähten Wallet-Claim.

'Wallet' schreiben und Wallet sein sind nicht derselbe Commit.