@autocode-cli/autocode 0.1.29 → 0.1.31

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@autocode-cli/autocode",
3
- "version": "0.1.29",
3
+ "version": "0.1.31",
4
4
  "description": "Filesystem-based issues system with web dashboard",
5
5
  "type": "module",
6
6
  "main": "dist/index.js",
@@ -6,16 +6,13 @@ Re-run unit tests after development work to verify no regressions were introduce
6
6
 
7
7
  ## Actions
8
8
 
9
- 1. Pull the latest changes from the development branch
10
- 2. Install or update dependencies if package files changed
11
- 3. Run the full unit test suite
12
- 4. Analyze any test failures to determine if they are regressions
13
- 5. If regressions found, identify the commits or changes that caused them
14
- 6. Document test results including pass/fail counts and coverage metrics
15
- 7. Verify test coverage has not decreased from baseline
16
- 8. If out of scope work detected: `autocode new "<title>" "<description>" --priority P2 --labels "<labels>" --acceptance "<criteria>" --semver patch --column backlog`
17
- 9. Document: `autocode comment <issue-key> "[summary]"`
18
- 10. Advance: `autocode next <issue-key>`
9
+ 1. Run the full unit test suite: `npm test`
10
+ 2. Analyze any test failures to determine if they are regressions
11
+ 3. If regressions found, identify the changes that caused them
12
+ 4. If tests fail: return to dev column for fixes
13
+ 5. Verify test coverage has not decreased
14
+ 6. Document: `autocode comment <issue-key> "Unit tests passed: X/X tests green"`
15
+ 7. Advance: `autocode next <issue-key>`
19
16
 
20
17
  > Or return: `autocode move <issue-key> <target-column-slug>`
21
18
 
@@ -6,16 +6,13 @@ Relancer les tests unitaires après le travail de développement pour vérifier
6
6
 
7
7
  ## Actions
8
8
 
9
- 1. Récupérer les dernières modifications de la branche de développement
10
- 2. Installer ou mettre à jour les dépendances si les fichiers de package ont changé
11
- 3. Exécuter la suite complète de tests unitaires
12
- 4. Analyser les échecs de tests pour déterminer s'il s'agit de régressions
13
- 5. Si des régressions sont trouvées, identifier les commits ou modifications qui les ont causées
14
- 6. Documenter les résultats des tests incluant le nombre de succès/échecs et les métriques de couverture
15
- 7. Vérifier que la couverture de tests n'a pas diminué par rapport à la référence
16
- 8. Si du travail hors périmètre est détecté : `autocode new "<titre>" "<description>" --priority P2 --labels "<labels>" --acceptance "<critères>" --semver patch --column backlog`
17
- 9. Documenter : `autocode comment <issue-key> "[résumé]"`
18
- 10. Avancer : `autocode next <issue-key>`
9
+ 1. Exécuter la suite complète de tests unitaires : `npm test`
10
+ 2. Analyser les échecs de tests pour déterminer s'il s'agit de régressions
11
+ 3. Si des régressions sont trouvées, identifier les modifications qui les ont causées
12
+ 4. Si des tests échouent : retourner en dev pour correction
13
+ 5. Vérifier que la couverture de tests n'a pas diminué
14
+ 6. Documenter : `autocode comment <issue-key> "Tests unitaires passés : X/X tests verts"`
15
+ 7. Avancer : `autocode next <issue-key>`
19
16
 
20
17
  > Ou retourner : `autocode move <issue-key> <target-column-slug>`
21
18