kenaz 0.3.17 → 0.3.19

package/core/.claude/commands/product-review.md

@@ -1,131 +0,0 @@
-# /product-review - Automated Project Review Mode (English alias)
-
-> This is an English alias for `/產品檢視` to avoid PowerShell encoding issues.
-
-## Purpose
-This command is used for automated self-enhancement iteration. When all development tasks are completed, this command is automatically called to review the project status and decide the next step.
-
-## Execution Steps
-
-Please execute the project review analysis according to the following steps:
-
-### 1. Read Required Files
-- Read `.claude/skills/product_manager/SKILL.md` to adopt the Product Manager role
-- Read `dev/PRODUCT_SPEC.md` to understand product specifications (if not exists, read `dev/PRODUCT_SPEC_FOR_AI_template.md`)
-- Read `dev/pipeline/PROGRESS.md` to understand current progress
-- List `dev/pipeline/completed/` directory to understand completed tasks
-
-### 2. Project Gap Analysis
-Analyze based on the read information:
-1. **Feature Coverage**: Compare the feature requirements in PRODUCT_SPEC with completed tasks
-2. **Core Feature Check**: Confirm whether all P0/P1 core features have been implemented
-3. **Test Coverage**: Check if there are sufficient test tasks
-4. **Quality Check**: Whether QA verification or optimization tasks are needed
-
-### 3. Decision Output
-**Important Constraints**:
-- Must strictly follow PRODUCT_SPEC, cannot add features randomly
-- Only add features that are clearly defined in PRODUCT_SPEC but not yet implemented
-- Project completion criteria: All core features (P0/P1) in PRODUCT_SPEC have been implemented
-
-Based on the analysis results, make one of the following decisions:
-
-#### Decision A: Need to Continue Development
-If there are core features in PRODUCT_SPEC that have not been implemented:
-1. Create new tasks in `dev/pipeline/tasks/`
-2. Update `dev/pipeline/PROGRESS.md`
-3. Write status file:
-
-```json
-// dev/pipeline/SELF_ENHANCEMENT_STATUS.json
-{
-  "status": "continue",
-  "decision": "Add development tasks",
-  "reason": "There are unfinished core features in PRODUCT_SPEC: [list features]",
-  "new_tasks": ["TASK_XXX", "TASK_YYY"],
-  "timestamp": "ISO timestamp format"
-}
-```
-
-#### Decision B: Need Testing/QA
-If core features are implemented but lack testing:
-1. Create QA test tasks in `dev/pipeline/tasks/`
-2. Update `dev/pipeline/PROGRESS.md`
-3. Write status file:
-
-```json
-{
-  "status": "continue",
-  "decision": "Add testing tasks",
-  "reason": "Core features completed, quality verification needed",
-  "new_tasks": ["TASK_XXX_QA"],
-  "timestamp": "ISO timestamp format"
-}
-```
-
-#### Decision C: Project Completed
-If all core features in PRODUCT_SPEC are implemented with basic testing:
-1. Write status file:
-
-```json
-{
-  "status": "complete",
-  "decision": "Project completed",
-  "reason": "All core features (P0/P1) in PRODUCT_SPEC have been implemented, project has reached deliverable state",
-  "summary": {
-    "total_completed": number,
-    "core_features": ["list of completed core features"]
-  },
-  "timestamp": "ISO timestamp format"
-}
-```
-
-#### Decision D: Project Completed with Suggestions
-If PRODUCT_SPEC core features are completed, but AI identifies optimization opportunities or extensible features (outside PRODUCT_SPEC scope):
-1. **Do not automatically create tasks** (because they are outside PRODUCT_SPEC scope)
-2. Write status file, record suggestions for user reference:
-
-```json
-{
-  "status": "complete_with_suggestions",
-  "decision": "Project completed with optimization suggestions",
-  "reason": "PRODUCT_SPEC core features implemented, following are additional optimization suggestions",
-  "summary": {
-    "total_completed": number,
-    "core_features": ["list of completed core features"]
-  },
-  "suggestions": [
-    {
-      "type": "optimization/feature/enhancement",
-      "title": "Suggestion name",
-      "description": "Detailed description",
-      "priority": "P2/P3",
-      "effort": "low/medium/high"
-    }
-  ],
-  "next_action": "Suggest user evaluate and manually run /產品 to add requirements",
-  "timestamp": "ISO timestamp format"
-}
-```
-
-> **Note**: This decision is still considered "complete", scheduler will end. Suggestions are for user reference only and will not be automatically executed.
-
-### 4. Output Format
-After completion, output a brief summary:
-
-```
-========================================
-Project Review Analysis Complete
-========================================
-Decision: [continue/complete/complete_with_suggestions]
-Reason: [brief explanation]
-New Tasks: [if any]
-Optimization Suggestions: [if any, list count]
-========================================
-```
-
-## Notes
-- This command is designed for automated scheduling
-- No user interaction required, proceed directly with analysis and decision
-- Strictly follow PRODUCT_SPEC, cannot imagine new features
-- Status file `SELF_ENHANCEMENT_STATUS.json` is the key dependency for the scheduler script

package/core/.claude/commands/strategy.md

@@ -1,141 +0,0 @@
-# /strategy - 策略智庫團隊
-
-調用 Strategy Team 進行設計思考、方案討論、決策建議。
-
-## 用法
-
-```bash
-/strategy "您的問題或需求"
-```
-
-## 範例
-
-```bash
-# 架構決策
-/strategy "我們應該使用單體架構還是微服務架構？"
-
-# 技術選型
-/strategy "資料庫應該選擇 PostgreSQL 還是 MongoDB？"
-
-# 功能評估
-/strategy "這個 AI 助手功能值得開發嗎？需要投入多少資源？"
-
-# 方案設計
-/strategy "如何設計一個可擴展到千萬用戶的系統？"
-
-# 風險分析
-/strategy "重構代碼庫有哪些潛在風險？如何緩解？"
-```
-
-## 團隊特色
-
-- 🧠 **7 個專業成員**：產品、技術、UX、商業、創新、風險、策略
-- 💬 **成員互相討論**：就像真實的策略會議
-- 🤝 **與您互動**：主動提問、澄清需求
-- 📊 **方案對比**：提供 2-3 個可行方案
-- ⚖️ **權衡分析**：清楚說明每個方案的優缺點
-
-## 輸出
-
-1. **問題分析**
-2. **團隊討論摘要**（成員之間的對話）
-3. **2-3 個方案選項**
-4. **建議報告**（包含推薦方案與理由）
-5. **風險分析與緩解策略**
-6. **下一步行動計劃**
-
-## 執行時間
-
-- 人類預估：8-16 小時（策略會議 + 分析 + 報告）
-- Agent 預估：20-30 分鐘（AI 討論與分析）
-- 效率提升：約 30 倍
-
-## 調用邏輯
-
-當用戶執行 `/strategy` 時：
-
-1. 讀取 Strategy Agent Skill 定義
-2. 啟動策略分析流程
-3. 多視角獨立分析
-4. 向用戶提問（使用 AskUserQuestion）
-5. 設計 2-3 個方案
-6. 提出建議報告
-7. 記錄決策過程
-
-## 團隊成員
-
-| 成員 | 視角 | 關注點 |
-|------|------|--------|
-| Strategy Lead | 整合 | 協調、綜合、達成共識 |
-| Product Strategist | 產品 | 用戶價值、功能優先級 |
-| Technical Architect | 技術 | 可行性、架構設計 |
-| UX Strategist | UX | 用戶體驗、交互設計 |
-| Business Analyst | 商業 | ROI、成本效益 |
-| Innovation Specialist | 創新 | 新技術、突破性方案 |
-| Risk Analyst | 風險 | 風險識別、緩解策略 |
-
-## 適用場景
-
-✅ **推薦使用**：
-- 面對複雜決策（架構、技術選型）
-- 需要多視角分析
-- 需要評估商業價值
-- 需要風險分析
-- 需要創新方案
-
-❌ **不推薦使用**：
-- 已有明確方案（直接用執行團隊）
-- 簡單 Bug 修復
-- 緊急問題（需要快速響應）
-- 日常維護工作
-
-## 與其他團隊的區別
-
-| 特性 | Strategy Team | Developer/Backend Team |
-|------|---------------|----------------------|
-| 職責 | 設計思考、方案建議 | 代碼實現、功能開發 |
-| 輸出 | 建議報告、方案文檔 | 代碼、Git commits |
-| 時間 | 20-30 分鐘 | 5-15 分鐘 |
-| 價值 | 決策支援、風險規避 | 快速執行、交付功能 |
-
-## 範例輸出
-
-```markdown
-# 建議報告：資料庫選型
-
-## Executive Summary
-建議使用 PostgreSQL + Redis 組合方案，平衡性能、可擴展性與成本。
-
-## Options
-
-### 選項 1：PostgreSQL + Redis（推薦）⭐
-優點：成熟穩定、團隊熟悉、成本可控
-缺點：垂直擴展有上限
-ROI：高
-
-### 選項 2：MongoDB + ElasticSearch
-優點：水平擴展能力強
-缺點：學習成本高、複雜查詢較弱
-ROI：中
-
-### 選項 3：Supabase（雲原生）
-優點：運維成本低、快速上線
-缺點：雲服務依賴、長期成本高
-ROI：中
-
-## Recommendation
-推薦選項 1，理由：
-1. 符合團隊技能
-2. 可擴展到千萬級
-3. 成本最優
-
-## Next Steps
-1. 建立 PostgreSQL PoC
-2. 設計 Schema
-3. 建立監控策略
-```
-
----
-
-**建立日期**: 2026-02-09
-**適用版本**: Claude Code v1.0+

package/core/.claude/commands/sunny.md

@@ -1 +0,0 @@
-讀取並遵循 `.claude/skills/sunny/SKILL.md` 中的指示。

package/core/.claude/commands//347/224/242/345/223/201/346/252/242/350/246/226.md

@@ -1,129 +0,0 @@
-# /產品檢視 - 自動化專案檢視模式
-
-## 用途
-此指令用於自動化排程的自我增強迭代。當所有開發任務完成後，自動呼叫此指令檢視專案狀態並決定下一步。
-
-## 執行步驟
-
-請按照以下步驟執行專案檢視分析：
-
-### 1. 讀取必要文件
-- 讀取 `.claude/skills/product_manager/SKILL.md` 採用產品經理角色
-- 讀取 `dev/PRODUCT_SPEC.md` 了解產品規格（若不存在則讀取 `dev/PRODUCT_SPEC_FOR_AI_template.md`）
-- 讀取 `dev/pipeline/PROGRESS.md` 了解目前進度
-- 列出 `dev/pipeline/completed/` 目錄了解已完成任務
-
-### 2. 專案差距分析
-根據讀取的資訊進行分析：
-1. **功能覆蓋率**：比對 PRODUCT_SPEC 中的功能需求與已完成任務
-2. **核心功能檢查**：確認 P0/P1 核心功能是否都已實現
-3. **測試覆蓋**：檢查是否有足夠的測試任務
-4. **品質檢查**：是否需要 QA 驗證或優化任務
-
-### 3. 決策輸出
-**重要限制**：
-- 必須緊貼 PRODUCT_SPEC，不可天馬行空新增功能
-- 只新增 PRODUCT_SPEC 中明確定義但尚未實現的功能
-- 專案完成標準：PRODUCT_SPEC 中所有核心功能 (P0/P1) 已實現
-
-根據分析結果，做出以下決策之一：
-
-#### 決策 A：需要繼續開發
-如果 PRODUCT_SPEC 中有尚未實現的核心功能：
-1. 在 `dev/pipeline/tasks/` 建立新任務
-2. 更新 `dev/pipeline/PROGRESS.md`
-3. 寫入狀態文件：
-
-```json
-// dev/pipeline/SELF_ENHANCEMENT_STATUS.json
-{
-  "status": "continue",
-  "decision": "新增開發任務",
-  "reason": "PRODUCT_SPEC 中尚有未完成的核心功能：[列出功能]",
-  "new_tasks": ["TASK_XXX", "TASK_YYY"],
-  "timestamp": "ISO 時間格式"
-}
-```
-
-#### 決策 B：需要測試/QA
-如果核心功能已實現但缺乏測試：
-1. 在 `dev/pipeline/tasks/` 建立 QA 測試任務
-2. 更新 `dev/pipeline/PROGRESS.md`
-3. 寫入狀態文件：
-
-```json
-{
-  "status": "continue",
-  "decision": "新增測試任務",
-  "reason": "核心功能已完成，需要進行品質驗證",
-  "new_tasks": ["TASK_XXX_QA"],
-  "timestamp": "ISO 時間格式"
-}
-```
-
-#### 決策 C：專案已完成
-如果 PRODUCT_SPEC 中所有核心功能已實現且有基本測試：
-1. 寫入狀態文件：
-
-```json
-{
-  "status": "complete",
-  "decision": "專案已完成",
-  "reason": "PRODUCT_SPEC 中所有核心功能 (P0/P1) 已實現，專案達到可交付狀態",
-  "summary": {
-    "total_completed": 數字,
-    "core_features": ["已完成的核心功能列表"]
-  },
-  "timestamp": "ISO 時間格式"
-}
-```
-
-#### 決策 D：專案已完成但有優化建議
-如果 PRODUCT_SPEC 核心功能已完成，但 AI 判斷有優化空間或可延伸的功能（不在 PRODUCT_SPEC 範圍內）：
-1. **不自動建立任務**（因為超出 PRODUCT_SPEC 範圍）
-2. 寫入狀態文件，記錄建議供用戶參考：
-
-```json
-{
-  "status": "complete_with_suggestions",
-  "decision": "專案已完成，有優化建議",
-  "reason": "PRODUCT_SPEC 核心功能已實現，以下為額外優化建議",
-  "summary": {
-    "total_completed": 數字,
-    "core_features": ["已完成的核心功能列表"]
-  },
-  "suggestions": [
-    {
-      "type": "optimization/feature/enhancement",
-      "title": "建議名稱",
-      "description": "詳細說明",
-      "priority": "P2/P3",
-      "effort": "low/medium/high"
-    }
-  ],
-  "next_action": "建議用戶評估後，可手動執行 /產品 新增需求",
-  "timestamp": "ISO 時間格式"
-}
-```
-
-> **注意**：此決策仍視為「完成」，排程將結束。建議內容僅供用戶參考，不會自動執行。
-
-### 4. 輸出格式
-執行完成後，輸出簡短摘要：
-
-```
-========================================
-專案檢視分析完成
-========================================
-決策：[continue/complete/complete_with_suggestions]
-原因：[簡短說明]
-新增任務：[如有]
-優化建議：[如有，列出建議數量]
-========================================
-```
-
-## 注意事項
-- 此指令專為自動化排程設計
-- 不需要與用戶互動，直接進行分析和決策
-- 嚴格遵循 PRODUCT_SPEC，不可自行發想新功能
-- 狀態文件 `SELF_ENHANCEMENT_STATUS.json` 是排程腳本的關鍵依據

package/core/.claude/commands//351/200/262/345/272/246.md

@@ -1,15 +0,0 @@
-# /進度 - 查看 Pipeline 開發進度
-
-正在讀取開發進度...
-
-請執行以下操作：
-
-1. 讀取 `dev/pipeline/PROGRESS.md` 文件內容
-2. 以清晰的格式顯示：
-   - 當前執行中的任務
-   - 待處理任務佇列
-   - 已完成任務列表
-   - 整體進度統計
-3. 如有阻塞項目，特別標註
-
-請顯示當前 Pipeline 開發進度。

package/core/.claude/hooks/__tests__/substrate.test.js

@@ -1,122 +0,0 @@
-#!/usr/bin/env node
-/**
- * Smoke tests for substrate-path detection (TASK_1434; TASK_2335 dropped the pulse-before-* hooks).
- *
- * Run: node .claude/hooks/__tests__/substrate.test.js
- *
- * Hooks are exercised through the one remaining hook that consumes substrate paths.
- * Hooks are spawned as child processes with mock JSON stdin — no server needed
- * (Dashboard offline → hooks fall through to deterministic non-server logic).
- */
-'use strict';
-
-const assert = require('assert');
-const { execSync } = require('child_process');
-const fs = require('fs');
-const path = require('path');
-
-const HOOKS_DIR = path.join(__dirname, '..');
-let passed = 0;
-let failed = 0;
-
-function ok(label, val) {
-  if (val) {
-    console.log(`  ✓ ${label}`);
-    passed++;
-  } else {
-    console.error(`  ✗ ${label}`);
-    failed++;
-  }
-}
-
-// ---------------------------------------------------------------------------
-// Shared helper: spawn a hook with JSON stdin, return parsed stdout JSON
-// ---------------------------------------------------------------------------
-function runHook(hookFile, jsonInput, envOverrides = {}) {
-  const hookPath = path.join(HOOKS_DIR, hookFile);
-  const env = { ...process.env, ...envOverrides };
-  // Clear advisory mode by default so we get 'ask' on substrate
-  if (!('ANSUZ_HOOK_MODE' in envOverrides)) {
-    delete env.ANSUZ_HOOK_MODE;
-  }
-  const result = execSync(`node "${hookPath}"`, {
-    input: JSON.stringify(jsonInput),
-    timeout: 6000,
-    env,
-  });
-  return JSON.parse(result.toString());
-}
-
-// ---------------------------------------------------------------------------
-// 1. _substrate-paths.js — SUBSTRATE_PATH_RE and isSubstratePath
-// ---------------------------------------------------------------------------
-console.log('\n--- _substrate-paths.js ---');
-const { isSubstratePath } = require('../_substrate-paths');
-
-// substrate triggers
-ok('.claude/agents/test.md → substrate',      isSubstratePath('.claude/agents/test.md'));
-ok('.claude/hooks/turn-context.js → substrate', isSubstratePath('.claude/hooks/turn-context.js'));
-ok('.specialist/Ansuz/ → substrate',           isSubstratePath('.specialist/Ansuz/'));
-ok('.specialist/Ansuz/concepts/c.yaml → substrate', isSubstratePath('.specialist/Ansuz/concepts/c.yaml'));
-ok('.specialist/Ansuz/phases/p0.yaml → substrate',  isSubstratePath('.specialist/Ansuz/phases/p0.yaml'));
-ok('.specialist/Ansuz/guards/L-005.yaml → substrate', isSubstratePath('.specialist/Ansuz/guards/L-005.yaml'));
-ok('.specialist/Ansuz/elixir.yaml → substrate', isSubstratePath('.specialist/Ansuz/elixir.yaml'));
-ok('.rule/general/synapse.yaml → substrate',   isSubstratePath('.rule/general/synapse.yaml'));
-ok('.failure/FAIL-001.yaml → substrate',       isSubstratePath('.failure/FAIL-001.yaml'));
-
-// non-substrate
-ok('src/foo.ts → NOT substrate',              !isSubstratePath('src/foo.ts'));
-ok('dashboard/build/ → NOT substrate',        !isSubstratePath('dashboard/build/'));
-ok('.claude/settings.json → NOT substrate',   !isSubstratePath('.claude/settings.json'));
-ok('null → NOT substrate',                    !isSubstratePath(null));
-ok('empty → NOT substrate',                   !isSubstratePath(''));
-
-// ---------------------------------------------------------------------------
-// 4. synapse-first-investigation.js
-// ---------------------------------------------------------------------------
-console.log('\n--- synapse-first-investigation.js ---');
-
-// Helper: parse additionalContext from investigation hook output
-// Isolated project dir: the hook's 5-minute same-command dedupe reads the
-// project's telemetry file, so running this suite twice within 5 minutes
-// against the real repo silenced the ls nudges and failed the asserts.
-const INVESTIGATION_PROJ = fs.mkdtempSync(path.join(require('os').tmpdir(), 'substrate-nudge-'));
-fs.mkdirSync(path.join(INVESTIGATION_PROJ, '.kenaz', 'specialist'), { recursive: true });
-fs.writeFileSync(path.join(INVESTIGATION_PROJ, '.kenaz', 'project.yaml'), 'name: substrate-fixture\n');
-function runInvestigationHook(cmd) {
-  const input = { toolInput: { command: cmd } };
-  return runHook('synapse-first-investigation.js', input, { CLAUDE_PROJECT_DIR: INVESTIGATION_PROJ });
-}
-
-// 4a. ls -la .specialist/Ansuz/ → NO nudge (the substrate/pulse nudge is gone)
-const lsSubstrateResult = runInvestigationHook('ls -la .specialist/Ansuz/');
-ok('ls .specialist/Ansuz/ → no nudge',
-  !lsSubstrateResult.hookSpecificOutput.additionalContext);
-
-// 4b. ls -la dashboard/build/ → NO nudge
-const lsNonSubstrateResult = runInvestigationHook('ls -la dashboard/build/');
-ok('ls dashboard/build/ → NO nudge',
-  !lsNonSubstrateResult.hookSpecificOutput.additionalContext);
-
-// 4c. cat .specialist/Ansuz/elixir.yaml → NO nudge (2026-09-23: reading a file
-//     you already chose is not investigation; pulse cannot replace its content)
-const catSubstrateResult = runInvestigationHook('cat .specialist/Ansuz/elixir.yaml');
-ok('cat substrate file → no nudge',
-  !catSubstrateResult.hookSpecificOutput.additionalContext);
-
-// 4d. A symbol grep over source → LSP nudge (kenaz_lsp_*), no removed tool names
-const grepSymbolResult = runInvestigationHook('grep -rn "resolveBootPolicy" .formation/');
-const grepAdditional = grepSymbolResult.hookSpecificOutput.additionalContext || '';
-ok('symbol grep → LSP nudge mentions kenaz_lsp_references',
-  grepAdditional.includes('kenaz_lsp_references') && !/synapse_(pulse|search|context|impact)/.test(grepAdditional));
-
-// ---------------------------------------------------------------------------
-// Summary
-// ---------------------------------------------------------------------------
-console.log(`\n${'─'.repeat(48)}`);
-console.log(`Passed: ${passed}  Failed: ${failed}`);
-if (failed > 0) {
-  process.exit(1);
-} else {
-  console.log('✓ All substrate hook tests passed');
-}

package/core/.claude/hooks/_substrate-paths.js

@@ -1,95 +0,0 @@
-#!/usr/bin/env node
-'use strict';
-
-/**
- * Shared substrate path definitions for Claude Code hooks.
- *
- * "Substrate" = specialist behavior-critical files. Edits/reads of these
- * paths reshape Ansuz/specialist reflex behavior and MUST trigger a pulse
- * reminder regardless of SKIP_PATTERNS (which treats .yaml/.md/.json as
- * non-source config).
- *
- * Matched paths:
- *   .claude/agents/**      — agent definitions
- *   .claude/hooks/**       — hook scripts (this directory)
- *   .specialist/{name}/**  — all specialist files (concepts, phases, guards,
- *                            elixir/kernel/skill yaml, tools)
- *   .rule/**               — rule library (highest-priority rules)
- *   .failure/**            — failure learning system
- *
- * Note: .specialist/{name}/ root (any depth) is included because listing or
- * modifying the specialist directory directly is substrate investigation.
- * This means .specialist/Ansuz/tools/session.js also triggers — intentional,
- * as session.js drives core Ansuz behavior.
- *
- * Worktree awareness (TASK_1762, layout updated in TASK_1777):
- * Worktrees live at <repoParent>/.kenaz-worktrees/<repoName>/wt-<id>/
- * (legacy pre-TASK_1777 layout: <repo>/.formation/worktrees/wt-<id>/). When a worktree-
- * isolated agent edits a file inside its own worktree (e.g.
- * /repo/.formation/worktrees/wt-abc/.specialist/tools/session.js), the
- * absolute path contains a worktree-prefix segment before the substrate
- * pattern. This must NOT be treated as main-repo substrate — the agent is
- * editing its own workspace. Strip the worktree prefix before matching.
- */
-const SUBSTRATE_PATH_RE =
-  /(?:^|\/)(?:\.claude\/(?:agents|hooks)\/|\.specialist(?:\/[^/]+)?\/|\.rule\/|\.failure\/)/;
-
-/**
- * Worktree prefix pattern (applied to forward-slash-normalized paths).
- * Matches the portion of a path up to and including the worktree directory.
- * Two layouts (TASK_1777):
- *   - sibling (current): `/parent/.kenaz-worktrees/<repoName>/wt-abc123-456/`
- *   - legacy in-repo:    `/repo/.formation/worktrees/wt-abc123-456/`
- * Relative forms (`.kenaz-worktrees/<name>/wt-…/`, `.formation/worktrees/wt-…/`) also match.
- *
- * The `wt-` prefix is enforced by worktree-create.js (makeWtName), so this
- * pattern reliably identifies worktree-internal paths.
- *
- * Design: uses `(?:^|/)` so it matches both:
- *   - absolute: `/repo/.formation/worktrees/wt-xxx/…`
- *   - relative: `.formation/worktrees/wt-xxx/…`
- */
-const WORKTREE_PREFIX_RE = /(?:^|\/)(?:\.formation\/worktrees|\.kenaz-worktrees\/[^/]+)\/(wt-[^/]+)\//;
-
-/**
- * Strip the worktree prefix from a forward-slash-normalized path if present,
- * leaving only the repo-relative portion. Returns the original path unchanged
- * if it is not a worktree-internal path.
- *
- * Example:
- *   /repo/.formation/worktrees/wt-abc/.specialist/tools/session.js
- *   → .specialist/tools/session.js
- */
-function stripWorktreePrefix(filePath) {
-  const normalized = filePath.replace(/\\/g, '/');
-  const m = normalized.match(WORKTREE_PREFIX_RE);
-  if (!m) return normalized;
-  // m.index = position of the leading separator (or 0 for relative path)
-  // m[0] = the full matched segment including the trailing /
-  return normalized.slice(m.index + m[0].length);
-}
-
-function isSubstratePath(filePath) {
-  if (!filePath) return false;
-  const normalized = filePath.replace(/\\/g, '/');
-  // Worktree-internal paths are NEVER main-repo substrate (TASK_1762).
-  // When a worktree-isolated agent edits files inside its own worktree
-  // (even files like .specialist/tools/session.js), those are the agent's
-  // own workspace — not the main repo's behavior-critical substrate.
-  // The substrate guard exists to protect the MAIN REPO's specialist files
-  // from inadvertent modification, not to block agents from doing their job.
-  if (isWorktreeInternalPath(normalized)) return false;
-  return SUBSTRATE_PATH_RE.test(normalized);
-}
-
-/**
- * Returns true if the filePath is inside a worktree directory.
- * Used by callers that need to know whether they're operating on a worktree-
- * internal file (e.g. to adjust reminder messaging).
- */
-function isWorktreeInternalPath(filePath) {
-  if (!filePath) return false;
-  return WORKTREE_PREFIX_RE.test(filePath.replace(/\\/g, '/'));
-}
-
-module.exports = { SUBSTRATE_PATH_RE, WORKTREE_PREFIX_RE, isSubstratePath, isWorktreeInternalPath, stripWorktreePrefix };