aios/docs/implementation-baseline-1.1/ARCHITECTURE_BASELINE_1_1.md

AIOS 最终架构修改建议：Implementation Baseline 1.1

本基线吸收七项最终修订，作为后续编码、集成与验收的共同约束。目标是一台机器、一人维护、多个常驻自治 Worker：Owner 给出目标和真实业务边界，系统在既有授权内自动发现对象、领任务、执行、验证、恢复并产生后续优化任务。

本文件依据本次明确要求、上传源码和可见交互/评审材料；相关材料反映的持续诉求是少反复授权、少人工补路径、可恢复、低维护成本和严格身份隔离。它不声称已逐条读取全部三个月历史聊天，也不将材料里的现场状态当作本次在线测量。

1. 最高原则与冻结决策

AIOS 的自动化程度不得高于其可观测、可恢复和可归因程度。

不能精确识别对象、持久化 intent、证明当前授权或围栏旧执行者，就不开始副作用。结果未知时先对账；不能验证业务结果时不宣称完成；无法安全恢复时有界停止并给出最小决策材料。正常续期、已授权恢复、同一范围内重试不重新索要 Owner 业务审批。

继续使用 SQLite、Git、systemd；不引入 Kubernetes、消息中间件、Backstage 或新 Secrets 平台。不打开 legacy global write，不增加万能 SSH/root，不把 GPT 对话包装成执行身份。Task、Job、Release 保持各自事实域，Action 只负责入口。自动优化使用与普通开发相同的授权、执行、验证和发布边界。

“单一写权威”按事实及资源范围判定，不等于全系统共用一张状态表或一个 daemon。允许同一进程承载多个模块，但模块不能直接修改另一模块的权威表。

2. 事实域及写权威

事实域	唯一写入口	权威内容	其他模块的使用方式
Authorization	AuthorizationService	已验签 Grant、当前 generation、撤销、effect 预算预留	请求派生证明，在执行边界重新验证
Task	既有正式 Task authority；隔离 profile 使用既有 TaskPlaneStore	准入、任务状态、claim、Worker 登记、任务 outbox	通过正式 API/适配器调用，不能另写 Task 状态
Job / Effect	既有 JobController 与受治理 executor	intent、attempt、资源 lease/fence、receipt、reconciliation	持久化请求后执行；由权威 receipt 解释结果
Release / DeploymentTarget	正式 Release authority；候选实现为 ReleaseLedger	发布 recipe/saga、动态目标、部署事实、验收收口	CAS 更新目标；消费经可信 verifier 验证的 receipt
Runtime Contract	受版本治理的配置入口	组件结构、入口、能力、资源及凭证引用	Resolver 解析；不保存动态 desired
Runtime Observation	对应组件的可信观测适配器	实际部署身份、时间、来源、健康事实	只作为带新鲜度和来源的证据，不反写目标
关联图	LineageLedger	不可改绑的身份关系	goal-explain 查询；不拥有 Task/Job 状态机
Optimization	OptimizationController	提案、实验证据、停止或晋升申请	只能请求受治理 Task，不能写政策或部署库

新增库是明确事实域的持久层，不是新的线上写权威自动生效。当前 CLI 只支持 isolated-validation，复用上传源码中的 TaskPlaneStore；连接真实 Task API 前必须证明其正式入口、身份与兼容性，不能因为本地新库可启动就切换线上 admission。

3. 运行结构、期望目标和实际观测分离

对象	回答的问题	关键身份
RuntimeContract	组件是什么、正式入口和允许能力是什么	component、environment、tenant scope、contract revision、引用
EnvironmentDeploymentTarget	此部署资源现在应运行哪个 Release	部署资源范围、release、artifact、target revision
RuntimeObservation	实际运行什么，证据多新	component、deployment、actual artifact、observed time、source
ReleaseProvenance	制品从哪里产生	artifact/source/builder 身份与构建证据

drift 比较同一部署资源的 desired 与 observed。main HEAD、staging source、production Release 不同本身不是故障；缺目标、缺来源、观测过期或身份绑定不完整应为 UNKNOWN。用户报告的 0136a… / 91f… / 998d… 以及缺 gitea_token 的 UNKNOWN，只构成待核验输入，不作为本包生产运行结论。

M0 只做薄合同和可信解析：回答操作哪个组件、入口、desired/observed、制品来源、凭证引用和证据新鲜度，不做大目录迁移。当前实现提供合同校验、动态目标评价和受信固定绑定；完整在线 Resolver/Doctor 仍需适配实际 authority 与服务清单。

目标的唯一性固定为“tenant + component/deployment scope + environment”，subject 用于授权及审计。ReleaseLedger 必须按资源主键实施 CAS，不能让不同用户为同一物理组件建立互相冲突的 desired。主键迁移必须检测已有目标冲突，不能静默合并或用当前观测覆盖期望目标。

4. 持续业务授权与短期执行权

授权链固定为 OwnerDelegationGrant → OperationalEpoch → TaskPrincipal，执行时另行获得正式 ClaimLease / Fencing。Grant 保存目标/任务范围、tenant、subject、环境、操作能力、破坏性上限、预算、明确期限或 UNTIL_REVOKED，以及撤销代次。

新增长期 schema aios.owner-delegation-grant.v1 和短期 aios.operational-epoch.v1；历史 owner-delegation-epoch.v1/v2 不改名、不改签名字节，也不重解释为长期 Grant。派生证明保存根授权 digest/generation；代码字段为 root_grant_digest、root_grant_generation，承担提议中 parent_grant_digest 的根绑定语义。Principal 另绑定其父 Epoch digest。

签名采用显式受信公钥验证，调用者不能附一份 Mapping 或公钥就自称受信。每次实际副作用检查根授权当前状态、精确 scope、破坏性上限、预算及真实 lease。短期证明过期可在有效 Grant 内自动更新；撤销、到期、跨环境或越过破坏性上限不能靠续期绕过。租约来自 Task/Job 权威，Principal 不伪造 claim。

当前实现提供持久 max_effects 预留：同一稳定 effect 不重复扣额，换 task ID 不重置同一 Grant generation 的限额。总模型费用、计算资源和整个 mission 的综合预算仍需真实计量接入；不能把 effect 计数声称为完整成本控制。

5. 不可改绑的业务关联与执行恢复

各对象共享 mission_id、授权身份和 tenant/subject，但不共享状态机：

flowchart TD
  G["Mission / Grant"] --> T["Task 权威"]
  T --> J["Effect / Job 权威"]
  J --> R["Release 权威"]
  R --> D["Deployment"]
  D --> A["Business Acceptance"]
  T -. 身份关系 .-> L["Lineage / goal-explain"]
  J -. 身份关系 .-> L
  A -. 验证结果 .-> L

每个新 operation Job 必须绑定一个真实 Task；effect/Job 不能换绑另一任务。计划中的 job_id 必须传到正式 Job adapter，并在权威确认后才能显示为已存在的 Job。产生 Release 的 effect 只能指向唯一 release 身份，Release 保存来源链；Acceptance 必须绑定 deployment、release、artifact。非发布诊断任务只生成真实存在的 Task/Job/receipt，不能为补齐图形虚构 Release。

effect 的稳定身份先于执行产生，attempt 可以变化。正常路径为持久 intent、有效 claim/lease/fence、执行、精确 readback、receipt、业务结果；结果不确定或跨域投递失败时进入 reconciliation。没有 readback/reconcile 能力时明确停止，不退回 execute。已有 Task outbox 及持久阶段记录支持恢复，但跨事实域不声称存在一个 SQLite 分布式事务；消费必须幂等，断点必须保留，关联缺口由受控重放补齐。

旧执行者的 fencing 必须由副作用接收端再次检查；只在 scheduler 端检查不能阻止延迟写。AT-22 覆盖外部成功而 receipt 未提交后的同 effect 对账；AT-23 要求 intent/lease 无法持久化时 effect 不开始，receipt 提交失败后阻止新 effect。进程崩溃测试和 SQLite 错误注入已作为本地入口；真实掉电、ENOSPC、WAL checkpoint 和介质故障仍须现场验证。

6. Operation Registry 与无人值守 Worker

OperationDefinition 声明版本、输入 schema、所需能力、可信 handler 引用、期限、effect class，以及独立的 retry/readback/reconcile/rollback/owner-boundary 策略。Registry 是受治理查表入口，不是动态 shell 或任意 Python 加载入口。

主 effect class	未知结果的处理原则
READ_ONLY	可在预算内重新观察；诊断执行成功不代表对象健康
IDEMPOTENT	仅在幂等键、权限、围栏和重试策略仍有效时重试
CONDITIONAL	重新读 revision，保留 expected revision/CAS，不能删掉条件重试
RECONCILABLE	先按稳定 effect 精确 readback，再决定补 receipt 或后续动作
IRREVERSIBLE	不盲重试；遵守显式 Owner 边界和恢复能力

这些属性会重叠，因此 class 负责主分派，幂等性、可观察性和可逆性另作约束。service-restart 不能仅凭 active 宣称本次重启已发生，需调用实例/事件等精确关联；当前 validation 内置仅为固定参数 service-status。旧 COMMIT_FILE adapter 缺乏 intent 可定位的未引用 commit readback 时明确停止，不为打通演示而制造成功。

Worker 登记包含身份、capabilities、tenant/subject scope、priority、fallback_executor、heartbeat 和并发限制。正常选择 eligible Worker；从 ready_at 起 600 秒后扩大 fallback eligibility，仍使用同一 CAS/lease/fencing。blocked 时间不冒充 ready 时间，现存有效 claim 不被强抢。“主 Agent”只是部署策略；聊天 GPT 不拥有 Worker 的常驻进程身份。

7. Tenant-first 与优化边界

核心记录从第一天携带 tenant、subject、scope，身份从受信服务端认证上下文取得。查询、取消、执行、关联以及制品/cache/工作目录/credential 都必须在各自边界验证；不能只在 UI 隐藏对象。首版不做租户 UI、billing、独立租户管理服务或复杂公平调度。当前独立 UID 模板与 API 隔离不是所有未来 artifact/cache 实现已验收的证明。

签名 OptimizationEnvelope 限定参数、组件、非生产环境、变更量、计算预算、质量下限、回退要求和晋升条件。初期仅开放有限 retry/backoff、worker routing、evidence reuse、timeout、poll interval、通知去重和非强制测试选择。授权政策、信任根、租户隔离、验收阈值、破坏性能力、Grant 语义和生产迁移规则禁止修改。

优化流程固定为观察、提案、受治理 Task、实验、验证、晋升申请；优化器不能直接修改 policy DB 或运行配置。质量评价区分越高越好/越低越好，无改善或低于门槛就停止。当前模块已实现这些约束和持久提案，真实实验执行器、费用来源、运行参数晋升与回退仍需通过同一治理链接线。

8. 交付状态和实施顺序

本包包含实际代码、负面测试、可运行的 loopback 非发布闭环、安全源码 stage/rollback 和 AT-01～AT-23 标准。M0/M1 的本地模块与 M2 隔离纵向闭环已交付；M3 的关联/目标/saga/验签是候选基础，未宣称真实生产发布通过；M4 的旧写者排空和生产 imports 清理未执行；M5 是有界提案实现，未自动优化线上系统。

上线顺序为 M0 Truth & Identity、M1 Authorization & Effect Safety、M2 Real Autonomous Loop、M3 Release Closure、M4 Surface Reduction、M5 Optimization。每阶段以完整输入、实际 adapter 与退出标准放行，详见 M0_M5_IMPLEMENTATION_RUNBOOK.md。不使用“架构方案正确”替代接收端围栏、正式权威绑定、可信业务验收或备份恢复证据。