#0055 is done: ThreadNet-Web be323ed checks in an .npmrc binding @sorb to rohana. The bump that mattered was not the file but what upstream's .gitignore does with it - it ignores /.npmrc, so the naive fix would have stayed local while CI kept resolving against npmjs. Measured in an isolated tree: without the file pnpm goes to npmjs and fails, with it the scope resolves to rohana at the integrity hash the lockfile already carries, and with rohana unreachable the install fails instead of falling back. threadnet-call only publishes and already sets the scope in its own CI; gitops never touches it. ThreadNet-Web was the only consumer. Four issues no longer describe reality, each verified rather than assumed: - #0091 (gitops#61) was fixed when it was written - on_conflict: fail shipped in ef04d86 and the MAS pod has run that config since 2026-08-11T14:08:41Z. Its one deliberate remainder became #0043, which is closed and verified live. - #0079 (gitops#46) asked for the Gitea migration and a central view. The migration ran; the central view was decided the other way round - repo canonical, GitLab mirrored (ADR-0012/0019) - which also answers the reachability trade-off it left open, and better than its three options did. - #0075 (gitops#40) is rejected, not done: it wanted new issues to appear in the Gitea kanban automatically. Issues no longer live in Gitea and the board is script-written. Nothing was accomplished; the question dissolved. - #0098 is a rollout record whose only remainder, the macOS build, is #0022. Three AARs move to harvested - every open item in them is tracked as an issue. Checked and still accurate, so left alone: the wiki branch still exists on both remotes (#0019), docs/TASKS.md and oldwiki/ are still there (#0085), element-web-docs still names live resources (#0086), res/themes/element persists (#0100), only WIKI_CANONIZE_TOKEN is set so TURN rotation still lacks its token (#0084), gameserver still has zero push mirrors (#0032), the broken .6 package is still published (#0101), and options.ts still builds simulcast layers regardless of codec, which is what blocks VP9 (#0057). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2.7 KiB
type, id, status, created, milestone, priority, projekt, gitlab_iid, related
| type | id | status | created | milestone | priority | projekt | gitlab_iid | related |
|---|---|---|---|---|---|---|---|---|
| issue | 0098 | done | 2026-08-02 | M4 | low | threadnet-web | 11 |
Themes-Rollout 2026-08-02: Web live, Linux + Windows gebaut, macOS lokal
Adoptiert aus threadnet-web#11 (2026-08-18, ADR-0019). Kommentare und Verlauf bleiben dort; kanonisch ist ab jetzt diese Datei.
Protokoll zum Ausrollen der elf neuen Themes (aXion1337 Light + zehn Paletten, gitops a2438e1).
Web ✅ live
Flux reconciled auf a2438e1; https://axion1337.chat/config.json liefert 17 Themes — verifiziert, nicht abgeleitet. Keine Pod-Rotation nötig, kein Checksum-Problem (der Fallstrick vom 2026-08-01 trat nicht auf, weil sich nur ConfigMap-Inhalt änderte, den Element beim Laden liest).
Desktop-Config 2a2bb37
Die Desktop-Apps laden ihre eigene config.json (apps/desktop/axion1337/config.json) — ohne diesen Commit hätten sie die neuen Themes nicht. Chirurgisch eingefügt: 0 entfernte / 427 neue Zeilen, JSON validiert.
Builds (Pipeline 144)
| Job | Ergebnis |
|---|---|
web |
✅ 75 s |
desktop_linux |
✅ 428 s — .deb + .tar.gz, 287 MB Artefakt |
desktop_windows |
✅ 461 s — 135 MB Artefakt |
stop_windows_vm |
ausgelöst (8 GB wieder frei) |
Verifikation der Linux-Artefakte: Die Themes stecken in resources/webapp.asar, nicht in app.asar — dort hatte ich zuerst gesucht und fälschlich „fehlt" gemeldet. webapp.asar enthält die eingebettete config.json mit allen 17 Themes.
⚠️ start_windows_vm scheiterte zunächst (No such container: windows-runner), sorb hat den Container manuell neu gestartet — Ursache und Optionen als management#21 festgehalten.
macOS
Wird lokal auf sorbs Mac gebaut (arm64, unsigniert) — kein macOS-Runner im Lab. Ergebnis folgt als Kommentar.
Erledigt — Relevanz-Durchgang 2026-08-18
Dieses Issue ist ein Rollout-Protokoll, keine offene Aufgabe: Web live und
verifiziert (17 Themes aus config.json), Desktop-Config nachgezogen, Linux- und
Windows-Artefakte gebaut und im webapp.asar gegengeprüft.
Der einzige Rest war „macOS wird lokal gebaut, Ergebnis folgt" — und das ist keine Nacharbeit an den Themes, sondern der Dauerzustand, den #0022 (BUILD-01: macOS-Client reproduzierbar bauen) als eigenes Issue führt. Der VM-Fehlschlag am Rand ist als #0021 erfasst.
Offen bleibt hier also nichts, was nicht anderswo eine Nummer hätte. Das Protokoll
bleibt als Beleg stehen — insbesondere der Fund, dass die Themes in
resources/webapp.asar stecken und nicht in app.asar, wo zuerst fälschlich
„fehlt" gemeldet wurde.