LessJS 框架从第一天起就选择了 Lit 作为组件基础。这个选择是对的——Lit 是 Web Components 生态中 最成熟的库，让我们快速验证了 K·I·S·S 架构的可行性。但经过后续架构审查，我们也更清楚地看到： core 的长期合同不能绑定到某个组件库。Lit 应该保留为 adapter，而不是成为用户必须接受的唯一组件模型。
依赖 Lit 编写的 island 会携带 Lit 运行时；SSR/style extraction 需要 adapter 维护；旧 Lit SSR 路线留下的 hydration 术语又容易和现在的 DSD + Custom Element upgrade 模型混淆。Deno fmt 在处理复杂 Lit 模板字面量时也曾触发上游 panic。结论不是“消灭 Lit”，而是把 Lit 放回正确的位置： 一个好 adapter，而不是 LessJS 的定义本身。
一个组件一个文件。没有 class 声明，没有 decorator，没有 import：
零依赖的原生 Custom Element：
— Lit-authored islands 的框架运行时代价 → 编译产物 0 KB framework runtime
— adapter-mediated SSR → LessJS DSD renderer / template strings
— hydration 术语漂移 → 明确的 Custom Element upgrade
— decorator / tagged template 生态复杂度 → 标准 JS 输出
— 复杂的类型层次 → 简单的 getter/setter
这项工作不应该阻塞 v0.7–v0.10。当前路线是：先修可信度、安全、DSD renderer、Island Upgrade、
Serverless Fullstack 与 SSG/ISR，再在 v0.11.0 引入 .less compiler alpha。 Lit
兼容模式在 v0.x 生命周期中保留。版本策略详见
ADR 0006。
详细技术设计见 docs/decisions/0002-kiss-compiler-eliminate-lit.md。