完成小团队内部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