[rockyshi1993]

Original agreed roadmap — Phase 2 (after S07, before S13)

Strict scope: unify Interactive static compilation with Standard's existing project root and Skill validation options; remove wrong rejection of shared checkStep on pure Condition/Terminal; pin Host-provided binding version identities via existing policyHash (no new binding runtime); measure verified Program repeated-loading first, optimize only if justified.

Scope

• Reuse normalizeOptions and resolveProjectRoot for projectRoot, skillsRoot, skillCheck, remoteSkillHosts. No importing source, no network fetching. Keep Interactive-only options output/featureStage and reject irrelevant Standard runtime/diagram options, preserving strict configuration contract.
• The verified P0-A Program's required Agent bindings determine checkStep rejection, not the accidental presence of an unused method on an otherwise pure Host.
• Explicit binding versions are Host-owned identities declared under policy.bindingVersions, which the current Coordinator already fingerprints and checks across restarts. Functions and external Skill contents are NOT automatically hashed by FlowKit; Host is responsible for bumping versions when implementations/dependencies change. See new docs and regression tests.
• Verified benchmark: 16 Condition nodes, 15,908 B Program, before-cache sampled total Run 147.468 ms with 34 Store reads; after-cache sampled total Run 30.681 ms with 34 Store reads. This is diagnostic sample data, not an SLA. Added 4-entry per-Coordinator verified Program LRU: the Store is still re-read and exact bytes/identity/policy checked at every phase. Tests prove tamper/missing/changed identity rejects even after cache warmup.

Validation and gates

• tests/interactive/stage2-integration.test.mjs: nested package.json root parity, local/custom/remote Skills, integrity/allowlist, wrong options/accessors, pure vs Agent checkStep, version-pinned resume mismatch and exact-State no-mutation.
• Type declarations and TS consumer updated for static configuration and no-Agent callback.
• All Standard API, P0-A Program ABI, M5 Host security, M6 S07 recovery, and packaging remain unchanged.
• Final exact HEAD: Ubuntu/Windows × Node22/24 npm run verify + docs, website, Linux OS security checks; independent review; squash merge only if all pass. M6 PR test(interactive): M6 P0-A integrated Host acceptance and cross-process verification #7 stays Draft pending real-model S13. No P0-B/P1/P2, Context, artifact providers, releases or deployment.

---

Note

Medium Risk
Touches compile-time Skill policy, runtime Host binding checks, and Coordinator load paths where incorrect caching or policy handling could affect run integrity; mitigated by fail-closed checks and explicit negative tests.

Overview
Aligns Interactive P0-A static compilation with Standard: compileInteractive now accepts projectRoot, skillsRoot, skillCheck, and remoteSkillHosts via the same discovery/normalization as Standard, while still rejecting unrelated Standard runtime options.

Coordinator behavior is tightened for Stage 2: unused runtime.checkStep is allowed only for Programs with no Agent bindings; Agent graphs still fail closed. Host binding drift is enforced through the existing policyHash (e.g. policy.bindingVersions), without a new API.

Adds a per-coordinator 4-entry LRU of verified Programs. Every phase still re-reads Store artifacts, re-hashes bytes, and checks identity/policy—even on cache hits—with new regression tests for tamper/mismatch cases.

Documentation (interactive-stage2-contract.md), type declarations, integration/cache tests, a diagnostic bench-interactive-load.mjs, and a Ubuntu/Node 24 CI measurement step complete the Stage 2 evidence path.

^{Reviewed by Cursor Bugbot for commit 4559755. Bugbot is set up for automated code reviews on this repo. Configure here.}

[rockyshi1993]

Stage 2 — 源码复审 / 精确 HEAD 验收（2026-11-11）

受审提交： 45597554602518b1bfd20cae3ab72d2c59f2fa98；基线 main@674a3a92b128877f07e4f31590aab4bab306c698。独立审查 PR #10 的 10 个修改文件，源/类型/测试/CI/文档一致性。原计划中的阶段一 S07 已完成；本轮没有把 S13 提前，也没有进入 P0-B。

A. 集成契约修复：通过

• compileInteractive 复用 Standard normalizeOptions 与 resolveProjectRoot，支持且只支持此阶段必要静态参数 projectRoot,skillsRoot,skillCheck,remoteSkillHosts。默认寻找最近 package.json，同一份原分析器给出相同诊断；不加载/执行用户 DSL 源码，不在编译时下载远程 Skill，不接受无关的 Standard trace/mermaid/fetch。
• 正反例：嵌套工作流文件、默认/显式项目根目录、定制 Skill 根目录、缺失 Skill、skillCheck:false、*.workflow.ts、HTTPS Skill 域名白名单和 integrity、非法字段/访问器/类型，以及内存/文件编译输出。均已通过。
• P0-A 纯 Condition/Terminal 的 Host 包含无关 checkStep 时不再误拒；涉及 Agent Program 仍对非空 checkStep 拒绝且无 Run 落库，避免暗中跳过未支持的验证逻辑。
• **绑定版本边界没有越权：**没有实现新的 Bindings Runtime。Host 使用已有 policy.bindingVersions 声明版本；原本的 policyHash 会在恢复时阻止版本变化，负例证明拒绝不修改 Checkpoint/Journal，同版本正常完成。**重要限制：**FlowKit 不能自动识别 JS 回调的闭包、磁盘 Skill 或外部依赖是否变化。版本声明目前兼容性优先仍为 Host 的显式义务，并非由 FlowKit 强制推导。不可声称所有实际绑定漂移均自动防护。

B. Program 重复加载：先测量再优化，通过

• 同一 Ubuntu Node24 基准环境、同类型 Program（15,908 bytes，16 个 Condition 节点）：初始样本 34 次 SQLite Program 读取、全部运行 147.468 ms、验证 loader 热样本中位数 5.386 ms；内存复用后仍 34 次 Program 读取、全部运行 30.681 ms、原 loader 中位数 3.888 ms。跨 CI run 环境噪声存在，不可作为 SLA，也不能认定稳定提升倍数。
• 采用每个 Coordinator 实例、最多 4 项的已验证 Program LRU，不是全局缓存；每个阶段仍重新访问 Store，核验原始 Program byte SHA、原身份、Run policyHash、Program required bindings 与执行 Block。仅复用不可变且已验证的 Program 解析结果。
• 缓存预热后模拟 Store 缺失 / 篡改字节 / 篡改 Program identity，仍在 CAS 前拒绝，Checkpoint/Journal 不变；恢复合法内容后正常推进；重复 resume 的终态、State 和 Journal 仍一致。以上正反例与原 M1–M5 + S07 回归均通过。

C. 正式 CI / 安全与兼容性

GitHub Actions 42954236755：精确 HEAD 7/7 completed/success。Ubuntu 24.04 / Windows 2025 × Node 22.13.0 / 24.22.1 各 357/357 PASS，0 FAIL，0 SKIP；打包、TS 类型、文档示例消费成功；website 和两个 Linux OS-user Host 隔离专项成功。

D. 复审裁决

阶段二：PASS，可以按精确 HEAD 门禁 squash merge。
已确认核心范围没有扩张：Standard 根六个 API、Interactive Program ABI V1、M5 签名模型安全、S07 容量/回执持久化、业务产物存储/Context/GC 均未改动。性能基准仅为诊断，不含生产 SLA 承诺。

**未关闭的事项：**完整需求 V0.3、技术 V0.6-R5 的逐条正式契约核查仍受原文材料可获得性限制；M6 S13 真实模型宿主原生 JS 工具日志依然 BLOCKED，PR #7 继续保持 Draft/Open。不得以本阶段 CI 结果代替真实模型 Host 验收，不得发布、部署或提前开展 P0-B/P1/P2。