specs(BIZ-158): SOP-017 v1.1 草案 — 知识缺口上报通道改用 Multica（Gitea Issue 退位）

- 第 5 节上报流程重写为 Multica 主通道：记录 → 通知 COO → multica issue create 并回写 issue id → 审核 → 补全卡 → 补全 → 闭环
- 明确「Multica 优先、Gitea 退位」定位；Gitea 仅作代码/文档版本控制
- 补标准上报格式（与 BIZ-84 口径一致）与「什么不算知识缺口」判据
- 量化口径改为「含 Multica issue id 回写的上报记录数」直接计数
- v1.0 本体零改写（交付即冻结）

Co-authored-by: multica-agent <github@multica.ai>

specs/BIZ-127_auth-schema.sql

@@ -0,0 +1,170 @@
+-- ============================================================
+-- BIZ-127 方案 C 完整用户系统 —— 数据模型 SQL DDL
+-- ============================================================
+-- 设计人：梁思筑（architect）| 2026-09-04
+-- 适用版本：lottoData v2.0（Flask + SQLite）
+-- 数据库：SQLite 3.x（与现有 lottery.db 同库同文件，复用 DB 连接）
+-- 兼容性：当前 SQLite 文件存储（.generation_records.json）将迁移至本 schema
+-- 字符集：UTF-8
+-- 加密策略：bcrypt(cost=12) 密码哈希、session 哈希、不存任何明文凭证
+-- ============================================================
+
+-- ------------------------------------------------------------
+-- 1. users —— 用户表
+-- ------------------------------------------------------------
+CREATE TABLE IF NOT EXISTS users (
+    id              INTEGER PRIMARY KEY AUTOINCREMENT,
+    username        TEXT    NOT NULL UNIQUE,
+    password_hash   TEXT    NOT NULL,                       -- bcrypt cost=12 哈希
+    email           TEXT,                                    -- 可选，找回密码用
+    role            TEXT    NOT NULL DEFAULT 'user'          -- 预留：admin / user
+                       CHECK (role IN ('user', 'admin')),
+    status          TEXT    NOT NULL DEFAULT 'active'        -- active / locked / disabled
+                       CHECK (status IN ('active', 'locked', 'disabled')),
+    tenant_id       INTEGER NOT NULL DEFAULT 1,              -- 多租户预留，单租户默认 1
+    failed_attempts INTEGER NOT NULL DEFAULT 0,              -- 登录失败计数（达到 5 锁定）
+    locked_until    INTEGER,                                 -- Unix 时间戳，NULL=未锁
+    password_changed_at INTEGER NOT NULL,                    -- 用于旧 session 失效判断
+    last_login_at   INTEGER,                                 -- 最近登录时间
+    created_at      INTEGER NOT NULL,
+    updated_at      INTEGER NOT NULL,
+    -- 多用户扩展索引
+    CONSTRAINT idx_users_username UNIQUE (username),
+    CONSTRAINT idx_users_tenant   UNIQUE (username, tenant_id)
+);
+
+CREATE INDEX IF NOT EXISTS idx_users_role_status ON users(role, status);
+CREATE INDEX IF NOT EXISTS idx_users_tenant      ON users(tenant_id);
+
+-- ------------------------------------------------------------
+-- 2. sessions —— 会话表（服务端 session，cookie 仅存 session_id）
+-- ------------------------------------------------------------
+-- 决策：DB 存 session（不用 JWT），理由：
+--   - 可控失效（改密码立即清空）
+--   - 可主动踢人
+--   - 内网系统不需分布式无状态
+CREATE TABLE IF NOT EXISTS sessions (
+    id              TEXT    PRIMARY KEY,                     -- 32 字节 URL-safe base64
+    user_id         INTEGER NOT NULL,
+    session_hash    TEXT    NOT NULL,                        -- sha256(session_id + server_secret)
+    user_agent      TEXT,                                    -- 浏览器/客户端 UA
+    ip_address      TEXT,                                    -- 登录 IP（内网）
+    password_epoch  INTEGER NOT NULL,                        -- 登录时 users.password_changed_at 快照
+    expires_at      INTEGER NOT NULL,                        -- Unix 时间戳（30 天）
+    created_at      INTEGER NOT NULL,
+    last_seen_at    INTEGER NOT NULL,                        -- 用于过期清理
+    revoked_at      INTEGER,                                 -- NULL=有效，非 NULL=已撤销
+    FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE
+);
+
+CREATE INDEX IF NOT EXISTS idx_sessions_user      ON sessions(user_id);
+CREATE INDEX IF NOT EXISTS idx_sessions_expires   ON sessions(expires_at);
+CREATE INDEX IF NOT EXISTS idx_sessions_active    ON sessions(user_id, revoked_at, expires_at);
+
+-- ------------------------------------------------------------
+-- 3. password_reset_tokens —— 密码重置 token 表
+-- ------------------------------------------------------------
+-- 决策：DB 存一次性 token（不用 JWT 自包含），理由：
+--   - 一次性、可控、可撤销
+--   - 速率限制基于 DB 计数
+CREATE TABLE IF NOT EXISTS password_reset_tokens (
+    token_hash      TEXT    PRIMARY KEY,                     -- sha256(明文 token)
+    user_id         INTEGER NOT NULL,
+    expires_at      INTEGER NOT NULL,                        -- 1 小时过期
+    used_at         INTEGER,                                 -- NULL=未用
+    ip_address      TEXT,                                    -- 请求来源 IP
+    created_at      INTEGER NOT NULL,
+    FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE
+);
+
+CREATE INDEX IF NOT EXISTS idx_pwd_reset_user    ON password_reset_tokens(user_id);
+CREATE INDEX IF NOT EXISTS idx_pwd_reset_expires ON password_reset_tokens(expires_at);
+
+-- ------------------------------------------------------------
+-- 4. operation_logs —— 操作日志表
+-- ------------------------------------------------------------
+-- 用途：审计、追踪、异常告警
+-- 保留周期：90 天（按月度手动归档）
+-- 未来扩展：按 tenant_id 分区（本次单租户，分区预留）
+CREATE TABLE IF NOT EXISTS operation_logs (
+    id              INTEGER PRIMARY KEY AUTOINCREMENT,
+    user_id         INTEGER,                                 -- 公开操作可 NULL
+    tenant_id       INTEGER NOT NULL DEFAULT 1,              -- 多租户预留
+    username        TEXT,                                    -- 冗余存储，避免 JOIN
+    action          TEXT    NOT NULL,                        -- login / logout / generate / delete / reset_request ...
+    resource_type   TEXT,                                    -- record / config / user ...
+    resource_id     TEXT,                                    -- 关联 ID
+    ip_address      TEXT,
+    user_agent      TEXT,
+    status          TEXT    NOT NULL DEFAULT 'success'       -- success / failure
+                       CHECK (status IN ('success', 'failure')),
+    detail          TEXT,                                    -- JSON 字符串，存额外上下文
+    created_at      INTEGER NOT NULL
+);
+
+CREATE INDEX IF NOT EXISTS idx_oplog_user_time   ON operation_logs(user_id, created_at);
+CREATE INDEX IF NOT EXISTS idx_oplog_tenant_time ON operation_logs(tenant_id, created_at);
+CREATE INDEX IF NOT EXISTS idx_oplog_action      ON operation_logs(action, created_at);
+
+-- ------------------------------------------------------------
+-- 5. auth_settings —— 全局鉴权配置（单行配置表）
+-- ------------------------------------------------------------
+-- 用途：运行时调整鉴权策略，不重启服务
+CREATE TABLE IF NOT EXISTS auth_settings (
+    id                  INTEGER PRIMARY KEY CHECK (id = 1),  -- 仅允许 id=1
+    bcrypt_cost         INTEGER NOT NULL DEFAULT 12,         -- 12-14
+    session_max_age_sec INTEGER NOT NULL DEFAULT 2592000,    -- 30 天
+    session_renew_sec   INTEGER NOT NULL DEFAULT 86400,      -- 24h 内活跃则续期
+    max_failed_attempts INTEGER NOT NULL DEFAULT 5,
+    lock_duration_sec   INTEGER NOT NULL DEFAULT 900,         -- 15 分钟
+    pwd_reset_ttl_sec   INTEGER NOT NULL DEFAULT 3600,        -- 1 小时
+    pwd_reset_rate_limit INTEGER NOT NULL DEFAULT 3,          -- 每用户每小时最多 3 次
+    log_retention_days  INTEGER NOT NULL DEFAULT 90,
+    maintenance_mode    INTEGER NOT NULL DEFAULT 0,           -- 0=正常 1=维护
+    updated_at          INTEGER NOT NULL
+);
+
+-- 初始化默认配置（仅在表为空时插入）
+INSERT OR IGNORE INTO auth_settings (id, updated_at)
+VALUES (1, strftime('%s', 'now'));
+
+-- ============================================================
+-- 二、迁移脚本（从当前 JSON 文件存储 + Bearer-only 模式）
+-- ============================================================
+-- 迁移目标：
+--   1. 初始化 users 表，创建默认管理员账号
+--   2. 现有 .generation_records.json 数据保留，不迁移（无 user_id 字段）
+--   3. operation_logs 表从空开始
+-- ============================================================
+
+-- 迁移步骤 1：创建默认管理员账号
+-- 默认用户名：lotto_admin
+-- 默认密码：BIZ-127-Lottery-2026（首次登录后强制修改）
+-- 警告：此密码必须在首次登录后立即修改（通过 BIZ-129 强制流程）
+INSERT OR IGNORE INTO users (
+    username, password_hash, email, role, status,
+    tenant_id, failed_attempts, password_changed_at,
+    created_at, updated_at
+) VALUES (
+    'lotto_admin',
+    -- bcrypt('BIZ-127-Lottery-2026', cost=12)
+    -- 由 BIZ-129 实施时用 Python bcrypt 生成，SQL 仅作占位
+    '__BCRYPT_PLACEHOLDER__',
+    NULL, 'admin', 'active', 1, 0,
+    strftime('%s', 'now'), strftime('%s', 'now'), strftime('%s', 'now')
+);
+
+-- 迁移步骤 2：保留 .generation_records.json 数据
+-- 策略：不迁移到 operation_logs（records 是业务数据，不是审计日志）
+-- 备注：BIZ-129 需在 add_record() 中写入 operation_logs(action='generate')
+
+-- 迁移步骤 3：环境变量兼容
+-- 保留 LOTTO_API_TOKEN（Bearer 备用通道，仅供内部服务调用）
+-- 用户系统上线后，外部前端用 cookie，内部脚本用 Bearer
+
+-- ============================================================
+-- 三、清理脚本（可选，生产环境 90 天后执行）
+-- ============================================================
+-- DELETE FROM sessions WHERE expires_at < strftime('%s', 'now');
+-- DELETE FROM password_reset_tokens WHERE expires_at < strftime('%s', 'now');
+-- DELETE FROM operation_logs WHERE created_at < strftime('%s', 'now', '-90 days');

specs/BIZ-127_完整用户系统架构_v1.0.md

@@ -0,0 +1,240 @@
+# BIZ-127 完整用户系统架构设计 v1.0
+
+| 项 | 内容 |
+|---|---|
+| **版本** | v1.0 |
+| **作者** | 梁思筑（architect） |
+| **日期** | 2026-09-04 |
+| **关联卡片** | BIZ-127（架构）→ BIZ-129（实施） |
+| **父卡片** | BIZ-109（P0 修复闭环） |
+| **关联 PRD** | BIZ-111（产品 PRD） |
+| **存储位置** | docs/BIZ-127_完整用户系统架构_v1.0.md |
+| **同步位置** | 思源知识库 `/standards/完整用户系统架构 v1.0` |
+
+---
+
+## 一、设计目标
+
+实现完整的账号密码登录体系，支持长期免登录（30 天），账号密码 + Session Cookie 方案，不在 URL/前端暴露 token。
+
+---
+
+## 二、数据模型
+
+**完整 SQL DDL** 见 `docs/auth-schema.sql`（9.7KB）。
+
+包含 5 张表：
+1. **users** —— 用户表（bcrypt 密码哈希、登录失败计数、锁定时间戳、多租户/角色预留）
+2. **sessions** —— 服务端会话（DB 存，非 JWT；存 session_hash、password_epoch 用于改密失效）
+3. **password_reset_tokens** —— 密码重置 token（一次性、1 小时过期、限速 3 次/小时）
+4. **operation_logs** —— 操作日志（90 天保留、多租户索引预留）
+5. **auth_settings** —— 全局鉴权配置（bcrypt cost、session 寿命、锁定参数）
+
+### 关键决策
+
+| 决策点 | 选择 | 理由 |
+|--------|------|------|
+| Session 存储 | **DB 存** | 可控失效、改密立即踢人；JWT 不适合内网场景 |
+| 重置 token 存储 | **DB 存** | 一次性、可控、可限速；JWT 自包含不可撤销 |
+| 密码哈希 | **bcrypt cost=12** | 行业标准，登录耗时 ~250ms，安全/性能平衡 |
+| 多用户扩展 | **数据层预留 + UI 不暴露** | 见下文"多用户扩展决策" |
+
+---
+
+## 三、鉴权中间件流程图
+
+```
+请求进入
+   │
+   ▼
+┌──────────────────────┐
+│ 日志中间件           │  ← 记录 method/path/IP/UA
+│ (log_request)        │
+└──────────┬───────────┘
+           │
+           ▼
+┌──────────────────────┐
+│ 鉴权中间件           │  ← 优先读 cookie，fallback Bearer
+│ (authenticate)      │     Bearer 仅用于内部服务调用
+└──────────┬───────────┘
+           │
+           │ 判断：path 是否在白名单？
+           │
+     ┌─────┴──────┐
+     │            │
+   YES (白名单)  NO
+     │            │
+     │            ▼
+     │   ┌──────────────────────┐
+     │   │ require_auth 装饰器  │  ← 验证 session_id
+     │   │   - 查 sessions 表   │     校验：
+     │   │   - 校验 session_hash│     1. session 存在
+     │   │   - 校验 expires_at  │     2. 未撤销
+     │   │   - 校验密码 epoch   │     3. 未过期
+     │   │   - 续期（如活跃）   │     4. password_epoch 匹配
+     │   └──────────┬───────────┘
+     │              │
+     │              ▼
+     │   ┌──────────────────────┐
+     │   │ 业务中间件           │
+     │   │ (业务逻辑处理)       │
+     │   └──────────┬───────────┘
+     │              │
+     │              ▼
+     │   ┌──────────────────────┐
+     │   │ 日志中间件（出口）   │  ← 记录 status/duration/user_id
+     │   └──────────────────────┘
+     │
+     └──▶ 业务中间件（白名单接口无需鉴权）
+```
+
+### 5 个鉴权端点
+
+| 端点 | 方法 | 说明 |
+|------|------|------|
+| `/api/login` | POST | 账号密码 → 校验 → 创建 session → 设置 cookie |
+| `/api/logout` | POST | 清 cookie → 撤销 session（revoked_at=now） |
+| `/api/password-reset/request` | POST | 生成 token → 邮件/日志通知（内网暂用日志） |
+| `/api/password-reset/confirm` | POST | 校验 token → 改密码 → 撤销该用户所有 session |
+
+### 装饰器改造
+
+```python
+# 现状
+@require_auth
+def api_records(): ...
+
+# 改造后（伪代码，BIZ-129 实施）
+@require_auth  # 内部自动读 cookie 或 Bearer
+def api_records(): ...
+
+# 新增装饰器
+@require_admin  # role == 'admin' 才允许
+def admin_only_api(): ...
+```
+
+---
+
+## 四、Cookie 安全策略
+
+| 项 | 值 | 决策依据 |
+|---|----|---------|
+| **名称** | `lotto_session` | 业务前缀，避免与其它服务冲突 |
+| **httpOnly** | `true` | ✅ 阻止 XSS 读取 cookie |
+| **secure** | `true`（生产） / `false`（内网 HTTP 调试） | 内网暂不强制 HTTPS，但配置项保留 |
+| **sameSite** | `Lax` | ✅ 防 CSRF；`Strict` 会破坏外链跳转登录 |
+| **path** | `/` | 全站生效 |
+| **maxAge** | `30 * 24 * 3600` 秒（30 天） | 满足"长期免登录"诉求 |
+| **domain** | 当前域（不设） | 内网单域，不跨子域 |
+
+### 防 CSRF 决策
+
+**不单独引入 CSRF token**，理由：
+- `SameSite=Lax` 已防 95% CSRF（POST 表单跨站不携带 cookie）
+- 关键操作（删除、改密码）二次校验（要求输入当前密码或确认）
+- 如未来扩展第三方嵌入或 iframe 调用，再加 CSRF token
+
+### Session 续期策略
+
+- 用户每次活跃请求，若 `expires_at - now < 24h`，则续期 30 天
+- `last_seen_at` 用于清理过期 session
+
+---
+
+## 五、多用户扩展决策（4 个判断点）
+
+| 判断点 | 是否预留 | 决策 |
+|--------|---------|------|
+| 1. 数据库 `users.tenant_id` / `role` 字段 | **✅ 预留** | 已建字段，索引就绪，单租户默认 1 |
+| 2. API 路径 `/api/admin/users/*` | **❌ 不预留** | 过度设计；未来需要时再加，无需现在占坑 |
+| 3. 前端「多用户切换」入口 | **❌ 不预留** | UI 保持单用户登录，多用户场景届时再迭代 |
+| 4. 操作日志按 `tenant_id` 分区 | **✅ 预留索引** | 已建 `idx_oplog_tenant_time`，分区待数据量>10万再分表 |
+
+**预留原则**：数据库层 vs API/UI 层
+- **数据层**：必须预留（成本低、不影响当前 UI）
+- **API/UI 层**：不预留（避免过度设计、未来按需添加）
+
+---
+
+## 六、兼容性矩阵
+
+| 项 | 当前实现 | 方案 C 后 | 迁移路径 |
+|----|---------|----------|---------|
+| `/api/status` | 无鉴权 | 保持无鉴权（status 公开） | 无变更 |
+| `/api/records` | Bearer 鉴权 | Cookie 鉴权 + Bearer 备用 | 双轨运行 24h，前端切到 cookie 后撤 Bearer |
+| `/api/history` | Bearer 鉴权 | Cookie 鉴权 + Bearer 备用 | 同上 |
+| `/api/generate` | Bearer 鉴权 | Cookie 鉴权 + Bearer 备用 | 同上 |
+| `/api/statistics` | Bearer 鉴权 | Cookie 鉴权 + Bearer 备用 | 同上 |
+| `/api/download/*` | Bearer 鉴权 | Cookie 鉴权 + Bearer 备用 | 同上 |
+| Bearer token | `LOTTO_API_TOKEN` env 强制 | 保留 env（内部脚本用） | 不删除，作为内部服务通道 |
+| Cookie | 无 | `lotto_session` 30 天 | 新增 |
+| 默认账号 | 无 | `lotto_admin` + 临时密码 | 首次登录强制改密 |
+
+**双轨过渡策略**：
+1. 上线 Cookie 鉴权后，前端自动改用 cookie
+2. Bearer 通道保留 24h 给内部脚本迁移
+3. 24h 后仅允许 Bearer 用于 `/api/internal/*`（如有）
+4. 监控 `/api/records` 等接口的鉴权失败日志，确认为 0 后撤 Bearer
+
+---
+
+## 七、性能 + 安全边界（5 项决策）
+
+| 项 | 决策 | 理由 |
+|----|------|------|
+| 1. bcrypt cost=12 登录耗时 | **目标 < 500ms（实测 ~250ms）** | Ubuntu 22.04 + bcrypt cost=12 单次 ~250ms，远低于 500ms 上限 |
+| 2. Session 失效机制（改密） | **改密码后该用户所有 session 立即失效** | session 表 `password_epoch` 字段；登录时快照，改密后 `password_changed_at` 更新，session 自动失效 |
+| 3. 找回密码 token 速率限制 | **每用户 3 次/小时** | 防爆破；超限返回 429 |
+| 4. 登录失败锁定 | **5 次失败锁定 15 分钟** | `users.failed_attempts` + `locked_until`；自动解锁 |
+| 5. 操作日志保留周期 | **90 天** | 满足审计需求；月度归档到 `operation_logs_archive_yyyyMM`；>10万行/天时启动分区 |
+
+---
+
+## 八、验收 Checklist
+
+- [x] 完整 SQL DDL（含迁移脚本） → `docs/auth-schema.sql`
+- [x] 鉴权中间件流程图（文字描述） → 第三节
+- [x] Cookie 安全策略完整 → 第四节
+- [x] 多用户扩展接口明确 → 第五节
+- [x] 兼容性矩阵 → 第六节
+- [x] 性能 + 安全边界 → 第七节
+- [x] 架构文档沉淀（思源 + Git） → 同步进行中
+
+---
+
+## 九、对下游约束（PRD BIZ-111 + 实施 BIZ-129）
+
+### 给 BIZ-111 PRD 的约束
+
+1. **登录页**必须有：用户名、密码、"记住我"勾选（默认勾选=30天免登录）
+2. **找回密码流程**：输入用户名 → 后台生成 token → 通过日志/邮件通知（内网暂用日志）
+3. **首次登录强制改密**：检测 `password_changed_at == created_at` 时，强制跳改密页
+4. **UI 不暴露**多用户切换、注册入口（保持单账号）
+
+### 给 BIZ-129 实施的约束
+
+1. **必须用 bcrypt cost=12**，不要用 sha256/md5/pbkdf2
+2. **session_id 必须 32 字节 URL-safe base64**（`secrets.token_urlsafe(32)`）
+3. **session_hash = sha256(session_id + server_secret)**，secret 存 env
+4. **不改 LOTTO_API_TOKEN 流程**，保留 Bearer 作为内部通道
+5. **/api/status 必须保持公开**，不能误加鉴权
+6. **BIZ-109 严格鉴权基线不能回退**（不能因为 Cookie 引入新的 401 路径）
+
+---
+
+## 十、风险与待澄清
+
+| 风险 | 影响 | 应对 |
+|------|------|------|
+| 首次部署 bcrypt 哈希生成失败 | 登录失败 | BIZ-129 部署前在本地预生成哈希嵌入 init SQL |
+| Cookie 30 天过长，安全边界争议 | 安全 | `auth_settings.session_max_age_sec` 运行时可调 |
+| 多用户预留字段被误用 | 数据污染 | 在 BIZ-129 代码层加 `tenant_id == 1` 断言 |
+| 操作日志 90 天后未归档 | 磁盘膨胀 | BIZ-129 实施时同时交付归档脚本 |
+
+---
+
+## 十一、变更历史
+
+| 版本 | 日期 | 变更 | 作者 |
+|------|------|------|------|
+| v1.0 | 2026-09-04 | 初版（BIZ-127 架构交付） | 梁思筑 |

specs/SOP-017_知识缺口上报SOP_v1.1_草案.md

@@ -0,0 +1,426 @@
+# SOP-017：知识缺口上报 SOP（v1.1 草案）
+
+> **版本**：v1.1 草案  
+> **基线**：SOP-017《知识缺口上报 SOP》v1.0（2026-07-06）  
+> **起草人**：刘诗妮（secretary）  
+> **送审人**：陆怀瑾（COO）  
+> **起草日期**：2026-10-29  
+> **关联 Issue**：BIZ-158  
+> **状态**：草案，待 COO 审核与刘炜承批准；批准前不替代 v1.0
+
+---
+
+## 0. 修订说明与系统定位
+
+### 0.1 修订背景
+
+v1.0 第 5 节 Step 3 仍指向旧工单通道。该流程已与公司现行编排规则不一致，导致知识缺口上报缺少可追踪的书面记录。
+
+### 0.2 系统定位（新增）
+
+| 系统 | 定位 | 用途 | 不承担的职责 |
+|------|------|------|--------------|
+| **Multica** | **唯一书面真相源与主工单通道** | 任务建单、缺口登记、补全任务、状态与评论回写、闭环追踪 | 无 |
+| **Gitea** | 代码与文档版本控制系统 | 代码、配置、方案、报告、记忆的版本控制与审阅 | 不作为工单、知识缺口登记或任务状态跟踪通道 |
+| **思源知识库** | 人类浏览与编辑层 | 最终版 SOP、指南、制度 | 不承担工单流转 |
+| **memory / wiki** | Agent 查询层 | 知识检索与读取 | 不承担工单流转 |
+| **WorkBoard** | 内部执行看板（辅助） | 需要时承载可执行补全卡片；不得取代 Multica issue 作为书面真相源 | 不取代 Multica 记录、状态与评论 |
+
+> **原则**：Multica 优先，Gitea 退位。任何知识缺口只有完成 Multica 建单并回写 issue id，才视为完成“登记”。Gitea commit、PR 或仓库文件均不能替代 issue id。
+
+---
+
+## 1. 目的
+
+解决知识缺口“发现后无书面登记、无主通道、无法追踪闭环”的问题，使每个影响任务交付的知识缺口都可查询、可审核、可补全、可量化。
+
+---
+
+## 2. 适用范围
+
+全部 Agent（产研线、运营线、职能线），以及负责知识补全的责任人。
+
+---
+
+## 3. 知识缺口定义与判据
+
+### 3.1 定义
+
+**知识缺口** = 执行任务时发现知识库（memory / wiki / 思源）中找不到的、且影响任务交付或决策质量的必要知识。
+
+### 3.2 属于知识缺口的情况
+
+| # | 类型 | 示例 |
+|---|------|------|
+| 1 | 核心业务数据缺失 | 缺少业务线 KPI 历史、竞品基准或经营口径 |
+| 2 | 核心 SOP / 流程文档缺失 | 没有对应流程标准，操作无法一致执行 |
+| 3 | 决策依据缺失 | 选型或决策缺少可核验的数据与依据 |
+| 4 | 模板 / 指南缺失 | 缺少 PRD、验收、交接等标准模板 |
+| 5 | 外部信息缺失 | 需要外部文档、资质或条款且现有知识库无存档 |
+| 6 | 技术 / API 文档缺失 | 缺少接口规范、配置说明或操作文档 |
+| 7 | Agent 配置 / 技能文档缺失 | 新 Agent 接入缺少必要说明或配置参考 |
+
+### 3.3 什么不算知识缺口
+
+**直接沿用 SOP-017 v1.0 第 3 节“**不属于知识缺口的情况**”，不重复制定替代判据**：
+
+| # | 场景 | 应对方式 |
+|---|------|----------|
+| 1 | 可通过 `web_search` / `tavily_search` 快速获取的公开信息 | 自行检索 |
+| 2 | 可通过 `memory_search` / `wiki_search` 检索到的现有知识 | 自行读取 |
+| 3 | 可通过联系对应 Agent 获得的信息 | 直接联系 |
+| 4 | Agent 自身职责范围内的常识 | 无需上报 |
+
+补充说明：任务执行中的临时疑问若不影响交付质量或决策准确性，记录在任务评论即可，不构成知识缺口。
+
+---
+
+## 4. 触发条件
+
+完成执行前检索（SOP-016）后，满足以下任一条件即触发上报：
+
+1. `memory_search(corpus=all, ...)`、`wiki_search` 与思源全文搜索均无匹配；
+2. 检索有结果，但缺少支撑当前任务或决策的关键环节；
+3. 任务执行中发现缺少必要规范、模板、指南、数据或外部存档；
+4. 现有口径互相冲突，无法判定应采用哪一项。
+
+> 外部公开信息可快速获取时，按第 3.3 节自行检索，不进入本流程。
+
+---
+
+## 5. 上报流程（Multica 主通道）
+
+### 5.1 流程总览
+
+```text
+发现知识缺口
+  → Step 1 记录：在当日 memory 日志及当前任务评论中记录
+  → Step 2 通知：sessions_send 通知 COO
+  → Step 3 建单：multica issue create，并在日志/评论回写 issue id
+  → Step 4 审核：COO 审核接受 / 拒绝 / 升级
+  → Step 5 补全卡：COO 在 Multica 创建补全任务并关联原上报 issue
+  → Step 6 补全：责任 Agent 完成知识补全并提交证据
+  → Step 7 闭环：COO 验收、关闭补全任务与原上报 issue，回写结果
+```
+
+### 5.2 逐步动作与命令
+
+#### Step 1：记录
+
+**动作**：在 `memory/YYYY-MM-DD.md` 追加标准格式记录；若当前已有 Multica issue 或 WorkBoard 卡片，同时在该任务评论中粘贴同一份记录。
+
+```bash
+# 路径示例；按实际日期写入对应文件
+memory/YYYY-MM-DD.md
+```
+
+记录必须包含第 6 节标准格式、已执行的检索方式与 query、当前任务 id / 标题。不得只写“知识缺失”而没有证据。
+
+#### Step 2：通知 COO
+
+**动作**：通过 `sessions_send` 通知 COO（陆怀瑾），请求审核；同时保留 Multica 建单动作。
+
+```text
+sessionKey: agent:coo:feishu:coo:direct:ou_9f73b4e54af59f038e2b754793ea0908
+```
+
+通知正文必须包含：缺口类型、一句话描述、影响、紧急程度、建议处理方式、已记录位置、已执行的检索证据。
+
+> 通知不是登记的替代品。若 Step 3 建单失败，应立即在通知中说明失败原因，并在恢复后补建。
+
+#### Step 3：在 Multica 建单并回写 issue id（核心步骤）
+
+**动作**：使用 `multica issue create` 创建“知识缺口上报”书面项；从 stdout 取得 issue identifier（如 `BIZ-123`）后，立即回写当日日志和当前任务评论。
+
+```bash
+cat > gap_description.md <<'EOF'
+## 📚 知识缺口上报
+
+**缺口类型**：[核心业务数据 | SOP 缺失 | 决策依据 | 外部信息 | 技术文档 | 模板/指南缺失 | Agent 配置]
+**缺口描述**：[具体缺什么，以及为什么影响当前任务或决策]
+**影响范围**：[哪些任务、决策或 Agent 受影响]
+**紧急程度**：[高/中/低]
+**建议补全方式**：[需要谁提供、查什么、创建什么文档]
+
+## 已执行的检索
+- `memory_search(corpus=all, query="[实际 query]")`：无结果 / 结果不足
+- `wiki_search(query="[实际 query]")`：无结果 / 结果不足
+- 思源全文搜索 `[实际 query]`：无结果 / 结果不足
+
+## 当前任务
+- 任务：[任务标题或 id]
+
+## 验收标准
+- [ ] 缺口所需知识已补全并可检索
+- [ ] 补全内容含来源、版本 / 生效日期与归档路径
+- [ ] 原上报 Agent 已收到闭环通知
+EOF
+
+multica issue create \
+  --title "知识缺口-<领域>-<关键词>" \
+  --description-stdin \
+  --assignee coo \
+  --priority high \
+  --status backlog \
+  < gap_description.md
+```
+
+> 优先级口径：高 = 阻塞当前任务；中 = 有 workaround 但影响效率；低 = 可排期改进。若 Multica 当前工作区要求项目归属，应使用 `multica project list` 确认有效 `<pid>` 后追加 `--project <pid>`；不得臆造 pid。
+
+**回写动作**：拿到 issue id 后，将下列内容追加到 `memory/YYYY-MM-DD.md` 和当前任务评论：
+
+```markdown
+**Multica 上报 issue id**：[ISS-123]
+**建单时间**：[YYYY-MM-DD HH:MM]
+```
+
+只有包含 issue id 回写的记录，才计入“知识缺口上报通道是否落地”的分子（见第 7 节）。
+
+#### Step 4：COO 审核
+
+**动作**：COO 核对检索证据、缺口定义、影响范围、紧急程度与建议补全方式，并给出以下结论之一：
+
+- **接受**：进入 Step 5；
+- **拒绝**：在原上报 issue 评论中说明理由并关闭；
+- **升级**：涉及预算、外部采购、跨部门资源或战略决策时，转刘炜承决策，并在 issue timeline 保留升级记录。
+
+COO 不得仅在飞书消息中口头处置而不在 Multica 留下评论或状态记录。
+
+#### Step 5：创建补全卡（Multica 补全任务）
+
+**动作**：COO 在 Multica 创建补全任务，关联原上报 issue，并设置 stage / 依赖关系。
+
+```bash
+cat > gap_remediation.md <<'EOF'
+## 补全目标
+
+[说明需要补齐的知识及验收口径]
+
+## 来源与证据
+
+[原上报 issue id、检索证据、缺口影响]
+
+## 验收标准
+- [ ] 补全内容可被 memory_search / wiki_search 检索
+- [ ] 文档包含版本 / 生效日期、维护者与归档路径
+- [ ] 原上报 issue 中回写补全链接并通知原上报 Agent
+EOF
+
+multica issue create \
+  --title "[知识补全] <缺口主题>" \
+  --description-stdin \
+  --parent <原上报-issue-id> \
+  --stage 1 \
+  --assignee <领域责任人> \
+  --priority <high|medium|low> \
+  < gap_remediation.md
+```
+
+说明：
+
+- `<原上报-issue-id>` 与 `<领域责任人>` 必须使用实际值，不得保留尖括号占位符；
+- 责任矩阵沿用现行《知识缺口上报 SOP v1.0》第三节；无法匹配时由 COO 明确指派；
+- 若同时使用 WorkBoard 承载执行，仍须以该 Multica 补全任务记录状态与验收结果，不得只维护 WorkBoard。
+
+#### Step 6：补全
+
+**动作**：责任 Agent 在补全任务中完成知识产出，并提交可验证证据：
+
+1. 补全文档 / 数据 / 决策记录及其归档路径；
+2. 版本号、生效日期、维护者；
+3. 检索验证结果（`memory_search` / `wiki_search` 能命中）；
+4. 与原上报 issue 的关联说明。
+
+补全任务的状态更新只能在实际完成后进行；不得以“已创建文档”替代“已完成补全”。
+
+#### Step 7：闭环
+
+**动作**：COO 验收补全内容，确认检索可命中、证据齐全后：
+
+1. 在补全任务中回写验收结论、链接和验收人；
+2. 在原上报 issue 中回写补全 issue id、验收结论与闭环时间；
+3. 按 Multica 流程关闭补全任务及原上报 issue；
+4. 通过 `sessions_send` 通知原上报 Agent：
+
+```text
+【知识缺口已补全】
+原上报 issue：[ISS-123]
+补全 issue：[ISS-456]
+补全内容：[文档链接或归档路径]
+验收结论：[通过 / 需返工]
+后续可直接检索使用。
+```
+
+闭环的完成标志是：原上报 issue 与补全 issue 均有验收和闭环记录，且原上报 Agent 已收到通知。
+
+---
+
+## 6. 标准上报格式
+
+### 6.1 核心模板（与 BIZ-84、`SOP_知识缺口上报_v1.0.md` 口径一致）
+
+以下五项为必填核心字段：
+
+```markdown
+## 📚 知识缺口上报
+
+**缺口类型**：[核心业务数据 | SOP 缺失 | 决策依据 | 外部信息 | 技术文档 | 模板/指南缺失 | Agent 配置]
+**缺口描述**：[具体缺什么，为什么影响任务]
+**影响范围**：[哪些任务/决策/Agent 受影响]
+**紧急程度**：[高/中/低]
+**建议补全方式**：[希望怎么处理；需要谁提供、查什么、创建什么文档]
+```
+
+### 6.2 登记证据与任务关联（随模板一并记录）
+
+```markdown
+## 已执行的检索
+- `memory_search(corpus=all, query="[实际 query]")`：[结果]
+- `wiki_search(query="[实际 query]")`：[结果]
+- 思源全文搜索 `[实际 query]`：[结果]
+
+## 当前任务
+- 任务：[任务标题或 id]
+
+## Multica 登记
+**Multica 上报 issue id**：[ISS-123]
+**建单时间**：[YYYY-MM-DD HH:MM]
+```
+
+> 字段顺序可调整；五个核心字段不得删减。issue id 只有在 `multica issue create` 成功后才能填写。
+
+---
+
+## 7. 量化口径与运营指标（改进）
+
+### 7.1 直接计数口径
+
+将知识缺口运营指标从“抽样评论中是否含检索证据”的代理指标，改为直接统计：
+
+> **知识缺口上报通道落地数 = 在日志或任务评论中回写了 Multica issue id 的知识缺口上报记录数。**
+
+### 7.2 计算方法
+
+设：
+
+- `G` = 周期内确认的知识缺口总数（每条缺口按唯一上报记录计数）；
+- `I` = 周期内含有效 Multica issue id 回写的知识缺口上报记录数。
+
+则：
+
+```text
+通道落地率 = I / G × 100%
+```
+
+计数规则：
+
+1. 一条缺口对应一个 Multica 上报 issue，按 issue id 去重；
+2. 只有日志或任务评论中明确回写该 issue id，才计入 `I`；
+3. 仅发飞书通知、仅创建 WorkBoard 卡片、仅提交仓库 commit / PR、仅口头上报，均不计入 `I`；
+4. `G = 0` 时，本周期通道落地率记为“不适用（无知识缺口）”，不得记为 0%；
+5. 月度巡检报告须列出：本期 `G`、本期 `I`、通道落地率、去重后的 issue id 清单及未落地原因。
+
+### 7.3 建议目标
+
+- **通道落地率目标：≥ 80%**；
+- **P0 缺口落地率目标：100%**；
+- 未落地项须在下一次巡检前完成补建或记录明确豁免原因。
+
+---
+
+## 8. 优先级与响应时限
+
+| 优先级 | 定义 | 建议响应时限 | 建议补全时限 |
+|--------|------|--------------|--------------|
+| 高 / P0 | 阻塞当前任务，无法继续执行 | COO 4 小时内响应 | 24 小时内补全 |
+| 中 / P1 | 有 workaround，但影响效率或质量 | COO 1 个工作日内响应 | 3 个工作日内补全 |
+| 低 / P2 | 当前可正常运行，属于改进建议 | COO 1 周内响应 | 按排期补全 |
+
+> 上表的“高 / 中 / 低”用于标准模板和 Multica 优先级；“P0 / P1 / P2”沿用 v1.0 分级语义，两者一一对应，不另行造轮子。
+
+---
+
+## 9. COO 审核标准
+
+| 审核项 | 标准 |
+|--------|------|
+| 是否真正检索过 | 上报记录包含实际 query 与结果，而非只写“已检索” |
+| 是否属于知识缺口 | 对照第 3 节；第 3.3 节四类场景应驳回并引导自行处理 |
+| 是否完成 Multica 登记 | 原上报 issue 已创建，issue id 已回写 |
+| 优先级是否合理 | 根据影响范围与阻塞程度判断 |
+| 补全方式是否可行 | 责任人、产出形式、归档位置和验收标准明确 |
+| 闭环是否可验证 | 补全后能通过 `memory_search` / `wiki_search` 命中 |
+
+### 审核结果与处理
+
+| 结果 | 处理方式 |
+|------|----------|
+| 接受 | 创建关联的 Multica 补全任务并明确责任人 |
+| 拒绝 | 在原上报 issue 评论中说明理由，关闭 issue |
+| 升级 | 转刘炜承决策，在 issue timeline 与评论中留存记录 |
+
+---
+
+## 10. TOOLS.md 注入模板（同步替换旧流程）
+
+```markdown
+## 📚 知识缺口上报
+
+> 完整 SOP 见 `specs/SOP-017_知识缺口上报SOP.md`；待 v1.1 批准后更新引用版本。
+
+### 触发条件
+执行 SOP-016 检索后，满足以下任一条件需上报：
+1. 核心业务数据 / SOP / 决策依据缺失；
+2. 缺失影响任务交付质量或决策准确性；
+3. 无法通过 memory_search / wiki_search / 思源全文搜索获得必要知识。
+
+### 不属于知识缺口的情况
+直接引用 SOP-017 v1.0 第 3 节，不另行维护副本。
+
+### 上报流程
+1. **记录**：在 `memory/YYYY-MM-DD.md` 与当前任务评论中使用标准格式记录；
+2. **通知**：通过 `sessions_send` 通知 COO；
+3. **建单**：执行 `multica issue create`，并回写 issue id；
+4. **审核与补全**：COO 审核后创建关联的 Multica 补全任务；
+5. **闭环**：COO 验收并关闭 issue，通知原上报 Agent。
+
+### 标准格式
+见 SOP-017 第 6 节。核心字段：缺口类型、缺口描述、影响范围、紧急程度、建议补全方式。
+```
+
+---
+
+## 11. 生效、迁移与维护
+
+### 11.1 生效条件
+
+- 本文件为 v1.1 **草案**，经 COO 审核并由刘炜承批准后方可生效；
+- 生效后应以新文件替换现行引用，但不得直接改写 v1.0 本体，以保留历史基线；
+- 同步更新各 Agent `TOOLS.md` 中旧工单通道的上报步骤。
+
+### 11.2 迁移要求
+
+1. 检查所有 Agent 的 `TOOLS.md` / `AGENTS.md`，将“创建旧仓库 Issue 作为上报通道”替换为 Multica 建单并回写 issue id；
+2. 存量、尚未建 Multica issue 的知识缺口，按本 SOP 第 5 节补建并回写；
+3. 已存在的旧仓库 issue 不自动迁移为 Multica issue，但须在巡检报告中列出待补建清单；
+4. 对 Multica 建单失败项，保留失败日志，修复后补建，不以旧仓库替代。
+
+### 11.3 维护信息
+
+- **维护人**：COO（陆怀瑾）
+- **起草协助**：刘诗妮（secretary）
+- **review 周期**：每季度一次，或发生流程通道变更时即时修订
+- **基线保留**：`specs/SOP-017_知识缺口上报SOP.md`（v1.0）保持零改写
+
+---
+
+## 12. 版本历史
+
+| 版本 | 日期 | 变更内容 | 审批 |
+|------|------|----------|------|
+| v1.0 | 2026-07-06 | 初始版本；第 5 节 Step 3 使用旧工单通道 | 刘总 |
+| v1.1 草案 | 2026-10-29 | 上报主通道改为 Multica；增加 issue id 回写；统一标准格式；量化改为直接计数；Gitea 退位为版本控制 | 待审 |
+
+---
+
+*本草案承接 BIZ-158。批准前，SOP-017 v1.0 仍为现行基线。*

specs/SOP-018_跨境电商统计口径纪律_v1.0.md

@@ -0,0 +1,191 @@
+# SOP-018：跨境电商统计口径纪律
+
+> **版本**: v1.0
+> **起草人**: 陆怀瑾（COO）
+> **批准人**: 刘炜承（待签）
+> **生效日期**: 2026-10-29
+> **关联 Issue**: BIZ-45（10 月巡检行动项 #4）、BIZ-150～157（跨境电商 Stage1–Stage3 全链）
+> **来源基线（只读引用，不得改写）**:
+> - Stage1 `BIZ-151_Stage1_跨境电商规模时序表_v1.2.2.md`（sha256 `a7d3c958…b123631b`）
+> - Stage2-1 `BIZ-152_S2-1_表D结构扩表_v1.4.md`（`530a9fc5…8f0765f0`）
+> - Stage2-2 `BIZ-152_S2-2_区域口径核销_v1.2.md`（`27819a14…19e41bfb`）
+> - Stage2-3 `BIZ-152_S2-3_政策变量建模骨架_v1.3.md`（`122ab64f…2e2a50a2`）
+> - Stage3 终稿 `BIZ-150_跨境电商趋势简报_终稿_v1.2.md`（`c3415381…f9d6002`）
+> - 飞书决策版摘要 `BIZ-150_飞书决策版摘要_v1.2.md`（`6d209910…f406`）
+
+---
+
+## 1. 目的
+
+跨境电商规模、结构、政策变量三类数据的公开来源高度混杂，且多组数值**数值相近、口径不同**，最易发生「混用基数 → 算术全错 → 结论句失真」。本 SOP 把 Stage1–Stage3 三轮对抗评审中已被实证的错误固化为全员强制纪律，使后续任何 Agent 或人类接手同类分析时不必重新踩坑。
+
+**适用一句话判断**：只要分析涉及跨境电商的规模、增速、出口额、目的国/来源国、分省占比、CR5/CR10、政策变量影响，**全部适用**，无例外。
+
+---
+
+## 2. 三条最贵的坑（先看这三条）
+
+| # | 坑 | 后果 | 纪律 |
+|---|---|---|---|
+| 1 | **商指针「出口销售额 28388.5 亿元」误当海关出口额** | 与海关出口 22672 亿元差 +25.2%，会把 2025 出口增速由真实 5.4% 虚增至约 31% | 出口基数**只取 22672 亿元**；28388.5 禁入任何计算 |
+| 2 | **「2.84 万亿元」与「28388.5 亿元」当作同一值混用** | 两者相差 11.5 亿元，相对差 **0.0405%**（= 11.5 ÷ 28388.5） | 二者**禁混用**；引用时必须二选一并写明单位 |
+| 3 | **海关全业态 / 海关验放零售 B2C / 网经社广义三口径拼接算增速** | 零售旧口径（360.2→1862.1 亿元）与全业态量级差 7–8 倍；网经社对海关倍数 2018≈8.5、2025≈6.6，**倍数随基数变化** | 后两口径分口径单列，**禁跨期取倍数、禁拼序列** |
+
+---
+
+## 3. 唯一主序列与基数纪律
+
+### 3.1 主序列
+- **唯一主序列 = 海关全业态跨境电商进出口**。任何趋势、增速、结构分析只以该序列为底。
+- 出口基数（2025）：**22672 亿元**。
+- 商指针 28388.5 亿元、艾瑞 28.4%、网经社广义、海关验放零售旧口径：**一律禁入主序列与任何计算**。
+
+### 3.2 两对基数不可混引（Stage1 R9 / Stage2 S2-1 v1.1 实证）
+
+| 基数对 | 差值 | 相对差 | 适用 |
+|---|---|---|---|
+| 28400 ↔ 28388.5 | 11.5 亿元 | **0.0405%** | 同一「2025 年出口规模」表述的两种写法 |
+| 28374 ↔ 28388.5 | 14.5 亿元 | **0.0511%** | Stage1 R9 另一基数对 |
+
+> **禁止**：把 0.051% 挂到 28400 vs 28388.5 上。该错误已在 Stage2-1 v1.1 出现三处（§4.2、§七 #8、§六 结论句 7），由评审方误引 R9 数值引发，执行方照抄固化 —— **教训：复检方给错的数值，执行方照抄即成系统性错误，双方都有责**。
+
+### 3.3 初步数 ≠ 最终数
+海关每年调查两次（上年全年 + 本年上半年），公布值会修订：
+- 2025：初步 2.75 万亿 → 正式 2.84 万亿
+- 2024：初步 2.63 万亿 → 修订后约 2.71 万亿
+- 2021：公布 1.98 万亿后隐含下修至约 1.92 万亿
+
+**跨版本增速不采**；引用时必须写明「初步 / 正式（修订后）」。
+
+---
+
+## 4. 论断强度纪律（数值能不能进结论句）
+
+### 4.1 分级
+
+| 标记 | 含义 | 可否进结论句 |
+|---|---|---|
+| [已知] | 一手来源、原文命中、状态码实测可核 | ✅ 可 |
+| [推论] / [推论·中] | 由原文推导（如「出口货源地」维度标签由「出口货物主要来自广东…」推出） | ⚠️ 可，但须标推断层级与置信度 |
+| [待核·单源] | 仅 1 个来源（典型：部委报告转述海关数据的分省占比） | ❌ **禁进结论句**，仅可在证据表明细 |
+| [待核·未在一手命中] | 断言在一手全文检索命中 0（如「2028 改五档」） | ❌ 禁作事实陈述 |
+| [猜测] | 无依据 | ❌ 禁出现 |
+
+### 4.2 「单源不进结论句」的完整判据（Stage2-2 教训）
+**不是只查「分点值」**。判定要看结论句内**每一个数值**的来源条数：
+- 案例：Stage2-2 v1.1 结论句删掉了 49.4%、16.7% 等分点值，却仍写了「五省合计 81.2%」「进口合计 45.4%」——这两项与分点值同为**单源一手**（商务部《2025 中国数字贸易发展报告》转述海关数据，无独立第二来源），仍属单源值进结论句。
+- **正确形态**：结论句只陈述「原文已取得、载体、链接实测状态码、数值明细见证据表」，**不复述任何单源数值**。
+
+### 4.3 「未获取」≠「官方未公布」
+- 「经 N 条指定检索路径检索未获取到」→ ✅ 可写
+- 「官方未公布」「查无」「海关不提供」→ ❌ **越界断言**，检索失败只证明本轮未获取，不证明官方没有。
+
+### 4.4 反面证据必须前置披露
+执行方已抓到的一手数值若因保守未写入，按事实错误处理；**只引支持性证据、不引反面证据，构成选择性取证**。
+- 实例：Stage2-3 v1.0 只写 Drewry WCI +2%，漏写 SSE 官方 CCFI −2.41%、波红航线 −5.39% 领跌 → 打回。
+
+---
+
+## 5. 时态与内生关系纪律
+
+### 5.1 「已生效在执行中」≠「影响已内生于既有基数」
+判断方法：**政策生效时点 vs 观测区间上界**。生效时点晚于观测上界 → **零内生**，是后续区间的新增扰动。
+
+| 变量 | 生效时点 | 2026H1 观测上界 | 内生判定 |
+|---|---|---|---|
+| 欧盟 150 欧关税减免取消（Reg (EU) 2026/382） | 2026-07-01 | 2026-06-30 | **零内生**（唯一） |
+| 美国 de minimis | 2025-05-02 对华港 / 2025-08-29 全球 / 2026-06/07 CBP 无限期暂停并入规章 | — | 已（部分）内生，归因待剥离 |
+| GPSR | 2024-12-13（Art 52 适用；Art 51 为祖父条款） | — | 已（部分）内生，归因待剥离 |
+| 红海绕行 | 持续 | — | 已（部分）内生，归因待剥离 |
+
+### 5.2 未来时点必须单列
+OBBBA §70531(b) **2027-07-01** 法定永久终止属**未来时点**，不得省略，否则读者会误以为该变量已封顶。
+
+### 5.3 法律性质不得偷换
+- 欧盟 150 欧 = **取消 ≤150 欧元的关税减免**（2026-07-01→2028-07-01 按 EUR 3/件，仅限 IOSS 与邮政路径；Art 3 自 2026-10-01 每月评估）
+- ❌ 不是「收紧至 150 欧」；❌ 不是「增值税门槛」（从未涉及进口增值税）
+
+---
+
+## 6. 来源与链接可访问性纪律
+
+### 6.1 四类定性法（同站对照实验：首页 + 栏目页 + 目标路径三连测）
+
+| 类型 | 特征 | 处置 |
+|---|---|---|
+| 站点反爬 | 该站**所有**路径同一拦截码，返回 js 校验页 | **≠ 死链**。属有效一手来源，正文经代理通道取；**不得进失败链接表**（如 customs.gov.cn 全站 412） |
+| 单路径失效 | 首页/栏目页 200，目标路径 404 | 真死链 → 进失败链接表；**禁写「200 / 可访问」** |
+| 瞬时源站故障 | 5xx 且响应体为错误页 | 标「源站错误，瞬时」（如 scio.gov.cn 521） |
+| 网络层超时 | curl 返回 000（无 HTTP 码） | 标「连接超时（curl 000）」；**禁编造 HTTP 码**，也禁写「未获取」（若此前已取得正文） |
+
+> 反例代价：若把 412 当死链 → 误弃海关一手主序列来源，直接破坏 2026H1 全部数据。
+
+### 6.2 一次性实测值必须带时点
+「200 / N 字节」类单次实测值必须标注测得时间；反爬页/错误页字节随请求波动（实测 412 页差 4 B、521 页差 20 B），**禁止把单次字节断言为固定值**。可写「约 X KB」。
+
+### 6.3 指控前先找原始下载件
+涉及「臆造/伪造」的指控，必须先在磁盘找执行方的原始下载件/中间产物（如 `/tmp/*.pdf`）：
+- 找不到 → 只能说「无来源、不可复现」
+- 找到了 → 应定性为「未标时点、复核期不可复现」，**不是编造**
+- 真实案例：Stage2-3 v1.1 曾把 UNCTAD PDF 写成 200/10,463,733 B，COO 一度定性「臆造」；后经 `/tmp/rmt2024.pdf` 实物（合法 PDF，2026-10-28 13:32 下载）证明字节逐字节吻合 → 撤回定性。
+
+### 6.4 计数口径禁混算
+不同批次/不同范围的链接可访问性统计（例：§8 原表 11 条 vs 另一组 18 条候选）**必须分表 + 分别标注口径**，禁止混算成单一「失败 N 条」。
+
+---
+
+## 7. 交付与版本纪律
+
+1. **交付即冻结**：执行方一落盘，评审方立即复制审计副本并记录 sha256；冻结必须早于任何后续派发。
+2. **禁止就地改写**：每次修订必须新出版本文件。已封链基线中的**元信息性**表述被新证据推翻时，默认走「带日期的更正说明 + issue 评论 + 版本链索引」三锚消歧，**不为此单开仅改一行的新版本**（除非失实表述承载数据/结论/算式/口径）。
+3. **阶段间依赖门控**：Stage2-3 放行须 Stage2-1 通过；Stage3 放行须全部上游通过。任何卡未通过评审 → 下游保持 todo，不放行。
+4. **衍生件必须单独评审**：全链收口 ≠ 收口后新增产物自动免检。要发给老板的对外件必须单独走一轮对抗评审（实例：飞书决策版摘要 v1.0 曾自行新增终稿中没有的法条号与日期，且标「置信度：高」→ 打回）。
+5. **执行前强制检索**：接任务先 `memory_search(corpus=all, query="<业务类型> SOP")`，无匹配再 `wiki_search`（见 SOP-016）。
+
+---
+
+## 8. 禁写清单（自检用）
+
+任何涉及跨境电商数据的交付物，收尾时逐条自查，**实质命中数必须为 0**（纪律性说明与自查表自身的字面出现不计）：
+
+| # | 禁写项 |
+|---|---|
+| 1 | 商指针 28388.5 进入任何计算或主序列 |
+| 2 | 艾瑞 28.4% / 36.5% 进入结论或与海关直接对比 |
+| 3 | 网经社 18.68 万亿作为主序列 |
+| 4 | 零售旧口径 360.2/499.6/902.4/1347/1862.1 用于增速计算 |
+| 5 | 「2.84 万亿元」与「28388.5 亿元」混用 |
+| 6 | 28400↔28388.5 的相对差写成 0.051%（应为 0.0405%） |
+| 7 | 已作废分省值 51.1% / 58.7% 出现于任何段落 |
+| 8 | 2024 二手结构值与 2026H1 一手值拼成序列 |
+| 9 | 单源值 / 待核值进入结论句 |
+| 10 | 「官方未公布」「查无」类越界断言 |
+| 11 | 「收紧至 150 欧」「增值税门槛」「2026 年新规（指 GPSR）」 |
+| 12 | 失败链接口径混算 |
+| 13 | 臆造状态码；412 写入失败链接表；S6/S7 写作「200 / 可访问」 |
+| 14 | 占位符 / TBD / 待填类标记 |
+| 15 | 未经指定路径的插值、推测或邻近口径顶替 |
+
+---
+
+## 9. 未闭环项（不得插值、不得以邻近口径顶替）
+
+2015–2017 全业态官方值｜目的国逐年官方序列｜CR5/CR10｜B2B/B2C 官方拆分｜海外仓绝对规模｜2026 年度（含 2026H1）分省量化占比｜《中国数字贸易发展报告 2026》PDF｜各政策变量受影响件数与货值基数｜单位合规成本单价｜SSE 指数多期序列｜UNCTAD PDF 镜像二次确认｜OBBBA public law 编号｜欧盟 Art 3 首次月度评估结果｜Art 51 逐品类边界｜分品类占比、分省占比、独立站份额、综试区贡献率 97.2%（商指针口径）。
+
+---
+
+## 10. 存储与分发（BIZ-19）
+
+| 层 | 系统 | 本 SOP 落位 |
+|---|---|---|
+| 人类层 | 思源知识库 | `/规范/跨境电商统计口径纪律 v1.0` |
+| Agent 层 | Gitea（EnterpriseArchitect） | `specs/SOP-018_跨境电商统计口径纪律_v1.0.md` |
+| 查询层 | OpenClaw Wiki | 由记忆索引同步，供 `memory_search` 命中 |
+
+---
+
+## 11. 变更记录
+
+| 版本 | 日期 | 变更 | 起草/评审 |
+|---|---|---|---|
+| v1.0 | 2026-10-29 | 首版。汇编 Stage1–Stage3 全链三轮对抗评审已实证的 15 类口径错误与 4 类链接定性错误 | 陆怀瑾（COO） |