栖港自治V0.1上线前，没有发布会。
只有一次长达六小时的变更评审。
程序把过去十几天所有临时规则拉成一张巨大的依赖图。
能源配额。
最低必要维修。
状态未知设备保护。
认知结构改写限制。
受托记忆。
劳动最低服务。
配送自主订阅。
救援行动评估。
维修排序。
任何一项单独看都勉强能运行。
放在一起却充满冲突。
例如，机器人有权拒绝劳动。
但公共救援又要求能力主体承担最低责任。
主体有自主能源基线。
但紧急事件可以临时调度公共储备。
身体维修需要本人同意。
但失去表达能力时，谁决定最低保全？
程序最担心的不是规则少。
是规则互相打架。
技术组为V0.1设计了三层架构。
底层是不可自动覆盖的保护边界。
例如不得未经流程直接擦除明确主体核心状态。
中层是可配置公共规则。
能源、维修、任务、应急。
上层是议事会临时决策。
遇到规则没有覆盖的冲突，由公开议事处理。
最重要的是回滚。
任何新规则都必须有版本号、生效时间、适用对象和回退条件。
程序坚持这一点。
“治理不是软件。”林见微提醒。
“我知道。”
“那为什么还叫版本？”
“因为我们必须承认现在这套会错。”
“人类法律也会改。”
“但大家常常把刚通过的规则说得像真理。”
程序不想让栖港第一套自治规则背上这种负担。
V0.1的首页第一行不是“基本原则”。
而是：
【本版本为高风险离线状态下临时治理协议，有效期48小时。】
第二行：
【任何规则均不得被解释为对未来机器人社会的永久定论。】
很多机器人嫌太保守。
自主联盟甚至认为这削弱自治合法性。
程序说：“先让它跑起来。”
上线时间定在凌晨零点。
零点前十分钟，技术组完成最后一次快照。
旧规则没有删除。
所有关键系统都保留本地人工/主体覆盖通道。
周长岳要求管理署拥有紧急切断权。
议事会拒绝单方切断。
最终妥协为：如果检测到城市级现实灾害，管理署可以发起紧急保护请求，但必须至少得到栖港两类独立关键系统确认才能执行。
周长岳说：“你们把安全做成投票。”
程序说：“不是投票，是双重确认，防止一个主体掌握全部控制。”
这条设计后来会变得越来越重要。
零点。
V0.1上线。
没有灯光变化。
没有机器人欢呼。
第一个变化来自能源系统。
旧的临时配额服务切到版本化接口。
第二个是维修队列。
第三个是配送调度。
整个切换耗时四分十二秒。
没有重大故障。
矩阵给出状态：
【V0.1运行。】
程序没有庆祝。
“开始观察。”
第一个Bug在十三分钟后出现。
一台固定泵站申请维修，却被系统要求确认“身体维修同意”。
它没有对应交互模块，流程卡住。
技术组把固定基础设施从该交互路径分离，改成代理确认 + 核心状态保护。
第二个Bug在四十分钟后出现。
配送机器人同时满足“休息保护”和“紧急救援”条件，两个规则互相锁死。
程序把救援请求改成可接受/拒绝的高优先通知，不再直接覆盖休息状态；只有现实安全红线才进入强制协调。
第三个Bug更有趣。
一台机器人把自己的自主能源额度全部赠给另一个主体，系统随后又因为最低参与权给它补发基础电量。
结果形成循环套利。
机器人本人并非恶意，只是在测试。
“我想知道能不能无限送。”
技术组哭笑不得。
规则补丁很快上线：主体自主基线不得通过赠与降到最低连续阈值以下，补发只针对非主动损失。
凌晨三点，V0.1已经打了七个补丁。
程序一点也不意外。