长期方向会继续保留，但当前对外只讲已经进入真实推进节奏的三个阶段。
Editions & Roadmap
版本路线
Version Plan当前公开版本先讲 1.0 / 1.1 / 2.0，但现实使用路径已经拆成免费线、本地脚本位、标准团队版和企业交付四层。
版本阶段讲的是平台建设节奏，四层路径讲的是用户该走哪条路，这两件事不要混着讲。
ExecGov 当前的版本节奏可以这样理解： 1.0 先把真实交付、可信执行和本地接入做稳， 1.1 把自动注册、支付、续费和低客服闭环补起来， 2.0 再决定哪些部分值得继续做成更稳定的标准方案。多 Skill 编排不是当前默认能力，要等治理底座补齐后才进入正式产品化。
当前 1.0 的核心定位是：ExecGov（执治）是一个以 Python 脚本为第一种成熟执行资产的多租户能力治理与执行平台。
更后面的 3.0 / 4.0 仍保留在内部长期规划里，但当前公开路线只讲 1.0 / 1.1 / 2.0，避免把长期设想说成眼前能力。
截止当前版本，1.0 已经完成第一轮兼容式升级：通用资源层和执行器注册层已落地， 第一种非脚本能力样板是 public 超管侧的 HTTP 能力接入。 但下一步优先级仍然不是横向铺更多能力，而是先把 1.1 的自动注册、支付、续费和停开恢复做成低客服闭环。
这一轮也进一步收紧了边界： HTTP 能力接入 继续只在 public 超管治理域开放， 白名单租户 admin 只保留最小跨租户控制台； 同时系统也不再用 user_id == 1 这种条件去误判管理员。
当前 1.1 已先落下一段真实骨架：public 超管订单中心支持建单、确认支付、执行开通、续费提醒扫描、到期停开扫描； 个人免费版也已经接通本地脚本位自助增购，免费页还增加了团队版月租 / 年租注册入口说明。 但完整通用自助账单中心、真实第三方支付网关和外发提醒渠道仍未完成。
同时，标准 SaaS 共享租户前端骨架也已经建立：从 tenant_1003+ 开始，标准 SaaS 客户不再默认一客户复制一套前端工程， 而是优先走共享租户前端。它当前已经能承接正式租户入口，但动态品牌化、初始化和更细定制边界还在继续收口。
1.0 可信交付1.1 低客服闭环2.0 下一步收敛持续升级按需扩展
EXECGOV // ROADMAPDOC 06
1.0: delivery_ready / trusted_execution1.1: self_serve_trial / renewal_loop2.0: productize_proven_paths
ROADMAP SHOULD FOLLOW REAL DEMAND
优先把交付、入口闭环和可复用能力做稳，再决定哪些部分值得继续做厚。
如果你要评估这套平台现在适不适合接入，优先按下面这 4 个判断点来看，而不是被长期规划带偏。
现在1.0 的核心是可信交付、脚本接入和多租户治理
正在补1.1 重点是自动注册、续费和低客服闭环
后续再看2.0 才会决定哪些路径值得继续标准化做厚
不要误判多步骤编排和长期 3.0 / 4.0 方向都还不是当前承诺能力
1.0
可信 AI 执行交付版
- 一个客户一个租户
- 统一能力目录、脚本接入与 Skill 映射
- 当前以 Python 脚本作为第一种成熟执行资产
- 通用资源层和执行器注册层已经落地
- public 超管侧已先落一版 HTTP 能力接入样板，租户侧只开放只读台账
- 白名单租户 admin 当前只开放最小跨租户控制台，不直接开放平台治理页
- 管理员判定已按显式 admin / 超管标记收口，不再依赖
user_id == 1 - 智能大脑推荐、确认、执行、审计
- 模板分发、安装、回滚、日志
- 免登录体验页、登录 / 注册 / 注册结果页、个人技能库、智能助手、公告中心、社区广场、个人空间、升级正式版、上传脚本、HTTP 只读台账、本地脚本位轻量自助增购，以及
execgov-cli最小闭环
Next
下一阶段先收敛这些
- 把自动注册、入口开通、支付、续费、到期提醒和停开流程补成低客服闭环
- 把小团队协作里真正高频的能力收成更稳的方案
- 把套餐、额度和交付边界收敛成更清楚的产品规则
- 把共享 SaaS 租户前端的品牌化、初始化和菜单边界继续收口成稳定方案
- 把 CLI / Local Agent 的绑定码、心跳、状态和远程执行继续补成正式方案
- 把社区治理、隐藏说明页和免费版生命周期提示继续收口成稳定口径
1.1 Now
1.1 已经落地的第一段
public超管订单中心已经切到真实生命周期模式- 已支持建单、确认支付、执行开通、续费单预填、续费提醒扫描、到期停开扫描
- 个人免费版前台已经接通本地脚本位轻量自助增购，并开放团队版月租 / 年租注册入口说明
- 订单、客户和租户状态会联动回写，不再只是样例展示
1.1 Pending
1.1 还没完成的部分
- 个人免费版完整账单中心、终端用户自助续费入口和对账能力
- 真实第三方支付网关、签名验签和正式支付回调
- 邮件 / 企业微信 / 短信等外发提醒渠道
Path Ladder
版本阶段之上，当前真实使用路径怎么分层
| 层级 | 当前承接方式 | 和版本路线的关系 | 建议入口 |
|---|---|---|---|
| 免费线 | 公开体验、登录 / 注册、个人入口 | 属于 1.0 已成立的获客与体验入口 | 快速开始 |
| 本地脚本位增购 | 个人空间轻量扩容 | 属于 1.1 已落地的第一段闭环，不等于完整账单中心 | 支付与会员 |
| 标准团队版 | 共享 SaaS 正式租户入口 | 当前依托 1.0 交付底座和 1.1 升级路径继续收口 | 客户流程 / 交付 |
| 企业交付 | 单租户交付、私有化或更深部署控制 | 属于 1.0 当前最成熟的正式交付主线 | 部署方式 |
1.0 Core
1.0 当前重点
- 以 Python 脚本为第一种成熟执行资产
- Skill 继续作为用户可见的能力单元
- 资源层和执行器注册层已经补上，后面接第二、第三种能力不该再大改库
- 交付、执行、安全边界和持续更新形成闭环
- 单能力执行已经可用
- 本地桥接与 CLI 支撑更深接入
2.0 Expansion
2.0 再继续扩什么
- 在 1.1 低客服闭环稳定后，再继续把自动注册、支付、续费、提示和自助支持做成更稳的标准方案
- 更通用的能力资产注册模型
- API、数据连接器、文档模板、审批流程等更多能力接入
- 多 Skill / 多步骤编排只在补齐复合诉求拆解、节点级确认、正式降级/回退、部分成功/可恢复状态后再进入真实开发
- 安装、分发、升级和回滚策略进一步通用化
- 小团队协作、套餐化和标准能力边界继续收敛
Upgrade Route
从免费入口到正式交付，版本阶段怎么承接
01. 免费入口感知价值
先通过公开体验页、登录 / 注册 / 注册结果页和免费入口理解平台是什么；登录后的个人入口当前会继续落到技能库、智能助手、公告中心、社区广场、个人空间、升级正式版、上传脚本、HTTP 只读台账和本地脚本位轻量扩容入口，确认“AI 调度能力”这条链路是否成立。
02. 个人继续使用先走本地脚本位
如果用户已经在个人空间持续接脚本，但还没进入多人协作，当前更适合先走本地脚本位轻量增购；CLI 和本地桥接属于支撑能力，不是另一套独立商业路径。
03. 多人协作先走标准团队版
如果客户只是标准能力和较轻协作，当前可以先走共享租户前端承接的正式租户入口，先验证标准团队路径是否够用。
04. 更强边界再进入企业交付
如果涉及内网、更强隔离、专属品牌、专属页面或正式项目验收，再继续走企业 1.0 单租户交付；2.0 才是后续继续把复用路径做厚。
Current Upgrade Logic
升级路径怎么走
- 第一步先让用户通过免费入口感知价值
- 第二步如果还停留在个人持续使用，就先承接本地脚本位轻量扩容
- 第三步当用户进入多人协作时，先由标准团队版正式租户入口承接
- 第四步如果进入更强隔离和正式验收，再转企业
1.0交付；同时继续把1.1的低客服闭环补稳
What 2.0 Changes
2.0 之后，这条路径会发生什么变化
- 免费入口、小团队方案和正式交付之间的边界会更明确
- 套餐、配额、资源、转化和运营指标会收敛得更清楚
- CLI + 本地 Agent 里真正有价值的部分会继续往稳定方案靠拢
- “先体验，再按场景升级”的路径才会真正收成标准化链路
1.0 Companion Docs
1.0 落地判断可继续看这 3 页
Near-Term Focus
当前阶段的标准服务包
电商 / 内容 / 运营数据自动化
先把散落脚本、表格处理和数据整理任务收成稳定入口，这类场景最容易先成交，也最容易复用。
技术团队脚本治理与自动化运维
围绕脚本治理、任务调度、日志留痕和本地执行桥接，形成最贴近当前能力边界的一条交付线。
需要内网或私有化的小型正式客户
这类客户最能验证多租户隔离、权限边界和正式交付链路，但要控制定制深度，只接能沉淀平台能力的项目。
Why Both Lines
为什么正式客户线和免费版要并行
- 只做企业线：个人与小团队缺少低门槛验证入口
- 只做免费线：正式交付、隔离治理和长期使用能力不够完整
- 因此当前路线保持为：正式客户交付
1.0承接正式场景，个人免费版承接体验与升级入口，两条线共用同一套可信执行底座
Current Rhythm
当前版本节奏
1.0是当前已经有可用基础的交付主线1.1优先把自动注册、支付、续费、提醒和低客服支持做稳2.0是下一阶段的标准化收敛- 更多能力会按需求逐步扩展