Fehler melden mit Screenshot und Markierung, Sammlung für Bearbeiter

Käfer-Button unten rechts: nimmt den sichtbaren Bildschirm mit html2canvas
(selbst gehostet) auf, Vorschau mit roten Rechtecken, Beschreibung, Name
optional, Senden ohne Anmeldung. Aus offenen Dialogen heraus wird der
Dialog selbst aufgenommen. Bearbeiter sehen die Meldungen unter „Fehler"
mit Zähler, kopieren einen fertigen Claude-Prompt und den Screenshot.

Serverseitig: Pfade nur in exakter Schreibweise, /api standardmäßig nur
für Bearbeiter mit ausdrücklicher Freigabeliste, Bremse zählt jeden
Versuch vor dem Lesen großer Bodies, X-Forwarded-For nur von vertrauten
Proxys, Nutzertext im Prompt eingezäunt. HTTP-Tests für die Sperren.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This commit is contained in:
ferdi2goandClaude Fable 5.1 committed 2026-10-15 08:19:46 +00:00
1 parent 6a3c68aaac
commit 4ec23ccd25
15 files changed
+877 -36

No files matched your search

+39 -2
View File
@@ -330,7 +330,12 @@ Die **Engine** (Postgres oder MySQL) leitet VCH aus deinen Schlüsselnamen und d
**Bringt dein Compose seine eigene Datenbank mit**, startet VCH sie mit und bietet **keine**
zweite an. Achte dann selbst auf ein dauerhaftes Volume — ein Datenbankdienst ohne Volume
verliert seine Daten beim nächsten Neubau, und VCH warnt nur.
verliert seine Daten beim nächsten Neubau, und VCH warnt nur. Erkannt wird der Dienst **am
Image-Namen**: `postgres`, `postgresql`, `pgvector`, `postgis`, `timescaledb`, `mysql`,
`mariadb`, `percona`/`percona-server`. Ein anderes Image (eigener Build, fremder Name) gilt
nicht als Datenbank — dann bietet VCH eine verwaltete an, und der Deploy läuft blau-grün mit
einem zweiten Stapel.
<!-- Beleg: deployManifest.ts PG_IMAGE_RE/MYSQL_IMAGE_RE, deploy.ts skipBlueGreen -->
Eine Compose-Datei, die **nur** eine Datenbank startet, ist Entwicklungs-Beiwerk: sie läuft in
Produktion nicht mit. Nimm dort die verwaltete Datenbank.
@@ -347,6 +352,8 @@ const datenVerzeichnis = process.env.VCH_DATA_DIR || './data';
VCH setzt die Variable bei allen Betriebsarten (bei Docker als Einhängepunkt `/data`). **Lies
sie zur Laufzeit**, schreibe den Pfad nirgends fest und trage sie nicht in `.env`-Dateien ein.
Ein Verzeichnis relativ zum Release (`./data`) ist beim nächsten Deploy weg.
Bei Compose gilt das nur im Container des `${VCH_PORT}`-Dienstes — in der Compose-Datei selbst
steht die Variable nicht zur Verfügung (Abschnitt 13, Regel 5).
Der Prüfling während des Audits (Abschnitt 10) bekommt diesen Speicher **nicht** — er läuft
gegen einen leeren. Das ist Absicht: zwei Prozesse dürfen nicht gleichzeitig auf dieselbe
@@ -377,6 +384,16 @@ Projektarbeitsplatz per Rollback zurückholen.
**Auto-Deploy:** ist er eingeschaltet, löst jeder Push auf den konfigurierten Deploy-Branch
einen Deploy aus. Pushes auf andere Branches werden ignoriert.
- **Das Ergebnis jedes Deploys liegt in `.vch/deploy-report.md`** (nicht im Git — VCH trägt
die Datei wie den Audit-Bericht in `.git/info/exclude` ein). Er nennt Commit, Stufe,
Fehlermeldung, das Ende des Logs (Geheimnisse geschwärzt) und eine Einschätzung:
„probably fixable in this repository" heißt, die Ursache liegt vermutlich im Code — beheben,
committen, pushen. „platform error" heißt: **nicht** im Code suchen, sondern dem Nutzer sagen,
was dort steht. Nach einem erfolgreichen Deploy steht dort genau das; ein alter Fehlerbericht
bleibt nicht liegen. Nennt der Bericht einen anderen Commit als den, nach dem du gefragt
wirst, ist er noch nicht aktualisiert.
<!-- Beleg: services/deployReportFile.ts -->
## 11. Audit — was geprüft wird
Das Audit läuft nicht hier, sondern in einem eigenen Runner gegen einen **sauberen Checkout
@@ -399,6 +416,11 @@ macht eine Datei für das Audit unsichtbar.
`skipped` meldet, gilt als **durchgefallen** — sie ist nie gelaufen.
- `secrets` sucht eingecheckte Zugangsdaten. Echte Werte gehören nie ins Repository: in die
`.env.example` nur Beispiele, die echten Werte in den Env-Editor von VCH.
- **Das Ergebnis liegt nach jedem Audit in `.vch/audit-report.md`** (nicht im Git — VCH trägt
die Datei in `.git/info/exclude` ein). Bei einem Fehlschlag: lesen, beheben, committen,
pushen — erst der nächste Deploy auditiert den neuen Commit. Der Kopf nennt Commit und
Zeitpunkt; lief die Instanz beim Audit nicht, ist die Datei älter oder fehlt, dann steht der
aktuelle Bericht im Audit-Fenster von VCH zum Kopieren.
## 12. Veröffentlichen
@@ -410,7 +432,7 @@ macht eine Datei für das Audit unsichtbar.
- Im **Showcase** erscheinen veröffentlichte Projekte mit bestandenem Audit und einer
eingecheckten `.vch-description`.
## 13. Compose — die vier Regeln, an denen es sonst scheitert
## 13. Compose — die fünf Regeln, an denen es sonst scheitert
1. **Der App-Dienst muss seinen Port als `ports: ["${VCH_PORT}:<intern>"]` veröffentlichen.**
VCH setzt `VCH_PORT` und kann so einen Prüfling neben deiner laufenden Fassung starten.
@@ -425,3 +447,18 @@ macht eine Datei für das Audit unsichtbar.
4. **Der ganze Stapel startet.** Datenbanken, Caches und Ähnliches aus deinem Compose laufen
automatisch mit — eine zusätzliche verwaltete Datenbank brauchst du dafür nicht. Dienste
hinter einem `profiles:`-Schlüssel bleiben aus.
5. **Gebaute Dienste bekommen kein `image:`, dauerhafte Daten liegen unter `/data` des
`${VCH_PORT}`-Dienstes.** Für jeden Dienst mit `build:` vergibt VCH den Image-Namen selbst,
je Commit — so starten Prüfling, Live-Stand und Rollback jeweils genau ihren Code. Ein
eigenes `image:` bei einem gebauten Dienst teilt sich ein Image über alle Releases; ein
Rollback startet dann den zuletzt gebauten Code. `VCH_DATA_DIR` gibt es **nur im Container**
des `${VCH_PORT}`-Dienstes (als `/data`), nicht beim Einlesen der Compose-Datei:
`${VCH_DATA_DIR:-.}/data` wird dort zu `./data` im Release-Ordner und ist beim nächsten
Deploy weg. Ein zweiter Dienst, der dieselben Daten braucht, bekommt `volumes_from: [<app>]`;
eigene Daten legt er in ein benanntes Volume (`volumes: [daten:/var/lib/…]`) — das überlebt
Deploys, sichert VCH aber nicht mit. `vch-images.yml` wird bei jedem Build neu
geschrieben oder entfernt, `vch-override.yml` bei jedem Start des Live-Stands geschrieben
(sofern es einen `${VCH_PORT}`-Dienst gibt) — beide gehören VCH, keine eigenen Dateien dieses
Namens.
<!-- Beleg: dockerCommands.ts composeImageRef/renderComposeImages, runtimeOps.ts composeStableUpCmds (#291); deployManifest.ts classifyServiceDataMount -->