@haposoft/cafekit 0.7.20 → 0.7.22

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@haposoft/cafekit",
-  "version": "0.7.20",
+  "version": "0.7.22",
   "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>
@@ -29,7 +30,7 @@ DO NOT write implementation code until an approved spec exists.
 | "No need to scout first" | Coding without knowing the architecture is blind. ALWAYS call `inspect` to scan files. |
 | "Review process is too tedious, let me just finish it myself" | The system needs an audit trail through agents. ALWAYS delegate via `Task` tool. |
 
-## Absolute 4-Step Workflow
+## Absolute Workflow
 
 ```mermaid
 flowchart TD
@@ -39,21 +40,26 @@ flowchart TD
     C --> D[Step 3: Implement Code (god-developer)]
     D --> E[Step 4: Auto-Fix Code Review / Max 3 rounds]
     E -->|Fail (code-auditor)| D
-    E -->|Pass| F[Report Completion]
+    E -->|Pass| F[Step 5: Incremental Docs Sync]
+    F --> G[Report Completion]
 ```
 
 ### 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.
@@ -61,6 +67,11 @@ The moment you finish coding, DO NOT proceed further. Switch to `references/qual
 
 - Only escalate to the user after 3 consecutive failed review rounds.
 
+### Step 5: Incremental Docs Sync
+- After passing the Quality Gate, evaluate if any actual codebase modifications occurred (e.g., check pending files via git status).
+- If files were created or modified: Trigger `docs-keeper` automatically to execute `repomix` and update the global `/docs/` and project logs.
+- Do NOT skip this step! The user explicitly requires documentation to be synced immediately after every `/hapo:develop` action, overriding the default Phase 3-only rule.
+
 ---
 ## Attached References
 - `references/quality-gate.md` - Rules for the Code Review loop.

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

@@ -85,7 +85,17 @@ System auto-analyzes the description:
 ### 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`, adopt Red Team personas, and read the entire `specs/` directory to hunt for flaws before interviewing the user.
+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
 
@@ -269,6 +279,8 @@ Load: `references/review.md` + `rules/design-review.md`
   - **>= 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:

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.