Sasedev/pgr
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

0.1.5-alpha.2

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-10-01 09:53:53 +02:00
parent 32433caccf
commit e94b78610d
15 changed files with 406 additions and 65 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
docs/000-README.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/000-README.md -->
<!-- version: 47 -->
<!-- version: 48 -->
# Documentation PGR
@@ -22,9 +22,9 @@ Les templates techniques copiables sous `templates/` restent séparés des instr
## Points d'entrée de 0.1.5
- [`plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md`](plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md) — plan actif de `0.1.5` : inventaire `alpha.1`, sémantique normative, autonomie locale, frontière PGR / Knowledge, réconciliation puis freeze.
- [`plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md`](plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md) — plan actif de `0.1.5` : inventaire `alpha.1`, récupération de preuve `alpha.1.fix.1`, sémantique normative `alpha.2`, autonomie locale, frontière PGR / Knowledge, réconciliation puis freeze.
- [`studies/004-V0_1_4_HORIZON_REVIEW.md`](studies/004-V0_1_4_HORIZON_REVIEW.md) — décision autoritaire de fermeture `0.1.4` qui place la release de gouvernance/autonomie avant les adoptions Games/KSP.
- [`../RULES.md`](../RULES.md), [`rules/230-ADOPTION.md`](rules/230-ADOPTION.md) et [`rules/400-VALIDATION.md`](rules/400-VALIDATION.md) — owners primaires à réconcilier pour la force de `SHOULD`, les conséquences de gate et la distinction entre recommandation, choix local et `OVERRIDE`.
- [`../RULES.md`](../RULES.md), [`rules/230-ADOPTION.md`](rules/230-ADOPTION.md) et [`rules/400-VALIDATION.md`](rules/400-VALIDATION.md) — owners primaires réconciliés en `alpha.2` : `SHOULD / SHOULD NOT` est une forte recommandation non obligatoire, sans `FAIL` de gate ni `OVERRIDE` automatique pour un simple écart.
- [`rules/220-SKELETONS.md`](rules/220-SKELETONS.md), [`skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md`](skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md) et [`templates/007-EXISTING_PROJECT_ADOPTION.md`](templates/007-EXISTING_PROJECT_ADOPTION.md) — propagation du contrat d'autonomie après instanciation/adoption.
- [`objectives/001-PROJECT_OBJECTIVES.md`](objectives/001-PROJECT_OBJECTIVES.md), [`architecture/002-GOVERNANCE_ARCHITECTURE.md`](architecture/002-GOVERNANCE_ARCHITECTURE.md) et [`rules/300-DOCUMENTATION.md`](rules/300-DOCUMENTATION.md) — owners proposés pour formaliser la frontière PGR / SaseDev Knowledge sans dépendance externe.
- [`../prompts/011-V0_1_5_START_PROMPT.md`](../prompts/011-V0_1_5_START_PROMPT.md) — contrat de reprise exécuté pour ouvrir `0.1.5-alpha.1` à partir de la stable `v0.1.4` vérifiée.

87
docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md -->
<!-- version: 1 -->
<!-- version: 2 -->
# Plan 0.1.5 — sémantique normative, autonomie et frontière PGR / Knowledge
@@ -126,30 +126,30 @@ L’inventaire a recherché les formulations `SHOULD / SHOULD NOT`, les contrats
Sur le corpus normatif/documentaire courant analysé, `29` fichiers contiennent au moins un `SHOULD` ou `SHOULD NOT`, pour `242` occurrences textuelles brutes. Ce volume interdit une conversion mécanique : la majorité de ces recommandations sont légitimes et doivent seulement hériter d’une sémantique globale claire.
### Ambiguïtés normatives confirmées
### Ambiguïtés normatives observées en `alpha.1`
`RULES.md` décrit actuellement `SHOULD / SHOULD NOT` comme un comportement attendu avec dérogation lorsque l’alternative est « mieux adaptée et justifiée ». Cette formulation peut rendre la justification obligatoire et doit devenir l’owner primaire de la clarification.
Avant `alpha.2`, `RULES.md` décrivait `SHOULD / SHOULD NOT` comme un comportement attendu avec dérogation lorsque l’alternative était « mieux adaptée et justifiée ». Cette formulation pouvait rendre la justification obligatoire et a désigné `RULES.md` comme owner primaire de la clarification.
`RULES.md` exige aussi un override pour une contradiction intentionnelle. Le texte doit distinguer explicitement une contradiction à une obligation d’un simple choix différent d’une recommandation.
Avant `alpha.2`, `RULES.md` exigeait aussi un override pour toute contradiction intentionnelle sans distinguer explicitement une contradiction à une obligation d’un simple choix différent d’une recommandation.
`docs/rules/400-VALIDATION.md` ne précise pas encore qu’un écart à un `SHOULD` ne peut pas, à lui seul, faire échouer une gate.
Avant `alpha.2`, `docs/rules/400-VALIDATION.md` ne précisait pas qu’un écart à un `SHOULD` ne peut pas, à lui seul, faire échouer une gate.
`docs/rules/230-ADOPTION.md` définit `OVERRIDE` comme le remplacement ou raffinement d’une règle PGR applicable. Sans clarification de la force normative, cette définition peut pousser à créer un override pour une simple recommandation non suivie.
Avant `alpha.2`, `docs/rules/230-ADOPTION.md` définissait `OVERRIDE` comme le remplacement ou raffinement d’une règle PGR applicable. Sans clarification de la force normative, cette définition pouvait pousser à créer un override pour une simple recommandation non suivie.
`docs/rules/500-LANGUAGES.md` et `docs/rules/700-FRAMEWORKS.md` utilisent des formulations d’exception/override qui doivent être relues après stabilisation de la sémantique globale afin de ne pas renforcer accidentellement un `SHOULD`.
`docs/rules/500-LANGUAGES.md` et `docs/rules/700-FRAMEWORKS.md` utilisaient des formulations d’exception/override pouvant renforcer accidentellement un `SHOULD` ; `alpha.2` les a donc inclus dans la réconciliation ciblée.
Des cas concrets confirment que l’ambiguïté n’est pas théorique :
Les cas concrets observés pendant `alpha.1` confirmaient que l’ambiguïté n’était pas théorique :
- `docs/rules/530-TYPESCRIPT.md` associe une recommandation à une incompatibilité documentée ;
- `docs/rules/540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md` demande actuellement, pour la politique de lockfile, soit l’adoption de la recommandation soit un `OVERRIDE` ;
- `docs/skeletons/003-WEB_FRONTEND.md` exige une justification lorsqu’une nouvelle baseline durable n’adopte pas la recommandation TypeScript ;
- `docs/templates/008-WEB_TYPESCRIPT_PACKAGE.md` impose une décision locale ou un `OVERRIDE` avec justification pour une politique de lockfile différente.
- `docs/rules/540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md` demandait alors, pour la politique de lockfile, soit l’adoption de la recommandation soit un `OVERRIDE` ;
- `docs/skeletons/003-WEB_FRONTEND.md` exigeait une justification lorsqu’une nouvelle baseline durable n’adoptait pas la recommandation TypeScript ;
- `docs/templates/008-WEB_TYPESCRIPT_PACKAGE.md` imposait une décision locale ou un `OVERRIDE` avec justification pour une politique de lockfile différente.
Ces cas doivent être corrigés de façon ciblée après la définition centrale, sans affaiblir les `MUST` réellement applicables.
Ces cas ont été retenus pour une correction ciblée en `alpha.2`, sans affaiblir les `MUST` réellement applicables.
### Ambiguïté de trajectoire confirmée
### Ambiguïté de trajectoire observée en `alpha.1`
`docs/rules/540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md` conserve une référence vivante à « l’adoption `0.1.5` de Games ». La revue d’horizon `0.1.4` a déplacé cette adoption en `0.1.6`. Cette référence est donc obsolète et doit être corrigée comme cohérence documentaire vivante, sans modifier les plans, études, prompts ou histories qui décrivent correctement l’ancien horizon dans leur contexte historique.
Avant `alpha.2`, `docs/rules/540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md` conservait une référence vivante à « l’adoption `0.1.5` de Games ». La revue d’horizon `0.1.4` avait déplacé cette adoption en `0.1.6`. `alpha.2` corrige cette référence vivante sans modifier les plans, études, prompts ou histories qui décrivent correctement l’ancien horizon dans leur contexte historique.
### Autonomie — acquis à conserver
@@ -179,41 +179,58 @@ Ces acquis doivent être consolidés plutôt que réécrits en bloc.
`docs/rules/300-DOCUMENTATION.md` est l’owner naturel pour formaliser la frontière documentaire sans créer un owner Knowledge artificiel. PGR ne doit pas créer une règle ou une collection dédiée uniquement parce que Knowledge existe comme produit séparé.
## Owners proposés
## Owners issus de l'inventaire
Les modifications ne sont engagées qu’après validation de cet inventaire.
L'inventaire `alpha.1` a fixé les owners ci-dessous. Leur modification reste répartie par tranche afin de ne pas mélanger sémantique normative, autonomie et frontière Knowledge.
```text
sémantique primaire
RULES.md MODIFY
docs/rules/230-ADOPTION.md MODIFY
docs/rules/400-VALIDATION.md MODIFY
RULES.md MODIFY alpha.2
docs/rules/230-ADOPTION.md MODIFY alpha.2 puis alpha.3
docs/rules/400-VALIDATION.md MODIFY alpha.2
réconciliation ciblée des effets SHOULD
docs/rules/500-LANGUAGES.md REVIEW / MODIFY IF NEEDED
docs/rules/530-TYPESCRIPT.md MODIFY
docs/rules/540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md MODIFY
docs/rules/700-FRAMEWORKS.md REVIEW / MODIFY IF NEEDED
docs/skeletons/003-WEB_FRONTEND.md MODIFY
docs/templates/008-WEB_TYPESCRIPT_PACKAGE.md MODIFY
docs/rules/500-LANGUAGES.md MODIFY alpha.2
docs/rules/530-TYPESCRIPT.md MODIFY alpha.2
docs/rules/540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md MODIFY alpha.2
docs/rules/700-FRAMEWORKS.md MODIFY alpha.2
docs/skeletons/003-WEB_FRONTEND.md MODIFY alpha.2
docs/templates/008-WEB_TYPESCRIPT_PACKAGE.md MODIFY alpha.2
autonomie
RULES.md MODIFY
docs/rules/220-SKELETONS.md MODIFY
docs/rules/230-ADOPTION.md MODIFY
docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md MODIFY
docs/templates/007-EXISTING_PROJECT_ADOPTION.md MODIFY
RULES.md MODIFY alpha.3
docs/rules/220-SKELETONS.md MODIFY alpha.3
docs/rules/230-ADOPTION.md MODIFY alpha.3
docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md MODIFY alpha.3
docs/templates/007-EXISTING_PROJECT_ADOPTION.md MODIFY alpha.3
docs/rules/210-WORKFLOW.md KEEP / REVIEW
docs/templates/003-NEW_SESSION_PROMPT.md KEEP / REVIEW
frontière PGR / Knowledge
docs/objectives/001-PROJECT_OBJECTIVES.md MODIFY
docs/architecture/002-GOVERNANCE_ARCHITECTURE.md MODIFY
docs/rules/300-DOCUMENTATION.md MODIFY
docs/objectives/001-PROJECT_OBJECTIVES.md MODIFY alpha.4
docs/architecture/002-GOVERNANCE_ARCHITECTURE.md MODIFY alpha.4
docs/rules/300-DOCUMENTATION.md MODIFY alpha.4
```
Aucun nouveau owner Knowledge n’est prévu par défaut.
## Progression acquise avant `alpha.2`
La première gate `alpha.1` a acquis les tests et audits principaux mais n'a pas exécuté toutes les assertions contractuelles prévues par son delta. Son history conserve donc le résultat réel `PARTIAL`.
`alpha.1.fix.1` a été limité à l'acquisition des preuves manquantes : trajectoire ROADMAP, frontière delta/history, assertions du prompt `011`, assertions du présent plan et audits documentaires. Cette récupération est `PASS` et n'a modifié aucun owner normatif.
La tranche `alpha.2` peut donc appliquer la sémantique centrale sans réécrire les `242` occurrences de recommandations. Les modifications sont bornées aux owners et artefacts où l'inventaire a démontré un renforcement accidentel ou une référence vivante obsolète : `RULES.md`, `230`, `400`, `500`, `530`, `540`, `700`, le skeleton Web `003` et le guide `008`.
Décisions de mise en œuvre `alpha.2` :
- `SHOULD / SHOULD NOT` devient explicitement une forte recommandation non obligatoire ;
- un écart à cette recommandation ne crée ni non-conformité, ni `FAIL` de gate, ni `OVERRIDE` automatique ;
- un projet MAY documenter la raison d'un écart lorsqu'elle apporte une valeur durable ;
- les contradictions avec des obligations `MUST / MUST NOT` restent soumises aux contrats d'exception/override applicables ;
- la référence vivante à l'adoption Games est corrigée de `0.1.5` vers `0.1.6` ;
- l'autonomie post-adoption reste réservée à `alpha.3` et la frontière Knowledge à `alpha.4`.
## Trajectoire de release
### `alpha.1` — intake, audit transversal et plan
@@ -278,9 +295,9 @@ Aucun nouveau owner Knowledge n’est prévu par défaut.
- une migration physique vers SaseDev Knowledge ;
- une conversion globale de tous les `SHOULD` en `MUST` ou `MAY`.
## Gate de planification
## Gate de planification `alpha.1` — historique
`alpha.1` est prête à validation opérateur lorsque :
`alpha.1` était prête à validation opérateur lorsque :
- la baseline `0.1.4` a été rejouée proprement ;
- l’historique `0.1.4` reste intact, y compris `alpha.2 FAIL` puis `alpha.2.fix.1 PASS` ;

10
docs/rules/230-ADOPTION.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/rules/230-ADOPTION.md -->
<!-- version: 1 -->
<!-- version: 2 -->
# Existing project adoption rules
@@ -50,6 +50,8 @@ OVERRIDE
DEFER
```
Ces classifications n'augmentent pas la force normative d'une règle. En particulier, choisir une solution différente d'un `SHOULD` / `SHOULD NOT` ne crée pas à lui seul un `OVERRIDE` obligatoire ; le projet MAY conserver ce choix comme décision locale et documenter sa raison lorsque cette trace apporte une valeur durable.
### ADOPT
`ADOPT` signifie que le projet retient le contrat PGR applicable et migre son état local lorsque nécessaire.
@@ -64,9 +66,9 @@ Cette classification ne crée pas une exception : elle reconnaît qu’un choix
### OVERRIDE
`OVERRIDE` signifie qu’une règle PGR applicable est volontairement remplacée ou raffinée dans un scope local.
`OVERRIDE` signifie qu'une obligation PGR réellement applicable, ou un contrat localement rendu obligatoire, est volontairement remplacé ou raffiné dans un scope local.
L’override MUST identifier la règle concernée, le scope, la raison et le contrat local retenu. Il ne doit pas être utilisé pour masquer une migration incomplète ou faire disparaître une violation non résolue.
L'override MUST identifier la règle concernée, le scope, la raison et le contrat local retenu. Il ne doit pas être utilisé pour masquer une migration incomplète ou faire disparaître une violation non résolue. Un simple écart à une recommandation `SHOULD` / `SHOULD NOT` MUST NOT exiger un override uniquement parce que la recommandation n'est pas suivie.
### DEFER
@@ -119,7 +121,7 @@ Une adoption PGR réussie laisse :
- un projet autonome ;
- uniquement les owners PGR réellement applicables ;
- les choix locaux légitimes préservés ;
- les overrides explicites ;
- les overrides explicites lorsqu'une obligation applicable est volontairement remplacée ;
- les domaines différés clairement identifiés ;
- un historique non falsifié ;
- une validation proportionnée au changement réellement effectué.

8
docs/rules/400-VALIDATION.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/rules/400-VALIDATION.md -->
<!-- version: 1 -->
<!-- version: 2 -->
# Validation rules
@@ -27,6 +27,12 @@ Une preuve déjà acquise MAY être réutilisée tant qu'aucun changement pertin
Les gates de `beta`, `rc` et promotion stable MAY élargir volontairement la validation pour démontrer l'intégration ou la cohérence de release.
## Force normative et résultat des gates
Une gate MUST distinguer une obligation `MUST / MUST NOT` d'une recommandation `SHOULD / SHOULD NOT`. Un écart à un `SHOULD` ou `SHOULD NOT` PGR ne constitue pas à lui seul une preuve en échec et MUST NOT faire passer une tranche en `FAIL`.
Une gate MAY signaler un écart à une recommandation comme observation, diagnostic ou point de revue. Si un projet décide de rendre cette recommandation obligatoire dans un scope local, il doit matérialiser ce contrat local explicitement ; la gate évalue alors ce contrat local, pas le `SHOULD` PGR d'origine.
## Matrice de validation
Un projet suffisamment structuré SHOULD posséder une matrice de validation canonique, par défaut sous :

4
docs/rules/500-LANGUAGES.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/rules/500-LANGUAGES.md -->
<!-- version: 1 -->
<!-- version: 2 -->
# Règles de profils langage et écosystème
@@ -31,7 +31,7 @@ Les profils de cette famille héritent des règles générales PGR et ne doivent
Une règle générale comme l'interdiction de versionner des secrets reste applicable sans être répétée dans chaque profil langage.
Lorsqu'un langage ou un build tool impose une exception réelle à une règle générale, le profil spécifique doit déclarer l'override et sa justification.
Lorsqu'un langage ou un build tool impose une contradiction réelle avec un `MUST / MUST NOT` général applicable, le profil spécifique MUST déclarer l'override ou l'exception et sa justification. Un choix différent d'un `SHOULD / SHOULD NOT` général ne nécessite pas, à lui seul, un override.
## Langage et build tool

6
docs/rules/530-TYPESCRIPT.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/rules/530-TYPESCRIPT.md -->
<!-- version: 3 -->
<!-- version: 4 -->
# Profil TypeScript
@@ -15,7 +15,7 @@ Le profil s'applique lorsqu'une partie du source contrôlé est écrite en TypeS
Pour un frontend que l'organisation contrôle, TypeScript **SHOULD** être préféré à du JavaScript non typé dès que le frontend porte une logique durable non triviale.
Cette préférence n'est pas une obligation universelle. Du JavaScript direct MAY rester approprié pour un artefact très petit, un script isolé, une contrainte externe ou un environnement où l'introduction de TypeScript n'apporte pas une valeur proportionnée.
Cette préférence n'est pas une obligation universelle. Du JavaScript direct MAY rester approprié pour un artefact très petit, un script isolé, une contrainte externe ou un environnement où l'introduction de TypeScript n'apporte pas une valeur proportionnée. Choisir JavaScript ne constitue donc pas à lui seul une non-conformité, n'exige pas automatiquement un `OVERRIDE` et ne crée pas une obligation de justification ; la décision MAY être documentée lorsqu'elle apporte une valeur durable.
La justification de la recommandation est fonctionnelle : TypeScript ajoute une vérification statique avant exécution et permet de détecter une partie des incohérences de types pendant la validation plutôt qu'au runtime.
@@ -61,7 +61,7 @@ noEmit = true
`strict` exprime la volonté d'utiliser le contrôle de types renforcé de TypeScript. `noEmit` sépare le type-check de la production des artefacts JavaScript lorsque cette production appartient à un bundler ou à un autre outil.
Pour une baseline stricte, PGR `SHOULD` également activer les contrôles simples suivants sauf incompatibilité documentée :
Pour une baseline stricte, PGR `SHOULD` également activer les contrôles simples suivants lorsqu'ils sont pertinents pour le package :
```text
noUnusedLocals = true

4
docs/rules/540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/rules/540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md -->
<!-- version: 3 -->
<!-- version: 4 -->
# Profil écosystème de packages JavaScript
@@ -67,7 +67,7 @@ Un package **SHOULD NOT** conserver simultanément plusieurs lockfiles concurren
Lorsqu'un lockfile est versionné, la CI **SHOULD** utiliser le mode de résolution gelé, immutable ou clean-install fourni par le package manager sélectionné. Le nom exact de cette commande reste local à l'outil ; PGR MUST NOT transformer `npm ci` en commande universelle.
L'absence actuelle de lockfiles dans Games reste historique. Lors de l'adoption `0.1.5`, chaque package concerné devra soit `ADOPT` cette recommandation, soit documenter un `OVERRIDE` si une autre politique reste préférable.
L'absence actuelle de lockfiles dans Games reste historique. Lors de l'adoption `0.1.6`, chaque package concerné devra décider sa politique de lockfile selon son rôle et ses contraintes. Versionner le lockfile reste une recommandation `SHOULD` pour les applications privées, frontends déployables et outils livrés ; conserver une autre politique ne requiert pas à lui seul un `OVERRIDE`, même si la décision locale MAY être documentée lorsqu'elle apporte une valeur durable.
## Validation

4
docs/rules/700-FRAMEWORKS.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/rules/700-FRAMEWORKS.md -->
<!-- version: 2 -->
<!-- version: 3 -->
# Règles de profils framework
@@ -45,7 +45,7 @@ GENERAL
+ Tauri
```
Lorsque PGR gouverne la baseline du projet, les règles des profils hérités restent applicables dans leur scope complet tant qu'un override plus spécifique n'est pas documenté. Un framework ne constitue pas à lui seul une justification pour affaiblir une convention de langage, de plateforme ou de sécurité.
Lorsque PGR gouverne la baseline du projet, les règles des profils hérités restent applicables dans leur scope avec leur force normative propre. Un framework MUST NOT contredire silencieusement un `MUST / MUST NOT` hérité ; une telle contradiction exige l'override ou l'exception applicable. Un framework MAY choisir différemment d'un `SHOULD / SHOULD NOT` sans que cet écart constitue à lui seul un override ou une non-conformité.
Un projet existant ou imposé de l'extérieur MAY conserver des contraintes différentes. Ces écarts appartiennent alors au niveau project-specific ou à une exception explicite et bornée ; ils ne doivent pas être remontés comme nouvelle règle générale du framework.

4
docs/skeletons/003-WEB_FRONTEND.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/skeletons/003-WEB_FRONTEND.md -->
<!-- version: 1 -->
<!-- version: 2 -->
# Skeleton — Web frontend
@@ -65,7 +65,7 @@ Le nom `frontend/` est une convention possible, pas un chemin imposé par ce ske
Résoudre explicitement au minimum :
1. la racine et le scope exacts du frontend ;
2. TypeScript ou JavaScript, avec justification si une nouvelle baseline durable n'adopte pas la recommandation TypeScript ;
2. TypeScript ou JavaScript ; pour une nouvelle baseline durable, considérer explicitement la recommandation TypeScript sans transformer un choix JavaScript en obligation de justification ou en `OVERRIDE` ;
3. le package manager réel et la politique de lockfile adaptée au rôle du package ;
4. les versions réelles de TypeScript et des dépendances, ainsi que les déclarations `@types/*` réellement nécessaires ;
5. Vite ou un build tool alternatif, avec ses chemins `root`, cache, outputs, `base`, ports, plugins et assets lorsqu'ils s'appliquent ;

4
docs/templates/008-WEB_TYPESCRIPT_PACKAGE.md vendored
View File

@@ -1,5 +1,5 @@
<!-- file: docs/templates/008-WEB_TYPESCRIPT_PACKAGE.md -->
<!-- version: 2 -->
<!-- version: 3 -->
# Templates de package Web TypeScript
@@ -135,7 +135,7 @@ Ces lignes sont des exemples, pas une sélection de package manager par PGR.
Pour une application privée/deployable issue de ce template, le lockfile du package manager sélectionné SHOULD normalement être versionné.
Si le projet conserve volontairement une autre politique, l'écart doit être traité comme décision locale ou `OVERRIDE` lors d'une adoption PGR, avec justification proportionnée.
Si le projet conserve volontairement une autre politique, l'écart reste une décision locale. Ne pas suivre ce `SHOULD` n'exige pas à lui seul un `OVERRIDE` ni une justification ; documenter la raison reste utile lorsqu'elle apporte une valeur durable de maintenance, reproductibilité ou reprise.
PGR MUST NOT conserver plusieurs lockfiles concurrents uniquement pour rendre le template compatible avec plusieurs package managers.