用 ISA 把 CI 凭据轮换写成 16 条可验证的验收标准LifeOS 运维任务Ops ISA实战拆解【免费下载链接】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导读凭据轮换credential rotation是每个团队迟早要面对的运维高危动作新 token 没配上、旧 token 没吊销、日志里泄露了明文、或者轮换后下一次部署直接失败。LifeOS 的 ISAIdeal State Artifact理想状态工件把这套高风险运维手册改写为一份自带验收探针probe的任务文档——不再依赖记得按步骤做而是把每一步都变成一条可被工具证伪的 ISCIdeal State Criteria。本文以仓库中 e2-rotate-credential.md 这份官方示例为骨架逐条拆解其 16 条验收标准与 6 类测试策略并结合 ISA 技能定义、ISA 格式规范 与 ISA 系统文档 说明其底层机制读完你可以照此模式为自己的 CI 管道设计一份可执行、可回滚、可审计的凭据轮换 ISA。一、为什么运维任务也需要一份 ISA1.1 ISA 的本质把done写成可证伪的断言在 LifeOS 中ISA 是一个具有五种身份的单一工件理想状态表述ideal state articulation、测试夹具test harness、构建验证build verification、完成条件done condition与事实记录system of record。核心主张是done 必须被写成难以变形的解释——即每一条 ISC 都必须能命名一个可以推翻它的测试。正如 ISASystem.md 所述一个 ISC 难以变形当且仅当你能命名一个会使其失败的测试。无法说出失败长什么样这条 ISC 就可以被任何东西满足。这直接对应 ISAFormat 中的经典对照邮件被送达了是几乎任何发送路径都能满足的废话而邮件在 60 秒内进入收件箱主标签而非推广/垃圾箱是命名了具体失败方式的承重断言。凭据轮换正是这种垃圾断言重灾区——更新了密钥吊销了旧 token听起来像标准但既不精确也无法自动验证。1.2 运维任务与代码任务共用同一个原语e2-rotate-credential.md 文件末尾的注释点明了这一设计意图E2 ops ISA。必需章节Problem、Goal、Criteria、Test Strategy。演示了 ISA 原语应用于 ops/runbook 任务——与代码任务形状完全相同。ISC 数量 16 恰好达到 E2 下限。反标准ISC-14/15/16覆盖隐私、范围与回滚安全——典型运维任务的回归预防关注点。也就是说ISA 的十七节结构见 SKILL.md 的章节表对运维任务与代码任务一视同仁## Problem说明现状痛点## Goal给出可验证的完成表述## Claims/## Criteria存放原子化断言## Test Strategy为每条断言绑定探针。区别只在于探针形态代码任务多用bun-test运维任务则几乎全部是curl、gh、git log与jq组合。二、任务骨架frontmatter 与 Problem/Goal2.1 frontmatter最小化载荷示例文件的 YAML frontmatter 是task: Rotate the production deploy credential in the CI pipeline slug: 20260208-103000_rotate-deploy-credential effort: extended effort_source: explicit phase: execute progress: 0/16 mode: interactive started: 2026-02-08T18:30:00Z updated: 2026-02-08T18:30:00Z对照 ISAFormat.md 的 Field Rules这里的effort:/effort_source:/mode:属于已退役字段——effort 分级体系于 2026-07-11 退役、mode 系统同日退役新版 ISA 不再书写它们但旧 ISA 中的这些键仍被宽容解析。真正承重的是phase:与progress:progress: 0/16表示 16 条 ISC 尚未关闭任何一条且这个数字必须是机械计数不允许是感觉快完成了的主观值。2.2 Problem把风险讲清楚示例的 Problem 段是典型的现状 风险 违约触发三要素写法生产部署凭据CI 中以DEPLOY_API_TOKEN存储的长效 API token已签发 14 个月、从未轮换、对部署目标拥有宽泛写权限。按组织季度轮换策略已逾期。需要在不断送下一次部署、且不让旧 token 存活过久的前提下完成轮换。这段文字回答了 ISA 第一节要求的问题——现在什么坏了或缺失使得理想状态值得追求。在凭据轮换场景里风险来源明确暴露面随时间线性增长token 已在 14 个月的 CI 日志、Artifact、开发者本地环境中流转而轮换本身又是高危动作改坏了立刻阻断发布。Problem 写清楚Goal 才有靶子。2.3 Goal1-3 句话的可验证完成表述端到端轮换DEPLOY_API_TOKEN以相同 scope 签发新 token、更新 CI 密钥、在非生产分支上执行一次验证部署、然后吊销旧 token。本次轮换后的下一次生产部署必须成功且旧 token 必须在新 token 生效后 4 小时内失效。注意 Goal 的措辞全部指向可测量结果同 scope、非生产分支、验证部署成功、4 小时失效窗口。没有一句是尽量尽快这类无法验证的形容词。这与 ISAFormat 的 Goal 规范一致——Goal 是可变形脊柱hard-to-vary spine如果删改 Goal 而不影响 ISC 集合说明 Goal 不是承重的。三、16 条 ISC 全解完整继承与逐条分析示例的核心是 16 条按生命周期分组的验收标准。每条都遵循同一格式- [ ] ISC-N: 断言文本probe: 验证命令。下面完整保留并逐组拆解。3.1 轮换前Pre-rotationISC-1 ~ ISC-3ISC断言探针ISC-1新 token 仅授予deploy:writescope无更宽 scopecurl -H Authorization: Bearer $NEW_TOKEN /v1/me返回 scopes 恰为[deploy:write]ISC-2新 token 90 天后过期curl /v1/tokens/id显示expires_at≤ 90 天ISC-3新 token 的created_by是轮换 runbook 服务账号而非个人用户token 元数据这三条构成最小权限 有期限 可审计归属的签发铁三角。最小权限ISC-1直接对抗的是运维中常见的顺手多给权限90 天有效期ISC-2把长效 token变成有时限的与 Goal 中季度轮换策略呼应服务账号归属ISC-3保证审计时能区分机器发起的轮换与个人私自签发。3.2 CI 更新CI updateISC-4 ~ ISC-5ISC断言探针ISC-4CI 提供方中的DEPLOY_API_TOKEN密钥已更新为新值gh secret list --repo org/repo显示updated_at在最近 5 分钟内ISC-5没有任何 commit、日志行或 artifact 以字符串形式包含新 token 值gh run view run-id --log \| rg $(echo $NEW_TOKEN \| head -c 8) \| wc -l返回 0ISC-4 的探针设计值得注意它不检查密钥值对不对CI 提供方的 API 通常不允许读回密钥明文而是用updated_at时间戳作为间接证据——5 分钟窗口既足够新确实是本次轮换改的又不至于误伤。ISC-5 是防泄露的第一道闸只取 token 前 8 个字符做匹配head -c 8既不把完整 token 写进探针命令避免探针自身成为泄露源又能捕捉任何明文出现。3.3 验证VerificationISC-6 ~ ISC-8ISC断言探针ISC-6在rotation-test分支上使用新 token 的测试部署成功部署 job exit 0部署目标 API 确认新 artifact 已注册ISC-7验证部署创建的 artifact 带rotation-test-timestamp标签且可删除curl /v1/artifacts?tagrotation-test能列出该 artifactISC-8验证后清理在 60 分钟内移除测试 artifactcurl /v1/artifacts/id清理后返回 404这三条是把新 token 能用从口头保证变成实证的关键链路先在小分支上真跑一次部署ISC-6给测试产物打上可识别的标签ISC-7规定清理时限ISC-8。测试 deploy 成功如果不附上 exit 0 和 artifact 注册证据就可能被看起来成功糊弄过去而 ISC-8 确保验证本身不留下垃圾——这既是对部署目标的卫生要求也避免测试 artifact 污染后续真实部署的审计。3.4 旧 token 吊销Old token revocationISC-9 ~ ISC-11ISC断言探针ISC-9旧 token 在新 token 激活后 ≤ 4 小时内被吊销curl /v1/tokens/old-id返回revoked_at已填充ISC-10用旧 token 发起部署在吊销后 60 秒内返回 401curl -H Authorization: Bearer $OLD_TOKEN /v1/deploys -X POST返回 401ISC-11吊销事件记录在组织的认证审计日志中含操作者、时间、原因SIEM 中查询最近一小时的token_revoked事件吊销是轮换的下半场也是最常被偷懒的部分。ISC-9 用 4 小时上限防止旧 token 无限期存活ISC-10 验证吊销真的生效而不是已提交吊销请求——用旧 token 实测 401这是最直接的证伪方式ISC-11 把轮换接入组织的审计链路为事后追溯留证据。3.5 文档DocumentationISC-12 ~ ISC-13ISC断言探针ISC-12更新docs/runbooks/credential-rotation.md记录新 token 的 ID 与轮换日期runbook 文件内容检查ISC-13在团队日历中安排下次轮换提醒now 90 天 - 14 天提前预警日历事件检查这两条属于运维知识闭环轮换完成后下一位执行者可能是新同事、也可能是半年后的自己必须能从 runbook 得知本次轮换的 ID 与时间90 天 - 14 天的提前量是防到期才发现的保险丝。注意示例中的docs/runbooks/credential-rotation.md与bash scripts/credential-leak-audit.shISC-14 探针都是教学占位符——文件头注释明确说明 The CI pipeline and credential surfaces here are teaching placeholders真实场景中应替换为组织实际路径与脚本。3.6 反标准Anti-criteriaISC-14 ~ ISC-16ISC类型断言探针ISC-14Anti: privacy两个 token 值都不出现在任何 commit message、PR 描述、Slack/邮件或 CI 日志中git log --all -S $(echo $NEW_TOKEN \| head -c 8) --oneline返回空旧 token 同样ISC-15Anti: scope creep新 token 不具有admin:write、users:write或任何超出deploy:write的 scopetoken 元数据 scope 列表比对ISC-16Anti: rollback safety旧 token 在新 token 部署验证后至少保持活跃 ≥ 30 分钟以便轮换失败时可重新固定旧 token激活/吊销事件时间戳显示 ≥ 30 分钟间隔反标准是这份 ISA 最有深度的部分。对照 SKILL.md 的三护栏分类法Three-Guardrail TaxonomyPrinciples 约束思考、Constraints 约束解空间、Out of Scope 约束愿景而Anti-criteria 约束测试面——它们是前三者转化为可探测断言的派生形式。在这个示例中**ISC-14隐私**把别把 token 发到群里这种原则变成可执行的git log -S与日志 grep 探针覆盖 commit、PR、IM、CI 日志四个泄露表面**ISC-15范围蔓延**把最小权限原则变成 scope 列表精确比对——防止顺手加admin:writeISC-16回滚安全是最反直觉也最有价值的一条它刻意要求旧 token 至少存活 30 分钟为的是给失败留下退路。文件注释点明ISC-16 明确保留了一个安全窗口——这是从过去搞砸的轮换中吸取的真实教训。这体现了 ISA 反标准的设计哲学反标准不是不要做 X的口号而是可证伪的失败模式断言。四、Test Strategy六类探针的 YAML 契约示例用 YAML 块声明测试策略## Test Strategy将 16 条 ISC 中的代表性条目绑定到具体的探测工具与阈值。原文档的完整策略如下- isc: ISC-1 type: api-probe check: new tokens scope list is exactly [deploy:write] threshold: scopes [deploy:write] tool: curl -s -H Authorization: Bearer $NEW_TOKEN https://deploy.example.org/v1/me | jq -r .scopes | sort | join(,) - isc: ISC-5 type: log-grep check: new token value never appears in CI logs threshold: 0 matches tool: gh run view --log | rg $(echo $NEW_TOKEN | head -c 8) - isc: ISC-6 type: integration check: test deploy with new token succeeds threshold: exit 0 tool: gh workflow run deploy.yml --ref rotation-test wait-for-completion - isc: ISC-10 type: api-probe check: old token is rejected threshold: HTTP 401 tool: curl -i -H Authorization: Bearer $OLD_TOKEN -X POST https://deploy.example.org/v1/deploys - isc: ISC-14 type: privacy check: neither tokens first 8 chars appear in any tracked log/commit/artifact threshold: 0 matches across all surfaces tool: bash scripts/credential-leak-audit.sh - isc: ISC-16 type: timing check: gap between new-token-active and old-token-revoked ≥ 30 min threshold: ≥ 1800s tool: jq .activated - .revoked rotation-log.json4.1 探针类型与阈值六条策略覆盖了运维任务需要的全部验证模态api-probeISC-1、ISC-10对部署目标 API 发真实 HTTP 请求验证 scope 精确性与吊销生效阈值分别是scope 列表精确等于与HTTP 401——直接、可重复、可在 CI 中定时重放log-grepISC-5用gh run view --log拉取 CI 日志并 grep token 前缀阈值0 匹配是隐私断言的标准形式integrationISC-6触发真实工作流gh workflow run deploy.yml --ref rotation-test并等待完成阈值exit 0——这是唯一真正跑一遍的探针也是验证阶段的主干privacyISC-14多表面tracked log/commit/artifact扫描阈值全表面 0 匹配timingISC-16对rotation-log.json做jq .activated - .revoked数值计算阈值≥ 1800s——把留出回滚窗口这个时间约束变成机器可判定的数字。4.2 与现行格式规范的关系需要指出示例文件带注释说明它是v2.15.0 之前的旧格式带已退役的effort:/mode:键与## Criteria旧标题因此它的 Test Strategy 使用 YAML 块而现行 ISAFormat.md 规定## Test Strategy必须是六列可扩展至八列Markdown 表格列序契约为isc | type | check | threshold | tool | anchors_to | severity | tier。Bunker 的解析器Bunker/src/isa.ts私有实现、发布时排除按位置读取cells[1]type … cells[5]anchors_to——示例注释中的教训一个发明出来的 type 或非表格YAML块会被解析成零探针。换句话说在真实仓库中请使用规范规定的表格列序并把type取值为受控词表bash/bun-test/bun-property/curl/manual/screenshot/eval之一。同时ISAFormat.md 的 v2.20.0 引入了验证器三分类deterministicbash/curl/bun-test/bun-property/screenshot工具说了算、可阻塞门禁、judgedeval受限于 rubrik 的模型、attestedmanual由委托人认定。本示例中的全部探针都属于 deterministic 类——这正是运维任务的标准形态凭据轮换不该依赖任何人感觉 OK。五、源码级机制ISA 如何被机械地强制执行5.1 Completeness Gate 与 CheckCompletenessISC-14/15/16 三条反标准不是装饰——CheckCompleteness.md 工作流规定substantial 及以上体量的工作反标准数量为 0 是 HARD fail≥1 条反标准一个零失败模式值得命名的目标是被低估规格的。同时每条叶 ISC 必须有 Test Strategy 行绑定探针orphan 叶节点在 substantial 级是 HARD fail。16 条 ISC、6 条已命名探针、3 条反标准——这份示例刚好踩在 E2extended体量的结构底线上。5.2 ISAGate 的机械硬门禁ISAFormat.md 的 v2.16.0 起机械结构子集在关闭转换写phase: complete时由 ISAGate.ts 强制经 ISAGate.hook.ts 接入 StopGates 链硬阻塞条件包括progress:不是机械的M/N计数、## Not yet specified存在未解决行关闭时 fog 必须为空、设置了principal_stated_goal时 Test Strategy 行缺少anchors_to。而反标准数量、每条 claim 的探针覆盖等可被数量游戏攻破的检查仅作 advisory——这是 Goodhart 定律的防御用数量当门禁只会制造凑数的数量。5.3 ID 稳定性与 Frontier 边本示例的 16 条 ISC 在轮换过程中会不断被勾选。如果执行中发现 ISC-7 其实包含两个独立失败模式比如 artifact 注册成功但标签格式错误正确做法是保留ISC-7作为父项、新增ISC-7.1/ISC-7.2绝不重编号ID-Stability RuleSKILL.md 的 Gotchas 首条若某条 ISC 被放弃则留下墓碑- [ ] ISC-N: [DROPPED — see Decisions YYYY-MM-DD]。若轮换任务存在真实执行顺序例如先吊销再验证部署这种危险次序v2.21.0 允许在 claim 行尾追加(after: ISC-N)边由 IsaFrontier.ts 计算当前可执行集合——不过多数运维 ISA 是顺序天然的凭据轮换本身就是流水线通常不需要显式边。5.4 关闭时的证据坍缩执行完成后## Verification章节的每条记录坍缩为单行溯源桩commit hash、测试名或探针引用而不是保留证据段落变更史以git log -- isa-path为准ISA 文档内不再维护 changelogAlgorithm v8.7.1 claim 12见 SKILL.md。这意味着轮换完成后ISC-4: gh secret list updated_at 2026-02-08T22:31Z这样一行就是全部证据——证明在 git 与 CI 中ISA 只负责指向。六、把凭据轮换 ISA落地到你的仓库6.1 六工作流路径在 LifeOS 中ISA 由 ISA 技能目录 的六个工作流生成与维护工作流触发动词在本场景的用途Scaffoldscaffold、new ISA from this prompt从轮换 DEPLOY_API_TOKEN一句话生成骨架Interviewinterview me、deepen补齐模糊章节——比如问清 CI 提供方是 GitHub Actions 还是其他、旧 token 泄露面有哪些Grillgrill me、figure out the shape对半成品想法做对抗式盘问找出没想过的失败模式CheckCompletenesscheck、is it complete?轮换前按 substantial 体量打分硬缺口阻断 closeReconcilereconcile若用 ephemeral 文件把轮换任务交给独立上下文执行按稳定 ID 合并回主文件Appendappend decision、append verification记录 Decisions 与单行验证桩6.2 实操建议从示例到生产的四点改造替换教学占位符示例中的deploy.example.org域名、rotation-log.json、scripts/credential-leak-audit.sh均为虚构占位文件头注释已声明。落地时换成组织的真实 API 端点、日志路径与泄露审计脚本并把 Test Strategy 从 YAML 改为规范规定的isc | type | check | threshold | tool | anchors_to表格。沿用反标准三件套privacy防泄露、scope creep防范围蔓延、rollback safety防无退路是运维任务的高频失败模式几乎可直接复用再按组织情况补充例如旧 token 在 4 小时窗口内必须吊销这类合规断言。把探针挂进监控v2.20.0 的 execution tier 允许把deep探针如 90 天到期前扫描、定期重放 401 验证交给 Bunker 的云端调度按小时运行让轮换效果在两次轮换之间持续被验证。保持 ID 稳定任何增删改都通过ISC-N.M拆分或[DROPPED]墓碑进行因为 Decisions、Verification 与 Reconcile 全部以 ID 为键。七、总结运维手册 → 可证伪的验收契约把 e2-rotate-credential.md 这份示例读完你会得到一个可复用的心智模型任何高风险运维操作都可以写成一个 Problem → Goal → 16 条可证伪 ISC → 6 类探针的 ISA。它同时具备五重身份——既是对done的表述又是测试套件又是构建验证又是完成条件又是系统记录。探针负责说不token 没配上是 ISC-4 的探针失败旧 token 还在活是 ISC-9/10 的探针失败日志里出现 token 前 8 字符是 ISC-5/14 的探针失败。当所有探针都通过、progress: 16/16、phase: complete时轮换才算真正完成——而这整个过程从 ISA 技能 到 格式规范 再到 ISAGate 的机械门禁构成了一个不依赖任何人记忆的闭环。值得最后强调这份示例同时展示了一个反直觉的设计智慧——回滚安全窗口ISC-16被显式写成标准。好的运维不是越快越好而是任何时候都留得住退路ISA 的价值正在于把这种退路从经验变成可验证、可审计、可传承的契约。【免费下载链接】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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 用 ISA 把 CI 凭据轮换写成 16 条可验证的验收标准：LifeOS 运维任务（Ops ISA）实战拆解
用 ISA 把 CI 凭据轮换写成 16 条可验证的验收标准LifeOS 运维任务Ops ISA实战拆解【免费下载链接】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导读凭据轮换credential rotation是每个团队迟早要面对的运维高危动作新 token 没配上、旧 token 没吊销、日志里泄露了明文、或者轮换后下一次部署直接失败。LifeOS 的 ISAIdeal State Artifact理想状态工件把这套高风险运维手册改写为一份自带验收探针probe的任务文档——不再依赖记得按步骤做而是把每一步都变成一条可被工具证伪的 ISCIdeal State Criteria。本文以仓库中 e2-rotate-credential.md 这份官方示例为骨架逐条拆解其 16 条验收标准与 6 类测试策略并结合 ISA 技能定义、ISA 格式规范 与 ISA 系统文档 说明其底层机制读完你可以照此模式为自己的 CI 管道设计一份可执行、可回滚、可审计的凭据轮换 ISA。一、为什么运维任务也需要一份 ISA1.1 ISA 的本质把done写成可证伪的断言在 LifeOS 中ISA 是一个具有五种身份的单一工件理想状态表述ideal state articulation、测试夹具test harness、构建验证build verification、完成条件done condition与事实记录system of record。核心主张是done 必须被写成难以变形的解释——即每一条 ISC 都必须能命名一个可以推翻它的测试。正如 ISASystem.md 所述一个 ISC 难以变形当且仅当你能命名一个会使其失败的测试。无法说出失败长什么样这条 ISC 就可以被任何东西满足。这直接对应 ISAFormat 中的经典对照邮件被送达了是几乎任何发送路径都能满足的废话而邮件在 60 秒内进入收件箱主标签而非推广/垃圾箱是命名了具体失败方式的承重断言。凭据轮换正是这种垃圾断言重灾区——更新了密钥吊销了旧 token听起来像标准但既不精确也无法自动验证。1.2 运维任务与代码任务共用同一个原语e2-rotate-credential.md 文件末尾的注释点明了这一设计意图E2 ops ISA。必需章节Problem、Goal、Criteria、Test Strategy。演示了 ISA 原语应用于 ops/runbook 任务——与代码任务形状完全相同。ISC 数量 16 恰好达到 E2 下限。反标准ISC-14/15/16覆盖隐私、范围与回滚安全——典型运维任务的回归预防关注点。也就是说ISA 的十七节结构见 SKILL.md 的章节表对运维任务与代码任务一视同仁## Problem说明现状痛点## Goal给出可验证的完成表述## Claims/## Criteria存放原子化断言## Test Strategy为每条断言绑定探针。区别只在于探针形态代码任务多用bun-test运维任务则几乎全部是curl、gh、git log与jq组合。二、任务骨架frontmatter 与 Problem/Goal2.1 frontmatter最小化载荷示例文件的 YAML frontmatter 是task: Rotate the production deploy credential in the CI pipeline slug: 20260208-103000_rotate-deploy-credential effort: extended effort_source: explicit phase: execute progress: 0/16 mode: interactive started: 2026-02-08T18:30:00Z updated: 2026-02-08T18:30:00Z对照 ISAFormat.md 的 Field Rules这里的effort:/effort_source:/mode:属于已退役字段——effort 分级体系于 2026-07-11 退役、mode 系统同日退役新版 ISA 不再书写它们但旧 ISA 中的这些键仍被宽容解析。真正承重的是phase:与progress:progress: 0/16表示 16 条 ISC 尚未关闭任何一条且这个数字必须是机械计数不允许是感觉快完成了的主观值。2.2 Problem把风险讲清楚示例的 Problem 段是典型的现状 风险 违约触发三要素写法生产部署凭据CI 中以DEPLOY_API_TOKEN存储的长效 API token已签发 14 个月、从未轮换、对部署目标拥有宽泛写权限。按组织季度轮换策略已逾期。需要在不断送下一次部署、且不让旧 token 存活过久的前提下完成轮换。这段文字回答了 ISA 第一节要求的问题——现在什么坏了或缺失使得理想状态值得追求。在凭据轮换场景里风险来源明确暴露面随时间线性增长token 已在 14 个月的 CI 日志、Artifact、开发者本地环境中流转而轮换本身又是高危动作改坏了立刻阻断发布。Problem 写清楚Goal 才有靶子。2.3 Goal1-3 句话的可验证完成表述端到端轮换DEPLOY_API_TOKEN以相同 scope 签发新 token、更新 CI 密钥、在非生产分支上执行一次验证部署、然后吊销旧 token。本次轮换后的下一次生产部署必须成功且旧 token 必须在新 token 生效后 4 小时内失效。注意 Goal 的措辞全部指向可测量结果同 scope、非生产分支、验证部署成功、4 小时失效窗口。没有一句是尽量尽快这类无法验证的形容词。这与 ISAFormat 的 Goal 规范一致——Goal 是可变形脊柱hard-to-vary spine如果删改 Goal 而不影响 ISC 集合说明 Goal 不是承重的。三、16 条 ISC 全解完整继承与逐条分析示例的核心是 16 条按生命周期分组的验收标准。每条都遵循同一格式- [ ] ISC-N: 断言文本probe: 验证命令。下面完整保留并逐组拆解。3.1 轮换前Pre-rotationISC-1 ~ ISC-3ISC断言探针ISC-1新 token 仅授予deploy:writescope无更宽 scopecurl -H Authorization: Bearer $NEW_TOKEN /v1/me返回 scopes 恰为[deploy:write]ISC-2新 token 90 天后过期curl /v1/tokens/id显示expires_at≤ 90 天ISC-3新 token 的created_by是轮换 runbook 服务账号而非个人用户token 元数据这三条构成最小权限 有期限 可审计归属的签发铁三角。最小权限ISC-1直接对抗的是运维中常见的顺手多给权限90 天有效期ISC-2把长效 token变成有时限的与 Goal 中季度轮换策略呼应服务账号归属ISC-3保证审计时能区分机器发起的轮换与个人私自签发。3.2 CI 更新CI updateISC-4 ~ ISC-5ISC断言探针ISC-4CI 提供方中的DEPLOY_API_TOKEN密钥已更新为新值gh secret list --repo org/repo显示updated_at在最近 5 分钟内ISC-5没有任何 commit、日志行或 artifact 以字符串形式包含新 token 值gh run view run-id --log \| rg $(echo $NEW_TOKEN \| head -c 8) \| wc -l返回 0ISC-4 的探针设计值得注意它不检查密钥值对不对CI 提供方的 API 通常不允许读回密钥明文而是用updated_at时间戳作为间接证据——5 分钟窗口既足够新确实是本次轮换改的又不至于误伤。ISC-5 是防泄露的第一道闸只取 token 前 8 个字符做匹配head -c 8既不把完整 token 写进探针命令避免探针自身成为泄露源又能捕捉任何明文出现。3.3 验证VerificationISC-6 ~ ISC-8ISC断言探针ISC-6在rotation-test分支上使用新 token 的测试部署成功部署 job exit 0部署目标 API 确认新 artifact 已注册ISC-7验证部署创建的 artifact 带rotation-test-timestamp标签且可删除curl /v1/artifacts?tagrotation-test能列出该 artifactISC-8验证后清理在 60 分钟内移除测试 artifactcurl /v1/artifacts/id清理后返回 404这三条是把新 token 能用从口头保证变成实证的关键链路先在小分支上真跑一次部署ISC-6给测试产物打上可识别的标签ISC-7规定清理时限ISC-8。测试 deploy 成功如果不附上 exit 0 和 artifact 注册证据就可能被看起来成功糊弄过去而 ISC-8 确保验证本身不留下垃圾——这既是对部署目标的卫生要求也避免测试 artifact 污染后续真实部署的审计。3.4 旧 token 吊销Old token revocationISC-9 ~ ISC-11ISC断言探针ISC-9旧 token 在新 token 激活后 ≤ 4 小时内被吊销curl /v1/tokens/old-id返回revoked_at已填充ISC-10用旧 token 发起部署在吊销后 60 秒内返回 401curl -H Authorization: Bearer $OLD_TOKEN /v1/deploys -X POST返回 401ISC-11吊销事件记录在组织的认证审计日志中含操作者、时间、原因SIEM 中查询最近一小时的token_revoked事件吊销是轮换的下半场也是最常被偷懒的部分。ISC-9 用 4 小时上限防止旧 token 无限期存活ISC-10 验证吊销真的生效而不是已提交吊销请求——用旧 token 实测 401这是最直接的证伪方式ISC-11 把轮换接入组织的审计链路为事后追溯留证据。3.5 文档DocumentationISC-12 ~ ISC-13ISC断言探针ISC-12更新docs/runbooks/credential-rotation.md记录新 token 的 ID 与轮换日期runbook 文件内容检查ISC-13在团队日历中安排下次轮换提醒now 90 天 - 14 天提前预警日历事件检查这两条属于运维知识闭环轮换完成后下一位执行者可能是新同事、也可能是半年后的自己必须能从 runbook 得知本次轮换的 ID 与时间90 天 - 14 天的提前量是防到期才发现的保险丝。注意示例中的docs/runbooks/credential-rotation.md与bash scripts/credential-leak-audit.shISC-14 探针都是教学占位符——文件头注释明确说明 The CI pipeline and credential surfaces here are teaching placeholders真实场景中应替换为组织实际路径与脚本。3.6 反标准Anti-criteriaISC-14 ~ ISC-16ISC类型断言探针ISC-14Anti: privacy两个 token 值都不出现在任何 commit message、PR 描述、Slack/邮件或 CI 日志中git log --all -S $(echo $NEW_TOKEN \| head -c 8) --oneline返回空旧 token 同样ISC-15Anti: scope creep新 token 不具有admin:write、users:write或任何超出deploy:write的 scopetoken 元数据 scope 列表比对ISC-16Anti: rollback safety旧 token 在新 token 部署验证后至少保持活跃 ≥ 30 分钟以便轮换失败时可重新固定旧 token激活/吊销事件时间戳显示 ≥ 30 分钟间隔反标准是这份 ISA 最有深度的部分。对照 SKILL.md 的三护栏分类法Three-Guardrail TaxonomyPrinciples 约束思考、Constraints 约束解空间、Out of Scope 约束愿景而Anti-criteria 约束测试面——它们是前三者转化为可探测断言的派生形式。在这个示例中**ISC-14隐私**把别把 token 发到群里这种原则变成可执行的git log -S与日志 grep 探针覆盖 commit、PR、IM、CI 日志四个泄露表面**ISC-15范围蔓延**把最小权限原则变成 scope 列表精确比对——防止顺手加admin:writeISC-16回滚安全是最反直觉也最有价值的一条它刻意要求旧 token 至少存活 30 分钟为的是给失败留下退路。文件注释点明ISC-16 明确保留了一个安全窗口——这是从过去搞砸的轮换中吸取的真实教训。这体现了 ISA 反标准的设计哲学反标准不是不要做 X的口号而是可证伪的失败模式断言。四、Test Strategy六类探针的 YAML 契约示例用 YAML 块声明测试策略## Test Strategy将 16 条 ISC 中的代表性条目绑定到具体的探测工具与阈值。原文档的完整策略如下- isc: ISC-1 type: api-probe check: new tokens scope list is exactly [deploy:write] threshold: scopes [deploy:write] tool: curl -s -H Authorization: Bearer $NEW_TOKEN https://deploy.example.org/v1/me | jq -r .scopes | sort | join(,) - isc: ISC-5 type: log-grep check: new token value never appears in CI logs threshold: 0 matches tool: gh run view --log | rg $(echo $NEW_TOKEN | head -c 8) - isc: ISC-6 type: integration check: test deploy with new token succeeds threshold: exit 0 tool: gh workflow run deploy.yml --ref rotation-test wait-for-completion - isc: ISC-10 type: api-probe check: old token is rejected threshold: HTTP 401 tool: curl -i -H Authorization: Bearer $OLD_TOKEN -X POST https://deploy.example.org/v1/deploys - isc: ISC-14 type: privacy check: neither tokens first 8 chars appear in any tracked log/commit/artifact threshold: 0 matches across all surfaces tool: bash scripts/credential-leak-audit.sh - isc: ISC-16 type: timing check: gap between new-token-active and old-token-revoked ≥ 30 min threshold: ≥ 1800s tool: jq .activated - .revoked rotation-log.json4.1 探针类型与阈值六条策略覆盖了运维任务需要的全部验证模态api-probeISC-1、ISC-10对部署目标 API 发真实 HTTP 请求验证 scope 精确性与吊销生效阈值分别是scope 列表精确等于与HTTP 401——直接、可重复、可在 CI 中定时重放log-grepISC-5用gh run view --log拉取 CI 日志并 grep token 前缀阈值0 匹配是隐私断言的标准形式integrationISC-6触发真实工作流gh workflow run deploy.yml --ref rotation-test并等待完成阈值exit 0——这是唯一真正跑一遍的探针也是验证阶段的主干privacyISC-14多表面tracked log/commit/artifact扫描阈值全表面 0 匹配timingISC-16对rotation-log.json做jq .activated - .revoked数值计算阈值≥ 1800s——把留出回滚窗口这个时间约束变成机器可判定的数字。4.2 与现行格式规范的关系需要指出示例文件带注释说明它是v2.15.0 之前的旧格式带已退役的effort:/mode:键与## Criteria旧标题因此它的 Test Strategy 使用 YAML 块而现行 ISAFormat.md 规定## Test Strategy必须是六列可扩展至八列Markdown 表格列序契约为isc | type | check | threshold | tool | anchors_to | severity | tier。Bunker 的解析器Bunker/src/isa.ts私有实现、发布时排除按位置读取cells[1]type … cells[5]anchors_to——示例注释中的教训一个发明出来的 type 或非表格YAML块会被解析成零探针。换句话说在真实仓库中请使用规范规定的表格列序并把type取值为受控词表bash/bun-test/bun-property/curl/manual/screenshot/eval之一。同时ISAFormat.md 的 v2.20.0 引入了验证器三分类deterministicbash/curl/bun-test/bun-property/screenshot工具说了算、可阻塞门禁、judgedeval受限于 rubrik 的模型、attestedmanual由委托人认定。本示例中的全部探针都属于 deterministic 类——这正是运维任务的标准形态凭据轮换不该依赖任何人感觉 OK。五、源码级机制ISA 如何被机械地强制执行5.1 Completeness Gate 与 CheckCompletenessISC-14/15/16 三条反标准不是装饰——CheckCompleteness.md 工作流规定substantial 及以上体量的工作反标准数量为 0 是 HARD fail≥1 条反标准一个零失败模式值得命名的目标是被低估规格的。同时每条叶 ISC 必须有 Test Strategy 行绑定探针orphan 叶节点在 substantial 级是 HARD fail。16 条 ISC、6 条已命名探针、3 条反标准——这份示例刚好踩在 E2extended体量的结构底线上。5.2 ISAGate 的机械硬门禁ISAFormat.md 的 v2.16.0 起机械结构子集在关闭转换写phase: complete时由 ISAGate.ts 强制经 ISAGate.hook.ts 接入 StopGates 链硬阻塞条件包括progress:不是机械的M/N计数、## Not yet specified存在未解决行关闭时 fog 必须为空、设置了principal_stated_goal时 Test Strategy 行缺少anchors_to。而反标准数量、每条 claim 的探针覆盖等可被数量游戏攻破的检查仅作 advisory——这是 Goodhart 定律的防御用数量当门禁只会制造凑数的数量。5.3 ID 稳定性与 Frontier 边本示例的 16 条 ISC 在轮换过程中会不断被勾选。如果执行中发现 ISC-7 其实包含两个独立失败模式比如 artifact 注册成功但标签格式错误正确做法是保留ISC-7作为父项、新增ISC-7.1/ISC-7.2绝不重编号ID-Stability RuleSKILL.md 的 Gotchas 首条若某条 ISC 被放弃则留下墓碑- [ ] ISC-N: [DROPPED — see Decisions YYYY-MM-DD]。若轮换任务存在真实执行顺序例如先吊销再验证部署这种危险次序v2.21.0 允许在 claim 行尾追加(after: ISC-N)边由 IsaFrontier.ts 计算当前可执行集合——不过多数运维 ISA 是顺序天然的凭据轮换本身就是流水线通常不需要显式边。5.4 关闭时的证据坍缩执行完成后## Verification章节的每条记录坍缩为单行溯源桩commit hash、测试名或探针引用而不是保留证据段落变更史以git log -- isa-path为准ISA 文档内不再维护 changelogAlgorithm v8.7.1 claim 12见 SKILL.md。这意味着轮换完成后ISC-4: gh secret list updated_at 2026-02-08T22:31Z这样一行就是全部证据——证明在 git 与 CI 中ISA 只负责指向。六、把凭据轮换 ISA落地到你的仓库6.1 六工作流路径在 LifeOS 中ISA 由 ISA 技能目录 的六个工作流生成与维护工作流触发动词在本场景的用途Scaffoldscaffold、new ISA from this prompt从轮换 DEPLOY_API_TOKEN一句话生成骨架Interviewinterview me、deepen补齐模糊章节——比如问清 CI 提供方是 GitHub Actions 还是其他、旧 token 泄露面有哪些Grillgrill me、figure out the shape对半成品想法做对抗式盘问找出没想过的失败模式CheckCompletenesscheck、is it complete?轮换前按 substantial 体量打分硬缺口阻断 closeReconcilereconcile若用 ephemeral 文件把轮换任务交给独立上下文执行按稳定 ID 合并回主文件Appendappend decision、append verification记录 Decisions 与单行验证桩6.2 实操建议从示例到生产的四点改造替换教学占位符示例中的deploy.example.org域名、rotation-log.json、scripts/credential-leak-audit.sh均为虚构占位文件头注释已声明。落地时换成组织的真实 API 端点、日志路径与泄露审计脚本并把 Test Strategy 从 YAML 改为规范规定的isc | type | check | threshold | tool | anchors_to表格。沿用反标准三件套privacy防泄露、scope creep防范围蔓延、rollback safety防无退路是运维任务的高频失败模式几乎可直接复用再按组织情况补充例如旧 token 在 4 小时窗口内必须吊销这类合规断言。把探针挂进监控v2.20.0 的 execution tier 允许把deep探针如 90 天到期前扫描、定期重放 401 验证交给 Bunker 的云端调度按小时运行让轮换效果在两次轮换之间持续被验证。保持 ID 稳定任何增删改都通过ISC-N.M拆分或[DROPPED]墓碑进行因为 Decisions、Verification 与 Reconcile 全部以 ID 为键。七、总结运维手册 → 可证伪的验收契约把 e2-rotate-credential.md 这份示例读完你会得到一个可复用的心智模型任何高风险运维操作都可以写成一个 Problem → Goal → 16 条可证伪 ISC → 6 类探针的 ISA。它同时具备五重身份——既是对done的表述又是测试套件又是构建验证又是完成条件又是系统记录。探针负责说不token 没配上是 ISC-4 的探针失败旧 token 还在活是 ISC-9/10 的探针失败日志里出现 token 前 8 字符是 ISC-5/14 的探针失败。当所有探针都通过、progress: 16/16、phase: complete时轮换才算真正完成——而这整个过程从 ISA 技能 到 格式规范 再到 ISAGate 的机械门禁构成了一个不依赖任何人记忆的闭环。值得最后强调这份示例同时展示了一个反直觉的设计智慧——回滚安全窗口ISC-16被显式写成标准。好的运维不是越快越好而是任何时候都留得住退路ISA 的价值正在于把这种退路从经验变成可验证、可审计、可传承的契约。【免费下载链接】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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考