@haposoft/cafekit 0.8.11 → 0.8.12
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/package.json +1 -1
- package/src/claude/hooks/lib/config.cjs +1 -0
- package/src/claude/hooks/lib/skill-router-routes.cjs +190 -0
- package/src/claude/hooks/skill-router.cjs +68 -0
- package/src/claude/migration-manifest.json +3 -1
- package/src/claude/settings/settings.json +4 -0
- package/src/claude/skills/debug/SKILL.md +56 -23
- package/src/claude/skills/develop/SKILL.md +78 -6
- package/src/claude/skills/develop/references/implementation-notes-template.html +320 -0
- package/src/claude/skills/develop/references/quality-gate.md +25 -0
- package/src/claude/skills/hotfix/SKILL.md +69 -18
- package/src/claude/skills/hotfix/references/prevention-gate.md +1 -1
- package/src/claude/skills/hotfix/references/review-cycle.md +9 -9
- package/src/claude/skills/hotfix/references/workflow-specialized.md +2 -2
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@haposoft/cafekit",
|
|
3
|
-
"version": "0.8.
|
|
3
|
+
"version": "0.8.12",
|
|
4
4
|
"description": "Claude Code-first spec-driven workflow for AI coding assistants. Bundles CafeKit hapo: skills, runtime hooks, agents, and installer scaffolding.",
|
|
5
5
|
"author": "Haposoft <nghialt@haposoft.com>",
|
|
6
6
|
"license": "MIT",
|
|
@@ -0,0 +1,190 @@
|
|
|
1
|
+
const MIN_SCORE = 4;
|
|
2
|
+
const WEIGHTS = { strong: 6, medium: 3, weak: 1, negative: -5 };
|
|
3
|
+
|
|
4
|
+
const ROUTES = [
|
|
5
|
+
route('hapo:hotfix', 'urgent fix or production regression', 100, {
|
|
6
|
+
strong: ['hotfix', 'fix bug', 'fix lỗi', 'fix loi', 'sửa lỗi', 'sua loi', 'production bug', 'prod bug', 'regression', 'lỗi production', 'loi production', 'sửa gấp', 'sua gap', 'バグ修正', '不具合修正', '本番障害', '本番バグ', '緊急修正', '至急修正', 'リグレッション'],
|
|
7
|
+
medium: ['khẩn cấp', 'khan cap', 'production', 'critical bug', 'rollback', '修正して', '直して', '緊急', '本番', '重大バグ', 'ロールバック', '障害対応'],
|
|
8
|
+
weak: ['fix', 'fixing', 'sửa', 'sua', 'urgent', 'emergency', 'release is broken', '修正', '直す', '至急', 'リリースが壊れた'],
|
|
9
|
+
negative: ['slide', 'pptx', 'spec', 'brainstorm'],
|
|
10
|
+
}),
|
|
11
|
+
route('hapo:debug', 'bug investigation or failure diagnosis', 90, {
|
|
12
|
+
strong: ['debug', 'root cause', 'diagnose', 'stack trace', 'không chạy', 'khong chay', 'デバッグ', '原因調査', '根本原因', 'スタックトレース', '動かない'],
|
|
13
|
+
medium: ['bug', 'error', 'exception', 'failing', 'failed', 'failure', 'broken', 'lỗi', 'loi', 'tại sao', 'tai sao', 'vì sao', 'vi sao', 'nguyên nhân', 'nguyen nhan', 'ci fail', 'build fail', 'バグ', 'エラー', '例外', '失敗', '壊れている', 'なぜ', '原因', 'ci失敗', 'ビルド失敗'],
|
|
14
|
+
weak: ['sai', 'fail', 'issue', 'problem', '問題', '不具合'],
|
|
15
|
+
negative: ['commit', 'push', 'slide', 'pptx'],
|
|
16
|
+
}),
|
|
17
|
+
route('hapo:specs', 'specification, requirements, design, tasks, or spec validation', 80, {
|
|
18
|
+
strong: ['spec', 'specs', 'requirements', 'acceptance criteria', 'task breakdown', 'đặc tả', 'dac ta', '仕様', '仕様書', '要件', '受け入れ条件', 'タスク分解', '仕様を作って', '仕様を作成'],
|
|
19
|
+
medium: ['requirement', 'ears', 'design doc', 'scope', '--validate', 'yêu cầu', 'yeu cau', 'phạm vi', 'pham vi', 'validate spec', 'kiểm tra spec', 'kiem tra spec', '要求', '設計書', 'スコープ', '検証', '仕様を確認'],
|
|
20
|
+
weak: ['tính năng mới', 'tinh nang moi', 'feature idea', 'user story', 'criteria', 'task list', '新機能', 'ユーザーストーリー', '基準', 'タスクリスト'],
|
|
21
|
+
negative: ['commit', 'push', 'bug', 'error', 'production', 'pptx', 'pdf'],
|
|
22
|
+
}),
|
|
23
|
+
route('hapo:develop', 'implementation from an approved spec or task list', 75, {
|
|
24
|
+
strong: ['develop', 'implement', 'implementation', 'theo spec', 'theo specs', 'approved spec', 'làm theo spec', 'lam theo spec', '実装', '開発', '仕様に沿って', '仕様どおり', '承認済み仕様'],
|
|
25
|
+
medium: ['build this', 'code this', 'start task', 'run task', 'thực hiện task', 'thuc hien task', 'phát triển', 'phat trien', 'bắt đầu implement', 'bat dau implement', 'vào code', 'vao code', '作って', 'コードを書いて', 'タスクを開始', 'タスクを実行', '開発して', '実装して'],
|
|
26
|
+
weak: ['triển khai', 'trien khai', 'đưa vào code', 'dua vao code', 'code feature', 'コード化', '機能を作る'],
|
|
27
|
+
negative: ['bug', 'debug', 'review', 'test only', 'commit'],
|
|
28
|
+
}),
|
|
29
|
+
route('hapo:test', 'test, verification, QA, or runtime validation', 70, {
|
|
30
|
+
strong: ['unit test', 'integration test', 'e2e', 'playwright', 'coverage', 'kiểm thử', 'kiem thu', '単体テスト', '結合テスト', 'カバレッジ', 'テストして'],
|
|
31
|
+
medium: ['test', 'tests', 'testing', 'qa', 'verify', 'verification', 'kiểm tra chạy', 'kiem tra chay', 'xác minh', 'xac minh', 'テスト', '検証', '確認', '動作確認'],
|
|
32
|
+
weak: ['assert', 'runtime proof', 'manual qa', 'end to end', 'smoke test', 'アサート', 'スモークテスト'],
|
|
33
|
+
negative: ['spec', 'requirements', 'commit', 'push'],
|
|
34
|
+
}),
|
|
35
|
+
route('hapo:code-review', 'code review, audit, security, or quality assessment', 68, {
|
|
36
|
+
strong: ['code review', 'security review', 'performance review', 'đánh giá code', 'danh gia code', 'コードレビュー', 'セキュリティレビュー', '性能レビュー'],
|
|
37
|
+
medium: ['review', 'audit', 'quality', 'đánh giá', 'danh gia', 'kiểm tra chất lượng', 'kiem tra chat luong', 'レビュー', '監査', '品質', '品質確認'],
|
|
38
|
+
weak: ['risk', 'maintainability', 'readability', 'vulnerability', 'lỗ hổng', 'lo hong', 'リスク', '保守性', '可読性', '脆弱性'],
|
|
39
|
+
negative: ['slide', 'pptx', 'commit and push'],
|
|
40
|
+
}),
|
|
41
|
+
route('hapo:git', 'git, commit, push, branch, tag, or pull request workflow', 65, {
|
|
42
|
+
strong: ['commit', 'push', 'pull request', 'git', 'đẩy lên', 'day len', 'コミット', 'プッシュ', 'プルリク', 'リリースして'],
|
|
43
|
+
medium: ['pr ', 'branch', 'tag', 'release', 'publish', 'merge', 'rebase', 'ブランチ', 'タグ', 'リリース', '公開', 'マージ', 'リベース'],
|
|
44
|
+
weak: ['origin', 'remote', 'checkout', 'stash', 'version bump', 'リモート', 'チェックアウト', 'スタッシュ', 'バージョン更新'],
|
|
45
|
+
negative: ['deploy', 'test', 'review only'],
|
|
46
|
+
}),
|
|
47
|
+
route('hapo:inspect', 'codebase discovery, file search, structure scan, or locating implementation areas', 64, {
|
|
48
|
+
strong: ['inspect', 'codebase scan', 'scan codebase', 'scan source', 'file discovery', 'find files', 'locate files', 'xem source', 'xem codebase', 'quét source', 'quet source', 'quét codebase', 'quet codebase', 'kiểm tra cấu trúc', 'kiem tra cau truc', 'コード構造', 'ソース確認', 'コードベース確認', 'ファイル探索', '構造を確認'],
|
|
49
|
+
medium: ['search files', 'find where', 'where is', 'project structure', 'code structure', 'repo structure', 'tìm file', 'tim file', 'tìm trong source', 'tim trong source', 'cấu trúc project', 'cau truc project', 'ở đâu', 'o dau', '関連ファイル', 'どこにある', 'プロジェクト構造', 'リポジトリ構造', '探して'],
|
|
50
|
+
weak: ['scan', 'inspect code', 'explore code', 'xem qua', 'xem giúp', '調べて', '確認して'],
|
|
51
|
+
negative: ['bug', 'error', 'lỗi', 'loi', 'fail', 'failure', 'production', 'hotfix', 'fix', 'sửa', 'sua', 'debug', 'develop', 'implement', 'test', 'commit', 'push', 'slide', 'pptx'],
|
|
52
|
+
}),
|
|
53
|
+
route('hapo:impact-analysis', 'impact analysis before changing existing behavior', 64, {
|
|
54
|
+
strong: ['impact analysis', 'blast radius', 'ảnh hưởng', 'anh huong', 'tác động', 'tac dong', '影響分析', '影響範囲', '影響', '副作用'],
|
|
55
|
+
medium: ['impact', 'liên quan những đâu', 'lien quan nhung dau', 'affected files', 'dependency impact', '関連箇所', '影響ファイル', '依存関係'],
|
|
56
|
+
weak: ['before changing', 'risk area', 'downstream', 'upstream', 'side effect', '変更前', 'リスク範囲', '下流', '上流'],
|
|
57
|
+
negative: ['slide', 'pptx'],
|
|
58
|
+
}),
|
|
59
|
+
route('hapo:frontend-design', 'UI/UX design, visual style, layout, or color system', 62, {
|
|
60
|
+
strong: ['ui design', 'visual style', 'color system', 'thiết kế giao diện', 'thiet ke giao dien', 'màu sắc', 'mau sac', 'uiデザイン', '画面デザイン', 'ビジュアルスタイル', '配色'],
|
|
61
|
+
medium: ['ux', 'layout', 'style', 'theme', 'responsive design', 'giao diện', 'giao dien', 'wireframe', 'レイアウト', 'スタイル', 'テーマ', 'レスポンシブデザイン', '画面', 'ワイヤーフレーム', '色'],
|
|
62
|
+
weak: ['palette', 'typography', 'spacing', 'polish ui', 'mockup', 'prototype', 'パレット', 'タイポグラフィ', '余白', 'モックアップ', 'プロトタイプ'],
|
|
63
|
+
negative: ['backend', 'api', 'database'],
|
|
64
|
+
}),
|
|
65
|
+
route('hapo:react-best-practices', 'React and Next.js performance patterns, rerender optimization, and Vercel best practices', 60, {
|
|
66
|
+
strong: ['react best practices', 'next.js best practices', 'vercel react best practices', 'react performance', 'next.js performance', 'optimize react', 'optimize next.js', 'tối ưu react', 'toi uu react', 'tối ưu next.js', 'toi uu next.js', 'reactベストプラクティス', 'next.jsベストプラクティス', 'react最適化', 'next.js最適化', 'react性能'],
|
|
67
|
+
medium: ['bundle optimization', 'bundle size', 'rerender optimization', 're-render optimization', 'data fetching', 'server component', 'client component', 'suspense', 'hydration', 'waterfall', 'usememo', 'usecallback', 'react cache', 'tối ưu rerender', 'toi uu rerender', 'tối ưu bundle', 'toi uu bundle', 'バンドル最適化', '再レンダー最適化', 'データ取得', 'サーバーコンポーネント', 'クライアントコンポーネント', 'ハイドレーション'],
|
|
68
|
+
weak: ['react', 'next.js', 'memo', 'rerender', 're-render', 'render performance', 'component performance', 'waterfalls', 'lazy state', 'dynamic import', 'react pattern', 'next.js pattern', 'レンダー性能', 'コンポーネント性能', '動的インポート'],
|
|
69
|
+
negative: ['backend', 'api', 'database', 'slide', 'pptx', 'commit', 'push'],
|
|
70
|
+
}),
|
|
71
|
+
route('hapo:frontend-development', 'frontend implementation work', 58, {
|
|
72
|
+
strong: ['react', 'next.js', 'vite', 'frontend', 'tailwind', 'web app', 'フロントエンド', 'webアプリ'],
|
|
73
|
+
medium: ['component', 'css', 'html', 'browser ui', 'client side', 'giao diện react', 'コンポーネント', 'ブラウザui', 'クライアント側', 'react画面'],
|
|
74
|
+
weak: ['state management', 'hook', 'form', 'table', 'dashboard ui', '状態管理', 'フック', 'フォーム', 'テーブル', 'ダッシュボードui'],
|
|
75
|
+
negative: ['best practices', 'performance', 'optimize', 'optimization', 'rerender', 're-render', 'tối ưu', 'toi uu', '再レンダー', '最適化', '性能', 'backend only', 'database only', 'slide', 'pptx'],
|
|
76
|
+
}),
|
|
77
|
+
route('hapo:backend-development', 'backend, API, database, or service implementation', 58, {
|
|
78
|
+
strong: ['backend', 'api', 'database', 'endpoint', 'server', 'service', 'バックエンド', 'データベース', 'エンドポイント', 'サーバー', 'サービス'],
|
|
79
|
+
medium: ['db', 'sql', 'postgres', 'mysql', 'migration', 'schema', 'worker', 'queue', 'マイグレーション', 'スキーマ', 'ワーカー', 'キュー'],
|
|
80
|
+
weak: ['controller', 'route handler', 'repository', 'model', 'auth service', 'コントローラ', 'ルートハンドラ', 'リポジトリ', 'モデル', '認証サービス'],
|
|
81
|
+
negative: ['frontend only', 'slide', 'pptx'],
|
|
82
|
+
}),
|
|
83
|
+
route('hapo:mobile-development', 'mobile app implementation', 56, {
|
|
84
|
+
strong: ['mobile', 'ios', 'android', 'react native', 'flutter', 'モバイル'],
|
|
85
|
+
medium: ['app store', 'play store', 'native app', 'mobile screen', 'アプリストア', 'playストア', 'ネイティブアプリ', 'モバイル画面'],
|
|
86
|
+
weak: ['gesture', 'push notification', 'offline sync', 'ジェスチャー', 'プッシュ通知', 'オフライン同期'],
|
|
87
|
+
negative: ['web only', 'desktop only'],
|
|
88
|
+
}),
|
|
89
|
+
route('hapo:devops', 'deployment, infrastructure, CI/CD, or operations work', 54, {
|
|
90
|
+
strong: ['deploy', 'deployment', 'docker', 'kubernetes', 'ci/cd', 'github actions', 'デプロイ', 'デプロイメント'],
|
|
91
|
+
medium: ['vercel', 'infra', 'infrastructure', 'devops', 'pipeline', 'environment variable', 'インフラ', 'パイプライン', '環境変数'],
|
|
92
|
+
weak: ['build server', 'container', 'helm', 'terraform', 'monitoring', 'ビルドサーバー', 'コンテナ', '監視'],
|
|
93
|
+
negative: ['slide', 'pptx', 'spec only'],
|
|
94
|
+
}),
|
|
95
|
+
route('hapo:generate-graph', 'diagram, graph, architecture map, or flow visualization', 52, {
|
|
96
|
+
strong: ['diagram', 'graph', 'mermaid', 'flowchart', 'architecture diagram', 'sơ đồ', 'so do', '図', '図解', 'ダイアグラム', 'グラフ', 'フローチャート', '構成図'],
|
|
97
|
+
medium: ['biểu đồ', 'bieu do', 'visualize', 'sequence diagram', 'data flow', '可視化', 'シーケンス図', 'データフロー'],
|
|
98
|
+
weak: ['mind map', 'dependency map', 'system map', 'マインドマップ', '依存関係図', 'システム図'],
|
|
99
|
+
negative: ['pptx', 'slide deck'],
|
|
100
|
+
}),
|
|
101
|
+
route('hapo:brainstorm', 'early ideation or unclear solution direction', 50, {
|
|
102
|
+
strong: ['brainstorm', 'ý tưởng', 'y tuong', 'phương án', 'phuong an', 'gợi ý', 'goi y', 'ブレスト', 'アイデア', '案', '提案して', '相談'],
|
|
103
|
+
medium: ['idea', 'ideas', 'approach', 'options', 'tradeoff', 'chủ đề', 'chu de', 'cần làm gì', 'can lam gi', 'アプローチ', '選択肢', 'トレードオフ', 'テーマ', '何をすれば'],
|
|
104
|
+
weak: ['proposal', 'strategy', 'plan options', 'explore', 'direction', 'seminar topic', '提案', '戦略', '方向性', '検討'],
|
|
105
|
+
negative: ['commit', 'push', 'bug', 'error'],
|
|
106
|
+
}),
|
|
107
|
+
route('hapo:research', 'technical research or best-practice lookup', 48, {
|
|
108
|
+
strong: ['research', 'best practice', 'tìm hiểu', 'tim hieu', 'nghiên cứu', 'nghien cuu', '調査', 'リサーチ', 'ベストプラクティス'],
|
|
109
|
+
medium: ['documentation', 'docs', 'compare tools', 'latest docs', 'official docs', 'ドキュメント', '比較', '最新ドキュメント', '公式ドキュメント'],
|
|
110
|
+
weak: ['investigate options', 'market scan', 'reference', 'source material', '選択肢を調べる', '参考資料', '資料'],
|
|
111
|
+
negative: ['commit', 'push'],
|
|
112
|
+
}),
|
|
113
|
+
route('hapo:pptx', 'presentation or PowerPoint work', 46, {
|
|
114
|
+
strong: ['pptx', 'powerpoint', 'slide deck', 'presentation deck', 'スライド資料', 'プレゼン資料'],
|
|
115
|
+
medium: ['slide', 'slides', 'deck', 'presentation', 'seminar slides', 'スライド', 'プレゼン', 'セミナー資料'],
|
|
116
|
+
weak: ['speaker notes', 'appendix', 'mục lục slide', 'muc luc slide', '発表ノート', '付録', '目次'],
|
|
117
|
+
negative: ['source code', 'api', 'database'],
|
|
118
|
+
}),
|
|
119
|
+
route('hapo:agent-browser', 'browser automation with snapshot refs, web interaction, recording, or Browserbase cloud browser workflows', 45, {
|
|
120
|
+
strong: ['agent-browser', 'browser automation', 'web automation', 'browserbase', 'cloud browser', 'snapshot refs', 'browser snapshot', 'automate browser', 'tự động trình duyệt', 'tu dong trinh duyet', 'tự động thao tác trình duyệt', 'tu dong thao tac trinh duyet', 'ブラウザ自動化', 'クラウドブラウザ', 'ブラウザ操作', 'ブラウザスナップショット'],
|
|
121
|
+
medium: ['open url', 'navigate site', 'click in browser', 'fill form in browser', 'record browser', 'browser session', 'multi tab', 'browser test session', 'mở website', 'mo website', 'truy cập website', 'truy cap website', 'click trên web', 'click tren web', 'điền form web', 'dien form web', 'サイトを開く', 'ブラウザで開く', 'フォーム入力', 'クリック操作', '録画'],
|
|
122
|
+
weak: ['click button', 'fill form', 'open site', 'web session', 'browser ref', 'viewport', 'cookies', 'localstorage', 'ボタンをクリック', 'ビューポート', 'クッキー'],
|
|
123
|
+
negative: ['attached screenshot', 'ảnh đính kèm', 'anh dinh kem', '画像添付', 'source code', 'codebase', 'commit', 'push', 'pptx', 'pdf'],
|
|
124
|
+
}),
|
|
125
|
+
route('hapo:pdf', 'PDF reading, extraction, or generation', 44, {
|
|
126
|
+
strong: ['pdf'], medium: ['export pdf', 'read pdf', 'extract pdf', 'pdf出力', 'pdfを読む', 'pdf抽出'], weak: ['page render', 'ページレンダー'], negative: [],
|
|
127
|
+
}),
|
|
128
|
+
route('hapo:docx', 'Word document work', 42, {
|
|
129
|
+
strong: ['docx', 'word document', 'word file', 'word文書', 'wordファイル'], medium: ['word'], weak: ['tracked changes', 'document file', '変更履歴', '文書ファイル'], negative: [],
|
|
130
|
+
}),
|
|
131
|
+
route('hapo:xlsx', 'spreadsheet or Excel work', 42, {
|
|
132
|
+
strong: ['xlsx', 'excel', 'spreadsheet', 'スプレッドシート'], medium: ['csv', 'sheet', 'workbook', 'シート', 'ワークブック'], weak: ['formula', 'pivot table', '数式', 'ピボットテーブル'], negative: [],
|
|
133
|
+
}),
|
|
134
|
+
route('hapo:ai-multimodal', 'image, video, audio, or multimodal artifact analysis', 40, {
|
|
135
|
+
strong: ['screenshot', 'video', 'audio', 'multimodal', 'ảnh', 'anh', 'hình', 'hinh', 'スクリーンショット', '動画', '音声', '画像', '写真'],
|
|
136
|
+
medium: ['image', 'screen capture', 'recording', 'file attached', 'イメージ', '画面キャプチャ', '録画', '添付ファイル'],
|
|
137
|
+
weak: ['visual', 'describe image', 'ocr', 'ビジュアル', '画像説明'],
|
|
138
|
+
negative: ['pptx', 'pdf export'],
|
|
139
|
+
}),
|
|
140
|
+
];
|
|
141
|
+
|
|
142
|
+
function route(skill, reason, priority, signals) {
|
|
143
|
+
return { skill, reason, priority, signals };
|
|
144
|
+
}
|
|
145
|
+
|
|
146
|
+
function normalize(value) {
|
|
147
|
+
return String(value || '')
|
|
148
|
+
.normalize('NFKC')
|
|
149
|
+
.normalize('NFD')
|
|
150
|
+
.replace(/[\u0300-\u036f]/g, '')
|
|
151
|
+
.normalize('NFC')
|
|
152
|
+
.toLowerCase();
|
|
153
|
+
}
|
|
154
|
+
|
|
155
|
+
function scoreRoute(prompt, routeItem) {
|
|
156
|
+
const normalized = normalize(prompt);
|
|
157
|
+
const matched = [];
|
|
158
|
+
let score = 0;
|
|
159
|
+
for (const [bucket, weight] of Object.entries(WEIGHTS)) {
|
|
160
|
+
for (const term of routeItem.signals[bucket] || []) {
|
|
161
|
+
if (!normalized.includes(normalize(term))) continue;
|
|
162
|
+
score += weight;
|
|
163
|
+
matched.push({ bucket, term, weight });
|
|
164
|
+
}
|
|
165
|
+
}
|
|
166
|
+
return { ...routeItem, score, matched, confidence: confidence(score) };
|
|
167
|
+
}
|
|
168
|
+
|
|
169
|
+
function confidence(score) {
|
|
170
|
+
if (score >= 12) return 'high';
|
|
171
|
+
if (score >= 7) return 'medium';
|
|
172
|
+
if (score >= MIN_SCORE) return 'low';
|
|
173
|
+
return 'none';
|
|
174
|
+
}
|
|
175
|
+
|
|
176
|
+
function findRoute(prompt) {
|
|
177
|
+
const candidates = ROUTES
|
|
178
|
+
.map((routeItem, index) => ({ ...scoreRoute(prompt, routeItem), index }))
|
|
179
|
+
.filter((routeItem) => routeItem.score >= MIN_SCORE)
|
|
180
|
+
.sort((a, b) => b.score - a.score || b.priority - a.priority || a.index - b.index);
|
|
181
|
+
return candidates[0] || null;
|
|
182
|
+
}
|
|
183
|
+
|
|
184
|
+
module.exports = {
|
|
185
|
+
MIN_SCORE,
|
|
186
|
+
ROUTES,
|
|
187
|
+
findRoute,
|
|
188
|
+
normalize,
|
|
189
|
+
scoreRoute,
|
|
190
|
+
};
|
|
@@ -0,0 +1,68 @@
|
|
|
1
|
+
#!/usr/bin/env node
|
|
2
|
+
/**
|
|
3
|
+
* Copyright (c) 2026 Haposoft. MIT License.
|
|
4
|
+
*
|
|
5
|
+
* UserPromptSubmit Hook - skill-router.cjs
|
|
6
|
+
*
|
|
7
|
+
* Adds a deterministic CafeKit skill suggestion for natural-language prompts.
|
|
8
|
+
* It never overrides explicit slash commands; it only injects a short routing hint.
|
|
9
|
+
*
|
|
10
|
+
* Exit: 0 always (fail-open)
|
|
11
|
+
*/
|
|
12
|
+
|
|
13
|
+
const fs = require('fs');
|
|
14
|
+
const path = require('path');
|
|
15
|
+
|
|
16
|
+
function logCrash(error) {
|
|
17
|
+
try {
|
|
18
|
+
const dir = path.join(__dirname, '.logs');
|
|
19
|
+
if (!fs.existsSync(dir)) fs.mkdirSync(dir, { recursive: true });
|
|
20
|
+
fs.appendFileSync(
|
|
21
|
+
path.join(dir, 'hook-log.jsonl'),
|
|
22
|
+
JSON.stringify({
|
|
23
|
+
ts: new Date().toISOString(),
|
|
24
|
+
hook: 'skill-router',
|
|
25
|
+
status: 'crash',
|
|
26
|
+
error: error.message,
|
|
27
|
+
}) + '\n'
|
|
28
|
+
);
|
|
29
|
+
} catch (_) {}
|
|
30
|
+
}
|
|
31
|
+
|
|
32
|
+
try {
|
|
33
|
+
const { isHookEnabled } = require('./lib/config.cjs');
|
|
34
|
+
const { findRoute } = require('./lib/skill-router-routes.cjs');
|
|
35
|
+
|
|
36
|
+
function isExplicitCommand(prompt) {
|
|
37
|
+
const trimmed = prompt.trim();
|
|
38
|
+
return trimmed.startsWith('/') || /^hapo:[a-z-]+/i.test(trimmed);
|
|
39
|
+
}
|
|
40
|
+
|
|
41
|
+
if (!isHookEnabled('skill-router')) process.exit(0);
|
|
42
|
+
|
|
43
|
+
const stdin = fs.readFileSync(0, 'utf8').trim();
|
|
44
|
+
if (!stdin) process.exit(0);
|
|
45
|
+
|
|
46
|
+
const payload = JSON.parse(stdin);
|
|
47
|
+
const prompt = payload.prompt || '';
|
|
48
|
+
if (!prompt || isExplicitCommand(prompt)) process.exit(0);
|
|
49
|
+
|
|
50
|
+
const route = findRoute(prompt);
|
|
51
|
+
if (!route) process.exit(0);
|
|
52
|
+
|
|
53
|
+
const skillDir = route.skill.replace(/^hapo:/, '');
|
|
54
|
+
const lines = [
|
|
55
|
+
'## CafeKit Skill Router',
|
|
56
|
+
`- Suggested skill: \`${route.skill}\``,
|
|
57
|
+
`- Why: ${route.reason}.`,
|
|
58
|
+
`- Confidence: ${route.confidence} (score ${route.score}).`,
|
|
59
|
+
`- Action: before acting, read \`.claude/skills/${skillDir}/SKILL.md\` and follow that workflow.`,
|
|
60
|
+
'- If the user explicitly names another workflow or asks for direct answering only, follow the user request.',
|
|
61
|
+
];
|
|
62
|
+
|
|
63
|
+
console.log(lines.join('\n'));
|
|
64
|
+
process.exit(0);
|
|
65
|
+
} catch (error) {
|
|
66
|
+
try { logCrash(error); } catch (_) {}
|
|
67
|
+
process.exit(0);
|
|
68
|
+
}
|
|
@@ -78,6 +78,7 @@
|
|
|
78
78
|
"hooks/privacy-block.cjs",
|
|
79
79
|
"hooks/inspect-block.cjs",
|
|
80
80
|
"hooks/rules.cjs",
|
|
81
|
+
"hooks/skill-router.cjs",
|
|
81
82
|
"hooks/spec-state.cjs",
|
|
82
83
|
"hooks/state.cjs",
|
|
83
84
|
"hooks/lib/color.cjs",
|
|
@@ -86,7 +87,8 @@
|
|
|
86
87
|
"hooks/lib/git.cjs",
|
|
87
88
|
"hooks/lib/config.cjs",
|
|
88
89
|
"hooks/lib/context.cjs",
|
|
89
|
-
"hooks/lib/detect.cjs"
|
|
90
|
+
"hooks/lib/detect.cjs",
|
|
91
|
+
"hooks/lib/skill-router-routes.cjs"
|
|
90
92
|
]
|
|
91
93
|
},
|
|
92
94
|
"settings": {
|
|
@@ -42,6 +42,10 @@
|
|
|
42
42
|
"type": "command",
|
|
43
43
|
"command": "node \"$CLAUDE_PROJECT_DIR/.claude/hooks/rules.cjs\""
|
|
44
44
|
},
|
|
45
|
+
{
|
|
46
|
+
"type": "command",
|
|
47
|
+
"command": "node \"$CLAUDE_PROJECT_DIR/.claude/hooks/skill-router.cjs\""
|
|
48
|
+
},
|
|
45
49
|
{
|
|
46
50
|
"type": "command",
|
|
47
51
|
"command": "node \"$CLAUDE_PROJECT_DIR/.claude/hooks/spec-state.cjs\""
|
|
@@ -16,17 +16,37 @@ Debugging is diagnosis, not repair. Find the source of the failure before changi
|
|
|
16
16
|
- `--frontend` - Include browser console, screenshot, accessibility tree, network, and responsive checks
|
|
17
17
|
- `--perf` - Include baseline measurements, bottleneck layer, profiling, and before/after targets
|
|
18
18
|
|
|
19
|
-
Default: systematic diagnosis with no product-code edits.
|
|
20
|
-
|
|
21
|
-
<
|
|
22
|
-
|
|
19
|
+
Default: systematic diagnosis with no product-code edits, scout first.
|
|
20
|
+
|
|
21
|
+
<DIAGNOSTIC-ONLY-GATE>
|
|
22
|
+
`hapo:debug` is read-only for product code.
|
|
23
|
+
Do NOT edit product code, apply fixes, create migrations, or add regression tests as implementation.
|
|
24
|
+
Do NOT change config, dependency versions, generated assets, or test snapshots to make the failure disappear.
|
|
25
|
+
Temporary instrumentation is allowed only when it is the minimal way to observe hidden state; record the file/line, capture the proof, remove it before finishing, and report `Temporary instrumentation: removed`.
|
|
26
|
+
</DIAGNOSTIC-ONLY-GATE>
|
|
27
|
+
|
|
28
|
+
<HARD-GATE-SCOUT-FIRST>
|
|
29
|
+
Before hypotheses, inspect the actual codebase context.
|
|
30
|
+
You must identify:
|
|
31
|
+
- project type, language, framework, runtime, and test runner
|
|
32
|
+
- affected files/modules and exact symptom location
|
|
33
|
+
- direct callers, dependents, and data/config boundaries
|
|
34
|
+
- related tests and reproduction commands
|
|
35
|
+
- recent commits touching affected paths
|
|
36
|
+
- adjacent known-good implementation patterns
|
|
37
|
+
|
|
38
|
+
After scout, provide a 3-6 bullet codebase-context summary before evidence capture.
|
|
39
|
+
Do not ask generic questions before this step unless the issue cannot be located from the prompt or repository.
|
|
40
|
+
</HARD-GATE-SCOUT-FIRST>
|
|
41
|
+
|
|
42
|
+
<ROOT-CAUSE-GATE>
|
|
23
43
|
Do NOT recommend a fix until the root-cause contract is complete.
|
|
24
44
|
Do NOT stop at the first plausible explanation. Test hypotheses against evidence.
|
|
25
45
|
If 2+ hypotheses are refuted, change strategy before continuing.
|
|
26
|
-
If evidence is insufficient, report `Root cause: unknown`
|
|
27
|
-
</
|
|
46
|
+
If evidence is insufficient, report `Root cause: unknown`, `Missing Evidence`, and `Next Diagnostic Action`; do not hand off to `hapo:hotfix` as ready.
|
|
47
|
+
</ROOT-CAUSE-GATE>
|
|
28
48
|
|
|
29
|
-
|
|
49
|
+
If the user asks to fix while still inside `hapo:debug`, finish the debug report first. Then hand off only the completed root-cause contract to `hapo:hotfix`.
|
|
30
50
|
|
|
31
51
|
## Process Flow
|
|
32
52
|
|
|
@@ -53,15 +73,18 @@ flowchart TD
|
|
|
53
73
|
Understand the affected code before forming hypotheses.
|
|
54
74
|
|
|
55
75
|
**Action:** Activate `hapo:inspect` for the relevant scope.
|
|
76
|
+
If `hapo:inspect` is unavailable, use direct read-only reconnaissance (`rg`, file reads, test discovery, and `git log`) and state that fallback.
|
|
56
77
|
|
|
57
78
|
**Checklist:**
|
|
79
|
+
- [ ] Project type, language, framework, runtime, and test runner identified
|
|
58
80
|
- [ ] Affected files and modules identified
|
|
59
81
|
- [ ] Direct dependencies and call paths mapped
|
|
82
|
+
- [ ] Inputs/outputs, data boundaries, and config/env boundaries mapped
|
|
60
83
|
- [ ] Related tests located
|
|
61
84
|
- [ ] Recent changes checked: `git log --oneline -10 -- <affected-files>`
|
|
62
85
|
- [ ] Existing working examples or adjacent patterns identified
|
|
63
86
|
|
|
64
|
-
**Output:** `✓ Step 1: Scouted - [N] files, [M] deps, [K] tests`
|
|
87
|
+
**Output:** `✓ Step 1: Scouted - [N] files, [M] deps, [K] tests` plus a 3-6 bullet context summary.
|
|
65
88
|
|
|
66
89
|
---
|
|
67
90
|
|
|
@@ -77,9 +100,9 @@ Create a baseline that can later prove whether the issue changed.
|
|
|
77
100
|
- Environment facts: runtime, dependency versions, OS, browser, CI runner, config
|
|
78
101
|
- Whether the issue reproduces consistently or intermittently
|
|
79
102
|
|
|
80
|
-
For frontend issues, use
|
|
81
|
-
For CI/log issues, use
|
|
82
|
-
For performance issues, use
|
|
103
|
+
For frontend issues, use `.claude/references/debugger/frontend-verification.md`.
|
|
104
|
+
For CI/log issues, use `.claude/references/debugger/log-ci-analysis.md`.
|
|
105
|
+
For performance issues, use `.claude/references/debugger/performance-diagnostics.md`.
|
|
83
106
|
|
|
84
107
|
**Output:** `✓ Step 2: Evidence captured - baseline command/symptom recorded`
|
|
85
108
|
|
|
@@ -115,7 +138,7 @@ Result: confirmed | refuted | inconclusive
|
|
|
115
138
|
Rules:
|
|
116
139
|
- Never batch unrelated changes as a test.
|
|
117
140
|
- Prefer read-only evidence: logs, grep, stack traces, DB queries, browser traces.
|
|
118
|
-
- For flaky async tests, use
|
|
141
|
+
- For flaky async tests, use `.claude/references/debugger/condition-based-waiting.md`.
|
|
119
142
|
- If 2+ hypotheses are refuted, use inversion: ask what evidence would make the current explanation impossible.
|
|
120
143
|
|
|
121
144
|
**Output:** `✓ Step 4: Hypotheses tested - [confirmed/refuted counts]`
|
|
@@ -156,7 +179,7 @@ Prepare the handoff to `hapo:hotfix` or the user.
|
|
|
156
179
|
- Affected-module tests
|
|
157
180
|
- Typecheck/lint/build commands when relevant
|
|
158
181
|
- UI screenshot/console/network checks when relevant
|
|
159
|
-
- Side-effect sweep from
|
|
182
|
+
- Side-effect sweep from `.claude/references/debugger/side-effect-gate.md`
|
|
160
183
|
|
|
161
184
|
**Output:** `✓ Step 6: Verification planned - [commands/scenarios]`
|
|
162
185
|
|
|
@@ -189,9 +212,18 @@ Prepare the handoff to `hapo:hotfix` or the user.
|
|
|
189
212
|
- Regression guard:
|
|
190
213
|
- Side-effect sweep:
|
|
191
214
|
|
|
215
|
+
### Temporary Instrumentation
|
|
216
|
+
- none | removed: [file:line, purpose, proof captured]
|
|
217
|
+
|
|
192
218
|
### Recommended Fix Direction
|
|
193
219
|
[Smallest root-cause fix, or "insufficient evidence"]
|
|
194
220
|
|
|
221
|
+
### Missing Evidence
|
|
222
|
+
- [Only when root cause is unknown]
|
|
223
|
+
|
|
224
|
+
### Next Diagnostic Action
|
|
225
|
+
- [Only when root cause is unknown]
|
|
226
|
+
|
|
195
227
|
### Unresolved Questions
|
|
196
228
|
- [Only if any]
|
|
197
229
|
```
|
|
@@ -199,18 +231,19 @@ Prepare the handoff to `hapo:hotfix` or the user.
|
|
|
199
231
|
## Relationship To Hotfix
|
|
200
232
|
|
|
201
233
|
- Use `hapo:debug` to determine what is wrong.
|
|
202
|
-
- Use `hapo:hotfix` to change code after the root-cause contract is complete.
|
|
234
|
+
- Use `hapo:hotfix` to change code only after the root-cause contract is complete.
|
|
235
|
+
- A `Root cause: unknown` report is not ready for hotfix; continue diagnosis or ask for the missing artifact.
|
|
203
236
|
- If `hapo:hotfix` verification fails, return to `hapo:debug` with the new evidence.
|
|
204
237
|
|
|
205
238
|
## References
|
|
206
239
|
|
|
207
240
|
Load as needed:
|
|
208
|
-
-
|
|
209
|
-
-
|
|
210
|
-
-
|
|
211
|
-
-
|
|
212
|
-
-
|
|
213
|
-
-
|
|
214
|
-
-
|
|
215
|
-
-
|
|
216
|
-
-
|
|
241
|
+
- `.claude/references/debugger/core-philosophy.md` - Anti-guessing discipline
|
|
242
|
+
- `.claude/references/debugger/root-cause-tracing.md` - Backward trace to origin
|
|
243
|
+
- `.claude/references/debugger/verification-protocol.md` - Fresh evidence requirements
|
|
244
|
+
- `.claude/references/debugger/log-ci-analysis.md` - Logs and CI/CD failure analysis
|
|
245
|
+
- `.claude/references/debugger/parallel-agent-hydration.md` - Parallel reconnaissance
|
|
246
|
+
- `.claude/references/debugger/frontend-verification.md` - Browser/UI verification
|
|
247
|
+
- `.claude/references/debugger/performance-diagnostics.md` - Performance investigation
|
|
248
|
+
- `.claude/references/debugger/condition-based-waiting.md` - Flaky async test diagnosis
|
|
249
|
+
- `.claude/references/debugger/side-effect-gate.md` - Regression and blast-radius checks
|
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: hapo:develop
|
|
3
|
-
description: "Code execution engine: Reads specs and implements code end-to-end with automatic code review
|
|
4
|
-
argument-hint: "[feature-name|specs-directory-path]"
|
|
3
|
+
description: "Code execution engine: Reads specs and implements code end-to-end with automatic code review, self-healing, and visual implementation notes."
|
|
4
|
+
argument-hint: "[feature-name|specs-directory-path] [task-file] [--flash] [--no-notes]"
|
|
5
5
|
---
|
|
6
6
|
|
|
7
7
|
# Develop — Feature Implementation (Task-Orchestrated Build)
|
|
@@ -16,6 +16,9 @@ Reads the project specification (`hapo:specs`) and implements code through a dis
|
|
|
16
16
|
/hapo:develop <feature name>
|
|
17
17
|
/hapo:develop specs/<feature-name>
|
|
18
18
|
/hapo:develop <feature name> <specific-task-file.md>
|
|
19
|
+
/hapo:develop <feature name> --flash
|
|
20
|
+
/hapo:develop <feature name> <specific-task-file.md> --flash
|
|
21
|
+
/hapo:develop <feature name> --no-notes
|
|
19
22
|
```
|
|
20
23
|
|
|
21
24
|
## Execution Modes
|
|
@@ -25,7 +28,7 @@ Triggered by `/hapo:develop <feature> <task-file>`.
|
|
|
25
28
|
|
|
26
29
|
- Load exactly one task file.
|
|
27
30
|
- Implement only that task packet.
|
|
28
|
-
- STOP immediately after the task is verified and synchronized.
|
|
31
|
+
- STOP immediately after the task is verified and synchronized, or flash-synchronized when `--flash` is active.
|
|
29
32
|
- Never auto-chain into the next task.
|
|
30
33
|
|
|
31
34
|
### 2. Full-Spec Mode
|
|
@@ -37,6 +40,28 @@ Triggered by `/hapo:develop <feature>` or `/hapo:develop specs/<feature>`.
|
|
|
37
40
|
- Sync state.
|
|
38
41
|
- Recompute the queue and continue.
|
|
39
42
|
- STOP the overall run on the first blocked task, unresolved gate failure, or missing proof.
|
|
43
|
+
- In `--flash` mode, missing full test proof does not stop the loop; record `FLASH_UNVERIFIED` and continue to the next unblocked task.
|
|
44
|
+
|
|
45
|
+
### 3. Flash Mode
|
|
46
|
+
Triggered by adding `--flash` to either specific-task or full-spec mode.
|
|
47
|
+
|
|
48
|
+
- Optimize for fast implementation, not full verification.
|
|
49
|
+
- Still load the approved spec, scout every task, obey scope, and implement real code.
|
|
50
|
+
- Skip dedicated test suites, E2E/browser/manual QA loops, full task evidence execution, and code-review retry loops.
|
|
51
|
+
- Run only cheap preflight checks when available and fast: syntax, typecheck, or build commands that do not require installing dependencies or starting external services.
|
|
52
|
+
- Never weaken, delete, or rewrite tests to avoid running them.
|
|
53
|
+
- Sync completed implementation with an explicit `FLASH_UNVERIFIED` receipt; do not claim production-ready quality.
|
|
54
|
+
- Final output MUST recommend `/hapo:test <feature>` before merge, release, or publish.
|
|
55
|
+
|
|
56
|
+
### 4. Implementation Notes
|
|
57
|
+
Enabled by default for all develop modes. Disable only with `--no-notes`.
|
|
58
|
+
|
|
59
|
+
- Maintain `specs/<feature-name>/implementation-notes.html`.
|
|
60
|
+
- Use `references/implementation-notes-template.html` when the file does not exist.
|
|
61
|
+
- Keep the file self-contained: inline CSS, no JS, no external fonts, no network assets.
|
|
62
|
+
- Style notes as readable Claude Code-like blocks: compact cards, left accent bars, category badges, monospace file paths, and a task timeline.
|
|
63
|
+
- Record decisions and caveats while implementing, not only at the end.
|
|
64
|
+
- Do not use notes to justify scope changes that alter the approved contract. If the contract changes, stop and route back to `/hapo:specs update`.
|
|
40
65
|
|
|
41
66
|
<HARD-GATE>
|
|
42
67
|
DO NOT write implementation code until an approved spec exists.
|
|
@@ -46,6 +71,7 @@ DO NOT write implementation code until an approved spec exists.
|
|
|
46
71
|
<DEFINITION-OF-DONE>
|
|
47
72
|
A task is NOT done because code compiles or a placeholder renders.
|
|
48
73
|
A task is done only when the task file's Completion Criteria AND Evidence section are satisfied with real execution proof. Existing specs may use `Task Test Plan & Verification Evidence` or legacy `Verification & Evidence`; treat those as the same contract.
|
|
74
|
+
`--flash` is the only exception: it records fast implementation closeout with `FLASH_UNVERIFIED`, not full Definition of Done.
|
|
49
75
|
</DEFINITION-OF-DONE>
|
|
50
76
|
|
|
51
77
|
<CONTRACT-FIDELITY>
|
|
@@ -73,9 +99,13 @@ flowchart TD
|
|
|
73
99
|
B -->|Missing| Z[Stop: Run /hapo:specs]
|
|
74
100
|
B -->|Ready| C[Step 2: Task-Aware Scout (inspector)]
|
|
75
101
|
C --> D[Step 3: Implement Code (god-developer)]
|
|
76
|
-
D --> E
|
|
77
|
-
E -->|
|
|
78
|
-
E -->|
|
|
102
|
+
D --> E{Flash Mode?}
|
|
103
|
+
E -->|No| Q[Step 4: Quality Gate: Test + Spec Review + Code Review + Evidence]
|
|
104
|
+
E -->|Yes| R[Step 4F: Flash Gate: Minimal Preflight + Scope Sanity]
|
|
105
|
+
Q -->|Fail| D
|
|
106
|
+
Q -->|Pass| F[Step 5: State Sync + Incremental Docs Sync]
|
|
107
|
+
R -->|Syntax/compile fail| D
|
|
108
|
+
R -->|Flash closeout| F
|
|
79
109
|
F --> H{More tasks?}
|
|
80
110
|
H -->|Yes| B
|
|
81
111
|
H -->|No| G[Final Integration Scout + Report Completion]
|
|
@@ -85,6 +115,10 @@ flowchart TD
|
|
|
85
115
|
- Identify input: Open `specs/<feature-name>/spec.json`.
|
|
86
116
|
- Check `ready_for_implementation` status. If not ready, notify user.
|
|
87
117
|
- Load `task_registry` and verify it matches the requested task file(s). If registry is missing or stale, route to `/hapo:sync audit <feature>` before coding.
|
|
118
|
+
- Unless `--no-notes` is present, initialize or update `specs/<feature-name>/implementation-notes.html`:
|
|
119
|
+
- If missing, create it from `references/implementation-notes-template.html`.
|
|
120
|
+
- Replace template placeholders for feature name, spec path, creation timestamp, and current mode.
|
|
121
|
+
- If present, preserve existing note cards and update the summary/timeline/status fields.
|
|
88
122
|
- **Task Scoping (CRITICAL):**
|
|
89
123
|
- If the user specifies a particular task file (e.g., `task-R0-02...md`), load **ONLY** that specific file into working memory.
|
|
90
124
|
- If no specific task is mentioned, DO NOT load all tasks into working memory. Resolve the next single unblocked `pending` task from `task_registry` and load only that task packet.
|
|
@@ -121,6 +155,14 @@ flowchart TD
|
|
|
121
155
|
- Act as `god-developer` OR directly write code, executing tasks specified in the loaded Markdown file(s) sequentially.
|
|
122
156
|
- **Important:** You may create and modify files directly, but must faithfully follow the design from the Spec.
|
|
123
157
|
- You MUST use the Step 2 scout report as implementation context. If code reality contradicts the task packet, stop and reconcile the spec before coding.
|
|
158
|
+
- Unless `--no-notes` is present, append a note card to `implementation-notes.html` whenever any of these occurs:
|
|
159
|
+
- `decision`: a necessary implementation choice not specified by the spec
|
|
160
|
+
- `spec-gap`: missing or ambiguous spec detail discovered during implementation
|
|
161
|
+
- `codebase-reality`: existing code requires a different integration path than the task implied
|
|
162
|
+
- `tradeoff`: a conscious simplicity, performance, UX, or maintainability tradeoff
|
|
163
|
+
- `scope-escape`: a file or behavior outside Related Files must be touched for reachability/compile/integration
|
|
164
|
+
- `risk`: known residual risk, edge case, or deferred follow-up
|
|
165
|
+
- `verification`: command result, skipped check, manual proof, or evidence caveat
|
|
124
166
|
- Progress tracking: Temporarily change `[ ]` to `[/]` in Spec files while coding is in progress. Do NOT mark `[x]` before Step 4 passes.
|
|
125
167
|
- **Task Boundary Protocol (CRITICAL):**
|
|
126
168
|
- Default editable scope is `Related Files` from the task packet.
|
|
@@ -141,6 +183,8 @@ flowchart TD
|
|
|
141
183
|
The moment you finish coding, DO NOT proceed further. Switch to `references/quality-gate.md` and run the automatic review loop.
|
|
142
184
|
**Mantra:** Scope/spec compliance first, code quality second. All feedback from code-auditor must be addressed thoroughly: Score >= 9.5 & Zero Critical issues.
|
|
143
185
|
|
|
186
|
+
If `--flash` is active, use **Step 4F: Flash Gate** instead of the full automatic review loop.
|
|
187
|
+
|
|
144
188
|
- Passing Step 4 requires ALL of the following:
|
|
145
189
|
1. Automated verification passes, including preflight compile/typecheck/build health and every exact command named in the task's `Evidence` section (or `Task Test Plan & Verification Evidence` / legacy `Verification & Evidence`)
|
|
146
190
|
2. Spec compliance review passes: every scoped requirement and active task criterion is implemented, with no extras and no omissions
|
|
@@ -153,8 +197,28 @@ The moment you finish coding, DO NOT proceed further. Switch to `references/qual
|
|
|
153
197
|
- If the implementation silently replaced a named contract choice or relies on cross-service process-local stand-ins, the task is still FAIL.
|
|
154
198
|
- Only escalate to the user after 3 consecutive failed review rounds.
|
|
155
199
|
|
|
200
|
+
### Step 4F: Flash Gate (`--flash` only)
|
|
201
|
+
Flash mode is an explicit speed trade-off requested by the user.
|
|
202
|
+
|
|
203
|
+
- Skip:
|
|
204
|
+
- dedicated test commands from task Evidence
|
|
205
|
+
- full test-runner delegation
|
|
206
|
+
- E2E/browser/manual QA loops
|
|
207
|
+
- full code-auditor retry loop
|
|
208
|
+
- screenshot, accessibility, performance, and visual verification unless the active task is purely visual and can be checked cheaply
|
|
209
|
+
- Still perform:
|
|
210
|
+
- task-aware scout from Step 2
|
|
211
|
+
- active task scope sanity check against Completion Criteria
|
|
212
|
+
- reachability sanity check for runtime-facing files: imported, mounted, registered, routed, or invoked where applicable
|
|
213
|
+
- cheap compile/syntax/typecheck/build command when it is already available and expected to run quickly
|
|
214
|
+
- If the cheap preflight fails, return to Step 3 and fix before syncing.
|
|
215
|
+
- If no cheap preflight exists or it would require slow setup/external services, record `Preflight: skipped in --flash mode`.
|
|
216
|
+
- Flash output MUST log: `⚡ Step 4 Flash Gate: tests skipped by --flash; preflight=<pass|skipped>; evidence=FLASH_UNVERIFIED`.
|
|
217
|
+
- Flash output MUST NOT say `Test PASS`, `Evidence PASS`, `Auto-Approved`, or `production-ready`.
|
|
218
|
+
|
|
156
219
|
### Step 5: State Sync + Task-Level Docs Sync
|
|
157
220
|
- Only after Step 4 passes may you mark task checkboxes completed and sync `spec.json` progress/timestamps/task_registry.
|
|
221
|
+
- In `--flash` mode, Step 4F may sync the task only as a fast implementation closeout with an explicit `FLASH_UNVERIFIED` receipt.
|
|
158
222
|
- If verification is partial or blocked by environment, keep the task in `pending` or `in_progress` and record the blocker instead of pretending completion.
|
|
159
223
|
- A completed task MUST leave behind:
|
|
160
224
|
- markdown `**Status:** done`
|
|
@@ -162,7 +226,14 @@ The moment you finish coding, DO NOT proceed further. Switch to `references/qual
|
|
|
162
226
|
- `completed_at` + `last_updated_at`
|
|
163
227
|
- synchronized top-level `updated_at`
|
|
164
228
|
- a human-readable verification receipt inside the task's `Evidence` section showing which commands ran, their outcomes, and what proof was observed
|
|
229
|
+
- In `--flash` mode, the receipt MUST include `Mode: --flash`, `Tests: skipped by user request`, `Evidence: FLASH_UNVERIFIED`, and `Next verification: /hapo:test <feature>`.
|
|
165
230
|
- Verification receipts with `PRECHECK_FAIL`, `FAIL`, `UNVERIFIED`, or an explicit note that the implementation intentionally simplified a named contract MUST NOT be synchronized as `done`.
|
|
231
|
+
- Exception: `FLASH_UNVERIFIED` is allowed only when `--flash` is explicitly present. It records fast implementation completion, not full verification completion.
|
|
232
|
+
- Unless `--no-notes` is present, update `implementation-notes.html` before reporting the task:
|
|
233
|
+
- Mark the task block as `done`, `blocked`, or `flash_unverified`.
|
|
234
|
+
- Add a `verification` note with exact commands run or `Tests skipped by --flash`.
|
|
235
|
+
- If no implementation note was needed for the task, add a compact `decision` note: `No spec gaps, tradeoffs, scope escapes, or deferred risks recorded for this task.`
|
|
236
|
+
- Add `Next verification: /hapo:test <feature>` when any evidence is skipped, partial, or `FLASH_UNVERIFIED`.
|
|
166
237
|
- After syncing the active task, run a **Task Closeout Docs Checkpoint**
|
|
167
238
|
- Task Closeout Docs Checkpoint:
|
|
168
239
|
- Evaluate `Docs impact: none | minor | major` based on real behavior changes from the just-completed task
|
|
@@ -183,3 +254,4 @@ The moment you finish coding, DO NOT proceed further. Switch to `references/qual
|
|
|
183
254
|
## Attached References
|
|
184
255
|
- `references/quality-gate.md` - Rules for the Code Review loop.
|
|
185
256
|
- `references/subagent-patterns.md` - Standard prompts for calling subagents.
|
|
257
|
+
- `references/implementation-notes-template.html` - Self-contained visual implementation notes template.
|
|
@@ -0,0 +1,320 @@
|
|
|
1
|
+
<!doctype html>
|
|
2
|
+
<html lang="en">
|
|
3
|
+
<head>
|
|
4
|
+
<meta charset="utf-8">
|
|
5
|
+
<meta name="viewport" content="width=device-width, initial-scale=1">
|
|
6
|
+
<title>Implementation Notes - {{FEATURE_NAME}}</title>
|
|
7
|
+
<style>
|
|
8
|
+
:root {
|
|
9
|
+
color-scheme: light;
|
|
10
|
+
--bg: #f7faf9;
|
|
11
|
+
--panel: #ffffff;
|
|
12
|
+
--ink: #17211d;
|
|
13
|
+
--muted: #63736d;
|
|
14
|
+
--line: #dfe8e4;
|
|
15
|
+
--soft: #eef7f3;
|
|
16
|
+
--brand: #087a5a;
|
|
17
|
+
--brand-2: #0ea5a0;
|
|
18
|
+
--decision: #0f766e;
|
|
19
|
+
--spec-gap: #b45309;
|
|
20
|
+
--tradeoff: #7c3aed;
|
|
21
|
+
--scope: #be123c;
|
|
22
|
+
--risk: #dc2626;
|
|
23
|
+
--verify: #2563eb;
|
|
24
|
+
--codebase: #475569;
|
|
25
|
+
--flash: #c2410c;
|
|
26
|
+
--shadow: 0 12px 32px rgba(15, 23, 42, 0.08);
|
|
27
|
+
}
|
|
28
|
+
|
|
29
|
+
* { box-sizing: border-box; }
|
|
30
|
+
|
|
31
|
+
body {
|
|
32
|
+
margin: 0;
|
|
33
|
+
background:
|
|
34
|
+
radial-gradient(circle at top left, rgba(14, 165, 160, 0.16), transparent 34rem),
|
|
35
|
+
linear-gradient(180deg, #f8fffd 0%, var(--bg) 34%, #eef7f3 100%);
|
|
36
|
+
color: var(--ink);
|
|
37
|
+
font-family: Inter, ui-sans-serif, system-ui, -apple-system, BlinkMacSystemFont, "Segoe UI", sans-serif;
|
|
38
|
+
line-height: 1.55;
|
|
39
|
+
}
|
|
40
|
+
|
|
41
|
+
main {
|
|
42
|
+
width: min(1120px, calc(100% - 32px));
|
|
43
|
+
margin: 0 auto;
|
|
44
|
+
padding: 32px 0 56px;
|
|
45
|
+
}
|
|
46
|
+
|
|
47
|
+
.hero {
|
|
48
|
+
border: 1px solid var(--line);
|
|
49
|
+
border-radius: 16px;
|
|
50
|
+
background: rgba(255, 255, 255, 0.9);
|
|
51
|
+
box-shadow: var(--shadow);
|
|
52
|
+
padding: 28px;
|
|
53
|
+
display: grid;
|
|
54
|
+
gap: 18px;
|
|
55
|
+
}
|
|
56
|
+
|
|
57
|
+
.eyebrow {
|
|
58
|
+
color: var(--brand);
|
|
59
|
+
font-size: 12px;
|
|
60
|
+
font-weight: 760;
|
|
61
|
+
letter-spacing: 0.08em;
|
|
62
|
+
text-transform: uppercase;
|
|
63
|
+
}
|
|
64
|
+
|
|
65
|
+
h1, h2, h3 { margin: 0; line-height: 1.15; }
|
|
66
|
+
h1 { font-size: clamp(30px, 5vw, 52px); letter-spacing: 0; }
|
|
67
|
+
h2 { font-size: 22px; }
|
|
68
|
+
h3 { font-size: 16px; }
|
|
69
|
+
|
|
70
|
+
.summary {
|
|
71
|
+
display: grid;
|
|
72
|
+
grid-template-columns: repeat(4, minmax(0, 1fr));
|
|
73
|
+
gap: 12px;
|
|
74
|
+
}
|
|
75
|
+
|
|
76
|
+
.metric {
|
|
77
|
+
border: 1px solid var(--line);
|
|
78
|
+
border-radius: 12px;
|
|
79
|
+
background: var(--soft);
|
|
80
|
+
padding: 12px 14px;
|
|
81
|
+
min-height: 76px;
|
|
82
|
+
}
|
|
83
|
+
|
|
84
|
+
.metric span {
|
|
85
|
+
display: block;
|
|
86
|
+
color: var(--muted);
|
|
87
|
+
font-size: 12px;
|
|
88
|
+
margin-bottom: 6px;
|
|
89
|
+
}
|
|
90
|
+
|
|
91
|
+
.metric strong {
|
|
92
|
+
display: block;
|
|
93
|
+
font-size: 15px;
|
|
94
|
+
overflow-wrap: anywhere;
|
|
95
|
+
}
|
|
96
|
+
|
|
97
|
+
.layout {
|
|
98
|
+
display: grid;
|
|
99
|
+
grid-template-columns: 280px minmax(0, 1fr);
|
|
100
|
+
gap: 20px;
|
|
101
|
+
margin-top: 20px;
|
|
102
|
+
align-items: start;
|
|
103
|
+
}
|
|
104
|
+
|
|
105
|
+
aside, .content-panel {
|
|
106
|
+
border: 1px solid var(--line);
|
|
107
|
+
border-radius: 16px;
|
|
108
|
+
background: rgba(255, 255, 255, 0.92);
|
|
109
|
+
box-shadow: var(--shadow);
|
|
110
|
+
}
|
|
111
|
+
|
|
112
|
+
aside {
|
|
113
|
+
padding: 18px;
|
|
114
|
+
position: sticky;
|
|
115
|
+
top: 18px;
|
|
116
|
+
}
|
|
117
|
+
|
|
118
|
+
.toc {
|
|
119
|
+
list-style: none;
|
|
120
|
+
padding: 0;
|
|
121
|
+
margin: 14px 0 0;
|
|
122
|
+
display: grid;
|
|
123
|
+
gap: 8px;
|
|
124
|
+
}
|
|
125
|
+
|
|
126
|
+
.toc a {
|
|
127
|
+
display: block;
|
|
128
|
+
color: var(--ink);
|
|
129
|
+
text-decoration: none;
|
|
130
|
+
border: 1px solid var(--line);
|
|
131
|
+
border-radius: 10px;
|
|
132
|
+
padding: 9px 10px;
|
|
133
|
+
background: #fbfefd;
|
|
134
|
+
font-size: 14px;
|
|
135
|
+
}
|
|
136
|
+
|
|
137
|
+
.toc a:hover { border-color: var(--brand-2); color: var(--brand); }
|
|
138
|
+
|
|
139
|
+
.content-panel {
|
|
140
|
+
padding: 20px;
|
|
141
|
+
display: grid;
|
|
142
|
+
gap: 16px;
|
|
143
|
+
}
|
|
144
|
+
|
|
145
|
+
.task-block {
|
|
146
|
+
border: 1px solid var(--line);
|
|
147
|
+
border-radius: 14px;
|
|
148
|
+
overflow: hidden;
|
|
149
|
+
background: #fff;
|
|
150
|
+
}
|
|
151
|
+
|
|
152
|
+
.task-header {
|
|
153
|
+
display: flex;
|
|
154
|
+
justify-content: space-between;
|
|
155
|
+
gap: 14px;
|
|
156
|
+
align-items: flex-start;
|
|
157
|
+
padding: 16px 18px;
|
|
158
|
+
background: linear-gradient(90deg, rgba(8, 122, 90, 0.1), rgba(14, 165, 160, 0.04));
|
|
159
|
+
border-bottom: 1px solid var(--line);
|
|
160
|
+
}
|
|
161
|
+
|
|
162
|
+
.task-meta {
|
|
163
|
+
color: var(--muted);
|
|
164
|
+
font-size: 13px;
|
|
165
|
+
margin-top: 6px;
|
|
166
|
+
}
|
|
167
|
+
|
|
168
|
+
.status {
|
|
169
|
+
border-radius: 999px;
|
|
170
|
+
padding: 5px 10px;
|
|
171
|
+
background: #ecfdf5;
|
|
172
|
+
color: var(--brand);
|
|
173
|
+
border: 1px solid rgba(8, 122, 90, 0.22);
|
|
174
|
+
font-size: 12px;
|
|
175
|
+
font-weight: 720;
|
|
176
|
+
white-space: nowrap;
|
|
177
|
+
}
|
|
178
|
+
|
|
179
|
+
.notes {
|
|
180
|
+
padding: 16px;
|
|
181
|
+
display: grid;
|
|
182
|
+
gap: 12px;
|
|
183
|
+
}
|
|
184
|
+
|
|
185
|
+
.note {
|
|
186
|
+
border: 1px solid var(--line);
|
|
187
|
+
border-left: 5px solid var(--brand);
|
|
188
|
+
border-radius: 12px;
|
|
189
|
+
padding: 14px 14px 14px 16px;
|
|
190
|
+
background: #fbfefd;
|
|
191
|
+
display: grid;
|
|
192
|
+
gap: 10px;
|
|
193
|
+
}
|
|
194
|
+
|
|
195
|
+
.note.decision { border-left-color: var(--decision); }
|
|
196
|
+
.note.spec-gap { border-left-color: var(--spec-gap); }
|
|
197
|
+
.note.tradeoff { border-left-color: var(--tradeoff); }
|
|
198
|
+
.note.scope-escape { border-left-color: var(--scope); }
|
|
199
|
+
.note.risk { border-left-color: var(--risk); }
|
|
200
|
+
.note.verification { border-left-color: var(--verify); }
|
|
201
|
+
.note.codebase-reality { border-left-color: var(--codebase); }
|
|
202
|
+
.note.flash { border-left-color: var(--flash); }
|
|
203
|
+
|
|
204
|
+
.note-head {
|
|
205
|
+
display: flex;
|
|
206
|
+
justify-content: space-between;
|
|
207
|
+
gap: 10px;
|
|
208
|
+
align-items: center;
|
|
209
|
+
}
|
|
210
|
+
|
|
211
|
+
.badge {
|
|
212
|
+
display: inline-flex;
|
|
213
|
+
align-items: center;
|
|
214
|
+
border-radius: 999px;
|
|
215
|
+
padding: 4px 9px;
|
|
216
|
+
font-size: 12px;
|
|
217
|
+
font-weight: 780;
|
|
218
|
+
background: #eef7f3;
|
|
219
|
+
color: var(--brand);
|
|
220
|
+
border: 1px solid var(--line);
|
|
221
|
+
}
|
|
222
|
+
|
|
223
|
+
.note time {
|
|
224
|
+
color: var(--muted);
|
|
225
|
+
font-size: 12px;
|
|
226
|
+
}
|
|
227
|
+
|
|
228
|
+
.note p { margin: 0; }
|
|
229
|
+
|
|
230
|
+
.details {
|
|
231
|
+
display: grid;
|
|
232
|
+
grid-template-columns: repeat(2, minmax(0, 1fr));
|
|
233
|
+
gap: 10px;
|
|
234
|
+
}
|
|
235
|
+
|
|
236
|
+
.detail {
|
|
237
|
+
border-radius: 10px;
|
|
238
|
+
background: #f8fbfa;
|
|
239
|
+
border: 1px solid var(--line);
|
|
240
|
+
padding: 10px;
|
|
241
|
+
font-size: 13px;
|
|
242
|
+
}
|
|
243
|
+
|
|
244
|
+
.detail strong {
|
|
245
|
+
display: block;
|
|
246
|
+
color: var(--muted);
|
|
247
|
+
font-size: 11px;
|
|
248
|
+
text-transform: uppercase;
|
|
249
|
+
letter-spacing: 0.04em;
|
|
250
|
+
margin-bottom: 4px;
|
|
251
|
+
}
|
|
252
|
+
|
|
253
|
+
code {
|
|
254
|
+
font-family: "SFMono-Regular", Consolas, "Liberation Mono", monospace;
|
|
255
|
+
font-size: 0.92em;
|
|
256
|
+
background: #eef7f3;
|
|
257
|
+
border: 1px solid var(--line);
|
|
258
|
+
border-radius: 6px;
|
|
259
|
+
padding: 1px 5px;
|
|
260
|
+
}
|
|
261
|
+
|
|
262
|
+
.empty {
|
|
263
|
+
color: var(--muted);
|
|
264
|
+
border: 1px dashed var(--line);
|
|
265
|
+
border-radius: 12px;
|
|
266
|
+
padding: 18px;
|
|
267
|
+
background: #fbfefd;
|
|
268
|
+
}
|
|
269
|
+
|
|
270
|
+
@media (max-width: 860px) {
|
|
271
|
+
main { width: min(100% - 20px, 1120px); padding-top: 18px; }
|
|
272
|
+
.summary, .layout, .details { grid-template-columns: 1fr; }
|
|
273
|
+
aside { position: static; }
|
|
274
|
+
.task-header, .note-head { flex-direction: column; align-items: flex-start; }
|
|
275
|
+
}
|
|
276
|
+
</style>
|
|
277
|
+
</head>
|
|
278
|
+
<body>
|
|
279
|
+
<main>
|
|
280
|
+
<section class="hero">
|
|
281
|
+
<div class="eyebrow">CafeKit Implementation Notes</div>
|
|
282
|
+
<h1>{{FEATURE_NAME}}</h1>
|
|
283
|
+
<div class="summary">
|
|
284
|
+
<div class="metric"><span>Spec path</span><strong><code>{{SPEC_PATH}}</code></strong></div>
|
|
285
|
+
<div class="metric"><span>Mode</span><strong>{{MODE}}</strong></div>
|
|
286
|
+
<div class="metric"><span>Last updated</span><strong>{{UPDATED_AT}}</strong></div>
|
|
287
|
+
<div class="metric"><span>Verification</span><strong>{{VERIFICATION_STATUS}}</strong></div>
|
|
288
|
+
</div>
|
|
289
|
+
</section>
|
|
290
|
+
|
|
291
|
+
<div class="layout">
|
|
292
|
+
<aside>
|
|
293
|
+
<h2>Task Timeline</h2>
|
|
294
|
+
<ul class="toc">
|
|
295
|
+
<!-- TASK_TOC_START -->
|
|
296
|
+
<li><a href="#task-current">Current task</a></li>
|
|
297
|
+
<!-- TASK_TOC_END -->
|
|
298
|
+
</ul>
|
|
299
|
+
</aside>
|
|
300
|
+
|
|
301
|
+
<section class="content-panel">
|
|
302
|
+
<!-- NOTES_START -->
|
|
303
|
+
<article class="task-block" id="task-current">
|
|
304
|
+
<div class="task-header">
|
|
305
|
+
<div>
|
|
306
|
+
<h2>Current Task</h2>
|
|
307
|
+
<div class="task-meta">Add task id, title, and active task file here.</div>
|
|
308
|
+
</div>
|
|
309
|
+
<span class="status">in_progress</span>
|
|
310
|
+
</div>
|
|
311
|
+
<div class="notes">
|
|
312
|
+
<div class="empty">No implementation decisions recorded yet.</div>
|
|
313
|
+
</div>
|
|
314
|
+
</article>
|
|
315
|
+
<!-- NOTES_END -->
|
|
316
|
+
</section>
|
|
317
|
+
</div>
|
|
318
|
+
</main>
|
|
319
|
+
</body>
|
|
320
|
+
</html>
|
|
@@ -8,6 +8,8 @@ Green tests are NOT enough. The gate requires four proofs:
|
|
|
8
8
|
3. Code quality review
|
|
9
9
|
4. Task evidence (completion criteria + runtime/artifact/reachability proof from the task file)
|
|
10
10
|
|
|
11
|
+
`--flash` is the explicit fast path. It bypasses this full gate and uses the Flash Gate defined below.
|
|
12
|
+
|
|
11
13
|
## Automation Semantics
|
|
12
14
|
|
|
13
15
|
- If the task names exact commands in `Evidence` (or `Task Test Plan & Verification Evidence` / legacy `Verification & Evidence`), those exact commands are mandatory and must run before any fallback repo defaults.
|
|
@@ -21,6 +23,29 @@ Green tests are NOT enough. The gate requires four proofs:
|
|
|
21
23
|
- Scope fidelity is mandatory: missing scoped behavior, extra unapproved behavior, or task output that exists only as orphaned/unreachable code is a review failure even when build/tests pass.
|
|
22
24
|
- Runtime-facing artifacts must be reachable from the real entrypoint/caller named by the task or the task-aware scout report.
|
|
23
25
|
|
|
26
|
+
## Flash Gate (`--flash`)
|
|
27
|
+
|
|
28
|
+
Use this only when `/hapo:develop ... --flash` is present.
|
|
29
|
+
|
|
30
|
+
- Skip dedicated test commands, E2E/browser/manual QA, full task evidence execution, test-runner delegation, and code-auditor retry loops.
|
|
31
|
+
- Do not report `Test PASS`, `Evidence PASS`, `Auto-Approved`, or `production-ready`.
|
|
32
|
+
- Still perform a scope sanity check against active task Completion Criteria.
|
|
33
|
+
- Still perform a reachability sanity check for runtime-facing files: imported, mounted, registered, routed, or invoked where applicable.
|
|
34
|
+
- Run a cheap compile/syntax/typecheck/build command only when available and expected to complete quickly without dependency install or external services.
|
|
35
|
+
- If the cheap preflight fails, return to implementation; do not sync.
|
|
36
|
+
- If the cheap preflight is unavailable or too slow, record `Preflight: skipped in --flash mode`.
|
|
37
|
+
- Sync only with receipt fields:
|
|
38
|
+
- `Mode: --flash`
|
|
39
|
+
- `Tests: skipped by user request`
|
|
40
|
+
- `Evidence: FLASH_UNVERIFIED`
|
|
41
|
+
- `Next verification: /hapo:test <feature>`
|
|
42
|
+
|
|
43
|
+
Terminal log:
|
|
44
|
+
|
|
45
|
+
```text
|
|
46
|
+
⚡ Step 4 Flash Gate: tests skipped by --flash; preflight=<pass|skipped>; evidence=FLASH_UNVERIFIED
|
|
47
|
+
```
|
|
48
|
+
|
|
24
49
|
## Quality Cycle
|
|
25
50
|
|
|
26
51
|
Maximum retry counter: **3 attempts**. Exceeding 3 triggers a collapse warning.
|
|
@@ -11,11 +11,11 @@ Kill bugs systematically. No guessing. Evidence first, fix second.
|
|
|
11
11
|
|
|
12
12
|
## Arguments
|
|
13
13
|
|
|
14
|
-
- `--quick` -
|
|
14
|
+
- `--quick` - Reduced-depth path for trivial issues (lint, type errors, syntax); still scout-first
|
|
15
15
|
- `--parallel` - Spawn multiple `god-developer` agents for independent issues
|
|
16
16
|
- `--from-debug` - Start from an existing `hapo:debug` report and validate its root-cause contract
|
|
17
17
|
|
|
18
|
-
Default:
|
|
18
|
+
Default: deterministic scout-first hotfix. There is no initial mode selection step.
|
|
19
19
|
|
|
20
20
|
<HARD-GATE>
|
|
21
21
|
Do NOT propose or implement fixes before completing Steps 1-2 (Scout + `hapo:debug` diagnosis).
|
|
@@ -23,9 +23,36 @@ Symptom fixes are FAILURE. Find the root cause first.
|
|
|
23
23
|
The exact root-cause contract is mandatory: symptom, reproduction, expected/actual, root cause file:line or config/env source, why now, evidence chain, blast radius.
|
|
24
24
|
The side-effect gate is mandatory before completion.
|
|
25
25
|
If 3+ fix attempts fail → STOP. Question the architecture. Discuss with user.
|
|
26
|
-
Exception: `--quick` mode
|
|
26
|
+
Exception: `--quick` mode only abbreviates depth; it never skips scout, pre-fix evidence, diagnosis, or before/after verification.
|
|
27
27
|
</HARD-GATE>
|
|
28
28
|
|
|
29
|
+
<HARD-GATE-SCOUT-FIRST>
|
|
30
|
+
Hotfix ALWAYS scouts before asking broad clarification questions, forming hypotheses, or changing files.
|
|
31
|
+
Collect these scout outputs first:
|
|
32
|
+
1. Project type, language(s), framework(s), and package/test runner from repo files.
|
|
33
|
+
2. Exact file(s) where the symptom surfaces and their direct callers/dependents.
|
|
34
|
+
3. Related tests covering the affected area.
|
|
35
|
+
4. Recent commits touching affected files: `git log --oneline -10 -- <affected-files>`.
|
|
36
|
+
5. Existing patterns/conventions for this kind of fix.
|
|
37
|
+
Then state a concise 3-6 bullet codebase-context summary before Step 2.
|
|
38
|
+
</HARD-GATE-SCOUT-FIRST>
|
|
39
|
+
|
|
40
|
+
<HARD-GATE-NO-SIDE-EFFECTS>
|
|
41
|
+
The fix is not done until Step 5 proves:
|
|
42
|
+
1. The original symptom no longer reproduces with the exact pre-fix command/user flow.
|
|
43
|
+
2. Modified files and transitively affected modules still pass relevant tests.
|
|
44
|
+
3. Blast-radius workflows have no business-logic regression.
|
|
45
|
+
4. No new lint/type/build errors were introduced.
|
|
46
|
+
5. Public contracts are unchanged unless intentionally called out: function signatures, exported types, response shapes, DB schemas, env vars.
|
|
47
|
+
|
|
48
|
+
If verification reveals a side effect or regression, STOP and present 2-4 concrete options to the user:
|
|
49
|
+
- Revert this fix and try a different root-cause angle.
|
|
50
|
+
- Narrow the fix scope to remove the regression.
|
|
51
|
+
- Keep the fix and update named dependent files/contracts.
|
|
52
|
+
- Accept the behavior change intentionally.
|
|
53
|
+
Do not silently patch around the regression.
|
|
54
|
+
</HARD-GATE-NO-SIDE-EFFECTS>
|
|
55
|
+
|
|
29
56
|
## Anti-Rationalization
|
|
30
57
|
|
|
31
58
|
| Thought | Reality |
|
|
@@ -35,6 +62,7 @@ Exception: `--quick` mode allows abbreviated scout→diagnose→fix for trivial
|
|
|
35
62
|
| "Just try changing X" | Random fixes waste time and create new bugs. Diagnose first. |
|
|
36
63
|
| "It's probably X" | "Probably" = guessing. Use structured diagnosis. |
|
|
37
64
|
| "One more fix attempt" (after 2+) | 3+ failures = wrong approach. Question architecture. |
|
|
65
|
+
| "Quick mode means skip process" | Quick mode only reduces depth. Scout, diagnosis, and before/after proof remain mandatory. |
|
|
38
66
|
|
|
39
67
|
## Process Flow
|
|
40
68
|
|
|
@@ -43,7 +71,7 @@ flowchart TD
|
|
|
43
71
|
A[Issue Input] --> B[Step 1: Scout via hapo:inspect]
|
|
44
72
|
B --> C[Step 2: Diagnose via hapo:debug]
|
|
45
73
|
C --> D[Step 3: Classify Complexity]
|
|
46
|
-
D -->|Trivial| E[Quick Fix]
|
|
74
|
+
D -->|Trivial| E[Quick Fix after scout+diagnose]
|
|
47
75
|
D -->|Standard| F[Standard Fix]
|
|
48
76
|
D -->|Complex| G[Deep Fix + Subagents]
|
|
49
77
|
D -->|Multiple Issues| H[Parallel Fix]
|
|
@@ -70,17 +98,22 @@ flowchart TD
|
|
|
70
98
|
|
|
71
99
|
**Action:** Activate `hapo:inspect` skill to map the blast radius.
|
|
72
100
|
|
|
73
|
-
|
|
101
|
+
Do not ask generic questions before this step unless there is no repo, no error text, and no observable artifact to inspect.
|
|
102
|
+
|
|
103
|
+
| Path | Scout Depth |
|
|
74
104
|
|------|-------------|
|
|
75
|
-
| `--quick` | Minimal —
|
|
76
|
-
| Standard | Full —
|
|
105
|
+
| `--quick` | Minimal — project type, affected file(s), direct callers/dependents, related tests, recent commits |
|
|
106
|
+
| Standard | Full — project type, module boundaries, test coverage, call chains, recent changes, existing patterns |
|
|
77
107
|
| `--parallel` | Per-issue independent scouts |
|
|
78
108
|
|
|
79
109
|
**Checklist:**
|
|
110
|
+
- [ ] Project type, language, framework, package manager, and test runner identified
|
|
80
111
|
- [ ] Affected files identified
|
|
81
|
-
- [ ] Direct
|
|
112
|
+
- [ ] Direct callers/dependents mapped (imports/exports, route registrations, provider wiring, consumers)
|
|
82
113
|
- [ ] Related tests located
|
|
83
114
|
- [ ] Recent git changes checked: `git log --oneline -10 -- <affected-files>`
|
|
115
|
+
- [ ] Existing local patterns for this code path identified
|
|
116
|
+
- [ ] 3-6 bullet codebase-context summary reported before diagnosis
|
|
84
117
|
|
|
85
118
|
**Output:** `✓ Step 1: Scouted — [N] files mapped, [M] dependencies, [K] tests found`
|
|
86
119
|
|
|
@@ -115,6 +148,8 @@ Use `hapo:debug` or validate an existing debug report when `--from-debug` is pro
|
|
|
115
148
|
- Evidence chain: observations proving the cause
|
|
116
149
|
- Blast radius: affected files, modules, tests, users, workflows, or release paths
|
|
117
150
|
|
|
151
|
+
If any field is vague (`probably`, `maybe`, `I think`, or missing file:line/config/env evidence), keep diagnosing or ask the user for the specific missing artifact. Do not implement.
|
|
152
|
+
|
|
118
153
|
**Output:** `✓ Step 2: Diagnosed — Root cause: [summary], Evidence: [brief], Scope: [N files]`
|
|
119
154
|
|
|
120
155
|
---
|
|
@@ -131,6 +166,7 @@ Use `hapo:debug` or validate an existing debug report when `--from-debug` is pro
|
|
|
131
166
|
**Task Orchestration (Standard+ only):**
|
|
132
167
|
- Use `TaskCreate` with dependencies to track fix phases
|
|
133
168
|
- Skip for Trivial (overhead exceeds benefit)
|
|
169
|
+
- If `TaskCreate` / `TaskUpdate` are unavailable, use a concise markdown checklist or `TodoWrite` fallback. Do not block the hotfix because structured task tools are missing.
|
|
134
170
|
|
|
135
171
|
**Output:** `✓ Step 3: [Complexity] detected — [workflow] selected`
|
|
136
172
|
|
|
@@ -144,8 +180,9 @@ Use `hapo:debug` or validate an existing debug report when `--from-debug` is pro
|
|
|
144
180
|
- One logical change per commit boundary.
|
|
145
181
|
|
|
146
182
|
### Quick Workflow
|
|
147
|
-
1. Apply the
|
|
148
|
-
2. Run typecheck/lint immediately
|
|
183
|
+
1. Apply the minimal fix directly from completed scout + diagnosis
|
|
184
|
+
2. Run exact pre-fix command plus typecheck/lint immediately
|
|
185
|
+
3. Report before/after proof
|
|
149
186
|
|
|
150
187
|
### Standard Workflow
|
|
151
188
|
1. Implement fix targeting root cause
|
|
@@ -178,20 +215,27 @@ Use `hapo:debug` or validate an existing debug report when `--from-debug` is pro
|
|
|
178
215
|
2. **Regression test:** The test MUST fail without the fix and pass with it.
|
|
179
216
|
3. **Parallel verification:** Run typecheck + lint + build + test simultaneously via `Bash`. See `references/parallel-patterns.md` Pattern C.
|
|
180
217
|
4. **Prevention guard (Standard+ only):** See `references/prevention-gate.md`.
|
|
181
|
-
5. **Side-effect gate:**
|
|
182
|
-
|
|
218
|
+
5. **Side-effect gate:** Sweep the full blast radius identified in Step 2:
|
|
219
|
+
- Modified files and direct dependents pass relevant tests
|
|
220
|
+
- Affected user/API/CLI workflows still work
|
|
221
|
+
- Public contracts unchanged unless intentionally called out
|
|
222
|
+
- No new lint/type/build errors
|
|
223
|
+
6. **Code review:** Trigger `hapo:code-review`; never auto-approve blocking security, auth, data-loss, resource-exhaustion, or public-contract issues.
|
|
183
224
|
|
|
184
225
|
**If verification fails:**
|
|
185
226
|
- < 3 attempts → Loop back to Step 2 (re-diagnose with new evidence)
|
|
186
227
|
- 3+ attempts → STOP. Question architecture. Discuss with user.
|
|
187
228
|
|
|
229
|
+
**If a side effect appears:**
|
|
230
|
+
- STOP and present concrete options to the user. Do not silently broaden the fix.
|
|
231
|
+
|
|
188
232
|
**Output:** `✓ Step 5: Verified + Prevented — [before/after comparison], [N] tests added`
|
|
189
233
|
|
|
190
234
|
---
|
|
191
235
|
|
|
192
236
|
## Step 6: Finalize (MANDATORY — never skip)
|
|
193
237
|
|
|
194
|
-
1. **Report:** Confidence score, root cause, changes made, files affected, prevention measures
|
|
238
|
+
1. **Report:** Confidence score, root cause, changes made, files affected, prevention measures, side-effect sweep result
|
|
195
239
|
2. **Docs update:** If API/behavior changed → delegate to `docs-keeper` subagent
|
|
196
240
|
3. **Task cleanup:** `TaskUpdate` → mark all tasks `completed` (skip if no tasks created)
|
|
197
241
|
4. **Commit:** Ask user if ready to commit via `git-ops` subagent
|
|
@@ -227,16 +271,23 @@ Unified step markers (emit after each step):
|
|
|
227
271
|
| `docs-keeper` | Update docs if behavior changed (Step 6) |
|
|
228
272
|
| `god-developer` | Parallel independent issues (each gets own agent) |
|
|
229
273
|
|
|
274
|
+
## Specialized Paths
|
|
275
|
+
|
|
276
|
+
Use `references/workflow-specialized.md` as an overlay after Step 1 scout:
|
|
277
|
+
- CI/CD failures
|
|
278
|
+
- Test suite failures
|
|
279
|
+
- TypeScript type errors
|
|
280
|
+
- UI / visual issues
|
|
281
|
+
- Application log errors
|
|
282
|
+
|
|
283
|
+
Specialized paths do not replace the 6-step hotfix process.
|
|
284
|
+
|
|
230
285
|
## References
|
|
231
286
|
|
|
232
287
|
Load as needed:
|
|
233
288
|
- `references/diagnosis-protocol.md` — Structured root cause analysis methodology
|
|
234
289
|
- `references/escalation-tactics.md` — What to do when hypotheses fail (Inversion, Scale Game)
|
|
235
290
|
- `references/prevention-gate.md` — Defense-in-depth validation after fix
|
|
236
|
-
- `references/review-cycle.md` —
|
|
291
|
+
- `references/review-cycle.md` — Review handling and required user-pause conditions
|
|
237
292
|
- `references/parallel-patterns.md` — Parallel Explore/Bash/Task coordination with code templates
|
|
238
293
|
- `references/workflow-specialized.md` — CI/CD, test, TypeScript, UI-specific workflows
|
|
239
|
-
- `references/debugger/frontend-verification.md` — Browser/UI evidence and visual verification
|
|
240
|
-
- `references/debugger/performance-diagnostics.md` — Baseline-driven performance diagnosis
|
|
241
|
-
- `references/debugger/condition-based-waiting.md` — Flaky async test diagnosis
|
|
242
|
-
- `references/debugger/side-effect-gate.md` — Regression and blast-radius sweep
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
# Prevention Gate
|
|
2
2
|
|
|
3
|
-
After a fix is verified, apply defense-in-depth to prevent the same bug class from recurring. Prevention is not the same as side-effect safety; run
|
|
3
|
+
After a fix is verified, apply defense-in-depth to prevent the same bug class from recurring. Prevention is not the same as side-effect safety; run the Step 5 side-effect sweep in `../SKILL.md` before claiming completion.
|
|
4
4
|
|
|
5
5
|
## Mandatory Prevention Checklist
|
|
6
6
|
|
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
|
|
3
3
|
How to handle code review results after a fix is implemented. Ensures quality without unnecessary friction.
|
|
4
4
|
|
|
5
|
-
##
|
|
5
|
+
## Default Review Handling
|
|
6
6
|
|
|
7
7
|
The agent reviews its own fix using `hapo:code-review` and decides automatically:
|
|
8
8
|
|
|
@@ -32,9 +32,9 @@ LOOP:
|
|
|
32
32
|
→ Proceed to Step 6
|
|
33
33
|
```
|
|
34
34
|
|
|
35
|
-
##
|
|
35
|
+
## Required User Pause
|
|
36
36
|
|
|
37
|
-
When the fix touches production-critical code or the user explicitly requests review control:
|
|
37
|
+
When the fix touches production-critical code, changes public contracts, introduces a behavior change, or the user explicitly requests review control:
|
|
38
38
|
|
|
39
39
|
1. Run `hapo:code-review` → collect score + findings
|
|
40
40
|
2. Present a structured summary to user:
|
|
@@ -52,15 +52,15 @@ When the fix touches production-critical code or the user explicitly requests re
|
|
|
52
52
|
- If no critical issues → "Approve" | "Address warnings" | "Abort"
|
|
53
53
|
4. Execute user's choice. Max 3 remediation cycles.
|
|
54
54
|
|
|
55
|
-
## When
|
|
55
|
+
## When To Pause vs Continue
|
|
56
56
|
|
|
57
57
|
| Situation | Mode |
|
|
58
58
|
|-----------|------|
|
|
59
|
-
| Type errors, lint, syntax fixes |
|
|
60
|
-
| Single-file logic bugs |
|
|
61
|
-
| Multi-file changes touching auth/payments/data |
|
|
62
|
-
| Architecture-impacting changes |
|
|
63
|
-
| User said "review with me" or similar |
|
|
59
|
+
| Type errors, lint, syntax fixes | Continue after passing verification |
|
|
60
|
+
| Single-file logic bugs | Continue after passing verification |
|
|
61
|
+
| Multi-file changes touching auth/payments/data | Pause recommended |
|
|
62
|
+
| Architecture-impacting changes | Pause required |
|
|
63
|
+
| User said "review with me" or similar | Pause required |
|
|
64
64
|
|
|
65
65
|
## Blocking Issues (Never Auto-Approve)
|
|
66
66
|
|
|
@@ -27,7 +27,7 @@ When unit/integration/e2e tests are failing:
|
|
|
27
27
|
2. **Check for pollution:** Does it pass alone but fail in suite? → Test order dependency or shared state leaking
|
|
28
28
|
3. **Check for staleness:** Did the implementation change but the test assertions were not updated?
|
|
29
29
|
4. **Snapshot drift:** If snapshot tests fail, review the diff carefully — is it an intentional change or a regression?
|
|
30
|
-
5. **Flaky async:** Replace arbitrary sleeps with condition-based waits
|
|
30
|
+
5. **Flaky async:** Replace arbitrary sleeps with condition-based waits: wait for observable state, DOM condition, network completion, queue drain, or explicit event instead of fixed timeouts.
|
|
31
31
|
|
|
32
32
|
---
|
|
33
33
|
|
|
@@ -52,7 +52,7 @@ When the interface is broken, misaligned, or not rendering:
|
|
|
52
52
|
1. **Capture visual evidence:** Use `pushd skills/chrome-devtools/scripts && node screenshot.js --url <url> && popd`
|
|
53
53
|
2. **Check ARIA structure:** `pushd skills/chrome-devtools/scripts && node aria-snapshot.js --url <url> && popd` — reveals hidden overlays, z-index battles
|
|
54
54
|
3. **Check console errors:** `pushd skills/chrome-devtools/scripts && node console.js --url <url> && popd` — catches JS crashes preventing render
|
|
55
|
-
4. **Run frontend verification:**
|
|
55
|
+
4. **Run frontend verification:** collect screenshot, console, network, accessibility, responsive, and interaction evidence before/after the fix.
|
|
56
56
|
5. **Common traps:**
|
|
57
57
|
- CSS specificity wars (use browser DevTools or ARIA snapshot to verify computed styles)
|
|
58
58
|
- Hydration mismatch in SSR frameworks (server HTML differs from client render)
|