Workflow API 已经在代码中,并且当前画布支持 workflow 列表加载、新建与切换。
Profiles 与 Targets API 已经在代码中,并且现在支持通过 live API 创建测试记录。
当前 staging 运行时已经接在 cloudflare-d1 上;workflow 本机默认也开始要求同一条 D1 主路径,不再静默回退到本地文件。
Autofill 节点配置与字段级映射已经在代码中,AI generated 字段现在支持提示语、长度约束、预演候选值,以及 readiness 与 AI runtime 摘要。
Review 节点现在会收口 Autofill 的复核字段与策略门禁,并在运行预演里生成待审核清单。
Run preview 里的 approve / reject 现在会重新请求 run-preview,并由后端返回 Review gate / Result gate 是否放行。
当 Result gate ready 时,当前已经可以把一次预演接受为真实 queued run,并立即写入 reserved credits ledger。
当前 preview / accept / complete / runs detail 还会统一返回 `executionBoundary` 与 `creditBoundary`,既明确区分 preview-only、queued-run、terminal-run,也会显式说明测试运行仍走同一条 credit gate。
现在 `complete-run` 与 `GET /api/runs/:runId` 也会显式返回 `executorReceipt`,把 terminal usage、audit 与写入落点收口成同一份终态凭据,后续真实执行器只需要替换 receipt 生产者。
从 Day 11 第十七刀开始,Runs 工作台还会直接渲染 `terminalResult`:现在可以在右侧 detail 里看到 sink label、reviewSummary 与实际写出的 field/value 列表,方便直接观察框架效果。
最新这一刀继续把 `executorArtifacts` 接到了同一条边界:右侧 detail 现在还会显示 pickup proof、target contract、AI runtime、review closure 与 sink-write evidence,框架效果又往前推进了一层。
workflow / profiles / targets / run-preview 当前开始统一使用 ok / meta / data / error 控制平面返回包装,便于后面接 D1、RBAC、Usage 与审计。
后端当前也开始抽成 route handler -> service -> store 三层边界,后面接执行器、权限和计费时不需要反复改路由。
Runs / Usage 现在已经补上 D1 优先的控制平面读取链路;Team 与 Projects 现在共用 foundation-governance 模型,用来锁定成员、角色、权限与 project-first 边界。
Projects 工作台与 `GET /api/projects`、`GET /api/org/context` 已进入代码,用来固定 account / project / membership 的读取边界。
Billing 工作台与 `GET /api/billing/overview` 已进入代码,并开始从共享 foundation-governance 暴露 subscription posture、credit lifecycle 与 accepted execution 的商业关系。
Usage 工作台与 `GET /api/usage` 现在也共用这份 foundation 商业真相,用来把 accepted execution path、reservation、consumed usage 与 settlement hold 放到同一条账本故事里。
Developers 工作台与 `GET /api/developer-supply` 已进入代码,并开始从共享 foundation-governance 暴露个人、企业与域名所有者三类 developer identity 的供给边界。
Marketplace 工作台与 `GET /api/marketplace/overview` 已进入代码,并开始从共享 foundation-governance 暴露 category map、listing version、install contract 与 recent install posture。
Settlement 工作台与 `GET /api/settlement/overview` 现在也共用 shared foundation,用来固定 settlement ledger stage、revenue share、payout policy、hold profile、payout account 与 ledger entries。
如果没有配置 provider,运行预演会明确回退到 local-template,并展示 fallback reason。
当 readiness 显示 ready 时,就可以开始半真实 provider 预演测试。
workflow、profiles 与 targets 的 D1-first 主路径已经落地;target detail 也开始携带最小 schema version 清单。
模块三 Day 8 已补齐数据文档与数据库验收记录;模块四 Day 1 到 Day 5 也已完成,默认命令、WSL2 主路径、staging 环境变量、smoke 路径、发布顺序与完整 drill 都已经固定。
默认 staging smoke 路径现已固定为 `npm run verify:smoke`,UI 或交互改动再追加 `npm run verify:smoke:browser`。
默认 staging 发布顺序现已固定为 `npm run release:staging`;空库 bootstrap 走 `npm run release:staging:bootstrap`,代码回退或纯重发则走 `npm run release:staging:redeploy`。
完整 staging 发布演练现已固定为 `npm run release:staging:drill`;部署操作 runbook 已收口到 `docs/staging-operations.zh-CN.md`。
模块五 Day 9 已完成;Developers、Marketplace 与 Settlement 现在都已经把二级入口、Docs Center / Help Center 入口与 placeholder routes 留全,后续接真实 onboarding、review、install、ledger、release policy 与 payout batch 不需要再补导航。
模块五 Day 10 已完成:扩展框架验收文档已经入库,下一轮真正实现优先级已锁定为组织、成员、权限,其次才是 Auth / RBAC enforcement。
构建与部署继续走 WSL2,浏览器 smoke 默认改为 Windows 主机浏览器优先,可直接运行 `npm run verify:smoke:browser`。
模块一最后那轮画布拖拽 / 连线人工确认已经在 staging 真实浏览器里补完;后续做 UI 回归时,仍建议优先在 Windows 主机浏览器里补看真实反馈。