@akinet/akidevrule 3.1.0 → 3.1.1

package/CHANGELOG.md

@@ -1,5 +1,10 @@
 # Changelog
 
+## [3.1.1] - 2026-09-15
+
+### Fixed
+- **`coding.B3` bans moving uncommitted work to attribute a failing check.** Evidence: during the 3.1.0 site sync a worker hit a typecheck failure and ran `git stash` on a site repo to re-check a clean HEAD, sweeping 17 of the owner's uncommitted files out of the tree; they were restored with `git stash pop`, nothing lost. Root cause: 3.1.0 made build/test self-authorized at ship time but said nothing about how a failure is attributed, and `agent.B5`'s git-mutation ban covers audits only. Mechanism: attribution reads the error against the changed files or rebuilds the committed tree in a separate `git worktree`; `stash`/`checkout -- <path>`/`restore`/`reset`/`clean` are never used for it. Rejected: widening `agent.B5` to all work, which would also forbid legitimate owner-ordered resets; the risk lives exactly where a check fails, so the ban sits in `coding.B3`.
+
 ## [3.1.0] - 2026-09-15
 
 ### Changed

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@akinet/akidevrule",
-  "version": "3.1.0",
+  "version": "3.1.1",
   "description": "Aki's shared rule corpus + Agent Skills for Claude Code, Gemini/Antigravity, Codex, Kiro and Grok — install and update with one command.",
   "keywords": [
     "claude-code",

package/payload/RULE-coding.md

@@ -39,6 +39,7 @@ A principle with the procedure that guarantees it — apply to any edit of code
 ### B3. Verification
 - Done means verified — never claim success from intention alone.
 - Verify by the **narrowest tool that actually settles the doubt**: static reading and type/lint/unit checks first. Never spin up a full build or dev server just to catch a typo a typecheck would catch.
+- **Never move uncommitted work to attribute a failing check.** No `git stash`/`checkout -- <path>`/`restore`/`reset`/`clean` to learn whether a typecheck or build error pre-exists: read the error against the changed files, or rebuild the committed tree in a separate `git worktree`. The working tree may hold the owner's unfinished work, and a known pre-existing failure yields no information worth risking it.
 - **Static reading IS verification** when the property is fully determined by visible code flow — state what was read as the evidence and close the checklist item on that evidence. Escalate a tier (typecheck → unit → runtime) only when you can name the specific doubt that tier settles.
 - **Never gate a done-transition on human manual testing for a check that static reading or an automated tier settles.** A plan's verify checklist stays fully detailed — the violation is not the checklist, it is parking finished work as "waiting for manual test" on items whose truth the code flow already proves. Hand the human only what genuinely needs human runtime judgment: UX feel, visual rendering, live external integration.
 - **Running the app is not a default verification step — but not running it does not let you claim "Done".** Starting a dev server or making live network calls stays **user-triggered**, not self-authorized (cost and side effects are the user's call). A full build and the test suite are **not** in that category — they are self-authorized, gated by the moment instead: **after edits** → typecheck/lint/related unit tests, never a full build per edit; **committing a large batch** (spans several modules, or touches build config/dependencies) → add the build; **ship/release/deploy** → full build plus full test suite is mandatory and self-authorized, commands derived per `release.B7` step 6. When a change's real risk lives **only at runtime** — hydration, layout/z-index, route/auth flow, a dynamically-built class a build step may purge — and you cannot settle it statically, you may **not** report "Done": halt and report the state as **"unverified — needs a runtime check"**, propose the exact command, and hand it to the user (see [[RULE-agent-behavior]] A3). "Done" for logic you only compiled is not done.