完成小团队内部OA复审与优化路线（07-26-small-team-internal-oa-review）

.trellis/spec/hyb-oa/project-governance.md

@@ -41,6 +41,41 @@ rollback and future self-maintenance.
 - Capture reusable lessons in `docs/`, `.trellis/spec/` or the current task
   while they are fresh; do not depend on chat history for project rules.
 
+### Design Decision: Internal-Only Small-Team Boundary
+
+**Context**: hyb-oa serves one domestic technology startup with 5–10 people.
+It is a long-term internal management system, not a SaaS, commercial product or
+general-purpose OA platform.
+
+**Options Considered**:
+
+1. Continue toward configurable, scalable product completeness.
+2. Optimize for a single company, overlapping roles and low maintenance.
+
+**Decision**: choose the second option. Do not add multi-tenancy, commercial
+configuration, department rollout infrastructure, generic low-code/BPM,
+microservices, provider breadth or competitive feature parity unless a later
+Trellis task proves a concrete internal need. Prefer fixed workflows, role-aware
+navigation, existing providers, manual SOPs for low-frequency work and small
+independently removable modules.
+
+Security and recovery do not become optional: authentication, least privilege,
+payment maker-checker, sensitive attachments, audit, off-host backup, restore
+drills and leaver access revocation remain required. Existing low-value modules
+are hidden or frozen first; data-bearing code is removed only through a scoped
+task with usage, export, retention and rollback evidence.
+
+**Decision gate**:
+
+```text
+clear owner + recurring internal use + material failure cost + no cheaper
+reliable substitute -> consider a small Trellis task
+otherwise -> defer, hide, freeze or keep as a manual SOP
+```
+
+**Related**: the evidence-backed baseline and initial retirement candidates are
+recorded in task `07-26-small-team-internal-oa-review`.
+
 ## Stop Conditions
 
 - Production config, deployment, database reset, migration drift, real data

.trellis/spec/hyb-oa/wecom-boundary.md

@@ -2,10 +2,26 @@
 
 ## Ownership
 
-Enterprise WeChat owns mature HR/attendance actions: check-in, leave, missed
-punch, outing, overtime and related mobile entry. OA owns reimbursement,
-procurement, contracts, projects, payments, invoices, sensitive attachments and
-operating audit.
+Use an Enterprise-WeChat-first, OA-complements model for this single-company,
+5–10-person internal system:
+
+- Enterprise WeChat owns mature commodity capabilities: workbench entry,
+  OAuth/SSO, directory and basic organization, application messages,
+  HR/attendance actions and low-risk, simple-field, mobile-first approvals.
+- General administration and simple procurement with no downstream financial
+  handling, sensitive attachment or cross-business ledger may use Enterprise
+  WeChat for submission and approval after a dedicated task verifies the real
+  template and approval chain. OA retains only a minimum reference when needed.
+- OA owns the complete reimbursement journey: request, invoice upload/PDF/OCR
+  and duplicate detection, approval, finance review, payment status and receipt.
+  Enterprise WeChat provides SSO/workbench entry, dehydrated notifications and
+  exact deeplinks into the relevant OA page; users must not re-enter or chase the
+  same reimbursement across both systems.
+- OA also owns financial ledgers, payment/AP and maker-checker, contract bodies,
+  sensitive attachments, cross-business relationships and long-term audit.
+
+This boundary is a selection rule, not evidence that any existing procurement
+or administration workflow has already migrated.
 
 ## Rules
 
@@ -17,6 +33,88 @@ operating audit.
   manual backend/real-device gates where specified.
 - Messages to Enterprise WeChat must be dehydrated and link back to OA; do not
   send sensitive attachments or business documents into native WeCom approvals.
+- Prefer a WeCom-native mobile form over duplicating it in OA when the process is
+  simple and low-risk. Do not build full payload mirrors, bidirectional writeback,
+  duplicate native approval UIs or generic approval-rule operations unless a
+  later task proves a concrete business and audit need.
+- For every WeCom approval promoted to formal use, manually verify the backend
+  rule, applicant-visible mobile submission page and actual post-submission
+  approval chain; API template metadata alone is insufficient.
+
+## Scenario: Compensatory Leave Is A WeCom Leave Category
+
+### 1. Scope / Trigger
+
+- Trigger: adding, displaying, validating or operating compensatory leave
+  (`调休`) in the WeCom-owned HR/attendance flow.
+- Purpose: support the required leave category without creating a fifth approval
+  integration, a parallel OA submission journey or an unneeded balance engine.
+
+### 2. Signatures
+
+- WeCom approval target remains `leave`; the existing target set remains
+  `leave`, `missed_punch`, `outing`, `overtime`.
+- WeCom template/form category label: `调休` under the leave template.
+- OA read-only archive fields: normalized leave category, interval, status and
+  minimum approval summary. No new ordinary OA submit/approve API is implied.
+
+### 3. Contracts
+
+- WeCom owns employee submission, approval and normal mobile history. OA must
+  distinguish `调休` from other leave categories in read-only history but must
+  not expose a parallel ordinary submission or approval flow.
+- The initial internal-team scope does not build an OA compensatory-leave
+  balance, automatic overtime-to-leave conversion, carry-over engine or payroll
+  calculation. If WeCom native balance management is enabled, it is the source
+  of truth; otherwise HR uses a controlled manual rule until a later task proves
+  automation is worth maintaining.
+- Template metadata is insufficient acceptance evidence. Formal use requires a
+  backend check, applicant-visible real-device form and actual submitted approval
+  chain with no self-approval.
+
+### 4. Validation & Error Matrix
+
+- WeCom backend lacks `调休` -> remain not ready; do not emulate it with an OA
+  ordinary form.
+- Real-device form does not show `调休` -> `PAUSED_MANUAL_CONFIRMATION`.
+- Applicant can select/change the approver or becomes the approver -> blocker;
+  do not enable real-team use.
+- OA archive cannot distinguish the leave category -> keep the data read-only
+  but do not claim compensatory-leave acceptance.
+- WeCom native balance is absent -> use the approved manual HR rule; do not
+  silently create an OA balance ledger.
+
+### 5. Good/Base/Bad Cases
+
+- Good: a test user selects `调休` in WeCom, a different real approver handles
+  it, and OA read-only history displays `调休`, interval and final status.
+- Base: WeCom manages the request while HR maintains the small-team balance by a
+  controlled manual rule; OA stores no balance.
+- Bad: introduce a `compensatory_leave` approval target and duplicate submit,
+  balance and approval state across OA and WeCom.
+
+### 6. Tests Required
+
+- Unit/fixture coverage proves a WeCom `leave` detail containing `调休` remains
+  target `leave` and preserves the category in the minimum archive/display path.
+- Mocked frontend coverage proves ordinary employees see read-only history and
+  no OA ordinary compensatory-leave submit action.
+- Formal-use evidence must include the backend option, real-device form and
+  actual no-self-approval chain; live writes require a separately approved task.
+
+### 7. Wrong vs Correct
+
+#### Wrong
+
+```text
+调休 -> new compensatory_leave target -> OA balance -> OA approval -> WeCom sync
+```
+
+#### Correct
+
+```text
+WeCom leave(category=调休) -> WeCom approval -> OA minimum read-only history
+```
 
 ## HR / Attendance UI Contracts
 

.trellis/tasks/07-26-small-team-internal-oa-review/check.jsonl

@@ -0,0 +1 @@
+{"_example": "Fill with {\"file\": \"<path>\", \"reason\": \"<why>\"}. Put spec/research files only — no code paths. Run `python3 .trellis/scripts/get_context.py --mode packages` to list available specs. Delete this line once real entries are added."}

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

@@ -0,0 +1,63 @@
+# 5–10 人内部 OA 适配性复审设计
+
+## 复审方法
+
+采用“真实工作是否需要 → 风险是否值得系统化 → 是否已有更便宜主办系统 → 长期维护成本”四层判断：
+
+1. 只有高频、多人协作、容易丢失或需要审计的工作才值得进入 OA。
+2. 低频且可由明确 SOP、共享表格或线下双人确认可靠完成的事项，不优先编码。
+3. 企业微信、银行、代账等已有系统能稳定主办的能力，OA 只保留必要入口、摘要和留痕。
+4. 每个保留的模块必须能说明谁每月使用、失败会造成什么损失、谁负责恢复。
+
+## 企业微信分层模型
+
+每项能力先按以下三层裁决，不再默认由 OA 自研完整闭环：
+
+1. **企微主办**：入口、免登、通讯录、基础组织、应用消息、HR/考勤、公告和字段简单的低风险审批。移动端优先使用企微原生页面，OA 不复制一套表单和处理 UI。
+2. **企微发起/审批，OA 最小留存**：一般行政申请以及无需后续财务处理、敏感附件和跨模块台账的简单采购可作为迁移候选。OA 只在确有业务关联时保存外部审批 ID、申请人、类型、状态、实际审批链和必要审计。
+3. **OA 主办**：报销全流程、发票 PDF/OCR 与去重、合同正文、高敏附件、财务台账、付款/AP、回单、maker-checker、跨模块关联和长期审计。企微只提供免登入口、脱敏消息和指向具体 OA 单据的 deeplink。
+
+优先选择企微的判据是：移动操作为主、字段和状态简单、敏感度低、无需复杂跨模块关联、企微能够可靠留痕。任一项不满足时，保留 OA 主办或采用“企微审批 + OA 最小索引”。
+
+业务旅程完整性优先于技术上的能力复用。报销天然连续经过申请、票据识别/去重、审批、财务复核、付款与回单，拆到企微原生审批和 OA 财务处理会产生重复录入、状态同步、附件搬运和跨平台查询，因此无论金额大小均保持 OA 单一主办；员工仍从企微工作台进入 OA，并在企微接收待办和结果通知。
+
+企微审批规则不能通过 API 完整读取，也无法仅靠 API 证明申请人是否可以自行改选审批人。任何正式模板迁移必须经过后台人工确认、真机提交页确认和提交后的实际审批链校验；本调研只提出行政/简单采购候选，不宣告任何流程已经迁移。
+
+### 调休边界
+
+- 调休属于企微“请假”模板中的假别，与年假、事假、病假同属 `leave`，不扩展第五个企微审批目标。
+- 员工在企微提交和查看调休，审批人在企微处理；OA 普通页面只读展示同步到的假别、时间、状态和必要审批摘要。
+- 首批不在 OA 建设调休余额、加班自动换休、跨年度结转、薪资计算或复杂假期引擎。余额若由企微原生能力管理，以企微为事实源；否则由 HR 按简明制度人工维护。
+- 正式启用前必须验证企微后台确有“调休”选项、真机申请页可见、实际审批链禁止自审，并证明 OA 最小历史能区分“调休”与其他请假类型。
+
+## 评估维度
+
+- **业务价值**：月使用频率、参与人数、金额/合规风险、跨人交接价值。
+- **认知成本**：导航数量、角色切换、配置项、状态数量、重复录入和培训成本。
+- **工程成本**：代码与测试规模、依赖、后台任务、集成、数据迁移和故障面。
+- **运维成本**：部署、备份、恢复、监控、密钥、外部 API 和人工值守要求。
+- **替代成本**：企微原生能力、银行/代账流程、共享文档或简单 SOP 是否更可靠。
+
+## 输出模型
+
+每个主题归入以下一类：
+
+- `KEEP`：内部运营底座，继续维护并保持简单。
+- `SIMPLIFY`：业务需要，但应合并入口、状态、角色或配置。
+- `FREEZE`：现状可读/可用，停止扩展，仅修安全和数据损坏问题。
+- `TOUCH-TO-REMOVE`：不立即大删；未来触达相关代码时有证据地移除。
+- `DEFER`：没有当前收益，保留决策记录但不投入。
+
+## 风险边界
+
+- “内部使用”不降低认证、最小权限、敏感资料隔离、付款 maker-checker、审计、备份恢复和离职权限回收要求。
+- “人数少”允许一人多岗和短审批链，但不能允许同一人完成高风险付款制单与复核、系统运维与敏感业务授权的全部闭环。
+- 精简优先通过隐藏入口、冻结扩展和减少配置完成；涉及历史数据或审计链的物理删除必须另建任务。
+
+## 交付物
+
+- 当前状态简报。
+- 模块级裁剪矩阵。
+- 工程/运维/安全建议。
+- 30 天优先行动与后续按需清单。
+- 明确的“不再建设”清单。

.trellis/tasks/07-26-small-team-internal-oa-review/implement.jsonl

@@ -0,0 +1 @@
+{"_example": "Fill with {\"file\": \"<path>\", \"reason\": \"<why>\"}. Put spec/research files only — no code paths. Run `python3 .trellis/scripts/get_context.py --mode packages` to list available specs. Delete this line once real entries are added."}

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

@@ -0,0 +1,40 @@
+# 5–10 人内部 OA 适配性复审执行清单
+
+## 调研步骤
+
+- [x] 读取当前事实源、项目规约及相关归档 task，提取已确认的小团队边界。
+- [x] 盘点前后端模块、导航、路由、数据模型、功能开关、外部集成和后台任务。
+- [x] 盘点测试、QA、部署、运维、文档与历史证据的维护成本。
+- [x] 识别安全/恢复底线、产品化复杂度和低频功能候选。
+- [x] 形成 `KEEP/SIMPLIFY/FREEZE/TOUCH-TO-REMOVE/DEFER` 模块矩阵。
+- [x] 重排既有 P0/P1/P2 开放项并给出 30 天行动建议。
+- [x] 将完整证据与建议写入 task research，不新建常驻平行文档。
+- [x] 按用户“充分利用企微减少自研”的补充边界，复核已验证企微能力与 API 限制，并将结论修订为“企微主办、OA 补位”。
+- [x] 将调休纳入企微请假假别，并形成分批改进优化任务地图、依赖和验收边界。
+- [x] 运行 task/governance/敏感扫描/diff 门禁。
+- [x] 提交并归档任务。
+
+## 核查重点
+
+- 前端一级导航与管理员入口是否超过小团队实际任务数量。
+- 后端是否存在只为规模化、通用化或未启用集成服务的长期维护面。
+- Prisma 模型和 feature flags 是否承载冻结域、双轨流程或历史兼容逻辑。
+- QA/文档是否因历史阶段证据过多而降低当前状态信噪比。
+- 部署、备份恢复、管理员交接是否比新增功能更值得优先投入。
+- 是否把企微成熟能力与 OA 重复建设混为一谈；简单流程是否可以迁到企微，而财务/敏感数据仍保持 OA 控制。
+- 后续工作是否可按运营底线、企微入口/HR、报销闭环、导航精简、安全缺口和退役候选独立交付，而不是一次大改。
+
+## 验证命令
+
+- `python3 ./.trellis/scripts/task.py validate .trellis/tasks/07-26-small-team-internal-oa-review`
+- `node scripts/qa/check-trellis-governance.mjs`
+- `node scripts/qa/check-sensitive-content.mjs`
+- `node scripts/qa/check-process-contract.mjs --baseline --json`
+- `node scripts/qa/audit-docs.mjs --check-registry`（允许既有 22 项未登记文档 warning，不新增 warning）
+- `git diff --check`
+
+## 停止条件
+
+- 发现需要生产配置、真实数据、企微写入或部署证据时，只记录为后续授权项。
+- 发现建议会删除数据、破坏审计链或改变付款/审批状态机时，不在本任务实施。
+- 若事实源冲突，以当前 task、模块规约和当前可信状态矩阵为准，并明确记录冲突。

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

@@ -0,0 +1,73 @@
+# 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
+
+- [x] 给出面向 5–10 人内部公司的目标架构与产品原则。
+- [x] 给出核心模块逐项“保留/合并/冻结/删除候选”结论及证据。
+- [x] 给出安全、权限、付款、审计、备份恢复中不可削减的底线。
+- [x] 给出可取消的产品化、规模化和通用平台建设项。
+- [x] 给出按收益/成本/风险排序的 30 天、后续按需行动建议。
+- [x] 明确哪些现有开放项应继续、降级或关闭。
+- [x] 给出企微主办、企微审批 + OA 最小留存、OA 主办的能力边界与迁移优先级。
+- [x] 明确调休的企微归属、最小实现边界和后续验证方式。
+- [x] 给出后续改进优化任务地图，不把跨域工作合并成一次大改。
+- [x] 任务只做只读调研与建议，不修改业务代码、不部署、不写真实数据。
+
+## 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 长期维护面，而不是追求功能完整度、配置自由度、外部可扩展性或行业对标得分。

.trellis/tasks/07-26-small-team-internal-oa-review/research/internal-only-review.md

@@ -0,0 +1,300 @@
+# 5–10 人内部 OA 适配性复审结论
+
+## 一、执行结论
+
+hyb-oa 当前已经不是“功能不够”的问题，而是“长期维护面明显大于 5–10 人内部使用所需”。现有代码质量和本地候选门禁较强，但产品、数据模型、集成、测试和历史治理资产已经接近一套通用中型 OA 平台。
+
+推荐战略不是大规模重写，而是：
+
+1. 固定单公司、单实例、内部自用边界。
+2. 先完成真实部署来源、权限、备份恢复和访问边界等运营底线。
+3. 用现有工作区配置隐藏低频模块，不急于删除数据和代码。
+4. 让企微主办入口、身份、组织、消息、考勤和简单审批；停止差旅、ERP、AI、通用工作流、灰度发布以及 OA 内的企微全量镜像/双向回写等新增开发。
+5. 观察 30 天真实使用后，再按模块执行“触达即删”，避免一次性重构破坏已验证的业务链。
+
+最终目标应是“企微通用前台 + OA 财务与敏感业务控制台 + 单机可恢复运行”，而不是继续追求通用 OA 完整度。
+
+## 二、证据与限制
+
+### 已确认事实
+
+| 维度 | 当前规模/状态 | 判断 |
+| --- | --- | --- |
+| 前端 | 75 个页面文件，约 4.2 万行页面代码；导航 registry 覆盖约 50 个页面语义 | 对 5–10 人团队偏重 |
+| 后端 | 68 个路由文件，约 5.1 万行路由代码 | 业务与治理面较宽 |
+| 数据模型 | 117 个 Prisma model、79 个 enum、61 项 migration | 已接近通用平台模型，不宜继续扩张 |
+| 功能治理 | 26 个 feature flag，支持 env + DB override + 部门 allowlist | 单公司内部工具不需要部门灰度能力 |
+| 差旅 | 34 个相关代码/测试文件，约 1.28 万行 | 当前冻结，但维护面仍大 |
+| ERP | 21 个相关代码/测试文件，约 4960 行 | 事实源已明确未来不接 ERP，属于退役候选 |
+| 企业微信 | 59 个相关代码/测试/QA 文件，约 2.51 万行；免登、消息、通讯录、打卡、人事花名册、审批读取/回调/补偿等已有能力 | 是减少自研的首选平台；应扩大成熟原生能力的使用，同时压缩 OA 重复 UI、完整镜像和双向写回 |
+| QA/文档 | 161 个服务端测试文件、81 个前端测试文件、58 个 QA 脚本、47 个 docs 文件、349 个历史 Issue CSV | 质量证据强，但日常维护信噪比偏低 |
+| 仓库体积 | tracked 文件约 24 MiB | 不是 Git 膨胀问题，无需激进清理 |
+
+关键代码证据：
+
+- 主导航目前可覆盖工作台、团队、请假、考勤、报销、资产、周报、公告、项目、管理、审批、合同、采购、差旅、预算、付款、AP、票据、盘点和看板：`client/src/components/navigation/NavLinks.tsx:20`。
+- 默认工作区已经标记为 `small_team_internal` 和 `single_company`，但仍保留 30 余项模块可见性配置：`server/src/services/workspaceSettings.js:3`、`:111`、`:169`。
+- feature flag 支持 `global` 和 `department_allowlist` 两种 rollout：`server/src/services/featureFlags/index.js:1`、`:31`、`:247`。
+- 作业系统同时支持 cron、pg-boss 和独立 worker：`server/src/jobs/jobSystem.js:1`、`deploy/trialrun/docker-compose.yml:76`。
+- 部署还准备了可选 MinIO：`deploy/trialrun/docker-compose.yml:22`；当前本地文件存储已经能满足小团队 V0。
+- 当前可信状态仍是 `LOCAL_CANDIDATE_PASS`，7 月安全修复尚无当前部署/公网证据：`docs/文档事实源状态矩阵.md:11`、`.trellis/tasks/archive/2026-07/07-26-trellis-upgrade-project-audit/research/current-state-audit.md:55`。
+- 恢复演练仍未完成：`deploy/trialrun/checklist.md:115`、`docs/试运行与自动化验证手册.md:245`。
+
+### 无法由仓库回答的事实
+
+本轮未读取生产数据库或真实访问日志，因此不能证明每个模块的实际月使用次数。物理删除模块前应先收集 30 天的脱敏模块访问/写入计数，至少回答：谁使用、使用几次、失败损失、替代方式和数据保留要求。
+
+## 三、目标产品形态
+
+### 推荐的内部工作台
+
+普通员工默认从企微工作台、原生审批和消息进入日常操作；只有票据、财务、合同或台账事项才进入 OA。OA 内默认只需要：
+
+- 工作台
+- 我的报销
+- 与 OA 主办业务相关的我的申请/待我处理（按角色出现）
+- 与本人相关的采购、项目、合同或资产入口（仅真实常用项）
+- 通知和个人设置
+
+负责人/财务在此基础上增加：
+
+- 待我处理
+- 付款与财务处理
+- 授权范围内的合同、采购、项目和票据
+
+系统管理员只从“管理”进入人员、权限、审计、配置和故障处理，不把这些入口铺在普通导航。
+
+建议每个角色的常驻一级入口控制在 5–7 个。当前已有 `moduleVisibility`，第一步只需按真实使用配置，无需先改导航代码。
+
+### 推荐的固定流程
+
+- 普通低风险事项：优先使用企微原生审批，申请人 → 一名负责人审批；OA 不再造表单。
+- 报销：申请、票据上传/OCR/去重、审批、财务复核、付款状态和回单查询全部在 OA 完成；员工通过企微工作台免登进入具体页面，企微只发送待办与结果通知。
+- 付款：财务制单/执行 → 经理或公司负责人独立复核；禁止同人制单和复核。
+- 高额付款：仍是两人复核，只增加醒目确认和线下核对，不引入第三层可配置审批。
+- 企微 HR/考勤：企业微信主办，OA 最多保留入口、摘要和必要审计；不继续建设完整双向镜像。
+
+### 企业微信能力边界
+
+| 层级 | 推荐能力 | OA 的责任 |
+| --- | --- | --- |
+| 企微直接主办 | 工作台入口、OAuth/免登、通讯录与基础组织、应用消息、请假（含调休）/补卡/外出/加班/打卡、公告、简单待办、低风险一次性审批 | 不复制移动 UI；必要时只提供 deeplink 或脱敏摘要 |
+| 企微发起/审批，OA 最小留存 | 一般行政申请、无需后续财务处理和敏感附件的简单采购 | 仅在需要业务关联时保存外部审批 ID、申请人、类型、状态、实际审批链与必要审计 |
+| OA 主办 | 报销全流程、发票 PDF/OCR、票据去重、合同正文、高敏附件、采购/财务台账、项目与资产台账、付款/AP、回单、跨模块关联与导出 | 企微仅作免登入口、待办/结果通知和精确 deeplink，不传业务正文或敏感附件 |
+
+现有实现已具备免登、应用消息、通讯录成员读取、打卡与规则读取、人事助手花名册、审批模板/申请详情读取、回调验签解密、补偿拉取和最小历史查询等复用基础。后续重点应是把真实简单流程迁到企微并删除 OA 重复入口，而不是继续扩张集成框架。
+
+必须保留一个现实限制：企微 API 无法完整读取后台审批规则，也不能单靠 API 证明申请人是否能改选审批人。因此，正式迁移每个行政或简单采购模板前仍需后台人工确认、真机提交页确认和提交后的实际审批链校验。
+
+报销不采用“企微申请/审批 + OA 票据/付款”的拆分模式。该模式表面减少 OA 表单和审批 UI，实际上增加附件搬运、重复录入、状态同步、异常补偿和跨平台查询。对 5–10 人团队，更低的总维护成本来自 OA 单一报销闭环，再借助企微免登、工作台入口和消息 deeplink 消除访问摩擦。
+
+## 四、模块裁剪矩阵
+
+| 模块 | 建议 | 原因与边界 |
+| --- | --- | --- |
+| 登录、账号、角色 | `KEEP + SIMPLIFY` | 保留密码登录、账号停用、最小角色和应急管理员；若邮件验证码/自助找回没有真实使用，改为管理员受控重置，减少公网认证面。 |
+| 工作台 | `KEEP` | 只展示真实待办、异常和常用入口；不要继续增加统计卡、成熟度提示或模块介绍。 |
+| 统一待办/审批 | `KEEP + SIMPLIFY` | 保留历史 snapshot 和统一处理入口；冻结通用 workflow definition 编辑器，固定少数审批模板。 |
+| 报销 | `KEEP + UNIFY` | 申请、票据、审批、财务处理、付款和回单保持 OA 单一闭环；企微承担免登入口、待办和结果通知。优先精简 OA 表单与移动交互，不做跨平台流程拆分。 |
+| PDF 发票/OCR | `KEEP CONDITIONALLY` | PDF 上传和票据去重可保留；只有月票据量足以稳定节省人工时才启用真实 OCR/worker，否则使用人工录入。图片 OCR继续冻结。 |
+| 采购/费用 | `KEEP CORE + SPLIT` | 简单采购/行政申请优先评估企微主办；OA 保留财务台账、受控附件、轻量验收和付款关联，不做采购订单、库存、三单匹配或供应商生命周期。 |
+| 合同 | `KEEP + SIMPLIFY` | 只保留元数据、到期提醒、负责人、关联业务和受控附件；不建设 CLM、电子签、条款库或版本协同。 |
+| 项目 | `KEEP CONDITIONALLY` | 科技初创通常需要轻项目台账，但只保留负责人、状态、里程碑、风险和业务关联；若连续 30 天无真实写入则降为 `FREEZE`。 |
+| 资产 | `KEEP + SIMPLIFY` | 保留设备责任、领用归还、离职交接；盘点任务和 QR 扫码只在资产数量或现场需求证明价值时启用。 |
+| 付款/AP | `KEEP + SIMPLIFY` | maker-checker、状态机、回单和审计不能删；前端可合并为一个“财务处理”入口，不再扩展银行直连、总账、自动对账。 |
+| 票据池 | `KEEP CONDITIONALLY` | 若报销 PDF 量稳定存在则保留；否则并入报销材料入口，独立票据后台降级。 |
+| 人员/组织 | `KEEP + SIMPLIFY` | 保留人员目录、账号、直属负责人、入离职和权限回收；组织层级限制为实际层级，不建设复杂组织模型。 |
+| 工资、绩效、培训 | `FREEZE` | 对 5–10 人团队敏感度高、使用频率低、维护成本高；工资和绩效优先由财务/线下受控材料承接，除非已有稳定月度使用。 |
+| 周报、公告、团队状态、独立待办、看板 | `MIGRATE/FREEZE` | 公告、周报、简单待办和团队沟通优先直接用企微；OA 重复入口隐藏，只有与财务/项目台账存在强关联的视图才保留。 |
+| 预算管理 | `FREEZE` | 小团队使用“资金安排说明 + 负责人确认”通常足够；不继续预算硬控和预算池建设。 |
+| 差旅 | `TOUCH-TO-REMOVE` | 当前已冻结，却保留申请、订单、企业卡、交易、核销和 ERP 摘要等三轨实现；先隐藏并停止扩展，确认无真实数据后分批退役 UI/API/job/model。 |
+| ERP 集成 | `TOUCH-TO-REMOVE` | 事实源已明确未来不接 ERP；停止维护 ERP adapter/job/route，先确认 outbox 是否仍被企微通知等路径复用。 |
+| AI 建议 | `FREEZE/REMOVE CANDIDATE` | 小团队没有通用 AI 工作台的必要性；外部依赖、隐私和提示治理成本高于当前收益。 |
+| 功能开关/切换控制台 | `FREEZE + SIMPLIFY` | 保留少数高风险 kill switch；停止部门灰度、复杂 inherit/override 和普通管理员日常配置。 |
+| 企微平台复用 | `EXPAND USE + REDUCE CODE` | 充分复用免登、通讯录、消息、考勤和原生审批；保留可靠回调与必要补偿，但只落最小业务索引。冻结完整原始 payload 镜像、通用 RuleOps、OA 复制企微 UI 和双向应急回写。 |
+| PWA 离线审批/上传/盘点队列 | `REMOVE OR HARDEN` | 对 5–10 人稳定联网内部团队收益有限，却增加跨账号残留和冲突处理。推荐关闭业务离线队列，仅保留静态壳；确有现场离线需求再做严格账号隔离。 |
+| MinIO、独立 worker | `DEFER` | 单机本地受控存储 + 备份足够；只有附件量、并发 OCR 或恢复需求证明瓶颈时再启用。 |
+
+## 五、不可削减的底线
+
+“内部使用”不能成为降低以下控制的理由：
+
+1. **身份与最小权限**：系统管理员不得自动获得工资、证件、合同原件和付款审批权限；应急 `admin` 单独托管。
+2. **付款职责分离**：至少两名不同自然人完成制单/执行与复核；5 人团队也不能自制自批。
+3. **敏感附件**：实际内容校验、对象权限、强制下载、下载用途和审计继续保留。
+4. **导出安全**：CSV/XLSX 是内部团队最常使用的交接媒介，统一公式中和仍应完成。当前 `csvCell()` 只处理引号/换行，没有处理 `= + - @` 等活动前缀：`server/src/routes/exports.js:132`。
+5. **客户端清理**：退出时虽清理 auth snapshot 和 PWA runtime cache，但三个 IndexedDB 业务队列没有统一清理入口；其中盘点队列没有 owner 字段，审批缓存会保存详情：`client/src/auth/AuthContext.tsx:251`、`client/src/mobile/inventoryScanQueue.ts:4`、`client/src/mobile/workflowActionQueue.ts:27`。
+6. **备份恢复**：数据库和附件必须成对备份、异机/异盘保存并实际恢复验证。仅有 backup 脚本不等于可恢复。
+7. **离职回收**：账号停用、企微解绑、角色撤销、设备/session 清理和资产交接必须有一个可执行清单。
+8. **审计**：保留付款、敏感资料、权限、附件下载和配置变更审计；无需把所有普通页面访问都做成重型审计。
+
+## 六、推荐运行架构
+
+### 默认形态
+
+```text
+受限 HTTPS/VPN/可信入口
+        ↓
+反向代理
+        ↓
+单个 Fastify 应用（同时服务 React 静态文件）
+        ↓
+PostgreSQL + 本地受控附件目录
+        ↓
+每日加密异机备份 + 定期恢复演练
+```
+
+推荐长期只保留反向代理、应用和 PostgreSQL 三个必要组件。当前 pg-boss 已稳定且依赖 PostgreSQL，可先保留在应用进程内，不值得为了“纯粹”重写；停止增加新 job。只有真实 OCR 积压或任务阻塞时再启用独立 worker。MinIO、完整 Prometheus/OTel、复杂告警和多进程扩展均不是当前前置条件。
+
+### 运维目标
+
+将现有 99.9% SLO、错误预算和 DORA 体系降为小团队可执行目标：
+
+- 工作日可用，计划维护提前通知。
+- 数据 RPO 建议 24 小时；付款/合同关键变更后可触发额外备份。
+- RTO 建议 4 小时或半个工作日，以一次真实演练结果为准。
+- 监控只保留：进程/容器存活、数据库连接、磁盘空间、备份结果、5xx、OCR/通知失败积压。
+- 不设置 24×7 pager、复杂错误预算或全链路追踪，除非真实故障频率证明需要。
+
+## 七、既有开放项重新排序
+
+| 既有事项 | 新优先级 | 处理建议 |
+| --- | --- | --- |
+| 当前安全修复未部署/未复核 | `P0` | 正式内部使用前核对实际运行提交、访问边界和关键角色行为。 |
+| 备份恢复未演练 | `P0` | 优先级高于任何新功能；用影子库和临时附件目录演练，不触碰正式库。 |
+| 真实账号与职责分配 | `P0` | 明确负责人、财务、系统管理员、应急管理员和第二付款复核人。 |
+| 统一导出公式中和 | `P1` | 保留并尽快完成，不能因内部使用降级。 |
+| 离线数据生命周期 | `P1` | 推荐优先关闭业务离线能力并清理 IndexedDB；只有明确离线需求才继续复杂隔离方案。 |
+| React Router moderate advisory | `P2/条件 P1` | 若系统继续公网可达则安排专项升级；若只通过 VPN/可信入口且无对应危险路径，可记录接受风险并等待兼容窗口。不要混入其他 major 升级。 |
+| 下载凭证、CSP | `P1（公网）/P2（私网）` | 根据最终访问面决定；高敏附件下载仍应优先。 |
+| 风险型覆盖阈值 | `P2` | 只对认证、付款、附件、权限、备份恢复设置，不追求全仓百分比。 |
+| 文档 registry 22 项 warning | `P2` | 修检查器即可，不复制台账；不阻断内部启用。 |
+| bundle、字体、PWA precache | `DEFER` | 没有真实弱网/首屏问题前不优化。 |
+| 全量可访问性、路由元数据、视觉一致性 | `TOUCH-TO-FIX` | 高频页面触达即修，不做全站运动。 |
+| ignored artifacts 清理 | `P3` | 仅是本地空间治理，不是系统价值问题。 |
+
+## 八、30 天行动建议
+
+### 第 1 周：先让系统可恢复
+
+1. 只读确认实际内部实例的运行提交、访问方式、TLS、数据库和附件位置。
+2. 完成真实角色分配和应急管理员托管；确认付款至少有两名不同人员。
+3. 为数据库与附件建立每日备份、异机/异盘副本和保留周期。
+4. 在影子环境完成一次 DB + 附件恢复，记录实际 RPO/RTO 和 `/ready` 结果。
+
+### 第 2 周：配置上先瘦身
+
+1. 使用现有工作区配置将每个角色常驻入口压到 5–7 个。
+2. 固定功能开关基线；关闭差旅、预算、AI、ERP、OA 看板/周报/团队状态和不使用的企微全量镜像，但保留并优先启用已验证的企微免登、消息、通讯录、考勤和审批接入。
+3. 禁止新增 workflow、feature flag、外部 provider 或后台 job，除非有明确月度使用证据。
+
+### 第 3 周：关闭最有价值的两个安全缺口
+
+1. 统一处理 CSV/XLSX 单元格活动内容。
+2. 关闭或清理离线审批、上传、盘点队列，确保退出和换账号后不残留业务详情。
+3. 根据最终公网/私网访问面决定 React Router、CSP 和下载凭证任务的时间窗。
+
+### 第 4 周：用真实使用决定删除
+
+1. 记录各模块 30 天脱敏访问与写入次数，不记录业务正文。
+2. 对每个低频模块登记负责人、替代流程、数据导出和保留要求。
+3. 优先建立 ERP、差旅、AI 的退役 task；一批只移除一类能力，先 UI/route，再 job/service，最后评估 model，不改写 migration 历史。
+4. 选择一个字段简单、低风险的真实行政审批做企微优先试点；通过后台、真机和实际审批链三项校验后，再决定哪些无财务后续的简单采购适合迁移。报销保持 OA 单一闭环。
+
+## 九、明确不再建设
+
+- 多租户、租户隔离、商业计费、插件市场和客户自定义。
+- 微服务、Kubernetes、服务网格、独立缓存集群和数据中台。
+- 通用低代码/BPM、任意层级审批、流程市场和部门灰度发布。
+- 银行直连支付、ERP、总账、自动记账、税务申报和完整财务系统。
+- 完整 CLM、电子签章、文件中心、知识库和源码/Secret 托管。
+- 完整 HRIS、薪酬绩效平台、排班、防作弊考勤、企微全量 payload 镜像、通用 RuleOps 和双向写回；但继续充分复用企微原生通用能力。
+- 通用 AI 助手、自动审批、AI 写库和 agent 自治。
+- 原生 App、小程序和复杂离线优先架构。
+- 以行业竞品功能数量、99.9% SLA、DORA 指标或全仓覆盖率作为内部系统成功标准。
+
+## 十、后续改进优化任务地图
+
+以下工作不合并为一次重构。当前复审任务完成并归档后，按顺序逐个创建 Trellis task；上一批达到验收和回滚条件后再进入下一批。生产、企微真实写入和真实数据操作仍需在对应任务中另行批准。
+
+### Batch 0：运行与恢复底线（P0）
+
+**目标**：先证明当前内部实例的来源可信、权限可控、数据可恢复。
+
+- 只读确认运行提交、访问边界、TLS、数据库和附件位置。
+- 固定负责人、财务、系统管理员、应急管理员和第二付款复核人。
+- 建立数据库 + 附件成对备份、异机/异盘副本及保留周期。
+- 在影子库和临时附件目录完成恢复演练，记录真实 RPO/RTO 和 `/ready`。
+
+**验收**：运行提交可追溯；付款制单与复核为不同自然人；最近一次备份可恢复；不触碰正式数据完成恢复证明。没有这批证据，不进入“用户可以正式测试”的结论。
+
+### Batch 1：企微入口与 HR/考勤收口（P0/P1）
+
+**目标**：把企微真正变成员工默认入口，并明确请假、调休、补卡、外出、加班和打卡均由企微主办。
+
+- 验证工作台免登、身份映射和指向具体 OA 页面而非首页的 deeplink。
+- 对齐 HR/考勤事实源：调休是企微 `leave` 模板中的假别，不新增第五个审批 target。
+- 先用脱敏 fixture/只读详情证明 OA 最小历史能区分调休与年假、事假、病假。
+- 在另行批准的真实企微步骤中，核对后台“调休”选项、真机表单、禁止自选审批人/自审和实际审批链。
+- 普通员工 OA 页面保持只读历史和企微处理提示；不建设 OA 调休余额、加班自动换休和薪资联动。
+- 将旧业务文档中“完整原始镜像、自动恢复写回”的泛化目标收缩为最小留存和人工受控兜底，避免继续维护双轨系统。
+
+**验收**：企微可提交并审批调休测试单；OA 只读历史正确显示“调休”、时间和状态；普通员工看不到 OA 日常提交入口；无原始 payload 或敏感正文进入证据文件。
+
+### Batch 2：导航和重复入口精简（P1）
+
+**目标**：先通过现有配置降低认知负担，不急于删除代码和历史数据。
+
+- 每个角色 OA 常驻一级入口控制在 5–7 个。
+- 普通员工主要保留工作台、报销、与本人相关的采购/合同/项目/资产和个人设置。
+- 隐藏 OA 中与企微重复的日常请假/考勤创建、公告、周报、简单待办和团队沟通入口。
+- 管理能力合并到单一“管理”入口；财务角色增加付款、AP 和票据入口。
+- 同步更新导航 smoke 基线，避免检查脚本强迫恢复已隐藏模块。
+
+**验收**：员工、经理、财务、系统管理员四类角色导航符合基线；深链仍可访问保留页面；隐藏模块不删除数据；前端 typecheck/build 和角色化导航测试通过。
+
+### Batch 3：报销单一闭环优化（P1）
+
+**目标**：报销申请、票据、审批、财务处理、付款和回单保持 OA 单一操作链，企微只降低进入和通知成本。
+
+- 从企微工作台免登进入 OA 报销页面。
+- 待审批、驳回、通过、待付款和已付款消息跳转到具体报销单或财务处理对象。
+- 复核员工是否需要重复录入字段、附件是否重复上传、状态是否需要跨页面寻找。
+- 保持 PDF 发票/OCR、票据去重、付款 maker-checker、回单和审计边界。
+- 只精简高频路径，不重做通用 workflow 或新的移动端框架。
+
+**验收**：员工和审批人从企微入口到目标单据无二次登录；一张测试票据只上传一次；申请至付款/回单状态可在 OA 连续追踪；相关后端测试、前端 typecheck/build 和聚焦 Playwright 通过。
+
+### Batch 4：两个高收益安全缺口（P1）
+
+**目标**：关闭内部团队最可能通过日常导出和共享设备触发的风险。
+
+- 统一中和 CSV/XLSX 的 `= + - @` 等活动单元格前缀。
+- 关闭不需要的离线审批/上传/盘点队列，或补齐 owner 隔离、登出和换账号清理。
+- 根据最终公网/私网访问面，再决定 React Router、CSP 和下载凭证的独立升级任务。
+
+**验收**：导出恶意前缀测试通过；登出/换账号后 IndexedDB 和缓存不残留上一账号业务详情；认证、附件与导出聚焦回归通过。
+
+### Batch 5：30 天使用观察与退役（P2）
+
+**目标**：用真实使用证据减代码，不凭主观一次性大删。
+
+- 只记录模块级脱敏访问/写入计数，不记录业务正文。
+- 对 ERP、差旅、AI、预算、复杂 feature flag、PWA 离线能力逐项记录使用人、频率、替代流程、数据保留和回滚要求。
+- 每类能力独立建立退役 task：先隐藏 UI/route，再移除 job/service，最后评估 model；不改写 migration 历史。
+- 若项目或独立票据池连续 30 天无真实写入，分别评估冻结或并入更高频入口。
+
+**验收**：每次只退役一个边界清楚的模块；数据可导出或按制度保留；相关测试、构建、治理和恢复路径不受影响。
+
+### 执行约束
+
+- 不预先创建全部子任务；按 Batch 0 → 5 即时创建，保持任一时刻只有一个主要实施任务。
+- Batch 0 的真实环境检查、Batch 1 的企微模板/测试单、部署和生产配置均需单独明确批准。
+- 任何权限、审批链、状态机或 migration 改动，实施后增加只读 reviewer 复核。
+- 每批都必须给出独立回滚方式；仅隐藏模块时保留数据，物理退役前再次确认使用和保留证据。
+
+## 十一、最终判断
+
+项目不需要推倒重来。核心财务、附件和审计能力已经具备较强本地质量基础，企微接入也已有可复用基础。最合理的路线是把企微作为员工日常入口和通用流程平台，把 OA 收缩成“财务与敏感业务控制台”：少入口、最小同步、强数据边界、可恢复、低频模块不打扰。
+
+未来任何新增功能应先满足四个条件：至少一名明确负责人、可说明的月使用频率、失败会造成真实损失、没有更便宜可靠的现成替代。不能同时满足时，默认不开发。

.trellis/tasks/07-26-small-team-internal-oa-review/task.json

@@ -0,0 +1,32 @@
+{
+  "id": "small-team-internal-oa-review",
+  "name": "small-team-internal-oa-review",
+  "title": "5-10人内部OA适配性复审",
+  "description": "以仅供 5–10 人初创科技公司内部管理、永久不产品化为前提，复审系统范围、复杂度、运维和治理投入。",
+  "status": "in_progress",
+  "dev_type": null,
+  "scope": "small-team-internal-only-product-engineering-operations-review",
+  "package": null,
+  "priority": "P2",
+  "creator": "shunli",
+  "assignee": "shunli",
+  "createdAt": "2026-07-26",
+  "completedAt": null,
+  "branch": null,
+  "base_branch": "main",
+  "worktree_path": null,
+  "commit": null,
+  "pr_url": null,
+  "subtasks": [],
+  "children": [],
+  "parent": null,
+  "relatedFiles": [
+    "client/",
+    "server/",
+    "docs/",
+    ".trellis/spec/hyb-oa/",
+    "scripts/qa/"
+  ],
+  "notes": "已完成只读复审和后续任务地图：采用企微主办、OA 补位，调休作为企微请假假别；报销保持 OA 单一闭环；按运行恢复、企微入口与 HR、导航、报销、安全、30 天退役六批逐项实施，真实环境动作另行批准。",
+  "meta": {}
+}