底座层
多租户隔离、权限、公告、模板分发、日志和审计是通用底座，不只服务脚本。
Architecture
架构说明
Architecture Thesis先让不同入口共用同一套治理内核，后面才不会越做越乱。
目标不是铺更多端，而是让免费入口、正式交付和本地接入共用一套逻辑，单人维护也不容易散掉。
ExecGov（执治）是一个以 Python 脚本为第一种成熟执行资产的多租户能力治理与执行平台。
平台当前采用 单仓多前端 + 统一后端能力中心 的结构。 重点不是“组件堆多少”，而是把 平台治理、租户隔离、 免费入口 和 本地接入 收进同一套架构逻辑。
统一后端public 超管tenant 前端CLI 接入
EXECGOV // ARCH LAYOUTDOC 04
const core = 'unified_python_backend' // capability control centerconst governance = 'public_admin_console' // platform governanceconst entries = ['tenant_fronts', 'free_entry', 'execgov_cli']
ONE CORE / MULTIPLE ENTRY SURFACES
1.0 Standard
定位在架构层的落点
抽象层
Skill 是能力单元，负责输入输出、风险、审批和可见范围，不应该只按脚本文件去理解。
实现层
当前第一种成熟执行资产仍然是 Python 脚本，所以上传、注册、运行时和 CLI 现在仍然以脚本优先。
当前这层已经往前走了一步：平台新增了通用资源层和执行器注册层， 第一种非脚本能力样板 HTTP 能力接入 已先在 public 超管侧验证。 这说明底座已经不是只能“跑脚本文件”，但租户侧当前最成熟、最稳定的交付能力仍然是脚本优先。
这轮还把平台治理边界收得更清楚了： HTTP 能力接入 的配置、凭据治理和试跑仍然只放在 public 超管治理域； 白名单租户 admin 只保留最小跨租户控制台入口，租户侧只做只读查看，不把平台治理入口直接摊给租户。
从 1.1 看，当前也已经先把订单、支付确认、续费提醒扫描和到期停开扫描收在 public 治理域里， 避免一开始就把收费与生命周期逻辑散进租户前台。后面再继续补用户自助链路和真实支付网关。
同时，管理员判定也已经从这轮开始统一收口： 不再使用 user_id == 1 这类在多租户场景下容易误伤普通用户的条件， 而是只认显式 admin 用户名或超管标记。
System Map
系统组成
统一后端能力中心
统一后端能力中心，承接认证、租户、能力目录、执行资产、日志、模板等核心服务。
治理控制台
负责平台级配置、模板、日志和运营治理，不与普通业务入口混合。
正式客户前端
面向正式客户环境，承接实际业务访问与脚本执行入口。
多租户交付站点
用于承接不同客户或不同环境的交付前端。当前已经分出单租户前端和共享 SaaS 租户前端两条现实路径，不再默认每来一个客户就复制一套前端工程。
个人体验入口
面向个人用户与早期探索者，承接体验、增长和免费线索入口。
联调与集成层
用于多入口协同、联调与统一验证，不直接作为客户正式使用入口。
CLI / Local Bridge
本地接入与 Agent 骨架入口，把平台控制面和本地环境连接起来。
docs
公开说明文档、版本路线和入口页，方便自己和客户都能快速对齐。
Governance Domain
public 负责什么
- 平台超管
- 客户台账
- 租户管理
- 订单中心与租户生命周期治理
- 平台审计
- HTTP 资源接入、凭据治理与写边界控制
- 模板分发治理
Tenant Domain
tenant schema 负责什么
- 用户、角色、菜单、参数、公告
- 能力接入、Skill 绑定与租户授权
- 已授权 HTTP 资源的只读摘要查看
- 执行记录与调度日志
- 业务扩展表
- 各租户自己的访问边界与数据边界
Concept 01
Skill 是能力单元
Skill 面向用户和 AI，负责描述能力名称、输入输出、可见范围、风险等级、审批要求和审计边界。
Concept 02
执行资产是具体接入物
执行资产描述能力到底连到什么对象。当前最成熟的是 Python 脚本，平台也已经开始用 HTTP 资源样板验证 API 类型资产怎么进入统一治理链路。
Concept 03
执行器负责运行时适配
执行器决定不同资产类型怎么被调用、怎么校验输入输出、怎么把结果统一回到平台审计链路里。当前运行时已经不再只写死脚本判断。
Runtime Boundary
运行时边界怎么成立
一个客户一个网址
标准交付内容里，每个客户会拿到独立访问地址、独立租户空间和一组客户专属能力。
Host 绑定租户
当前运行时会按访问 Host 绑定租户并切换 schema，所以“一个客户一个网址”不是营销说法，而是运行时边界的一部分。
public 不等于普通租户
public 负责平台治理与共享底座，客户不会直接把它当成自己的业务租户来用。
Shared Tenant Front
共享 SaaS 租户前端
- 从
tenant_1003+开始，标准 SaaS 客户会优先进入共享租户前端骨架 - 共享的是前端工程和发版节奏，不共享租户数据、菜单权限和执行结果
- 运行时仍按访问 Host 切到对应 schema
- 这条路径适合标准能力和较轻团队协作场景
Shell Role
exec-gov-shell 的真实定位
- 它主要用于多入口聚合、联调和最终同步
- 它不是客户长期正式运行入口
- 客户正式使用时，仍以正式单项目或共享租户前端为准
- 这能减少“壳层成真相、正式工程反而漂移”的问题
Delivery Package
标准交付通常包含什么
- 一个独立租户
- 一个独立访问网址
- 一组客户专属能力，当前通常以脚本型能力为主
- 平台账号与基础权限
- 客户使用说明和客户脚本热更新说明
Acceptance Check
客户验收时最该确认什么
- 是否能登录自己的网址
- 是否只能看到自己的能力
- 是否能执行自己的能力并查看结果
- 是否能按流程继续提交脚本更新，而不重部署整个平台
Architecture To Delivery
架构落地重点资料
Architecture Rules
实施与隔离原则
Rule 01租户隔离优先
不同客户的数据、能力和权限边界需要先清晰，再谈统一运营与扩展。
Rule 02治理与业务入口分层统一治理能力与客户业务入口需要职责分明，避免权限和表达混乱。
Rule 03变更可验证后再推广能力、流程和前端改动都应先验证稳定，再逐步扩展到更大范围。
Rule 04交付与平台边界清晰既要支持客户交付，也要保留统一治理与运营能力，两者不能互相挤占。
Rule 05execgov-cli 负责连接本地环境与平台控制面本地脚本接入、后续其他执行资产接入和 manifest 生成，当前都沿这条桥接链继续往前做；Agent 常驻执行仍属于后续增强。
Rule 06文件链路要纳入正式架构，不应作为临时上传功能理解只要项目真实依赖输入文件和结果文件，上传、批次和结果入口就属于正式交付架构的一部分。
Why This Works
为什么这套结构适合当前阶段
能直接接企业客户项目
租户边界和平台治理边界都先成立，交付结构完整，不依赖临时拼接。
能同时保留平台治理能力
public 侧客户台账、租户状态、模板分发、日志审计不需要另起炉灶。
能承接个人免费版增长入口
免费版不是旁支，而是正式入口之一，可以持续沉淀线索和使用样本。
能继续扩展到 API、模板、Agent 与更多能力形态
控制面、执行端和能力单元已形成基础边界，未来扩到更多能力资产的成本更低。
Next Read
理解架构后，建议继续看交付落地
真正能把架构说明转成项目推进材料的，通常不是重复解释概念，而是把文件链路、交付物和接入准备一起说明清楚。