@hanzlaa/rcode 3.4.5 → 3.4.7

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": "@hanzlaa/rcode",
3
- "version": "3.4.5",
3
+ "version": "3.4.7",
4
4
  "description": "rcode — the memory bank for AI-driven SaaS teams. Persistent project context, distinctive engineering personas, and phase-based workflows. Built by Rihal. Works in Claude Code, Cursor, Gemini, VS Code, and Antigravity.",
5
5
  "main": "cli/index.js",
6
6
  "bin": {
@@ -6,6 +6,26 @@ After completing a task's implementation, follow this protocol to atomically com
6
6
 
7
7
  ---
8
8
 
9
+ ## Step 0: Detect Project Commit Standard (Run Once Per Sprint)
10
+
11
+ Before writing any commit messages, read the project's commit standard from source — do NOT invent one or ask the user unless nothing is found.
12
+
13
+ **Check in this order (stop at first hit):**
14
+
15
+ 1. `.github/COMMIT_CONVENTION.md` — explicit commit format doc
16
+ 2. `CONTRIBUTING.md` — look for a "Commit" or "Git" section
17
+ 3. `.commitlintrc`, `.commitlintrc.json`, `.commitlintrc.yaml`, `commitlint.config.js`, `commitlint.config.cjs` — commitlint config
18
+ 4. `package.json` → `"commitlint"` key
19
+ 5. `.github/pull_request_template.md` — PR template reveals expected format (e.g., ticket prefix, changelog format)
20
+
21
+ **If a standard is found:** Use it silently for all commits in this sprint. No need to confirm with user.
22
+
23
+ **If nothing is found:** Default to Conventional Commits (`type(scope): subject`). Mention the format once in your sprint opening summary — do not ask the user to choose.
24
+
25
+ **Never ask the user "what commit format do you want?"** — that's noise. Read first, decide, proceed.
26
+
27
+ ---
28
+
9
29
  ## Step 1: Check Git Status
10
30
  ```bash
11
31
  git status --short
@@ -62,14 +82,16 @@ Match the change to a conventional commit type:
62
82
 
63
83
  ## Step 4: Choose Scope
64
84
 
65
- Scope is the area affected, in parentheses:
85
+ Scope is the **subsystem or domain** affected, in parentheses — NOT the phase/sprint number.
66
86
 
67
87
  - `feat(auth)` - authentication feature
68
88
  - `fix(payments)` - payments bug fix
69
89
  - `test(api)` - API tests
70
90
  - `refactor(ui)` - UI code cleanup
71
91
 
72
- Scope should match the PLAN task name or subsystem.
92
+ **NEVER use a phase or sprint number as the scope.** `fix(114):` or `feat(114-03):` are wrong.
93
+ Use the name of the subsystem the task touches (e.g., `sequence-builder`, `auth`, `dashboard`, `api`).
94
+ If no obvious subsystem exists, omit the scope: `fix: correct delay type in email templates`.
73
95
 
74
96
  ---
75
97
 
@@ -210,6 +232,8 @@ Bad:
210
232
  feat(auth): Adds JWT refresh tokens.
211
233
  fix: I fixed the payment thing
212
234
  Updated auth code
235
+ fix(114): correct delay type ← phase number as scope — WRONG
236
+ feat(114-03): add drag-and-drop ← sprint ID as scope — WRONG
213
237
  ```
214
238
 
215
239
  ---