docs: 移除开发过程文档，开源版文档统一见文档站

- docs/角色权限任务切换.md（管理后端与 Worker 的角色权限任务切换上线顺序、回滚与验收）
- SIM_STATUS_RUN_ACCOUNTING.md（卡状态同步 Run 计数收尾语义与上线步骤）

文档站：https://git.5iot.com/iotlcm-public/iotlcm-docs

SIM_STATUS_RUN_ACCOUNTING.md

@@ -1,34 +0,0 @@
-# 卡状态同步 Run 计数与收尾
-
-状态同步此前创建了 Run 元数据，但使用渠道级 `EnqueueBatch/Enqueue` 和 `AckBatch`，这些操作不会维护 Run 计数，也不会调用 Run 完成判定。任务实际处理结束后，元数据因此可能长期停在 `running`，成功、失败计数均为零。
-
-## 新任务行为
-
-全量和单卡状态同步均改用 Run 队列。`RunQueueEnabled` 控制 Run 消费，`RoundRetryEnabled` 独立控制多轮重试；状态同步固定单轮，流量同步继续保留原来的多轮策略。
-
-- 入队按稳定 Task ID 去重；`activeCount` 包含排队及租约中的任务，背压不能再次加上 `inflightCount`。
-- 成功结果先写 MySQL，再凭租约令牌原子确认、累加成功数。永久业务失败记入失败数及失败记录；数据库失败和可恢复网络失败保留任务，等待租约恢复。
-- 电信渠道受限时，先确认同批已落库的成功结果，再凭触发任务的有效租约封禁该 Run 的渠道。其余已入队任务记为 `channel_blocked` 终态失败，保留逐卡记录；尚未入队而被拒绝的任务不计入已处理数量。此计数规则仅用于状态同步。
-- 只有 `producerDone=1`，且 `activeCount/inflightCount/nextRoundCount` 均为零，才写入 `completedAt`。无失败为 `completed`，存在失败为 `completed_with_failures`。周期性检查覆盖空 Run 和消费先结束的情形。
-- 元数据、任务状态和失败记录在收尾后保留 30 天。`sim_status_queue_round_batch` 是批次尝试日志，不能直接按其 `failed` 汇总终态失败；最终 Run 计数以元数据及 `sim_status_queue_run` 事件为准。
-
-## 配置和后续上线步骤
-
-使用 `simStatusQueueSync.redisKeyPrefix`，默认 `sim-status:`。生产者和消费者锁仍使用原键。
-
-本次代码交付不部署、不修改旧 Run。后续上线应遵循以下顺序：
-
-1. 暂停状态同步的新触发入口（定时、手动及单卡），让旧 Worker 完成现有工作。核对两个状态 MQ 队列的 ready/unacked 为零、无在途 producer，以及旧命名空间所有渠道 ZSet 与租约为零。历史 `status=running` 本身不能作为仍有业务任务的判据。
-2. 使用新代码和 `redisKeyPrefix: "sim-status:"` 启动，保持锁键配置不变；恢复触发入口。
-3. 先运行小规模/单卡同步，再核验一次全量同步：MySQL 状态及同步时间符合成功结果，Run 计数持续变化，最终唯一入队数量（任务状态 Hash 的 HLEN）等于成功数加失败数，活动计数归零、终态与完成时间正确。查询 `sim-status:{<runId>}:meta`。
-4. 如需回滚，先暂停新触发并等待 v2 队列处理结束，再停新 Worker、恢复旧版本和旧配置；有未完成 v2 任务时应保留可消费 v2 的版本继续处理，不直接切回旧版遗留任务。
-
-## 自动验证
-
-```text
-go test ./...
-```
-
-Redis 集成测试要求 PATH 存在 `redis-server`，或设置 `REDIS_SERVER_BINARY` 为可执行文件路径。每个测试启动独立的回环地址 Redis，使用临时目录且关闭持久化，退出后清理进程；不会读取应用 Redis 配置。缺少二进制时会明确 skip，验收时应确认这些测试实际执行。
-
-覆盖成功/失败混合、空 Run、生产消费交错、重复入队/确认、租约失效及恢复、数据库和网络失败、渠道封禁及逐卡失败记录、多 Run 并行、单卡入口和背压；另回归流量五轮重试与原渠道封禁语义。

docs/角色权限任务切换.md

@@ -1,24 +0,0 @@
-# 角色权限任务切换
-
-管理后端仅保存角色并事务记录 sys_role_sync_task，Worker 接管执行。任务数据格式和迁移脚本与管理后端一致。
-
-## 启用顺序
-
-1. 备份并执行 resource/migrations/20261014_role_sync_outbox.sql；已执行时无需重复迁移。
-2. 停止全部旧管理后端执行实例，更新后端。不要与旧消费者混跑。
-3. 核对 Worker 和管理后端使用同环境数据库、RabbitMQ vhost；数据库账号须有角色、菜单、机构、任务及权限版本表的相应读写权限。
-4. 配置 roleSync.enabled: true，更新 Worker；确认 role sync Worker started 日志及 iotlcm-worker-agent-role-sync 消费者。
-5. 核对旧主队列、retry、dlq 积压。完整来源的旧消息转为确定性 ID 的数据库任务；不完整消息拒绝处理，不能盲目清空队列。
-6. 保存成功仅表示来源权限和任务已提交；通过管理后端任务查询与重试接口观察结果。
-
-## 验收
-
-使用隔离环境验证正常同步、断开 RabbitMQ、消费者断线重连、Worker 重启、重复消息、部分失败、模板切换、多实例撤权和租约丢失。监控 pending/retry 积压、最老任务时间和终态失败。SQLite 测试不能代替 MySQL 行锁及真实消息队列验收。
-
-## 回滚
-
-关闭 Worker 的 roleSync.enabled 前先记录未完成任务；恢复旧后端消费者与停止新消费者要协调，禁止长期双执行。保留任务表和权限版本表，不删除真实角色绑定。未启用执行器期间任务保留 pending，恢复后处理。
-
-## 检查补充
-
-无效 JSON 和缺少来源信息的旧消息先确认发布到 iotlcm.agent.role.sync.dlq，再确认原消息；隔离发布失败时原消息重新入队。消息引用不存在的任务只记警告，不无限重投；有效任务载荷必须与任务表的租户及来源字段一致。缺失默认角色直接失败，不自动生成孤立角色，修复绑定须业务确认。权限相关数据库查询使用主库，避免从库延迟将旧权限缓存到新版本。