四仓项目蓝图

本篇用于采用 xt-platform-java、xt-platform-admin、xt-platform-web、xt-platform-uniApp 的新项目。四个仓库分别提供服务端、管理后台、浏览器前台和多端前台。它们是既定的工程起点；业务模块、接口、环境和发布链路仍要按当前产品补齐。各仓当前状态见脚手架当前能力与待联调事项。

一条业务链路贯穿需要的仓库

从首个用户任务出发，先明确它发生在哪个端、是否需要管理操作、谁有权读写、服务端结果和数据存在哪里。后端业务模块拥有规则、授权、事务和持久化；前端提交用户操作并呈现真实结果。管理端、Web 和 uni-app 可以是不同的界面，但不能各自维护一份互相矛盾的业务事实。

开发顺序可按“数据结构与服务端规则 → API 契约 → 涉及的前端页面 → 联调验证”推进。只开发本次需求涉及的端，保留其余仓库的既定脚手架，不做无需求的占位页面。新增 API 时核对路径前缀、身份与租户、字段类型、分页、错误结果及上传方式；尤其不能把管理端已有的 /admin-api 直接当作 C 端契约。

四个交付物的运行边界

交付物	部署前应确认
Java JAR	数据库、Redis、环境配置、迁移或初始化步骤、健康检查和日志。初始化 SQL 有删除语句，不在已有业务库执行。
管理端静态 SPA	API 地址、登录与权限联调、静态服务器的路由回退，以及构建时公开配置。
Nuxt SSR 服务	Node 运行环境、服务端和浏览器两侧到 API 的网络路径、域名和搜索引擎收录配置。
uni-app 各平台产物	实际目标平台的 API 地址、登录态、平台能力、应用标识及真机或对应工具验证。

测试和生产环境的数据库、存储、认证上下文及公开入口分别配置；前端公开变量不能承载密钥。记录四仓具体修订、构建命令、产物位置和部署顺序，避免交接时只提供源码而没有运行条件。

验证与交接

各仓先按自己的 README.md 和 AGENTS.md 执行必要检查。跨仓验证至少走通本次功能的成功、失败和无权限路径，确认实际持久化结果。涉及数据结构时提供可审阅的变更及执行步骤；涉及资源或性能时按用户任务测量请求数、等待时间和资源体积，并复测修正效果。

交接说明哪些端已联调、使用了什么环境、哪些平台和生产条件尚未验证。只有页面可打开或单仓构建通过时，不声称四仓系统已经可部署。项目规则和具体命令以四仓当前本地约定为准，本站技术选型与落地仅说明共同技术基线。