Portfolio One Shot

Que fait Portfolio One Shot ?

Objectif

Transformer un répertoire de travaux réels en un portfolio qui peut être ouvert, lu par des machines et vérifié de manière indépendante — sans que le modèle n'écrive une seule ligne de texte fictif sur les projets.

Les trois invariants, par ordre de priorité :

1. Aucune fabrication. Chaque fait affiché doit remonter à un fichier, un extrait de README ou une valeur fournie par l'utilisateur. Les champs manquants apparaissent sous forme de lacunes visibles. N'inventez jamais de noms de projet, rôles, métriques, clients, citations, résultats ou images.
2. Vérification indépendante. Exécutez le vérificateur sur la sortie avant de signaler un succès. Listez d'abord les échecs, puis les réussites. Ne présentez jamais une liste de critères verts comme preuve que le portfolio est esthétiquement réussi — le jugement visuel appartient à l'utilisateur, par ses propres yeux.
3. Une seule commande. all effectue l'analyse → la configuration → la construction → la vérification. Une deuxième commande est un défaut, pas un flux de travail.

Quand l'utiliser

• L'utilisateur dit "一键生成作品集" / "做个作品集" / "把我的项目做成作品集" / "build a portfolio from this folder".
• L'utilisateur remet un répertoire d'images, de vidéos ou de dossiers de projets et souhaite les présenter.
• L'utilisateur souhaite régénérer un portfolio après avoir ajouté ou supprimé des travaux.
• L'utilisateur souhaite vérifier si un portfolio existant comporte des preuves manquantes.

Ne pas utiliser lorsque l'utilisateur souhaite un site de démonstration décoratif avec du contenu inventé, un style visuel spécifique dirigé par un artiste, ou une intégration à une plateforme hébergée. Ce sont des tâches différentes. Ne passez pas silencieusement aux règles de zéro fabrication de cette compétence dans ce cas — énoncez la différence à voix haute.

La commande unique

python scripts/portfolio.py all <SOURCE_DIR> --out <OUTPUT_DIR> --mode <case_study|gallery>

Exemple :

python scripts/portfolio.py all "C:/work/mes-projets" --out "C:/work/portfolio-dist" --mode gallery

La commande écrit index.html, portfolio.txt, portfolio.md, projects.json, assets/, build-report.json et verify-report.md dans le répertoire de sortie, puis affiche le verdict du vérificateur. Ouvrez index.html pour l'utilisateur avec l'outil de présentation de fichiers. Placez le livrable visuel en premier dans la liste.

Pour reconstruire après que l'utilisateur a modifié projects.json, exécutez build et verify uniquement :

python scripts/portfolio.py build <OUTPUT_DIR>/projects.json --out <OUTPUT_DIR> --mode gallery
python scripts/portfolio.py verify <OUTPUT_DIR>

Flux de travail

Phase 0 · Décider du mode, ne pas deviner silencieusement

Deux modes existent car la recherche sur les sources a montré que les deux domaines exigent des choses opposées (voir references/content-spec.md §Division des domaines).

Mode	Pour	Densité textuelle	Mise en page
case_study	UX, produit, design, ingénierie, recherche	Récit long ; sept groupes de champs obligatoires	Un projet par section, images entrelacées
gallery	Art de jeu, illustration, concept art, photographie, animation	Mots minimaux ; laissez le travail parler	Grille axée sur les images, visionneuse au clic

Si l'utilisateur n'a pas choisi, déduisez-le du matériel et annoncez l'inférence en une phrase avant de lancer l'exécution — puis laissez un seul mot de l'utilisateur pour annuler. Ne codez jamais en dur une valeur par défaut dans le portfolio de quelqu'un.

Phase 1 · Analyser le matériel réel

scan énumère les sous-répertoires en tant que projets. Pour chaque projet, il enregistre :

• Le nom du répertoire comme candidat au titre du projet (un fait, pas une invention).
• Chaque fichier image et vidéo avec sa taille en octets, le préfixe SHA-256 et les dimensions en pixels.
• Le premier paragraphe de README.md / project.md / about.md comme candidat summary textuel, avec une entrée _sources nommant le fichier et la plage de lignes.
• Une liste missing des champs qu'aucun fichier n'a pu fournir.

Les fichiers avec des extensions inconnues restent dans manifest.json en tant que unclassified plutôt que d'être supprimés. Ne supprimez, renommez, déplacez ou redimensionnez jamais les fichiers source. Écrivez uniquement dans le répertoire de sortie.

Phase 2 · Construire

build lit projects.json (schéma dans references/config-schema.md) et génère :

• index.html — thème clair, responsive, police système, aucune dépendance CDN, aucun modèle tape-à-l'œil. Chaque <img> porte alt, width, height, loading="lazy". Les images utilisent des chemins relatifs sous assets/.
• portfolio.txt — résumé texte du projet pour l'analyse ATS et le copier-coller dans un CV.
• portfolio.md — les mêmes faits en Markdown pour README ou e-mail.
• Une bannière d'avertissement visible indiquant exactement combien de champs sont manquants, afin qu'un squelette ne puisse jamais être confondu avec un portfolio terminé.

Lorsque --embed est défini, intégrez en ligne uniquement les images de moins de 10 Ko en base64 et conservez les plus grandes en externe ; imprimez un avertissement pour chaque fichier qui aurait dépassé le seuil. Le base64 augmente la charge utile d'environ 33 % et ne peut pas être chargé en différé — voir references/content-spec.md §Politique d'image.

Phase 3 · Vérifier avant de signaler

verify vérifie l'exhaustivité des champs, l'existence et la décodabilité des images, la présence de texte alternatif significatif, l'absence de serveurs d'images de substitution, la forme des liens, la structure HTML et la parité texte. Il écrit verify-report.md avec les Échecs en premier, les Réussites en second, puis les Limitations / non vérifié.

Le code de sortie 1 signifie que des éléments rouges existent. Signalez-le honnêtement. Ne modifiez pas les critères pour les faire passer, ne réessayez pas un canal de génération défaillant et ne masquez pas une limitation.

Pour un contrôle positif/négatif, exécutez python scripts/portfolio.py verify <dir> --self-test — il construit un projet délibérément cassé et un projet complet en mémoire et confirme que le vérificateur signale le premier et valide le second. Si le contrôle négatif passe au vert, le vérificateur est cassé ; corrigez le vérificateur, pas le dispositif de test.

Phase 4 · Remettre le livrable

Présentez index.html en premier afin que l'utilisateur puisse l'ouvrir, puis verify-report.md, puis projects.json. Dans la réponse textuelle : donnez le verdict, le nombre exact de champs manquants et la prochaine action unique (remplir projects.json). N'affirmez pas que le portfolio a belle apparence. N'affirmez pas qu'il est prêt à être envoyé tant que la bannière d'avertissement est présente.

Contrat de zéro fabrication

Règles strictes, toutes dérivées des modes de défaillance documentés dans references/content-spec.md :

• N'écrivez jamais de prose de projet, légendes, rôles, métriques, résultats, crédits ou noms de clients absents de l'entrée. Un champ manquant s'affiche sous forme [MANQUANT: champ] — visible, jamais silencieusement vide, jamais paraphrasé en une phrase plausible.
• N'utilisez jamais de serveurs d'images de substitution (picsum.photos, placehold.co, lorem, URL de stock) comme substituts pour un travail réel. Un projet sans images affiche un bloc média vide explicite.
• Ne citez jamais une métrique sans une entrée _sources. Si l'utilisateur fournit une métrique, enregistrez source: "fourni par l'utilisateur" ; ne la mettez pas à niveau en "vérifié".
• N'inventez jamais de nom de studio, biographie personnelle ou coordonnées. Laissez-les vides et listez-les comme des échecs.
• Lorsqu'un README est utilisé, copiez le paragraphe textuellement et enregistrez son fichier et sa plage de lignes. Ne le polit, ne le raccourcissez et ne le réécrivez pas.
• Ne présentez pas un texte assisté par IA comme une décision personnelle de l'utilisateur. Les champs de processus et de réflexion restent vides jusqu'à ce que l'utilisateur les fournisse.

Sortie multi-versions

Le même projects.json prend en charge des versions ciblées. Ajoutez une liste select d'identifiants de projet, ou passez --only id1,id2 à build, pour produire une version destinée à une audience. Le réordonnancement est un changement de configuration, jamais une réécriture automatique. Cela suit la division documentée entre un site web pour la découverte et un PDF ou un diaporama pour les candidatures.

Pièges

• Ne jugez pas à partir d'un fragment. Lisez l'intégralité du README, l'intégralité de projects.json et l'intégralité du rapport de vérification avant de conclure quoi que ce soit comme complet ou cassé.
• La réussite des critères n'est pas la qualité. Un vérificateur vert signifie que la structure du fichier est saine. L'esthétique nécessite les yeux de l'utilisateur.
• Ne comblez pas les lacunes pour donner l'impression que la page est terminée. Une page visiblement incomplète est le résultat correct lorsque l'utilisateur n'a pas fourni les faits.
• Ne touchez pas aux répertoires personnels. L'analyse est en lecture seule sur la source. Toutes les écritures vont dans le répertoire de sortie.
• N'élargissez pas le périmètre à la génération de PDF, à l'hébergement ou à l'accès à l'API GitHub. Ceux-ci nécessitent une décision explicite de l'utilisateur.
• Les dimensions des images sont importantes. L'émission de width et height empêche le décalage de mise en page. Si Pillow n'est pas disponible, revenez à l'analyse d'en-tête et imprimez un avertissement visible ; ne dégradez jamais silencieusement.
• Un dossier équivaut à un projet. Si le matériel de l'utilisateur est plat, demandez un regroupement ou utilisez --flat pour créer un projet contenant tous les médias. N'inventez pas de regroupements.

Ressources

Chemin	Rôle
scripts/portfolio.py	CLI unique : scan, build, verify, all, --self-test. Bibliothèque standard plus Pillow optionnel.
references/content-spec.md	Règles de contenu basées sur la recherche, division des domaines, politique d'image et URL sources. Chargez avant de modifier les définitions de champs ou les modèles.
references/config-schema.md	Schéma complet de projects.json, significations des champs et ce qui compte comme source.
assets/template.html	Modèle responsive thème clair avec les deux modes. Remplacez uniquement les espaces réservés {{TOKEN}} ; ne réécrivez pas le CSS pour rechercher un style particulier.
assets/projects.sample.json	Un exemple de configuration clairement étiqueté DÉMO. Ne l'expédiez jamais comme le véritable portfolio de l'utilisateur.