Khy-OS 选活与发展路径（不知做什么时）#

想推进项目但没头绪时，照这套定位下一步，并把它变成一个能安全执行的加法式小任务。

第一步：只读体检，让项目自己告诉你哪里疼#

node services/backend/bin/khy.js maintain freshness    # 与时俱进体检
npm --prefix services/backend run arch:god             # 有没有上帝组件(>2500行)
node services/backend/bin/khy.js health                # 顶层诊断

守卫红、体检报警、上帝文件超标——这些是排最前的活。

第二步：按优先级选（从上往下，上面的先做）#

命脉：pip 能不能打包发布？守卫是否全绿？版本号是否一致？——任何一个坏，先修这个。
缺陷：已知 bug、崩溃、安全洞（SSRF/密钥泄漏/破坏性命令绕过/边界未锚定）。
兼容：弱模型/陌生模型跑不通的地方（上下文撑爆、截断、JSON 解析、role 兼容、鉴权形态过时、模型名泄漏 404）。
体验：CLI/TUI 的小打磨、错误文案更诚实、可读性。
能力：新工具、新 provider、新 skill——最后做，且必须门控可关。

拿不准就往靠上选。稳定和可回退永远优先于新功能。

第三步：把它收敛成一个加法式小任务#

一个好任务应满足：

单一职责：只解决一个明确问题。
加法式：能写成"纯叶子 + KHY_ 门控（默认开）+ 关掉逐字节回退"。
可接线：能接到 executeTool / toolUseLoop.js / aiManagementServer.js 之一。
可测：能写几个单测证明它对，且不破坏既有测试。

一句话描述清楚再动手，例如：

修 <函数> 在 <场景> 下 <错误行为>；新增纯叶子 <xxxGuard>（门控 KHY_XXX 默认开），接线在 <真实入口>，关掉逐字节回退。

第四步：执行#

改代码 → 激活 /khy-safe-change
是弱模型/任务复杂 → 先激活 /khy-weak-model-guardrails
做完 → 激活 /khy-honest-closure

不做什么#

不做"大重构/批量改"除非先备份且用户明确要。
不为炫技加复杂度。项目的目标是换任何 AI 都能接着干，且不越改越坏。