refactor: split android overlay out of storyforge

docs/AUDIT_2026-03-18.md

@@ -16,7 +16,6 @@
 - 知识库、智能体、任务管理
 - 视频链接/上传视频/文本三类入口
 - 下载器、ffmpeg、whisper.cpp 风格的本地处理调用
-- Android OTA 查询/发布
 
 ### 2. 旧数据集运行链实际承担的功能
 
@@ -180,12 +179,11 @@
 - `n8n` 工作流导出文件已纳入仓库
 - `collector-service` 的 live 运行态已回归到 `StoryForge-gitea` 自身源码构建，不再依赖旧导入目录的临时 bind mount
 - `collector-service` 现已在 live `8081` 提供 `/v2/douyin/*` 接口，并保留原有 `real-cut / ai-video / content-source-sync` 路由
-- Android Explore 页已补上“账号同步”入口，可直接创建内容源账号同步任务，并支持平台、主页链接、账号标识、最大抓取条数、跳过已存在、自动触发分析等参数
-- Android 工作区缺失的 `com.aiglasses.app.data` 数据层已从同源代码补回，当前 `./gradlew :app:compileDebugKotlin` 与 `:app:assembleDebug` 均已通过，并产出 `app-debug.apk`
+- 曾混入本仓库的 `android-app/` 已确认来自独立 `AI Glasses` 工程叠加，现已从 StoryForge 主仓库边界中拆出，后续不再作为当前主工作区的一部分维护
 
 ## 当前主要风险
 
 1. 小红书账号级内容源还未做真实平台验证
 2. `douyin` public 直抓仍受反爬限制，但现在已经有“真实浏览器 + 人工登录 + 自动提取 + 回写现有工作台”的可落地协作链
 3. `huobao-drama-upstream` 已完成代码迁移并可编译，但 fresh smoke 受外部图片/视频凭证 `403 invalid user` 阻塞
-4. Android 端目前已能完成 Debug APK 构建，但仍缺少真机安装和功能回归验证
+4. Android / OTA 旧链路已拆出当前仓库，相关验证和发布不再属于 StoryForge 主线范围

docs/LAN_E2E_GUIDE_2026-03-18.md

@@ -295,22 +295,18 @@ npm run capture -- \
   - `http://127.0.0.1:8081/healthz`
   - `http://127.0.0.1:5670/healthz`
 
-## 11. Android 本地构建
+## 11. Android 说明
 
-如果你要在本机重新打 Android 包：
+`android-app/` 已确认属于独立 `AI Glasses` 工程的叠加目录，现已从当前 StoryForge 主仓库拆出。
 
-```bash
-cd /Users/kris/code/StoryForge-gitea/android-app
-./gradlew :app:assembleDebug
-```
+当前联调范围只包含：
 
-当前已验证结果：
+- `collector-service`
+- `n8n`
+- `web/storyforge-web-v4`
+- `scripts/douyin-browser-capture`
 
-- `:app:compileDebugKotlin` 通过
-- `:app:assembleDebug` 通过
-- APK 输出路径：
-  - `/Users/kris/code/StoryForge-gitea/android-app/app/build/outputs/apk/debug/app-debug.apk`
+如果后续需要维护 Android / OTA 链路，请转到独立仓库：
 
-补充说明：
-
-- 工作区根目录的 `.gitignore` 里保留了通用 `data/` 忽略规则，但已对 Android 源码目录 `android-app/app/src/main/java/com/aiglasses/app/data/` 做了白名单放行，避免误伤客户端代码
+- Gitea：`https://git.hyzq.site/krisolo/ai-glasses`
+- 本机工作区：`/Users/kris/code/AI-glasses`

docs/MVP_STATUS_2026-03-18.md

@@ -10,8 +10,6 @@
 - `user -> project -> assistant / knowledge base / job / content source` 数据模型
 - 文本 / 视频链接 / 上传视频 三类分析任务创建
 - 内容源账号同步任务创建与子任务派发
-- Android Explore 页已补上内容源账号同步入口
-- Android `com.aiglasses.app.data` 数据层已补回，`compileDebugKotlin` 与 `assembleDebug` 已通过
 - `n8n` 工作流导入、激活与触发接口
 - 本地下载器调用
 - 本地 `ffmpeg` / `whisper` 风格入口封装
@@ -46,7 +44,6 @@
 - `douyin` 对标关系：`dyrel_c8df266341e74237b99c880eb4b572d8`
 - `huobao-upstream` 隔离 smoke 剧本：`drama_id=11` (`http://127.0.0.1:5681`)
 - `huobao-upstream` 隔离 smoke 启动脚本：`/Users/kris/code/huobao-drama-upstream/scripts/run_storyforge_smoke.sh`
-- Android Debug APK：`/Users/kris/code/StoryForge-gitea/android-app/app/build/outputs/apk/debug/app-debug.apk`
 - `douyin` 浏览器采集最小 smoke：`/tmp/storyforge-douyin-capture-smoke/2026-03-20T06-49-37.705Z-storyforge_test_001`
 - `douyin` 控制台 smoke：`/Users/kris/code/StoryForge-gitea/output/playwright/douyin/control-panel/run-mmyzplxp-cw0o7q/2026-03-20T14-24-13.174Z-storyforge_test_001`
 - `douyin` 控制台提前继续回归 smoke：`/Users/kris/code/StoryForge-gitea/output/playwright/douyin/control-panel/run-mmyzshsp-c6vdhi/2026-03-20T14-26-27.792Z-storyforge_test_001`
@@ -59,7 +56,7 @@
 - `douyin` 控制台点击流已可用，但它仍然依赖本机可打开 Chromium 的环境，不适合放进纯 Docker 容器内部跑 GUI
 - `huobao-upstream` 已能全量编译；并且旧改版隔离实例也已重放确认，当前 fresh 生成被外部图片/视频凭证统一返回 `403 invalid user`
 - `huobao-upstream` 已新增 `HUOBAO_TEXT_* / HUOBAO_IMAGE_* / HUOBAO_VIDEO_*` 运行时覆盖能力，后续补新 key 可直接接管数据库配置
-- Android Debug 包已可本地构建，但尚未完成真机安装验证
+- Android / OTA 链路已拆回 `AI Glasses` 独立仓库，不再纳入当前 StoryForge MVP 范围
 
 ## 下一步优先级
 

docs/STORYFORGE_REPO_BOUNDARY_2026-03-26.md

@@ -6,7 +6,8 @@
 
 - `StoryForge` 与 `AI Glasses` 是两个独立项目，分别独立维护。
 - 当前仓库只负责 `StoryForge` 的产品、运行时、联调、部署与发布。
-- 后续在本仓库中看到的 `AI Glasses` 命名残留，应优先视为历史迁移残留或暂未完成的命名收口，不应直接推导为“需要删除 AI Glasses 项目代码”。
+- `AI Glasses` 当前独立维护仓库为 [krisolo/ai-glasses](https://git.hyzq.site/krisolo/ai-glasses)。
+- 当前仓库已经移除混入的 `android-app/` 目录；历史提交中的 Android / `com.aiglasses.*` 痕迹只作为拆分审计证据保留。
 
 ## 当前仓库内属于 StoryForge 的主维护范围
 
@@ -14,21 +15,15 @@
 - `web/storyforge-web-v4/`：StoryForge Web 工作台和前端壳。
 - `scripts/douyin-browser-capture/`：抖音浏览器辅助采集与工作台控制台。
 - `n8n/`：StoryForge 编排工作流导出与说明。
-- `android-app/`：当前 StoryForge Android 客户端入口。
 - `deploy/`：StoryForge 部署模板与网关配置。
 - `docs/`：StoryForge 审计、联调、实施与产品逻辑文档。
 - `docker-compose.yml`、`.env.example`、`scripts/start_business.sh`、`scripts/status_business.sh`、`scripts/smoke_business.sh`：当前 StoryForge 运行与联调基线。
 
-## 需要特别注意的命名残留
+## 已拆出的独立项目边界
 
-以下内容说明 Android 客户端曾沿用旧命名空间，但当前业务入口已经是 StoryForge：
-
-- `android-app/app/src/main/java/com/aiglasses/app/`：Android 包名仍是 `com.aiglasses.app`。
-- `android-app/app/src/main/java/com/aiglasses/app/MainActivity.kt`：入口已经直接加载 `StoryForgeScreen` 与 `StoryForgeViewModel`。
-- `android-app/app/src/main/res/values/themes.xml`：主题名仍为 `Theme.AIGlasses`。
-- `android-app/app/build.gradle.kts`：构建命名空间仍与 `com.aiglasses.*` 保持一致。
-
-这些文件目前应被视为 StoryForge Android 客户端的迁移残留，不属于“删除 AI Glasses 项目代码”的操作范围。若未来要统一命名，应作为独立重构任务推进，而不是在日常功能开发中顺手清除。
+- `AI Glasses` 的 Android / BLE / Baidu / AAR / OTA 代码不再属于当前 StoryForge 主仓库边界。
+- 与其相关的当前维护仓库、分支、发布应在 `krisolo/ai-glasses` 中进行。
+- 若后续需要回看叠加来源，可参考 Git 历史中的 `acb1103`、`ac6a8a8`、`7070c3a`、`fe07a5f` 等提交，以及 [StoryForge / AI Glasses 拆分评估方案](./STORYFORGE_SPLIT_ASSESSMENT_2026-03-26.md)。
 
 ## 提交与同步边界
 
@@ -43,5 +38,5 @@
 - 后端与部署安全收口：去掉默认超级管理员口令依赖，强化 orchestrator secret 校验，新增 `readyz`，修复 `huobao/cutvideo` 超时串线。
 - n8n 工作流收口：内部回调地址与 secret 改为环境变量注入。
 - Web 稳定性与结构收口：修账号切换竞态，收紧会话存储，引入平台能力 gate，并拆出首批运行时模块。
-- Android 安全收口：会话加密存储、明文流量白名单、敏感输入遮罩、日志级别收紧。
+- 仓库边界收口：将混入的 `android-app/` 从 StoryForge 主仓库移出，并确认 `AI Glasses` 继续在独立 Gitea 仓库维护。
 - 基线验证：新增 `scripts/check_repo_baseline.sh` 作为统一回归入口。

docs/STORYFORGE_SPLIT_ASSESSMENT_2026-03-26.md

@@ -0,0 +1,252 @@
+# StoryForge / AI Glasses 拆分评估方案
+
+执行状态（2026-03-26）：
+
+- 已确认独立仓库存在：`https://git.hyzq.site/krisolo/ai-glasses`
+- 已确认本机独立工作区存在：`/Users/kris/code/AI-glasses`
+- 当前评估方案已进入执行阶段：`StoryForge-gitea` 将移除混入的 `android-app/`
+
+## 1. 结论摘要
+
+当前仓库的问题更像是“项目导入时发生了目录叠加”，而不是后续开发过程中出现了随机数据错乱。
+
+明确证据如下：
+
+- Gitea 现有历史只有一个根提交：`acb1103`，日期为 `2026-03-14`。
+- 这个根提交从一开始就包含完整的 `android-app/` 子树。
+- 该 `android-app/` 子树内同时存在：
+  - `StoryForge` 相关界面与接口代码；
+  - 明显属于 `AI Glasses` 的包名、BLE、Baidu 实时能力、硬件依赖和 AAR。
+
+因此，当前更合理的判断是：
+
+- `StoryForge` 与 `AI Glasses` 原本是两个独立项目；
+- 在 `StoryForge-gitea` 建库或导入时，把一个带 `AI Glasses` Android 子项目的目录整体叠加进来了；
+- 后续又在这个混合目录上继续写入了一部分 `StoryForge` Android 代码，导致边界越来越模糊。
+
+## 2. 现状诊断
+
+### 2.1 明显属于 StoryForge 的主干目录
+
+这些目录整体上是当前 StoryForge 的核心交付面：
+
+- `collector-service/`
+- `web/storyforge-web-v4/`
+- `scripts/douyin-browser-capture/`
+- `n8n/`
+- `deploy/`
+- `docs/`
+- `Common/`
+- `docker-compose.yml`
+- `.env.example`
+
+### 2.2 明显带有 AI Glasses 叠加痕迹的区域
+
+`android-app/` 是本仓库最明显的混合区，内部包含三类内容：
+
+1. 明显偏 AI Glasses / 硬件链路的内容：
+
+- `android-app/app/src/main/java/com/aiglasses/app/ble/BleManager.kt`
+- `android-app/app/src/main/java/com/aiglasses/app/software/BaiduConversationAgent.kt`
+- `android-app/app/src/main/java/com/aiglasses/app/software/BaiduRealtimeWsClient.kt`
+- `android-app/app/src/main/java/com/aiglasses/app/software/BaiduVisualUploader.kt`
+- `android-app/app/src/main/java/com/aiglasses/app/software/SoftwareConversationController.kt`
+- `android-app/app/src/main/java/com/aiglasses/app/ui/MainViewModel.kt`
+- `android-app/app/libs/lib_agent-1.0.1.4.aar`
+- `android-app/app/libs/brtc-3.5.0.1a.aar`
+
+2. 明显是 StoryForge 业务，但写在旧命名空间里的内容：
+
+- `android-app/app/src/main/java/com/aiglasses/app/storyforge/StoryForgeApiService.kt`
+- `android-app/app/src/main/java/com/aiglasses/app/storyforge/StoryForgeModels.kt`
+- `android-app/app/src/main/java/com/aiglasses/app/storyforge/StoryForgeRepository.kt`
+- `android-app/app/src/main/java/com/aiglasses/app/storyforge/StoryForgeScreen.kt`
+- `android-app/app/src/main/java/com/aiglasses/app/storyforge/StoryForgeSessionStore.kt`
+- `android-app/app/src/main/java/com/aiglasses/app/storyforge/StoryForgeViewModel.kt`
+- `android-app/app/src/main/java/com/aiglasses/app/MainActivity.kt`
+
+3. 明显属于旧项目命名残留的工程设置：
+
+- `android-app/settings.gradle.kts` 中的 `rootProject.name = "AIGlassesApp"`
+- `android-app/app/build.gradle.kts` 中的 `namespace = "com.aiglasses.app"`
+- `android-app/app/src/main/res/values/themes.xml` 中的 `Theme.AIGlasses`
+- `android-app/app/src/main/AndroidManifest.xml` 当前仍引用 `Theme.AIGlasses`
+
+### 2.3 Git 历史上的关键时间点
+
+- `2026-03-14` `acb1103`
+  - Gitea 根提交。
+  - 从第一天就已带入 `android-app/` 和 `com.aiglasses.*`。
+- `2026-03-20 14:10` `ac6a8a8`
+  - 开始明显向 StoryForge Android UI / 交互继续推进。
+- `2026-03-20 14:17` `7070c3a`
+  - 提交信息直接是 `restore android build path`，说明 Android 构建链被重新激活。
+- `2026-03-22` `fe07a5f`
+  - 明确进入 `storyforge mobile v4 shell` 阶段。
+
+结论是：Gitea 历史里没有“完全纯净、完全不含 Android 叠加痕迹”的版本，但存在“尚未明显进入 APK 推进阶段”的较早切点。
+
+## 3. 目标定义
+
+基于当前产品节奏，推荐把拆分目标定义成：
+
+- `StoryForge-gitea` 只保留 StoryForge 当前实际在推进的主线：
+  - Web
+  - Backend
+  - n8n orchestration
+  - Douyin browser capture
+  - deploy / docs / ops
+- `AI Glasses` 相关 Android / BLE / Baidu / AAR / OTA 旧链路，移出当前仓库边界。
+- 如果未来要做 StoryForge Mobile，重新在一个干净边界内启动，而不是继续沿用 `com.aiglasses.*` 的混合目录。
+
+## 4. 拆分策略选项
+
+### 方案 A：按目录硬拆，StoryForge 先回到 Web 主线
+
+做法：
+
+- 从当前 StoryForge 仓库中移除整个 `android-app/` 目录。
+- 同步清理 README、docs、脚本中所有 Android/APK 主线描述。
+- 保留 Web、Backend、n8n、browser capture、deploy、docs 作为 StoryForge 正式主干。
+
+优点：
+
+- 边界最清楚，最符合“此前一直在做 Web 版本”的项目认知。
+- 能最快结束当前“两个项目目录叠加”的混乱状态。
+- 后续所有开发决策都会更简单。
+
+缺点：
+
+- 当前 `android-app/storyforge/*` 里写过的一些 StoryForge 业务代码会一起被移出，需要单独存档。
+
+适用判断：
+
+- 如果当前项目目标就是 Web 优先、暂不做 APK，这是最推荐方案。
+
+### 方案 B：保留 StoryForge Android 子集，拆掉 AI Glasses 硬件链
+
+做法：
+
+- 在 `android-app/` 中只保留 `storyforge/*`、`MainActivity.kt`、必要的网络与 OTA 文件；
+- 删除 `ble/`、`software/`、旧 `ui/MainViewModel.kt`、AAR、旧权限与旧命名；
+- 后续再把包名重构到 `com.storyforge.*`。
+
+优点：
+
+- 保留了已写过的 StoryForge 移动端业务界面。
+
+缺点：
+
+- 仍要处理大量命名空间和依赖残留。
+- 会继续占用当前 StoryForge 项目的精力。
+- 和“你之前并没有打算做 APK”的事实不完全一致。
+
+适用判断：
+
+- 只有在你确认近期确实要保留 StoryForge Android 端时才值得做。
+
+### 方案 C：直接回滚到较早基线
+
+候选点：
+
+- `acb1103`：最早基线，但已经带着 Android 叠加目录。
+- `1c539ab`：仍未明显进入 Android 壳推进，但已有少量 Android 接口同步。
+
+优点：
+
+- 操作简单。
+
+缺点：
+
+- 无法真正解决“根提交就已经叠加”的结构问题。
+- 会回退掉后续大量有价值的 Web / backend / deploy 进展。
+
+适用判断：
+
+- 只适合做参考，不适合作为主方案。
+
+## 5. 推荐方案
+
+推荐采用 `方案 A：按目录硬拆，StoryForge 先回到 Web 主线`。
+
+原因：
+
+- 它最符合当前产品事实：你确认之前的实际推进重点一直是 Web，而不是 APK。
+- 它最符合现有目录证据：`android-app/` 是混合最严重的区域，且根提交就已叠加。
+- 它最符合后续治理成本：先把 StoryForge 主仓库边界收干净，后面要不要重建移动端，再单独决定。
+
+## 6. 实施步骤
+
+### 第 0 阶段：安全快照
+
+- 基于当前 Gitea 状态打一个拆分前快照分支。
+- 导出 `android-app/` 的完整目录快照，作为独立归档或后续 AI Glasses 仓库恢复源。
+- 记录关键参考提交：
+  - `acb1103`
+  - `1c539ab`
+  - `ac6a8a8`
+  - `7070c3a`
+  - `fe07a5f`
+
+### 第 1 阶段：StoryForge 主仓库边界清理
+
+- 从 StoryForge 仓库中移除整个 `android-app/`。
+- 清理以下入口中的 Android/APK 主线描述：
+  - `README.md`
+  - `docs/AUDIT_2026-03-18.md`
+  - `docs/MVP_STATUS_2026-03-18.md`
+  - `docs/LAN_E2E_GUIDE_2026-03-18.md`
+  - 其他出现 `compileDebugKotlin`、`assembleDebug`、`APK`、`com.aiglasses` 的说明文档
+- 调整基线检查脚本，不再把 Android 编译当成 StoryForge 主仓库必检项。
+
+### 第 2 阶段：AI Glasses 资产外置
+
+- 将 `android-app/` 单独落到 AI Glasses 仓库或归档仓库。
+- 在那个仓库中保留 `com.aiglasses.*`、BLE、Baidu、AAR、OTA 等原始工程语义。
+
+### 第 3 阶段：StoryForge 后续演进
+
+- 当前仓库继续只推进：
+  - `collector-service/`
+  - `web/storyforge-web-v4/`
+  - `scripts/douyin-browser-capture/`
+  - `n8n/`
+  - `deploy/`
+  - `docs/`
+- 若未来确实需要 StoryForge Mobile，再开一个全新、干净的移动端工程，不复用当前混合 Android 目录。
+
+## 7. 风险与控制
+
+### 风险 1：误删仍有参考价值的 StoryForge Android 代码
+
+控制：
+
+- 在删除前先对 `android-app/` 做完整快照导出。
+- 如果担心未来要参考 `storyforge/*` 子目录，可以单独保留一份只读归档。
+
+### 风险 2：文档和状态记录出现历史断层
+
+控制：
+
+- 不改历史提交。
+- 仅在当前分支上明确标记“自本次拆分起，StoryForge 主仓库不再承载 Android 主线”。
+
+### 风险 3：脚本和检查项仍假设存在 Android
+
+控制：
+
+- 统一核对：
+  - `README.md`
+  - `scripts/check_repo_baseline.sh`
+  - 任何引用 `./gradlew` 的脚本或文档
+
+## 8. 最终建议
+
+不要先回滚历史，也不要先做大规模重命名。
+
+更稳妥的动作顺序应当是：
+
+1. 先承认当前问题是“目录叠加”而不是“功能开发方向变化”。
+2. 先把 `android-app/` 整体从 StoryForge 主仓库边界中拆出去。
+3. 把 StoryForge 主仓库重新收敛成 Web / Backend / Orchestration 主线。
+4. 最后再决定是否需要单独保留一个 StoryForge Mobile 项目。