@haposoft/cafekit 0.14.0 → 0.14.2

package/src/claude/skills/specs/rules/tasks-generation.md

@@ -157,7 +157,7 @@ Every task file MUST contain the Risk Assessment table, even if no risks are ide
 
 ### Mandatory Evidence Section
 
-Every new task file MUST include a `## Evidence` section. Existing specs may still use the v0.8 heading `## Task Test Plan & Verification Evidence` or the legacy `## Verification & Evidence` heading; readers and sync tools must support all three.
+Every new task file MUST include a `## Evidence` section (`## Evidence` (legacy heading aliases still parse)).
 
 That section is the task-level test plan and proof checklist. It MUST contain:
 1. **Automated proof** — exact command(s) for typecheck, tests, build, or explicit `N/A`

package/src/claude/skills/specs/templates/task.md

@@ -60,6 +60,8 @@
 This section is both the task-level test plan and the proof checklist. Keep it short, exact, and executable.
 Select the proof by task risk; do not run every test type for every task.
 
+Verification: PENDING
+
 - Logic/data/validator task: include unit tests.
 - Stateful UI/component task: include component or integration tests.
 - Cross-module/API/state flow task: include integration tests.
@@ -94,4 +96,4 @@ Select the proof by task risk; do not run every test type for every task.
 > **Parallel marker**: Append `(P)` to the title if this task can run concurrently with another (usually when serving different requirements).
 > **Test note**: If a test coverage sub-task can be deferred post-MVP, mark it with `- [ ]*`.
 > **Requirement mapping**: Every sub-task MUST end with `_Requirements: X.X_`. No mapping = invalid task file.
-> **Evidence rule**: No `## Evidence` section = invalid task file. Existing specs may use `## Task Test Plan & Verification Evidence` or legacy `## Verification & Evidence`; agents must support all three headings.
+> **Evidence rule**: No `## Evidence` section = invalid task file. Use `## Evidence` (legacy heading aliases still parse).

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

@@ -39,8 +39,8 @@ Scans the `spec.json` against all physical `task-R*.md` files to detect mismatch
 
 1. **Precision Edits:** Never overwrite the entire `spec.json` string blindly. Update only the required keys, while keeping JSON valid.
 2. **Machine + Human Sync:** Every task status update MUST modify both `spec.json.task_registry[...]` and the matching markdown task file header/status section.
-3. **Markdown Integrity:** When marking a task `done`, only then turn `[ ]` into `[x]` inside `## Steps` / `## Implementation Steps` and relevant `Completion Criteria` / `Evidence` checkboxes that have actual proof. `Task Test Plan & Verification Evidence` and legacy `Verification & Evidence` sections are supported.
-4. **Verification Receipt Rule:** `done` is illegal without a human-readable verification receipt already present in `## Evidence`, `## Task Test Plan & Verification Evidence`, or legacy `## Verification & Evidence` (commands executed, artifact/runtime proof, or equivalent concrete evidence). If proof is missing, keep the task `in_progress` or `blocked`.
+3. **Markdown Integrity:** When marking a task `done`, only then turn `[ ]` into `[x]` inside `## Steps` / `## Implementation Steps` and relevant `Completion Criteria` / `Evidence` checkboxes that have actual proof. Use `## Evidence` (legacy heading aliases still parse).
+4. **Verification Receipt Rule:** `done` is illegal without a human-readable verification receipt already present in `## Evidence` (legacy heading aliases still parse) (commands executed, artifact/runtime proof, or equivalent concrete evidence). If proof is missing, keep the task `in_progress` or `blocked`.
 5. **Task Docs Hook:** Every time `hapo:sync` marks a task as `done`, it must flag that a task-level docs checkpoint is now due for that verified task.
 6. **Phase Prompt Rule:** When `hapo:sync` marks the final pending task in the whole feature as `done`, it should automatically prompt the user if they'd like to advance the phase, but only after the docs checkpoint for that last completed task has been considered.
 

package/src/claude/skills/sync/references/sync-protocols.md

@@ -15,7 +15,7 @@ When requested to update a phase or change task configuration, `spec.json` must
     - full relative path like `tasks/task-R0-02-extension-shell.md`
 *   **Status Update:** If a task changes to `blocked`, the matching `task_registry[path].status` must become `"blocked"`, `task_registry[path].blocker` must record the reason, and `spec.json.status` / `spec.json.blocker` must reflect the top-level block if work is globally blocked.
 *   **Timestamp Rule:** Update `task_registry[path].started_at`, `completed_at`, and `last_updated_at` consistently with the new state. Also refresh `spec.json.updated_at`.
-*   **Done-State Rule:** Never set `task_registry[path].status = "done"` unless the matching markdown task file already contains a verification receipt in `## Evidence`, `## Task Test Plan & Verification Evidence`, or legacy `## Verification & Evidence`, or the caller explicitly provides proof that can be written there first.
+*   **Done-State Rule:** Never set `task_registry[path].status = "done"` unless the matching markdown task file already contains a verification receipt in `## Evidence` (legacy heading aliases still parse), or the caller explicitly provides proof that can be written there first.
 *   **Receipt Integrity Rule:** A valid verification receipt must include the exact commands run, their outcomes, and artifact/runtime proof. Receipts containing `PRECHECK_FAIL`, `FAIL`, `UNVERIFIED`, or explicit "placeholder / simplified for MVP / production later" contract deviations are not eligible for `done`.
 *   **Contract Fidelity Rule:** If the task file notes or evidence show that a named framework/auth/runtime choice from the spec was silently replaced, sync MUST refuse `done` until the spec is amended or the implementation is corrected.
 *   **Task Docs Rule:** After a task is moved to `done`, emit a short alert that a task-level docs checkpoint is due for this verified task.
@@ -27,12 +27,12 @@ The structure of `tasks/task.md` relies heavily on exact keyword markers. Follow
 ### A. Completing a Task
 When `/hapo:sync <feature> <task-id> done`:
 1. Find: `**Status:** pending` (or `in_progress` / `blocked`).
-2. Inspect `## Evidence` first. If the task uses `## Task Test Plan & Verification Evidence` or legacy `## Verification & Evidence`, inspect that section instead. If it has no explicit proof lines (commands run, artifact proof, runtime proof, or blockers cleared), STOP and refuse to mark the task done.
+2. Inspect `## Evidence` (legacy heading aliases still parse) first. If it has no explicit proof lines (commands run, artifact proof, runtime proof, or blockers cleared), STOP and refuse to mark the task done.
 3. Refuse completion if the receipt contains any non-passing marker such as `PRECHECK_FAIL`, `FAIL`, `UNVERIFIED`, or an explicit note that the implementation substituted a named contract with a placeholder/custom simplification.
 4. Replace with: `**Status:** done`.
 5. Locate block: `## Steps` or `## Implementation Steps`.
 6. Convert `- [ ]` into `- [x]` strictly within that section.
-7. Update relevant checkboxes in `## Completion Criteria` and `## Evidence` only when the caller provides or the file already contains real proof. For v0.8 or legacy task files, update `## Task Test Plan & Verification Evidence` or `## Verification & Evidence` instead.
+7. Update relevant checkboxes in `## Completion Criteria` and `## Evidence` (legacy heading aliases still parse) only when the caller provides or the file already contains real proof.
 8. Surface a note such as: `Docs checkpoint due: task Rn-mm just completed`.
 
 ### B. Blocking a Task
@@ -59,7 +59,7 @@ When `/hapo:sync audit <feature>` is activated:
    - Missing disk file referenced in registry → remove or flag it
    - Markdown says `done` but registry not done → registry wins only if evidence already exists; otherwise downgrade markdown or flag conflict
    - Registry says `done` but markdown still pending → update markdown only if evidence exists
-   - Either side says `done` but `## Evidence` / `## Task Test Plan & Verification Evidence` / legacy `## Verification & Evidence` has no concrete proof → downgrade to `in_progress` or flag conflict instead of preserving fake completion
+   - Either side says `done` but `## Evidence` (legacy heading aliases still parse) has no concrete proof → downgrade to `in_progress` or flag conflict instead of preserving fake completion
    - Either side says `done` but the receipt contains `PRECHECK_FAIL`, `FAIL`, `UNVERIFIED`, or explicit contract-substitution notes → downgrade to `in_progress` or flag conflict
 5. **Correction Alert:** Output a brief markdown alert detailing mismatches fixed and any unresolved conflicts requiring manual review.
 6. **Task Docs Alert:** If audit reveals tasks newly marked `done`, include whether task-level docs sync appears still due or already accounted for in the current run summary.

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

@@ -177,7 +177,7 @@ It merges the JSON data into `.hapo/test-memory.json` per `references/test-memor
 | `hapo:develop` | orchestrates | Spawns hapo:test at Step 4 |
 | `inspector` agent | hapo:test → | Scout test file locations when structure is unfamiliar |
 | `god-developer` agent | hapo:test → | FAIL verdicts route back here for fixing |
-| `test-runner` agent | hapo:test → | Primary executor, spawned via Task tool |
+| `test-runner` agent | hapo:test → | Primary executor, spawned via the `Agent` tool |
 | chrome-devtools scripts | test-runner → | UI verification (navigate, screenshot, console, network, performance, aria-snapshot, inject-auth) |
 
 ## References

package/src/claude/status.cjs

@@ -21,8 +21,10 @@ const { countConfigs } = require('./hooks/lib/counter.cjs');
 const { loadConfig } = require('./hooks/lib/config.cjs');
 const { getGitInfo } = require('./hooks/lib/git.cjs');
 
-// Buffer constant matching /context output (22.5% of 200k)
-const AUTOCOMPACT_BUFFER = 45000;
+// Autocompact reserve as a fraction of the ACTUAL window size from the payload.
+// Derived from /context on a 200k window (45000/200000 = 22.5%); expressed as a
+// ratio so 1M-context models are not treated as if they were 200k.
+const AUTOCOMPACT_BUFFER_RATIO = 0.225;
 
 /**
  * Expand home directory to ~
@@ -411,19 +413,20 @@ async function main() {
       }
     } catch {}
 
-    // Context window - use current_usage fields with AUTOCOMPACT_BUFFER
+    // Context window - use current_usage fields with a proportional reserve
     const usage = data.context_window?.current_usage || {};
     const contextSize = data.context_window?.context_window_size || 0;
     let contextPercent = 0;
     let totalTokens = 0;
 
-    if (contextSize > 0 && contextSize > AUTOCOMPACT_BUFFER) {
+    if (contextSize > 0) {
       totalTokens = (usage.input_tokens ?? 0) +
                     (usage.cache_creation_input_tokens ?? 0) +
                     (usage.cache_read_input_tokens ?? 0);
 
-      // Add buffer to match /context calculation
-      contextPercent = Math.min(100, Math.round(((totalTokens + AUTOCOMPACT_BUFFER) / contextSize) * 100));
+      // Add the reserve to match /context calculation on any window size
+      const buffer = Math.round(contextSize * AUTOCOMPACT_BUFFER_RATIO);
+      contextPercent = Math.min(100, Math.round(((totalTokens + buffer) / contextSize) * 100));
     }
 
     // Write context data to temp file for hooks to read

package/src/opencode/plugins/docs-sync.ts

@@ -71,27 +71,21 @@ function currentSourceHash(cwd: string): string {
 
 function buildMissingDocsBanner(): string {
   return [
-    "### 🔴 URGENT SYSTEM ACTION: MISSING DOCUMENTATION 🔴",
-    "> BẮT BUỘC (MANDATORY): Hệ thống phát hiện dự án đã có Source Code nhưng thư mục `docs/` chưa tồn tại.",
-    "> Nhiệm vụ ĐẦU TIÊN của bạn trong session này là đọc hiểu mã nguồn hiện tại và tạo ra các tài liệu tiêu chuẩn:",
-    "> 1. `docs/system-architecture.md` (Kiến trúc hệ thống, phân tích flow)",
-    "> 2. `docs/project-overview-pdr.md` (Tổng quan, mục tiêu, tính năng)",
-    "> 3. Khởi tạo file hidden `docs/.sync_hash` để theo dõi cập nhật.",
-    "> ",
-    '> LƯU Ý BẮT BUỘC: Bạn phải chạy lệnh Git này trong Terminal để lấy Hash Code mới nhất: `git log -1 --format="%H" -- . ":(exclude)docs"`',
-    "> Sau đó ghi chuẩn giá trị Hash đó vào file `docs/.sync_hash`.",
+    "### Missing docs/",
+    "> Source exists but `docs/` does not. Create baseline docs first:",
+    "> 1. `docs/system-architecture.md` — system architecture and flows",
+    "> 2. `docs/project-overview-pdr.md` — overview, goals, features",
+    '> 3. Write current hash to `docs/.sync_hash` via `git log -1 --format="%H" -- . ":(exclude)docs"`',
   ].join("\n");
 }
 
 function buildStaleDocsBanner(currentHash: string, lastSyncHash: string): string {
   return [
-    "### 🔄 CONTINUOUS DOCS SYNC REQUIRED 🔄",
-    `> Source Code vừa có sự thay đổi mới (Git Hash: \`${currentHash}\`) kể từ lần đồng bộ Docs cuối cùng (\`${lastSyncHash || "Chưa gán"}\`).`,
-    "> YÊU CẦU TRƯỚC KHI LÀM THÊM TÍNH NĂNG:",
-    `> 1. Rà soát file bị thay đổi gần đây (dùng \`git diff ${lastSyncHash} ${currentHash}\` hoặc \`git log\`).`,
-    "> 2. Cập nhật lại `docs/system-architecture.md` hoặc các chuẩn code nếu cần thiết.",
-    "> 3. Cập nhật Changelog (nhật ký thay đổi).",
-    `> 4. KHI HOÀN TẤT, BẠN PHẢI GHI ĐÈ GIÁ TRỊ SAU: \`${currentHash}\` VÀO FILE \`docs/.sync_hash\` ĐỂ CHỐT TRẠNG THÁI HIỆN TẠI.`,
+    "### Docs sync needed",
+    `> Source changed (\`${currentHash}\`) since last docs sync (\`${lastSyncHash || "none"}\`).`,
+    `> 1. Review recent changes (\`git diff ${lastSyncHash} ${currentHash}\` or \`git log\`).`,
+    "> 2. Update architecture/code-standards docs and changelog as needed.",
+    `> 3. Write \`${currentHash}\` to \`docs/.sync_hash\` when done.`,
   ].join("\n");
 }
 

package/src/claude/archive-command/code/SKILL.md

@@ -1,55 +0,0 @@
----
-name: hapo:code
-description: Implement the next approved spec task and then hand off to hapo:test and hapo:review.
-version: 1.0.0
-argument-hint: <feature-name>
----
-
-# Code
-
-Implement the next pending task from an approved spec instead of coding from memory.
-
-## Usage
-
-```bash
-/hapo:code <feature-name>
-```
-
-## Load First
-
-- `references/execution-loop.md`
-- `.specs/$ARGUMENTS/tasks.md`
-- `.specs/$ARGUMENTS/design.md`
-- `.specs/$ARGUMENTS/requirements.md`
-
-## Execute
-
-1. Read `.specs/$ARGUMENTS/tasks.md` and identify the next pending task.
-2. Read the related context from `design.md` and `requirements.md`.
-3. Implement only that task. Keep scope tight.
-4. Follow the project standards already present in the repo.
-5. Update task status in the spec artifact if the workflow supports it.
-6. Hand off immediately to:
-   - `/hapo:test`
-   - `/hapo:review`
-
-## Output
-
-Return:
-- implemented task name
-- touched files
-- blockers or follow-up items
-- explicit handoff to `/hapo:test` and `/hapo:review`
-
-## Rules
-
-- Do not implement multiple major tasks in one pass.
-- Stop if `tasks.md` is missing.
-- Prefer existing patterns over new abstractions.
-- Keep the work aligned to the spec.
-
-## Related
-
-- Command: `/code`
-- Previous skill: `/hapo:spec-tasks`
-- Next skills: `/hapo:test`, `/hapo:review`

package/src/claude/archive-command/code/references/execution-loop.md

@@ -1,21 +0,0 @@
-# Execution Loop
-
-## Goal
-
-Implement one approved task at a time and immediately validate it.
-
-## Loop
-
-1. Read the next pending task in `tasks.md`.
-2. Read the matching context in `design.md` and `requirements.md`.
-3. Implement only that task.
-4. Run `/hapo:test`.
-5. Run `/hapo:review`.
-6. Move to the next task only after the current pass is clear.
-
-## Guardrails
-
-- Keep scope tight.
-- Prefer existing project patterns.
-- Do not batch multiple major tasks into one pass.
-- Stop and report blockers instead of guessing.

package/src/claude/archive-command/code.md

@@ -1,17 +0,0 @@
----
-name: code
-description: Implement approved work from specification tasks and then hand off to test and review.
-allowed-tools: Read, Glob, Grep, Edit, Write, Bash
-argument-hint: <feature-name>
----
-
-# /code - Implement from spec tasks
-
-Use this command after /spec-tasks.
-
-1. Read `.specs/$ARGUMENTS/tasks.md` and identify the next pending task.
-2. Implement only that task following project standards.
-3. Run `/test`.
-4. Run `/review`.
-
-Preferred flow: /spec-init -> /spec-requirements -> /spec-design -> /spec-tasks -> /code -> /test -> /review