hyb-oa/.trellis/tasks/07-26-small-team-internal-oa-review/prd.md

5–10 人内部 OA 适配性复审

Goal

以“仅供本公司 5–10 人长期内部管理、不会产品化或对外销售”为永久前提，重新评估 hyb-oa 当前功能、架构、治理和运维投入，给出能降低维护成本、认知负担和操作风险的保留、简化、冻结与精简建议。

Background

• 公司是 5–10 人的初创型科技公司，人员少、一人多岗、审批链短。
• 系统不会作为 SaaS、商业软件或通用 OA 产品发布，不需要多租户、客户配置能力、市场竞争型功能广度或大规模扩展设计。
• 公司希望充分复用企业微信已有的入口、身份、组织、移动交互、消息、考勤和审批能力，以减少 OA 的自研页面、流程和长期维护工作量。
• 企业微信 HR/考勤范围明确包含调休；调休作为企微“请假”的假别，不新建一套 OA 调休申请流程。
• 当前代码已经完成五人团队本地候选收口，质量上限是 LOCAL_CANDIDATE_PASS，尚不能等同于已部署或正式内用。
• 既有事实源已经采用“小团队 V1”边界，但历史建设过程仍包含大量面向完整 OA、成熟度对标和复杂外部集成的遗留资产，需要重新判断长期价值。

Scope

• 产品与流程：真实高频事项、角色重叠、审批层级、页面入口、模块边界和手工流程替代空间。
• 工程与架构：单体边界、数据库、异步任务、功能开关、集成、依赖、测试和可观测性是否过度。
• 安全与数据：内部系统仍必须保留的权限、敏感数据、付款复核、审计、备份恢复和离职交接底线。
• 运维与交付：部署形态、升级节奏、故障恢复、管理员负担、Trellis/docs/历史证据治理。
• 仓库与代码：可冻结模块、低价值兼容层、重复文档、生成物和未来触达即删的候选；不在本任务直接物理删除。

Requirements

• 以仓库、当前事实源、归档任务和已验证门禁为证据，不重新制造一套平行产品文档。
• 明确区分“内部工具也不能省”的安全/恢复底线与“只有产品化才需要”的复杂度。
• 每项建议说明当前问题、对 5–10 人团队的收益、代价/风险、推荐动作和验证方式。
• 建议至少分为：继续保留、立即简化、冻结不扩展、触达即删、暂不处理。
• 给出 P0/P1/P2 优先级和可独立验收的行动批次，避免形成巨型重构。
• 将调研建议转换为可独立创建、实施、验证和回滚的后续 Trellis 工作包，明确依赖顺序、验收门禁和需要另行授权的真实环境动作。
• 采用“企微优先、OA 补位”的分层裁决：成熟通用能力由企微主办；字段简单、低风险的一次性业务可由企微发起/审批且 OA 仅留最小索引；票据、财务台账、付款、合同正文、高敏附件和跨业务关联仍由 OA 主办。
• 坚持“一个业务流程只有一个主操作系统”：报销从申请、票据、审批、财务处理到付款查询均由 OA 主办，企微只提供免登入口、待办通知和精确 deeplink，避免员工跨平台补录或查询。
• 不把“充分利用企微”误解为全量数据镜像、双向写回或把敏感业务正文复制进企微；所有迁移候选必须尊重企微 API、审批规则可见性、附件和审计限制。
• 结论必须遵守当前部署状态，不把本地候选误写为已正式内用。

Acceptance Criteria

• 给出面向 5–10 人内部公司的目标架构与产品原则。
• 给出核心模块逐项“保留/合并/冻结/删除候选”结论及证据。
• 给出安全、权限、付款、审计、备份恢复中不可削减的底线。
• 给出可取消的产品化、规模化和通用平台建设项。
• 给出按收益/成本/风险排序的 30 天、后续按需行动建议。
• 明确哪些现有开放项应继续、降级或关闭。
• 给出企微主办、企微审批 + OA 最小留存、OA 主办的能力边界与迁移优先级。
• 明确调休的企微归属、最小实现边界和后续验证方式。
• 给出后续改进优化任务地图，不把跨域工作合并成一次大改。
• 任务只做只读调研与建议，不修改业务代码、不部署、不写真实数据。

Acceptance Evidence

• 完整结论与仓库相对证据见 research/internal-only-review.md。
• 调研覆盖产品入口、前后端规模、Prisma 模型、feature flags、jobs、部署组件、备份恢复、客户端离线数据、导出安全、测试与文档治理。
• 企微裁决复核 docs/企微API能力目录.md、docs/企微优先开发路线图.md 和 .trellis/spec/hyb-oa/wecom-boundary.md，区分已验证能力、后台/真机确认项与迁移候选。
• 未连接生产环境、未读取真实访问日志；所有物理删除建议均以未来 30 天脱敏使用证据为前置。

Out of Scope

• 本轮不实现建议，不修改业务 API/schema/UI，不升级依赖。
• 不部署、不改生产配置、不执行公网/真机检查、不写真实数据库或企业微信。
• 不建设多租户、插件市场、低代码平台、通用 BPM、微服务、数据中台或商业化能力。
• 不因“精简”直接删除历史审计材料、现有模块或真实业务数据。

Test Plan

• 复核当前 task、事实源矩阵、产品设计规则、核心业务规约和 07-16/07-18/07-26 历史审查证据。
• 盘点前后端路由、主要导航、Prisma 模型、功能开关、依赖、测试与 QA 脚本规模。
• 将建议逐项映射到仓库证据，并检查是否与现有小团队事实源冲突。
• 运行 task validate、Trellis governance、流程合同、文档 registry、敏感扫描与 git diff --check；本轮无业务代码改动，不重复运行全量 985 测试。

Key Decision

长期采用“单公司、5–10 人、内部自用、非产品化”的裁决基线，并以企业微信作为默认入口与通用流程平台。建议优先减少 OA 长期维护面，而不是追求功能完整度、配置自由度、外部可扩展性或行业对标得分。