目录

一、阶段目标与总体进展

D6 以“首页聚合与管理”为阶段目标，承接前五天的发布、浏览、匹配、认领和消息能力，把原先分散在各页面的关键信息组织到首页，同时补齐校园认证审核和收纳点维护的必要管理入口。首页需要向不同身份返回恰当的信息：匿名用户可以浏览公共统计与招领预览，登录用户还可以查看本人未读消息、新线索和待处理认领。

当前共同基线为 c76092c，已推送远程主干。后端提供首页聚合、认证审核、收纳点与代管、物品举报及处理接口；小程序接入首页真实数据，并提供认证审核和收纳点管理页面。

本阶段把首页的两类内容分开处理：pendingClaims 是别人对本人发布的物品发起的待处理认领，公开招领预览则来自物品列表。两者的对象范围不同，不能把前者直接写成全校“待认领物品”。首页搜索携带关键词进入列表，按当前列表类型检索，可在列表切换寻物与招领；现阶段校区显示依赖已有校区数据，尚无多校区切换界面。

二、站会安排

讨论与核对事项

1. 首页先分清数据归属。 公共物品预览和本人收到的申请分别取数，未登录时不展示他人私有申请、未读与线索。
2. 认证结果保持一致。 审核通过要同步更新申请与用户认证状态，写入审计及站内通知；重复审核不能再次通知。
3. 管理员权限由服务端验证。 页面依据资料显示入口，审核与点位写操作仍由后端检查权限，不能把隐藏按钮当作授权。
4. 点位信息按实际字段展示。 名称、地址、校区及联系方式可以维护；营业时间当前没有持久化字段，不能展示为已保存。
5. 区分接口、页面和设备验收。 实库接口检查、页面源码回归与真实微信设备操作分别记录，未执行的测试不记为通过。
6. 提前核对 D7 交付。 测试随笔、共享评审表、答辩 PPT、演示脚本和实际彩排需要具体材料，不因计划排期到达而视为完成。

三、六人分工、进展与困难

下表依据六人计划和当前仓库成果整理工作关联。D6 的后端与前端分别形成多项合并提交；提交账号并非六人的逐人独立签入记录，代表性提交用于定位协作成果，不能据此推断个人实际提交次数。

按当前可核对成果，D6 暂记 17 点：T26 记 7 点，T27 记 3 点，T29 记 7 点。此处沿用前几天对任务组记账的方式，T27 的设备验收和 T29 的总结初稿仍是未闭合子项；T28 与 T30 因缺少完成材料暂不记账。团队核对实际进展后可调整，不能将暂记点数等同于全部验收完成。

四、AI 技术员分工与协作

AI 技术员围绕最新接口契约、源码、测试输出和验收记录辅助梳理。各角色的输出需要由负责成员结合实际运行结果检查，避免把接口已写入、页面已接入和真实设备已验收混为一谈。

公共预览与本人申请分开查询

首页聚合服务根据请求身份返回不同范围的数据。server/src/main/java/com/shiguang/home/service/HomeService.java 在匿名时只返回公共统计，登录后再补本人相关内容：

if (viewer == null) {
    return new HomeView(campus, stats, List.of(), 0L, List.of());
}
return new HomeView(
        campus,
        stats,
        pendingClaims(viewer),
        messages.unreadCount(viewer),
        banners(viewer));

页面另用公开物品列表读取招领预览。这样匿名用户看到的是公开物品，登录用户的“待处理”则只关联本人发布物品的申请。统计中的 recoveredCount 是累计已归还／已完成数量，页面不把它写成“今天归还”。

先按物品去重，再截取待处理预览

server/src/main/java/com/shiguang/home/mapper/HomeMapper.java 对本人收到的待处理认领按物品分组，再按最早申请时间排序和限制数量：

SELECT c.item_id
FROM t_claim c
WHERE c.progress = 2
  AND c.item_id IN (SELECT i.id FROM t_item i
                     WHERE i.user_id = #{ownerId} AND i.deleted = 0)
GROUP BY c.item_id
ORDER BY MIN(c.create_time) ASC, c.item_id ASC
LIMIT #{limit}

如果先取三条认领再去重，同一物品的多条申请会挤掉其他物品。当前 SQL 先确定不同物品，再截取首页最多三件；交付记录中的早期实库报告曾指出这一问题，后续提交 b589920 已调整查询。该修复与早期报告的实测版本应分开理解。

审核事务和重复操作

server/src/main/java/com/shiguang/admin/service/AdminVerificationService.java 的审核通过方法在事务内先做条件更新，再更新用户认证状态：

@Transactional
public void approve(long id, ApproveRequest request, long auditorId) {
    VerificationRow row = requireRow(id);
    if (mapper.approve(id, auditorId) == 0) {
        throw ApiException.conflict("该认证申请已审核，请勿重复操作");
    }
    if (mapper.markVerified(row.userId) == 0) {
        throw ApiException.notFound("申请用户不存在或已注销");
    }

同一方法后续写审计记录和申请人的站内通知。条件更新只允许待审记录进入通过状态，重复处理返回冲突；若用户状态无法更新，事务回滚，避免申请显示通过而用户仍未认证。驳回则要求原因代码和文字，并记录驳回结果。

管理入口与服务端权限

miniprogram/pages/admin/admin.js 打开工作台时重新获取当前用户资料，并根据权限选择可用功能：

const permissions = profile.permissions || [];
const canReview = permissions.includes('verification:review');
const canPoints = permissions.includes('point:manage');
const tab = this.data.tab === 'points' && canPoints
  ? 'points' : (canReview ? 'review' : 'points');

个人中心仅对具有相应权限的用户显示入口，工作台也在无权限时提示。入口控制用于改善交互，最终授权仍在后端；未登录访问管理接口返回 401，普通用户返回 403。账号切换或页面离开后，旧请求序号失效，不再将上一个用户的审核列表回填到当前页面。

页面真实数据与错误恢复

miniprogram/pages/index/index.js 发起首页聚合前记录当前身份，并在响应返回时检查身份与请求顺序：

const sequence = this._homeSeq = (this._homeSeq || 0) + 1;
const account = currentAccount();
return homeApi.overview().then(d => {
  if (sequence !== this._homeSeq || account !== currentAccount()) return;
  const banner = (d.banners || []).find(it => it.type === 'match') || null;

首页聚合和公开预览分别加载。接口失败显示错误及重试，返回空列表时显示空态，不用演示数据填充；搜索时把输入词带到招领墙，并将时间范围设为全部时间。审核列表和点位维护也保留失败信息，保存和审核操作通过状态锁避免重复点击。

协作体会

首页整合表面上是几个数字和卡片，实际涉及公开统计、用户身份、认领记录和消息计数。管理功能则需要同时检查操作权限、状态转换、通知和审计。AI 有助于展开这些依赖，但结果仍应逐项回到接口、页面和数据库核对；不能因为页面上有按钮就认定整个业务链路已被真实设备验收。

五、项目燃尽图

本轮总计 162 点，六名成员各 27 点。根据当前可核对的任务组成果，D6 暂记 17 点，累计记账 139 点，剩余 23 点；计划线同期剩余 23 点。T28 测试随笔与共享评审表、T30 PPT／使用说明／彩排尚未记账。

本日点数为根据现有证据整理的暂记值，后续由团队核对。T27 的设备操作、T29 的总结初稿仍需完成；T28、T30 未记账。点数曲线与计划重合不意味着所有验收项目、材料和权限边界已经闭合。

六、代表性提交与分工关联

功能整合进展

1. 首页使用真实数据。 公共预览与本人待处理申请分别取数，未读、线索横幅及统计来自聚合接口。
2. 认证审核有完整服务端结果。 管理员通过／驳回后，申请状态、用户状态、审计与通知按实现规则更新。
3. 收纳点可以维护。 管理页面提供新建、编辑和关闭；代管登记与核销已有后端接口，页面入口仍待补充。
4. 举报接口已有基础。 物品举报及管理员处理有服务端实现与实库记录，用户举报和管理页面尚未接入。
5. 前端按身份和请求顺序回读。 首页和管理工作台处理空态、错误和重试，账号切换后旧数据不应覆盖当前结果。

七、运行与测试

运行检查结果

本轮覆盖后端全量测试、跨阶段页面源码回归，以及已有的首页、审核、收纳点和举报实库接口验收。后端默认测试使用 H2 与测试会话；页面脚本使用可控异步响应。实库报告针对前一批 D6 后端提交，在真实 MySQL 8、Redis 和 local 模拟身份下执行，并逐项核对 SQL；该报告并非小程序真实设备端到端验收。

以上结果来自 D6 甲方实库报告及乙方交付记录，本篇整理未重新执行全部测试。甲方早期实库报告记录了 159 项后端测试；后续整合版本的测试集合为 160 项，两者是不同版本快照，不能相加。早期报告中尾斜杠与待处理预览去重问题已有 b589920 修复，仍需按当前版本继续复验。

问题定位与处理

首页不能把私有数据当作公开预览。 聚合返回的待处理认领属于当前发布者；页面另从公开物品列表取得招领预览。匿名访问只返回公共统计与空的用户相关数据，避免向未登录用户展示他人的未读、申请或线索。

一件物品的多条认领可能挤占预览。 早期查询先限制认领行数，再按物品去重，可能让其他物品无法进入三条预览。当前改为按物品分组后再排序和截断；后续需要在最新版本上结合真实页面检查。

审核权限与审核状态要同时检查。 工作台根据当前资料显示功能，后端仍验证管理员权限。审核状态更新受待审条件限制；通过后用户需重新登录以获取更新后的权限，重复操作不会再次生成结果通知。

营业时间不能假装已经保存。 收纳点接口目前接收 openingHours，但现有表没有对应列，响应为 null；管理页面因此只编辑已有持久化字段。认证材料目前仅展示对象标识，安全预览接口尚未接入。

演示认证与真实身份分开。 “提交审核 · 演示”使用 demo-pending 构造本地待审申请，供联调审核路径。它不能证明真实微信登录或真实校园认证服务已经完成验收。

匹配规则已随最新代码调整。 D5 随笔记录的是当时的四维权重与样本结果；后续匹配实现调整了类别门槛和标题关键词处理，不能将 D5 的 80 分当作当前版本的固定分数承诺。答辩时应使用当前配置和实际响应展示。

现有材料仍有缺口。 目前没有 D6 站会照片、微信开发者工具完整编译记录、真机截图或真实微信身份验收证据；测试随笔、共享评审表、答辩 PPT 与实际彩排也尚待补充。D4 独立双向确认与取消、线索阅读回执等遗留项继续保留。

首页与管理回归清单

八、阶段小结与后续安排

D6 将首页从演示内容推进到真实聚合与公开预览，并补齐认证审核、收纳点维护和举报处理的服务端基础。管理工作台接入认证审核与点位维护，本地演示模式可以提交待审申请。本日按现有成果暂记 17 点，累计 139 点，剩余 23 点；尚缺的测试和交付材料继续保留。

本阶段的主要体会是，聚合页面和管理功能都依赖明确的数据范围。公开预览、本人待处理申请、审核结果与管理员权限分别有各自的来源和边界。把这些规则与实际测试范围写清楚，可以减少页面展示和后端结果不一致带来的误判。

1. 刘伟鑫核对最终版本、部署和冷启动步骤，补齐冲刺总结与集合随笔的正式链接。
2. 刘传浩在微信开发者工具中复测首页、搜索、认证审核和点位页面，补连续操作及布局问题。
3. 许毅君复核管理员权限、审核结果和会话失效，跟踪材料预览、举报管理与其他未闭合边界。
4. 王永臻复验建库、首页统计、归还事务、事件和善意值，维护最终燃尽数据。
5. 李明学执行最终自动化与主流程回归，完成测试随笔及共享评审表，分类记录失败、阻塞和未执行项。
6. 许煜煌补站会与运行素材，整理使用说明、演示脚本和答辩 PPT，完成现场及备用方案彩排。