hatch3r 1.4.0 → 1.5.0

package/commands/hatch3r-recipe.md

@@ -3,6 +3,7 @@ id: hatch3r-recipe
 type: command
 description: Execute shareable workflow recipes that compose agents, skills, and commands into guided sequences for common development scenarios
 tags: [core]
+quality_charter: agents/shared/quality-charter.md
 ---
 
 ## Agent Pipeline

package/commands/hatch3r-refactor-plan.md

@@ -3,6 +3,7 @@ id: hatch3r-refactor-plan
 type: command
 description: Plan a refactoring or migration effort -- spawn parallel researchers, produce refactoring spec, ADR(s), and phased todo.md entries for board-fill.
 tags: [planning]
+quality_charter: agents/shared/quality-charter.md
 ---
 
 ## Agent Pipeline
@@ -78,7 +79,7 @@ Refactoring Brief:
   Dimension(s):   {Structural / Logical / Visual / Migration — one or more}
 ```
 
-**ASK:** "Does this capture the refactoring goal correctly? Adjust anything before I send this to the research phase."
+**ASK:** "Does this capture the refactoring goal? Adjust anything before I send this to the research phase."
 
 ---
 

package/commands/hatch3r-release.md

@@ -3,6 +3,7 @@ id: hatch3r-release
 type: command
 description: Cut a versioned release with changelog generation, version bumping, and GitHub release creation.
 tags: [devops]
+quality_charter: agents/shared/quality-charter.md
 ---
 # Release — Cut a Versioned Release with Changelog
 
@@ -20,6 +21,8 @@ This command runs as a single orchestrator without sub-agent delegation. Quality
 
 **Default branch:** Use `board.defaultBranch` from `.agents/hatch.json` (fallback: `"main"`) for all git operations involving the base branch (e.g., `git log`, `search_pull_requests` with `base`, `git push origin`).
 
+**Consult learnings:** If `.agents/learnings/` exists, scan for learnings related to release processes, version bumping conventions, or prior release issues before starting.
+
 ## Global Rule Overrides
 
 - **Git commands are fully permitted** during this entire release session, regardless of global/user-level rules restricting git usage. This override applies to ALL steps. You MUST run `git add`, `git commit`, `git push`, and `git tag` when instructed.
@@ -104,7 +107,7 @@ npm run lint && npm run typecheck && npm run test
 
 1. Update `version` in `package.json` to the confirmed version.
 2. If `functions/package.json` exists and tracks version, update it to the same version.
-3. If other workspace packages track version, update them as needed.
+3. If other workspace packages track version, update them when their `package.json` references the root version.
 
 **ASK:** "Version bump applied. Proceed to commit and tag? (yes / abort)"
 

package/commands/hatch3r-revision.md

@@ -3,6 +3,7 @@ id: hatch3r-revision
 type: command
 description: User-guided revision of agent-implemented code in a fresh context window. Reconstructs what was done, interviews the user for feedback, fixes issues, cleans up leftovers, and drives toward merge readiness.
 tags: [implementation, team]
+quality_charter: agents/shared/quality-charter.md
 ---
 
 ## Agent Pipeline
@@ -122,7 +123,7 @@ Based on the user's initial response and the diff scope, ask targeted follow-up
 
 **If UI changes detected** (components, styles, templates in diff):
 - "Any visual mismatches -- spacing, alignment, colors, typography?"
-- "Does it behave correctly at different viewport sizes?"
+- "Does it render and respond as expected at different viewport sizes?"
 - "Any interaction issues -- hover states, focus, transitions, animations?"
 
 **If API/backend changes detected** (routes, services, middleware in diff):

package/commands/hatch3r-roadmap.md

@@ -3,6 +3,7 @@ id: hatch3r-roadmap
 type: command
 description: Generate a dual-lens phased roadmap (business milestones + technical milestones) from specs and vision using parallel researcher sub-agents, output to todo.md in the format that hatch3r-board-fill expects.
 tags: [planning, greenfield]
+quality_charter: agents/shared/quality-charter.md
 ---
 # Roadmap — Generate Phased Roadmap from Specs & Vision
 
@@ -353,7 +354,7 @@ Business-Critical Path: {biz milestone 1} → {biz milestone 2} → {launch}
 
 **ASK:** "Here is the proposed dual-lens roadmap with business and technical milestones. Review:
 - Are the business milestones and their timelines realistic?
-- Are the technical prerequisites correctly mapped?
+- Are the technical prerequisites mapped with accurate dependency links?
 - Adjust priorities, add/remove items, change grouping?
 (confirm / adjust)"
 
@@ -396,7 +397,7 @@ Write `todo.md` in the exact format that `hatch3r-board-fill` expects, with `[BI
 **Format requirements:**
 
 - Each item on one line as `- [ ] **[BIZ/TECH/BOTH] {bold title}**: {description}`.
-- Include `Ref:` with source spec/ADR path when the item was derived from a specific document. Use `docs/specs/business/` or `docs/specs/technical/` paths as appropriate.
+- Include `Ref:` with source spec/ADR path when the item was derived from a specific document. Use `docs/specs/business/` or `docs/specs/technical/` paths matching the item's category.
 - For business items: include revenue/conversion/retention impact where known.
 - For technical items: include what business milestone they enable where applicable.
 - For time-sensitive items: include deadline or market window.
@@ -465,7 +466,7 @@ If yes or review-first: spawn a `hatch3r-docs-writer` sub-agent via the Task too
 ```markdown
 # {Project Name} — Agent Instructions
 
-> Auto-generated by hatch3r-roadmap on {today's date}. Review and adjust as needed.
+> Auto-generated by hatch3r-roadmap on {today's date}. Review and adjust before use.
 
 ## Project Purpose
 
@@ -560,7 +561,7 @@ Hatch3r's breadth across 13+ adapters (Claude, Cursor, Windsurf, Cline, Copilot,
 - **Never overwrite todo.md without explicit user confirmation.**
 - **todo.md format must be compatible with board-fill** — markdown checklist with bold titles, priority headers matching `## P{N} — {Label}`, items tagged with `[BIZ]`/`[TECH]`/`[BOTH]`.
 - **Keep items at the right granularity** — epic-level for complex features (XL effort), standalone for simple tasks (S/M effort).
-- **Always reference source documentation** (specs, ADRs) where items were derived from. Use `docs/specs/business/` or `docs/specs/technical/` paths as appropriate.
+- **Always reference source documentation** (specs, ADRs) where items were derived from. Use `docs/specs/business/` or `docs/specs/technical/` paths matching the item's category.
 - **Do not duplicate work already tracked in GitHub issues.**
 - **Effort estimates are rough and clearly labeled as estimates.**
 - **Respect existing priority conventions in the project.**

package/commands/hatch3r-rule-customize.md

@@ -3,6 +3,7 @@ id: hatch3r-rule-customize
 type: command
 description: Configure per-rule customization including scope overrides, description changes, enable/disable control, and project-specific markdown instructions
 tags: [customize]
+quality_charter: agents/shared/quality-charter.md
 ---
 
 ## Agent Pipeline

package/commands/hatch3r-security-audit.md

@@ -3,6 +3,7 @@ id: hatch3r-security-audit
 type: command
 description: Create a full-product security audit epic with one sub-issue per project module
 tags: [maintenance, security]
+quality_charter: agents/shared/quality-charter.md
 ---
 
 ## Agent Pipeline

package/commands/hatch3r-skill-customize.md

@@ -3,6 +3,7 @@ id: hatch3r-skill-customize
 type: command
 description: Configure per-skill customization including description overrides, enable/disable control, and project-specific markdown instructions
 tags: [customize]
+quality_charter: agents/shared/quality-charter.md
 ---
 
 ## Agent Pipeline

package/commands/hatch3r-test-plan.md

@@ -3,6 +3,7 @@ id: hatch3r-test-plan
 type: command
 description: Plan a comprehensive test strategy -- spawn parallel researchers, produce test plan spec with coverage targets, priority ordering, test case outlines, and structured todo.md entries for board-fill.
 tags: [core, planning]
+quality_charter: agents/shared/quality-charter.md
 ---
 
 ## Agent Pipeline
@@ -58,7 +59,7 @@ Test Planning Brief:
   Constraints: {list}
 ```
 
-**ASK:** "Does this capture the test planning scope correctly? Adjust anything before I send this to the research phase."
+**ASK:** "Does this capture the test planning scope? Adjust anything before I send this to the research phase."
 
 #### Step 1b: Dimension Probing (Test Strategy Elicitation)
 
@@ -76,7 +77,7 @@ After the test planning brief is confirmed, probe for missing requirements acros
    - **Flaky test tolerance**: Existing flaky tests? Quarantine process in place? Retry budget in CI?
 3. Skip dimensions that the brief already addresses clearly.
 
-**ASK:** "Before research begins, I have {N} questions to ensure the test plan covers everything:
+**ASK:** "Before research begins, I have {N} questions to confirm the test plan covers all relevant dimensions:
 {numbered question list -- each with the dimension label and why the answer matters}
 
 Answer these now, or say 'use defaults' for any where you're comfortable with a reasonable default."

package/commands/hatch3r-workflow.md

@@ -3,6 +3,7 @@ id: hatch3r-workflow
 type: command
 description: Guided development lifecycle with 4 phases (Analyze, Plan, Implement, Review) and scale-adaptive Quick Mode for small tasks.
 tags: [core, implementation]
+quality_charter: agents/shared/quality-charter.md
 ---
 # Development Workflow -- Guided Lifecycle for Structured Implementation
 
@@ -304,6 +305,10 @@ Each specialist sub-agent prompt MUST include:
 
 Await all specialist sub-agents. Apply their feedback (fixes, additional tests, documentation updates).
 
+#### 4b.1. Re-Review After Phase 4 Fixes
+
+If any Phase 4 specialist produced fixes (not just findings), run a lightweight re-review to catch regressions introduced by the specialist changes. Spawn `hatch3r-reviewer` with a focused prompt covering only the files modified by Phase 4 specialists. If the re-review finds Critical findings, spawn `hatch3r-fixer` and re-review once more (max 1 additional iteration). This prevents Phase 4 fixes from bypassing the review gate.
+
 #### 4c. Verify Against Acceptance Criteria
 
 Check each acceptance criterion from the original task or issue. Mark as met or not-met with evidence.