Sumonta056/claude-storehouse

Mettre à jour le site web, la démo et le README

Le site web se trouve dans site/. .github/workflows/pages.yml le déploie vers https://sumonta056.github.io/claude-storehouse/ après le passage du CI sur main.

La démo en direct est le véritable code de public/. site/build.js copie public/ dans _site/demo/, ajoute site/demo/demo-api.js avant app.js et écrit demo-data.json. Pour créer ce fichier, la build construit un répertoire personnel factice à partir de scripts/demo-home.js, lance le vrai serveur dessus et enregistre chaque réponse GET. Les chemins du répertoire personnel deviennent /Users/demo.

Ainsi, une modification de l'interface utilisateur apparaît dans la démo sans effort supplémentaire. Cette compétence couvre ce qui ne se met pas à jour automatiquement : les données d'exemple, les routes d'écriture fictives, les captures d'écran et le texte.

Planifiez les modifications et obtenez une approbation avant de modifier les fichiers. Demandez avant de valider.

1. Trouver ce qui a changé

• git log --oneline <dernier commit site ou README>..HEAD et CHANGELOG.md → [Unreleased] listent les changements visibles par l'utilisateur.
• git diff <ce commit>..HEAD -- .claude/rules/business-logic.md .claude/rules/ui.md public/ montre le nouveau comportement.
• Ignorez les tests, les refactorisations et le CI. Le site et le README décrivent ce que l'utilisateur voit.

2. Cartographier chaque changement vers les endroits où il s'affiche

Zone modifiée	Site web (site/index.html)	Capture d'écran	Section README.md
Tableau de bord, bande d'utilisation	fonctionnalité « Dashboard and usage »	dashboard.png	Fonctionnalités › Dashboard and usage
Compétences, agents, fork	fonctionnalité « Skills and agents »	skills.png	Fonctionnalités › Skills and agents
Favoris, catégories	fonctionnalité « Favorites »	favorites.png	Fonctionnalités › Favorites
Plugins, mods, désinstallation	fonctionnalité « Plugins and mods »	plugins.png	Fonctionnalités › Plugins and mods
Hooks, serveurs MCP	fonctionnalité « Hooks and MCP servers »	mcp.png	Fonctionnalités › Hooks and MCP servers
Tiroir, éditeur, activité, sauvegardes	fonctionnalité « Edit in place, undo anything »	editor.png	Fonctionnalités › Edit in place
Un mécanisme de commutation	section « How on / off works » lignes	—	Tableau How on/off works
Nouvelle page	nouveau bloc .feature (alternance flip), onglet de démo dans .demo-tabs, nom dans PAGE_NAMES dans site/site.js	nouvelle <page>.png	nouvelle sous-section Fonctionnalités
Option CLI	panneau « CLI options »	—	Options CLI
Raccourci clavier	tableau « Keyboard shortcuts »	—	Raccourcis clavier
Règle de sécurité	panneau « Safety and privacy »	—	Sécurité et confidentialité
Structure des fichiers	—	—	Arborescence How it works
Version	JSON-LD softwareVersion dans <head>	—	Changelog (propriété de /release-tag)

Les chips « Things to try » dans #demo doivent nommer des éléments qui existent dans les données de la démo.

3. Donner à la démo ce dont elle a besoin

• Données d'exemple. Une fonctionnalité qui nécessite des données (un nouveau type d'élément, un mod, un hook mis en attente) les obtient dans scripts/demo-home.js. Les captures d'écran utilisent les mêmes données. N'insérez jamais de chaînes ressemblant à des clés ou des jetons : un hook de sécurité bloque l'écriture.
• Nouvelle route GET. Si public/app.js appelle une nouvelle GET /api/..., enregistrez-la dans record() dans site/build.js et servez-la dans route() dans site/demo/demo-api.js.
• Nouvelle route d'écriture. Ajoutez un cas à route() qui modifie db en mémoire comme le serveur modifie les fichiers, et renvoyez la même forme JSON que le gestionnaire dans src/api*.js. Ajoutez une fonction undo à l'entrée d'activité si la vraie peut annuler. Une écriture qui ne peut pas fonctionner dans un navigateur (ouvrir dans l'éditeur, désinstaller, supprimer) tombe dans le cas default, qui renvoie 501 avec un message « non disponible dans la démo en direct ». L'interface utilisateur affiche alors ce message sous forme de toast.
• Forme de réponse modifiée. Mettez à jour la fonction correspondante dans demo-api.js. test/site.test.js vérifie la build, pas chaque route, alors testez la route dans Chrome (étape 4).

4. Construire et inspecter

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

Utilisez Chrome DevTools MCP. Ouvrez votre propre onglet et fermez-le à la fin.

1. Ouvrez http://127.0.0.1:8811/demo/#<page> pour chaque page modifiée. La console ne contient aucune erreur.
2. Utilisez la nouvelle fonctionnalité en cliquant. Chaque écriture affiche un toast, la page se met à jour et l'activité la liste avec Annuler là où la vraie application a Annuler.
3. Ouvrez http://127.0.0.1:8811/. Les onglets de démo changent de page, Reset demo recharge, et chaque lien « Try it in the demo » ouvre la bonne page.

5. Recapturer les captures d'écran qui ont changé

Ne faites jamais de capture d'écran du vrai ~/.claude. Prenez chaque vue depuis la démo à 1440 × 900, échelle 2. Le résultat est 2880 × 1800, la taille que les balises <img> déclarent.

Pour une page sans clics, utilisez Chrome sans tête. Utilisez un nouveau dossier de profil pour chaque vue :

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/#<page>"

Pour un état nécessitant des clics (un tiroir, un onglet d'édition, un interrupteur), utilisez l'onglet MCP : emulate avec viewport 1440x900x2, pilotez l'état avec evaluate_script, puis take_screenshot avec filePath = docs/images/<name>.png. N'utilisez pas resize_page : il donne une hauteur de 1612 px.

Lisez chaque nouvelle image. Elle montre la fonctionnalité, n'a pas de marques de survol ni de halos de focus par hasard, et n'a pas de parties à moitié chargées. docs/images/icon.png est le rendu 256 px de public/icon.svg. Refaites-le seulement lorsque l'icône change.

6. Rédiger le texte

• Le site et le README utilisent les mêmes mots pour la même chose. Style phrase, verbes simples, phrases courtes.
• Chaque bloc de fonctionnalité sur le site : 1 <h3>, 1 ou 2 phrases, au maximum 4 éléments de liste, 1 lien « Try it in the demo → » avec data-demo="<page>".
• README : ajoutez la fonctionnalité à sa sous-section Fonctionnalités, au maximum 5 puces. Une sous-section avec une capture d'écran la place après les puces. Ne modifiez pas la section Changelog. /release-tag en est propriétaire.
• Chaque image et lien de dépôt du README est une URL absolue (https://raw.githubusercontent.com/Sumonta056/claude-storehouse/main/... ou https://github.com/Sumonta056/claude-storehouse/blob/main/...). npm ne résout pas les chemins relatifs.
• Les nouvelles captures d'écran reçoivent un texte alt réel qui dit ce que l'image montre.
• Si la fonctionnalité change ce qu'est le produit, mettez à jour <meta name="description">, og:description, twitter:description et le JSON-LD description dans site/index.html.
• Vérifiez chaque affirmation par rapport au code et à .claude/rules/business-logic.md. Ne listez jamais une fonctionnalité supprimée.

7. Vérifier

1. npm run format, puis npm run check. Affichez la sortie.
2. npm run site réussit. test/site.test.js fait partie de npm test.
3. Ouvrez le site à 1440 px et à 390 px : pas de défilement latéral, chaque image se charge, la console ne contient aucune erreur.
4. Publiez la page de démo modifiée ou le site en tant que lien Artifact pour l'utilisateur, et dites quelles captures d'écran ont changé et ce que vous n'avez pas pu vérifier.

Demandez avant de valider. Utilisez docs(site): ... pour le texte et les captures d'écran, feat(site): ... pour un nouveau comportement du site ou de la démo, et docs(readme): ... pour les modifications du seul README.