tencentmusic/modus

modus-reinit

Utilisé lors de la révision complète du contenu existant. Consultez le guide des preuves, le cadre de génération et le contrat de publication ; ce fichier ne décrit que les différences de reinit.

D'abord inventorier, puis prouver les changements

Lisez entièrement le contenu existant et les hachages, en classant les cibles comme unchanged, anchor-only, implementation-change, scope-change, content-repair, suspecté décommissionné ou contenu manuel. Les identités stables et les définitions principales sont réutilisées par défaut ; les déplacements de chemin source / symbole ne modifient que les ancres, les changements de mise en page ne sont pas des changements de Scope.

content-repair inclut : remplacement de paragraphes génériques par des scénarios réels, remplacement d'ancres représentatives par des faits, copie entre modules, ambiguïté sémantique de complétion/échec, relations complexes manquant de diagrammes significatifs pour la compréhension. Le contenu qui répond réellement aux tâches du lecteur et dont les faits n'ont pas changé reste unchanged et est passé.

Exécution

1. Construisez une fois les preuves de ce tour de manière synchronisée pour un seul dépôt et obtenez le contexte reinit-diff ; en cas d'échec, revenez immédiatement au code source actuel. Développez de manière dirigée selon le contrat de preuves machine, sans lire directement les fichiers internes du bundle, et sans viser à épuiser le curseur.
2. Selon la modélisation du Scope avec l'ordre "identité stable → responsabilité d'entrée/objet → changement sémantique → changement structurel → changement de fichier", évaluez et écrivez la portée, les handles, les hachages de lecture, l'evidence/status précis du Domain/Module, la couverture du Domain, le résultat final et les candidats de diagrammes dans une carte d'exécution unique avec schemaVersion: 2. Ne confirmez qu'une seule fois les ajouts, fusions, déplacements, renommages ou décommissionnements déjà prouvés. Par défaut, exécution séquentielle ; lorsque l'utilisateur l'autorise explicitement et qu'il existe plusieurs Domaines affectés sans chevauchement, chargez la rédaction parallèle par Domaine et utilisez le contrat de délégué Domaine ; l'auteur racine continue d'occuper la carte d'exécution et les artefacts partagés.
3. Pour chaque Module modifié ou faisant l'objet d'un content-repair, demandez un contexte module-authoring avec un sélecteur précis, vérifiez les doubles résumés et le requestedScope ; les demandes larges couvrant plusieurs Modules indépendants dans tout un domaine sont invalides. Les demandes précises non dépendantes peuvent être concurrentes, puis regroupez et dédupliquez les chemins source/symboles du Domaine courant, avant de relire par lots. En cas d'échec de la demande, de résultat vide ou partiel, revenez aux méthodes, configuration, SQL et tests actuels pour compléter les preuves ; n'utilisez pas les noms de classe, signatures d'interface ou ancres de première ligne comme preuve de contenu restauré. N'analysez pas plusieurs fois la même chaîne pour différents sujets, et n'écrivez pas simultanément le même contenu. Reprouvez selon la clôture de scénario ; révisez la définition principale d'origine, n'ajoutez pas de changelog, ne réécrivez ni ne redessinez pas en masse en raison de changements de modèle.
4. Relisez la portée affectée par lots complets de Domaine selon "définition principale des six sujets → scénarios de Module → routage du Domaine". Migrez les chemins source et les numéros de ligne vers les quelques anchors.locations du frontmatter de chaque document généré ; supprimez les chemins source complets, path#L et les listes de preuves du contenu. L'objectif de la réparation est de restaurer la tâche complète, la sémantique des champs, les branches clés, les états et la récupération d'erreurs, pas de redonner au fichier des titres, des ancres ou une longueur similaire. Après la clôture des preuves, réévaluez les candidats selon l'expression visuelle et mettez à jour le diagramme principal unique ; la table de navigation ne remplace pas les diagrammes explicatifs. L'audit de couverture coverage-audit au niveau du Domaine doit réutiliser la portée des candidats/capacités/chemins source/symboles de ce Domaine, sans utiliser modus/knowledge/** ; les résultats sans correspondance, vides ou partiels ne déclenchent qu'une complétion de preuve ou l'identification claire d'une lacune. Enregistrez les résultats valides comme couverture du Domaine, et après avoir terminé la relecture des trois types de lecteurs, l'auteur racine lit les fichiers réels et les marque reviewed. Ne mettez à jour la vue d'ensemble racine qu'en cas de changements de direction inter-domaines, de propriété, d'état, de condition, de complétion ou de restauration ; le Team Standard et les éléments business existants sont protégés par octet par défaut ; pour les nouveaux Domaines, utilisez modus knowledge seed-business --domain <slug> --json pour créer les index manquants.
5. Pour les changements structurels, écrivez d'abord la nouvelle cible et effectuez une relecture sémantique, réparez les liens entrants et la navigation du contenu généré, puis supprimez les anciens fichiers générés en fonction des hachages de lecture. Ne déduisez pas un décommissionnement directement à partir de la disparition de symboles, de résultats partiels ou de lacunes de couverture.
6. Après la relecture sémantique globale, exécutez modus knowledge verify --publication --json, publiez en CAS et relisez. La publication doit vérifier la carte d'exécution avec schemaVersion: 2, l'absence de chemins source dans le contenu, les ancres structurées, les preuves par Module, la couverture du Domaine et la décision visuelle ; clean n'est toujours pas une preuve de qualité du contenu. Continuez à réviser en cas de nombreux textes courts de même longueur, d'absence de scénarios réels, de tables de navigation uniquement, de sujets d'état sans transition ou de preuves ne tombant que sur la première ligne. Ne supprimez pas la carte d'exécution prématurément, et ne la reconstruisez pas en une carte plus petite "tout reviewed" basée sur la sortie après l'avoir perdue. Ne nettoyez la carte d'exécution qu'une fois que toutes les cibles ont atteint l'état final et que la relecture sémantique, la publication réelle et la relecture après publication sont toutes réussies ; les vérifications mécaniques ordinaires ne remplacent pas la publication. Rapportez fidèlement les éléments inchangés (unchanged), les révisions, les suppressions, les conflits et les lacunes.