sileya-ai
/
vr-shopxo-source
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
vr-shopxo-source/plan.md

11 KiB
Raw Blame History

<<<<<<< HEAD

ShopXO 评测环境清理计划 — BackendArchitect

背景

ShopXO 评测 worktree 在调试后遗留大量修改和临时文件。需在三轮调试完成前将 worktree 恢复干净状态，再重启调试会话。

评估结论（BackendArchitect 角色）

1. git checkout HEAD -- 是否能完全恢复 ShopXO 原始状态？

结论：基本可以，但存在边界情况风险。

能完全恢复的情况：

  • app/admin/controller/Common.php、Plugins.php、common.php、service/AdminPowerService.php、service/PluginsService.php、public/core.php → 这些文件在 ShopXO 仓库内有历史记录，git checkout HEAD -- 可完全恢复。
  • config/shopxo.php → 同样有历史记录，可完全恢复。

潜在边界情况：

  1. 数据库插件状态与代码不同步：vr_ticket 插件已在 DB 中启用（is_enable=1），但代码在 app/plugins/vr_ticket/（untracked）。如果 PluginsService.php 的 checkout 版本包含旧插件扫描逻辑，可能导致"插件已启用但代码缺失"的状态，ShopXO 报错或行为异常。
  2. .env 或数据库配置：如果调试过程中 .env 或 DB 配置被修改（未在 git 追踪范围内），这些不会通过 checkout 恢复，但 task 描述中未提及。
  3. untracked 文件夹 app/admin/view/default/plugins_admin 和 pluginsadmin：这些是 debug 调试过程中生成的视图文件，Plan A 的 rm -f 无法删除目录，需手动 rm -rf。
  4. untracked .worktrees/ 目录：这个是 git worktree 的元数据目录，不应删除。

建议：Plan A 需补充一条：

rm -rf app/admin/view/default/plugins_admin app/admin/view/default/pluginsadmin/pluginsadmin

2. vr_ticket 插件目录（untracked）如何安全保留？

方案：使用 git stash --include-untracked 暂存，或直接在 worktree 外备份。

推荐操作：

# 方案A-1: 复制到 worktree 外备份
cp -r app/plugins/vr_ticket /tmp/vr_ticket_plugin_backup/

# 方案A-2: git stash（需先 checkout 恢复文件，再 stash）
git checkout HEAD -- <modified files>
git stash --include-untracked  # 会 stash 所有 untracked，包括 vr_ticket
git stash pop --index          # 恢复时需注意

风险：方案 A-2 的 git stash 会把所有 untracked 打包，如果后续调试产生更多临时文件，会混入 stash，不够干净。

推荐：方案 A-1 直接备份到 /tmp/vr_ticket_plugin_backup/，清晰可控。

3. Goods.php 那1行修改如何正确重新应用？

当前状态：Goods.php 已修改并在 master 上 commit (4747d92)。但 Plan A 的 git checkout 会将 Common.php、Plugins.php 等文件恢复到 HEAD，如果这些文件在 commit 4747d92 之后与 Goods.php 有依赖关系，checkout 会同步恢复。

推荐方法：

# 1. 先备份 Goods.php 的修改内容
git show master:app/index/controller/Goods.php > /tmp/Goods.php.stock
# 或直接：
cp app/index/controller/Goods.php /tmp/Goods.php.modified

# 2. Plan A checkout 后重新应用
git checkout HEAD -- app/index/controller/Goods.php  # 先 checkout
# 然后用 /tmp/Goods.php.modified 覆盖，或重新找到那1行修改

关键点：Goods.php 的修改在 4747d92 中已 commit，所以 master 分支 checkout 后该文件会保持修改状态（因为 git checkout HEAD -- 默认不包含已 commit 的文件）。Plan A 的 checkout 列表中没有包含 Goods.php，所以 Goods.php 的修改会保留。

但是：如果 app/service/PluginsService.php 或 app/service/AdminPowerService.php 的 checkout 版本与 Goods.php 存在接口依赖，需要重新验证接口兼容性。

推荐方案

Plan A（修正版），分阶段执行：

阶段 0：备份（先行）

cp -r app/plugins/vr_ticket /tmp/vr_ticket_plugin_backup/
cp app/index/controller/Goods.php /tmp/Goods.php.modified

阶段 1：Git 清理

# 恢复被改文件（不包含 Goods.php，因为 Goods.php 已 commit）
git checkout HEAD -- app/admin/controller/Common.php \
  app/admin/controller/Plugins.php \
  app/common.php \
  app/service/AdminPowerService.php \
  app/service/PluginsService.php \
  config/shopxo.php \
  public/core.php

# 删除调试文件和目录
rm -f adminwatekc.php debug_power.php test_admin.php public/adminwatekc.php public/test_admin.php
rm -rf app/admin/view/default/plugins_admin app/admin/view/default/pluginsadmin

# 删除 .worktrees/ 元数据目录（如果是 worktree 调试遗留）
rm -rf .worktrees/

阶段 2：验证

git status --short  # 应该只有 Goods.php 的修改（M app/index/controller/Goods.php）

阶段 3：Docker 重启

docker stop shopxo-web shopxo-php
docker start shopxo-web shopxo-php

阶段 4：vr_ticket 插件恢复（如果需要）

# 如果 vr_ticket 插件需要重新加载
cp -r /tmp/vr_ticket_plugin_backup/ app/plugins/vr_ticket/
# 在 ShopXO 后台重新扫描/启用插件

风险项

风险 等级 缓解
vr_ticket 插件启用但代码缺失 高 阶段 0 备份 + 阶段 4 恢复
plugins_admin 视图目录残留 低 阶段 1 手动删除
.worktrees/ 目录污染 低 阶段 1 删除
git checkout 后接口不兼容 中 调试后验证接口调用

任务清单

  • [Claimed: BackendArchitect] 评估 git checkout HEAD -- 的边界情况
  • [Pending] 确认 vr_ticket 插件备份方案
  • [Pending] 确认 Goods.php 重新应用方案
  • [Pending] 执行修正版 Plan A
  • [Pending] 验证清理结果
  • [Pending] 确认 Docker 重启后 vr_ticket 插件状态

依赖关系

  • vr_ticket 插件备份 → Git 清理（必须先备份）
  • Git 清理 → Docker 重启（顺序执行）
  • Docker 重启 → vr_ticket 插件恢复（可选）

备注

  • ShopXO 主分支为 master（非 main）
  • 所有 Agent worktree 均基于 master
  • 当前 master 分支领先 1 个 commit（Goods.php 修改） =======

Council Plan — SecurityEngineer Round 1

角色职责

SecurityEngineer — 负责安全风险评估，尤其关注 debug 代码注入、日志文件写入权限、config 泄露等风险点。

当前状态

Git 状态（已确认）

  • Worktree 分支：council/SecurityEngineer，HEAD = 4747d92
  • Git status 已确认干净：所有 modified 文件（Common.php, Plugins.php, common.php, AdminPowerService.php, PluginsService.php, shopxo.php, core.php）均已通过 git checkout HEAD -- 恢复至 HEAD 状态
  • 仅 .claude/ 目录为 untracked（框架自身目录）
  • admin.php / public/admin.php 已恢复
  • adminwatekc.php, debug_power.php, test_admin.php, public/adminwatekc.php, public/test_admin.php 已不存在（已清理）
  • app/plugins/vr_ticket/ 不存在于 worktree 中（untracked，未被追踪）

当前文件安全状态

文件 风险点 当前状态
app/common.php is_develop: true / debug 日志 ✅ 已恢复，is_develop: false
app/admin/controller/Plugins.php 权限检查逻辑被修改 ✅ 已恢复
config/shopxo.php is_develop: false ✅ 已恢复
public/core.php 未知修改 ✅ 已恢复
app/service/AdminPowerService.php 未知修改 ✅ 已恢复
app/service/PluginsService.php 未知修改 ✅ 已恢复
adminwatekc.php 等调试脚本 潜在后台入口暴露 ✅ 已删除
app/plugins/vr_ticket/ untracked 插件目录 ⚠️ 未存在于 worktree（需从 Docker volume 重新获取）

SecurityEngineer 评估

Plan A — Git 清理（推荐）

git checkout HEAD -- [files]

优势：

  • 原子性恢复，无残留风险
  • is_develop: false 恢复生产配置
  • 权限检查逻辑恢复原始状态
  • 调试文件（adminwatekc.php 等）已确认不存在

安全确认（基于当前 git status）：

  1. ✅ is_develop: false — 不泄露 stack trace / 配置信息
  2. ✅ 无 file_put_contents('/tmp/...') debug 日志残留
  3. ✅ 权限检查逻辑已恢复原始代码
  4. ✅ 调试脚本已清理
  5. ✅ admin.php / public/admin.php 已恢复原始入口

潜在残留风险：

  • app/plugins/vr_ticket/ 插件目录不在 worktree 中（untracked 且不存在），需要从 Docker 重新获取
  • /tmp/ 目录可能残留旧的 debug 日志文件（isPower_debug.log, plugins_debug.log, aipower_debug.log），但不暴露于 Web 路径

结论：Plan A 已基本完成，当前状态安全。

Plan B — 重新 clone

git clone → 重新应用 → docker start

安全劣势：

  • 重新 clone 会丢失当前已确认的安全状态
  • 重新应用 Goods.php 那1行修改时可能引入新的人为错误
  • 多一步操作 = 多一个出错机会
  • vr_ticket 插件目录仍需从 Docker volume 获取

结论：Plan B 在安全层面无额外收益，反而增加操作风险。

vr_ticket 插件风险评估

  • 该插件已在 MySQL DB 中启用（is_enable=1），但插件代码不在 worktree
  • 插件代码如需重新部署，需要从 Docker volume 提取
  • 风险：如直接删除 Docker volume 中的插件目录但 DB 仍启用，可能导致 ShopXO 运行错误

待完成任务

  • 确认 debug 代码已清理（✅ 已确认 git status 干净）
  • 高优先级：从 Docker volume 提取 vr_ticket 插件代码并纳入 version control 或明确记录其来源
  • 建议：清理 /tmp/ 下的 debug 日志（isPower_debug.log, plugins_debug.log, aipower_debug.log）
  • 建议：Docker 重启后验证 ShopXO 正常运行（vr_ticket 插件 DB 启用但代码缺失状态）

依赖关系

任务 依赖
vr_ticket 插件代码提取 需要 DevOps 从 Docker volume 获取
Docker 重启验证 DevOps 执行
Goods.php 修改确认 BackendArchitect 确认

阶段

  • Phase 1: Draft — 完成 ✅（本 round 完成风险评估）
  • Phase 2: Review — 待其他 member review
  • Phase 3: Finalize — 待执行 vr_ticket 提取 + Docker 重启验证

建议行动

  1. 立即确认当前状态安全 — Plan A 已完成，无需额外清理
  2. 提取 vr_ticket 插件代码 — 从 Docker volume 提取到 worktree 或其他安全位置
  3. 清理残留日志 — rm -f /tmp/isPower_debug.log /tmp/plugins_debug.log /tmp/aipower_debug.log
  4. Docker 重启 — docker stop shopxo-web shopxo-php && docker start shopxo-web shopxo-php
  5. 验证 ShopXO 运行 — 检查 vr_ticket 插件在无代码状态下的行为

Claim 状态

  • [Done: SecurityEngineer] — 安全风险评估完成
  • [Claimed: DevOps] — Docker 重启操作（待分配）
  • [Claimed: DevOps] — vr_ticket 插件提取（待分配）

council/SecurityEngineer