# Von zuhause weiterarbeiten

Stand 21.08.2026. Alles Nötige liegt im Repository — außer dem Kundenmaterial
und dem SSH-Zugang.

## 1. Repository holen

Das Repository ist rein lokal, es hat noch kein Remote. Vor dem Wechsel:

```bash
git remote add origin <URL-deines-privaten-Repos>
git push -u origin main
```

Zuhause dann klonen. Ordner mit **`Kundenmaterial/` fehlt bewusst** — 156 MB
Layout-PDFs, per `.gitignore` ausgeschlossen. Die liegen in OneDrive.

## 2. SSH-Zugang einrichten

Der Staging-Server hört auf den Alias `nees-staging`. Auf dem Heimrechner:

```bash
ssh-keygen -t ed25519
```

Den öffentlichen Schlüssel im Kundenpanel des Hosters hinterlegen, dann
`~/.ssh/config` ergänzen:

```
Host nees-staging
    HostName              wow-internet.de
    User                  p166709
    IdentityFile          ~/.ssh/id_ed25519
    StrictHostKeyChecking accept-new
    ServerAliveInterval   30
```

Testen mit `ssh nees-staging`.

## 3. Was wo liegt

| Datei | Inhalt |
|---|---|
| `CLAUDE.md` | **Zuerst lesen.** Projektkontext, Festlegungen, Serverstand, nächste Schritte |
| `nees-komponenten.csv` | Bauliste: 22 Komponenten mit Bordmittel-Zuordnung und Zieldateien |
| `nees-ablauf.md` | Ablaufdiagramm der Phasen |
| `nees-elementvergleich.html` | Bestandsanalyse Ist/Soll |
| `nees-html-elemente.md` | Auswertung der 64 `html`-Elemente |
| `chatverlauf.md` | Gesprächsverlauf, 130 KB statt 187 MB |
| `neue-Site/` | Das neue Package, 131 Dateien |
| `altes-Site/` | Bestand als Referenz, **nicht weiterentwickeln** |

Claude Code liest `CLAUDE.md` beim Start automatisch, sobald du im
Projektordner arbeitest.

## 4. Gesprächsverlauf aktualisieren

`chatverlauf.md` ist eine Momentaufnahme. Neu erzeugen:

```bash
python tools/export-chat.py
```

Das Skript findet die Sitzung selbst über den Projektpfad. Schalter:
`--tools`, `--thinking`, `--alle`, `--liste`.

## 5. Sicherungen auf dem Server

Alles unter `/html/backup`, Stempel `20260821-1605`:

| Datei | Inhalt |
|---|---|
| `vor-update-20260821-1605.sql.gz` | Datenbank vor dem v14-Upgrade |
| `vor-update-config-20260821-1605.tar.gz` | `config/`, `composer.json`, `.lock` |
| `nees-alt-20260821-1605/` | Das alte Sitepackage vollständig |
| `ce-overrides-v13-20260821-1605/` | Die 60 entfernten CE-Templates |
| `composer-v13-20260821-1605.json` | Wurzel-`composer.json` der v13-Fassung |
| `site-config-20260821-1605.yaml` | Site-Konfiguration vor dem Upgrade |
| `entfernte-instagram-uids.txt` | UIDs der entfernten Elemente |

Dazu ein Snapshot der gesamten Umgebung beim Hoster.

## 6. Nützliche Befehle auf dem Server

```bash
ssh nees-staging 'cd /html/typo3-composer && vendor/bin/typo3 cache:flush'
```

Weitere, jeweils mit demselben Vorspann:

- `vendor/bin/typo3 extension:setup` — nach Änderungen an Extensions
- `vendor/bin/typo3 content-blocks:lint` — prüft die Content-Block-Definitionen
- `vendor/bin/typo3 database:updateschema --dry-run` — zeigt offene Schemaänderungen
- `vendor/bin/typo3 referenceindex:update --check` — prüft den Referenzindex

Dateien hochladen:

```bash
scp -r neue-Site/packages/nees/Resources/. nees-staging:/html/typo3-composer/packages/nees/Resources/
```

## 7. Zwei Fallen, in die ich getappt bin

**scssphp ist nicht Dart Sass.** bootstrap_package kompiliert mit scssphp.
Das rechnet `1.7rem + 2.4vw` selbst aus und scheitert an gemischten Einheiten —
deshalb steht jede Rechnung in `clamp()` innerhalb von `calc()`. Und es löst
bei `EXT:`-Pfaden keine Partials auf, weshalb die Importe in `theme.scss` den
Unterstrich ausdrücklich tragen. Lokal gegen Dart Sass zu testen beweist
für diese Installation wenig.

**Zwei getrennte Pfadsätze für Templates.** `plugin.bootstrap_package.view.*`
gilt für Plugins, die Seitenausgabe nutzt `page.fluidtemplate.*` — und die
Pfade enden auf `/Page/`. Wer nur den ersten setzt, wundert sich, warum
Layout-Überschreibungen wirkungslos bleiben.