工作分支:test-202609v2,沿用现有分支,不创建新分支。
创建日期:2026-10-09
进度:已验证(本地定向测试、构建及静态审查);按用户要求在三个仓库原分支提交和推送,结果以 Git 记录为准。SQL 未执行,未部署联调。见 quickstart.md。
输入:夜市主创建摊位及摊主账号;摊主登录后自行提交认证资料,由平台审核。认证归属摊位,独立于登录账号;使用认证主表和申请记录表。所有摊位使用完全相同的资料项目,不区分个人经营或公司经营。
storeId;一个摊位可由多个账号共同管理,认证资料只有一套。stall_qualification 和 stall_qualification_application 两张表,保留审核历史及当前有效版本。| 项目 | 来源/归属 | 建议提交要求 |
|---|---|---|
| 所属夜市、摊位名称、摊位地址 | 读取 pos_store,提交时由服务端固化快照 |
系统关联;摊主不能改写夜市或摊位归属 |
负责人姓名 responsibleName |
申请资料 | 必填 |
联系手机号 contactPhone |
申请资料,与账号登录手机号分别管理 | 必填 |
身份证/护照号码 identityNumber |
申请资料 | 必填 |
身份证/护照照片 identityImageUrls |
私有附件引用数组 | 必填,证件照片应完整清晰 |
摊位现场照片 stallImageUrls |
私有附件引用数组 | 必填 |
食品业者登录字号 foodRegistrationNumber |
申请资料 | 统一作为平台入驻必填项 |
食品业者登录证明 foodRegistrationImageUrls |
私有附件引用数组 | 统一作为平台入驻必填项 |
这份表格只定义平台入驻审核所收集的四组资料:负责人姓名/电话、身份证明、摊位信息/照片、食品业者登录字号/证明。不收集商业/税籍登记、保险等补充证明,不代表免除经营者依法应履行的义务;食品登录必填属于平台准入标准,不宣称台湾所有摊贩依法都必须具备。首期不新增董监事截图、UBO 声明等公司专属项目。银行卡、收款账户及支付凭证继续由现有支付配置维护,不在认证模块重复建立收款配置。
夜市主创建摊位及关联账号,摊主可登录并填写认证草稿。提交时校验统一必填资料、账号启用状态及摊位归属。提交后的资料成为确定版本,不能被普通资料修改接口覆盖。
验收:缺失必填材料拒绝提交;保存草稿允许不完整;其他摊位账号提交请求必须拒绝;同一摊位多个账号并发保存时不得静默覆盖;重复提交不得产生多条待审核申请。
有审核权限的平台管理员查看所属夜市、摊位、申请材料及提交人,执行通过或驳回;驳回原因必填。审核同一版本只允许成功一次。驳回后以新版本重新填写,不修改既有审核记录。
验收:无审核权限拒绝访问材料或执行审核;通过后主表指向该申请;驳回后保留材料及原因;重复或并发审核不得产生冲突结果。
摊主查看自己摊位的草稿、申请状态、驳回原因和历史;夜市主查看旗下摊位认证进度;负责人证件及附件不在公开摊位接口和夜市进度列表中返回。已通过的认证在重新提交期间保持原有效版本,新申请通过才切换。
验收:查看其他摊位申请拒绝;账号停用后无法继续操作;新申请驳回不覆盖此前有效资料;账号更换不删除摊位认证。
storeId 和账号/摊位有效状态;平台按权限操作。InfoUser.auditStatus 不能作为摊位资质审核通过的依据,普通商家及骑手原审核功能不受此模块替换。updatesql/sql.md,不直接执行数据库迁移。ImagePreview,支持缩略图、放大及同组切换。私有上传/鉴权读取不改成公开地址;合法 JPEG/PNG 的 Content-Type 附加参数不应导致图片被丢弃,JSON/HTML 错误响应仍不得渲染为证件。存量摊位与新摊位一样补材料审核,通过前不得营业或创建新订单。部署必须先执行本模块 DDL,再发布门禁代码;无认证记录也视为未通过,不根据旧账号审核状态自动通过。既有订单的出餐、配送、支付后续处理不受此门禁阻断。