# Phase 0 — Machbarkeits-Spike

Vier Annahmen tragen das gesamte Projekt. Scheitert eine, sieht alles Weitere anders
aus — und das will man **vor** dem Bau der Infrastruktur wissen, nicht danach.

Der Code hier ist bewusst Wegwerf-Code. Was zählt, sind die Protokolle: sie werden
später zur Grundlage der Setup-Skripte in `rootfs/`.

| | Beweis | Wenn er scheitert |
|---|---|---|
| **S1** | Plasma Mobile läuft in proot (genestetes KWin) | XFCE-Profil wird Hauptweg; Kamera-Portal, Bildschirmtastatur und Telefonie-Oberfläche ändern sich mit |
| **S2** | Mikrofon-Eingang erreicht die Linux-Seite | Keine Videocalls, keine Sprachaufnahme, keine Spracheingabe |
| **S3** | Virtuelle PipeWire-Kamera ohne Kernel-Modul | Kamera nur in einer eigenständigen App, keine Browser-Videocalls |
| **S4** | Intent-Handoff Linux → Android-App | Keine Navigation aus dem Linux-Adressbuch |

Dazu der **Übernacht-Test**: überlebt der Stack eine Nacht mit gesperrtem Bildschirm?
Scheitert er, ist das ein früher Warnschuss fürs Gesamtkonzept, kein Detail.

## Voraussetzungen

- Android-Telefon, Adreno 6xx/7xx bevorzugt (Turnip-Pfad)
- **Termux von F-Droid oder GitHub** — nicht aus dem Play Store, die Fassung dort ist
  veraltet und unbrauchbar
- Einmalig `provision/provision.sh` vom PC, plus die dort genannten Handgriffe von Hand
- Etwa 6 GB freier Speicher (Debian-Rootfs, Plasma Mobile, Firefox)
- Geduld beim ersten Lauf: rund 1 GB Pakete

## Ablauf

```bash
# Einmalig, vom PC mit angeschlossenem Telefon
./provision/provision.sh

# Auf dem Telefon in Termux
bash spike/00-bootstrap-termux.sh

# Beweise in dieser Reihenfolge — S1 zuerst, weil er der wackligste ist
bash spike/01-s1-plasma-mobile.sh
bash spike/02-s2-mikrofon.sh
bash spike/03-s3-pipewire-kamera.sh
bash spike/04-s4-intent-handoff.sh
```

Jedes Skript fragt am Ende nach deiner Beurteilung und schreibt sie nach
`spike/out/ergebnisse.tsv`. Rohprotokolle liegen daneben in `spike/out/*.log`.

**Übertrage die Ergebnisse anschließend nach [`docs/spike-protokoll.md`](../docs/spike-protokoll.md).**
`spike/out/` ist absichtlich nicht im Repo — die Auswertung gehört dorthin, nicht die Rohdaten.

## Stellschrauben

| Variable | Vorgabe | Wofür |
|---|---|---|
| `HPOS_BREITE` / `HPOS_HOEHE` | `1080` / `2340` | Virtuelle Auflösung. Volle Panel-Auflösung ist für einen Telefon-Desktop zu viel Fläche |
| `HPOS_DAUER` | `6` | Sekunden Aufnahme in S2 |
| `HPOS_ZIEL` | Brandenburger Tor, Berlin | Navigationsziel in S4 |
| `HPOS_BEGLEIT_APP` | leer | Paketname einer Overlay-App, die in S4 vor der Navigation startet |

Beispiel:

```bash
HPOS_BEGLEIT_APP=de.blitzer HPOS_ZIEL="Kölner Dom" bash spike/04-s4-intent-handoff.sh
```

## Wenn etwas schiefgeht

**S1 startet nicht.** Das Skript probiert von selbst zwei Wege und fällt am Ende auf
XFCE zurück. Läuft XFCE, dann tragen X-Server und GPU-Pfad — der Fehlschlag liegt dann
eindeutig bei Plasma. Läuft auch XFCE nicht, liegt es an X-Server oder GPU.

**S2 erzeugt eine Datei ohne Ton.** Der häufigste und tückischste Fehlschlag. Das Skript
misst deshalb den Pegel. Ursache ist meist eine fehlende Mikrofonberechtigung für
Termux:API oder ein Termux-Build ohne `module-sles-source`.

**S3: Firefox sieht die Kamera nicht.** Prüfen, ob `xdg-desktop-portal-kde` läuft — die
GTK- und wlr-Portale können das Kamera-Portal nicht bedienen. In `about:config` muss
`media.webrtc.camera.allow-pipewire` auf `true` stehen; das Skript setzt es vorab.

**S4: kein Empfänger für den Intent.** Ohne installierte Navigations-App gibt es nichts,
was den `geo:`-Intent annehmen könnte. Das ist kein Fehler der Brücke.

## Aufräumen

```bash
pkill -f 'termux-x11|virgl_test_server|kwin_wayland|pipewire|bridge-mini.py'
pulseaudio --kill
```