Édition d'article de physique — section
À utiliser pour une section entière de physique de toute longueur, une note technique ou tout passage de physique de plus de 12 phrases typographiques en LaTeX, Markdown ou texte brut. Utilisez physics-paper-editing directement pour les passages plus courts (hors section). Le canon est physics-language-principles.
Toutes les sessions héritées/version-1 sont des enregistrements historiques fermés. Ne les reprenez jamais et ne comptez pas leurs vérifications dans l'achèvement en cours. Chaque nouveau passage ou passage répété démarre un cycle d'édition version-2 avec son propre identifiant de cycle et un instantané source ; voir disk-layout.md.
Ordre de lecture
- Avant la première réponse à l'utilisateur, lisez le runtime-contract.md et le user-communication.md du micro-skill. Suivez la politique de communication avant chaque réponse ultérieure à l'utilisateur.
- En cas de reprise, résolvez le cycle version-2 actif via
CURRENT, lisez lesession.mdde ce cycle, puis cross-skill.md. Pour les limites d'automatisation de reprise, lisez aussi automation.md. - Lisez stages.md et disk-layout.md.
- Avant l'édition par bloc, lisez chunk-contract.md et le micro-skill actif SKILL.md.
- Lisez scope-and-verifiers.md pour la révision de l'étape B ou E. Lorsque le projet possède un fichier de décisions, lisez aussi rulings-file.md.
- Avant l'achèvement, lisez test-checklist.md.
Conception directrice
La section est organisée autour d'une colonne vertébrale physique globale et d'un registre global d'objets avant que la prose locale ne soit optimisée. Chaque bloc en hérite. Un bloc ne peut pas introduire une normalisation concurrente, une convention de facteur, un symbole dupliqué ou une portée modifiée sans réconciliation avec le registre global.
Le découpage en blocs reste un mécanisme d'attention et de persistance. Un éditeur de section expérimenté peut créer des blocs directement ; un éditeur novice ou inconnu utilise l'échafaudage. Chaque bloc ordinaire utilise le contrat direct | reviewed du micro-skill. Une unité sûre au format source qui ne peut pas être divisée en dessous de 13 phrases reste un bloc surdimensionné appartenant à la section et utilise le contrat révisé directement plutôt que de violer une définition ou une limite d'équation.
Chaque bloc doit préserver la terminologie et la notation établies de la section. L'assemblage de blocs ne peut pas introduire une nouvelle étiquette raccourcie, un alias mathématique ou un nom dupliqué absent de la source et du contexte global, sauf si names-and-symbols.md l'autorise et qu'il est réconcilié délibérément.
Étapes
| Étape | Résultat |
|---|---|
| A | Cycle version-2, source immuable, intention d'édition, couverture linguistique, politique rôle-à-modèle, périmètre de la section |
| B | Colonne vertébrale physique de la section, carte des paragraphes, registre global d'objets, plan structurel |
| C | Blocs d'argumentation sûrs au format source, normalement au plus 12 phrases, avec un repli défini pour les unités surdimensionnées |
| D | Édition directe ou révisée par bloc ; registre global mis à jour délibérément |
| E | Révision physique à l'échelle de la section, cohérence des objets et révision formelle : au plus deux cycles de relecteurs indépendants en aveugle, combinés et arbitrés |
Ne lancez pas un relecteur par phrase. Un bloc révisé utilise un relecteur de phrase entier et un relecteur de terminologie et notation, plus des spécialistes déclenchés. N'exigez pas de relecteur pour un bloc direct à faible risque. Ne rouvrez que les passages qui échouent à un axe de qualité requis.
Dans la première réponse à l'utilisateur, suivez le contrat d'exécution du micro-skill. S'il existe une politique de correspondance rôle-à-modèle pour le projet ou la conversation en cours, énoncez son mappage et continuez sans demander de confirmation. Sinon, demandez et attendez. Enregistrez le mappage actif dans session.md et transmettez-le à chaque bloc et à chaque révision à l'échelle de la section. Les blocs ne demandent pas à nouveau.
Chaque cycle déclare également language_coverage: selective | exhaustive. La couverture sélective audite les phrases modifiées ou diagnostiquées ainsi que la prose au niveau du bloc. La couverture exhaustive donne à chaque phrase de chaque bloc actuel un verdict linguistique basé sur un instantané actuel. N'inférez pas une couverture exhaustive de la simple existence d'artefacts de blocs anciens ; demandez lorsque la couverture demandée est ambiguë. Détail : language-coverage.md du micro-skill.
La couverture sélectionne des phrases, pas des principes. Chaque phrase dans le périmètre reçoit les 16 vérifications de phrase, et chaque phrase dans un texte nouvellement rédigé compte comme modifiée.
Persistance
Le travail sur une section est normalement reproductible, donc persistez chaque cycle version-2, son texte de section original immuable et ses limites, le candidat actuel, le brief, la révision du contexte et du registre d'objets, le manifeste des blocs, les hachages et les résultats de qualité sous .physics-edit/ comme spécifié dans disk-layout.md. Les cycles historiques restent des preuves immuables et ne satisfont jamais un cycle ultérieur.
Langage destiné à l'utilisateur
Conservez le vocabulaire exact de version, cycle, instantané, routage et statut dans les enregistrements persistés, là où il est nécessaire pour l'exactitude. En conversation, suivez la politique de communication utilisateur partagée : décrivez ce qui se passe dans un langage ordinaire et ne présentez jamais une étiquette interne sans expliquer immédiatement ce qu'elle signifie pour le texte de l'auteur.
Porte de conformité
La comptabilité d'un cycle est un programme, scripts/check_edit_round.py (exécutez-le avec python3 ; il ne nécessite aucun package ; --root par défaut pointe vers le niveau supérieur du dépôt git actuel). Il conserve les verdicts par phrase, émet des paquets de relecteur avec le hachage du texte qu'ils montrent, enregistre les rapports des relecteurs et décide avec check si le cycle peut être signalé comme prêt. Il n'appelle aucun LLM et ne modifie aucun texte du manuscrit. La politique rôle-à-modèle du projet à la racine du dépôt est physics-edit-policy-<platform>.json pour la plateforme hôte active (par exemple physics-edit-policy-antigravity.json sur Antigravity ou physics-edit-policy-claude.json sur Claude Code, sélectionnée automatiquement à partir de l'environnement hôte ou avec --platform <platform>), avec repli sur physics-edit-policy.json ; la compétence ne stocke pas de valeur par défaut, donc demandez au propriétaire lorsqu'elle est manquante et écrivez la réponse avec policy set (ou policy set --platform <platform>).
Lorsque le dépôt contient project-vocabulary.json et que la compétence sœur physics-vocabulary est installée, check scanne également chaque phrase révisée, légendes comprises, pour les avoid_names de l'ensemble du registre (les commentaires, les étiquettes et les chemins ne sont pas lus). Un résultat positif bloque le cycle jusqu'à ce que la phrase soit corrigée, ou, lorsque les mots ne nomment pas le concept enregistré, jusqu'à ce qu'un waive --roles terminology enregistre pourquoi ; transmettez les résultats au relecteur de terminologie du bloc. Les paquets pour le relecteur de phrases et de terminologie contiennent également l'ensemble du paragraphe avant le bloc et le rapport consultatif de scripts/check_prose_patterns.py pour le bloc ; les paquets holistiques de l'étape E contiennent le rapport sur l'ensemble du texte. Les relecteurs confirment ou infirment ses candidats ; le rapport ne bloque jamais un cycle par lui-même. Chaque paquet contient les lignes de la carte des paragraphes pour son bloc (étape E : la carte entière). Lorsque le dépôt contient RULINGS.md, digest et stage-e merge l'impriment une fois par cycle, pour l'agent qui pèse les conclusions ; digest --rulings l'imprime à nouveau après une reprise. Aucun paquet de relecteur ne le contient.
Commandes : policy, init, chunks, rechunk, pending, prompt, record,
digest, waive, stage-e, status, snapshot, defect, revision, gc, check
(--help liste les options). Exécutez-les aux moments ci-dessous. Doit signifie que le programme refuse l'étape suivante ou que check échoue sans cela.
| # | Moment | Exécuter | |
|---|---|---|---|
| 1 | Début d'un cycle | policy show (si manquant : demander au propriétaire, puis policy set), init, remplir le brief, la carte des paragraphes et le registre, check | doit : politique, init ; devrait : check (seuls le brief, la carte des paragraphes, le registre et les attestations doivent être ouverts) |
| 2 | Reprise dans une nouvelle session ou après compactage | status, pending, digest --rulings, check | doit. status liste les paquets émis mais non enregistrés : enregistrez-les ou supprimez-les avant d'en lancer de nouveaux |
| 3 | Un élément est divisé, fusionné, déplacé ou ajouté | rechunk, chunks | doit. Un bloc dont au moins la moitié des phrases sont déjà révisées conserve son identifiant |
| 4 | Après chaque lot d'édition, une fois la vérification canonique de l'éditeur terminée | record --role editor_closure, puis digest (aucune conclusion acceptée ne peut être non appliquée), pending, prompt | doit : la clôture (prompt refuse sans elle). Une correction que vous décidez de ne pas appliquer : waive --reason |
| 5 | Lancement d'un relecteur | le modèle et l'effort que prompt imprime | doit |
| 6 | Résultat d'un relecteur | record --packet pNNN --report FILE --model M --effort E | doit. Il applique le modèle et l'effort, la révision, et un verdict pour chaque phrase dans le périmètre. Les phrases qui ont changé depuis l'émission du paquet sont signalées, pas rejetées : leurs verdicts ne correspondent simplement plus |
| 7 | Une révision de phrase avec des résultats de principes FIX | prompt --role specialist --principles ... avant la réparation | doit (la porte doit un spécialiste par résultat) |
| 8 | Un lot est enregistré | pending, digest ; décidez chaque story_check, puis éditez sous la ligne 4 | devrait |
| 9 | Rien en attente dans un bloc | prompt --scope close pour le relecteur de phrases et de terminologie, puis réparations par les lignes 4 à 8 | doit : check a besoin d'une révision de clôture par rôle, sauf pour un bloc que la couverture sélective laisse inchangé |
| 10 | Après la dernière édition | snapshot | doit (check échoue jusqu'à ce que l'instantané soit égal au texte en direct) |
| 11 | Avant l'étape E | check ne montre aucune ligne commençant par un identifiant de bloc | doit : `prompt --role holistic |
| 12 | Un cycle d'étape E (au plus deux) | prompt --role holistic et --role formal une fois par relecteur (3 par rôle au cycle 1, 2 au cycle 2 ; le programme en refuse plus), chacun lancé comme un nouvel agent qui n'obtient que la ligne imprimée ; record --packet pour chacun ; stage-e merge ; `stage-e rule --cluster K.. --as applied | waived |
| 13 | Une décision du propriétaire, une réparation d'étape E, ou un déplacement entre blocs | defect rule si un défaut a été enregistré ; pending pour le rayon d'explosion ; mettez à jour le fichier de décisions (rulings-file.md) ; revision --yes seulement si la colonne vertébrale, le registre ou les conventions sur lesquelles les relecteurs jugent ont changé | doit pour defect rule. Une augmentation imprime et rejette chaque verdict actuel et rejette les paquets encore en cours. Une modification du registre, du brief ou de reviewer-context.md sans augmentation n'est qu'avertie lorsqu'un paquet est enregistré |
| 14 | Avant chaque rapport au propriétaire | check ; citez sa dernière ligne ; terminez par "Écarts par rapport à la compétence :" | doit |
| 15 | À la fin d'un cycle, ou lorsqu'on vous interroge sur l'utilisation du disque | gc | devrait. Il liste les cycles au-delà de la rétention et ne supprime rien ; gc --compact supprime la majeure partie des cycles expirés (rapports bruts, paquets, cartes de phrases, instantanés) et seulement avec l'accord du propriétaire |
Achèvement
Une section est prête seulement lorsque tous les blocs sont intégrés, que chaque résultat requis correspond aux instantanés actuels du bloc et de la section, que la couverture linguistique déclarée est complète, qu'aucun axe de qualité requis d'un bloc n'est FIX ou USER_DECISION, et que l'étape E est arbitrée : au plus deux cycles de relecteurs indépendants en aveugle, chaque cluster obligatoire appliqué ou levé (aucun ouvert, aucun différé au propriétaire). L'indépendance de la vérification est enregistrée séparément de la qualité du contenu.
Un défaut scientifique dans la source de l'auteur que la tâche demandée n'a pas déjà autorisé à réparer suit la règle dans quality-contract.md : enregistrez-le avec defect add, continuez à travailler sur les blocs qui n'en dépendent pas, et laissez le cycle needs_user jusqu'à ce que l'auteur décide. Ne convertissez pas le défaut en une limitation au moment de l'achèvement.
Compétences associées
- physics-paper-workflow — recette principale et carte des étapes à travers l'article
- physics-paper-outline — planification, formule d'introduction en 4 paragraphes et limite entre le corps du texte et l'annexe
- physics-paper-framing — résumés, paragraphes de synthèse et alignement Conclusion ↔ Introduction
- physics-language-principles — canon de rédaction et de révision
- physics-paper-editing — passages d'au plus 12 phrases, et chaque bloc
- physics-paper-author-read — réponse aux propres modifications et commentaires en marge de l'auteur ; son langage passe par cette compétence
Hors périmètre
- Passages hors section d'au plus 12 phrases
- Invention de sens physique manquant
- Traiter les limites de blocs comme une permission de redéfinir localement des objets globaux
- Reprendre ou réactiver une session héritée/version-1