universal-dev-standards 6.9.0 → 6.11.0

package/src/utils/integration-generator.js

@@ -3,8 +3,10 @@ import { dirname, join, basename } from 'path';
 import { getLanguageRules } from '../prompts/integrations.js';
 import { computeIntegrationBlockHash } from './hasher.js';
 import { UDS_MARKERS, SUPPORTED_AI_TOOLS, LEGACY_TOOL_MAPPINGS } from '../core/constants.js';
-import { resolveSelectedOptionSources, resolveStandardFilename } from './registry.js';
+import { locateMarkerBlock } from './marker-locator.js';
+import { resolveSelectedOptionSources, resolveStandardFilename, getAllStandards } from './registry.js';
 import { getAgentConfig, getAgentTier } from '../config/ai-agent-paths.js';
+import { STANDARD_ID_MAPPING } from './conversion-rules.js';
 
 /**
  * Resolve contentMode and level based on AI tool's tier and capabilities.
@@ -2003,6 +2005,16 @@ src/
 /**
  * Tool-specific file headers
  */
+// 🔴 These headers used to open by telling the agent to "PRIORITIZE reading the
+// concise rules in `core/`". `uds init` installs standards into `.standards/`
+// and has never created a `core/` directory in an adopter's project — `core/`
+// is where the standards live in the UDS repo, not in the repos that adopt it.
+// So the first instruction in every generated file, for every tool, in every
+// language, pointed at nothing. An adopter reported the symptom on 2026-09-16
+// and read it as residue from an old install; it was not residue, a clean
+// `uds init` wrote it. 36 copies of the same two sentences, all wrong the same
+// way. `tests/unit/utils/tool-headers-no-core.test.js` walks the generated
+// output so a tenth tool cannot reintroduce it.
 const TOOL_HEADERS = {
   cursor: {
     en: `# Cursor Rules
@@ -2015,8 +2027,8 @@ You are an expert software engineer assistant. Follow these project standards.
 All responses should be in **English**.
 
 ## Core Standards Usage Rule
-> When verifying standards, checking code, or performing tasks, **PRIORITIZE** reading the concise rules in \`core/\` (e.g., \`core/testing-standards.md\`).
-> **ONLY** read \`core/guides/\` or \`methodologies/guides/\` when explicitly asked for educational content, detailed explanations, or tutorials.
+> When verifying standards, checking code, or performing tasks, read the rules in \`.standards/\` — that is where this project's standards are installed.
+> Each file states its own requirements; read the one the task is about rather than all of them.
 > This ensures token efficiency and focused context.`,
     'zh-tw': `# Cursor 規則
 # 由 Universal Dev Standards CLI 生成
@@ -2028,8 +2040,8 @@ All responses should be in **English**.
 所有回覆必須使用**繁體中文 (Traditional Chinese)**。
 
 ## 核心標準使用規則 / Core Standards Usage Rule
-> 當驗證標準、檢查程式碼或執行任務時，**優先**讀取 \`core/\` 中的精簡規則（例如 \`core/testing-standards.md\`）。
-> 只有在被明確要求提供教育內容、詳細解釋或教學時，才讀取 \`core/guides/\` 或 \`methodologies/guides/\`。
+> 當驗證標準、檢查程式碼或執行任務時，讀取 \`.standards/\` 裡的規則——那是本專案標準實際安裝的位置。
+> 每個檔案各自寫明它要求什麼；讀與當下任務相關的那一份，不必全部讀完。
 > 這確保了 Token 效率和上下文聚焦。`,
     bilingual: `# Cursor Rules | Cursor 規則
 # Generated by Universal Dev Standards CLI
@@ -2044,10 +2056,10 @@ All responses should be in **Traditional Chinese (繁體中文)**, with technica
 所有回覆必須使用**繁體中文**，技術術語可保留英文。
 
 ## Core Standards Usage Rule / 核心標準使用規則
-> When verifying standards, checking code, or performing tasks, **PRIORITIZE** reading the concise rules in \`core/\` (e.g., \`core/testing-standards.md\`).
-> 當驗證標準、檢查程式碼或執行任務時，**優先**讀取 \`core/\` 中的精簡規則（例如 \`core/testing-standards.md\`）。
-> **ONLY** read \`core/guides/\` or \`methodologies/guides/\` when explicitly asked for educational content, detailed explanations, or tutorials.
-> 只有在被明確要求提供教育內容、詳細解釋或教學時，才讀取 \`core/guides/\` 或 \`methodologies/guides/\`。
+> When verifying standards, checking code, or performing tasks, read the rules in \`.standards/\` — that is where this project's standards are installed.
+> 當驗證標準、檢查程式碼或執行任務時，讀取 \`.standards/\` 裡的規則——那是本專案標準實際安裝的位置。
+> Each file states its own requirements; read the one the task is about rather than all of them.
+> 每個檔案各自寫明它要求什麼；讀與當下任務相關的那一份，不必全部讀完。
 > This ensures token efficiency and focused context.
 > 這確保了 Token 效率和上下文聚焦。`
   },
@@ -2062,8 +2074,8 @@ You are an expert software engineer assistant. Follow these project standards.
 All responses should be in **English**.
 
 ## Core Standards Usage Rule
-> When verifying standards, checking code, or performing tasks, **PRIORITIZE** reading the concise rules in \`core/\` (e.g., \`core/testing-standards.md\`).
-> **ONLY** read \`core/guides/\` or \`methodologies/guides/\` when explicitly asked for educational content, detailed explanations, or tutorials.
+> When verifying standards, checking code, or performing tasks, read the rules in \`.standards/\` — that is where this project's standards are installed.
+> Each file states its own requirements; read the one the task is about rather than all of them.
 > This ensures token efficiency and focused context.`,
     'zh-tw': `# Windsurf 規則
 # 由 Universal Dev Standards CLI 生成
@@ -2075,8 +2087,8 @@ All responses should be in **English**.
 所有回覆必須使用**繁體中文 (Traditional Chinese)**。
 
 ## 核心標準使用規則 / Core Standards Usage Rule
-> 當驗證標準、檢查程式碼或執行任務時，**優先**讀取 \`core/\` 中的精簡規則（例如 \`core/testing-standards.md\`）。
-> 只有在被明確要求提供教育內容、詳細解釋或教學時，才讀取 \`core/guides/\` 或 \`methodologies/guides/\`。
+> 當驗證標準、檢查程式碼或執行任務時，讀取 \`.standards/\` 裡的規則——那是本專案標準實際安裝的位置。
+> 每個檔案各自寫明它要求什麼；讀與當下任務相關的那一份，不必全部讀完。
 > 這確保了 Token 效率和上下文聚焦。`,
     bilingual: `# Windsurf Rules | Windsurf 規則
 # Generated by Universal Dev Standards CLI
@@ -2091,10 +2103,10 @@ All responses should be in **Traditional Chinese (繁體中文)**, with technica
 所有回覆必須使用**繁體中文**，技術術語可保留英文。
 
 ## Core Standards Usage Rule / 核心標準使用規則
-> When verifying standards, checking code, or performing tasks, **PRIORITIZE** reading the concise rules in \`core/\` (e.g., \`core/testing-standards.md\`).
-> 當驗證標準、檢查程式碼或執行任務時，**優先**讀取 \`core/\` 中的精簡規則（例如 \`core/testing-standards.md\`）。
-> **ONLY** read \`core/guides/\` or \`methodologies/guides/\` when explicitly asked for educational content, detailed explanations, or tutorials.
-> 只有在被明確要求提供教育內容、詳細解釋或教學時，才讀取 \`core/guides/\` 或 \`methodologies/guides/\`。
+> When verifying standards, checking code, or performing tasks, read the rules in \`.standards/\` — that is where this project's standards are installed.
+> 當驗證標準、檢查程式碼或執行任務時，讀取 \`.standards/\` 裡的規則——那是本專案標準實際安裝的位置。
+> Each file states its own requirements; read the one the task is about rather than all of them.
+> 每個檔案各自寫明它要求什麼；讀與當下任務相關的那一份，不必全部讀完。
 > This ensures token efficiency and focused context.
 > 這確保了 Token 效率和上下文聚焦。`
   },
@@ -2109,8 +2121,8 @@ You are an expert software engineer assistant. Follow these project standards.
 All responses should be in **English**.
 
 ## Core Standards Usage Rule
-> When verifying standards, checking code, or performing tasks, **PRIORITIZE** reading the concise rules in \`core/\` (e.g., \`core/testing-standards.md\`).
-> **ONLY** read \`core/guides/\` or \`methodologies/guides/\` when explicitly asked for educational content, detailed explanations, or tutorials.
+> When verifying standards, checking code, or performing tasks, read the rules in \`.standards/\` — that is where this project's standards are installed.
+> Each file states its own requirements; read the one the task is about rather than all of them.
 > This ensures token efficiency and focused context.`,
     'zh-tw': `# Cline 規則
 # 由 Universal Dev Standards CLI 生成
@@ -2122,8 +2134,8 @@ All responses should be in **English**.
 所有回覆必須使用**繁體中文 (Traditional Chinese)**。
 
 ## 核心標準使用規則 / Core Standards Usage Rule
-> 當驗證標準、檢查程式碼或執行任務時，**優先**讀取 \`core/\` 中的精簡規則（例如 \`core/testing-standards.md\`）。
-> 只有在被明確要求提供教育內容、詳細解釋或教學時，才讀取 \`core/guides/\` 或 \`methodologies/guides/\`。
+> 當驗證標準、檢查程式碼或執行任務時，讀取 \`.standards/\` 裡的規則——那是本專案標準實際安裝的位置。
+> 每個檔案各自寫明它要求什麼；讀與當下任務相關的那一份，不必全部讀完。
 > 這確保了 Token 效率和上下文聚焦。`,
     bilingual: `# Cline Rules | Cline 規則
 # Generated by Universal Dev Standards CLI
@@ -2138,10 +2150,10 @@ All responses should be in **Traditional Chinese (繁體中文)**, with technica
 所有回覆必須使用**繁體中文**，技術術語可保留英文。
 
 ## Core Standards Usage Rule / 核心標準使用規則
-> When verifying standards, checking code, or performing tasks, **PRIORITIZE** reading the concise rules in \`core/\` (e.g., \`core/testing-standards.md\`).
-> 當驗證標準、檢查程式碼或執行任務時，**優先**讀取 \`core/\` 中的精簡規則（例如 \`core/testing-standards.md\`）。
-> **ONLY** read \`core/guides/\` or \`methodologies/guides/\` when explicitly asked for educational content, detailed explanations, or tutorials.
-> 只有在被明確要求提供教育內容、詳細解釋或教學時，才讀取 \`core/guides/\` 或 \`methodologies/guides/\`。
+> When verifying standards, checking code, or performing tasks, read the rules in \`.standards/\` — that is where this project's standards are installed.
+> 當驗證標準、檢查程式碼或執行任務時，讀取 \`.standards/\` 裡的規則——那是本專案標準實際安裝的位置。
+> Each file states its own requirements; read the one the task is about rather than all of them.
+> 每個檔案各自寫明它要求什麼；讀與當下任務相關的那一份，不必全部讀完。
 > This ensures token efficiency and focused context.
 > 這確保了 Token 效率和上下文聚焦。`
   },
@@ -2156,8 +2168,8 @@ You are an expert software engineer assistant. Follow these project standards.
 All responses should be in **English**.
 
 ## Core Standards Usage Rule
-> When verifying standards, checking code, or performing tasks, **PRIORITIZE** reading the concise rules in \`core/\` (e.g., \`core/testing-standards.md\`).
-> **ONLY** read \`core/guides/\` or \`methodologies/guides/\` when explicitly asked for educational content, detailed explanations, or tutorials.
+> When verifying standards, checking code, or performing tasks, read the rules in \`.standards/\` — that is where this project's standards are installed.
+> Each file states its own requirements; read the one the task is about rather than all of them.
 > This ensures token efficiency and focused context.`,
     'zh-tw': `# GitHub Copilot 說明
 # 由 Universal Dev Standards CLI 生成
@@ -2169,8 +2181,8 @@ All responses should be in **English**.
 所有回覆必須使用**繁體中文 (Traditional Chinese)**。
 
 ## 核心標準使用規則 / Core Standards Usage Rule
-> 當驗證標準、檢查程式碼或執行任務時，**優先**讀取 \`core/\` 中的精簡規則（例如 \`core/testing-standards.md\`）。
-> 只有在被明確要求提供教育內容、詳細解釋或教學時，才讀取 \`core/guides/\` 或 \`methodologies/guides/\`。
+> 當驗證標準、檢查程式碼或執行任務時，讀取 \`.standards/\` 裡的規則——那是本專案標準實際安裝的位置。
+> 每個檔案各自寫明它要求什麼；讀與當下任務相關的那一份，不必全部讀完。
 > 這確保了 Token 效率和上下文聚焦。`,
     bilingual: `# GitHub Copilot Instructions | GitHub Copilot 說明
 # Generated by Universal Dev Standards CLI
@@ -2185,10 +2197,10 @@ All responses should be in **Traditional Chinese (繁體中文)**, with technica
 所有回覆必須使用**繁體中文**，技術術語可保留英文。
 
 ## Core Standards Usage Rule / 核心標準使用規則
-> When verifying standards, checking code, or performing tasks, **PRIORITIZE** reading the concise rules in \`core/\` (e.g., \`core/testing-standards.md\`).
-> 當驗證標準、檢查程式碼或執行任務時，**優先**讀取 \`core/\` 中的精簡規則（例如 \`core/testing-standards.md\`）。
-> **ONLY** read \`core/guides/\` or \`methodologies/guides/\` when explicitly asked for educational content, detailed explanations, or tutorials.
-> 只有在被明確要求提供教育內容、詳細解釋或教學時，才讀取 \`core/guides/\` 或 \`methodologies/guides/\`。
+> When verifying standards, checking code, or performing tasks, read the rules in \`.standards/\` — that is where this project's standards are installed.
+> 當驗證標準、檢查程式碼或執行任務時，讀取 \`.standards/\` 裡的規則——那是本專案標準實際安裝的位置。
+> Each file states its own requirements; read the one the task is about rather than all of them.
+> 每個檔案各自寫明它要求什麼；讀與當下任務相關的那一份，不必全部讀完。
 > This ensures token efficiency and focused context.
 > 這確保了 Token 效率和上下文聚焦。`
   },
@@ -2204,8 +2216,8 @@ Follow these project standards.
 All responses should be in **English**.
 
 ## Core Standards Usage Rule
-> When verifying standards, checking code, or performing tasks, **PRIORITIZE** reading the concise rules in \`core/\` (e.g., \`core/testing-standards.md\`).
-> **ONLY** read \`core/guides/\` or \`methodologies/guides/\` when explicitly asked for educational content, detailed explanations, or tutorials.
+> When verifying standards, checking code, or performing tasks, read the rules in \`.standards/\` — that is where this project's standards are installed.
+> Each file states its own requirements; read the one the task is about rather than all of them.
 > This ensures token efficiency and focused context.`,
     'zh-tw': `# Antigravity 系統指令
 # 由 Universal Dev Standards CLI 生成
@@ -2218,8 +2230,8 @@ Google Antigravity (Gemini Advanced Agent) 的推薦系統指令。
 所有回覆必須使用**繁體中文 (Traditional Chinese)**。
 
 ## 核心標準使用規則 / Core Standards Usage Rule
-> 當驗證標準、檢查程式碼或執行任務時，**優先**讀取 \`core/\` 中的精簡規則（例如 \`core/testing-standards.md\`）。
-> 只有在被明確要求提供教育內容、詳細解釋或教學時，才讀取 \`core/guides/\` 或 \`methodologies/guides/\`。
+> 當驗證標準、檢查程式碼或執行任務時，讀取 \`.standards/\` 裡的規則——那是本專案標準實際安裝的位置。
+> 每個檔案各自寫明它要求什麼；讀與當下任務相關的那一份，不必全部讀完。
 > 這確保了 Token 效率和上下文聚焦。`,
     bilingual: `# Antigravity System Instructions | Antigravity 系統指令
 # Generated by Universal Dev Standards CLI
@@ -2234,10 +2246,10 @@ All responses should be in **Traditional Chinese (繁體中文)**, with technica
 所有回覆必須使用**繁體中文**，技術術語可保留英文。
 
 ## Core Standards Usage Rule / 核心標準使用規則
-> When verifying standards, checking code, or performing tasks, **PRIORITIZE** reading the concise rules in \`core/\` (e.g., \`core/testing-standards.md\`).
-> 當驗證標準、檢查程式碼或執行任務時，**優先**讀取 \`core/\` 中的精簡規則（例如 \`core/testing-standards.md\`）。
-> **ONLY** read \`core/guides/\` or \`methodologies/guides/\` when explicitly asked for educational content, detailed explanations, or tutorials.
-> 只有在被明確要求提供教育內容、詳細解釋或教學時，才讀取 \`core/guides/\` 或 \`methodologies/guides/\`。
+> When verifying standards, checking code, or performing tasks, read the rules in \`.standards/\` — that is where this project's standards are installed.
+> 當驗證標準、檢查程式碼或執行任務時，讀取 \`.standards/\` 裡的規則——那是本專案標準實際安裝的位置。
+> Each file states its own requirements; read the one the task is about rather than all of them.
+> 每個檔案各自寫明它要求什麼；讀與當下任務相關的那一份，不必全部讀完。
 > This ensures token efficiency and focused context.
 > 這確保了 Token 效率和上下文聚焦。`
   },
@@ -2250,8 +2262,8 @@ All responses should be in **Traditional Chinese (繁體中文)**, with technica
 All responses should be in **English**.
 
 ## Core Standards Usage Rule
-> When verifying standards, checking code, or performing tasks, **PRIORITIZE** reading the concise rules in \`core/\` (e.g., \`core/testing-standards.md\`).
-> **ONLY** read \`core/guides/\` or \`methodologies/guides/\` when explicitly asked for educational content, detailed explanations, or tutorials.
+> When verifying standards, checking code, or performing tasks, read the rules in \`.standards/\` — that is where this project's standards are installed.
+> Each file states its own requirements; read the one the task is about rather than all of them.
 > This ensures token efficiency and focused context.`,
     'zh-tw': `# Claude Code 專案指南
 # 由 Universal Dev Standards CLI 生成
@@ -2262,8 +2274,8 @@ All responses should be in **English**.
 AI 助手應以繁體中文回覆使用者的問題與請求。
 
 ## 核心標準使用規則 / Core Standards Usage Rule
-> 當驗證標準、檢查程式碼或執行任務時，**優先**讀取 \`core/\` 中的精簡規則（例如 \`core/testing-standards.md\`）。
-> 只有在被明確要求提供教育內容、詳細解釋或教學時，才讀取 \`core/guides/\` 或 \`methodologies/guides/\`。
+> 當驗證標準、檢查程式碼或執行任務時，讀取 \`.standards/\` 裡的規則——那是本專案標準實際安裝的位置。
+> 每個檔案各自寫明它要求什麼；讀與當下任務相關的那一份，不必全部讀完。
 > 這確保了 Token 效率和上下文聚焦。`,
     bilingual: `# Project Guidelines for Claude Code | Claude Code 專案指南
 # Generated by Universal Dev Standards CLI
@@ -2276,10 +2288,10 @@ All responses should be in **Traditional Chinese (繁體中文)**, with technica
 AI 助手應以繁體中文回覆使用者的問題與請求。
 
 ## Core Standards Usage Rule / 核心標準使用規則
-> When verifying standards, checking code, or performing tasks, **PRIORITIZE** reading the concise rules in \`core/\` (e.g., \`core/testing-standards.md\`).
-> 當驗證標準、檢查程式碼或執行任務時，**優先**讀取 \`core/\` 中的精簡規則（例如 \`core/testing-standards.md\`）。
-> **ONLY** read \`core/guides/\` or \`methodologies/guides/\` when explicitly asked for educational content, detailed explanations, or tutorials.
-> 只有在被明確要求提供教育內容、詳細解釋或教學時，才讀取 \`core/guides/\` 或 \`methodologies/guides/\`。
+> When verifying standards, checking code, or performing tasks, read the rules in \`.standards/\` — that is where this project's standards are installed.
+> 當驗證標準、檢查程式碼或執行任務時，讀取 \`.standards/\` 裡的規則——那是本專案標準實際安裝的位置。
+> Each file states its own requirements; read the one the task is about rather than all of them.
+> 每個檔案各自寫明它要求什麼；讀與當下任務相關的那一份，不必全部讀完。
 > This ensures token efficiency and focused context.
 > 這確保了 Token 效率和上下文聚焦。`
   },
@@ -2294,8 +2306,8 @@ You are an expert software engineer assistant. Follow these project standards.
 All responses should be in **English**.
 
 ## Core Standards Usage Rule
-> When verifying standards, checking code, or performing tasks, **PRIORITIZE** reading the concise rules in \`core/\` (e.g., \`core/testing-standards.md\`).
-> **ONLY** read \`core/guides/\` or \`methodologies/guides/\` when explicitly asked for educational content, detailed explanations, or tutorials.
+> When verifying standards, checking code, or performing tasks, read the rules in \`.standards/\` — that is where this project's standards are installed.
+> Each file states its own requirements; read the one the task is about rather than all of them.
 > This ensures token efficiency and focused context.`,
     'zh-tw': `# AGENTS.md - OpenAI Codex CLI 規則
 # 由 Universal Dev Standards CLI 生成
@@ -2307,8 +2319,8 @@ All responses should be in **English**.
 所有回覆必須使用**繁體中文 (Traditional Chinese)**。
 
 ## 核心標準使用規則 / Core Standards Usage Rule
-> 當驗證標準、檢查程式碼或執行任務時，**優先**讀取 \`core/\` 中的精簡規則（例如 \`core/testing-standards.md\`）。
-> 只有在被明確要求提供教育內容、詳細解釋或教學時，才讀取 \`core/guides/\` 或 \`methodologies/guides/\`。
+> 當驗證標準、檢查程式碼或執行任務時，讀取 \`.standards/\` 裡的規則——那是本專案標準實際安裝的位置。
+> 每個檔案各自寫明它要求什麼；讀與當下任務相關的那一份，不必全部讀完。
 > 這確保了 Token 效率和上下文聚焦。`,
     bilingual: `# AGENTS.md - OpenAI Codex CLI Rules | OpenAI Codex CLI 規則
 # Generated by Universal Dev Standards CLI
@@ -2323,10 +2335,10 @@ All responses should be in **Traditional Chinese (繁體中文)**, with technica
 所有回覆必須使用**繁體中文**，技術術語可保留英文。
 
 ## Core Standards Usage Rule / 核心標準使用規則
-> When verifying standards, checking code, or performing tasks, **PRIORITIZE** reading the concise rules in \`core/\` (e.g., \`core/testing-standards.md\`).
-> 當驗證標準、檢查程式碼或執行任務時，**優先**讀取 \`core/\` 中的精簡規則（例如 \`core/testing-standards.md\`）。
-> **ONLY** read \`core/guides/\` or \`methodologies/guides/\` when explicitly asked for educational content, detailed explanations, or tutorials.
-> 只有在被明確要求提供教育內容、詳細解釋或教學時，才讀取 \`core/guides/\` 或 \`methodologies/guides/\`。
+> When verifying standards, checking code, or performing tasks, read the rules in \`.standards/\` — that is where this project's standards are installed.
+> 當驗證標準、檢查程式碼或執行任務時，讀取 \`.standards/\` 裡的規則——那是本專案標準實際安裝的位置。
+> Each file states its own requirements; read the one the task is about rather than all of them.
+> 每個檔案各自寫明它要求什麼；讀與當下任務相關的那一份，不必全部讀完。
 > This ensures token efficiency and focused context.
 > 這確保了 Token 效率和上下文聚焦。`
   },
@@ -2341,8 +2353,8 @@ You are an expert software engineer assistant powered by Gemini. Follow these pr
 All responses should be in **English**.
 
 ## Core Standards Usage Rule
-> When verifying standards, checking code, or performing tasks, **PRIORITIZE** reading the concise rules in \`core/\` (e.g., \`core/testing-standards.md\`).
-> **ONLY** read \`core/guides/\` or \`methodologies/guides/\` when explicitly asked for educational content, detailed explanations, or tutorials.
+> When verifying standards, checking code, or performing tasks, read the rules in \`.standards/\` — that is where this project's standards are installed.
+> Each file states its own requirements; read the one the task is about rather than all of them.
 > This ensures token efficiency and focused context.`,
     'zh-tw': `# GEMINI.md - Gemini CLI 規則
 # 由 Universal Dev Standards CLI 生成
@@ -2354,8 +2366,8 @@ All responses should be in **English**.
 所有回覆必須使用**繁體中文 (Traditional Chinese)**。
 
 ## 核心標準使用規則 / Core Standards Usage Rule
-> 當驗證標準、檢查程式碼或執行任務時，**優先**讀取 \`core/\` 中的精簡規則（例如 \`core/testing-standards.md\`）。
-> 只有在被明確要求提供教育內容、詳細解釋或教學時，才讀取 \`core/guides/\` 或 \`methodologies/guides/\`。
+> 當驗證標準、檢查程式碼或執行任務時，讀取 \`.standards/\` 裡的規則——那是本專案標準實際安裝的位置。
+> 每個檔案各自寫明它要求什麼；讀與當下任務相關的那一份，不必全部讀完。
 > 這確保了 Token 效率和上下文聚焦。`,
     bilingual: `# GEMINI.md - Gemini CLI Rules | Gemini CLI 規則
 # Generated by Universal Dev Standards CLI
@@ -2370,10 +2382,10 @@ All responses should be in **Traditional Chinese (繁體中文)**, with technica
 所有回覆必須使用**繁體中文**，技術術語可保留英文。
 
 ## Core Standards Usage Rule / 核心標準使用規則
-> When verifying standards, checking code, or performing tasks, **PRIORITIZE** reading the concise rules in \`core/\` (e.g., \`core/testing-standards.md\`).
-> 當驗證標準、檢查程式碼或執行任務時，**優先**讀取 \`core/\` 中的精簡規則（例如 \`core/testing-standards.md\`）。
-> **ONLY** read \`core/guides/\` or \`methodologies/guides/\` when explicitly asked for educational content, detailed explanations, or tutorials.
-> 只有在被明確要求提供教育內容、詳細解釋或教學時，才讀取 \`core/guides/\` 或 \`methodologies/guides/\`。
+> When verifying standards, checking code, or performing tasks, read the rules in \`.standards/\` — that is where this project's standards are installed.
+> 當驗證標準、檢查程式碼或執行任務時，讀取 \`.standards/\` 裡的規則——那是本專案標準實際安裝的位置。
+> Each file states its own requirements; read the one the task is about rather than all of them.
+> 每個檔案各自寫明它要求什麼；讀與當下任務相關的那一份，不必全部讀完。
 > This ensures token efficiency and focused context.
 > 這確保了 Token 效率和上下文聚焦。`
   },
@@ -2388,8 +2400,8 @@ You are an expert software engineer assistant. Follow these project standards.
 All responses should be in **English**.
 
 ## Core Standards Usage Rule
-> When verifying standards, checking code, or performing tasks, **PRIORITIZE** reading the concise rules in \`core/\` (e.g., \`core/testing-standards.md\`).
-> **ONLY** read \`core/guides/\` or \`methodologies/guides/\` when explicitly asked for educational content, detailed explanations, or tutorials.
+> When verifying standards, checking code, or performing tasks, read the rules in \`.standards/\` — that is where this project's standards are installed.
+> Each file states its own requirements; read the one the task is about rather than all of them.
 > This ensures token efficiency and focused context.`,
     'zh-tw': `# AGENTS.md - OpenCode 規則
 # 由 Universal Dev Standards CLI 生成
@@ -2401,8 +2413,8 @@ All responses should be in **English**.
 所有回覆必須使用**繁體中文 (Traditional Chinese)**。
 
 ## 核心標準使用規則 / Core Standards Usage Rule
-> 當驗證標準、檢查程式碼或執行任務時，**優先**讀取 \`core/\` 中的精簡規則（例如 \`core/testing-standards.md\`）。
-> 只有在被明確要求提供教育內容、詳細解釋或教學時，才讀取 \`core/guides/\` 或 \`methodologies/guides/\`。
+> 當驗證標準、檢查程式碼或執行任務時，讀取 \`.standards/\` 裡的規則——那是本專案標準實際安裝的位置。
+> 每個檔案各自寫明它要求什麼；讀與當下任務相關的那一份，不必全部讀完。
 > 這確保了 Token 效率和上下文聚焦。`,
     bilingual: `# AGENTS.md - OpenCode Rules | OpenCode 規則
 # Generated by Universal Dev Standards CLI
@@ -2417,10 +2429,10 @@ All responses should be in **Traditional Chinese (繁體中文)**, with technica
 所有回覆必須使用**繁體中文**，技術術語可保留英文。
 
 ## Core Standards Usage Rule / 核心標準使用規則
-> When verifying standards, checking code, or performing tasks, **PRIORITIZE** reading the concise rules in \`core/\` (e.g., \`core/testing-standards.md\`).
-> 當驗證標準、檢查程式碼或執行任務時，**優先**讀取 \`core/\` 中的精簡規則（例如 \`core/testing-standards.md\`）。
-> **ONLY** read \`core/guides/\` or \`methodologies/guides/\` when explicitly asked for educational content, detailed explanations, or tutorials.
-> 只有在被明確要求提供教育內容、詳細解釋或教學時，才讀取 \`core/guides/\` 或 \`methodologies/guides/\`。
+> When verifying standards, checking code, or performing tasks, read the rules in \`.standards/\` — that is where this project's standards are installed.
+> 當驗證標準、檢查程式碼或執行任務時，讀取 \`.standards/\` 裡的規則——那是本專案標準實際安裝的位置。
+> Each file states its own requirements; read the one the task is about rather than all of them.
+> 每個檔案各自寫明它要求什麼；讀與當下任務相關的那一份，不必全部讀完。
 > This ensures token efficiency and focused context.
 > 這確保了 Token 效率和上下文聚焦。`
   }
@@ -2736,6 +2748,237 @@ function generateWorkflowGateContent(language) {
  * @param {Object} config - Integration configuration
  * @returns {string} Generated content
  */
+/**
+ * Strip a standard's extension to get its bare identifying stem, e.g.
+ * 'commit-message.ai.yaml' -> 'commit-message'. Shared by
+ * resolveStandardReferences and getHeadingToPrimaryStandardStem below.
+ */
+function stemOf(value) {
+  return basename(String(value)).replace(/\.(ai\.yaml|yaml|md)$/i, '');
+}
+
+/**
+ * Normalize a Markdown ATX heading line for comparison, e.g.
+ * '## 提交訊息標準  ' -> '提交訊息標準'. Returns null for a non-heading line.
+ */
+function normalizeHeadingLine(line) {
+  const m = String(line).match(/^#{1,6}\s+(.+?)\s*$/);
+  return m ? m[1].trim() : null;
+}
+
+let _headingToPrimaryStandardStem = null;
+
+/**
+ * Map every RULE_TEMPLATES section heading (any category, detail level,
+ * language that has a Reference:/參考: line) to the stem of the FIRST
+ * `.standards/...` path on that line — that section's "primary standard".
+ *
+ * XSPEC adopter-report, narrow auto-repair (decision 1, 2026-09-18):
+ * 6.10.0's resolveStandardReferences deleted `.standards/commit-message-guide.md`
+ * from an existing file's "## 提交訊息標準" section — it looked exactly like a
+ * retired, uninstalled UDS standard — leaving only the trailing options
+ * reference behind. Rewriting away the resulting dangling comma (the earlier
+ * fix, same XSPEC) does not bring the deleted item back: it is gone from the
+ * file, and nothing else regenerates that section, because rule-template
+ * sections live OUTSIDE the UDS markers by design.
+ *
+ * This map is how resolveStandardReferences recognizes "this heading belongs
+ * to a UDS rule template, and here is the one reference it must never be
+ * missing" — so it can restore ONLY that single item, ONLY when it is
+ * genuinely installed and missing from the line. A heading that does not
+ * match any template (a user's own section) is simply absent from this map,
+ * so it is never touched.
+ *
+ * Computed once and cached — RULE_TEMPLATES is a static module constant.
+ *
+ * @returns {Map<string, string>} heading text (without leading '#'s) -> primary standard stem
+ */
+function getHeadingToPrimaryStandardStem() {
+  if (_headingToPrimaryStandardStem) return _headingToPrimaryStandardStem;
+
+  const map = new Map();
+  const refLineRe = /^(?:Reference|參考|参考)[:：]([^\n]*)$/im;
+
+  for (const categoryTemplates of Object.values(RULE_TEMPLATES)) {
+    for (const modeTemplates of Object.values(categoryTemplates)) {
+      for (const text of Object.values(modeTemplates)) {
+        const heading = normalizeHeadingLine(String(text).split('\n')[0]);
+        if (!heading) continue;
+
+        // 'minimal' mode has no Reference: line at all — nothing to repair,
+        // and no primary standard to record for that heading.
+        const refMatch = text.match(refLineRe);
+        if (!refMatch) continue;
+
+        const firstItem = refMatch[1].split(',')[0].trim();
+        const pathMatch = firstItem.match(/^\.standards\/([^\s,`)\]]+)$/);
+        if (!pathMatch) continue;
+
+        map.set(heading, stemOf(pathMatch[1]));
+      }
+    }
+  }
+
+  _headingToPrimaryStandardStem = map;
+  return map;
+}
+
+/**
+ * Point every `.standards/<file>` reference at the file this project actually has.
+ *
+ * `RULE_TEMPLATES` spells its references as `.standards/<name>.md` because that
+ * is what UDS shipped when they were written. A project installed with
+ * `--format ai` holds `<name>.ai.yaml`, so those lines named files that are not
+ * there — reproduced on 6.9.0 (2026-09-16): a clean `--format ai` project got
+ * `.standards/anti-hallucination.md` and `.standards/checkin-standards.md`, and
+ * `uds check` called the file in sync because it compared names with the
+ * extension stripped and never asked whether the file existed.
+ *
+ * Rewrites by stem against the installed set; a reference whose standard this
+ * project did not install is dropped rather than left dangling, and if that
+ * empties the line, the line goes too.
+ *
+ * @param {string} content - Generated integration content
+ * @param {string[]} installedStandards - Manifest standards (IDs or paths)
+ * @param {string} standardsFormat - 'ai' | 'human'
+ * @returns {string}
+ */
+function resolveStandardReferences(content, installedStandards = [], standardsFormat = 'ai', projectPath = null) {
+  if (!content) return content;
+
+  // Every stem UDS itself ships — the only references this function may delete.
+  //
+  // Read defensively: this runs inside pure content generation, and callers
+  // (including this repo's own tests) may have the registry or `fs` mocked. A
+  // registry that cannot be read means "delete nothing", which degrades to
+  // rewriting matched paths only — never to removing a line.
+  const udsOwnedStems = new Set();
+  try {
+    for (const std of getAllStandards()) {
+      if (std?.id) udsOwnedStems.add(stemOf(std.id));
+      const sources = typeof std?.source === 'string'
+        ? [std.source]
+        : [std?.source?.ai, std?.source?.human].filter(Boolean);
+      for (const src of sources) udsOwnedStems.add(stemOf(src));
+    }
+  } catch {
+    // Registry unavailable — keep every reference that does not match.
+  }
+
+  const installedByStem = new Map();
+  for (const entry of installedStandards) {
+    const filename = resolveStandardFilename(entry, standardsFormat) || basename(String(entry));
+    installedByStem.set(stemOf(entry), filename);
+    installedByStem.set(stemOf(filename), filename);
+  }
+
+  // XSPEC adopter-report Q2: a reference written against a pre-6.0.0
+  // filename (`commit-message-guide.md`) must still resolve to whatever this
+  // project installed under the CURRENT id (`commit-message`) — that rename
+  // is exactly what STANDARD_ID_MAPPING already records, previously
+  // consulted only by the human→AI YAML generator. Without it, the old name
+  // was indistinguishable from a retired, UDS-owned standard the project
+  // chose not to install, and got deleted instead of rewritten.
+  const resolveActualFilename = (path) => {
+    const stem = stemOf(path);
+    return installedByStem.get(stem) || installedByStem.get(STANDARD_ID_MAPPING[stem] || stem) || null;
+  };
+
+  const headingToPrimaryStem = getHeadingToPrimaryStandardStem();
+  const headingLineRe = /^#{1,6}\s+/;
+  const referenceLineRe = /^([^\n]*(?:Reference|參考|参考)[:：])([^\n]*)$/i;
+
+  // XSPEC adopter-report Q2: rebuilt as a line-by-line split → filter → join
+  // instead of a single global regex, so each "Reference:" line's PRECEDING
+  // heading is known (needed for decision 1's narrow auto-repair below) —
+  // and instead of patching a deleted substring's separators with more
+  // regexes. The old single-regex approach deleted only the matched
+  // `.standards/...` text in place and then tried to tidy up whatever
+  // punctuation was left around the hole; it handled a trailing comma, a
+  // doubled comma, and a comma with stray space, but not a comma left
+  // dangling right after the colon when the FIRST item was the one dropped
+  // (`Reference:, .standards/other.md`).
+  const lines = content.split('\n');
+  let currentHeading = null;
+  const outLines = [];
+
+  for (const rawLine of lines) {
+    if (headingLineRe.test(rawLine)) {
+      currentHeading = normalizeHeadingLine(rawLine);
+      outLines.push(rawLine);
+      continue;
+    }
+
+    const refMatch = rawLine.match(referenceLineRe);
+    if (!refMatch) {
+      outLines.push(rawLine);
+      continue;
+    }
+
+    const [, label, rest] = refMatch;
+    const items = rest.split(',').map((s) => s.trim()).filter(Boolean);
+    const kept = [];
+    const presentStems = new Set();
+
+    for (const item of items) {
+      const pathMatch = item.match(/^(\.standards\/)([^\s,`)\]]+)$/);
+      if (!pathMatch) {
+        // Not a bare `.standards/...` reference (e.g. trailing prose) — leave untouched.
+        kept.push(item);
+        continue;
+      }
+      const [, prefix, path] = pathMatch;
+
+      // Option files live in `.standards/options/…` and are named by path, not ID.
+      if (path.startsWith('options/')) { kept.push(item); presentStems.add(stemOf(path)); continue; }
+
+      const actual = resolveActualFilename(path);
+      if (actual) { kept.push(`${prefix}${actual}`); presentStems.add(stemOf(actual)); continue; }
+
+      // 🔴 Only UDS's own standards may be dropped. The first version of this
+      // rewrite removed every unmatched reference, which deleted a project's own
+      // `.standards/our-house-rule.md` line — a file it had put there on purpose.
+      // Removing a user's line is worse than the dead link this exists to fix.
+      let onDisk = false;
+      try {
+        onDisk = Boolean(projectPath) && existsSync(join(projectPath, '.standards', path));
+      } catch {
+        onDisk = false;
+      }
+      if (onDisk || !udsOwnedStems.has(stemOf(path))) {
+        kept.push(item);
+        presentStems.add(stemOf(path));
+        continue;
+      }
+      // Dropped: a UDS-owned reference to a standard this project did not install.
+    }
+
+    // XSPEC adopter-report, narrow auto-repair (decision 1): this line's
+    // heading matches a UDS rule template EXACTLY (see
+    // getHeadingToPrimaryStandardStem's docblock) and that template's
+    // primary standard is genuinely installed but missing from the line —
+    // put it back at the front. Idempotent: a line that already has it does
+    // nothing. Everything else about the line — the project's own entries,
+    // options files, existing order — is untouched, and no OTHER (secondary)
+    // template item is ever added back.
+    const primaryStem = currentHeading ? headingToPrimaryStem.get(currentHeading) : null;
+    if (primaryStem && !presentStems.has(primaryStem)) {
+      const primaryActual = installedByStem.get(primaryStem);
+      if (primaryActual) {
+        kept.unshift(`.standards/${primaryActual}`);
+      }
+    }
+
+    if (kept.length === 0) {
+      outLines.push('');
+      continue;
+    }
+    outLines.push(`${label} ${kept.join(', ')}`);
+  }
+
+  return outLines.join('\n').replace(/\n{3,}/g, '\n\n');
+}
+
 export function generateIntegrationContent(config) {
   const {
     tool,
@@ -2890,7 +3133,8 @@ export function generateIntegrationContent(config) {
     sections.push('\n');
   }
 
-  return sections.join('\n').trim() + '\n';
+  const assembled = sections.join('\n').trim() + '\n';
+  return resolveStandardReferences(assembled, installedStandards, standardsFormat, config.projectPath || null);
 }
 
 /**
@@ -2939,7 +3183,10 @@ export function mergeRules(existingContent, newContent, strategy) {
  * @returns {Object} Result with success status
  */
 export function writeIntegrationFile(tool, config, projectPath) {
-  const fileName = getToolFileName(tool);
+  // XSPEC-418 R2/R3: config.integrationTargets carries manifest.integrationTargets
+  // (or its init-time equivalent) through unchanged — this is the actual write path,
+  // so it must be the one place that honors a per-tool target override.
+  const fileName = resolveIntegrationTargetFile(tool, { integrationTargets: config.integrationTargets });
   if (!fileName) {
     return { success: false, error: `Unknown tool: ${tool}` };
   }
@@ -2973,6 +3220,19 @@ export function writeIntegrationFile(tool, config, projectPath) {
       }
     }
 
+    // 🔴 The rule sections live OUTSIDE the markers, so a marker-based update
+    // never refreshes them: a file first written by an older CLI kept
+    // `.standards/commit-message-guide.md` for ever, and a regenerate on the
+    // fixed generator still left it (measured 2026-09-16). Repoint stale
+    // `.standards/` paths across the whole file — it touches nothing but the
+    // paths, and a path to a file that is not there helps no reader.
+    content = resolveStandardReferences(
+      content,
+      config.installedStandards || [],
+      config.standardsFormat || 'ai',
+      projectPath
+    );
+
     writeFileSync(filePath, content);
 
     // Compute block hash for tracking UDS content separately from user content
@@ -2993,10 +3253,13 @@ export function writeIntegrationFile(tool, config, projectPath) {
  * Check if integration file exists
  * @param {string} tool - Tool name
  * @param {string} projectPath - Project root path
+ * @param {Object} [manifestLike] - Manifest-like object; only `integrationTargets` is
+ *   read (XSPEC-418 R2) — pass the real manifest, or `{ integrationTargets }` at
+ *   init time before a manifest object exists.
  * @returns {boolean} True if file exists
  */
-export function integrationFileExists(tool, projectPath) {
-  const fileName = getToolFileName(tool);
+export function integrationFileExists(tool, projectPath, manifestLike) {
+  const fileName = resolveIntegrationTargetFile(tool, manifestLike);
   return fileName && existsSync(join(projectPath, fileName));
 }
 
@@ -3201,9 +3464,19 @@ function withSelectedOptions(manifest) {
 
 export function buildToolIntegrationConfig(manifest, tool) {
   const selected = manifest.options?.output_language || manifest.options?.commit_language || 'english';
-  const language = selected === 'bilingual'
+
+  // Content language comes from `display_language` — the setting whose entire
+  // job is "what language do you want to read" — and only falls back to
+  // `output_language`, which is the commit-message language, when the project
+  // has no display setting to go on. They are different questions: `uds init`
+  // has always used the first, every regeneration path used the second, and a
+  // project installed with `--locale zh-tw` therefore got Chinese instructions
+  // from `init` and English ones from the next `uds update`, silently.
+  const display = manifest.options?.display_language;
+  const fromOutput = selected === 'bilingual'
     ? 'bilingual'
     : selected === 'traditional-chinese' ? 'zh-tw' : 'en';
+  const language = ['en', 'zh-tw', 'bilingual'].includes(display) ? display : fromOutput;
   const resolved = resolveContentModeForTool(tool, manifest.contentMode || 'auto');
 
   return {
@@ -3220,7 +3493,12 @@ export function buildToolIntegrationConfig(manifest, tool) {
     contentMode: resolved.contentMode,
     level: resolved.level,
     outputLanguage: selected,
-    methodology: manifest.methodology
+    methodology: manifest.methodology,
+    // XSPEC-418 R2/R3: threads the per-tool target override through to
+    // writeIntegrationFile via resolveIntegrationTargetFile. Every caller of
+    // this function (regenerateIntegrations, plan-executor's migrate_block,
+    // backfillIntegrationConfigs) gets the override for free.
+    integrationTargets: manifest.integrationTargets
   };
 }
 
@@ -3280,13 +3558,18 @@ export function wrapWithMarkers(content, format) {
  */
 export function extractMarkedContent(fileContent, format) {
   const markers = UDS_MARKERS[format] || UDS_MARKERS.markdown;
-  const startIdx = fileContent.indexOf(markers.start);
-  const endIdx = fileContent.indexOf(markers.end);
-
-  if (startIdx === -1 || endIdx === -1 || endIdx <= startIdx) {
+  // XSPEC adopter-report Q5: locateMarkerBlock requires the marker to occupy
+  // a whole line by itself (and not be inside a fenced code block), so a
+  // sentence that merely mentions the marker text is never mistaken for the
+  // real boundary. It throws AmbiguousMarkerError if more than one real pair
+  // exists — callers must not catch that away silently.
+  const block = locateMarkerBlock(fileContent, markers);
+
+  if (!block) {
     return { before: fileContent, content: '', after: '' };
   }
 
+  const { startIdx, endIdx } = block;
   return {
     before: fileContent.substring(0, startIdx),
     content: fileContent.substring(startIdx + markers.start.length, endIdx).trim(),
@@ -3303,15 +3586,18 @@ export function extractMarkedContent(fileContent, format) {
  */
 export function updateMarkedSection(existingContent, newMarkedContent, format) {
   const markers = UDS_MARKERS[format] || UDS_MARKERS.markdown;
-  const startIdx = existingContent.indexOf(markers.start);
-  const endIdx = existingContent.indexOf(markers.end);
+  // XSPEC adopter-report Q5: same rule as extractMarkedContent — a line that
+  // merely mentions the marker text is not a boundary, so it is never
+  // deleted along with (what used to be mistaken for) "the UDS block".
+  const block = locateMarkerBlock(existingContent, markers);
 
-  if (startIdx === -1 || endIdx === -1) {
+  if (!block) {
     // No existing markers, append new content
     return existingContent.trim() + '\n\n' + wrapWithMarkers(newMarkedContent, format) + '\n';
   }
 
   // Replace existing marked section
+  const { startIdx, endIdx } = block;
   const before = existingContent.substring(0, startIdx);
   const after = existingContent.substring(endIdx + markers.end.length);
 
@@ -3327,6 +3613,45 @@ export function getToolFilePath(tool) {
   return getToolFileName(tool) || null;
 }
 
+/**
+ * Tool × manifest → the integration file this tool actually reads/writes.
+ *
+ * XSPEC-418 R2: honors a per-tool override recorded in
+ * `manifest.integrationTargets` (currently only ever set for `claude-code`, to
+ * `CLAUDE.local.md` — a personal UDS adoption in a repo with a team-owned,
+ * version-controlled `CLAUDE.md`). No override set → same file
+ * `getToolFilePath` already returns, so every manifest that never sets
+ * `integrationTargets` gets byte-identical output (XSPEC-418 AC-5).
+ *
+ * This is the single place "tool → target file" is decided once a manifest (or
+ * a manifest-shaped config carrying `integrationTargets`) is in scope. Every
+ * call site that used to call `getToolFilePath`/`getToolFileName` to answer
+ * "what file do I read/write for this tool right now" must call this instead
+ * — enforced by the static-scan guard in
+ * tests/unit/core/integration-target-resolver-guard.test.js.
+ *
+ * Placed here rather than core/constants.js, where XSPEC-418 originally
+ * suggested it next to `resolveIntegrationFile`: the default-file fallback
+ * must be the `getToolFileName` above — the one with the legacy-mapping guard,
+ * the already-a-filename passthrough, and the "known agent missing from
+ * SUPPORTED_AI_TOOLS" throw (see its own comment) — not a re-implementation in
+ * constants.js, which would silently drop that throw for every call site this
+ * migrates. constants.js is imported BY this file already, so this file
+ * cannot be imported back from constants.js without a cycle; it lives beside
+ * the function it wraps instead.
+ *
+ * @param {string} tool - Tool key (e.g. 'claude-code'), or an entry already
+ *   resolved to a file path — passed straight to `getToolFileName`, which
+ *   already tolerates that shape (XSPEC-208 BUG-208-01).
+ * @param {Object} [manifest] - Manifest-like object; only `integrationTargets` is read.
+ * @returns {string|null} Repo-relative target file, or null for a genuinely unknown tool.
+ */
+export function resolveIntegrationTargetFile(tool, manifest) {
+  const key = LEGACY_TOOL_MAPPINGS[tool] || tool;
+  const override = manifest?.integrationTargets?.[key];
+  if (typeof override === 'string' && override.length > 0) return override;
+  return getToolFileName(tool) || null;
+}
 
 /**
  * Get default commands based on ecosystem
@@ -3431,6 +3756,7 @@ export function generateAgentsMdSummary(config = {}) {
     language = 'en',
     outputLanguage = 'english',
     standardOptions = {},
+    standardsFormat = 'ai',
     projectPath
   } = config;
 
@@ -3523,12 +3849,25 @@ export function generateAgentsMdSummary(config = {}) {
     // only the option files. On one adopter that meant seven lines standing in
     // for seventy, under a heading reading "Installed Standards", with nothing
     // anywhere reporting the sixty-three that had been dropped.
-    const resolved = installedStandards
-      .map((s) => resolveStandardFilename(s, 'ai'))
-      .filter((name) => name?.endsWith('.ai.yaml'));
-
-    for (const filename of resolved) {
-      lines.push(`- \`.standards/${filename}\` — ${filename.replace('.ai.yaml', '')}`);
+    // Two things this used to get wrong, both of which produced a list of paths
+    // that are not there — under a heading telling the agent to read them.
+    //
+    // Options install one directory deeper (`.standards/options/…`), and this
+    // wrote every entry at the top level. The sibling renderer in this file has
+    // always handled that; the docblock above it says a previous fix reached
+    // "one of the two producers", and this is the other one.
+    //
+    // And the format was pinned to `ai`, so a `--format human` project was
+    // handed `.ai.yaml` names for files it holds as `.md`.
+    const format = standardsFormat === 'human' ? 'human' : 'ai';
+    const suffix = format === 'human' ? '.md' : '.ai.yaml';
+
+    for (const entry of installedStandards) {
+      const filename = resolveStandardFilename(entry, format);
+      if (!filename?.endsWith(suffix)) continue;
+      const isOption = entry.includes('/options/') || entry.includes('\\options\\');
+      const dir = isOption ? '.standards/options' : '.standards';
+      lines.push(`- \`${dir}/${filename}\` — ${filename.replace(suffix, '')}`);
     }
   } else {
     lines.push('No standards installed yet. Run `npx uds init` to install.');