Sumonta056/claude-storehouse

Website, Demo und README aktualisieren

Die Website befindet sich in site/. .github/workflows/pages.yml stellt sie unter https://sumonta056.github.io/claude-storehouse/ bereit, nachdem CI auf main erfolgreich war.

Das Live-Demo ist der echte public/-Code. site/build.js kopiert public/ nach _site/demo/, fügt site/demo/demo-api.js vor app.js ein und schreibt demo-data.json. Um diese Datei zu erstellen, erzeugt der Build das gefälschte Home-Verzeichnis aus scripts/demo-home.js, startet den echten Server darauf und zeichnet jede GET-Antwort auf. Home-Pfade werden zu /Users/demo.

Eine UI-Änderung wird also ohne zusätzliche Arbeit im Demo sichtbar. Diese Fähigkeit deckt ab, was sich nicht von selbst aktualisiert: Beispieldaten, gefälschte Schreib-Routen, Screenshots und Text.

Planen Sie die Änderungen und holen Sie sich vor dem Bearbeiten der Dateien die Zustimmung. Fragen Sie vor dem Commit.

1. Was sich geändert hat

• git log --oneline <letzter Website- oder README-Commit>..HEAD und CHANGELOG.md → [Unreleased] listen die benutzersichtbaren Änderungen auf.
• git diff <dieser Commit>..HEAD -- .claude/rules/business-logic.md .claude/rules/ui.md public/ zeigt das neue Verhalten.
• Tests, Refactorings und CI ignorieren. Die Website und die README beschreiben, was der Benutzer sieht.

2. Jede Änderung den Stellen zuordnen, an denen sie erscheint

Geänderter Bereich	Website (site/index.html)	Screenshot	README.md-Abschnitt
Dashboard, Nutzungsband	Feature „Dashboard und Nutzung"	dashboard.png	Funktionen › Dashboard und Nutzung
Fähigkeiten, Agenten, Fork	Feature „Fähigkeiten und Agenten"	skills.png	Funktionen › Fähigkeiten und Agenten
Favoriten, Kategorien	Feature „Favoriten"	favorites.png	Funktionen › Favoriten
Plugins, Mods, Deinstallation	Feature „Plugins und Mods"	plugins.png	Funktionen › Plugins und Mods
Hooks, MCP-Server	Feature „Hooks und MCP-Server"	mcp.png	Funktionen › Hooks und MCP-Server
Drawer, Editor, Aktivität, Backups	Feature „Direkt bearbeiten, alles rückgängig"	editor.png	Funktionen › Direkt bearbeiten
Ein Schaltermechanismus	Abschnitt „Wie An/Aus funktioniert" Tabellenzeilen	—	Tabelle „Wie An/Aus funktioniert"
Neue Seite	Neuer .feature-Block (alternatives flip), Demo-Tab in .demo-tabs, Name in PAGE_NAMES in site/site.js	neue <seite>.png	neuer Funktionen-Unterabschnitt
CLI-Flag	Panel „CLI-Optionen"	—	CLI-Optionen
Tastenkombination	Tabelle „Tastenkombinationen"	—	Tastenkombinationen
Sicherheitsregel	Panel „Sicherheit und Privatsphäre"	—	Sicherheit und Privatsphäre
Dateistruktur	—	—	Wie es funktioniert (Baum)
Version	JSON-LD softwareVersion in <head>	—	Changelog (gehört zu /release-tag)

Die „Zum Ausprobieren"-Chips in #demo müssen Elemente benennen, die in den Demodaten existieren.

3. Dem Demo geben, was es braucht

• Beispieldaten. Ein Feature, das Daten benötigt (neuer Elementtyp, Mod, geparkter Hook), erhält diese in scripts/demo-home.js. Die Screenshots verwenden dieselben Daten. Niemals Zeichenfolgen, die wie Schlüssel oder Token aussehen, einfügen: Ein Sicherheits-Hook blockiert das Schreiben.
• Neue GET-Route. Wenn public/app.js eine neue GET /api/... aufruft, in record() in site/build.js aufzeichnen und in route() in site/demo/demo-api.js ausliefern.
• Neue Schreib-Route. Einen Fall in route() hinzufügen, der db im Speicher so ändert, wie der Server die Dateien ändert, und dieselbe JSON-Struktur zurückgeben wie der Handler in src/api*.js. Eine undo-Funktion zum Aktivitätseintrag hinzufügen, wenn das Original rückgängig gemacht werden kann. Ein Schreibvorgang, der im Browser nicht funktioniert (im Editor öffnen, deinstallieren, löschen), fällt in den default-Fall, der 501 mit einer Meldung „im Live-Demo nicht verfügbar" zurückgibt. Die UI zeigt diese Meldung dann als Toast an.
• Geänderte Antwortstruktur. Die entsprechende Funktion in demo-api.js aktualisieren. test/site.test.js prüft den Build, nicht jede Route, daher die Route in Chrome testen (Schritt 4).

4. Bauen und ansehen

npm run site
python3 -I -m http.server 8811 --bind 127.0.0.1 -d _site

Chrome DevTools MCP verwenden. Eigenen Tab öffnen und am Ende schließen.

1. http://127.0.0.1:8811/demo/#<seite> für jede geänderte Seite öffnen. Die Konsole hat keine Fehler.
2. Das neue Feature durch Klicks nutzen. Jeder Schreibvorgang zeigt einen Toast, die Seite aktualisiert sich und unter Aktivität wird es mit Rückgängig aufgelistet, wo die echte App Rückgängig hat.
3. http://127.0.0.1:8811/ öffnen. Die Demo-Tabs wechseln die Seiten, Demo zurücksetzen lädt neu, und jeder „Im Demo ausprobieren"-Link öffnet die richtige Seite.

5. Die geänderten Screenshots neu aufnehmen

Niemals das echte ~/.claude screenshoten. Jedes Bild aus dem Demo bei 1440 × 900, Skalierung 2 aufnehmen. Das Ergebnis ist 2880 × 1800, die Größe, die die <img>-Tags angeben.

Für eine Seite ohne Klicks, headless Chrome verwenden. Für jedes Bild ein neues Profilverzeichnis:

P=$(mktemp -d <scratchpad>/chrome.XXXXXX)
"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" --headless=new --disable-gpu --user-data-dir="$P" \
  --hide-scrollbars --force-device-scale-factor=2 --window-size=1440,900 --virtual-time-budget=4000 \
  --screenshot="$PWD/docs/images/<name>.png" "http://127.0.0.1:8811/demo/#<seite>"

Für einen Zustand, der Klicks erfordert (ein Drawer, ein Edit-Tab, ein Schalter), den MCP-Tab verwenden: emulate mit Viewport 1440x900x2, den Zustand mit evaluate_script steuern, dann take_screenshot mit filePath = docs/images/<name>.png. Nicht resize_page verwenden: es ergibt 1612 px Höhe.

Jedes neue Bild lesen. Es zeigt das Feature, hat keine Hover-Markierungen oder Fokusringe durch Zufall und keine halb geladenen Teile. docs/images/icon.png ist die 256-px-Darstellung von public/icon.svg. Nur neu erstellen, wenn sich das Icon ändert.

6. Text schreiben

• Die Website und die README verwenden für dieselbe Sache dieselben Wörter. Satzanfang groß, einfache Verben, kurze Sätze.
• Jeder Feature-Block auf der Website: 1 <h3>, 1 oder 2 Sätze, höchstens 4 Listenelemente, 1 „Im Demo ausprobieren →"-Link mit data-demo="<seite>".
• README: Das Feature in seinen Funktions-Unterabschnitt einfügen, höchstens 5 Aufzählungspunkte. Ein Unterabschnitt mit Screenshot setzt diesen nach den Aufzählungspunkten. Den Changelog-Abschnitt nicht bearbeiten. /release-tag gehört er.
• Jedes README-Bild und jeder Repo-Link ist eine absolute URL (https://raw.githubusercontent.com/Sumonta056/claude-storehouse/main/... oder https://github.com/Sumonta056/claude-storehouse/blob/main/...). npm löst relative Pfade nicht auf.
• Neue Screenshots erhalten einen echten alt-Text, der sagt, was das Bild zeigt.
• Wenn das Feature das Produkt ändert, <meta name="description">, og:description, twitter:description und die JSON-LD description in site/index.html aktualisieren.
• Jede Behauptung gegen den Code und .claude/rules/business-logic.md prüfen. Niemals ein entferntes Feature aufführen.

7. Prüfen

1. npm run format, dann npm run check. Die Ausgabe zeigen.
2. npm run site ist erfolgreich. test/site.test.js ist Teil von npm test.
3. Die Website bei 1440 px und bei 390 px öffnen: kein seitliches Scrollen, jedes Bild lädt, die Konsole hat keine Fehler.
4. Die geänderte Demo-Seite oder die Website als Artefakt-Link für den Benutzer veröffentlichen und angeben, welche Screenshots sich geändert haben und was nicht geprüft werden konnte.

Vor dem Commit fragen. docs(site): ... für Text und Screenshots, feat(site): ... für neues Website- oder Demo-Verhalten und docs(readme): ... für README-spezifische Änderungen verwenden.