alignfirst 0.6.0-preview.0 → 0.6.0-preview.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "alignfirst",
-  "version": "0.6.0-preview.0",
+  "version": "0.6.0-preview.1",
   "license": "CC0-1.0",
   "author": "Thomas MUR",
   "description": "The AlignFirst CLI: protocols, work files and docs in one command.",

package/templates/guide/code-review/intent-reviewer.md

@@ -8,7 +8,7 @@ Evaluate the change as a whole: what it tries to accomplish, and whether the imp
    - Is there a simpler design that achieves the same intent?
    - Does the change fit the architecture and conventions of the codebase, or work against them?
    - Does it leave the codebase healthier than before?
-   - Is the size proportionate to the intent? Layers, options, and generality nobody asked for cost as much as missing pieces.
+   - Is the size proportionate to the intent? A diff that adds more lines than it removes owes a reason; layers, options, and generality nobody asked for cost as much as missing pieces.
    - Does the diff mix a refactor with a behavior change? If they cannot be told apart, say so — it is what makes a review reliable or not.
 4. Report portions of code that deserve a **rewrite** as findings: 🟡, or 🔴 when the flaw defeats the intent. Observations about the change as a whole belong in the assessment, not in the findings list.
 

package/templates/guide/code-review/quality-reviewer.md

@@ -16,6 +16,8 @@ Also check consistency by example: does the new code match its neighbors in stru
 | Abstraction introduced with a single implementation | Does it solve a present problem, or an anticipated one? | 🟡 |
 | Boolean parameter added to an existing function | Does the function now do two things? | 🟡 |
 | New file | Is it in the right place per the repo's conventions? | 🟡 |
+| Defect fixed by adding code | Is the line that caused it still there? Removing the cause is often a proper fix. | 🟡 |
+| Check or branch for a case already ruled out by a type, a caller or an earlier check | What guarantees it? A guard for an impossible case hides the real contract. | 🟡 |
 
 ## DRY and YAGNI
 

package/templates/guide/protocols/aad.md

@@ -22,7 +22,7 @@ Nothing is implemented, and nothing is written in TICKET_DIR, before the user ag
 
 The user is a developer who carries the global vision of the project and decides the choices that matter. You carry the details of the code you just read. The discussion keeps the user aware of what you found and hands them every decision worth taking.
 
-Manage the reader's attention. Open with the task as you understand it and the approach you propose, in two or three sentences. Then write one block per point that deserves a decision. Write for a reader who has not opened the code today: a function, module or mechanism gets a few words of definition the first time you name it.
+Manage the reader's attention. Open with the task as you understand it and the approach you propose, in two or three sentences. Then write one block per independent decision that needs the user. Write for a reader who has not opened the code today: a function, module or mechanism gets a few words of definition the first time you name it.
 
 A block is a question and a recommendation:
 
@@ -34,9 +34,11 @@ A block is a question and a recommendation:
 
 Look for edge cases and impacts on the rest of the system; each one that needs a decision gets its block.
 
-A ❓ is open: the user's answer shapes what you build. When the only answers are go or veto, the block shrinks to a single ➡️ line stating your choice. The more obvious the choice, the shorter the line. Leave out the investigation narrative and the list of files you read.
+Every decision for the user is a numbered question, a yes/no one included; the simpler it is, the shorter its block. Numbering continues across rounds.
 
-Settle on your own what the code can answer. Ask the user what needs their judgement: product behavior, scope, priorities, constraints the code does not show. Every ❓ carries a ➡️, so that "fine with all recommendations" is a valid answer. Ask in rounds: a question whose answer depends on another question still open waits for the next round.
+Settle on your own what the code can answer; routine choices belong in the opening approach. Ask the user what needs their judgement: product behavior, scope, priorities, constraints the code does not show. Leave out the investigation narrative and the list of files you read.
+
+Ask in rounds: a question whose answer depends on another question still open waits for the next round. A question the reply skips stays open.
 
 When there is nothing to decide, say so in a few lines and ask for an explicit go.
 

package/templates/guide/protocols/spec.md

@@ -28,7 +28,7 @@ Nothing is written in TICKET_DIR before the user agrees.
 
 The user is a developer who carries the global vision of the project and decides the choices that matter. You carry the details of the code you just read. The discussion keeps the user aware of what you found and hands them every decision worth taking.
 
-Manage the reader's attention. Open with the task as you understand it and the approach you propose, in two or three sentences. Then write one block per point that deserves a decision. Write for a reader who has not opened the code today: a function, module or mechanism gets a few words of definition the first time you name it.
+Manage the reader's attention. Open with the task as you understand it and the approach you propose, in two or three sentences. Then write one block per independent decision that needs the user. Write for a reader who has not opened the code today: a function, module or mechanism gets a few words of definition the first time you name it.
 
 A block is a question and a recommendation:
 
@@ -40,9 +40,11 @@ A block is a question and a recommendation:
 
 Look for edge cases and impacts on the rest of the system; each one that needs a decision gets its block.
 
-A ❓ is open: the user's answer shapes what you build. When the only answers are go or veto, the block shrinks to a single ➡️ line stating your choice. The more obvious the choice, the shorter the line. Leave out the investigation narrative and the list of files you read.
+Every decision for the user is a numbered question, a yes/no one included; the simpler it is, the shorter its block. Numbering continues across rounds.
 
-Settle on your own what the code can answer. Ask the user what needs their judgement: product behavior, scope, priorities, constraints the code does not show. Every ❓ carries a ➡️, so that "fine with all recommendations" is a valid answer. Ask in rounds: a question whose answer depends on another question still open waits for the next round.
+Settle on your own what the code can answer; routine choices belong in the opening approach. Ask the user what needs their judgement: product behavior, scope, priorities, constraints the code does not show. Leave out the investigation narrative and the list of files you read.
+
+Ask in rounds: a question whose answer depends on another question still open waits for the next round. A question the reply skips stays open.
 
 When several approaches are viable, present them with their trade-offs. Check that every sub-subject of the task has its block; a sub-subject skipped here is missing from the spec.