Add Discord support link and update registration URLs in docs

.gitignore

@@ -35,3 +35,13 @@ logs
 #VSC
 .history
 .wrangler
+
+# AI tooling
+.claude
+.agents
+.cursor
+.windsurf
+.aider*
+CLAUDE.md
+AGENTS.md
+skills-lock.json

README.md

@@ -10,7 +10,7 @@
 **The documentation site for [upcore](https://github.com/upcore-app/upcore)** — self-hosted uptime
 monitoring with public status pages.
 
-[docs.upcore.app](https://docs.upcore.app) · [Product repo](https://github.com/upcore-app/upcore) · [upcore Cloud](https://go.upcore.app)
+[docs.upcore.app](https://docs.upcore.app) · [Product repo](https://github.com/upcore-app/upcore) · [upcore Cloud](https://go.upcore.app/register) · [Discord](https://discord.gg/eWeaQZYcyd)
 
 </div>
 
@@ -80,3 +80,9 @@ CI publishes the image to `ghcr.io/upcore-app/docs` on every push to `main`.
 
 Issues and pull requests are welcome. For anything about upcore itself — features, bugs,
 security — use the [product repo](https://github.com/upcore-app/upcore).
+
+## Support
+
+Questions and support run through our Discord:
+[discord.gg/eWeaQZYcyd](https://discord.gg/eWeaQZYcyd). Want upcore without hosting it
+yourself? [upcore Cloud](https://go.upcore.app/register) is free to start.

app/app.config.ts

@@ -43,6 +43,7 @@ export default defineAppConfig({
 
   socials: {
     github: 'https://github.com/upcore-app/upcore',
+    discord: 'https://discord.gg/eWeaQZYcyd',
   },
 
   toc: {
@@ -56,6 +57,18 @@ export default defineAppConfig({
           to: 'https://github.com/upcore-app/upcore',
           target: '_blank',
         },
+        {
+          icon: 'i-simple-icons-discord',
+          label: 'Support on Discord',
+          to: 'https://discord.gg/eWeaQZYcyd',
+          target: '_blank',
+        },
+        {
+          icon: 'i-lucide-cloud',
+          label: 'Start upcore Cloud',
+          to: 'https://go.upcore.app/register',
+          target: '_blank',
+        },
         {
           icon: 'i-lucide-shield-check',
           label: 'Report a vulnerability',

app/components/app/AppFooterLeft.vue

@@ -0,0 +1,23 @@
+<script setup lang="ts">
+const appConfig = useAppConfig()
+
+const links = computed(() => appConfig.footer?.legal ?? [])
+</script>
+
+<template>
+  <div class="flex flex-wrap items-center gap-x-4 gap-y-1 text-sm text-muted">
+    <span>Copyright © {{ new Date().getFullYear() }}</span>
+
+    <!-- The legal pages live on the product site, not in the docs content -
+         they are the same imprint for every upcore surface. -->
+    <ULink
+      v-for="link of links"
+      :key="link.to"
+      :to="link.to"
+      target="_blank"
+      class="hover:text-default"
+    >
+      {{ link.label }}
+    </ULink>
+  </div>
+</template>

content/de/1.getting-started/1.introduction.md

@@ -142,7 +142,7 @@ ersten geschrieben, sofern nichts anderes dabeisteht.
 
   #description
   Dasselbe upcore, betrieben von onesrv auf
-  [go.upcore.app](https://go.upcore.app). Kostenlos starten, upgraden wenn es eng wird;
+  [go.upcore.app](https://go.upcore.app/register). Kostenlos starten, upgraden wenn es eng wird;
   keine Datenbank, kein Update und kein Zertifikat, um das du dich kümmerst.
   :::
 ::

content/de/2.guide/5.outposts.md

@@ -164,3 +164,29 @@ Outpost-Limit deines Tarifs — die stellst du bereit und bezahlst sie.
 Nimmt ein Tarifwechsel einen geteilten Standort weg, werden die davon abhängigen
 Zuweisungen genau dort entfernt statt bei der nächsten Check-Runde. Ein Monitor
 verliert einen Standort, nie seinen Check.
+
+### Sehen, welche Standorte ein Tarif hinzufügen würde
+
+Eine Probe, die dein Tarif nicht enthält, fehlt im Monitor-Formular nicht einfach
+— sie steht dort, ausgegraut, mit einem Schloss und den Tarifen, in denen sie
+enthalten ist. Ein Standort, der gar nicht auftaucht, liest sich wie ein Standort,
+den es nicht gibt, und das ist die falsche Auskunft über eine Flotte, die jemand
+anders betreibt.
+
+Es ist ein Hinweis und keine Checkbox: auswählbar ist er nicht, und eine
+deaktivierte Checkbox, die sich nie setzen lässt, liest sich wie ein Fehler statt
+wie ein Preis. Die Liste vergibt auch nichts — ein Monitor-Schreibvorgang prüft
+weiterhin gegen die Standorte, die der Organisation tatsächlich zur Verfügung
+stehen. Mehr als anzeigen kann ein Client damit also nicht.
+
+Auf jeder self-hosted Instanz und innerhalb der Operator-Organisation ist die
+Liste leer.
+
+::note
+Geteilt wird über Tags, nicht über eine Liste von IDs: Der Operator stellt eine
+Maschine bereit, taggt sie mit `eu`, und jeder Tarif mit diesem Tag bekommt sie —
+ohne dass ein einziger Tarif bearbeitet wird. Wird die Maschine abgebaut,
+verschwindet sie aus allen Tarifen gleichzeitig. Taggen lassen sich nur die
+Outposts des Operators — ein Tag an der eigenen Probe eines Mandanten würde nichts
+bedeuten und wird deshalb abgelehnt statt gespeichert und ignoriert.
+::

content/de/2.guide/6.topology.md

@@ -0,0 +1,154 @@
+---
+title: Topologie
+description: Wer prüft was — als Bild. Und die drei Fälle, in denen das nicht dem
+  entspricht, was am Monitor eingestellt ist.
+navigation:
+  icon: i-lucide-network
+---
+
+Jede Zahl auf dieser Seite gibt es woanders schon. Das Monitor-Formular kennt
+seine Check-Strategie, die Outpost-Liste kennt die Zahl der Monitore pro Probe —
+und keines von beiden sagt, was der Runner aus den beiden tatsächlich macht.
+
+Die **Topologie** sagt es. Ein Bildschirm, eine Frage: *welcher Standort erreicht
+gerade welchen Monitor* — und interessant wird es dort, wo die Antwort von der
+Konfiguration abweicht.
+
+![Der Topologie-Graph: links der zentrale Check, rechts ein Knoten pro Monitor](/screenshots/de/topology.jpg)
+
+## Die Fläche lesen
+
+Links steht jeder Ort, von dem ein Check kommen kann: **Zentral** — die
+upcore-Instanz selbst — und darunter jeder Outpost, den diese Organisation nutzen
+darf, einschließlich der Probes, die gerade nichts tragen. Eine untätige Probe ist
+kein Problem, aber sie gehört zur Flotte und bleibt deshalb auf der Fläche.
+
+Rechts steht ein Knoten pro Monitor. Eine Kante dazwischen heißt: dieser Standort
+prüft diesen Monitor.
+
+Zwei Monitor-Typen fehlen mit Absicht. Ein `group`-Monitor fasst andere Monitore
+zusammen, statt etwas zu erreichen, und ein `push`-Monitor wird gerufen, statt zu
+rufen — keiner von beiden wird von einem Standort aus versendet. Ihre Mitglieder
+und die Push-Endpunkte bleiben als eigene Monitore sichtbar.
+
+### Den Farben folgen
+
+Eine Kante trägt die Farbe dessen, was der Standort zuletzt gemeldet hat:
+
+| | |
+| --- | --- |
+| grün | erreichbar |
+| gelb | beeinträchtigt |
+| rot | Störung |
+| grau | still — dieser Standort hat im Zeitfenster nichts gemeldet |
+
+Wer eine Kante überfährt, bekommt die Zahlen dahinter: letzter Status, Latenz und
+Meldung mit dem Zeitpunkt, dazu Uptime, durchschnittliche Latenz und die Zahl der
+Checks der letzten **24 Stunden** — für genau diesen Standort und genau diesen
+Monitor.
+
+::note
+Ein Monitor, der von genau einem Ort geprüft wird, schreibt gar keine Zeilen pro
+Standort: Der Runner spaltet eine Runde erst auf, wenn mehr als ein Standort
+gemeldet hat. Sein aggregierter Heartbeat *ist* das Urteil dieses Standorts, und
+der Graph liest es deshalb am Monitor ab, statt eine leere Kante zu zeigen, die in
+Wahrheit das Einzige ist, was den Monitor oben hält.
+::
+
+## Die drei Überraschungen erkennen
+
+Eine Kante kann einen Hinweis tragen, und jeder benennt einen Fall, in dem Bild
+und Konfiguration auseinandergelaufen sind:
+
+::u-page-grid
+  :::u-page-card
+  ---
+  icon: i-lucide-life-buoy
+  variant: subtle
+  ---
+  #title
+  fallback
+
+  #description
+  Der Monitor hat entfernte Standorte verlangt, keiner davon kann ihn bedienen,
+  und der zentrale Check hat übernommen. Nirgends sonst in der Admin-Oberfläche
+  steht das — der Monitor liest sich weiterhin als „von Outposts geprüft“, und das
+  ist er nicht.
+  :::
+
+  :::u-page-card
+  ---
+  icon: i-lucide-power-off
+  variant: subtle
+  ---
+  #title
+  inactive
+
+  #description
+  Eine zugewiesene Probe, die abgeschaltet ist. Sie steht auf der Fläche, weil du
+  sie verlangt hast; angesprochen wird sie nicht.
+  :::
+
+  :::u-page-card
+  ---
+  icon: i-lucide-shield-alert
+  variant: subtle
+  ---
+  #title
+  unverified
+
+  #description
+  Eine zugewiesene Probe, die upcore nie zurück erreicht hat. Wird ebenfalls
+  übersprungen — siehe [Outposts](/de/guide/outposts) dazu, was Verifikation ist
+  und warum eine unverifizierte Probe inert bleibt.
+  :::
+::
+
+## Kacheln und Filter nutzen
+
+Über der Fläche stehen vier Zähler:
+
+| Kachel | Zählt |
+| --- | --- |
+| **Nur zentral geprüft** | Monitore, die kein Standort bedient. Ein `both`-Monitor gehört nicht dazu. |
+| **Von Outposts geprüft** | Monitore, für die mindestens eine Probe tatsächlich angesprochen wird. |
+| **Standorte einsatzbereit** | Outposts, die aktiv *und* verifiziert sind, von allen. |
+| **Auffälligkeiten** | Ausfallende Standorte plus Monitore, die zurückgefallen sind. |
+
+**Nur Auffälligkeiten** reduziert die Fläche auf die Monitore, die etwas zu sagen
+haben — ein Standort, der gerade ausfällt, eine Zuweisung, die der Runner nicht
+bedienen kann, oder ein abgeschalteter Monitor — und lässt die Probes weg, die
+nichts davon tragen. Zweihundert Monitore liest man nicht, indem man sie alle
+ansieht.
+
+Die Seite aktualisiert sich alle 30 Sekunden und lässt sich anhalten. Sie ist
+langsamer als die Outpost-Liste, und zwar absichtlich: eine Kante, die unter dem
+Mauszeiger die Farbe wechselt, ist eine Unterbrechung, und hier gibt es mehr
+davon.
+
+## Wissen, wer sie öffnen darf
+
+Nur Admins. Editoren sehen sie nicht in der Navigation, und
+`/api/outposts/topology` weist sie ab — die Antwort enthält Outpost-Zeilen, und
+unter welchen Adressen eine Probe erreichbar ist, geht einen Editor nichts an.
+
+::note
+Das ganze Bild ist ein Request: `GET /api/outposts/topology` auf der
+sessionauthentifizierten Admin-API, nicht auf [`/api/v1`](/de/api/authentication).
+::
+
+## Wie es weitergeht
+
+::u-page-links
+---
+links:
+  - label: Outposts
+    icon: i-lucide-globe
+    to: /de/guide/outposts
+    description: Was eine Probe ist, wie sie sich anmeldet und wie die Standorte abstimmen.
+  - label: Monitore
+    icon: i-lucide-activity
+    to: /de/guide/monitors
+    description: Wo Check-Strategie und Outpost-Policy eines Monitors gesetzt werden.
+---
+::

content/de/2.guide/7.users-and-access.md → content/de/2.guide/8.users-and-access.md

@@ -79,3 +79,27 @@ Die Session trägt keine Rolle. Die Rolle wird pro Request gegen die angesproche
 Organisation aufgelöst — eine gegen eine andere Organisation wiedereingespielte Session
 findet also keine Mitgliedschaft und wird abgelehnt, was sie anderswo auch sein
 mag.
+
+### Organisation wechseln
+
+Ein Konto kann mehreren angehören. In der upcore Cloud nennt der Fuß der
+Seitenleiste die Organisation, in der du bist, und öffnet die anderen in einem
+Popover — self-hosted wird er nicht gerendert, und für ein Konto mit einer
+einzigen Mitgliedschaft auch nicht: ein Menü mit einem Eintrag führt dorthin
+zurück, wo man ohnehin schon ist.
+
+Der Umschalter **betritt eine Organisation nicht selbst**. Sitzungen sind an den
+Host gebunden, und eine Übergabe aus einem Mandanten heraus zu erzeugen wird
+bewusst abgelehnt: Genau diese Ablehnung verhindert, dass ein Fuß in der Tür einer
+Organisation zu einer Sitzung in jeder anderen wird, die das Konto erreichen kann.
+Ein Eintrag verlinkt deshalb auf die Auswahl auf der Hauptdomain und benennt das
+Ziel; betreten wird es dort beim Ankommen — und die Mitgliedschaft wird
+serverseitig neu gelesen. Die benannte Organisation ist also eine Vorauswahl und
+nie eine Berechtigung.
+
+## Das Konto selbst absichern
+
+Rollen und Keys entscheiden, was eine Sitzung darf. Was es braucht, um überhaupt
+eine zu *bekommen* — Passkeys, Authenticator-App, Wiederherstellungscodes, die
+Pflicht für die ganze Organisation und die Liste der angemeldeten Geräte — steht
+unter [Kontosicherheit](/de/guide/account-security).