LifeOS ISA 实战解析：用 50 条可验证 ISC 定义「家用能源监控桌面应用」的理想态（WattWatch 案例全解读）-平芜编程栈

LifeOS ISA 实战解析：用 50 条可验证 ISC 定义「家用能源监控桌面应用」的理想态（WattWatch 案例全解读）

【免费下载链接】LifeOS⛰️ The Life Operating System — an intent engineering platform that moves you from your current state to your ideal state, in life and work.项目地址: https://gitcode.com/GitHub_Trending/pe/LifeOS

导读

本文以 LifeOS 的 ISA（Ideal State Artifact，理想态工件）技能库中的完整示例 e5-desktop-app.md 为对象，逐节拆解一个虚构但完全真实规格的「本地优先家用能源监控桌面应用 WattWatch」是如何被写成一份可测试、可执行、可追溯的 ISA 的。读完本文，你将掌握 LifeOS 中「用原子化、可证伪的 ISC 定义 done」的完整写作范式——包括十七节固定结构的组织、50 条验收标准的分类写法、Test Strategy 探针契约、Feature 分解、Dead End 记录与 C/R/L 学习轨迹——并可直接套用到自己的桌面应用、CLI 工具或任何软件项目的规格定义中。

说明：WattWatch 是 ISA 示例库中的教学项目名（文档头部已声明为虚构，wattwatch.example.org为 RFC 2606 保留域名），其价值在于示范 ISA 的形态与写法，而非真实产品。本文所有引用均以仓库实际文件为准。

一、这份示例在 ISA 体系中的位置

在 LifeOS 的 ISA 技能中，Examples/目录保存着跨越规模与领域的参考 ISA。SKILL.md 的示例索引表将 e5-desktop-app.md 归类为Code / E5 档位：「WattWatch — open-source desktop app for personal home-energy monitoring. Single-user app pattern, 50 ISCs, populated Changelog」。

也就是说，这个文件被定位为E5（最大规模）的「单用户桌面应用」参考模板，与同目录下其他示例形成互补：

示例文件	领域/模式	规模
e1-minimal.md	给 CLI 工具加一个`--no-color`参数	Goal + 4 ISC，最小快速路径
e2-backup-verify.md	备份 CLI 的 SHA-256 校验	单域，18 ISC
e3-project.md	arxiv 元数据提取器 CLI	中型项目，12 ISC，八节
e4-api-migration.md	REST → GraphQL API 迁移（6 个月兼容）	跨切面，73 ISC
e5-desktop-app.md	WattWatch 桌面应用（本文对象）	50 ISC，全节填充 + Changelog
e5-enterprise.md	多区域 HIPAA 患者门户	68 ISC，企业参考

文档顶部注释还提醒读者：该示例写于 v6.25.0 之前，因此省略了## Dependencies与## Bridge Criteria，并保留了已退役的 frontmatter 键（effort:、mode:）与旧式标题（## Criteria、## Changelog）——它们是历史形态，节序与新版 frontmatter 以 ISAFormat.md（格式规范 v2.21.0）为准。写作时按 SKILL.md 的建议：先读 canonical-isa.md（BeanLine 示范件）掌握节头，再选最贴近自己领域与规模的示例当模板。

二、Frontmatter 解剖：一张「可执行的规格卡片」

WattWatch 示例的 frontmatter 展示了 ISA 的身份信息：

--- task: "WattWatch — local-first home energy monitoring desktop app" slug: 20260115-090000_wattwatch-v1 project: WattWatch effort: comprehensive effort_source: explicit phase: execute progress: 71/104 mode: interactive started: 2026-01-15T17:00:00Z updated: 2026-04-27T22:30:00Z ---

对照 ISAFormat.md 的 Field Rules 可知：

slug遵循YYYYMMDD-HHMMSS_kebab-description格式；task用祈使句描述交付物（≤60 字符），省略时回退到 H1 标题。
progress: 71/104是「已关闭 claim / 总 claim」的机械计数，格式规范要求关闭 claim 时立即更新、不要攒到末尾。注意：示例的 71/104 与正文 50 条 ISC 存在差异，是因为这是虚构教学示例的留白，不构成规范冲突。
phase在 v2.15.0 之后改为最小生命周期值（scoping/climbing/learn/complete），旧式站点名（如observe/execute/verify）只保证可解析、不再写入新 ISA；effort:、effort_source:、mode:均属已退役字段，仅在旧 ISA 上容忍。

三、第一节骨架：Problem → Vision → Out of Scope → Principles → Constraints → Goal

这六节构成 ISA 的「前奏」，其核心是用文字锁住边界。WattWatch 的写法是教科书级的：

3.1 Problem：先写「现在缺什么」

文档用一段话精确刻画痛点：屋顶光伏、家用电池、智能插座用户拥有实时能源数据，但数据分散在 Shelly、Emporia、Sense、Tesla 五家「围墙花园」里，互不通信、无法形成整屋图景，且即使问「热泵现在开着吗」这种 LAN 内传感器就能回答的问题也要走一遍厂商云。想真正优化家庭用电的用户只能去搭 Home Assistant、手写 YAML，得到的是「爱好者工具箱」而非成品。中间地带——一个聚合主流美国住宅能源传感器的本地优先成品级桌面应用——在 2026 年不存在。

3.2 Vision：把「惊喜时刻」写成具体场景

ISA 的元理想态是「使用系统的人获得惊喜」（euphoric surprise），## Vision就是把这个通用目标落成具体场景。WattWatch 写的是：用户在炎热的下午打开应用，看到热泵拉取 4.2kW、光伏产出 6.8kW、Powerwall 实时用盈余充电——而没有一个数据包离开家庭网络；用户把截图发给朋友，朋友当晚就装上。

注意 Vision 写的是体验而非功能清单——这是 SKILL.md 与 ISAFormat.md 反复强调的写法（「The claims verify the specific summit; the Vision keeps the universal one in view」）。

3.3 Out of Scope：反愿景，一次性说清「不做什么」

示例声明了七条范围外事项，每条都给出理由：

无强制云账号：完全离线运行，云同步可选且默认关闭；
无电费账单集成：聚合的是传感器数据而非账单数据；
无 HVAC/家电控制：WattWatch 只读不写，v1 无自动化；
无移动端：仅桌面，未来最多做桌面应用自带的只读 Web 视图；
无商业/多租户部署：单家庭、单用户、单机；
不支持无法合法解码的厂商加密协议：Shelly 本地 HTTP 可以、Emporia Vue 本地 UDP 可以、Sense 逆向云协议推迟到其发布文档化本地 API；
无实时电价套利/电池调度优化：v1 只做可视化。

3.4 Principles：约束「思考方式」

五条原则都是可泛化的价值观，而非技术选型：本地优先不是特性而是整体姿态；传感器数据属于房主，不回家、不上报遥测、读路径不嵌第三方 SDK；精致的单用户桌面应用在 2026 年是正当产品品类；硬件集成天生脆弱，应用对部分覆盖保持诚实；历史数据神圣不可侵犯。

3.5 Constraints：锁定「解空间」

约束是不可动摇的架构命令，WattWatch 给出七条硬约束：

TypeScript + Bun 工具链，桌面壳用Tauri 2.x（Rust + 系统 webview）而非 Electron，压缩包体 ≤ 25MB；
所有传感器数据存本地 SQLite：${APP_DATA}/wattwatch/db.sqlite，无远程主存储；
平台分级：macOS 13+（一级，须达到生产质量）、Linux x86_64/aarch64（AppImage + .deb，二级）、Windows 10+（三级，已知问题写进 release notes）；
认证全部本地化（单密码、Argon2id、存 OS keychain），无 SSO/OAuth/账号服务器；
可选云同步（默认关）端到端加密、用户派生密钥，同步服务器是「读不到内容的薄中继」；
传感器轮询节奏可配但受限：最小 1 秒、最大 5 分钟，整屋默认 5 秒、单设备默认 30 秒；
UI 在 2019 款 8GB MacBook Air、累积 90 天数据下保持 60fps 滚动、交互延迟 p95 ≤ 100ms。

3.6 Goal：1–3 句「难以随意变动的主干」

Goal 把上述一切压缩成可验证的交付声明：交付一个代号 WattWatch、经签名安装包分发的 Tauri 桌面应用，聚合 Shelly、Emporia Vue、Sense、Tesla Powerwall 数据到统一本地 SQLite 存储，提供实时整屋视图 + 单设备归因 + 六个月历史归档，默认完全离线、可选端到端加密云同步。

四、核心：50 条 ISC 验收标准按域组织

WattWatch 的## Criteria节（旧式标题，新版为## Claims，两者都解析）是文章的主体——50 条原子 claim，每条都能用单一二进制探针证伪。示例按十个业务域分组，覆盖了从构建分发到反指标的完整验收面：

4.1 Build & Distribution（ISC-1 ~ ISC-5）

bun run tauri build产出 macOS arm64 签名.dmg、Linux x86_64.AppImage、Windows x64.msi；
macOS.dmg公证通过，spctl --assess --verbose报告accepted (source=Notarized Developer ID)；
三平台产物压缩后 ≤ 25MB；
wattwatch.example.org/download提供最新签名产物并附 SHA-256；
wattwatch --version打印与package.json一致的 semver。

4.2 First-Run & Onboarding（ISC-6 ~ ISC-11）

首次启动向导 ≤ 10 分钟完成（用户持一台 Shelly + 一台 Powerwall）；LAN 扫描经 mDNS（_shelly._tcp.local）30 秒内自动发现 Shelly；Emporia Vue 配置接受本地凭据并验证 UDP 65432 可达；Tesla Powerwall 配置接受网关 IP 与客户密码（无需特斯拉云账号）；Sense 集成前置「实验性——仅云端」免责声明；**ISC-11（未勾选）**要求零凭据以明文落盘，全部密钥进 OS keychain——这是一个「还没完成」的 claim 的正确示范：留在列表里，不假装完成。

4.3 Sensor Drivers（ISC-12 ~ ISC-17）

Shelly 驱动经本地 HTTP API（Gen1/status、Gen2/rpc/Shelly.GetStatus）轮询 Gen1/Gen2；
Emporia Vue 驱动解码本地 UDP 广播，把 16 路电路通道映射为用户命名标签；
Tesla Powerwall 驱动对/api/login/Basic认证，每 5 秒轮询/api/meters/aggregates与/api/system_status/soe；
Sense 驱动（实验性）经文档化 WebSocket 认证，并明确警告该路径需要 Sense 云端往返；
驱动健康状态机：连续 3 次轮询失败标记degraded，连续 10 次失败标记offline并暂停轮询 60 秒；
轮询延迟预算：LAN 传感器 p95 ≤ 200ms，云传感器（Sense）p95 ≤ 2000ms。

4.4 Data Model & Storage（ISC-18 ~ ISC-22）

SQLite schema 含 8 张表：device、sensor_reading、circuit、aggregate_5min、aggregate_hourly、aggregate_daily、event、user_pref；
sensor_reading持续汇总到aggregate_5min，原始读数 7 天后裁剪；
aggregate_hourly保留 13 个月，aggregate_daily无限期保留；
启动时执行PRAGMA integrity_check，失败走恢复向导、绝不静默忽略；
用户触发的Export → JSON在 ≤ 30 秒内写出 6 个月全历史（带时间戳文件）。

4.5 UI / Real-Time View（ISC-23 ~ ISC-28）

实时仪表盘每 5 秒更新整屋功率、光伏产量、电池 SOC、电网进出；逐回路面板按当前电流排序并带 60 分钟 sparkline；Sankey 能量流图实时渲染 solar → home/battery/grid 分流；**ISC-26（未勾选）**要求任意回路的 raw/hourly/daily 三级下钻视图（放大/平移）；ISC-27/ISC-28 把性能预算落成可测指标：2019 MacBook Air + 90 天数据下 60fps 滚动、点击到首帧 p95 ≤ 100ms。

4.6 Alerts（ISC-29 ~ ISC-32）

规则形如if <metric> <op> <threshold> for <duration>；规则触发时弹系统通知并写event行；告警状态跨重启持久化、应用关闭期间的告警下次启动展示；**ISC-32（未勾选）**要求即使系统拒绝通知，告警仍写入应用内日志。

4.7 Auth（ISC-33 ~ ISC-36）

首次启动设置本地密码（Argon2id，m=64MB, t=3, p=4）；本地密码在启动时解锁 SQLCipher 加密密钥；连续 5 次解锁失败触发 5 分钟冷却；密码重置需用户确认会丢失既有加密数据（v1 无恢复密钥）。

4.8 Cloud Sync（ISC-37 ~ ISC-41，全部未勾选）

这组 ISC 展示了「把功能推迟到 v1.1」时的处理方式：云同步默认 OFF，开启前显示单屏「什么数据会离开设备」说明；开启时用 HKDF + 每安装稳定盐从本地密码派生同步密钥；同步载荷客户端 AES-256-GCM 加密、中继只存密文；第二台设备凭相同密码+邮箱 60 秒内配对；关闭同步 24 小时内删除服务器端密文并弹确认。

4.9 Updates（ISC-42 ~ ISC-43）

每 24 小时检查wattwatch.example.org/api/release/latest一次，仅在用户点击「Install」后应用更新；更新载荷签名，未签名或篡改即中止并可见报错。

4.10 Operational（ISC-44 ~ ISC-45）

诊断导出把 SQLite schema（不含行）、驱动日志（最近 24h）、OS 信息打包成.zip供支持；崩溃报告器 opt-in，发送前展示将要发送的确切字节。

4.11 Anti-criteria：反指标（ISC-46 ~ ISC-50）

反指标是把 Out of Scope / Constraints / Principles 变成可探测的关键机制，WattWatch 写了五条：

Anti: privacy—— 首次启动、用户显式开启云同步之前零出站网络请求（用抓包验证）；
Anti: out of scope—— UI 中没有任何Control按钮，传感器写路径未接线；
Anti: data loss—— 应用更新从不覆盖或迁移 SQLite 而不先写带时间戳的.bak；
Anti: dependency creep—— 构建图里没有 Electron，bun pm ls | grep electron为空；
Anti: telemetry——rg "google-analytics|sentry|mixpanel|posthog|fullstory" src/零匹配。

对照 SKILL.md 的三护栏分类（Principles 约束思考、Constraints 约束解空间、Out of Scope 约束愿景、Anti-criteria 约束测试面），这五条反指标正是前三者的「探针化」产物。

五、Test Strategy：每条 claim 一条可执行探针

ISC	类型	检查	阈值	工具
ISC-2	notarization	macOS Gatekeeper 接受签名 .dmg	`spctl`报告`accepted (source=Notarized Developer ID)`	`spctl --assess --verbose dist/WattWatch.dmg`
ISC-3	bundle-size	压缩后产物体积	≤ 25MB	`du -m dist/WattWatch.dmg ...`
ISC-7	lan-discovery	mDNS 扫描返回测试台上 Shelly 设备	≥ 1 台，≤ 30s	`bun run scripts/mdns-probe.ts`
ISC-14	driver-integration	Powerwall 驱动读取`/api/meters/aggregates`	返回 site/load/solar/battery 值	`bun run scripts/powerwall-probe.ts --gateway 192.168.x.x`
ISC-21	db-integrity	既有库上执行`PRAGMA integrity_check`	返回`ok`	`sqlite3 ${APP_DATA}/wattwatch/db.sqlite "PRAGMA integrity_check"`
ISC-27	performance	90 天数据下 60fps 滚动	中位帧时间 ≤ 16.6ms	tauri devtools performance recorder
ISC-28	interaction-latency	点击 → 首帧 p95	≤ 100ms	`bun run scripts/ui-latency.ts --runs 200`
ISC-39	crypto	同步载荷为 AES-256-GCM 密文	载荷熵 ≥ 7.9 bits/byte	`bun run scripts/sync-payload-entropy.ts`
ISC-46	anti-probe	首次启动（未同意前）出站包	到非 LAN 目的地的包为 0	`tcpdump -i en0 'not net 192.168.0.0/16 ...'`60s
ISC-49	anti-dep	依赖树无 Electron	空匹配	`bun pm ls \\| rg -i electron`
ISC-50	anti-telemetry	源码无第三方遥测 SDK 字符串	0 匹配	`rg "google-analytics\\|sentry\\|..." src/`

从这份清单可以提炼出 ISA 探针设计的两个要点：一是探针要落在「事物与消费者的接缝处」（ISAFormat.md 的 seam rule——探针挂在最高且最贴近消费者的边界上）；二是优先用可运行的确定性探针（bash/curl/bun-test 类），只有无法运行化的场景才退回截图或人工检查。

六、Features：垂直切片式功能分解

## Features用 YAML 块列出 11 个功能，每个声明name、description、satisfies（满足哪些 ISC）、depends_on与parallelizable：

SensorDriverShelly / Emporia / Powerwall / Sense：四个独立传感器驱动，全部parallelizable: true——彼此无依赖，这正是「垂直切片」的体现：每个驱动端到端满足自己的发现/轮询/健康/延迟预算 claim；
LocalStorage：SQLCipher 支撑的 SQLite，含 rollup、保留策略、完整性检查（satisfies 含 ISC-18/19/20/21/22/34/48），parallelizable: false（数据层是串行核心）；
AuthLocal：Argon2id + OS keychain + 冷却，depends_on: [LocalStorage]（解锁加密密钥依赖存储）；
LiveDashboard：实时整屋视图 + Sankey + 逐回路面板，依赖三个主要驱动与 LocalStorage；
Alerts / CloudSyncOptional / Updater / Distribution / Diagnostics：其余功能块，CloudSyncOptional 依赖 AuthLocal + LocalStorage，符合「从本地密码派生同步密钥」的调用链。

对照 ISAFormat.md 的 Feature blocks 规则（v2.16.0）：新版中 Features 是承载 claim 的块（### F<n> · <name>+ 一行Why:+ 内嵌 ISC），旧式name | satisfies指针表已删除——本示例展示的正是旧指针表形态，其「功能 ↔ ISC 映射」的思想在 v2.16.0 后由 feature block 直接内嵌承载。

七、Decisions：决策日志与 Dead End

## Decisions是带时间戳的决策日志，包括死路（dead end）。WattWatch 记录了七条关键决策，其中两条是标注 ❌ DEAD END 的失败尝试：

2026-01-15：选 Tauri 2.x 弃 Electron——≤ 25MB 的包体约束在 Electron 的 Chromium 基线（~120MB）下不可能达成，且系统 webview 复用能显著改善 tier-1 macOS 的冷启动延迟；
2026-01-22：选 SQLite + SQLCipher 而非自定义加密 KV——数据形态是真正关系型的（设备/回路/读数/聚合），且「房主导出」用例要求可移植文件格式；
❌ DEAD END（2026-02-04）：曾尝试让单个 Worker 线程轮询全部四类传感器以简化调度器。结果：卡死的 Sense WebSocket 阻塞了 Shelly 轮询，仪表盘延迟超出 ISC-28 达 4 倍。回退为「每驱动独立 worker + 隔离事件循环」，并明确写「Don't retry」；
2026-02-19：refined:精化 ISC-19 保留策略——「原始读数无限期保留」是幼稚的，7 天原始 + 13 个月小时 + 无限期天级才是能在 256GB Mac 上撑过 6 个月的真实存储形态；
❌ DEAD END（2026-03-02）：曾尝试 LAN 认证失败时回退厂商云 API。这违反本地优先原则、引入隐藏云依赖，回退为诚实的「该传感器离线」UI；
2026-03-14：云同步从 v1 推迟到 v1.1——中继服务器威胁模型不简单，先交付本地优先产品更诚实；
2026-03-29：refined:把 ISC-46 从「无遥测」锐化为「首次启动、用户选择加入前对非 LAN 目的地零出站包」——抓包审查发现 Tauri 的自动更新探测在同意前就触发了，更新检查改为等用户完成 onboarding 之后；
2026-04-10：Sense 驱动保留为experimental而非砍掉——用户调研显示 Sense 用户是被现有工具服务最不到位的人群；
2026-04-22：refined:ISC-3 包体目标从 35MB 收紧到 25MB。

refined:前缀是 ISAFormat.md 对 Goal/ISC 重构的约定标记，而❌ DEAD END ... Don't retry则是把「被证伪的路径」永久钉进审计轨迹，防止未来重新论证同一错误。

八、Changelog（Learning）：C/R/L 四段式纠错轨迹

示例的## Changelog节（新版规范更名为## Learning）采用conjectured / refuted by / learned / criterion now四段式格式，记录「理解发生变化」的时刻，每条都必须四段齐全——SKILL.md 的 Gotchas 明确：Append 工作流拒绝写不完整的 C/R/L，缺任何一段就是 Decision 而非 Learning entry。WattWatch 示范了四条：

2026-02-04：猜想「单一轮询 worker 承载全部驱动可简化架构且无可见代价」→ 被「卡死的 Sense WebSocket 阻塞 Shelly 轮询、交互延迟超 ISC-28 达 4 倍」证伪 → 学到「一个驱动的失败模式是挂起连接而非错误响应时，必须做驱动级隔离」→ criterion now：ISC-17 拆分为 LAN 预算（≤200ms）与云预算（≤2000ms），驱动实现迁到独立 worker；
2026-02-22：猜想「7 天原始读数够高级用户下钻」→ 被 beta 用户「想查 30 天前 5 分钟分辨率的加热泵诊断数据」证伪 → 学到「5 分钟聚合才是正确的下钻分辨率」→ criterion now：ISC-19 锐化为原始 7 天 / 5 分钟聚合 13 个月 / 天级无限期；
2026-03-02：猜想「LAN 认证失败时回退厂商云是对用户的善意」→ 被「回退不可见，测试者带着云回退跑了 3 周没察觉」证伪 → 学到「跨信任边界的静默回退违反用户心智模型」→ criterion now：无 ISC 变更，决策入日志、原则进入代码审查清单；
2026-03-29：猜想「Tauri 默认自动更新探测可以在同意前发布」→ 被「抓包发现欢迎屏都没看到就触发了探测」证伪 → 学到「『无遥测』不够，审计必须包含框架默认网络行为」→ criterion now：ISC-46 锐化、更新检查推迟到 onboarding 之后。

这套格式的价值在于：它把「我们当时为什么这么想、现实如何反驳、我们现在知道什么、标准因此如何变化」完整保留，跨会话、跨 Agent 可审计——这正是 LifeOS 的 Deutsch 纠错轨迹（error-correction trail）。

九、Verification：一行式溯源存根

## Verification节为每条已通过（[x]）的 claim 保存一行溯源存根，指向证明所在处（commit hash、测试名或探针引用），而非大段证据：

ISC-2：spctl --assess --verbose dist/WattWatch.dmg→accepted (source=Notarized Developer ID)
ISC-3：du -m→ dmg 22M / AppImage 19M / msi 24M
ISC-7：测试 LAN 上 3 台 Shelly Gen2 全部在 4.1s 内被发现
ISC-14：探针返回{site_now: -1240, load_now: 3120, solar_now: 4360, battery_now: 0, percentage_charged: 87.4}
ISC-21：PRAGMA integrity_check→ok
ISC-27：2019 MacBook Air + 90 天数据集，滚动中位帧时间 14.2ms
ISC-28：200 次运行 p95 点击到首帧 78ms
ISC-46：首次启动同意前 60 秒 tcpdump → 0 个非 LAN 目的地包
ISC-49 / ISC-50：依赖树与源码扫描均为空

对照 ISAFormat.md 的「证据在关闭时坍缩」约定（Algorithm v8.7.1 claim 12）：claim 勾选的那一刻，其 Verification 条目就压缩为一行存根，证据留在 git 与 CI 中，ISA 只负责「指向」。一个不断堆积证据段落的 Verification 节正是该约定要防止的失败。

十、从 WattWatch 提炼的可复用写作模式

读完这份 50-ISC 示例，可以提炼出六个直接可复用的 ISA 写作手法：

边界先行：Problem → Vision → Out of Scope → Principles → Constraints 五节是「写 claim 之前的清场」——先把解空间划死，claim 才有意义；
原子化 claim 与单一探针：每条 ISC 可被一条命令/一次观察证伪；模糊表述（如「Email is delivered」）会被 ISAFormat.md 的硬变体性示例（fluff vs load-bearing 对比）淘汰；
性能预算必须数字化：60fps（≤16.6ms 帧时间）、p95 ≤ 100ms、包体 ≤ 25MB、发现 ≤ 30s——凡约束能映射为预算的，都需要数字 ISC，而不是「要快」这种氛围；
反指标不可缺：至少一条Anti:claim 把隐私/范围/依赖纪律变成可扫描的探针，这是 CheckCompleteness 的硬性要求之一；
未完成与推迟要如实呈现：ISC-11、ISC-15、ISC-26、ISC-32、ISC-37~41 保持[ ]或整体未勾选，不假装完成——ISA 展示的是诚实状态；
失败要留痕：两条 DEAD END + 四条完整 C/R/L，让「什么被证伪过、为什么、标准因此变成什么」永久可查。

十一、继续深入：相关文档与源码

想要把这份示例用到自己的项目，可以顺着以下仓库路径继续：

格式规范（权威文件形状契约）：ISAFormat.md——十七节固定顺序、Frontmatter Field Rules、Test Strategy 六/七/八列契约、ID-Stability、Completeness Gate；
系统架构（概念框架）：ISASystem.md——五重身份、三护栏分类、六工作流、两处存放地；
技能主文件（工作流路由与 Gotchas）：SKILL.md；
六条工作流：Scaffold.md、Interview.md、Grill.md、CheckCompleteness.md、Reconcile.md、Seed.md、Append.md；
其他示例（按领域选模板）：canonical-isa.md（BeanLine 示范件，先读）、e5-enterprise.md（企业级）、e4-api-migration.md（跨切面迁移）；
解析与执行侧源码：isa-utils.ts（ISA 解析）、IsaFrontier.ts（依赖边与前哨计算）、ISAGate.ts（关闭门禁）、ISARender.ts（渲染）。

结语

一份好的 ISA 不是需求文档，而是「把 done 写成可证伪的 claim，再让每条 claim 都被真实世界检验」的活体解释。WattWatch 示例的价值在于：它用 50 条 ISC 完整演示了桌面应用从架构选型（Tauri vs Electron）、数据模型（SQLite rollup 三级保留）、硬件驱动（四类传感器）、认证加密（Argon2id + SQLCipher）到反指标（零遥测、零出站）的全谱系验收怎么写，并用 DEAD END 与 C/R/L 轨迹示范了「理解如何随时间被现实修正」。下次面对任何「要做成什么样才算完成」的问题时，照这份骨架把边界划清、把 claim 写细、把探针挂到接缝处，你就已经在用 LifeOS 的方式爬山了。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

LifeOS ISA 实战解析：用 50 条可验证 ISC 定义「家用能源监控桌面应用」的理想态（WattWatch 案例全解读）