@haposoft/cafekit 0.7.18 → 0.7.21

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@haposoft/cafekit",
-  "version": "0.7.18",
+  "version": "0.7.21",
   "description": "Spec-Driven Development workflow for AI coding assistants. Supports Claude Code and Antigravity with spec-first workflows plus Claude Code hapo: skills.",
   "author": "Haposoft <nghialt@haposoft.com>",
   "license": "MIT",

package/src/claude/skills/develop/SKILL.md

@@ -15,6 +15,7 @@ Reads the full project specification (`hapo:specs`) and relentlessly implements
 ```bash
 /hapo:develop <feature name>
 /hapo:develop specs/<feature-name>
+/hapo:develop <feature name> <specific-task-file.md>
 ```
 
 <HARD-GATE>
@@ -43,17 +44,21 @@ flowchart TD
 ```
 
 ### Step 1: Initialize & Load Spec
-- Identify input. Open `specs/<feature-name>/spec.json`.
+- Identify input: Open `specs/<feature-name>/spec.json`.
 - Check `ready_for_implementation` status. If not ready, notify user.
-- List all Markdown files in `specs/<feature-name>/tasks/*.md`. Load them into working memory as the execution guide.
+- **Task Scoping (CRITICAL):**
+  - If the user specifies a particular task file (e.g., `task-R0-02...md`), load **ONLY** that specific file into working memory.
+  - If no specific task is mentioned, list and load all Markdown files in `specs/<feature-name>/tasks/*.md`.
 
 ### Step 2: Scout (Codebase Inspection)
 - **Mandatory:** Call agent `Task(subagent_type="inspect", ...)` to scan the overall codebase structure (e.g., where components live, where utils are). Avoid wandering into forbidden zones.
 
 ### Step 3: Implement Code
-- Act as `god-developer` OR directly write code, executing tasks specified in the Markdown files sequentially.
+- Act as `god-developer` OR directly write code, executing tasks specified in the loaded Markdown file(s) sequentially.
 - **Important:** You may create and modify files directly, but must faithfully follow the design from the Spec.
 - Progress tracking: Temporarily change `[ ]` to `[/]` in Spec files while coding is in progress.
+- **Hard Stop Protocol:** If you were asked to implement a specific task file, you MUST STOP completely after that task is verified. DO NOT auto-chain or jump to "Next Task" simply because you see it in the spec. Wait for the user's next command.
+- **Test Integrity Protocol:** You MUST NOT delete, replace, or reduce the scope of existing test cases to make tests pass. If a test fails, you must fix the **implementation code** or fix the **test setup/mock**, NOT remove the assertion. Reducing test count or weakening assertions (e.g., removing `toHaveBeenCalledWith` and replacing with `toEqual(expect.any(...))`) is a Critical violation.
 
 ### Step 4: Self-Healing (Quality Gate Auto-Fix)
 The moment you finish coding, DO NOT proceed further. Switch to `references/quality-gate.md` and run the automatic review loop.

package/src/claude/skills/specs/SKILL.md

@@ -2,7 +2,7 @@
 name: hapo:specs
 description: "Structured specification workflow — from vague idea to actionable task list. Includes init, requirements, design, task breakdown, review, and archiving."
 version: 2.0.0
-argument-hint: "<feature-description> | status | resume | review | archive"
+argument-hint: "<feature-description> | status | resume | --validate | archive"
 ---
 
 # Specs (SDD — Specification-Driven Development)
@@ -67,7 +67,7 @@ Display selection menu via `AskUserQuestion`:
       { "label": "Create new spec", "description": "Initialize spec from a feature description" },
       { "label": "status", "description": "View status of all specs in specs/" },
       { "label": "resume", "description": "Continue an in-progress spec" },
-      { "label": "review", "description": "Review spec (auto-decides: red team or validation)" },
+      { "label": "--validate", "description": "Review spec (auto-decides: red team or validation)" },
       { "label": "archive", "description": "Archive completed specs + write journal" }
     ],
     "multiSelect": false
@@ -82,12 +82,27 @@ System auto-analyzes the description:
 - If task is simple (small bugfix, config change) → suggest "A spec may not be needed for this. Continue anyway?"
 - If task is complex (multi-module, security/migration related) → auto-activate deep research, ask user 3 scope questions
 
+### When called WITH `--validate` argument
+
+System IMMEDIATELY jumps to **Step 9: Validation Review**.
+The system MUST NOT execute Steps 1-8. Instead, load `references/review.md` and follow it **step-by-step**.
+
+#### `--validate` Guardrails (NON-NEGOTIABLE)
+
+1. **Red Team cannot be skipped by the system.** If auto-decision says "Red Team + Validate", you MUST run Red Team. A previous `code-auditor` review does NOT count — code-auditor reviews source code, NOT specifications. Only the USER can downgrade to "Validate only" by explicitly saying so.
+2. **MUST use the 4 Personas** defined in `review.md` Part A Step 3 (Security Adversary, Failure Mode Analyst, Assumption Destroyer, Scope & Complexity Critic). Generic observations without persona attribution are REJECTED.
+3. **MUST use the Finding Format** defined in `review.md` Part A (Severity, Location, Flaw, Failure scenario, Evidence, Suggested fix, Disposition, Rationale). Shortened or custom formats are REJECTED.
+4. **MUST create `reports/red-team-report.md`** when Red Team runs (review.md Part A Step 8).
+5. **MUST NOT create implementation code files** (`.ts`, `.js`, `.py`, etc.). The validate workflow produces ONLY markdown spec documents and reports. If a fix requires a new shared module, describe it in the relevant task file instead of creating the actual code file.
+6. **MUST NOT over-engineer fixes.** Apply YAGNI — if user says "configure later", add an abstraction note to the task, do NOT generate 4 concrete provider implementations.
+7. **MUST follow auto-decision table exactly.** Count task files + scan for keywords → pick mode. No self-justification to override the table result.
+
 ## Workflow Diagram
 
 ```mermaid
 flowchart TD
     A["Call /hapo:specs"] --> B{Has description?}
-    B -->|No| C["Menu: init / status / resume / review / archive"]
+    B -->|No| C["Menu: init / status / resume / --validate / archive"]
     B -->|Yes| D["Step 1: Analyze description"]
     D --> E{Clear enough?}
     E -->|No| F["Ask user 1-2 clarifying questions"]
@@ -257,13 +272,15 @@ Load: `references/task-hydration.md`
 - If TaskCreate tool unavailable → fallback to `TodoWrite`
 - Task files are the single source of truth — hydration is just a convenience
 
-### Step 9: Review (Optional)
+### Step 9: Validation Review (Optional)
 Load: `references/review.md` + `rules/design-review.md`
 - System auto-evaluates spec complexity and decides review depth:
   - **< 3 task files, no security concerns** → Validate only (lightweight interview)
   - **>= 5 task files OR security/migration keywords** → Red Team first, then Validate
   - **User explicit request** → respect user's intent
 - When both run: Red Team ALWAYS before Validate (red team may change the spec)
+- **PROHIBITION:** The system MUST NOT skip Red Team because of a prior code-auditor review. Code review ≠ Spec review.
+- **PROHIBITION:** The system MUST NOT create `.ts`, `.js`, `.py` or any implementation files during validation. Spec-only outputs.
 
 ### Step 10: Completion — Context Reminder (MANDATORY)
 After completing the spec, output a short summary of what was generated, then you MUST output the following block EXACTLY as written. DO NOT use awkward translations like "Điểm đã phản ánh đúng quyết định của bạn", keep it professional or just output the block directly:
@@ -342,7 +359,7 @@ specs/
 |---|---|---|
 | `/hapo:specs status` | View status of all specs | — |
 | `/hapo:specs resume <feature>` | Continue an in-progress spec | — |
-| `/hapo:specs review <feature>` | Review spec (auto: red team + validate based on complexity) | `references/review.md` |
+| `/hapo:specs --validate <feature>` | Validate spec (auto: red team + validate based on complexity) | `references/review.md` |
 | `/hapo:specs archive` | Archive completed specs + write journal | `references/archive-workflow.md` |
 
 ## Quality Standards

package/src/claude/skills/specs/references/review.md

@@ -28,6 +28,19 @@ The system evaluates the spec and picks the appropriate review mode:
 1. Red Team may change the spec (added risks, removed sections)
 2. Validate should confirm the FINAL spec, not a pre-review draft
 
+## Guardrails (NON-NEGOTIABLE)
+
+These rules override any self-reasoning or optimization the system may attempt:
+
+1. **No self-override of auto-decision.** If the table above says "Red Team → then Validate", you MUST run Red Team. You CANNOT skip it because:
+   - A `code-auditor` previously reviewed the spec (code review ≠ spec review)
+   - The spec "looks good" to you
+   - You want to "save time"
+   - Only the USER can downgrade the mode by explicitly saying "just validate" or "skip red team"
+2. **No implementation code files.** This workflow produces ONLY `.md` files. If a finding requires a new shared module or config file, describe it inside the relevant `task-*.md` file. Do NOT create `.ts`, `.js`, `.py`, or any source code file.
+3. **Findings must use the exact format** defined in Part A Step 5 below. No shortened or custom formats.
+4. **Apply YAGNI to fixes.** When user says "configure later" or "decide later", add a single note to the task file. Do NOT generate multiple concrete implementations (e.g., 4 provider files when user only asked for abstraction).
+
 ---
 
 ## Part A: Red Team Review (Adversarial)

package/src/claude/skills/test/SKILL.md

@@ -109,9 +109,13 @@ Return a **structured verdict** (required format — not free-form prose):
 - Accessibility issues: N found | none
 - Screenshots: [paths]
 
+### Test Regression Check
+- **Comparison:** Compare current test count and assertion depth against previous runs.
+- **Result:** OK | REGRESSION (tests deleted/weakened)
+
 ### Action
 - PASS → Proceed. Hand off to hapo:code-review.
-- FAIL → [list specific fixes needed] → Return to god-developer.
+- FAIL → [list specific fixes needed] → Return to god-developer. (If REGRESSION: label "Test Regression — tests were deleted or weakened to produce green result")
 - PARTIAL → [list uncovered areas] → Consider adding tests.
 - NO_TESTS → No test runner detected. User must configure tests first.