diff --git a/.trellis/spec/hyb-oa/frontend-react-vite-design.md b/.trellis/spec/hyb-oa/frontend-react-vite-design.md
index 1d486c05..45eadce5 100644
--- a/.trellis/spec/hyb-oa/frontend-react-vite-design.md
+++ b/.trellis/spec/hyb-oa/frontend-react-vite-design.md
@@ -160,6 +160,48 @@ change the visual treatment once while preserving component contracts.
 - Focused Playwright screenshot coverage when changing login, Portal, primary
   PC list pages or command-bar/table styling.
 
+## Convention: Page Template Taxonomy
+
+**What**: hyb-oa frontend pages use six layout templates. New or redesigned
+pages must pick one primary template before implementation:
+
+- `工作台总览`: Portal and mobile home. Compact summary, today's actionable
+  items, conditional progress/blocker/reminder sections.
+- `任务处理列表`: workflow task queues. Pending summary, task list, processed
+  records and advanced filters.
+- `业务台账列表`: reimbursement, contracts, projects, payments, AP and invoices.
+  Page-header primary action, command bar, list/table body and folded ledger
+  tools.
+- `主从工作台`: procurement, assets and inventory checks. Left/index list plus
+  right/current-object detail and actions.
+- `详情工作区`: reimbursement detail, workflow task detail, project detail and
+  future contract detail. Overview, facts/evidence, right-side summary/command
+  panel and history.
+- `管理配置页`: people, organization, master data, approval rules, workflow
+  definitions, feature flags and audit logs. Grouped settings, searchable
+  tables and confirmed destructive/configuration actions.
+
+**Contracts**:
+
+- A page has one primary template. Local sections may reuse shared components,
+  but the page must not mix ledger, configuration, detail and dashboard patterns
+  without an explicit Trellis task.
+- Mobile is the responsive expression of these templates: top status/focus,
+  card list or sectioned detail, bottom primary action. Do not create a PC shell
+  inside mobile routes.
+- B-class business pages should usually choose `业务台账列表` or `主从工作台`.
+  Use a ledger when records open into details; use master-detail when users
+  select one object and edit/process it in the same workspace.
+- A-class task pages must not drift into configuration surfaces. C-class
+  configuration pages must not appear as ordinary employee task pages.
+
+**Tests Required**:
+
+- `cd client && npm run typecheck`
+- `cd client && npm run build`
+- Focused Playwright or screenshot checks for changed A-class, mobile or shared
+  template surfaces.
+
 ## Convention: Global Shell And Page Header Baseline
 
 **What**: PC page redesigns should preserve the shared Wave0-2 shell and
@@ -168,8 +210,10 @@ header baseline instead of recreating page-local wrappers:
 - `AppShellLayout` owns the PC shell background and content offset through
   `app-shell` and `app-shell-main`.
 - `Sidebar` and `NavLinks` own role-aware task navigation. The mental model is
-  a short primary task list plus collapsed `更多`; management configuration is
-  represented by one `管理` entry instead of many sidebar rows.
+  a task-first primary list plus collapsed `更多`; enabled OA-owned business
+  ledgers such as contracts, procurement, assets and projects should not be
+  hidden in `更多` by default when the current role has access. Management
+  configuration is represented by one `管理` entry instead of many sidebar rows.
 - `Topbar` is a compact command surface: page title, group badge, user context,
   global search and notifications. Do not expand it back into a large hero.
 - `PageHeader` and `WorkspaceHeader` should use `page-header-shell`,
@@ -187,6 +231,10 @@ point and prevents each route from inventing a different title/action layout.
 - Sidebar entries should be role-aware and task-first for domestic tech startups
   under 10 people; do not expose all permission-allowed modules as a default
   module catalog.
+- Do show enabled, permission-allowed day-to-day business ledgers directly in
+  the primary sidebar, including `合同`, `采购`, `资产` and `项目` when relevant.
+  `更多` is for low-frequency, frozen, staged or occasional entries, not a
+  place to bury common work.
 - Approvers see `待我处理`; ordinary employees should not see `待办` or
   `审批待办` in the sidebar by default.
 - PC leave navigation uses `请假记录` unless the current task explicitly opens OA
@@ -196,8 +244,9 @@ point and prevents each route from inventing a different title/action layout.
 - Finance labels should use work names such as `付款`, `应付账款` and `票据`;
   internal platform words like `AP 运营`, `ERP 集成` and `功能开关` should be
   hidden behind management wording or renamed for users.
-- `更多` is a lightweight collapsed row for low-frequency entries; do not add a
-  sidebar explanation card, subtitle or onboarding copy around it.
+- `更多` is a lightweight collapsed row for low-frequency, frozen, staged or
+  occasional entries; do not add a sidebar explanation card, subtitle or
+  onboarding copy around it.
 - Playwright navigation helpers should use exact names or anchored regex for
   short sidebar labels such as `管理`, otherwise fuzzy role-name matching can
   click longer labels such as `预算管理`.
@@ -220,6 +269,823 @@ point and prevents each route from inventing a different title/action layout.
   `Topbar`, `NavLinks`, `PageHeader`, `WorkspaceHeader`, login, Portal or other
   A-class pages.
 
+## Convention: Action Placement Baseline
+
+**What**: Page actions, filters, ledger tools and destructive commands use one
+system-wide coordinate model. New and redesigned pages should not invent
+page-local action placement.
+
+**Contracts**:
+
+- PC page primary action lives in the page header action area
+  (`WorkspaceHeader` / `PageHeader` actions). Keep one primary action per page
+  surface and at most two visible secondary actions.
+- List filters live in the first command bar below the page header. Search,
+  status, scope and other common filters stay on the left; ledger tools such as
+  export, batch, statistics, templates and advanced filters stay on the right or
+  inside `台账工具` / `更多`.
+- Row-level actions live at the right edge of a table row or at the tail of a
+  card. Prefer `查看详情`, `查看处理` and `继续编辑` over broad verbs that hide the
+  result.
+- Detail pages keep facts and evidence in the main content. High-risk actions
+  such as approve, reject, return, pay, publish, delete and configuration
+  switching live in the right command panel or a clearly separated
+  `detail-action-stack`, with confirmation that includes the current object
+  summary.
+- Form save/submit actions live at the form bottom on PC. Long forms may add a
+  right-side summary command panel, but the same action should not be repeated in
+  unrelated header, row and footer locations.
+- Mobile pages use top status/focus content plus a bottom safe-area action
+  surface for the primary action. Do not copy PC command bars or wide tables
+  into mobile routes.
+- Batch actions only appear after selection, as a contextual command bar or
+  bottom sticky bar.
+- Destructive, financial, approval and configuration-changing actions must be
+  visually and structurally separated from normal navigation/edit actions.
+
+**Why**: hyb-oa targets small teams where one person may switch roles many times
+per day. Stable action coordinates reduce relearning and help a solo developer
+avoid page-by-page exceptions.
+
+**Tests Required**:
+
+- `cd client && npm run typecheck`
+- `cd client && npm run build`
+- Focused Playwright or screenshot checks when changing shared page headers,
+  command bars, task lists, detail action panels or mobile bottom actions.
+
+## Convention: State-Driven Actions
+
+**What**: Business actions are derived from explicit object state and current
+actor context. Do not scatter page-local button conditions across route
+components.
+
+**Contracts**:
+
+- Before redesigning a page with mutable business records, define or reference a
+  state matrix. The matrix must cover object state, actor role, primary action,
+  secondary actions, forbidden actions, reason text, risk level and confirmation
+  requirement.
+- Common lifecycle states include draft, submitted, in approval, returned or
+  rejected, approved, pending execution or payment, completed or paid,
+  cancelled, abnormal and archived. Use the business module's real names when
+  they differ.
+- Draft states prioritize edit, submit and delete draft. Do not show approval or
+  payment actions there.
+- In-approval states prioritize progress, withdraw and supplement-material
+  actions. Approve, reject and return actions belong to the current user's
+  workflow task detail, not broad ledger rows.
+- Returned or rejected states prioritize correction and resubmission.
+- Approved-but-not-paid states route payment work to finance or cashier views;
+  ordinary employee views should explain the next step instead of exposing
+  executable payment controls.
+- Payment actions such as mark paid, register payment, cancel payment, batch
+  payment and execute payment live only in payment, finance-processing,
+  payment-batch detail or an explicitly current finance task panel.
+  Reimbursement, procurement, contract and project ledgers/details show payment
+  status, receipt status, `查看付款`, `补回单` or a payment-record link instead
+  of executable payment controls.
+- Paid, completed, archived and cancelled states are read-mostly. Print, export,
+  attachment download and history belong in `更多` or audit paths when allowed.
+- Abnormal states must explain source, impact and next step. A red status label
+  alone is insufficient.
+- Destructive, financial, approval and configuration-changing actions require
+  confirmation that shows the current object summary and writes audit evidence
+  when the backend supports it.
+- The frontend may hide disabled actions or show reason text, but the backend
+  remains the source of truth for permission and state validation.
+- Use destructive lifecycle verbs consistently: `删除` only for drafts,
+  non-effective temporary records or wrong materials that have not entered a
+  business process; `撤回` for initiator withdrawal during allowed workflow
+  states; `取消` when the business will not continue; `作废` when a numbered,
+  signed, paid, published or effective object becomes invalid; `归档` when a
+  completed object is locked for retention. Submitted business records should
+  not be physically deleted from ordinary UI paths.
+
+**Why**: State-driven actions prevent pages from showing buttons that the user
+cannot complete and keep reimbursement, procurement, contracts, assets and
+payments consistent as the system grows.
+
+**Tests Required**:
+
+- `cd client && npm run typecheck`
+- `cd client && npm run build`
+- Focused Playwright coverage for changed state/action behavior, especially
+  draft, rejected/returned, in-approval, approved, paid/completed, cancelled and
+  abnormal states.
+
+## Convention: Role-Scoped Data Surfaces
+
+**What**: The backend is the source of truth for permissions and data scope. The
+frontend shapes the authorized capabilities into the current task role instead
+of exposing every allowed tool at once.
+
+**Contracts**:
+
+- Ordinary employee views default to `我的`, `与我相关`, `我发起` and
+  `需要我补充`. Do not show company-wide ledgers, batch tools, export, audit,
+  configuration, internal IDs or other people's sensitive attachments by
+  default.
+- Initiator views emphasize current status, next step, supplement-material
+  needs, approval/payment progress and whether edit or withdraw is allowed.
+- Approver and processor views emphasize `待我处理` and the current node task.
+  Show approve, reject, return or transfer actions only when the server-backed
+  task assignment says the current user can act.
+- Approval actions such as approve, reject, return and transfer execute only in
+  `待我处理`, workflow task detail, mobile approval detail or an explicitly
+  current task-processing panel. Business ledger rows and ordinary business
+  details use `查看处理`, `查看进度`, `补材料` or a link into the workflow task;
+  they must not duplicate approval action buttons.
+- Finance and cashier views may expose authorized reimbursement, payment,
+  invoice, AP, receipt and exception operations. Full-scope, export, batch,
+  delegated creation and statistics tools belong in `台账工具`, `更多` or
+  role-only panels.
+- Owner and project-lead views emphasize team/project scope, blockers, risks and
+  approvals. They should not drift into system configuration unless the route is
+  a management route.
+- Admin views live under `管理` and cover people, organization, workflow,
+  feature flags, integrations, audit and troubleshooting. Do not mix these
+  controls into ordinary employee paths.
+- Read-only or audit views can show authorized evidence but must not show
+  mutable edit, approval, payment, publish or disable actions.
+- Do not add a global role or identity switcher. Multi-role users do not choose
+  `员工` / `财务` / `管理员` before using the system. Routes infer the most
+  relevant task view by default.
+- Multi-role users may switch scope inside a specific authorized ledger, but the
+  default scope follows the page purpose: reimbursement starts with mine,
+  workflow tasks start with my tasks, ledgers start with relevant or recent
+  records, management starts with management scope. Use route-local scope
+  controls such as `我相关` / `我负责` / `财务处理` / `全范围`.
+- Use explicit controls such as `我的 / 团队 / 全范围` only when the server grants
+  those scopes. Hiding controls in the frontend is not a security boundary.
+- Unauthorized actions should usually be hidden. When explanation is useful,
+  show short natural Chinese reasons such as `当前节点不是你处理`, `已支付单据不可编辑`
+  or `仅财务可导出`.
+
+**Why**: hyb-oa users often wear several hats. Role-scoped surfaces keep one
+person's broad authority from turning every page into an admin console.
+
+**Tests Required**:
+
+- `cd client && npm run typecheck`
+- `cd client && npm run build`
+- Role-focused Playwright coverage when changing visibility for employee,
+  approver, finance/owner or admin paths.
+
+## Convention: User-Facing Identifiers And Copy Semantics
+
+**What**: Ordinary product surfaces use business identifiers and natural
+Chinese. Internal identifiers are auxiliary evidence for audit and
+troubleshooting, not primary user-facing content.
+
+**Contracts**:
+
+- Use business identifiers, names or summaries as primary labels: reimbursement
+  number, purchase request number, contract number, asset number, payment batch
+  number and project name.
+- Do not show UUID, taskId, entityId, permission code, role code, internal state
+  code, raw payload, full local path, API path, database field name, OCR
+  provider, debug trace, Secret or token on ordinary employee, approver,
+  finance or mobile paths.
+- Audit logs, admin troubleshooting, integration failure details, printed
+  evidence and export handoff files may show necessary internal IDs when
+  authorized. Place them in low-priority areas such as `技术信息`, `审计信息` or
+  `排障信息`; never use them as the page title, card title, button label or
+  first ordinary list column.
+- Show one primary identifier for the same object in one surface. Avoid placing
+  business number, UUID, taskId and entityId together unless the route is an
+  audit/troubleshooting route.
+- Translate technical enum values and platform words into natural Chinese:
+  `PENDING_APPROVAL` becomes `审批中`; `REJECTED` becomes `已驳回` or
+  `被退回待补正`; `AP Operations` becomes `应付账款`; `Feature Flag` becomes
+  management wording.
+- Time copy should answer the business question. Prefer `已等待多久`, `接收于`,
+  `提交于`, `支付于` and `归档于` over generic `更新时间` when the user needs to
+  decide what to do.
+- Errors and abnormal states must explain source, impact and next step in
+  natural Chinese. Do not surface only HTTP codes, backend enum names or red
+  badges.
+- Notifications and mobile cards use the shortest useful business identifier or
+  summary. Do not pack long technical IDs into small surfaces.
+
+**Why**: Internal implementation language makes the product feel complex and
+unfamiliar. Business identifiers and natural Chinese keep small-team workflows
+legible.
+
+**Tests Required**:
+
+- `cd client && npm run typecheck`
+- `cd client && npm run build`
+- UI tests or screenshot review for changed list/detail/notification/mobile
+  surfaces to confirm internal IDs and technical enum names are not visible.
+
+## Convention: Ledger List Defaults
+
+**What**: Business list and ledger pages default to a light, task-oriented list.
+Advanced ledger capabilities remain available but must not dominate the first
+screen.
+
+**Contracts**:
+
+- Keep 3 to 5 high-frequency filters visible by default. Prioritize search,
+  status, scope and date/time; add business-specific filters such as project,
+  person or type only when they are genuinely frequent.
+- The default view must match the route's main job: `我的报销`, `待我处理`,
+  `合同台账`, `资产台账` and similar task nouns. Do not default ordinary users
+  into company-wide management views.
+- Rows and cards must answer what the object is, current state, why it relates
+  to the current user and the next action.
+- Place common filters on the left side of the command bar below the page
+  header. Put export, batch, statistics, templates, full-scope, advanced
+  filters, delegated creation and low-frequency module links in `台账工具`,
+  `更多` or role-only panels.
+- Batch actions appear only after selection, as a contextual command bar or
+  bottom sticky bar. High-risk batch actions such as approve, pay, delete or
+  publish require summary confirmation and result details.
+- Export is not a primary page action. Explain export scope and sensitive
+  content when relevant; finance, contract, asset and invoice exports must stay
+  permissioned and auditable.
+- PC ledgers may use pagination, sorting and density controls. Default columns
+  should be decision-supporting fields only; low-frequency fields belong in
+  details, column configuration or advanced filters.
+- Empty states are status-specific. `没有草稿`, `没有被驳回`, `没有待处理` and
+  `没有异常` should not all share one generic explanatory panel.
+- Mobile routes do not copy PC ledger tools. Use search, status filtering, card
+  lists and one primary action; leave complex analysis, export and broad-scope
+  management to PC.
+- Contract, procurement, project and finance ledgers use a list-to-detail
+  boundary. The list is for discovery, filtering, status reading and navigation.
+  High-risk or sensitive actions such as contract download, archive, payment,
+  export, batch processing, void/cancel and sensitive attachment viewing belong
+  in detail workspaces, detail command panels or `台账工具`, with permission,
+  audit and confirmation.
+- Default ledger scope follows the current task role: ordinary employees see
+  `我发起` / `我相关`, owners and project leads see `我负责` / `项目相关`, finance
+  sees `待复核` / `待付款` / `异常`, and admins may enter or switch to `全范围`.
+  Full scope, export and batch commands stay in `台账工具` or role-only panels,
+  not ordinary first screens.
+- Contract ledgers in V1 are registration, archive, due/renewal reminder and
+  relation surfaces for project, procurement and payment context. Do not design
+  `/contracts-registry` as e-signature, legal-review, clause-library,
+  version-collaboration or full CLM software. If contract approval is needed,
+  link to the OA approval center or a separate future task instead of adding an
+  approval workspace inside the contract ledger.
+- Procurement ledgers in V1 are request, approval, attachment, light
+  acceptance/archive and relation surfaces for project, contract and payment/AP
+  context. Do not design `/purchase-requests` as purchase-order lifecycle,
+  inventory, three-way matching, supplier-lifecycle, tendering or ERP software.
+  Approved procurement means the request was approved; it does not imply paid,
+  received into inventory or converted into a fixed asset.
+- Project pages in V1 are light project ledgers for status, owner/member,
+  milestone/task, risk, delivery-record and related reimbursement, procurement,
+  contract and payment context. Do not design `/projects` as full project
+  management software with Gantt charts, complex dependencies, timesheets,
+  resource scheduling, OKR, portfolio management or large collaboration suites.
+  Project pages summarize and route; source records stay in their business
+  modules.
+- Finance ledgers in V1 are payment-preparation, payment-batch, receipt-audit,
+  AP-status, invoice/OCR-status and agency-accounting handover summaries. Do
+  not design payment, AP or invoice pages as online banking, bank-statement
+  ingestion, ERP/general-ledger, voucher-generation, auto-reconciliation, tax
+  filing or full accounting software. Real payment stays in offline banking or
+  existing finance/accounting workflows; OA records status, evidence and
+  handover summaries.
+- Payment actions require the finance/payment context: amount, payee or target
+  object, source records, offline payment explanation, evidence completeness,
+  receipt requirement and correction boundary. Do not place `标记已付款`,
+  `取消付款`, `批量付款` or `执行付款` directly in reimbursement, procurement,
+  contract or project ledgers/details.
+- Cross-module relation sections are summary-and-route surfaces. Project,
+  procurement, contract, reimbursement, asset and payment pages may show related
+  business number/name, status, amount or quantity, owner, evidence completeness
+  and next-step summary, then link to the owning detail/task/finance page. Do not
+  duplicate the owning module's approval actions, payment actions, invoice/OCR
+  processing, contract-body download, sensitive attachment actions, state machine
+  or batch tools inside another module's relation card.
+
+**Why**: The product's main complexity complaint is too many visible operations.
+Light default ledgers keep daily work simple while preserving advanced finance
+and management workflows.
+
+**Tests Required**:
+
+- `cd client && npm run typecheck`
+- `cd client && npm run build`
+- Focused Playwright or screenshot checks when changing list filters, command
+  bars, `台账工具`, batch selection behavior, empty states or mobile list cards.
+
+## Convention: Asset Registry Pages
+
+**What**: Asset pages render `FA` fixed assets as a lightweight responsibility
+ledger inside the unified asset registry, not as a full accounting fixed-asset
+subsystem.
+
+**Contracts**:
+
+- The default `/assets` view answers where the asset is, who uses it, who is
+  responsible for it, what state it is in and whether it needs inventory or
+  handover. Do not lead with depreciation, accounting subjects or ERP sync.
+- Register physical items that must be returned, transferred, inventoried or
+  protected, such as computers, monitors, disks, equipment and security media.
+  Do not create `FA` cards for ordinary consumables.
+- Every `FA` card needs an asset number. Physical assets that can carry labels
+  should expose QR-label status for scan, inventory, assignment and return
+  workflows. Assets that cannot be labeled must still expose serial number,
+  custodian and location as the lookup fallback.
+- Inventory cadence is lightweight: quarterly routine checks by default, event
+  checks for departure, transfer, repair and retirement, and monthly custodian
+  plus location confirmation for high-risk physical assets such as backup disks,
+  security media and critical equipment.
+- Assignment, return and transfer are daily flow actions that admins may record
+  with audit evidence. Disposal actions such as retirement, loss, sale and gift
+  require owner confirmation, a reason and consequence summary. If compensation,
+  money or responsibility is disputed, the asset UI records pending/confirmed
+  outcomes only and must not complete the dispute in one click.
+- Keep acquisition source, business number, owner/custodian, location, status,
+  assignment, return, transfer, repair, retirement, inventory result and
+  handover evidence visible in the business flow.
+- Procurement or reimbursement records may expose an asset-candidate signal, but
+  they must not create an `FA` asset card automatically after approval,
+  submission or payment. The asset registry UI may guide admins from candidates
+  to `新建资产卡片`, but the card is created only after manual verification of
+  delivery, quantity, owner/custodian, consumable status, returns and gifts.
+- Move depreciation, residual value, accounting subject and monthly
+  depreciation voucher concepts out of the OA primary UI unless a later Trellis
+  task explicitly scopes accounting-ledger work.
+- Keep classification maintenance, ERP sync, raw metadata and advanced filters
+  behind management, collapsed or advanced surfaces so they do not dominate the
+  asset list/detail first screen.
+- Mobile asset lookup should prefer QR scan and fall back to asset number or
+  serial number input. Do not require heavy photo inventory unless a later task
+  explicitly scopes it.
+- Asset list/detail UI may show last inventory, next inventory and overdue
+  hints. Do not turn cadence into a complex scheduling/configuration console in
+  the default asset registry view.
+- Disposal commands must be visually separated from assignment/return/transfer
+  commands and use confirmation that shows asset number, name, owner, current
+  custodian, location, reason and effect on asset status.
+- Electronic assets (`EA-DOC`, `EA-SYS`, `EA-REPO`, `EA-BKP`) are metadata and
+  responsibility indexes. Show owner, custodian/admin, permission-recovery
+  requirement, backup or restore-verification date, sensitivity level and
+  archive-location summary. Do not display or store source packages, secrets,
+  tokens, full configs, real full paths or backup contents.
+- `EA-DOC` list/detail views show document name, type, hash or verification
+  summary, sensitivity level, owner, related project/contract/payment and
+  archive-location summary. Contract text, bank statements, certificate
+  originals, customer materials, sensitive quotes, payroll/social-security data
+  and personal identity materials must not appear as ordinary asset-page
+  content; route business originals through their module attachment permissions
+  or offline controlled archive.
+
+**Tests Required**:
+
+- Asset page screenshots or E2E assertions should verify the first screen is
+  asset-list/detail/task oriented, with classification and integration tooling
+  demoted.
+- Mobile asset scan tests should cover lookup, summary and one allowed action;
+  mobile must not expose classification maintenance or full metadata editing.
+  Include QR scan or manual asset-number/serial-number fallback when this
+  surface changes.
+- Electronic asset UI changes should assert that sensitive source/config/backup
+  content and full paths are not visible in ordinary list/detail/mobile views.
+- `EA-DOC` UI changes should assert that high-sensitive originals are not
+  rendered in ordinary asset list/detail/mobile views.
+
+## Convention: Forms, Drafts And Validation
+
+**What**: Long business forms support interruption and recovery. Save draft and
+submit are distinct actions with different consequences.
+
+**Contracts**:
+
+- Long forms should support drafts by default when the business object requires
+  multiple fields, line items or materials, including reimbursements,
+  procurement, contract drafting, asset intake and payment supplement flows.
+- `保存草稿` stores progress only. It must not trigger approval, payment,
+  publishing or external synchronization. `提交` enters the business workflow.
+- Draft save may allow incomplete data, but it must preserve entered fields,
+  line items, attachment references and the recoverable object state.
+- Before submit, run business validation and show a summary confirmation with
+  the object summary, amount or quantity, important contract/asset/payment
+  facts, attachment or invoice completeness, and next node or consequence.
+- Material upload is type-first. Let the user choose or enter the material type
+  before upload, then apply type-specific copy, validation, permissions, audit
+  and display placement. Do not use one generic attachment uploader for PDF
+  invoices, ordinary attachments, contract files, payment receipts, acceptance
+  materials, asset materials and electronic-document indexes.
+- Upload labels must describe the result, such as `上传 PDF 发票`,
+  `补充付款回单`, `上传合同文件`, `补充验收材料` or `登记资产材料`.
+- Validation errors must point to the field, line item, invoice, attachment,
+  contract material or asset section that needs work. A top-level `提交失败`
+  message alone is insufficient.
+- Separate blocking errors from warnings. Blocking errors prevent submit;
+  warnings may allow users to confirm and continue when the business rule
+  permits it.
+- Server-side validation failures must preserve user input and show repair
+  guidance in natural Chinese.
+- Warn before navigation when the form has unsaved changes, including leaving
+  the route, closing a modal, switching record or returning to the list.
+- Autosave can be used as an enhancement, but the visible state must still make
+  clear whether the object is draft, submitted or failed to save.
+- Mobile forms keep only necessary fields, material upload, status explanation
+  and a bottom safe-area primary action. Do not move admin configuration,
+  complex configuration matrices, bulk import or workflow design into mobile
+  forms.
+- Mobile validation messages should appear near the field or material card, and
+  bottom actions must not cover the final input.
+
+**Why**: Small-team users often switch tasks mid-form. Drafts and precise
+validation prevent repeated re-entry and reduce support/debugging cost.
+
+**Tests Required**:
+
+- `cd client && npm run typecheck`
+- `cd client && npm run build`
+- Focused Playwright coverage for draft save, submit validation, unsaved-change
+  protection and server-validation failure paths when changing form behavior.
+
+## Convention: Detail Evidence Layout
+
+**What**: Detail pages use one evidence-first structure so users can understand
+state, facts and consequences before acting.
+
+**Contracts**:
+
+- Use this order for reimbursement, workflow task, procurement, contract, asset,
+  project and payment details: status/next step, business summary, evidence
+  materials, risk or validation signals, approval/processing history, actions.
+- The top overview shows business number or name, current state, critical amount
+  or object facts, current handler or next node, and a clear return path.
+- The first content block is `当前状态与下一步`: explain where the object is,
+  who needs to act, what happens next and whether there are blockers or
+  warnings.
+- The business summary block shows the fields needed before approval or review:
+  requester, amount, project, purchase object, contract counterparty, asset
+  owner, payment batch and similar module facts.
+- Evidence materials sit in the main content, grouped by business meaning:
+  line items, PDF invoices, attachments, contract files, asset photos/numbers,
+  receipts and acceptance materials.
+- Risk or validation sections appear only when there is a real signal such as
+  budget issue, duplicate invoice, missing attachment, contract expiry, asset
+  anomaly or payment failure.
+- Approval and processing history is for traceability. Keep a useful summary
+  visible, but do not let full history crowd out current status and evidence.
+- PC high-risk actions live in the right command panel or separated action
+  stack. Mobile high-risk actions live in the bottom action surface or a
+  confirmation panel.
+- Approve, reject, return, pay, publish, delete and void actions must show the
+  object summary and consequence before execution.
+- When evidence is incomplete, change the primary action to supplement material,
+  view issues or an explained disabled state. Do not leave users guessing from a
+  disabled button alone.
+- List and ledger rows show only evidence completeness summaries, missing
+  evidence hints and a detail entry. Invoice preview, attachment download,
+  contract file viewing, receipt download, evidence deletion and bulk packaging
+  belong in detail workspaces, detail command panels, `台账工具` or authorized
+  audit paths.
+- Sensitive evidence such as invoices, contracts, receipts and attachments must
+  be permissioned; download and export belong in `更多` or audit paths when
+  appropriate.
+- Detail evidence sections group materials by type. Do not mix invoices,
+  ordinary attachments, contract files, receipts, asset materials and
+  electronic-document indexes in one undifferentiated list.
+- Mobile details use a top focus card, sectioned cards and bottom safe-area
+  actions. Do not copy PC two-column detail or wide tables into mobile.
+
+**Why**: Detail pages are the place where users decide whether to approve,
+reject, pay or supplement materials. Consistent evidence order reduces
+misreads and accidental actions.
+
+**Tests Required**:
+
+- `cd client && npm run typecheck`
+- `cd client && npm run build`
+- Focused Playwright or screenshot checks when changing detail overview,
+  evidence sections, history placement, right command panels or mobile detail
+  bottom actions.
+
+## Convention: Mobile Lightweight Surfaces
+
+**What**: Mobile and Enterprise WeChat WebView routes are lightweight action
+surfaces. They are not compressed PC management consoles.
+
+**Contracts**:
+
+- Mobile may support lightweight submit, supplement-material, status lookup,
+  task handling, scanning, upload and message-deeplink flows.
+- Keep mobile pages to top status or focus card, card list or sectioned detail,
+  and bottom safe-area primary action.
+- Mobile home should show compact status and today's actionable items. Do not
+  add a full module directory or dashboard.
+- Mobile lists use search/status filtering, cards and one primary action. Do not
+  use wide tables, column configuration, complex multi-column filters,
+  full-scope management, admin configuration, batch export, bulk approval or
+  bulk payment.
+- Mobile details use a focus card, sectioned evidence and bottom actions. Do not
+  copy PC two-column layouts.
+- Mobile forms keep necessary fields, material upload, field-local validation
+  and a bottom action. Do not put admin configuration, workflow configuration,
+  feature flags, statistics dashboards or bulk import into mobile forms.
+- Bottom actions must account for safe area and keyboard overlap. Button text
+  must remain readable on narrow screens.
+- Dangerous mobile actions must open a confirmation panel that shows object
+  summary and consequence.
+- Ordinary mobile paths must not show internal IDs, permission codes,
+  configuration matrices or audit troubleshooting panels.
+- Enterprise WeChat remains the primary owner for daily HR/attendance actions
+  such as leave, missed punch, outing, overtime and check-in. OA mobile shows
+  mirror/history/exception/emergency takeover according to the business
+  boundary.
+
+**Why**: Most mobile use happens from notifications or quick context switches.
+Reducing mobile scope keeps the phone path fast and prevents PC admin
+complexity from leaking into WeChat.
+
+**Tests Required**:
+
+- `cd client && npm run typecheck`
+- `cd client && npm run build`
+- Playwright or screenshot coverage for representative narrow viewports when
+  changing mobile home, mobile lists, mobile details, bottom actions, upload
+  surfaces or Enterprise WeChat WebView flows.
+- If true Enterprise WeChat device validation is unavailable, record it as
+  paused manual validation; do not claim full WebView acceptance.
+
+## Convention: Notifications Versus Tasks
+
+**What**: Task queues and notifications have separate jobs. A task queue is for
+action; a notification center is for event awareness and navigation.
+
+**Contracts**:
+
+- `待我处理` is an action list. Include only items that require the current user
+  to process, supplement material, review, pay, approve, confirm or resolve an
+  exception.
+- Task rows must have a clear next step, object summary, business state and
+  processing entry.
+- Completed items, read-only progress, announcements, successful sync notices
+  and ordinary system messages do not belong in the pending task list.
+- `通知中心` is an event inbox for status changes, reminders, failures, sync
+  results, workflow transitions, invoice/attachment recognition results and
+  Enterprise WeChat delivery results.
+- Notifications should support read/unread, view, jump target and failure
+  explanation. Do not rebuild the full workflow task list inside the
+  notification center.
+- Notification clicks must deep-link to the business detail, workflow task,
+  mobile target page or failure explanation. Do not send users back to a
+  generic notification list as the final destination.
+- Notification copy should explain what happened, who or what is affected, and
+  the next useful step. Do not expose raw payloads, internal state codes or
+  debug fields.
+- Workbench `今日待处理` aggregates only actionable items. Ordinary
+  notifications, read-only progress, completed activity and announcements are
+  not counted as pending work.
+- If a notification represents real work, the backend or aggregation layer
+  should expose it as an explicit task item; the frontend should not infer every
+  notification is a task.
+- The topbar bell is the notification entry. Do not add notification center as a
+  default sidebar row.
+- Enterprise WeChat messages are an external delivery channel. Keep message
+  content desensitized and deep-link into the OA business or task detail.
+
+**Why**: Separating event awareness from action prevents Portal, task queue and
+notification center from showing the same thing in three different ways.
+
+**Tests Required**:
+
+- `cd client && npm run typecheck`
+- `cd client && npm run build`
+- Focused Playwright coverage when changing task aggregation, notification
+  center rows, topbar bell behavior, notification deep links or workbench
+  `今日待处理` counts.
+
+## Convention: Sensitive Data And Exports
+
+**What**: Contracts, finance, invoices, receipts, payments, assets and
+attachments are sensitive by default. Frontend surfaces show the minimum useful
+summary unless a permissioned workflow requires more.
+
+**Contracts**:
+
+- Treat contract text and attachments, quotations, acceptance materials,
+  invoices, receipts, payment information, bank accounts, supplier details,
+  asset serial/location/owner data, personnel records, payroll/performance,
+  audit records, original file names and export files as sensitive.
+- Workbench, notifications, ordinary lists, mobile cards and Enterprise WeChat
+  messages show desensitized summaries only.
+- Ordinary surfaces must not show full bank/account numbers, full local paths,
+  storage paths, raw payloads, full sensitive attachment names, Secrets, tokens
+  or high-sensitive contract/finance details.
+- Previewing contract text, invoices, receipts and attachments requires
+  server-side permission checks. Frontend visibility is not a security boundary.
+- High-sensitive previews should explain context or purpose when useful and
+  record view evidence when the backend supports it.
+- Download, batch download, export, print, attachment packaging, contract text
+  export and finance ledger export must be controlled by server permissions and
+  data scope.
+- Export is never the primary first-screen action. Put exports in `台账工具`,
+  `更多` or role-only finance/admin panels.
+- Before exporting sensitive ledgers, explain scope and sensitive contents.
+  Finance, contract, asset and invoice exports should write audit records.
+- Export file names use business numbers and dates. Do not concatenate complete
+  personal accounts, complete supplier secrets or internal filesystem paths.
+- Audit sensitive operations with actor, time, object, action, scope and result
+  where supported.
+- Permission-denied and failure messages use natural Chinese without leaking
+  full paths, permission codes, raw URLs, payloads, Secrets or tokens.
+
+**Why**: The product is for small teams, but the data is still financial,
+contractual and operationally sensitive. Small team convenience must not turn
+into broad accidental disclosure.
+
+**Tests Required**:
+
+- `cd client && npm run typecheck`
+- `cd client && npm run build`
+- Focused Playwright or screenshot checks when changing attachment preview,
+  contract/invoice/receipt surfaces, export controls, mobile summaries,
+  notification copy or permission-denied states.
+
+## Convention: Permission Empty And Error States
+
+**What**: Permission-denied, empty and error states use natural Chinese that
+explains cause and next step. Ordinary users should not inspect platform
+internals to understand what happened.
+
+**Contracts**:
+
+- Hide unauthorized actions by default. If a route is opened directly or the
+  user needs context, show a natural Chinese explanation and a real next step
+  such as returning to workbench, viewing related records or contacting an
+  admin.
+- Empty states are scoped to the current filter, status or section. Explain what
+  is absent and show one useful next step; if there is no real next step, hide
+  the section instead of adding instructional copy.
+- Error states explain business cause, impact and recovery path such as retry,
+  supplement material, return to list or contact admin.
+- Ordinary user paths must not show raw `403`, API route names, permission
+  codes, internal state codes, route stacks, full paths, raw payloads or long
+  technical error dumps.
+- Admin, audit and troubleshooting routes may show the minimum technical
+  details needed to diagnose a problem, but the business reason and next step
+  remain primary.
+- Mobile and notification targets use shorter copy, but must still include
+  cause and next step.
+
+**Why**: Small-team users do not have time to decode implementation details.
+Clear failure states reduce support work and avoid leaking internal platform
+structure.
+
+**Tests Required**:
+
+- `cd client && npm run typecheck`
+- `cd client && npm run build`
+- Focused Playwright or screenshot checks when changing empty states,
+  permission-denied pages, notification failure targets or shared error
+  components.
+
+## Convention: Dangerous Action Confirmation
+
+**What**: Destructive, financial, approval, configuration, batch and external
+sync actions require meaningful confirmation. A generic `确定吗？` dialog is not
+enough.
+
+**Contracts**:
+
+- Treat delete, void, revoke, archive, restore, disable, publish, configuration
+  switching, workflow switching and feature-flag changes as dangerous actions.
+- Treat pay, batch pay, sensitive export, batch download, contract text
+  download and attachment packaging as dangerous or high-sensitive actions.
+- Treat approve, reject, return, transfer, batch approve and batch reject as
+  approval-risk actions that need context before execution.
+- Treat external synchronization, retry external write and Enterprise
+  WeChat/OA emergency-takeover switching as integration-risk actions.
+- Confirmation UI must show object summary: business number, name, requester or
+  counterparty, amount or quantity and current state when relevant.
+- Confirmation UI must explain consequences: target state, reversibility,
+  notifications, payment/approval/configuration impact and external-system
+  effect.
+- Confirmation UI must show impact scope for batch, export, configuration and
+  integration actions: selected count, data range, external system, Enterprise
+  WeChat message or audit scope.
+- Rejection and return require a reason. Payment, publishing, batch and
+  configuration actions may require a confirmation word, explicit checkbox or
+  selected reason when risk is high.
+- Dangerous actions must be visually separated from normal view, edit, save and
+  submit actions.
+- Mobile dangerous actions use bottom or full-screen confirmation panels, not
+  instant execution from an easy-to-mistap control.
+- Confirmation failure must preserve user input and show result details plus the
+  next repair action.
+- Audited actions should record actor, time, object, action, scope, reason and
+  result where backend support exists.
+- Delete, withdraw, cancel, void and archive confirmations must use the exact
+  business verb and explain the target state. Do not label cancel, void or
+  archive as `删除`.
+
+**Why**: These actions can change finance, contracts, workflow, approvals,
+configuration and external integrations. Users need context before execution,
+and support needs an audit trail after execution.
+
+**Tests Required**:
+
+- `cd client && npm run typecheck`
+- `cd client && npm run build`
+- Focused Playwright coverage when changing delete, payment, approval,
+  publish/disable, batch, configuration or external-sync confirmations.
+
+## Convention: Integration Boundary And External Status
+
+**What**: External-system state is conservative. OA shows facts confirmed by its
+own backend and explicit external acknowledgements; it does not present a queued
+request, frontend click or message attempt as final business completion.
+
+**Contracts**:
+
+- OA owns reimbursement, procurement, contracts, projects, payments, AP,
+  invoices, assets, sensitive attachments, audit and OA workflow handling.
+- Enterprise WeChat owns daily HR/attendance actions: check-in, leave, missed
+  punch, outing and overtime. OA shows mirror, history, exception, audit and
+  emergency-takeover records for those domains.
+- ERP, agency accounting, bank, OCR and Enterprise WeChat messages are external
+  capabilities or delivery channels. They do not replace OA server-side
+  permissions or state machines.
+- Show final labels such as `已同步`, `已发送`, `已付款` and `识别完成` only when the
+  relevant external system has returned a clear success acknowledgement.
+- Use in-progress labels such as `同步中`, `等待回执`, `银行处理中`, `识别中` and
+  `消息发送中` when the request has started but is not confirmed.
+- External failures must show source, impact and next step in natural Chinese,
+  such as `银行回执未返回` or `OCR 识别失败，需重新上传 PDF`.
+- Do not expose raw external error codes, payloads, full URLs, secrets, tokens
+  or debug traces to ordinary users.
+- External writes, payment execution, ERP sync, Enterprise WeChat resend and OCR
+  retry must be controlled by permissions and state-driven actions.
+- Retry confirmation should explain which object will be retried, whether it may
+  send duplicate external messages, external-system impact and audit effect.
+- External sync state should not block unrelated primary flows. If it blocks a
+  flow, show the blocker and manual repair path.
+- Ordinary routes show summary, failure reason and next step. Admin, finance or
+  troubleshooting routes may show deeper diagnostics when authorized.
+- HR/attendance routes should default to Enterprise WeChat record, sync mirror
+  or exception handling copy. Do not expose OA daily leave/missed-punch paths
+  unless OA emergency takeover is explicitly enabled.
+- Enterprise WeChat messages carry desensitized summary and OA deeplink only;
+  they do not carry sensitive attachment text or final payment/approval actions.
+- If bank, ERP, agency accounting or another integration is not connected or not
+  confirmed, UI copy must not imply the capability already completed.
+
+**Why**: External integrations are asynchronous and failure-prone. Conservative
+copy prevents users from trusting a state the system has not actually verified.
+
+**Tests Required**:
+
+- `cd client && npm run typecheck`
+- `cd client && npm run build`
+- Focused Playwright coverage when changing Enterprise WeChat boundary copy,
+  OCR status, bank/payment callbacks, ERP/accounting sync status, retry
+  controls, external failure messages or integration diagnostics.
+
+## Convention: Verification And User-Testable Claims
+
+**What**: Verification claims must describe the actual validation level. Local
+checks, screenshots and mock Playwright runs do not mean a user can test the
+change online.
+
+**Contracts**:
+
+- Local build passing means only the local code built successfully.
+- Playwright passing means the specified automated path passed in the specified
+  environment and data state.
+- Screenshot review passing means only the captured viewport and state were
+  reviewed.
+- Deployment passing must identify the deployed environment, version or commit
+  and health check result when available.
+- Say `可以线上测试` only after deployment, public access check, key-path smoke
+  testing and necessary screenshot evidence are complete.
+- Before deployment, say `本地验证通过，尚未线上可测`.
+- After deployment but before public access check, say `已部署，公网检查未完成`.
+- If real-device or Enterprise WeChat WebView validation is unavailable, record
+  it as paused manual validation. Do not substitute automation for full WebView
+  acceptance.
+- A-class page changes should keep build, focused Playwright or screenshot
+  evidence according to risk.
+- Changes touching permissions, state machines, approval, payment, Enterprise
+  WeChat, external systems, sensitive downloads or production configuration
+  need rollback or manual repair notes.
+- Updating this design/spec documentation does not mean pages were refactored,
+  deployed or accepted for live trial.
+
+**Why**: This keeps delivery status honest and prevents the user from trying a
+change that has not actually reached a public environment.
+
+**Tests Required**:
+
+- Documentation-only changes: Trellis task validation, governance check and
+  `git diff --check`.
+- Frontend implementation changes: `cd client && npm run typecheck`,
+  `cd client && npm run build`, plus focused Playwright or screenshots based on
+  affected surface.
+
 ## Convention: A-Class PC Task-First Pages
 
 **What**: A-class PC pages such as Portal, approvals, reimbursement list and
@@ -296,6 +1162,10 @@ a later Trellis task adds an explicit backend eligibility contract.
   but normal approval remains in Enterprise WeChat.
 - Reimbursement, procurement, travel, contract and other amount/evidence-heavy
   OA-owned tasks should route through `查看处理` first.
+- Business ledgers and ordinary business details must follow the same rule:
+  show the task entry or progress, but do not place `通过`, `驳回`, `退回` or
+  `转审` directly in reimbursement, procurement, contract, project or asset
+  tables/details.
 - Future list-level quick approval requires the backend to expose an explicit
   eligibility flag such as `quickApproveEligible=true`, plus task-domain and
   audit semantics in the current Trellis task. Frontend heuristics based only on
@@ -319,10 +1189,15 @@ training or permission-maintenance surfaces:
   `处理待办`, `提交报销` or `请假`; do not use explanatory entries like
   `了解流程`, and do not route users to settings or notifications as a
   substitute for task guidance.
-- `个人设置` default content is account identity, notification preference and
-  Enterprise WeChat binding. Organization, report line and role summary may be
-  folded under `账号详情`; permission code lists and full employee dossier fields
-  stay out of the default view.
+- `个人设置` default content is personal profile, password/security,
+  notification preference and Enterprise WeChat binding. Organization, report
+  line and role summary may be folded under `账号详情`; permission code lists
+  and full employee dossier fields stay out of the default view.
+- Keep account settings separate from admin configuration. `个人设置` may show
+  personal profile, password/security, notification preferences and Enterprise
+  WeChat binding only. Organization maintenance, role assignment, approval
+  rules, feature flags, master data, audit logs, employee maintenance and
+  system configuration belong under `管理`, not the ordinary profile route.
 
 **Why**: Small teams need fewer default decisions. Persistent onboarding and
 permission-heavy profile pages make ordinary users inspect system internals
diff --git a/.trellis/tasks/05-29-page-design-rules-audit/check.jsonl b/.trellis/tasks/05-29-page-design-rules-audit/check.jsonl
new file mode 100644
index 00000000..336409d6
--- /dev/null
+++ b/.trellis/tasks/05-29-page-design-rules-audit/check.jsonl
@@ -0,0 +1,6 @@
+{"file": ".trellis/spec/hyb-oa/project-governance.md", "reason": "检查任务合同、计划、审批和治理门禁是否满足项目规则。"}
+{"file": ".trellis/spec/hyb-oa/frontend-react-vite-design.md", "reason": "检查页面规则是否符合前端任务优先和共享布局约定。"}
+{"file": ".trellis/spec/hyb-oa/docs-and-evidence.md", "reason": "检查是否误建长期文档、是否符合事实源回写和脱敏规则。"}
+{"file": ".trellis/spec/hyb-oa/wecom-boundary.md", "reason": "检查 HR/考勤企微主办和 OA 镜像/历史边界是否清楚。"}
+{"file": ".trellis/spec/hyb-oa/approval-workflow.md", "reason": "检查审批动作、状态和自审边界是否被正确表达。"}
+{"file": ".trellis/spec/hyb-oa/reimbursement-invoice-ocr.md", "reason": "检查报销、PDF 发票 OCR 和附件规则是否一致。"}
diff --git a/.trellis/tasks/05-29-page-design-rules-audit/design.md b/.trellis/tasks/05-29-page-design-rules-audit/design.md
new file mode 100644
index 00000000..8b180dbb
--- /dev/null
+++ b/.trellis/tasks/05-29-page-design-rules-audit/design.md
@@ -0,0 +1,1335 @@
+# 全页面设计规则地图
+
+## 0. 设计基准
+
+hyb-oa 不是大型企业 BPM 平台，也不是营销型 SaaS 官网。它是小团队日常办事系统，默认用户是国内 10 人以下科技初创公司的负责人、财务、行政、项目负责人和员工，且角色经常重叠。
+
+页面规则统一采用“任务优先、证据清楚、低频隐藏、边界明确”的基准：
+
+- 首屏先展示当前用户最可能要处理的事项，不先展示功能目录。
+- 一屏内只保留一个主动作；最多两个次动作；批量、导出、模板、统计、配置、历史筛选放到高级入口或详情页。
+- 普通用户路径不展示系统内部编号、调试字段、权限 code、原始 payload 和复杂配置矩阵。
+- PC 负责批量查看、台账、复核、导出和管理配置；移动/企微负责提交、补材料、查状态和从消息直达。
+- 企业微信主办 HR/考勤日常动作；OA 不重复建设请假、补卡、外出、加班的日常提交流程。
+- 所有页面文案使用自然中文，避免 `Portal`、`Dashboard`、`Workflow`、`AP Operations` 等平台词进入用户默认界面。
+
+## 1. 全局壳层和导航
+
+### PC Shell
+
+- `AppShellLayout` 继续承接桌面壳层，页面内容统一使用 `PageScaffold` 或 `ListWorkspace`。
+- 顶栏只做当前页标题、用户上下文、搜索/通知/账号入口，不做大欢迎区。
+- 侧边栏是任务入口，不是模块全集。一级入口按权限和模块启用状态显示真实业务入口：工作台、待我处理、报销、付款、应付账款、票据、项目、合同、采购、资产、团队、请假记录等。
+- `更多` 只放低频、冻结、阶段性或偶尔查看的入口，例如差旅、公告、周报、预算、盘点、数据看板；不要把合同、采购、资产、项目这类常用业务台账默认藏进 `更多`。
+- 普通员工默认不显示“待办/审批待办”；审批人显示“待我处理”。
+- 个人设置只从账号菜单进入；通知只从顶部铃铛/通知中心进入，不进侧边栏。
+- “管理”是统一管理入口，人员、组织、流程、规则、审计、功能开关、集成等进入管理页后分组承接。
+
+### 移动 Shell
+
+- 移动端使用统一 mobile shell 和 `PageScaffold`，不复制 PC 壳层。
+- 列表使用卡片，详情使用上方焦点卡 + 分区内容 + 底部主操作。
+- 深层业务页隐藏或弱化底部 Tab，返回路径明确。
+- 不使用横向滚动桌面表格；小屏按钮文字必须完整可读。
+
+## 1.1 全系统操作区坐标规则
+
+操作区位置必须统一，否则每个页面都会让用户重新学习。后续所有页面按下面的坐标放按钮、筛选、更多工具和危险动作。
+
+| 场景 | PC 位置 | 移动位置 | 放什么 |
+| --- | --- | --- | --- |
+| 页面主动作 | 页头右侧 `WorkspaceHeader/PageHeader actions` | 顶部焦点卡下方或底部主按钮 | 新建报销、新建采购、新建资产、返回列表、发起主要任务 |
+| 列表筛选 | 页头下方第一条命令栏左侧 | 列表前的 `mobile-command-surface` | 状态、范围、搜索、常用筛选 |
+| 列表工具 | 命令栏右侧或折叠的 `台账工具/更多` | 筛选区下方折叠菜单 | 全范围、导出、批量、统计、模板、高级筛选 |
+| 行级动作 | 表格最右列；卡片右上或尾部 | 卡片底部按钮 | 查看详情、查看处理、继续编辑 |
+| 详情主动作 | 页头右侧只放 1 个主动作 + 最多 2 个次动作 | 底部吸附主操作区 | 提交、保存、查看处理、返回 |
+| 详情高风险动作 | 右侧命令栏或主内容最后的 `detail-action-stack` | 底部确认动作或独立确认页 | 通过、驳回、退回、付款、发布、删除、切换配置 |
+| 详情低频动作 | `更多`、右侧次级卡片或折叠区 | `更多` 弹层/折叠区 | 打印、导出、归档、复制、外部同步、历史 |
+| 表单保存 | 表单底部右侧；长表单可在右侧命令栏固定摘要 | 底部吸附区 | 保存草稿、提交、取消 |
+| 批量动作 | 选择后出现的命令栏或底部吸附条 | 底部吸附条 | 批量通过、批量导出、批量标记 |
+| 危险/不可逆确认 | 居中确认弹窗 | 全屏/底部确认面板 | 删除、付款执行、发布流程、切换开关 |
+
+布局坐标约定：
+
+- 左侧只放导航、列表、索引或低频配置索引；不要把高风险动作放左侧。
+- 右侧放当前对象的摘要、下一步和命令面板；右侧不是第二个筛选区。
+- 上方放全局方向：页面标题、主动作、状态摘要、筛选/工具栏。
+- 下方放收尾动作：长表单保存、移动端吸底操作、批量选择后的动作条。
+- 主内容左列放事实和证据：明细、附件、发票、项目、合同、资产字段。
+- 操作按钮按风险从上到下排序：主动作、次动作、更多、危险动作；危险动作必须和普通动作拉开。
+- 同一页面不要同时在页头、列表行、详情尾部重复同一个主动作，除非移动端需要底部吸附以保证可达。
+
+页面类型坐标：
+
+- `列表页`：页头右侧主动作；命令栏左筛选右工具；表格最右列行操作；批量条只在选中后出现。
+- `台账页`：默认列表；工具区折叠；导出/统计/全范围不进首屏主动作。
+- `详情页`：顶部概览；左侧主内容；右侧命令/摘要；移动端改为顶部焦点卡 + 内容分区 + 底部动作。
+- `主从工作台页`：左侧是列表/索引，右侧是所选对象详情；新建动作在页头右侧或右侧详情顶部，不放在左侧索引深处。
+- `管理配置页`：页头右侧新增/导入；命令栏筛选；表格右列编辑；发布/停用/删除必须确认。
+- `移动页`：不使用左右布局；顶部状态，下面列表/详情，底部主动作。
+
+## 1.2 全系统状态和动作生命周期规则
+
+后续所有业务页面先列状态矩阵，再设计按钮和文案。不能先在页面上放按钮，再用零散条件去隐藏或禁用。
+
+状态矩阵至少包含：
+
+- 业务状态：草稿、已提交、审批中、被驳回、已通过、待付款/待执行、已完成/已支付、已取消、异常、归档等。
+- 当前角色：发起人、审批人、财务/出纳、负责人、管理员、只读查看者。
+- 当前主动作：该状态下最应该做的一件事，例如继续编辑、提交、补材料、查看处理、付款、归档。
+- 次动作和低频动作：撤回、复制、打印、导出、查看历史、下载附件等。
+- 禁止动作和原因：为什么不能编辑、删除、付款、通过或驳回，必须给自然中文解释。
+- 风险等级：普通动作、审批动作、财务动作、配置动作、不可逆动作。
+- 确认方式：是否需要摘要确认、理由输入、二次弹窗、权限复核或审计记录。
+
+通用规则：
+
+- 草稿类状态优先给编辑、提交、删除草稿；不显示审批/付款动作。
+- 审批中状态优先给查看进度、撤回或补材料；只有当前审批任务持有人进入审批详情后才出现通过/驳回/退回。
+- 被驳回状态优先给补正和重新提交，不把它当成普通失败提示。
+- 已通过但未付款状态由财务/出纳路径处理付款，不让普通员工看到可执行付款动作。
+- 已支付、已完成、已归档状态默认只读；打印、导出、查看附件按权限进入更多或审计路径。
+- 已取消状态只保留查看和必要复制，不恢复编辑提交。
+- 异常状态必须说明异常来源、影响和下一步，不只显示红色标签。
+- 删除、付款、发布、停用、切换配置、驳回、退回等动作必须显示对象摘要并二次确认。
+- 如果前端显示动作，服务端仍必须做最终校验；前端只能做体验显隐和原因解释。
+- 同一页面不能出现互相矛盾的动作，例如同时给“继续编辑”和“已归档只读”、同时给“查看处理”和“通过”但没有摘要确认。
+
+审批动作承接位置：
+
+- `通过`、`驳回`、`退回`、`转审` 只在 `待我处理` 进入后的审批详情、移动审批详情或明确的当前任务处理面板中执行。
+- 报销、采购、合同、项目、资产等业务台账列表不直接放审批动作，默认使用 `查看处理`、`查看详情`、`查看进度` 或 `补材料`。
+- 普通业务详情页可展示审批状态、当前节点、历史和进入审批任务的入口，但不复制一套审批动作区。
+- 批量审批默认不开放；如后续启用，必须有后端明确资格标记、摘要确认、失败明细和审计。
+- 审批动作执行前必须展示同一套业务摘要、证据完整性、风险提示、后果说明和必要理由输入。
+
+付款动作承接位置：
+
+- `标记已付款`、`登记付款`、`取消付款`、`批量付款`、`执行付款` 只在 `付款`、财务处理详情、付款批次详情或明确的财务任务处理面板中执行。
+- 报销、采购、合同、项目等业务列表和普通详情只显示付款状态、回单状态、`查看付款`、`补回单` 或进入付款记录入口。
+- 普通业务详情页可展示付款摘要、付款批次号、回单状态和历史，不复制付款动作区。
+- 批量付款默认不开放；如后续启用，必须有后端明确资格标记、付款范围、失败明细和审计语义。
+- 付款动作执行前必须展示金额、收款对象、来源单据、线下付款说明、证据完整性、回单要求和可撤销/修正边界。
+
+删除、撤回、取消、作废和归档语义：
+
+- `删除`：只用于草稿、未生效临时记录或明显上传错误且未进入业务流程的材料；删除后不进入审批、付款或归档链路。
+- `撤回`：发起人在审批中或允许撤回的流转节点取回申请，流程终止或回到可修改状态，必须保留撤回记录。
+- `取消`：业务决定不再执行，例如采购不买了、报销不继续、付款取消；必须记录取消原因、操作者和时间。
+- `作废`：已编号、已签署、已付款、已发布或已生效对象被判定无效；不得释放业务编号重用，必须保留原对象、原因和审计。
+- `归档`：业务完成后锁定留存，普通用户只读；后续修正采用追加记录，不直接覆盖历史。
+- 已提交后的业务对象原则上不物理删除；界面不使用 `删除` 来表达取消、作废或归档。
+
+典型状态矩阵方向：
+
+- 报销：草稿、被驳回、审批中、已通过、待支付、已支付、已取消、异常。
+- 采购：草稿、审批中、待补材料、已通过、采购中、已完成、已取消、异常。
+- 合同：拟定、待审批、已通过/待签署、履行中、到期预警、已归档、已作废、异常。
+- 资产：待入库、在库、已领用、调拨中、维修中、盘点异常、已报废、已归档。
+- 付款：待复核、待执行、执行中、失败待处理、已付款、回单待补、已关闭。
+
+## 1.3 全系统角色和数据范围规则
+
+服务端权限和数据范围是安全事实源，前端只负责把可见能力按当前任务角色收敛成低负担界面。不能因为某个用户拥有多岗权限，就在普通页面默认展开所有数据、所有高级工具和所有内部字段。
+
+角色视图规则：
+
+- 普通员工：默认看 `我的`、`与我相关`、`我发起`、`需要我补充`。不默认看到全公司台账、批量处理、导出、审计、配置、内部编号和他人敏感附件。
+- 发起人：重点看单据状态、下一步、是否需要补材料、审批/付款进度和可撤回/可编辑条件。
+- 审批人/处理人：重点看 `待我处理` 和当前节点任务。只有服务端确认当前用户是任务持有人或委托处理人时，才显示通过、驳回、退回、转审等处理动作。
+- 财务/出纳：默认看授权范围内的报销、付款、票据、AP、回单和异常处理入口。导出、批量、全范围、代填等能力放在台账工具或明确权限入口。
+- 负责人/项目负责人：默认看团队或项目范围内的摘要、卡点、审批和预算/合同/采购风险，不默认进入系统配置。
+- 管理员：看人员、组织、流程、功能开关、集成、审计和排障。管理入口聚合在 `管理` 下，不混到普通员工路径。
+- 只读/审计角色：可以看授权对象和审计证据，但不能出现编辑、审批、付款、发布、停用等可变更动作。
+
+数据范围规则：
+
+- 页面默认范围要符合页面语义：`我的报销` 默认我的；`待我处理` 默认当前用户待办；`合同/采购/资产/项目` 默认与当前角色相关或最近使用；管理页默认管理范围。
+- 需要跨范围查看时使用明确范围控件，例如 `我的 / 团队 / 全范围`，并且只在服务端授权时出现。
+- 同一用户多岗时，不做全局身份切换器。系统不要求用户先选择“员工/财务/管理员”身份；页面按当前任务自动收敛最相关视角。
+- 需要切换视角时，只在具体台账或管理页内提供授权范围控件，例如 `我相关 / 我负责 / 财务处理 / 全范围`；默认视角仍跟页面主任务一致，不在一个页面首屏混合员工、审批、财务、管理员四种视角。
+- 前端隐藏不是安全边界。所有列表、详情、下载、导出、审批、付款和配置接口都必须由服务端校验权限和数据范围。
+- 无权限动作优先隐藏；若用户需要理解原因，显示自然中文说明，例如 `当前节点不是你处理`、`已支付单据不可编辑`、`仅财务可导出`。
+- 普通路径不展示 UUID、taskId、entityId、权限 code、内部状态码、原始 payload、完整路径和敏感调试信息；审计/排障页也必须按权限和最小必要展示。
+
+## 1.4 全系统编号和信息语义规则
+
+普通用户界面的主语义必须是业务语言，不是系统内部实现。编号、状态、时间和错误文案都要让用户知道“这是什么、现在怎样、下一步做什么”。
+
+主标识规则：
+
+- 普通页面主标识使用业务编号、业务名称或自然摘要，例如报销单号、采购申请号、合同编号、资产编号、付款批次号、项目名称。
+- 同一对象在同一区域只展示一次主标识，不同时展示业务编号、UUID、taskId 和 entityId 造成噪音。
+- 移动端和通知只展示最短可识别业务编号或摘要，不塞完整技术编号。
+- 打印、导出和留痕文件默认使用业务编号；确需内部编号时放在审计辅助区域。
+
+禁止默认展示：
+
+- UUID、taskId、entityId、permission code、role code、内部状态码、原始 payload、完整本地路径、接口路径、数据库字段名、OCR provider、调试 trace、Secret 或 token。
+- 英文平台词不进入普通用户默认界面，例如 `Workflow`、`Portal`、`Dashboard`、`AP Operations`、`Feature Flag`、`ERP Integration`。
+- 技术枚举值必须映射成自然中文，例如 `PENDING_APPROVAL` 显示为 `审批中`，`REJECTED` 显示为 `已驳回` 或 `被退回待补正`。
+
+允许展示内部标识的场景：
+
+- 审计日志、管理员排障、接口失败详情、打印留痕、导出交接和客服/运维定位。
+- 即使允许展示，也要按权限和最小必要展示，并放在 `技术信息`、`审计信息`、`排障信息` 等低优先区域。
+- 内部标识不能成为按钮文案、页面标题、卡片主标题或普通列表第一列。
+
+状态和时间文案：
+
+- 状态文案使用用户可理解的结果和下一步，例如 `待你处理`、`当前节点`、`已等待 2 天`、`接收于 05-30 10:20`、`发票识别失败，需重新上传 PDF`。
+- 不用 `更新时间` 替代等待时间，不用 `状态变化时间` 替代业务进度。
+- 异常和失败必须说明来源、影响和下一步；不能只显示错误码或红色标签。
+
+权限、空态和异常：
+
+- 权限不足要说明为什么看不了或做不了，并给返回工作台、查看相关记录、联系管理员等真实下一步。
+- 空态要说明当前列表或分区为什么为空；如果没有可执行下一步，就隐藏该模块，不放教学型长文案。
+- 错误态要说明业务可理解原因、影响范围和下一步，例如重试、补材料、返回列表或联系管理员。
+- 普通用户路径不展示 `403`、接口名、权限 code、内部状态码、路由栈、完整路径、原始 payload 或大段技术错误。
+- 管理员、审计和排障页面可以展示最小必要技术信息，但不能替代业务原因和下一步。
+
+## 1.5 全系统列表和台账行为规则
+
+列表页和台账页负责让用户快速找到当前对象，不负责把所有财务、管理、统计和批量能力一次性铺开。默认列表要轻，高级能力要可达但不抢首屏。
+
+默认列表：
+
+- 首屏只保留 3 到 5 个高频筛选，优先级是搜索、状态、范围、时间，再按业务决定项目/人员/类型等。
+- 默认视图必须符合页面主任务，例如 `我的报销`、`待我处理`、`合同台账`、`资产台账`，不默认进入全范围管理视图。
+- 列表行或卡片必须先回答：这是什么、当前状态是什么、为什么和我有关、下一步是什么。
+- 空态按当前状态拆文案，例如没有草稿、没有被驳回、没有待处理、没有异常；不使用一个通用空态解释所有情况。
+
+筛选和工具：
+
+- 搜索、状态、范围、常用时间放在页头下方命令栏左侧。
+- `导出`、`批量`、`统计`、`模板`、`全范围`、`高级筛选`、`代填`、`关联低频模块` 统一进入 `台账工具`、`更多` 或权限面板。
+- 高级筛选可以保留，但默认收起；筛选项过多时分组，不横向堆满首屏。
+- 工具显隐必须同时受服务端权限、模块启用状态和页面任务角色约束。
+
+批量和导出：
+
+- 批量动作只在用户选中记录后出现，使用上下文命令栏或底部吸附条。
+- 批量通过、批量付款、批量删除、批量发布等高风险动作必须有摘要确认、失败明细和可审计记录。
+- 导出默认不是主按钮。导出前要说明范围和敏感内容；财务/合同/资产/票据类导出必须受权限和审计约束。
+
+排序、分页和密度：
+
+- PC 台账可以提供分页、排序和密度切换，但默认只展示最能支撑决策的列。
+- 不把所有字段都做成默认列；低频字段进入详情页、列配置或高级筛选。
+- 列表主列使用业务编号/摘要，时间列使用业务语义，例如提交于、接收于、已等待、支付于。
+
+移动端：
+
+- 移动端不复制 PC 台账工具，不出现宽表、复杂多列筛选、批量导出、全范围管理和管理配置。
+- 移动端列表使用搜索、状态筛选、卡片列表和底部主动作；复杂分析和导出回到 PC。
+- 移动卡片只展示业务摘要、状态、关键时间和一个主动作。
+
+## 1.6 全系统表单和草稿规则
+
+表单页负责让用户可靠完成一次业务提交，不负责展示配置能力大全。报销、采购、合同、资产、付款补材料等长表单默认要允许中断后继续，避免用户因为材料不全或临时切换任务而重填。
+
+草稿和提交：
+
+- 长表单默认支持草稿，至少覆盖报销、采购、合同拟定、资产入库、付款补材料等需要多步材料的对象。
+- `保存草稿` 和 `提交` 是两个清晰动作。保存草稿不触发审批、付款、发布或外部同步；提交才进入业务流程。
+- 草稿保存可以允许部分字段缺失，但必须保留已填内容、明细行、附件引用和可恢复状态。
+- 提交前必须做业务校验和摘要确认，确认内容包括对象摘要、金额/数量/合同关键信息、附件/发票完整性、下一节点或后果。
+
+材料类型先行：
+
+- 上传前必须先明确材料类型，再决定文件格式、必填字段、权限、审计和展示位置。
+- 发票、普通附件、合同文件、付款回单、验收材料、资产材料和电子资料索引不能混用一个万能 `上传附件` 入口。
+- 上传控件文案必须说清结果，例如 `上传 PDF 发票`、`补充付款回单`、`上传合同文件`、`补充验收材料`、`登记资产材料`。
+- 如果用户选错材料类型，应给自然中文提示并允许重新选择，不把发票图片自动转成附件，也不把合同正文塞进普通补充材料。
+
+校验和错误：
+
+- 错误提示必须定位到字段、明细行、发票、附件、合同材料或资产信息区，不只在页面顶部显示 `提交失败`。
+- 业务校验要用自然中文说明原因和修复方式，例如 `第 2 行金额缺失`、`这张发票未关联明细`、`合同附件未上传`。
+- 阻断错误和非阻断提醒分开。阻断错误禁止提交；非阻断提醒允许用户确认后继续。
+- 服务端校验失败后，前端要保留用户输入，不清空表单。
+
+离开保护和恢复：
+
+- 用户有未保存改动时，离开页面、关闭弹窗、切换记录或返回列表必须提示。
+- 自动保存可以作为增强，但不能让用户分不清当前是草稿、已提交还是失败。
+- 表单恢复后要显示最近保存时间或草稿状态，不用技术时间字段替代用户可理解状态。
+
+移动端：
+
+- 移动端表单只保留必要字段、材料上传、状态说明和底部主动作。
+- 移动端不承接复杂配置表单、大量字段矩阵、批量导入、流程设计、管理配置和全范围管理。
+- 移动端错误提示要靠近字段或材料卡片，底部主动作不能遮挡最后一个输入项。
+
+## 1.7 全系统详情页证据结构规则
+
+详情页负责让用户在做动作前看清事实、证据和后果。报销详情、审批详情、采购详情、合同详情、资产详情、项目详情和付款详情都使用同一信息顺序，不允许每个页面把摘要、附件、历史和动作随意混排。
+
+PC 详情页骨架：
+
+- 顶部概览：业务编号/名称、当前状态、关键金额/数量/对象、当前处理人或下一节点、返回路径。
+- 第一块：`当前状态与下一步`，说明现在卡在哪里、谁要处理、下一步是什么、是否有阻断或预警。
+- 第二块：`业务摘要`，展示审批/复核前必须知道的核心字段，例如报销人、金额、项目、采购对象、合同对方、资产归属、付款批次。
+- 第三块：`证据材料`，按业务组织明细、PDF 发票、附件、合同文件、资产照片/编号、回单、验收材料等。
+- 第四块：`风险与校验提示`，只在有预算、重复票据、附件缺失、合同到期、资产异常、付款失败等真实信号时出现。
+- 第五块：`审批/处理历史`，用于追溯，不抢首屏；默认摘要可见，完整历史可折叠。
+- 右侧命令区：放当前对象摘要、可执行动作、原因说明和高风险确认入口；不要把高风险按钮放在用户看不到证据的位置。
+
+动作和证据关系：
+
+- 审批、驳回、退回、付款、发布、删除、作废等动作必须在同屏或确认弹窗中展示对象摘要。
+- 证据不足时，主动作应变为补材料、查看问题或不可提交原因，不用灰色按钮让用户猜。
+- 附件、发票、合同正文、回单等敏感材料默认按权限最小展示；下载和导出进入更多或审计路径。
+- 列表页和台账页只展示证据完整性摘要、缺失提示和进入详情入口；发票预览、附件下载、合同文件查看、回单下载、资产材料删除和批量打包等证据操作必须进入详情页、详情命令区、台账工具或授权审计路径。
+- 详情页证据区按材料类型分组展示，不把发票、附件、合同文件、回单、资产材料和电子资料索引混在同一列表里。
+- 历史记录不能替代当前状态说明；用户先看下一步，再看完整历史。
+
+移动端详情：
+
+- 移动端使用顶部焦点卡、分区内容和底部吸附动作。
+- 分区顺序仍保持状态与下一步、业务摘要、证据材料、历史、操作。
+- 证据材料以卡片或折叠分区展示，不使用 PC 两列详情和宽表。
+- 底部主动作不能遮挡证据材料，危险动作要进入确认面板。
+
+## 1.8 全系统移动端规则
+
+移动端是快速处理入口，不是 PC 管理台的缩小版。手机和企业微信 WebView 主要解决“收到消息后快速看状态、补材料、处理待办、扫码/上传”的场景。
+
+移动端承接：
+
+- 提交轻量业务：新建报销、补材料、上传 PDF 发票、提交必要字段的采购/资产动作。
+- 查状态：查看我的报销、审批进度、企微同步记录、采购/资产/合同/付款关键状态。
+- 处理待办：从消息或移动待办进入任务详情，查看证据后处理。
+- 扫码和上传：资产扫码、发票/附件上传、必要材料补充。
+- 消息直达：从企业微信或通知点击进入目标业务详情、任务详情或失败解释页。
+
+移动端不承接：
+
+- PC 复杂台账工具、全范围管理、批量导出、批量审批、批量付款、流程配置、管理配置、功能开关、复杂高级筛选、大表格、列配置、统计大屏。
+- 普通用户手机路径不展示内部编号、权限 code、系统配置矩阵和审计排障面板。
+- HR/考勤日常请假、补卡、外出、加班仍优先由企业微信主办；OA 移动端只展示镜像、历史、异常和应急接管。
+
+移动布局：
+
+- 移动首页：顶部状态摘要 + 今日待处理 + 条件出现的进度/提醒，不放模块大全。
+- 移动列表：搜索/状态筛选 + 卡片列表 + 一个主动作；不使用横向滚动宽表。
+- 移动详情：顶部焦点卡 + 分区内容 + 底部安全区动作。
+- 移动表单：必要字段、材料上传、错误定位和底部主动作。
+- 底部主动作必须避开安全区和键盘遮挡；危险动作进入确认面板。
+- 小屏按钮文字必须完整可读，不能因为标签过长挤压变形。
+
+验证要求：
+
+- 移动端页面改动必须覆盖代表性窄屏视口截图或 Playwright 验证。
+- 涉及企业微信 WebView 的改动，若没有真机验证，只能记录为暂缓人工验证，不能声明已完整通过。
+
+## 1.9 全系统通知和待办关系规则
+
+工作台、待我处理和通知中心必须各司其职。不能因为同一个事件需要提醒用户，就在三个地方都做成待办。
+
+待办：
+
+- `待我处理` 是行动列表，只放需要当前用户处理、补材料、复核、付款、审批、确认或解决异常的事项。
+- 待办必须有明确下一步、对象摘要、业务状态和处理入口。
+- 已完成、只读进度、普通公告、系统消息、已同步成功等不进入待办列表。
+
+通知：
+
+- `通知中心` 是事件收件箱，记录状态变化、提醒、失败、同步结果、审批流转、附件/发票识别结果、企微消息结果等。
+- 通知默认不提供完整处理工具，只提供查看、已读、跳转和必要的失败解释。
+- 通知点击必须直达业务详情、审批任务、移动目标页或失败解释页；不能只把用户带到通知列表本身。
+- 通知文案要说明发生了什么、影响谁、下一步是什么；不显示原始 payload、内部状态码或调试字段。
+
+工作台：
+
+- 工作台 `今日待处理` 只汇总真正需要当前用户行动的事项。
+- 普通通知、只读进度、已完成动态和公告不算待处理。
+- 如果通知背后产生了行动项，应由后端或聚合层转成明确待办，再进入工作台；不要让前端把所有通知都当待办。
+
+关系边界：
+
+- `待我处理` 可以显示从通知点击进入的同一审批任务，但通知中心不复制审批列表。
+- 通知中心可以显示任务已分配、已超时、已被处理等事件，但处理动作仍在待办/详情页完成。
+- 顶部铃铛只承接通知入口；侧边栏不单独放通知中心。
+- 企业微信消息是外部触达渠道，消息内容脱敏，点击后进入 OA 业务详情或任务详情。
+
+## 1.10 全系统敏感数据和导出下载规则
+
+hyb-oa 处理合同、财务、票据、付款、资产和附件等高敏业务材料。小团队不等于默认全员可见，所有敏感内容按最小必要展示。
+
+敏感数据范围：
+
+- 合同正文、合同附件、报价单、验收材料、发票、回单、付款信息、银行账号、供应商信息、资产序列号/位置/归属、人员资料、工资绩效、审计记录、原始附件名和导出文件。
+- 企业微信消息、移动端卡片、普通列表、通知和工作台只展示脱敏摘要，不展示完整合同/财务/账号/附件细节。
+- 普通页面不展示完整账号、完整本地路径、原始文件存储路径、Secret、token、原始 payload 或高敏附件内部地址。
+
+展示和预览：
+
+- 默认展示业务摘要，例如合同编号和对方名称、发票金额和状态、回单状态、资产编号和归属摘要。
+- 预览正文、发票、回单和附件必须由服务端校验权限；前端隐藏按钮不是安全边界。
+- 高敏内容预览要有场景说明或用途提示，必要时记录查看行为。
+- 移动端默认更保守，只展示摘要和必要材料预览入口。
+
+下载和导出：
+
+- 下载、批量下载、导出、打印、附件打包、合同正文导出、财务台账导出都必须按权限和数据范围控制。
+- 导出前应说明导出范围、敏感内容和用途；财务、合同、资产、票据类导出应写入审计。
+- 批量导出不作为首屏主动作，进入 `台账工具`、`更多` 或管理/财务权限入口。
+- 导出文件名使用业务编号和日期，不拼接完整个人账号、完整供应商敏感信息或内部路径。
+
+审计和错误：
+
+- 敏感操作审计至少记录操作者、时间、对象、动作、范围和结果。
+- 权限不足时用自然中文解释，例如 `你没有查看该合同附件的权限`，不暴露对象完整路径或权限 code。
+- 失败重试不能把原始 payload、完整 URL、Secret 或 token 展示给普通用户。
+
+## 1.11 全系统确认和危险动作规则
+
+危险动作的确认不是礼貌性弹窗，而是防止误操作的最后一道产品保护。任何不可逆、财务、审批、配置、批量和外部同步相关动作，都必须让用户看清对象、后果和影响范围。
+
+危险动作范围：
+
+- 删除、作废、撤销、归档、恢复、停用、发布、切换配置、切换流程、关闭功能开关。
+- 付款、批量付款、导出高敏材料、批量下载、合同正文下载、附件打包。
+- 审批通过、驳回、退回、转审、批量通过、批量驳回。
+- 同步外部系统、重试外部写入、切换企业微信/OA 应急接管状态。
+
+确认内容：
+
+- 对象摘要：业务编号、名称、申请人/对方、金额/数量、当前状态。
+- 后果说明：执行后会进入什么状态，是否可撤回，谁会收到通知，是否影响付款/审批/配置。
+- 影响范围：单个对象、批量数量、数据范围、外部系统、企业微信消息或审计记录。
+- 必要输入：驳回/退回必须填理由；付款/发布/批量高风险动作可要求输入确认词、二次勾选或选择原因。
+- 审计说明：需要审计的动作应明确记录操作者、时间、对象、动作、范围、理由和结果。
+
+交互规则：
+
+- 不允许只弹一句 `确定吗？`。
+- 危险动作必须和普通查看、编辑、保存、提交等动作视觉分离。
+- 低风险确认可以用轻量弹窗；高风险、批量、财务和配置动作使用更明确的确认面板。
+- 确认失败要显示失败明细和可修复下一步，不清空用户输入。
+- 移动端危险动作进入底部或全屏确认面板，不能靠误触即可执行。
+
+## 1.12 全系统集成和外部系统边界规则
+
+外部系统状态必须保守表达。OA 只能展示自己确认的业务事实和外部系统明确返回的结果，不能把异步请求、排队、消息发送尝试或前端按钮点击表达成最终业务完成。
+
+主办边界：
+
+- OA 主办：报销、采购、合同、项目、付款、AP、票据、资产、高敏附件、审计和 OA 内审批处理。
+- 企业微信主办：打卡、请假、补卡、外出、加班等 HR/考勤日常动作；OA 只展示镜像、历史、异常、审计和应急接管。
+- ERP/代账/银行/OCR/企业微信消息是外部能力或触达渠道，不替代 OA 自身状态机和服务端权限校验。
+
+状态表达：
+
+- 只有收到外部系统明确成功回执，才显示 `已同步`、`已发送`、`已付款`、`识别完成` 等最终状态。
+- 请求已发出但未确认时，使用 `同步中`、`等待回执`、`银行处理中`、`识别中`、`消息发送中`。
+- 外部系统失败时，显示失败来源、影响范围、下一步和可重试动作，例如 `银行回执未返回`、`OCR 识别失败，需重新上传 PDF`。
+- 不用外部系统内部错误码、原始 payload、完整 URL 或调试 trace 作为普通用户文案。
+
+动作和重试：
+
+- 外部写入、付款执行、同步 ERP、重发企业微信消息、重试 OCR 等动作必须按权限和状态矩阵控制。
+- 重试动作要说明会重试哪个对象、是否可能重复发送、是否影响外部系统和审计。
+- 外部同步状态不应阻塞无关主流程；如果会阻塞，必须明确阻断原因和人工处理方式。
+- 管理员/财务可在授权页面查看更多排障信息，普通路径只给摘要、失败原因和下一步。
+
+页面边界：
+
+- HR/考勤页面默认表达为企业微信记录、同步镜像或异常处理，不出现 OA 日常请假/补卡主路径，除非管理员开启 OA 应急接管。
+- 企业微信消息只发脱敏摘要和 OA deeplink，不承载附件原文、高敏合同正文和真实付款操作。
+- 银行、ERP、代账等外部系统未接入或未确认的能力，页面不能用完成态文案伪装已经可用。
+
+## 1.13 全系统试运行和验收证据规则
+
+验证结果必须准确描述验证层级。本地通过不等于线上可测，截图通过不等于业务已部署，模拟数据通过不等于真实试运行通过。
+
+验证口径：
+
+- 本地构建通过：只能说明本地代码可构建。
+- Playwright/mock 通过：只能说明自动化路径在指定环境通过。
+- 截图/视觉复核通过：只能说明指定视口和数据状态下视觉符合预期。
+- 部署通过：必须说明部署环境、版本或提交、健康检查结果。
+- 公网可测：必须完成部署、公网访问检查、关键路径冒烟和必要截图证据后才能告知。
+
+对外表述：
+
+- 未部署时，只能说 `本地验证通过，尚未线上可测`。
+- 部署但未公网检查时，只能说 `已部署，公网检查未完成`。
+- 公网检查通过后，才可以说 `可以线上测试`，并说明测试入口和已覆盖关键路径。
+- 真机或企业微信 WebView 未验证时，必须标记为暂缓人工验证，不用自动化通过替代。
+
+证据要求：
+
+- A 类页面改动需要保留构建、关键 Playwright 或截图证据。
+- 涉及权限、状态机、审批、付款、企业微信、外部系统、敏感下载和生产配置时，需要补充回滚或人工处理说明。
+- 规则文档更新本身不代表页面已整改、不代表已部署、不代表真实试运行 Go/No-Go。
+
+## 1.14 行业惯例决策清单
+
+以下事项需要在系统后续重构前提前拍板。每一项都影响多个页面，不能让单个页面临时决定。
+
+| 序号 | 决策项 | 为什么要提前定 | 当前建议 |
+| --- | --- | --- | --- |
+| 1 | 信息架构和一级入口 | 决定侧边栏、工作台、移动首页和权限显隐 | 已确认：任务优先；已启用且有权限的合同、采购、资产、项目直接显示；低频/冻结入口进“更多”，配置进“管理” |
+| 2 | 页面模板分类 | 决定页面是列表、台账、详情、主从工作台还是配置页 | 已确认：固定使用工作台总览、任务处理列表、业务台账列表、主从工作台、详情工作区、管理配置页六类模板 |
+| 3 | 操作区坐标 | 决定主动作、筛选、行操作、危险动作放哪里 | 已确认：页头右侧放主动作，命令栏放筛选/工具，行尾放行级动作，右侧命令区放详情高风险动作，移动底部放主动作 |
+| 4 | 状态和动作生命周期 | 决定草稿、审批中、已通过、已支付、取消、作废、归档、异常等动作显隐 | 已确认：每个业务对象必须先列状态矩阵，再决定按钮、禁用原因、确认方式和审计要求；审批动作集中在待我处理/审批详情；删除只用于草稿/未生效临时对象，撤回/取消/作废/归档分别表达不同业务结果 |
+| 5 | 角色和数据范围 | 决定普通员工、审批人、财务、管理员看到什么 | 已确认：服务端权限为准，前端按当前任务角色收敛展示；多岗用户不默认展开所有范围和高级工具 |
+| 6 | 编号和信息语义 | 决定业务编号、内部 id、状态文案、时间文案、权限/空态/异常文案 | 已确认：普通页面主标识使用业务编号和自然中文；权限不足、空状态和异常状态说明原因和下一步；内部编号和技术信息只在授权审计/排障/留痕场景最小展示 |
+| 7 | 列表和台账行为 | 决定搜索、筛选、分页、排序、导出、批量处理 | 已确认：默认 3 到 5 个高频筛选；导出/批量/统计/模板/全范围/高级筛选进台账工具或更多；批量只在选中后出现 |
+| 8 | 表单和草稿 | 决定保存、提交、校验、离开保护、错误提示 | 已确认：长表单支持草稿；保存草稿和提交分离；提交前业务校验和摘要确认；错误定位到字段/材料区 |
+| 9 | 详情页证据结构 | 决定摘要、明细、附件、审批历史、审计放哪里 | 已确认：状态与下一步先行，业务摘要其次，证据材料居中，历史靠后，动作面板在 PC 右侧或移动端底部；列表只显示证据完整性摘要和缺失提示，证据预览/下载/删除/批量打包进入详情或授权工具 |
+| 10 | 移动端规则 | 决定 WebView、底部动作、卡片列表、键盘和安全区 | 已确认：移动端只做提交、补材料、查状态、处理待办、扫码/上传和消息直达；不承接全范围管理、批量导出、流程配置、管理配置、复杂筛选和大表格，不复制 PC 管理台 |
+| 11 | 通知和待办关系 | 决定通知中心是否复制待办、消息跳哪里 | 已确认：待我是行动列表，通知中心是事件收件箱；通知直达业务详情/审批任务/失败解释页，不复制待办 |
+| 12 | 敏感数据和导出下载 | 决定附件、合同、票据、资产元数据和财务资料展示 | 已确认：默认最小展示；预览/下载/导出/批量下载按权限控制并审计；普通列表和移动端只展示摘要 |
+| 13 | 确认和危险动作 | 决定删除、付款、发布、驳回、切换配置如何确认 | 已确认：不可逆/财务/审批/配置/批量动作必须二次确认，显示对象摘要、后果、影响范围和必要理由/确认输入 |
+| 14 | 集成和外部系统边界 | 决定企微、ERP、银行、代账、OCR 的失败和重试口径 | 已确认：OA 主办高敏业务，企微主办 HR/考勤；外部系统只展示真实回执、失败原因和下一步，不虚假承诺 |
+| 15 | 试运行和验收证据 | 决定什么时候能说页面可测试、如何截图验证 | 已确认：本地构建/Playwright/截图只代表本地验证；部署、公网检查、关键路径冒烟和必要截图后才能告知线上可测 |
+| 16 | 固定资产管理口径 | 决定资产页是轻量责任台账还是复杂财务固定资产账 | 已确认：OA 中 `FA` 只做实物责任、流转、盘点和离职交接；折旧、残值、会计科目和月度折旧凭证暂不进 OA 主路径 |
+| 17 | 采购/报销到资产衔接 | 决定审批通过或报销完成后是否自动生成资产 | 已确认：采购/报销只提供资产候选线索；到货/验收后管理员手动建 `FA` 卡片，不自动从单据生成资产 |
+| 18 | 固定资产编号和标签 | 决定盘点、扫码和实物识别方式 | 已确认：所有 `FA` 必须有资产编号；能贴就贴二维码标签；不能贴时记录序列号、保管人和位置，扫码优先、手工输入兜底 |
+| 19 | 固定资产盘点频率 | 决定盘点是否常态化、何时触发临时确认 | 已确认：默认季度轻盘点；离职/调拨/维修/报废做事件盘点；备份硬盘、安全介质、关键设备月度确认责任人和位置 |
+| 20 | 固定资产处置规则 | 决定领用归还调拨和报废丢失出售赠送如何留痕 | 已确认：领用/归还/调拨由管理员记录留痕；报废/丢失/出售/赠送必须负责人确认和填写原因；赔偿、金额或责任争议另走审批或线下确认 |
+| 21 | 电子资产管理边界 | 决定代码仓库、系统、备份资产是否进入 OA 以及展示什么 | 已确认：OA 只登记元数据、负责人、权限回收要求、备份/恢复验证日期和归档位置摘要；不保存源码包、密钥、token、完整配置、真实完整路径或备份内容 |
+| 22 | 电子资料资产边界 | 决定 `EA-DOC` 是否保存业务原文和高敏资料 | 已确认：只登记资料名称、类型、hash/校验摘要、敏感级别、负责人、业务关联和归档位置摘要；高敏原文走业务附件权限或线下受控归档，不进普通资产页 |
+| 23 | 资产管理规则组收口 | 决定本轮是否继续扩展资产细节 | 已确认：资产规则组到此收口，后续资产页面整改按本任务和资产规约执行；下一组转入合同、采购、项目和财务台账 |
+| 24 | 台账与详情边界 | 决定合同/采购/项目/财务台账在哪里查找、在哪里执行高风险动作 | 已确认：列表只查找筛选看状态和进入详情；合同下载、归档、付款、导出、批量处理、作废、敏感附件查看等进入详情/详情命令区/台账工具并二次确认 |
+| 25 | 台账默认视角 | 决定多角色用户进入合同/采购/项目/财务台账后先看到什么 | 已确认：普通员工看我发起/我相关，负责人看我负责/项目相关，财务看待复核/待付款/异常，管理员才默认或可切换全范围；全范围/导出/批量进台账工具 |
+| 26 | 合同台账边界 | 决定合同页是轻量归档台账还是完整 CLM | 已确认：V1 只做登记、归档、到期/续签提醒和关联项目/采购/付款；不做电子签、复杂法务审查、条款库、版本协同或完整 CLM；审批若需要走统一审批中心或另建任务 |
+| 27 | 采购台账边界 | 决定采购页是轻量申请审批还是采购 ERP | 已确认：V1 只做申请、审批、附件、轻量验收/归档和关联项目/合同/付款；不做采购订单全生命周期、库存、三单匹配、供应商生命周期、招采评标或 ERP 入账 |
+| 28 | 项目模块边界 | 决定项目页是业务归集台账还是完整 PM 系统 | 已确认：V1 只做项目状态、负责人/成员、里程碑/任务、风险、交付记录和关联业务摘要；不做甘特图、复杂任务依赖、工时、资源排期、OKR、项目组合管理或大型协同平台 |
+| 29 | 财务台账边界 | 决定付款/AP/票据是 OA 留痕台账还是完整财务软件 | 已确认：V1 只做付款准备、付款批次、回单留痕、AP 状态、票据/OCR 状态和代账交接摘要；不做银行直连真实支付、银行流水自动导入、ERP/总账、凭证生成、自动对账或税务申报 |
+| 30 | 个人设置与管理配置边界 | 决定个人资料页是否承载用户/组织/权限维护 | 已确认：个人设置只放个人资料、密码/安全、通知偏好和企微绑定；组织、角色、审批规则、功能开关、主数据、审计日志、人员维护和系统配置统一进管理 |
+| 31 | 多角色视角规则 | 决定是否需要全局身份切换器 | 已确认：不做全局身份切换器；页面按当前任务自动收敛视角，跨范围查看只在具体台账内提供授权范围切换 |
+| 32 | 材料类型先行 | 决定上传入口、校验、权限、审计和证据展示 | 已确认：上传前先选材料类型；PDF 发票、普通附件、合同文件、付款回单、验收材料、资产材料和电子资料索引不混用万能上传入口 |
+| 33 | 删除/撤回/取消/作废/归档语义 | 决定高风险动作命名、状态流转和审计 | 已确认：草稿才删除；审批中可撤回；业务不执行用取消；已生效对象失效用作废；完成留存用归档；已提交对象原则上不物理删除 |
+| 34 | 审批动作承接位置 | 决定通过、驳回、退回、转审在哪里执行 | 已确认：审批动作只在待我处理/审批详情或明确任务处理面板执行；业务台账和普通详情只给查看处理、查看进度、补材料或进入审批任务入口 |
+| 35 | 付款动作承接位置 | 决定标记已付款、取消付款、批量付款在哪里执行 | 已确认：付款动作只在付款/财务处理详情或明确财务任务面板执行；业务台账和普通详情只显示付款状态、回单状态、查看付款、补回单或进入付款记录入口 |
+| 36 | 跨模块关联边界 | 决定项目/采购/合同/报销/资产/付款互相关联时展示什么、在哪里处理 | 已确认：关联区只展示摘要和跳转；审批、付款、发票/OCR、合同正文下载、高敏附件和资产处置等动作回到归属模块详情/任务/财务处理页执行 |
+
+## 2. 页面分级
+
+页面分级判断优先级，页面模板判断布局骨架。后续任何页面改造都先回答两个问题：它是 A/B/C 哪类优先级？它套用下面哪一种模板？
+
+## 2.0 已确认页面模板分类
+
+| 模板 | 适用页面 | 布局骨架 | 不允许 |
+| --- | --- | --- | --- |
+| 工作台总览 | `/portal`、`/mobile` | 紧凑摘要 + 今日待处理 + 条件出现的进度/卡点/提醒 | 不放完整列表、模块大全、常驻教学 |
+| 任务处理列表 | `/workflow/tasks`、`/mobile/approvals` | 待处理摘要 + 任务列表 + 已处理/筛选高级区 | 不默认快批高风险事项，不复制业务台账 |
+| 业务台账列表 | 报销、合同、采购、项目、付款、AP、票据等 | 页头主动作 + 命令栏 + 列表/表格 + 台账工具 | 不把导出/批量/统计/高风险处理放成首屏主动作 |
+| 主从工作台 | 资产、盘点、需要同屏编辑的过渡态采购等 | 左侧列表/索引，右侧当前对象详情和动作 | 左侧不放高风险动作；不要让配置表单压过业务对象 |
+| 详情工作区 | 报销详情、审批详情、项目详情、未来合同详情 | 顶部概览 + 左侧事实证据 + 右侧摘要/命令 + 历史 | 不把所有信息铺满首屏，不重复主动作 |
+| 管理配置页 | 人员、组织、主数据、审批规则、流程定义、功能开关、审计等 | 分组/表格/搜索/编辑，发布停用删除需确认 | 不进入普通用户路径，不和个人设置混用 |
+
+模板使用规则：
+
+- 一个页面只能有一个主模板；可有局部子模板，但不能混成“台账 + 配置 + 详情 + 大屏”。
+- 移动端不单独算第七类模板；移动端是上述模板的移动表达，统一变为顶部状态、卡片列表/分区详情、底部主动作。
+- B 类业务页面优先在 `业务台账列表` 和 `主从工作台` 二选一。能独立打开详情的用台账列表；需要一边选对象一边编辑/处理的用主从工作台。
+- A 类核心页面不得退化为管理配置页；C 类配置页面不得伪装成普通业务入口。
+
+## 2.1 台账与详情边界
+
+合同、采购、项目和财务台账默认采用“列表查找、详情处理”的边界。列表页负责让用户找到对象、理解状态和进入详情；详情页负责核对事实、证据、风险和执行动作。当前采购页面如果仍是双栏主从结构，后续整改也应按同一边界收敛：列表/左栏不直接承载高风险处理，处理动作进入当前对象详情或明确的待办详情。
+
+通用规则：
+
+- 列表页只保留搜索、状态、范围、时间和少量高频业务筛选；不要把附件、发票、合同文件、回单、资产材料、审批、付款、归档、作废、导出、批量等能力铺成列表首屏按钮。
+- 列表行默认动作为 `查看详情`、`查看处理`、`继续完善` 或 `查看进度`；普通列表行只显示证据完整性摘要和缺失提示，不直接执行发票预览、合同下载、回单下载、付款、归档、作废、批量处理、敏感附件查看、附件删除或批量打包。
+- 详情页第一屏展示状态、下一步、业务摘要、证据完整性和风险提示；详情命令区承载归档、付款、作废、下载、敏感查看等需要核对上下文的动作。
+- 台账工具承载全范围、高级筛选、导出、批量、统计、模板、归档检查和低频外部同步；导出和批量处理必须说明范围、敏感内容和失败结果。
+- 高风险动作必须二次确认，展示对象摘要、影响范围、后果和必要理由/确认输入；财务、合同、票据和附件类操作必须按权限和审计执行。
+- 移动端只保留搜索、状态卡片、查看详情和必要轻动作，不承接复杂台账工具、批量导出、全范围管理、管理配置或宽表操作。
+
+跨模块关联边界：
+
+- 关联区只展示对方模块的摘要：业务编号/名称、状态、金额或数量、负责人、证据完整性、最近更新时间和下一步。
+- 关联区的动作只允许 `查看详情`、`查看进度`、`进入审批任务`、`查看付款`、`补材料` 等跳转或补充入口；真正的审批、付款、发票处理、合同正文下载、附件删除、资产处置等动作回到归属模块执行。
+- 项目页可以汇总报销、采购、合同、付款和交付摘要，但不在项目页直接审批采购、标记付款、处理发票/OCR、下载合同正文或修改资产卡片。
+- 采购、合同、报销、资产之间互相关联时同理：当前页面只提供上下文，不复制对方模块的表单、状态机、批量工具和高敏附件操作。
+- 无权限查看关联对象时，优先隐藏高敏字段或显示脱敏摘要和原因；不能因为出现在关联区就绕过原模块的服务端权限。
+
+默认视角：
+
+- 普通员工进入合同、采购、项目和财务相关台账时，默认看 `我发起`、`我相关` 或 `需要我补充`，不默认看公司全量。
+- 负责人/项目负责人默认看 `我负责`、`我参与`、`项目相关` 和有风险/卡点的对象。
+- 财务/出纳默认看 `待复核`、`待付款`、`待补回单`、`异常` 和授权范围内的财务处理对象。
+- 管理员默认在管理或台账工具内看 `全范围`，普通台账入口不因管理员权限而把全量、导出、批量铺在首屏。
+- 同一用户一人多岗时可以在具体台账内切换授权范围，但不提供全局身份切换器；页面首屏必须先按当前页面主任务收敛，不把员工、负责人、财务、管理员四种工作混成一个默认视图。
+
+### A 类核心流程
+
+页面：登录、找回密码、修改密码、工作台、待我处理、审批详情、报销列表、报销详情、移动首页、移动审批、移动报销、通知中心。
+
+规则：
+
+- 首屏必须回答“有没有事要办、下一步是什么、风险在哪里”。
+- 默认隐藏统计、历史、导出、批量、模板、配置。
+- 空态必须给出可执行下一步，不放教程型长文案。
+- 每次改动必须做前端构建和针对性 Playwright/截图验证。
+
+### B 类业务运营
+
+页面：票据、付款、应付账款、采购、项目、项目详情、合同台账、资产、盘点、请假记录、考勤、企微审批历史、周报、团队、公告、预算、差旅、代办/轻协同。
+
+规则：
+
+- 默认视图优先台账/当前处理，而不是全量管理控制台。
+- 低频筛选、导出、批量、统计进入“台账工具”“更多”“高级筛选”。
+- 对员工不常用或冻结能力，用只读边界、历史视图或隐藏入口处理。
+- HR/考勤相关页面要显式表达企微主办，OA 只镜像/历史/异常/应急。
+
+### C 类管理配置
+
+页面：管理、工作区设置、人员、人员详情、人员统计、组织、用户、部门、主数据、审批规则、流程定义、费用标准、通知渠道、外部系统、功能管理、切换控制台、审计日志、委托、工资、绩效、数据看板。
+
+规则：
+
+- 默认在“管理”聚合页下承接，不直接占普通侧边栏。
+- 信息密度可以高，但要用统一表格、分组、搜索和状态提示。
+- 危险操作必须二次确认；配置变更要有可回滚或可审计提示。
+- 管理页可以展示内部编号，但只在排障/审计区域展示，不能变成普通主标识。
+
+## 2.2 页面覆盖索引
+
+本索引用来保证后续审查和整改不会只看工作台、报销和审批，而漏掉采购、合同、项目、资产、财务、管理和移动端。
+
+| 页面族 | 当前路由 | 页面定位 | 默认建议 |
+| --- | --- | --- | --- |
+| 认证入口 | `/login`、`/forgot-password`、`/change-password` | 登录与账号恢复 | A 类，稳定表单，不做营销页 |
+| 工作台 | `/portal` | 今天要办什么 | A 类，今日待处理优先 |
+| 审批 | `/workflow/tasks`、`/workflow/tasks/:taskId` | OA 主办审批处理 | A 类，列表看任务，详情做动作 |
+| 报销 | `/reimbursements`、`/reimbursements/:id`、`/reimbursements/:id/print`、`/reimbursements/dashboard` | 员工报销与财务台账 | A 类主链路，统计/打印为低频入口 |
+| 付款 | `/payment-batches` | 批次、回单、付款执行 | B 类财务运营，异常和待执行优先 |
+| 应付账款 | `/ap-operations` | AP、代账交接、导出 | B 类财务台账，不使用内部英文名 |
+| 票据 | `/invoice-pool` | PDF 发票状态与归档 | B 类财务/票据运营，员工侧从报销详情进入 |
+| 采购 | `/purchase-requests` | 采购申请、附件、审批 | B 类业务流程，需独立任务化整改 |
+| 差旅 | `/travel-requests` | 历史/兼容低频入口 | B 类低频/冻结，不恢复主线 |
+| 项目 | `/projects`、`/projects/:projectId` | 轻项目管理 | B 类轻管理，不做项目管理大平台 |
+| 合同 | `/contracts-registry` | 合同台账和附件归档 | B 类台账，正文/敏感附件按权限和审计 |
+| 资产管理 | `/assets`、`/inventory-checks`、`/mobile/assets/scan` | 固定资产、电子资产、分类、盘点、扫码 | B 类台账，敏感字段脱敏，操作区需独立统一 |
+| HR/考勤镜像 | `/leave-requests`、`/attendance`、`/wecom-approval-archive` | 企微主办记录、镜像、异常 | B 类镜像/历史，不做 OA 日常提交 |
+| 协同轻页面 | `/announcements`、`/team`、`/weekly-reports`、`/todos` | 公告、团队状态、周报、轻待办 | B 类辅助，不抢首页主流程 |
+| 个人设置 | `/settings/profile` | 个人资料、密码/安全、通知偏好、企微绑定 | A/B 边界页，不能做成用户管理页 |
+| 管理聚合 | `/system/settings` | 低频配置入口 | C 类统一入口 |
+| 人员组织 | `/people`、`/people/:employeeId`、`/people/stats`、`/organization`、`/system/users`、`/system/departments` | 员工、账号、组织 | C 类管理配置 |
+| 基础配置 | `/system/master-data`、`/system/expense-standards` | 主数据和费用标准 | C 类配置 |
+| 审批配置 | `/system/approval-rules`、`/system/workflow-definitions` | 规则和流程版本 | C 类配置，避免复杂 BPM |
+| 系统配置 | `/system/workspace`、`/system/feature-flags`、`/system/notification-channels`、`/system/integrations/erp`、`/system/cutover` | 工作区、开关、通知、集成、切换 | C 类运维管理 |
+| 其他管理 | `/audit-logs`、`/delegations`、`/payroll`、`/performance`、`/budgets`、`/dashboard` | 审计、委托、工资、绩效、预算、数据看板 | C/B 低频，默认不进普通路径 |
+| 移动首页 | `/mobile` | 手机入口 | A 类移动入口 |
+| 移动审批 | `/mobile/approvals`、`/mobile/approvals/:taskId` | 手机待办与详情 | A 类移动审批 |
+| 移动报销 | `/mobile/reimbursements`、`/mobile/reimbursements/:id`、`/mobile/capture` | 手机报销、PDF 发票上传 | A 类移动报销 |
+| 移动 HR/考勤 | `/mobile/leave`、`/mobile/leave/:id`、`/mobile/wecom-approval-archive` | 企微主办记录查看 | B 类移动镜像 |
+| 移动业务 | `/mobile/purchase-requests`、`/mobile/purchase-requests/:id`、`/mobile/assets/scan` | 采购和资产扫描 | B 类移动业务 |
+| 移动账号通知 | `/mobile/me`、`/mobile/profile`、`/mobile/notifications` | 我的、资料、通知 | A/B 边界页 |
+| 异常页 | `/403`、`*` | 无权限/不存在 | 通用异常，不暴露内部细节 |
+
+## 3. 页面布局模板
+
+### 3.1 工作台 `/portal`
+
+目标：让用户 5 秒内知道今天要处理什么。
+
+布局：
+
+- 顶部紧凑摘要：今天待处理、进度更新、团队/管理提醒；有最急事项时给一个主按钮。
+- 主区固定为“今日待处理”，每行包含事项、为什么找我、状态/时间、一个动作。
+- 次区条件展示“我的进度”“团队卡点”“管理提醒”，没有真实数据就不显示。
+- 首次欢迎只允许一次性可关闭弹窗，最多 3 个真实业务入口。
+
+不要：
+
+- 不放常驻快速上手清单。
+- 不放“了解流程”“设置通知偏好”“查看通知消息”这类说明型入口。
+- 不把报销进度、公告、试运行观测做固定模块。
+- 不展示纯统计卡片凑版面。
+
+现状判断：当前方向基本正确，后续重点是保证 `今日待处理` 的数据质量和行动语义，避免再次塞入口集合。
+
+### 3.2 审批列表 `/workflow/tasks`
+
+目标：审批人先看待处理，再进入详情核对依据。
+
+布局：
+
+- 标题使用“待我处理”。
+- 首屏用紧凑摘要展示待处理总数、最早等待、超时、业务分布。
+- 默认列表是任务列表式信息结构：事项、申请人/金额或天数、当前节点、等待时间、业务编号。
+- 默认主按钮是“查看处理”；历史入口叫“已处理记录”。
+- 复杂筛选、已处理/历史、业务类型筛选进入高级区。
+
+不要：
+
+- 不在列表层默认给“通过”。
+- 不对请假、补卡、外出、加班等企微主办 HR/考勤事项给 OA 快批。
+- 不把更新时间当成用户能理解的等待时间。
+
+现状判断：近期整改方向正确，后续要把 HR/考勤镜像数据和 OA 主办任务在视觉上继续区分。
+
+### 3.3 审批详情 `/workflow/tasks/:taskId`
+
+目标：审批动作前先核对业务摘要、证据和后果。
+
+布局：
+
+- 顶部概览：任务名、业务状态、业务类型、返回待办。
+- 主区第一块：当前状态与审批对象，突出下一步和可执行动作。
+- 主区第二块：业务摘要，按报销/采购/合同/项目等领域展示关键字段。
+- 主区第三块：审批动作，按通过、驳回、退回、转审分组；高风险动作二次确认。
+- 右侧：任务摘要、节点、角色、创建/完成时间、下一步说明。
+- 历史记录在主区下方，不抢首屏。
+
+不要：
+
+- 不把动作按钮放在看不到摘要的位置。
+- 不允许驳回/退回无理由提交。
+- 不让业务台账或普通详情复制审批按钮；从业务对象进入时也必须落到同一审批详情处理。
+- 不展示业务无关的技术字段。
+
+### 3.4 报销列表 `/reimbursements`
+
+目标：员工默认管理自己的报销，财务工具不压住普通路径。
+
+布局：
+
+- 默认标题“我的报销”，即使用户同时有财务/审批权限也先看自己的单据。
+- 顶部保留三张任务卡：被驳回待补正、草稿待完善、审批中进度。
+- 主按钮“新建报销”。
+- 状态 tabs 用草稿、被驳回、审批中、已通过、已支付、已取消。
+- 财务/管理员能力通过“台账工具”展开：全范围、审批中台账、统计分析、导出、批量处理、代填、模板、关联差旅。
+- 行文案区分“待你处理”和“当前节点”。
+
+不要：
+
+- 不默认进入全范围台账。
+- 不把批量审批、导出、模板、差旅关联放在普通首屏。
+- 不展示 `taskId`、UUID 或内部状态码。
+
+现状判断：近期整改方向正确；下一步应统一报销列表和付款/AP/票据的台账工具模式。
+
+### 3.5 报销详情 `/reimbursements/:id`
+
+目标：让申请人知道还能不能改、审批人/财务知道依据是否完整。
+
+布局：
+
+- 顶部 `EntityOverviewHero`：业务编号、状态、报销日期、报销人、提交人、金额、首屏动作。
+- 主区两列：左侧业务内容，右侧审批/付款/动作摘要。
+- 第一块固定“当前状态与下一步”：下一步、处理人、金额、材料完整性、阻断/预警。
+- 第二块“明细与发票”：明细先于发票；发票入口明确“仅支持 PDF 发票”。
+- 第三块“预算与审核提示”：只在有预算/风险/AI 辅助可用时显示。
+- 附件作为补充材料，和发票分开；敏感附件下载需要用途。
+- 更多入口承载打印/PDF、返回列表、删除草稿、关联项目、财务导出等低频内容。
+- 审批进度默认可见；完整审批记录可放更多或右侧。
+
+不要：
+
+- 不把全部详情默认铺满首屏。
+- 不把“添加发票”和“上传附件”混成一个入口。
+- 不在普通视图暴露 OCR provider、绑定整单、不绑定明细等内部词。
+- 不允许已通过/已支付普通用户删除。
+
+现状判断：页面信息较完整，但仍偏重。后续可把“更多详情”进一步结构化为可折叠低频区，并减少首屏之外的重复付款状态展示。
+
+### 3.6 报销打印 `/reimbursements/:id/print`
+
+目标：留痕和线下归档，不承担编辑。
+
+布局：
+
+- A4/打印友好结构：单号、申请人、金额、明细、发票摘要、附件清单、审批记录、付款状态。
+- 不显示编辑按钮、删除按钮、复杂筛选、动态 toast。
+- 内部编号只在审计需要时展示，默认使用业务编号。
+
+### 3.7 报销统计 `/reimbursements/dashboard`
+
+目标：财务/负责人回看，不是员工默认入口。
+
+布局：
+
+- 通过报销列表的“台账工具/统计分析”进入。
+- 默认展示时间范围、状态分布、金额趋势、异常/未付摘要。
+- 导出和明细钻取保留，但不能替代报销列表。
+
+### 3.8 付款 `/payment-batches`
+
+目标：出纳/财务处理付款准备、付款批次、线下银行付款后的回单留痕和异常跟进。付款页不是银行直连支付系统，不做真实支付、银行流水自动导入、自动对账、ERP/总账或凭证生成。
+
+布局：
+
+- 顶部突出待复核、待补回单、待执行、失败/异常。
+- 主区按批次任务列表展示：批次号、金额、单据数、付款状态、回单状态、当前动作。
+- `登记付款` 或 `标记已付款` 必须在证据要求满足后出现；如页面保留 `执行付款` 文案，必须明确是线下付款后的 OA 留痕，不是系统直接支付。
+- 付款动作只在付款/财务处理详情或付款批次详情执行；报销、采购、合同、项目等业务页只跳转查看付款或补回单。
+- 导出、历史、批量下载、筛选进入台账工具。
+
+不要：
+
+- 不表达为银行直连或真实支付自动执行，除非后续任务明确实现。
+- 不在报销、采购、合同、项目列表或普通详情里直接放 `标记已付款`、`取消付款`、`批量付款`。
+- 不把 AP、报销、付款三个概念混在同一个首屏。
+- 不展示银行流水自动导入、自动对账、总账或凭证生成作为默认能力。
+
+### 3.9 应付账款 `/ap-operations`
+
+目标：财务核对 AP 状态、付款关联、回单材料和代账交接摘要。
+
+布局：
+
+- 默认是台账视图：待付款、已付款、异常、待导出。
+- 首屏指标只保留与处理相关的数：待复核、待付款、异常、导出状态。
+- 筛选、导出、代账交接摘要和低频核对工具进入工具区。
+
+不要：
+
+- 不使用 `AP 运营` 作为用户文案。
+- 不把 ERP 同步作为默认主流程；无 ERP 时只表达代账交接。
+- 不把 AP 页做成总账、凭证生成、自动对账或完整财务软件。
+
+### 3.10 票据 `/invoice-pool`
+
+目标：财务/员工理解票据/OCR 状态，员工侧主要从报销详情补材料。票据页不做税务申报、自动验真、完整电子档案系统或财务软件入口。
+
+布局：
+
+- 财务/管理员看到票据池：识别中、可添加、已添加、识别失败、已归档/已报销。
+- 员工普通路径不把票据池作为主导航，优先从报销详情“添加发票”进入。
+- 上传入口明确 PDF-only；失败、重复、已使用必须可解释。
+
+不要：
+
+- 不展示 OCR provider、绑定策略、内部处理状态。
+- 不恢复图片发票 OCR 为正式路径。
+- 不把票据池做成税务申报、银行付款或 ERP/总账入口。
+
+### 3.11 采购 `/purchase-requests`
+
+目标：小团队采购申请、审批、附件证据、轻量验收/归档，以及关联项目、合同和付款/AP。采购页不是采购 ERP，不做采购订单全生命周期、库存、三单匹配、供应商生命周期、招采评标或 ERP 入账；审批通过也不代表已付款、已入库或已形成固定资产。
+
+推荐信息架构：
+
+- 页面标题：`采购申请`，副标题不用解释流程，只在异常/空态说明下一步。
+- 顶部任务区：草稿待完善、审批中、被退回/待补材料、待归档或待关联合同。
+- 主按钮：`新建采购`；如果已有草稿，任务卡优先引导“继续完善”。
+- 默认视角：普通用户看自己的采购；负责人/财务/管理员有权限时可进入台账工具。
+- 台账工具：全范围、供应商/项目/状态筛选、导出、归档检查、外部回执状态和低频关联工具都放这里。
+
+列表规则：
+
+- PC 列表展示：采购单号、标题、申请人、项目、供应商、金额、状态、当前节点/下一步。
+- 移动列表展示：采购单号、标题、金额、状态、申请人或项目，不显示宽表。
+- 空态按状态拆文案：没有草稿、没有审批中、没有被退回，分别说明。
+- 不把法体、成本中心、单据分类等管理字段作为普通首屏筛选；它们可以在高级筛选或详情中出现。
+
+详情规则：
+
+- 第一屏固定展示：当前状态、下一步、采购金额、供应商、项目、附件完整性、审批节点。
+- 明细/附件/供应商/预算或费用标准分区展示，顺序优先服务“能不能提交、能不能审批”。
+- 采购明细里的 `资产候选` 只表示后续可能需要登记资产，不等于已经入库、已形成固定资产或已完成验收。
+- 保存草稿、提交审批是普通用户主动作；通过、驳回、退回应通过审批详情或明确的待处理入口完成。
+- 采购台账列表和普通采购详情不直接给通过、驳回、退回；需要处理时进入当前审批任务详情。
+- 采购附件按合同、报价、订单/确认材料、验收、付款证明等类型表达；这些是证据材料，不代表 OA 已实现采购订单生命周期。
+- 关联合同、归档、导出、外部同步、复制申请放在“更多”或台账工具。
+
+现状判断：
+
+- 当前页面是左列表 + 右详情的工作台式结构，可以保留，但视觉和信息顺序仍偏“后台表单 + 筛选器”。
+- 下一轮整改应把采购改成“采购任务卡 + 采购列表 + 状态/证据/动作详情”，对齐报销详情的判断顺序。
+
+不要：
+
+- 不在普通首屏堆满法体、成本中心、单据分类等低频筛选。
+- 不把采购与差旅、合同、付款混成一个万能申请台。
+- 不把 ERP 跟踪、批量导出、复杂归档作为默认员工路径。
+- 不在采购页直接承诺合同审批、付款执行或银行支付。
+- 不把采购页做成完整采购订单、库存、三单匹配或供应商生命周期管理系统。
+
+### 3.12 差旅 `/travel-requests`
+
+目标：当前不作为主线扩展，只保留历史/低频兼容入口。
+
+布局：
+
+- 默认不进入主导航高频区，放在“更多”或仅按权限直达。
+- 若页面保留，首屏应表达当前状态和边界：差旅不是现阶段主流程，报销可按普通报销处理或按已有兼容数据关联。
+- 列表只展示历史/兼容申请：申请编号、申请人、目的、日期、预估金额、状态。
+- 不新增复杂差旅预订、行程、补贴、酒店/机票和差旅政策配置。
+
+不要：
+
+- 不把差旅恢复成工作台常用入口。
+- 不让报销主流程依赖差旅申请。
+
+### 3.13 项目 `/projects` 与项目详情 `/projects/:projectId`
+
+目标：轻项目台账，只服务小团队项目状态、负责人/成员、里程碑/任务、风险、交付记录和关联报销/采购/合同/付款。项目页不是完整项目管理软件，不做甘特图、复杂任务依赖、工时、资源排期、OKR、项目组合管理或大型协同平台。
+
+列表布局：
+
+- 默认展示我负责/我参与的项目，优先进行中和有风险项目。
+- 首屏指标：进行中、逾期里程碑、未关闭风险、今日跟进。
+- 列表展示项目号、名称、负责人、状态、下一里程碑、风险数、最近更新。
+
+详情布局：
+
+- 顶部展示项目状态、负责人、下一步、风险/里程碑摘要。
+- 主区按里程碑、任务/跟进、风险、交付记录、关联报销/采购/合同/付款分区。
+- 低频配置、项目成员、归档、导出进入更多。
+
+不要：
+
+- 不做大型项目管理软件。
+- 不把项目页面做成泛报表大屏。
+- 不把项目页做成 OKR、工时、资源排期或大型协同平台。
+
+### 3.14 合同台账 `/contracts-registry`
+
+目标：合同登记、附件归档、到期/续签提醒，以及关联项目、采购和付款。合同页不是完整合同生命周期管理系统，不自建电子签、复杂法务审查、条款库、版本协同或 CLM 流程；如需合同审批，使用 OA 统一审批中心或另建后续 Trellis task。
+
+推荐信息架构：
+
+- 页面标题：`合同台账`。
+- 顶部任务区：待补附件、即将到期、待归档、关联项目/采购缺失、敏感下载待审计。
+- 默认视图：我负责/我可见的合同；管理和财务角色可进入全范围台账。
+- 主按钮：按当前能力决定是否展示 `新增合同`；如果当前只做台账登记，则不要写成“发起合同审批”。
+- 工具区：全范围、导出、到期筛选、相对方筛选、项目/采购关联筛选、归档检查。
+
+列表规则：
+
+- 列表展示：合同号、合同名称、相对方、负责人、关联项目/采购、金额或币种摘要、开始/到期时间、状态、附件完整性。
+- 普通列表不展示合同正文原文、完整供应商敏感资料、报价明细、银行账号等高敏内容。
+- 到期、缺附件、未归档、敏感附件缺下载理由等状态要明显，但不要做成大面积告警墙。
+- 合同号和合同名称是主标识；内部 id 只在审计/排障区可见。
+
+详情规则：
+
+- 第一屏固定展示：合同状态、下一步、相对方、负责人、到期/续签提醒、附件完整性。
+- 主区分区：基础信息、关联项目/采购、附件与归档、审批/变更记录、到期提醒、审计记录。
+- 附件区按类型分组：合同正文、补充协议、报价/订单、验收、付款相关材料、其他说明。
+- 高敏附件只显示必要摘要；查看/下载需要权限，必要时要求填写用途并写审计。
+- 关联采购和项目只做上下文跳转，不把采购审批或付款动作塞进合同详情首屏。
+
+现状判断：
+
+- 合同页面应保留“台账 + 详情命令面板”的方向，但需要比普通列表更重视附件完整性、到期提醒和敏感资料边界。
+- 下一轮可和项目/采购一起做“业务台账详情模板”，避免合同单独发明一套卡片和表格样式。
+
+不要：
+
+- 不把合同正文原文、敏感报价、完整供应商资料暴露在普通列表。
+- 不承诺电子签章或复杂合同流，除非后续任务明确。
+- 不把合同页面做成完整 CLM 系统。
+- 不在合同台账页内实现条款库、版本协同、红线审查或法务会签工作台。
+- 不把合同附件、付款证明、银行材料写入自动化截图或聊天证据。
+
+### 3.15 资产管理 `/assets`、`/inventory-checks`、`/mobile/assets/scan`
+
+目标：统一电子资产和固定资产台账，同时覆盖资产分类、资产卡片、资产流转、盘点任务和移动扫码。资产页面不是单纯列表，必须按“分类/列表/详情/流转/盘点”拆开设计，避免变成混杂后台页。
+
+V1 业务口径：固定资产不另做复杂财务固定资产系统，而是在统一资产台账里使用 `FA` 类型管理。页面优先回答“资产在哪、谁在用、谁负责、状态如何、是否需要盘点或离职交接”。电脑、显示器、硬盘、设备、安全介质等需要归还或盘点的实物应登记；普通耗材不登记。折旧、残值、会计科目和月度折旧凭证暂由财务/代账系统主办，OA 只登记采购来源、业务编号、责任链、流转状态和交接证据。
+
+采购/报销衔接口径：采购明细或报销材料可以标记 `资产候选`，但不得在审批通过、报销提交或付款后自动生成资产卡片。管理员需要在到货、验收或报销完成后人工核对实物、数量、归属、是否耗材、是否退货/赠品，再手动创建 `FA` 卡片并关联采购/报销来源。资产页可以提供“从资产候选建卡”的引导，但主动作仍是管理员确认后的 `新建资产卡片`。
+
+编号和标签口径：所有 `FA` 固定资产必须有资产编号。电脑、显示器、硬盘、设备、安全介质等可贴标实物应贴二维码标签，二维码用于移动扫码查找、盘点、领用/归还确认。不适合贴标签的资产不强制贴，但详情中必须记录序列号、保管人和位置；盘点支持扫码优先和手工输入资产号/序列号兜底，不强制复杂拍照盘点。
+
+盘点频率口径：小团队 V1 默认每季度做一次固定资产轻盘点；离职、调拨、维修、报废等事件发生时做事件盘点；备份硬盘、安全介质和关键设备每月确认一次责任人和位置。资产页可以展示最近盘点、下次盘点和逾期提示，但不把盘点频率做成复杂计划配置中心。
+
+处置口径：领用、归还、调拨属于日常流转，由管理员直接记录并留痕。报废、丢失、出售、赠送属于资产处置，必须负责人确认并填写原因；涉及赔偿、金额或责任争议时另走审批或线下确认，资产页只记录确认结果和证据摘要，不提供一键完成。
+
+电子资产口径：`EA-DOC/EA-SYS/EA-REPO/EA-BKP` 只做责任、归档、权限回收和验证索引。代码仓库、系统、备份介质/集合在 OA 中展示名称、用途、负责人、管理员/保管人、敏感级别、访问入口摘要、权限回收要求、备份策略、最近恢复验证日期和归档位置摘要；不保存源码包、密钥、token、完整配置、真实完整路径或备份内容。电子资产详情以“谁负责、在哪归档、何时验证、离职如何回收”为主，不做文件库、密码库或源码托管页面。
+
+电子资料 `EA-DOC` 口径：资产页只登记资料名称、类型、hash/校验摘要、敏感级别、负责人、关联项目/合同/付款和归档位置摘要。合同正文、银行流水、证照原件、客户资料、高敏报价、工资社保、个人身份资料等高敏原文不进入普通资产页；业务必要原文走合同、报销、付款、项目等对应模块附件权限和下载审计，非业务必要高敏资料走线下受控归档。
+
+资产台账 `/assets`：
+
+- 页头左侧标题 `资产台账`，页头右侧主动作：`新建资产卡片`；`移动扫码查找` 是次动作。
+- 首屏默认以资产列表和当前资产详情为主，不让资产分类表单压过资产本身。
+- 资产分类属于管理索引，PC 可放左侧窄栏；若分类编辑表单过重，应折叠或移到管理/弹窗，避免左侧长期占据首屏。
+- 资产列表在主区上方：搜索、状态、类型、敏感级别、分类、法体、成本中心、归属人等筛选进入命令栏；超过 4 个筛选时默认收进“高级筛选”。
+- 列表字段：资产编号、名称、类型、分类、敏感级别、状态、负责人/归属人、标签状态、最近盘点/验证或最近流转。
+- 行级动作默认是选择/查看详情；领用、归还、调拨不放列表行，必须进入详情核对。
+
+资产详情：
+
+- 详情第一屏展示：资产编号、名称、状态、类型、敏感级别、负责人/归属人、位置、标签/二维码状态、最近盘点、下一步。
+- 主内容按分区：基础信息、归属与位置、采购来源、电子资产元数据、附件/证明、历史与审计。
+- 敏感字段只保留脱敏索引、hash、外部引用、归档位置摘要；不展示密码、token、Secret、完整本地路径、源码配置、原始 payload。
+- 电子资产元数据区只展示责任、权限回收、备份/恢复验证和归档摘要；源码包、密钥、完整配置、真实完整路径、备份内容和高敏资料原文不得进入普通详情页。
+- 资产保存动作放详情底部右侧或右侧命令面板；长表单不要在每个分区都放保存按钮。
+- `ERP 同步状态`、AI 建议、外部引用属于低频/高级区，默认折叠。
+
+资产流转：
+
+- 领用、归还、调拨是高影响业务动作，放在详情的命令面板或“资产流转”分区，不放分类栏或列表行。
+- 流转区固定展示当前归属人、当前位置、目标归属人、目标位置、备注。
+- 只能显示当前状态可执行的动作：未领用时突出领用；已领用时突出归还/调拨；不可执行动作禁用并说明原因。
+- 执行动作前需要确认对象摘要，写入审计记录。
+- 报废、丢失、出售、赠送等处置动作必须与领用/归还/调拨分区展示，使用二次确认，展示资产编号、名称、负责人、当前保管人、位置、处置原因和后果。
+- 涉及赔偿、金额或责任争议时，处置按钮只允许记录“待确认”或“已确认结果”，不得在资产页直接完成争议处理。
+
+资产分类：
+
+- 分类是 C 类配置能力，不是普通用户高频任务。
+- 分类入口在资产页左侧索引或管理页中；主动作是 `新建分类`，保存动作在分类表单底部。
+- 分类列表字段只保留编码、名称、关联单据分类、启停状态。
+- 不把分类维护和资产卡片编辑混成同一个主表单。
+
+盘点布局：
+
+- `/inventory-checks` 默认是盘点任务工作台：左侧/上方创建或选择盘点任务，右侧/下方显示当前盘点详情。
+- 页头右侧放 `移动扫码盘点` 次动作；`创建盘点任务` 是盘点任务表单主动作，不应和资产台账的新建资产混淆。
+- 任务列表字段：盘点单号、范围、负责人、状态、完成度、异常数、截止时间。
+- 当前盘点详情第一屏展示：盘点单号、范围、状态、完成度、异常数、下一步。
+- `启动盘点`、`完成盘点` 是高影响动作，放当前盘点详情右上或右侧命令区，并二次确认。
+- 记录盘点结果只在盘点中显示；字段为资产、结果、一句话备注。
+- 常规盘点默认按季度创建；离职、调拨、维修、报废等事件盘点可从资产详情或对应业务事件发起；高风险资产月度确认只需记录责任人、位置和一句话结果。
+
+移动扫码：
+
+- `/mobile/assets/scan` 只做快速查找、盘点记录、确认领用/归还等单一动作。
+- 移动端不展示资产分类维护、复杂高级筛选、ERP 同步和完整资产元数据。
+- 移动查找优先扫二维码标签；二维码不可用时允许输入资产编号或序列号。
+- 扫码后先展示资产摘要和当前允许动作，再让用户确认。
+- 小屏主动作在底部，次动作进入更多。
+
+不要：
+
+- 不把资产管理做成“分类表单 + 大量筛选 + 详情长表单”同时压在首屏。
+- 不让普通员工接触敏感电子资产元数据、完整路径、密钥或原始配置。
+- 不在列表行直接执行调拨、归还、删除等动作。
+- 不把资产分类维护作为普通资产台账主任务。
+- 不把盘点任务、资产流转、ERP 同步混成同一组按钮。
+- 不为了标签规则强制复杂拍照盘点或给不适合贴标的资产硬贴标签。
+- 不把电子资产页做成文件库、密码库、源码托管或备份内容浏览器。
+- 不把 `EA-DOC` 做成合同正文、银行流水、证照原件、客户资料或高敏报价的普通文件入口。
+
+### 3.16 请假记录 `/leave-requests`
+
+目标：OA 查看企微主办请假历史、镜像和应急接管记录。
+
+布局：
+
+- 标题建议保持“请假记录”。
+- 默认展示企微同步记录、状态、申请人、时间段、天数、审批结果、同步状态。
+- 若 OA 应急接管未开启，不突出“新建请假”。
+- 应急模式开启时必须显示应急原因、范围、预计结束时间和恢复路径。
+
+不要：
+
+- 不把请假当 OA 日常提交入口。
+- 不在 OA 列表提供默认快批。
+
+### 3.17 考勤 `/attendance`
+
+目标：利用企微打卡作为原始采集，OA 显示摘要、解释和异常。
+
+布局：
+
+- 默认展示月度/周期摘要、异常、同步状态、解释记录。
+- 员工视图看自己的记录；管理视图看团队摘要和同步异常。
+- 补卡、外出、加班等日常处理优先回到企微；OA 只展示镜像、历史、异常或应急。
+
+不要：
+
+- 不重造定位、人脸、Wi-Fi、排班、防作弊。
+- 不把 OA 做成新的打卡页面。
+
+### 3.18 企微审批历史 `/wecom-approval-archive`
+
+目标：只读历史和审计留存。
+
+布局：
+
+- 默认按类型、申请人、状态、时间展示请假/补卡/外出/加班等企微主办记录。
+- 详情展示外部单号、同步批次、审批摘要、审批链、回调/补偿状态。
+- 异常记录给“重试/查看同步状态”给管理员，不给普通员工。
+
+### 3.19 通知中心 `/notifications`
+
+目标：事件收件箱，不是待办列表副本。
+
+布局：
+
+- 默认卡片流：未读、类型、标题、业务编号、状态、时间、直达入口。
+- tabs 只分未读/全部/系统类等低复杂维度。
+- 点击通知应直达业务详情、审批任务或可解释失败提示。
+
+不要：
+
+- 不重复完整待办列表。
+- 不把通知作为快速上手入口。
+
+### 3.20 个人设置 `/settings/profile`
+
+目标：普通用户只管理账号可理解内容。
+
+布局：
+
+- 默认三块：个人资料、密码/安全、通知偏好；企业微信绑定可作为账号安全或绑定状态分区。
+- 组织归属、直属上级、角色摘要可折叠在“账号详情”。
+- 权限 code、完整员工档案维护、组织管理入口不放默认页。
+- 用户管理、角色分配、组织调整、审批规则、功能开关、主数据、审计日志和系统配置不从个人设置进入。
+
+不要：
+
+- 不做成系统用户管理页。
+- 不让用户看到一堆无法操作或不理解的权限/组织字段。
+- 不把“完善个人资料”导向人员档案维护、组织配置或权限管理。
+
+### 3.21 登录、找回密码、修改密码
+
+目标：稳定登录，不丢输入，不做营销 hero。
+
+布局：
+
+- 统一 Auth 面板，品牌、标题、表单在一条视觉轴线上。
+- 普通浏览器账号密码为主；企微 WebView 企业微信一键为主，账号密码为 fallback。
+- 忘记密码位置靠近密码输入；密码可见按钮使用图标按钮并保留输入。
+- PWA 更新提示不能自动刷新并清空表单。
+
+### 3.22 协同轻页面：公告、团队、周报、待办
+
+目标：辅助小团队日常，不抢主流程。
+
+公告：
+
+- 默认通知/制度/重要公告列表，管理发布从管理侧进入。
+- 不做新闻站或营销内容。
+
+团队：
+
+- 默认团队状态、在岗/外出/请假摘要、负责人视角提醒。
+- HR/考勤事实来自企微或 OA 镜像，不重复提交入口。
+
+周报：
+
+- 默认本周填写/提交状态、需要协助、负责人查看缺交/风险。
+- 不做复杂绩效系统。
+
+待办：
+
+- 只承接轻量个人事项，不和审批待办混淆。
+- 工作台可汇总高优先级个人待办，但不复制完整列表。
+
+### 3.23 管理聚合 `/system/settings`
+
+目标：低频配置统一入口。
+
+布局：
+
+- 分组：人员与组织、流程与规则、财务基础、通知与集成、审计与运维。
+- 每个卡片只展示名称、用途、状态/风险和进入按钮。
+- 不在侧边栏展开所有管理子页。
+- 管理聚合是组织、角色、审批规则、功能开关、主数据、审计日志、人员维护和系统配置的唯一普通入口；不要从个人设置或工作台教学入口跳进这些配置页。
+
+### 3.24 人员、组织、用户、部门、主数据
+
+目标：管理员维护基础资料。
+
+布局：
+
+- 默认表格 + 搜索 + 状态筛选 + 详情/编辑弹窗。
+- 人员页展示员工号、姓名、部门、直属上级、状态、企微绑定摘要。
+- 用户页展示登录账号、角色、启停状态，不展示密码或 Secret。
+- 主数据页按 tab 分组，但每个 tab 使用同一命令栏和表格规则。
+
+不要：
+
+- 不把人员详情和个人设置混成一个页面。
+- 不在普通用户路径暴露管理表单。
+- 不让普通员工通过个人资料页编辑组织、角色、账号启停或审批配置。
+
+### 3.25 审批规则、流程定义、费用标准
+
+目标：配置小团队审批和费用口径，避免平台化复杂 BPM。
+
+布局：
+
+- 审批规则默认按业务类型/金额阈值/角色链展示。
+- 流程定义只做线性版本治理，不做自由拖拽设计器。
+- 费用标准默认列表 + 适用范围 + 控制方式；超标口径要和报销预检一致。
+- 发布、停用、变更都需要确认和影响提示。
+
+### 3.26 报销模板 `/system/reimbursement-templates`
+
+目标：管理员维护低频创建模板，不影响普通报销首屏。
+
+布局：
+
+- 仅管理权限可见，从“管理”或报销“台账工具/更多创建方式”进入。
+- 默认表格展示模板名称、适用场景、启用状态、最近更新。
+- 新建/编辑模板使用弹窗或详情页，字段按报销明细结构分组。
+
+不要：
+
+- 不在普通员工报销列表首屏展示模板配置。
+- 不让模板成为新建报销的必选前置。
+
+### 3.27 通知渠道、外部系统、功能管理、切换控制台
+
+目标：管理员排障和集成配置，不面向普通业务用户。
+
+布局：
+
+- 默认展示当前状态、最近测试结果、配置缺口、最后同步/发送时间。
+- 外部系统页面要体现“当前无 ERP 深集成/代账交接为主”的边界。
+- 功能管理只做 feature flag 管理，不作为普通功能入口。
+- 切换控制台必须显示风险、影响范围、回滚方式。
+
+### 3.28 审计日志、委托、工资、绩效、预算、数据看板
+
+审计日志：
+
+- 默认只给管理员/审计角色，提供对象、操作者、动作、时间、结果筛选。
+- 可展示必要内部编号，但要避免原始 payload 和敏感值。
+
+委托：
+
+- 作为报销/审批代理能力的低频配置，入口放管理或个人账号高级区，不进普通首屏。
+
+工资、绩效：
+
+- 当前按系统设置权限隐藏在管理/低频路径；未明确启用前不作为主导航。
+
+预算：
+
+- 财务/负责人视角，展示预算池、已用、预警、阻断；普通员工只在报销预检看到结果。
+
+数据看板：
+
+- 作为低频分析入口，不替代工作台。
+- 默认不做大屏，不作为普通用户首页。
+
+### 3.29 移动首页 `/mobile`
+
+目标：从手机快速处理待办、提交/续填报销、查看状态。
+
+布局：
+
+- 顶部焦点卡：待处理、最急事项、当前身份。
+- 常用入口最多 3-4 个：移动审批、报销、发票上传、我的。
+- 列表只展示需要行动或最近进度，不展示 PC 管理入口。
+
+### 3.30 移动审批 `/mobile/approvals`
+
+目标：手机核对摘要后处理 OA 主办审批，企微主办 HR/考勤回企微处理。
+
+布局：
+
+- 列表卡片展示业务类型、编号、申请人、金额/天数、状态、等待时间。
+- 详情卡展示下一步、业务摘要、证据入口、动作。
+- 高风险动作二次确认；驳回/退回必须填写理由。
+
+不要：
+
+- 不出现 PC 表格。
+- 不对企微主办 HR/考勤默认 OA 快批。
+
+### 3.31 移动报销 `/mobile/reimbursements` 与详情
+
+目标：新建/续填/补材料/查状态。
+
+列表：
+
+- 默认显示草稿、被退回/驳回、审批中。
+- 主动作是新建报销或继续编辑。
+
+详情：
+
+- 顶部焦点卡显示状态、金额、下一步。
+- 分区顺序：明细、PDF 发票、附件、审批进度、操作。
+- 添加发票不默认弹键盘；发票入口 PDF-only。
+- 底部主操作不遮挡内容，小屏双按钮能同行时保持同行。
+
+### 3.32 移动发票上传 `/mobile/capture`
+
+目标：移动端上传 PDF 发票，不做拍照 OCR。
+
+布局：
+
+- 入口文案明确“上传 PDF 发票”。
+- 选择文件、上传状态、识别中、失败原因、可添加状态清楚。
+- 图片只能作为附件路径，不作为正式发票 OCR。
+
+### 3.33 移动请假 `/mobile/leave`
+
+目标：企微主办请假历史/镜像/应急查看。
+
+布局：
+
+- 默认展示请假历史和状态，明确日常请假在企业微信处理。
+- 若 OA 应急未开启，不给强主动作“提交请假”。
+- 若保留页面，标题/空态要避免用户误以为 OA 是主入口。
+
+### 3.34 移动采购、资产扫描、我的、通知、个人资料
+
+移动采购：
+
+- 卡片列表 + 详情摘要 + 保存/提交/补附件，不做 PC 双栏。
+
+资产扫描：
+
+- 扫码/输入资产号、展示资产摘要、确认盘点/归还/转交等单一动作。
+
+移动我的：
+
+- 账号身份、企业微信绑定、通知、退出登录；不放管理矩阵。
+
+移动通知：
+
+- 事件卡片流，点击直达业务，不复制审批列表。
+
+移动个人资料：
+
+- 与 PC 个人设置一致：个人资料、密码/安全、通知偏好、企微绑定，组织/角色折叠。
+
+### 3.35 异常页 `/403`、`*`
+
+目标：解释为什么进不去，并给可执行去向。
+
+布局：
+
+- 403：说明无权限，给返回工作台/联系管理员。
+- 404：说明页面不存在，给返回工作台。
+- 不显示路由栈、内部错误、完整路径。
+
+## 4. 通用状态规则
+
+- 加载态：A 类页面用骨架或紧凑文案，不能闪出空模块。
+- 空态：说明当前没有什么，并给一个真实下一步；没有下一步就不显示模块，不放教学型长文案。
+- 错误态：显示业务可理解原因、影响和重试/返回/联系管理员等下一步；普通用户不看接口名、内部状态码、路由栈、完整路径、原始 payload 或大段技术错误。
+- 无权限态：不渲染不可点击入口；直达路由才显示自然中文 403 解释和返回/联系管理员入口，不暴露权限 code。
+- 确认弹窗：必须包含对象摘要、动作后果、不可逆提示；删除/付款/发布/驳回/退回/切换配置必须二次确认。
+- 导出/下载：敏感附件和财务导出需要权限和审计；报告不写真实敏感内容。
+
+## 5. 后续实施优先级
+
+P0：不继续整改，保持当前已收敛方向
+
+- 工作台：保持任务优先，不恢复快速上手常驻区。
+- 待我处理：保持查看处理优先，不恢复 HR/考勤 OA 快批。
+- 报销列表：保持我的报销 + 台账工具模式。
+
+P1：建议下一批优先优化
+
+- 报销详情：减少重复付款/摘要展示，进一步规范更多区和右侧动作区。
+- 采购页：从后台双栏表单改为任务/状态/证据/动作顺序。
+- 请假记录、考勤、企微审批历史：统一企微主办镜像口径，避免误导为 OA 日常入口。
+- 个人设置：确认默认只保留个人资料、密码/安全、通知偏好、企微绑定，折叠组织/角色。
+
+P2：低频/管理页统一规范
+
+- 付款、AP、票据：统一“台账工具”与异常优先模式。
+- 项目、合同、资产：统一轻管理台账 + 详情命令面板。
+- 管理配置：统一管理聚合、命令栏、表格、风险确认和审计提示。
+- 移动端：统一焦点卡、卡片列表、底部动作和 HR/考勤企微边界文案。
+
+## 6. 回写建议
+
+- `docs/产品设计规则.md`：只回写稳定的产品体验事实，例如页面职责、HR/考勤企微主办边界、A/B/C 页面分级变化。
+- `.trellis/spec/hyb-oa/frontend-react-vite-design.md`：回写可执行的工程/组件规则，例如列表页、详情页、移动页、台账工具、确认弹窗和截图验证要求。
+- 当前 `design.md`：保留完整审查建议和后续实施拆分，不直接当作长期事实源。
diff --git a/.trellis/tasks/05-29-page-design-rules-audit/implement.jsonl b/.trellis/tasks/05-29-page-design-rules-audit/implement.jsonl
new file mode 100644
index 00000000..16b6e101
--- /dev/null
+++ b/.trellis/tasks/05-29-page-design-rules-audit/implement.jsonl
@@ -0,0 +1,6 @@
+{"file": ".trellis/spec/hyb-oa/project-governance.md", "reason": "Trellis task、审批、提交和单人开发低风险原则。"}
+{"file": ".trellis/spec/hyb-oa/frontend-react-vite-design.md", "reason": "前端页面设计、任务优先布局、共享组件和验证规则。"}
+{"file": ".trellis/spec/hyb-oa/docs-and-evidence.md", "reason": "文档治理、事实源回写和证据脱敏规则。"}
+{"file": ".trellis/spec/hyb-oa/wecom-boundary.md", "reason": "企业微信主办 HR/考勤与 OA 主办业务边界。"}
+{"file": ".trellis/spec/hyb-oa/approval-workflow.md", "reason": "审批、工作流、自审和状态边界。"}
+{"file": ".trellis/spec/hyb-oa/reimbursement-invoice-ocr.md", "reason": "报销、PDF 发票 OCR 和附件边界。"}
diff --git a/.trellis/tasks/05-29-page-design-rules-audit/prd.md b/.trellis/tasks/05-29-page-design-rules-audit/prd.md
new file mode 100644
index 00000000..d643b5b9
--- /dev/null
+++ b/.trellis/tasks/05-29-page-design-rules-audit/prd.md
@@ -0,0 +1,114 @@
+# 全页面设计规则梳理
+
+## Goal
+
+梳理 hyb-oa 当前 PC、移动和企业微信入口下所有页面的职责、默认布局、操作层级和后续优化建议，形成一份可用于后续前端开发、改进和重构的页面规则地图。目标不是本轮直接重构页面，而是先把“每类页面应该长什么样、先展示什么、哪些能力应隐藏到高级入口、哪些页面不应该继续做”的判断固定下来，降低单人开发时的返工和误改概率。
+
+## What I Already Know
+
+- 产品面向国内、小于 10 人的科技初创公司，用户一人多岗，默认需要低决策成本、少入口、任务优先。
+- 开发和维护主要由一个人完成，后续页面规则必须减少分叉、减少页面局部特例，优先复用已有共享布局和验证路径。
+- 前端视觉、布局和交互裁决以 `frontend-design` skill 为准；`docs/产品设计规则.md` 只保留产品体验事实、业务边界和验收边界。
+- OA 主办报销、采购、费用、合同、项目、付款、AP、票据、资产、审计和高敏附件。
+- 企业微信主办 HR/考勤日常动作，包括打卡、请假、补卡、外出、加班；OA 只做镜像、历史、审计、异常和应急接管。
+- 当前路由覆盖认证、工作台、审批、报销、财务、票据、采购、项目、合同、资产、HR/考勤镜像、协同、通知、管理配置和移动端页面。
+- 最近已完成的前端方向包括：侧边栏任务优先、工作台去快速上手常驻化、待我处理任务优先、报销列表任务卡和台账工具降噪、HR/考勤 OA 快批入口移除。
+
+## Scope
+
+- 梳理所有当前已注册路由和页面文件的页面规则。
+- 覆盖 PC、移动、企业微信 WebView 入口下的列表页、详情页、工作台、审批页、管理配置页、通知页、异常页和打印页。
+- 输出页面分级、页面布局模板、模块级建议、操作显隐规则、文案规则、空态/错误/加载/权限状态规则和验证建议。
+- 明确哪些页面应优先整改，哪些页面只保留管理/历史/低频入口，哪些页面未来需要单独 Trellis task。
+
+## Out Of Scope
+
+- 本轮不直接修改业务页面代码。
+- 本轮不做公网部署、公网检查、真实数据写入、企业微信写入或生产配置变更。
+- 本轮不重做视觉主题、颜色系统、组件库或路由权限模型。
+- 本轮不新增业务能力，不恢复已冻结模块，不把企业微信主办的 HR/考勤日常审批搬回 OA。
+
+## Requirements
+
+- 页面规则必须以小团队中文 OA 工作台为中心，不做营销页式布局。
+- A 类核心流程必须先回答“我现在要处理什么 / 下一步点哪里 / 当前状态是什么”。
+- B 类业务运营页面必须默认显示常用台账和处理动作，导出、批量、统计、模板、复杂筛选进入高级入口或权限入口。
+- C 类管理配置页面允许信息密度更高，但必须统一承接在“管理”下，默认不进入普通员工路径。
+- 移动端不得出现桌面宽表或 PC 管理配置台，必须使用卡片/列表/底部主操作/安全区规则。
+- 详情页必须统一“状态与下一步、业务摘要、证据材料、审批/处理历史、动作面板”的信息顺序。
+- 全系统必须统一操作区位置：PC 全局主动作在页头右侧，列表筛选/工具在页头下方命令栏，行级动作在列表最右侧或卡片尾部，详情高风险动作在右侧命令栏，移动主动作在底部吸附区。
+- 资产管理、盘点、合同、采购、项目等 B 类业务页必须单独列规则，不能只用“业务运营页面”笼统覆盖。
+- 所有普通用户页面不展示 UUID、taskId、entityId、内部状态码、Secret、完整本地路径、原始 payload 或调试字段。
+- HR/考勤页面必须明确企微主办边界：OA 页面默认是镜像/历史/异常/应急，不是日常请假/打卡入口。
+- 行业惯例相关事项必须提前形成决策清单，逐项确认后写入 `design.md` 或长期规范，不能在后续页面改造时临时各做各的。
+
+## Confirmed Decisions
+
+- `2026-05-30`：一级导航采用“任务优先 + 权限显示 + 更多兜底”，但不把已启用且常用的业务台账强行藏到 `更多`。`合同`、`采购`、`资产`、`项目` 这类真实业务入口，只要用户有权限且模块启用，应直接作为一级入口显示；`更多` 只承载低频、冻结、阶段性或偶尔查看的入口。
+- `2026-05-30`：`工作台` 和 `待我处理` 不重复。`工作台` 是所有人的今日总览和分流；`待我处理` 是审批/处理角色的正式处理队列，只对有处理职责的人显示。
+- `2026-05-30`：全系统审批动作集中在 `待我处理` / 审批详情执行。报销、采购、合同、项目、资产等业务台账列表和普通业务详情只显示 `查看处理`、`查看进度`、`补材料` 或进入审批任务的入口，不直接放 `通过`、`驳回`、`退回`、`转审`；审批前必须进入统一审批详情核对摘要、证据、后果和确认。
+- `2026-05-30`：全系统固定使用六类页面模板：`工作台总览`、`任务处理列表`、`业务台账列表`、`主从工作台`、`详情工作区`、`管理配置页`。后续页面先判定模板，再填业务内容，不允许每个页面临时自创新布局。
+- `2026-05-30`：全系统统一操作区坐标。PC 页头右侧放页面主动作，页头下方命令栏放筛选和台账工具，列表最右列或卡片尾部放行级动作，详情右侧命令区或动作栈放高风险动作，移动端底部吸附主动作；危险/不可逆动作必须和普通动作拉开并二次确认。
+- `2026-05-30`：全系统采用“状态先于按钮”的动作生命周期规则。每个业务对象必须先定义状态矩阵，再决定按钮显隐、主次关系、禁用原因和确认方式；不允许页面局部临时判断草稿、审批中、已通过、待支付、已支付、已取消、异常等状态下的动作。
+- `2026-05-30`：全系统统一删除、撤回、取消、作废和归档语义。草稿或未生效临时对象才可删除；审批中由发起人按规则撤回；业务不再执行用取消；已编号、已签署、已付款或已生效对象失效用作废；完成后锁定留存用归档。已提交后的业务对象原则上不物理删除，必须保留原因、操作者、时间和审计记录。
+- `2026-05-30`：全系统采用“服务端权限为准，前端按当前任务角色收敛展示”的角色和数据范围规则。普通员工默认看“我的/与我相关”，审批人看“待我处理”，财务和负责人看授权范围内的台账与处理入口，管理员看配置和审计；即使同一用户一人多岗，也不因为有权限就默认展开所有高级工具、全量数据和内部字段。
+- `2026-05-30`：全系统采用业务编号和自然中文作为普通用户主语义。普通用户页面不展示 UUID、taskId、entityId、权限 code、内部状态码、原始 payload、完整本地路径或调试字段；只有审计、排障、打印留痕等授权场景才展示必要内部编号，并且不能替代业务编号成为主标识。
+- `2026-05-30`：全系统权限不足、空状态和异常状态统一用自然中文说明原因和下一步。普通用户路径不暴露 `403`、接口名、权限 code、内部状态码、路由栈、完整路径、原始 payload 或大段技术错误；管理员、审计和排障页只展示最小必要技术信息。
+- `2026-05-30`：全系统列表和台账默认收敛。列表首屏只保留 3 到 5 个高频筛选，搜索、状态、范围、时间优先；导出、批量、统计、模板、全范围、高级筛选进入 `台账工具` 或 `更多`；批量动作只在选中记录后出现；移动端不承接复杂台账工具，只保留搜索、状态筛选和卡片列表。
+- `2026-05-30`：全系统长表单支持草稿和清晰提交。保存草稿与提交是两个明确动作；提交前必须做业务校验和摘要确认；离开未保存页面要提示；错误提示必须定位到字段、明细行、发票、附件或材料区；移动端表单只保留必要字段和底部主动作，不承接复杂配置表单。
+- `2026-05-30`：全系统详情页采用统一证据结构。详情页先展示状态与下一步，再展示业务摘要，证据材料居中，审批/处理历史靠后，动作面板固定在 PC 右侧或移动端底部；报销、审批、采购、合同、资产等详情页都按这个顺序组织，不把所有信息平铺到首屏，也不把高风险动作放在用户看完证据之前。
+- `2026-05-30`：全系统证据材料统一在详情页集中处理。列表页和台账页只显示发票、附件、合同文件、回单、资产材料等证据的完整性摘要、缺失提示和进入详情入口，不直接承接预览、下载、删除、批量打包或敏感材料处理；这些动作进入详情页、详情命令区、台账工具或授权审计路径。
+- `2026-05-30`：全系统上传材料采用“材料类型先行”。上传前必须明确是 PDF 发票、普通附件、合同文件、付款回单、验收材料、资产材料还是电子资料索引，不使用一个万能 `上传附件` 入口混收所有材料；不同类型分别进入对应校验、权限、审计和展示位置。
+- `2026-05-30`：全系统付款相关动作集中在 `付款` / 财务处理详情执行。报销、采购、合同、项目等列表和普通详情只显示付款状态、回单状态、`查看付款`、`补回单` 或进入付款记录入口，不直接放 `标记已付款`、`取消付款`、`批量付款`、`执行付款`；付款动作前必须核对金额、对象、线下付款说明、证据和回单。
+- `2026-05-30`：全系统跨模块关联采用“摘要 + 跳转”边界。项目、采购、合同、报销、资产、付款等页面可以展示关联对象的业务编号、名称、状态、金额/数量、负责人、证据完整性和下一步摘要，但不能复制对方模块的完整流程、审批动作、付款动作、发票/OCR处理、合同正文下载或高敏附件操作；需要处理时跳转到归属模块详情、审批任务或财务处理页。
+- `2026-05-30`：移动端只承接轻动作，不复制 PC 管理台。移动端主要用于提交、补材料、查状态、处理待办、扫码、上传和从企业微信消息直达；不承接复杂台账、全范围管理、批量导出、批量审批、批量付款、流程配置、管理配置、功能开关、复杂筛选和大表格；移动页面统一使用顶部状态/焦点卡、卡片列表或分区详情、底部安全区主动作。
+- `2026-05-30`：全系统区分待办和通知。`待我处理` 是行动列表，只放需要当前用户处理的事项；`通知中心` 是事件收件箱，只放状态变化、提醒、失败、同步结果等消息；通知点击直达业务详情、审批任务或失败解释页，不在通知中心复制一套待办处理列表，也不把普通通知算入工作台 `今日待处理`。
+- `2026-05-30`：全系统敏感数据默认最小展示。合同正文、发票、回单、付款信息、资产敏感字段、附件和导出文件只展示必要摘要；预览、下载、导出、批量下载必须按服务端权限控制并写审计；普通列表和移动端不展示完整账号、完整路径、原始附件名里的敏感信息或高敏合同/财务细节。
+- `2026-05-30`：全系统危险动作必须二次确认且展示对象和后果。删除、付款、发布、停用、作废、驳回、退回、切换配置、批量处理等不可逆或高风险动作，确认面板必须包含对象摘要、后果、影响范围、必要理由输入或确认输入，并写入审计；不允许只弹一句 `确定吗？`。
+- `2026-05-30`：全系统明确集成和外部系统边界。OA 主办报销、采购、合同、项目、付款、AP、票据、资产和高敏附件；企业微信主办 HR/考勤日常动作；ERP、银行、代账、OCR、企业微信消息等外部系统只展示真实同步状态、失败原因和下一步，不在界面上承诺系统无法确认的 `已同步`、`已付款` 或 `已审批`。
+- `2026-05-30`：全系统统一试运行和验收证据口径。本地构建、Playwright 和截图通过只代表本地验证通过；只有完成部署、公网访问检查、关键路径冒烟和必要截图证据后，才能告知用户 `可以线上测试`；未部署时只能说明 `本地验证通过，尚未线上可测`。
+- `2026-05-30`：固定资产在 OA 中按统一资产台账的 `FA` 类型管理，口径是实物责任、盘点和离职交接，不是完整财务固定资产账。电脑、显示器、硬盘、设备、安全介质等需要归还或盘点的实物应登记；普通耗材不登记；折旧、残值、会计科目和月度折旧凭证暂由财务/代账系统主办，OA 只记录采购来源、责任链、流转状态和交接证据。
+- `2026-05-30`：采购/报销与固定资产采用“资产候选 + 管理员建卡”的轻量衔接。采购明细或报销材料只标记可能形成资产的线索，不自动生成资产卡片；到货、验收或报销完成后，由管理员核对实物、数量、归属、是否耗材、是否退货/赠品后手动创建 `FA` 资产卡片并关联来源单据。
+- `2026-05-30`：固定资产必须有 `FA` 资产编号；电脑、显示器、硬盘、设备、安全介质等实物资产能贴标签就贴二维码标签。确实不适合贴标签的资产不强制贴，但必须记录序列号、保管人和位置；盘点支持扫码优先和手工输入兜底，不强制复杂拍照盘点。
+- `2026-05-30`：固定资产盘点采用轻量频率。小团队 V1 默认每季度做一次固定资产轻盘点；离职、调拨、维修、报废等事件发生时做事件盘点；备份硬盘、安全介质和关键设备每月确认一次责任人和位置。
+- `2026-05-30`：固定资产处置采用“流转留痕、处置确认”的轻量规则。领用、归还、调拨由管理员直接记录并留痕；报废、丢失、出售、赠送等处置必须负责人确认并填写原因；涉及赔偿、金额或责任争议时另走审批或线下确认，不在资产页一键完成。
+- `2026-05-30`：电子资产只做责任和验证索引。代码仓库、系统、备份介质/集合在 OA 中只登记元数据、负责人、权限回收要求、备份/恢复验证日期和归档位置摘要；不保存源码包、密钥、token、完整配置、真实完整路径或备份内容。
+- `2026-05-30`：电子资料资产 `EA-DOC` 只登记资料名称、类型、hash/校验摘要、敏感级别、负责人、关联项目/合同/付款和归档位置摘要。合同正文、银行流水、证照原件、客户资料等高敏原文不进普通资产页，必须走对应业务附件权限或线下受控归档。
+- `2026-05-30`：资产管理规则组已收口。后续资产页面整改按本任务和 `docs/需求-资产管理规约.md` 执行，不再在本轮继续扩展资产业务细节；下一组转入合同、采购、项目和财务台账的统一页面规则。
+- `2026-05-30`：合同、采购、项目和财务台账统一采用“列表查找、详情处理”的页面边界。列表页只负责查找、筛选、看状态和进入详情；合同下载、归档、付款、导出、批量处理、作废、敏感附件查看等高风险动作放到详情页、详情命令区或台账工具中，并二次确认。
+- `2026-05-30`：合同、采购、项目和财务台账默认按当前角色收敛视角。普通员工看 `我发起/我相关`，负责人看 `我负责/项目相关`，财务看 `待复核/待付款/异常`，管理员才默认进入或可切换 `全范围`；全范围、导出、批量默认收进台账工具。
+- `2026-05-30`：合同台账 V1 只做登记、归档、到期/续签提醒，以及关联项目、采购和付款，不做完整合同生命周期管理。电子签、复杂法务审查、条款库、版本协同和完整 CLM 不进入当前合同台账；如需合同审批，走 OA 统一审批中心或另建后续 Trellis task。
+- `2026-05-30`：采购台账 V1 只做申请、审批、附件、轻量验收/归档，以及关联合同、项目和付款/AP，不做完整采购 ERP。采购订单全生命周期、库存、三单匹配、供应商生命周期管理、招采评标和 ERP 入账不进入当前采购页；审批通过也不代表已付款、已入库或已形成固定资产。
+- `2026-05-30`：项目模块 V1 只做轻项目台账：项目状态、负责人/成员、里程碑/任务、风险、交付记录，以及关联报销、采购、合同和付款，不做完整项目管理软件。甘特图、复杂任务依赖、工时、资源排期、OKR、项目组合管理和大型协同平台不进入当前项目页。
+- `2026-05-30`：财务台账 V1 只做付款准备、付款批次、回单留痕、AP 状态、票据/OCR 状态和代账交接摘要，不做完整财务软件。银行直连真实支付、银行流水自动导入、ERP/总账、凭证生成、自动对账和税务申报不进入当前财务页面；真实付款继续在线下银行或既有财务/代账流程完成，OA 只记录状态、证据和交接摘要。
+- `2026-05-30`：个人设置和管理配置彻底分离。`个人设置` 只放个人资料、密码/安全、通知偏好和企业微信绑定；组织、角色、审批规则、功能开关、主数据、审计日志、人员维护和系统配置统一进入 `管理`，不出现在普通员工路径或个人资料页里。
+- `2026-05-30`：多角色用户不做全局身份切换器。用户一人多岗时，页面按当前任务自动显示最相关视角；需要跨范围查看时，只在具体台账内提供 `我相关 / 我负责 / 财务处理 / 全范围` 等授权范围切换，不要求用户先选择“员工/财务/管理员”身份再使用系统。
+
+## Acceptance Criteria
+
+- [ ] `design.md` 覆盖当前路由清单中的所有页面或页面族，并给出布局/操作/降噪建议。
+- [ ] 规则能直接指导工作台、报销列表、报销详情、审批列表、审批详情、通知、管理配置、移动端等后续页面整改。
+- [ ] 明确 A/B/C 页面分级和优先级，能用于拆分后续 Trellis 实施任务。
+- [ ] 明确 OA/企业微信边界，避免请假、补卡、外出、加班等日常 HR/考勤流程在 OA 中重复处理。
+- [ ] 明确哪些规则应回写到长期事实源，哪些仅保留为本任务审查建议。
+- [ ] 验证计划覆盖文档治理校验，不把“规则梳理”误报为页面已整改或已部署。
+
+## Test Plan
+
+- `python3 ./.trellis/scripts/task.py validate 05-29-page-design-rules-audit`
+- `node scripts/qa/check-trellis-governance.mjs`
+- `git diff --check`
+
+如果后续按规则改页面，再按具体页面追加 `cd client && npm run typecheck && npm run build`，以及对应 Playwright/视觉截图验证。
+
+## Technical Notes
+
+- 已读取 `.trellis/workflow.md`、`.trellis/spec/hyb-oa/index.md`、`.trellis/spec/hyb-oa/frontend-react-vite-design.md`、`.trellis/spec/hyb-oa/project-governance.md`、`.trellis/spec/hyb-oa/docs-and-evidence.md`、`.trellis/spec/hyb-oa/wecom-boundary.md`、`.trellis/spec/hyb-oa/approval-workflow.md`、`.trellis/spec/hyb-oa/reimbursement-invoice-ocr.md`。
+- 已读取 `docs/产品设计规则.md`、`docs/报销发票附件规则.md`、`docs/需求-统一审批中心规约.md`、`docs/文档索引.md`、`docs/文档事实源状态矩阵.md`。
+- 已检查路由和导航：`client/src/router/index.tsx`、`client/src/features/navigation/schema.ts`。
+- 已抽样检查核心页面、B 类业务页和共享组件：`PortalHomePage.tsx`、`WorkflowTasksPage.tsx`、`WorkflowTaskDetailPage.tsx`、`ReimbursementsPage.tsx`、`ReimbursementDetailPage.tsx`、`PurchaseRequestsPage.tsx`、`AssetRegistryPage.tsx`、`InventoryChecksPage.tsx`、`ContractsRegistryPage.tsx`、`ProjectsPage.tsx`、`ProjectDetailPage.tsx`、`ListWorkspace.tsx`、`PageScaffold.tsx`。
+- 行业参考采用官方设计体系作辅助判断：[Ant Design Layout](https://2x.ant.design/docs/spec/layout) 将企业应用常见页面抽象为首页、仪表盘、列表、表格、详情、表单等模板；[Ant Design Button](https://ant.design/docs/spec/buttons-cn/) 强调一个按钮区最多一个主按钮、按钮文案应清楚表达结果、危险动作要提示风险；[Ant Design Detail Page](https://ant.design/docs/spec/detail-page) 强调详情页按信息复杂度分组、审批类详情需要承载审批动作。项目最终规则仍以 hyb-oa 小团队业务边界和 `frontend-design` 裁决为准。
+
+## Open Questions
+
+- Grill-me 决策从“信息架构和一级入口”开始，之后逐项确认页面模板、操作区、状态流、权限、列表、表单、详情、移动、通知、敏感数据、审计和异常处理。
diff --git a/.trellis/tasks/05-29-page-design-rules-audit/task.json b/.trellis/tasks/05-29-page-design-rules-audit/task.json
new file mode 100644
index 00000000..4505b73c
--- /dev/null
+++ b/.trellis/tasks/05-29-page-design-rules-audit/task.json
@@ -0,0 +1,31 @@
+{
+  "id": "page-design-rules-audit",
+  "name": "page-design-rules-audit",
+  "title": "全页面设计规则梳理",
+  "description": "梳理 hyb-oa 当前 PC、移动和企业微信入口下所有页面的职责、默认布局、操作层级和后续优化建议，先形成规则地图，不直接改页面代码。",
+  "status": "in_progress",
+  "dev_type": null,
+  "scope": "frontend-docs-governance",
+  "package": null,
+  "priority": "P2",
+  "creator": "shunli",
+  "assignee": "shunli",
+  "createdAt": "2026-05-29",
+  "completedAt": null,
+  "branch": null,
+  "base_branch": "main",
+  "worktree_path": null,
+  "commit": null,
+  "pr_url": null,
+  "subtasks": [],
+  "children": [],
+  "parent": null,
+  "relatedFiles": [
+    ".trellis/tasks/05-29-page-design-rules-audit/prd.md",
+    ".trellis/tasks/05-29-page-design-rules-audit/design.md",
+    ".trellis/spec/hyb-oa/frontend-react-vite-design.md",
+    "docs/产品设计规则.md"
+  ],
+  "notes": "",
+  "meta": {}
+}
\ No newline at end of file
diff --git a/docs/产品口径.md b/docs/产品口径.md
index 1c2dcc88..f74d3ba0 100644
--- a/docs/产品口径.md
+++ b/docs/产品口径.md
@@ -11,6 +11,7 @@
 - WFOC 起，能用企业微信成熟能力的 HR/考勤员工日常审批优先使用企业微信；OA 做按域镜像、人工接管、恢复回写、财务闭环和审计中台。
 - DBWFOC 后固定数据边界：企业微信成熟功能可作为流程、字段、交互和规则参考，但不默认成为高敏业务数据托管处。
 - 报销、采购、费用、合同、项目、财务付款、AP 台账、代账交接、审计和敏感附件仍由 OA 主办，在 OA 内提交、审批、留痕、归档。
+- 财务主办口径限定为付款准备、付款批次、回单留痕、AP 状态、票据/OCR 状态和代账交接摘要；真实付款继续在线下银行或既有财务/代账流程完成，OA 不做银行直连、银行流水自动导入、ERP/总账、凭证生成、自动对账或税务申报。
 - 请假、补卡、外出、加班等 HR/考勤员工日常审批优先在企业微信原生审批中提交和处理，OA 同步按域镜像；企业微信不可用时由管理员人工开启 OA 应急模式。
 - 企业微信作为手机工作台入口、免登/绑定、通讯录身份、消息通知、打卡、人事助手和 HR/考勤员工日常审批主操作端；OA 主办审批通过企业微信个人应用消息发送脱敏提醒并 deeplink 回 OA 处理。
 - WEGOV1 后固定 OA 自建留存目标：OA 数据库保存企微关键历史、完整外部关联键和必要业务快照，用于历史查看、对账、补偿拉取和后续恢复；企微不可用时先保证能查看以前数据，不承诺 V1 完整替代企微继续办理。
diff --git a/docs/产品设计规则.md b/docs/产品设计规则.md
index 793c303a..a536547e 100644
--- a/docs/产品设计规则.md
+++ b/docs/产品设计规则.md
@@ -32,6 +32,72 @@
 
 A 类页面优先保证真实试运行路径顺畅；B 类页面优先保证台账、复核和导出不误导；C 类页面允许展示更多审计和排障信息，但不得泄露无权限数据。
 
+页面模板固定为六类：`工作台总览`、`任务处理列表`、`业务台账列表`、`主从工作台`、`详情工作区`、`管理配置页`。后续新增或重构页面必须先判定页面分级和模板，再设计业务内容；不允许每个页面临时自创布局。移动端是这些模板的移动表达，不单独开一套 PC 壳层。
+
+全系统操作语义固定：页面主动作只保留一个且出现在用户预期的主操作区；筛选、台账工具、行级动作、详情高风险动作和移动端底部动作各有稳定位置。不可逆或高风险动作不得混在普通查看/编辑动作里，必须显示当前对象摘要并二次确认。
+
+全系统动作必须从业务状态矩阵推导，不由单个页面临时决定。每个核心对象先明确草稿、审批中、被驳回、已通过、待执行/待支付、已完成/已支付、已取消、异常、归档等状态，再决定主动作、次动作、禁止动作、禁用原因、确认方式和审计要求；前端只负责体验显隐和原因解释，最终权限与状态校验仍以服务端为准。
+
+审批动作集中在 `待我处理` / 审批详情执行。报销、采购、合同、项目、资产等业务台账列表和普通业务详情只显示 `查看处理`、`查看进度`、`补材料` 或进入审批任务的入口，不直接放 `通过`、`驳回`、`退回`、`转审`；审批前必须进入统一审批详情核对摘要、证据、后果和确认。
+
+删除、撤回、取消、作废和归档语义全系统统一。草稿或未生效临时对象才使用 `删除`；审批中由发起人按规则 `撤回`；业务不再执行用 `取消`；已编号、已签署、已付款、已发布或已生效对象失效用 `作废`；业务完成后锁定留存用 `归档`。已提交后的业务对象原则上不物理删除，必须保留原因、操作者、时间和审计记录。
+
+全系统数据展示必须按当前任务角色收敛。普通员工默认只看我的、与我相关和需要我补充；审批人默认看待我处理；财务/负责人默认看授权范围内的台账、异常和处理入口；管理员默认在管理入口看配置、审计和排障。同一用户一人多岗时不做全局身份切换器，页面按当前任务自动显示最相关视角；如需跨范围查看，只在具体台账内提供 `我相关 / 我负责 / 财务处理 / 全范围` 等授权范围切换。页面首屏不因为有权限就默认展开全范围数据、高级工具、导出、批量、配置或内部字段。
+
+权限不足、空状态和异常状态统一用自然中文说明原因和下一步。普通用户路径不暴露 `403`、接口名、权限 code、内部状态码、路由栈、完整路径、原始 payload 或大段技术错误；空态如果没有真实下一步就不显示模块；管理员、审计和排障页才展示最小必要技术信息。
+
+全系统列表和台账默认保持轻量。首屏只保留搜索、状态、范围、时间等 3 到 5 个高频筛选；导出、批量、统计、模板、全范围、高级筛选等低频或高风险能力进入 `台账工具`、`更多` 或权限面板；批量动作只在选中记录后出现；移动端只承接搜索、状态筛选、卡片列表和主动作，不复制 PC 复杂台账工具。
+
+合同、采购、项目和财务台账统一采用“列表查找、详情处理”的页面边界。列表页只负责查找、筛选、看状态和进入详情；合同下载、归档、付款、导出、批量处理、作废、敏感附件查看等高风险动作必须放到详情页、详情命令区或台账工具里，并按权限、审计和二次确认执行。
+
+合同、采购、项目和财务台账默认按当前角色收敛视角。普通员工看 `我发起/我相关`，负责人看 `我负责/项目相关`，财务看 `待复核/待付款/异常`，管理员才在管理或台账工具内进入或切换 `全范围`；全范围、导出、批量默认收进台账工具，不铺在普通首屏。
+
+合同台账 V1 只做登记、归档、到期/续签提醒，以及关联项目、采购和付款。合同页面不做完整合同生命周期管理，不自建电子签、复杂法务审查、条款库、版本协同或 CLM；如需合同审批，走 OA 统一审批中心或另建后续 Trellis task，合同台账页只展示状态、摘要和关联入口。
+
+采购台账 V1 只做申请、审批、附件、轻量验收/归档，以及关联合同、项目和付款/AP。采购页面不做完整采购 ERP，不承接采购订单全生命周期、库存、三单匹配、供应商生命周期管理、招采评标或 ERP 入账；审批通过不代表已付款、已入库或已形成固定资产。
+
+项目模块 V1 只做轻项目台账：项目状态、负责人/成员、里程碑/任务、风险、交付记录，以及关联报销、采购、合同和付款。项目页面不做完整项目管理软件，不承接甘特图、复杂任务依赖、工时、资源排期、OKR、项目组合管理或大型协同平台；项目页主要负责业务归集、风险提醒和跳转到对应业务详情。
+
+财务台账 V1 只做付款准备、付款批次、回单留痕、AP 状态、票据/OCR 状态和代账交接摘要。付款、应付账款和票据页面不做完整财务软件，不承接银行直连真实支付、银行流水自动导入、ERP/总账、凭证生成、自动对账或税务申报；真实付款继续在线下银行或既有财务/代账流程完成，OA 只记录状态、证据和交接摘要。
+
+付款相关动作集中在 `付款` / 财务处理详情执行。报销、采购、合同、项目等列表和普通详情只显示付款状态、回单状态、`查看付款`、`补回单` 或进入付款记录入口，不直接放 `标记已付款`、`取消付款`、`批量付款`、`执行付款`；付款动作前必须核对金额、对象、线下付款说明、证据和回单。
+
+跨模块关联采用“摘要 + 跳转”边界。项目、采购、合同、报销、资产、付款等页面可以展示关联对象的业务编号、名称、状态、金额/数量、负责人、证据完整性和下一步摘要，但不能复制对方模块的完整流程、审批动作、付款动作、发票/OCR 处理、合同正文下载或高敏附件操作；需要处理时跳转到归属模块详情、审批任务或财务处理页，并继续按原模块权限和审计控制。
+
+全系统长表单默认支持草稿和清晰提交。保存草稿不触发审批、付款、发布或外部同步；提交前必须做业务校验和摘要确认；离开未保存页面要提示；错误提示必须定位到字段、明细、发票、附件或材料区，并保留用户已输入内容。移动端表单只保留必要字段、材料上传和底部主动作，不承接复杂配置表单。
+
+全系统详情页采用统一证据结构。状态与下一步先行，业务摘要其次，明细、发票、附件、合同文件、资产材料、回单等证据居中，审批/处理历史靠后，当前动作面板固定在 PC 右侧或移动端底部。高风险动作不得放在用户看不到证据的位置，确认时必须展示对象摘要和后果。
+
+全系统证据材料统一在详情页集中处理。列表页和台账页只显示发票、附件、合同文件、回单、资产材料等证据的完整性摘要、缺失提示和进入详情入口，不直接承接预览、下载、删除、批量打包或敏感材料处理；这些动作进入详情页、详情命令区、台账工具或授权审计路径。
+
+全系统上传材料采用“材料类型先行”。上传前必须明确是 PDF 发票、普通附件、合同文件、付款回单、验收材料、资产材料还是电子资料索引，不使用一个万能 `上传附件` 入口混收所有材料；不同类型分别进入对应校验、权限、审计和展示位置，上传文案必须说明结果。
+
+移动端只承接轻动作，不复制 PC 管理台。手机和企业微信 WebView 主要用于提交、补材料、查状态、处理待办、扫码、上传和消息直达；不承接复杂台账、全范围管理、批量导出、批量审批、批量付款、流程配置、管理配置、功能开关、复杂筛选和大表格。移动页面统一采用顶部状态/焦点卡、卡片列表或分区详情、底部安全区主动作。
+
+待办和通知必须分离。`待我处理` 是行动列表，只放需要当前用户处理的事项；`通知中心` 是事件收件箱，只记录状态变化、提醒、失败、同步结果和流转消息。通知点击直达业务详情、审批任务或失败解释页，不在通知中心复制一套待办处理列表；普通通知、已完成动态和只读进度不算工作台 `今日待处理`。
+
+敏感数据默认最小展示。合同正文、发票、回单、付款信息、资产敏感字段、附件和导出文件只在授权场景展示必要内容；预览、下载、导出和批量下载必须按服务端权限和数据范围控制，并对财务、合同、票据、资产等高敏操作写审计。普通列表、移动端、通知和企业微信消息只展示脱敏摘要。
+
+危险动作必须二次确认且展示对象和后果。删除、付款、发布、停用、作废、驳回、退回、切换配置、批量处理等不可逆或高风险动作，确认面板必须包含对象摘要、后果、影响范围、必要理由输入或确认输入，并写入审计；不允许只弹一句 `确定吗？`。
+
+集成和外部系统状态必须保守表达。OA 主办报销、采购、合同、项目、付款、AP、票据、资产和高敏附件；企业微信主办打卡、请假、补卡、外出、加班等 HR/考勤日常动作；ERP、银行、代账、OCR、企业微信消息等外部系统只展示真实同步状态、失败原因和下一步，不在界面上承诺无法确认的 `已同步`、`已付款` 或 `已审批`。
+
+试运行和验收口径必须准确。本地构建、Playwright 和截图通过只代表本地验证通过；只有完成部署、公网访问检查、关键路径冒烟和必要截图证据后，才可告知用户 `可以线上测试`。未部署时只能说明 `本地验证通过，尚未线上可测`。
+
+固定资产按统一资产台账的 `FA` 类型管理，产品口径是实物责任、流转、盘点和离职交接，不是完整财务固定资产账。电脑、显示器、硬盘、设备、安全介质等需要归还或盘点的实物应登记；普通耗材不登记；折旧、残值、会计科目和月度折旧凭证暂由财务/代账系统主办，OA 只记录采购来源、责任链、状态和交接证据。
+
+采购/报销到固定资产的衔接采用“资产候选 + 管理员建卡”。采购明细或报销材料只提供可能形成资产的线索；审批通过、报销提交或付款完成都不自动生成资产卡片。管理员在到货、验收或报销完成后核对实物、数量、归属、是否耗材、是否退货/赠品，再手动创建 `FA` 资产卡片并关联来源单据。
+
+固定资产必须有 `FA` 资产编号。电脑、显示器、硬盘、设备、安全介质等可贴标实物应贴二维码标签，用于移动扫码查找、盘点和领用/归还确认；不适合贴标签的资产不强制贴，但必须记录序列号、保管人和位置。盘点以扫码优先、手工输入兜底，不强制复杂拍照盘点。
+
+固定资产盘点采用轻量频率。小团队 V1 默认每季度做一次固定资产轻盘点；离职、调拨、维修、报废等事件发生时做事件盘点；备份硬盘、安全介质和关键设备每月确认一次责任人和位置。
+
+固定资产处置采用“流转留痕、处置确认”。领用、归还、调拨由管理员直接记录并留痕；报废、丢失、出售、赠送必须负责人确认并填写原因；涉及赔偿、金额或责任争议时另走审批或线下确认，资产页只记录结果和证据摘要，不一键完成争议处理。
+
+电子资产只做责任和验证索引。代码仓库、系统、备份介质/集合在 OA 中只登记元数据、负责人、权限回收要求、备份/恢复验证日期和归档位置摘要；不保存源码包、密钥、token、完整配置、真实完整路径或备份内容。
+
+电子资料资产 `EA-DOC` 只登记资料名称、类型、hash/校验摘要、敏感级别、负责人、关联项目/合同/付款和归档位置摘要。合同正文、银行流水、证照原件、客户资料等高敏原文不进普通资产页，必须走对应业务附件权限或线下受控归档。
+
 ## OA 与企业微信边界
 
 - `OA 主办`：报销、采购、费用、合同、项目、付款、AP、代账和高敏附件仍在 OA 内提交、审批、查看和导出；企业微信只发送脱敏消息和 OA deeplink。
@@ -44,6 +110,9 @@ A 类页面优先保证真实试运行路径顺畅；B 类页面优先保证台
 - 普通用户主展示使用业务编号或业务摘要，不把 UUID、taskId、entityId、内部状态码或调试字段作为主编号。
 - 审计页、管理员排障页和打印留痕页可在权限允许范围内展示必要内部编号。
 - 同一业务对象在同一区域只展示一次主标识；同一状态在同一区域只展示一次。
+- 普通路径不展示权限 code、role code、接口路径、数据库字段名、原始 payload、完整本地路径、调试 trace、Secret 或 token；审计/排障场景也只能最小必要展示。
+- 技术枚举和平台词必须翻译成自然中文。普通用户默认看到的是 `审批中`、`待你处理`、`已支付`、`发票识别失败`，而不是 `PENDING_APPROVAL`、`Workflow`、`AP Operations` 或 `Feature Flag`。
+- 时间文案优先表达业务含义，例如 `已等待多久`、`接收于`、`提交于`、`支付于`，不把 `更新时间` 当作用户主要判断依据。
 - 通知中心是事件收件箱，不是待办列表或进度页副本；通知点击应直达业务详情、审批任务或可解释的失败提示。
 - 首页只做工作台摘要，不重复完整待办列表、通知列表和进度列表。
 - 首页首屏优先展示 `今日待处理`：覆盖所有需要当前用户行动的事项，例如待审批、待补材料、待付款/待复核、票据异常、配置缺口和明确分配给当前用户的团队动作；普通通知、已完成进度、只读动态和低频管理入口不算待处理。
@@ -52,13 +121,14 @@ A 类页面优先保证真实试运行路径顺畅；B 类页面优先保证台
 - 首页不承担常驻新手教学职责；首次欢迎提示只做一次性、可关闭的常用业务入口，最多 3 个，不放个人设置、通知中心或“了解流程”这类说明型入口。
 - 审批入口同时服务审批人和发起人：审批人处理待我审批，员工查看我发起的进度。
 - 普通员工不应看到不可点或无权限的审批入口；审批、财务、负责人和管理员只能看到服务端允许的动作。
-- 个人设置默认只放账号信息、通知设置和企业微信绑定；组织归属、直属汇报和角色摘要可折叠展示，不默认暴露权限 code 或完整员工档案维护内容。
-- PC 侧边栏是小团队任务入口，不是全量模块目录；一级入口必须按角色、权限、频次和真实待办价值收敛，新增功能默认不得直接进入一级侧边栏。
+- 个人设置默认只放个人资料、密码/安全、通知偏好和企业微信绑定；组织归属、直属汇报和角色摘要可折叠展示，不默认暴露权限 code 或完整员工档案维护内容。
+- 个人设置和管理配置彻底分离：组织、角色、审批规则、功能开关、主数据、审计日志、人员维护和系统配置统一进入 `管理`，不出现在普通员工路径或个人资料页里。
+- PC 侧边栏是小团队任务入口，不是全量模块目录；一级入口必须按角色、权限、频次和真实办事价值收敛。已启用且有权限的 OA 主办业务台账，例如 `合同`、`采购`、`资产`、`项目`，不默认藏到 `更多`，否则会给常用业务增加二次点击负担。
 - 审批人、负责人和财务看到 `待我处理`；普通员工默认不显示 `待办` 或 `审批待办` 入口；通知只保留顶部铃铛或通知中心，不进入侧边栏。
 - PC 请假入口默认表达为 `请假记录`；提交请假、补卡、外出、加班仍优先走企业微信或移动入口，只有 OA 应急接管或指定管理场景才突出提交入口。
 - 管理配置类能力在侧边栏合并为 `管理`，具体人员、组织、流程、规则、审计、功能开关和外部系统入口进入管理页后分组承接。
 - 财务入口应使用真实工作名，例如 `付款`、`应付账款`、`票据`；`AP 运营`、`ERP 集成`、`功能开关` 等内部平台词不作为默认一级菜单文案。
-- `更多` 只承载低频入口，不使用说明型副标题、教学卡片或历史模块解释文案。
+- `更多` 只承载低频、冻结、阶段性或偶尔查看的入口，不使用说明型副标题、教学卡片或历史模块解释文案；不得把常用业务台账作为默认二级入口。
 
 ## 业务体验事实
 
@@ -68,6 +138,13 @@ A 类页面优先保证真实试运行路径顺畅；B 类页面优先保证台
 - 发票状态文案面向用户表达，例如识别中、识别失败、可添加、已添加、重复票据、已归档/已报销；不暴露 OCR provider、绑定整单、不绑定明细等内部术语。
 - 请假、补卡、外出、加班的员工日常主路径优先走企业微信；OA 负责镜像、审计、异常和应急接管。
 - 采购、合同、项目、财务附件和高敏资料不迁移到企业微信原生审批或企业微信附件。
+- 资产管理保留统一资产台账：固定资产 `FA` 负责实物责任和交接，电子资料/系统/仓库/备份资产负责索引、负责人和验证证据；账号密码、密钥、源码包和完整配置不进入 OA。
+- 采购/报销只作为资产候选来源，不自动入库或自动生成固定资产；资产建卡必须由管理员核对实物后完成。
+- 固定资产盘点优先使用资产编号和二维码标签；无法贴标时使用序列号、保管人和位置兜底。
+- 固定资产常规盘点默认按季度执行；离职、调拨、维修、报废触发事件盘点；高风险实物资产按月确认责任人和位置。
+- 固定资产报废、丢失、出售、赠送等处置必须负责人确认和填写原因；涉及赔偿或争议时不在资产页一键完成。
+- 电子资产页面只展示责任人、权限回收、备份/恢复验证和归档摘要，不展示或存储源码、密钥、完整配置、真实路径和备份内容。
+- `EA-DOC` 是资料索引和责任记录，不是文件库；高敏原文和业务原文按对应模块权限或线下归档处理。
 - 差旅仍不进入当前主线扩展；如恢复差旅能力，必须先新建独立 Trellis task。
 
 ## 验收边界
diff --git a/docs/报销发票附件规则.md b/docs/报销发票附件规则.md
index 224cece6..d8e1991f 100644
--- a/docs/报销发票附件规则.md
+++ b/docs/报销发票附件规则.md
@@ -11,9 +11,11 @@ R5 公网验收后确认：正式发票/OCR 上传入口只接受 PDF 发票文
 - PC 与手机功能一致，只允许布局和控件形态不同。
 - 普通员工看到的是“添加发票”“上传附件”“提交审批”，不看到“绑定整单”“发票池”“ERP 同步”等内部概念。
 - 发票是报销凭证，附件是补充材料，二者不能混用。
+- 报销上传采用材料类型先行：PDF 发票走“添加/上传 PDF 发票”入口，支付截图、订单、聊天记录、情况说明等走“上传附件/补充材料”入口，付款回单走财务付款或回单入口，不混成一个万能上传框。
 - 已经报销、他人已报销、重复上传的发票不能加入新的报销单。
 - 服务端必须强约束，前端只负责友好提示。
 - 报销审批必须在 OA 内完成，企业微信只发送提醒和 deeplink，不作为报销审批流或财务附件主库。
+- 财务台账 V1 只做付款准备、付款批次、回单留痕、AP 状态、票据/OCR 状态和代账交接摘要；真实付款继续在线下银行或既有财务流程完成，OA 不做银行直连、银行流水自动导入、ERP/总账、凭证生成、自动对账或税务申报。
 
 ## 发票状态
 
@@ -97,6 +99,7 @@ R5 公网验收后确认：正式发票/OCR 上传入口只接受 PDF 发票文
 
 - 草稿和驳回状态允许移除发票，移除后发票回到可用状态。
 - 审批中使用撤回，不提供删除。
+- 已提交后的报销单原则上不物理删除；业务不再继续用取消，已支付或已归档后只允许按权限追加修正或作废留痕。
 - 已通过、已支付、已归档的报销单不允许普通用户删除。
 - 删除草稿时，已添加发票应释放为可用，附件随报销单删除。
 
@@ -110,11 +113,15 @@ R5 公网验收后确认：正式发票/OCR 上传入口只接受 PDF 发票文
 - 支持多文件上传。
 - 不参与发票 OCR。
 - 不参与发票查重。
+- 上传前必须明确附件类型或用途，例如支付截图、订单、聊天记录、情况说明、验收材料；不能把 PDF 发票、付款回单、合同正文和资产材料都作为普通附件混传。
 - 草稿和驳回状态可上传、查看、删除。
 - 提交后审批人和财务可查看。
 - 默认治理标签为“已通过 / 内部 / 补充材料 / 标准下载”；若附件实际属于合同、报价、验收、付款证明或其他敏感材料，应按对应业务对象上传，不要混在普通报销补充材料里。
 - 报销附件可以保存业务办理所需原文，但只限报销人、审批人、财务和被授权角色按职责查看；自动化报告、企业微信消息、聊天和 AI/Codex 处理只能使用脱敏摘要或别名。
 - 敏感或 `reason_required` 附件下载必须填写用途并写入审计日志；普通员工不得批量下载他人报销附件。
+- 报销列表只显示发票和附件的完整性摘要、缺失提示和进入详情入口；发票预览、附件查看/下载/删除、敏感材料用途填写和批量打包必须进入报销详情、财务台账工具或授权审计路径。
+- 报销页只显示付款状态、回单状态、查看付款或补回单入口；标记已付款、取消付款、批量付款和执行付款必须进入付款/财务处理详情，不能放在报销列表或普通报销详情里直接执行。
+- 报销页展示项目、采购、合同、资产候选或付款记录时只显示摘要和跳转，不复制对方模块的审批、付款、合同正文下载、资产建卡或高敏附件操作。
 
 ## PC 与手机体验
 
diff --git a/docs/需求-合同附件归档规约.md b/docs/需求-合同附件归档规约.md
index 6bb6bc9a..c4038808 100644
--- a/docs/需求-合同附件归档规约.md
+++ b/docs/需求-合同附件归档规约.md
@@ -3,12 +3,12 @@
 **版本**：1.0
 **日期**：2026-05-09
 **状态**：模块级开发规约
-**补充口径**：OPOLICY1 后，合同/用印先按小团队 V1 执行；V1 通过合同台账、归档位置、离线档案号、非涉密证明和审计承载，不立即上电子签章或完整法务系统。
+**补充口径**：OPOLICY1 后，合同/用印先按小团队 V1 执行；V1 通过合同台账、归档位置、离线档案号、非涉密证明、到期提醒和审计承载，不立即上电子签章、复杂法务审查、条款库、版本协同或完整 CLM。
 **上级事实源**：[海音达OA-MVP需求规格说明书](./海音达OA-MVP需求规格说明书.md)
 **审批总依据**：[需求 - 统一审批中心规约](./需求-统一审批中心规约.md)
 **体验事实依据**：[产品体验事实源](./产品设计规则.md)；视觉与交互裁决以 `frontend-design` 为准。
 
-本规约细化合同台账、合同编号、非涉密附件、归档位置、权限审计和业务关联要求。合同审批、合同变更审批和归档动作仍回到 OA 统一审批中心留痕；PC 和移动页面职责以产品体验事实源为依据；本规约不替代公司法务制度。
+本规约细化合同台账、合同编号、非涉密附件、归档位置、到期提醒、权限审计和业务关联要求。合同审批、合同变更审批和归档审批如果需要，走 OA 统一审批中心或后续独立 Trellis task；合同台账页本身不自建审批流。PC 和移动页面职责以产品体验事实源为依据；本规约不替代公司法务制度。
 
 ---
 
@@ -19,6 +19,7 @@
 - 建立公司合同台账，避免合同编号、负责人、状态和归档位置分散在个人电脑或聊天记录中。
 - 将合同与客户/供应商、项目、采购、费用、报销和交付记录关联起来。
 - 对非涉密附件进行受控归档，并对查看、下载和归档动作留审计。
+- 提供到期、续签、待归档和关联缺失提醒，帮助小团队少漏事。
 - 明确涉密资料不进入公网 OA 的边界，降低小团队试运行风险。
 
 ### 1.2 适用对象
@@ -33,9 +34,10 @@
 
 ### 1.3 暂不做范围
 
-- 首批不做电子签章、在线法务审查、红线对比或合同智能审阅。
+- 首批不做电子签章、在线法务审查、红线对比、条款库、版本协同或合同智能审阅。
 - 首批不做合同自动履约、自动催收、收付款核销或 ERP 入账。
-- 首批不做客户关系管理 CRM、供应商生命周期管理或完整法务系统。
+- 首批不做客户关系管理 CRM、供应商生命周期管理、完整法务系统或完整 CLM。
+- 首批不在合同台账页自建复杂合同审批流；审批如需启用，走 OA 统一审批中心或后续独立任务。
 - 涉密合同正文、敏感报价、成本细节、客户敏感资料不进入公网 OA。
 - 不使用企业微信原生审批管理正式合同审批。
 - 合同正文、合同附件、报价、供应商资料和涉密归档信息不上传到企业微信原生审批或企业微信附件；企业微信只做脱敏提醒和 OA deeplink。
@@ -56,7 +58,7 @@
 
 | 角色 | 主要动作 | 权限边界 |
 | --- | --- | --- |
-| 合同负责人 | 新建合同台账、维护基本信息、上传允许上传的附件、发起审批或归档 | 只能维护自己负责或被授权的合同 |
+| 合同负责人 | 新建合同台账、维护基本信息、上传允许上传的附件、按规则发起归档或审批入口 | 只能维护自己负责或被授权的合同 |
 | 项目负责人 | 查看与项目相关合同、确认项目关联、补充交付或验收信息 | 不能越权下载无关合同附件 |
 | 财务 | 查看金额、付款条款、发票或收付款相关字段，参与财务复核 | 只处理财务范围字段和复核动作 |
 | 老板/总经理 | 审批重大合同或高风险变更，查看公司级合同摘要 | 查看和下载仍需审计 |
@@ -74,10 +76,14 @@
 | 合同台账列表 | 按编号、名称、客户/供应商、项目、负责人和状态查询 | 支持基础筛选和权限数据范围 |
 | 合同详情页 | 查看合同字段、附件、审批历史、变更记录和业务关联 | 不展示无权限字段和附件 |
 | 项目页合同区域 | 汇总项目相关合同 | 只展示当前用户有权查看的合同摘要 |
-| 审批待办 | 处理合同审批、变更审批或归档审批 | 统一进入 OA 审批中心 |
-| 移动端详情 | 查看摘要和处理待办 | 不做复杂合同编辑，优先支持审批和查看摘要 |
+| 审批待办 | 如未来启用合同审批、变更审批或归档审批，在待办中处理 | 统一进入 OA 审批中心；合同台账不自建审批工作台，不直接放审批动作 |
+| 移动端详情 | 查看摘要、到期/归档状态和必要待办入口 | 不做复杂合同编辑，不做完整法务审查 |
 
-合同台账是首批核心。合同正文是否上传取决于敏感级别和公司制度；不能上传时，应登记线下归档位置。
+合同台账是首批核心，职责限定为登记、归档、到期/续签提醒和关联项目/采购/付款。合同正文是否上传取决于敏感级别和公司制度；不能上传时，应登记线下归档位置。
+
+合同列表只显示附件完整性、归档状态、到期/续签提醒和进入详情入口；合同文件预览、附件查看/下载/删除、归档动作、敏感材料用途填写和批量打包必须进入合同详情、详情命令区、台账工具或授权审计路径。
+
+合同审批、变更审批和归档审批如启用，审批动作集中在 `待我处理`、审批详情或移动审批详情执行。合同台账和普通合同详情只显示审批状态、当前节点、历史、`查看处理`、`查看进度` 或进入审批任务入口，不直接放 `通过`、`驳回`、`退回`、`转审`。
 
 ---
 
@@ -116,6 +122,8 @@
 | 可见范围 | 必填，由权限规则计算或管理员配置 |
 | 下载次数和最近下载人 | 推荐记录 |
 
+合同上传必须先明确附件类型，例如合同扫描件、盖章页、补充协议、验收单、报价摘要或归档证明。不同类型适用不同敏感级别、可见范围、下载用途和审计规则；合同文件不进入普通报销附件、普通采购附件或资产材料的万能上传入口。
+
 ### 4.3 变更记录字段
 
 | 字段 | 要求 |
@@ -155,15 +163,17 @@
 
 | 状态 | 含义 | 允许动作 |
 | --- | --- | --- |
-| 拟稿 | 合同信息录入中，未正式提交审批或签署 | 保存、提交审批、删除草稿 |
-| 审批中 | 合同或关键变更正在 OA 审批 | 审批、退回、驳回、转审、按规则撤回 |
+| 拟稿 | 合同信息录入中，未正式提交审批或签署 | 保存、按规则提交审批或转入登记、删除草稿 |
+| 审批中 | 合同或关键变更正在 OA 统一审批中心处理 | 在待我处理/审批详情中审批、退回、驳回、转审、按规则撤回 |
 | 已签署 | 合同已签署但履行尚未完成 | 上传允许附件、登记签署日期、进入履行 |
 | 履行中 | 合同正在执行 | 关联项目、采购、费用、验收、收付款摘要 |
 | 已完成 | 合同义务完成 | 归档、查看、导出摘要 |
 | 已终止 | 合同提前终止或作废 | 记录原因、附件和审批记录 |
 | 已归档 | 合同资料已完成归档 | 普通字段锁定，后续修正追加记录 |
 
-拟稿、审批中、已驳回、已退回、已撤回等通用审批状态按统一审批中心语义处理；合同台账展示时可映射为以上合同业务状态。
+合同删除、撤回、取消、作废和归档语义遵循产品体验事实源：拟稿且未提交/未登记的合同可删除草稿；审批中按规则撤回；合同谈判不继续可取消拟办；已编号、已签署或已生效合同失效必须用作废或终止，不释放合同编号重用；归档后普通字段锁定，修正只能追加记录并留审计。
+
+拟稿、审批中、已驳回、已退回、已撤回等通用审批状态只有在启用合同审批时才按统一审批中心语义处理；合同台账展示时可映射为以上合同业务状态。
 
 ---
 
@@ -180,7 +190,7 @@
 | 合同终止 | 是 | 必须记录终止原因和审批历史 |
 | 合同归档 | 可按规则 | 归档动作必须留痕，敏感附件下载需审计 |
 
-合同审批链建议采用负责人主管 -> 老板/总经理，财务按金额或付款条款参与复核。当前阶段不做并行会签。
+合同审批链不是合同台账 V1 的内置能力。如后续启用，建议仍由统一审批中心配置为负责人主管 -> 老板/总经理，财务按金额或付款条款参与复核；当前合同台账页不做并行会签或法务会签工作台。
 
 ---
 
@@ -212,12 +222,16 @@
 
 | 模块 | 关系 |
 | --- | --- |
-| 统一审批中心 | 合同审批、变更、终止和归档按统一审批留痕 |
+| 统一审批中心 | 如启用合同审批、变更、终止或归档审批，统一在审批中心留痕；合同台账只展示状态和跳转 |
 | 采购/费用 | 大额采购可关联合同；合同可查看相关采购/费用申请 |
 | 报销/OCR | 合同相关报销或付款附件可关联合同摘要，但发票处理仍由报销规约管理 |
 | 项目轻管理 | 项目页汇总相关合同、里程碑、交付和风险 |
 | 企业微信 | 只发送脱敏通知：合同编号、标题、状态和 deeplink |
 
+合同页的跨模块关联采用“摘要 + 跳转”：可以展示项目、采购、报销、付款/AP 和验收对象的编号、名称、状态、金额、负责人、证据完整性和下一步，但不在合同页复制采购审批、报销发票/OCR、项目任务管理、付款处理或资产处置流程。需要处理时跳转到对应业务详情、审批任务或财务处理页。
+
+合同台账和普通合同详情只显示付款条款、付款状态、回单状态、`查看付款` 或进入付款记录入口，不直接放 `标记已付款`、`取消付款`、`批量付款`、`执行付款`。合同相关付款准备、回单留痕和付款修正统一进入付款/财务处理详情，并按财务权限和审计执行。
+
 企业微信通知不得包含合同正文、报价明细、供应商敏感资料、附件原文或线下归档位置的完整细节；点击后必须回到 OA，并按 OA 权限查看摘要或附件。
 
 ---
@@ -258,11 +272,11 @@
 | 场景 | 步骤 | 预期结果 |
 | --- | --- | --- |
 | 新建合同台账 | 负责人填写合同名称、客户、项目、金额、负责人和归档位置 | 合同保存为拟稿，编号唯一 |
-| 合同审批 | 负责人提交合同审批；主管或老板处理 | 审批历史完整，状态从拟稿进入审批中再到已签署或已通过业务态 |
+| 合同审批（如启用） | 负责人从统一审批中心提交合同审批；主管或老板处理 | 审批历史完整，合同台账只展示状态和跳转，不自建审批工作台 |
 | 历史合同补录 | 管理员录入历史编号和线下归档位置 | 编号唯一校验通过，可标记已归档 |
 | 涉密合同处理 | 用户尝试上传涉密正文 | 系统提示不进入公网 OA，要求登记线下归档位置 |
 | 附件下载审计 | 有权限用户下载非涉密附件 | 下载成功，审计记录包含人员、时间和附件 |
-| 合同变更审批 | 修改金额或期限并发起变更 | 变更前后值和审批历史可追溯 |
+| 合同变更审批（如启用） | 修改金额或期限并从统一审批中心发起变更 | 变更前后值和审批历史可追溯，合同台账只保留摘要 |
 | 项目关联查看 | 合同关联项目；项目页查看合同摘要 | 项目页只展示有权限合同摘要 |
 | 归档后修正 | 管理员修改归档位置并填写原因 | 不覆盖历史，追加修正记录 |
 
@@ -272,7 +286,7 @@
 
 1. 合同台账数据模型、编号规则和历史合同补录。
 2. 合同列表、详情、创建和编辑页面。
-3. 合同审批、变更审批和终止审批接入统一审批中心。
+3. 如需要合同审批、变更审批和终止审批，另建任务接入统一审批中心。
 4. 非涉密附件上传、下载权限和审计。
 5. 敏感级别、线下归档位置和上传阻断提示。
 6. 项目、采购、费用、报销的业务关联。
@@ -284,7 +298,7 @@
 ## 14. 后续 Backlog
 
 - 电子签章、合同在线签署和签署状态同步。
-- 法务审查、红线对比和合同模板库。
+- 法务审查、红线对比、合同模板库、条款库和版本协同。
 - 履约计划、收付款核销、自动提醒和 ERP 入账。
 - CRM、供应商生命周期和合同风险评分。
 - 合同智能审阅、条款抽取和 AI 摘要。
diff --git a/docs/需求-报销发票OCR规约.md b/docs/需求-报销发票OCR规约.md
index a0f3d39e..270d26e7 100644
--- a/docs/需求-报销发票OCR规约.md
+++ b/docs/需求-报销发票OCR规约.md
@@ -3,6 +3,7 @@
 **版本**：1.0
 **日期**：2026-05-09
 **状态**：模块级开发规约
+**补充口径**：财务台账 V1 只做付款准备、付款批次、回单留痕、AP 状态、票据/OCR 状态和代账交接摘要；不做银行直连真实支付、银行流水自动导入、ERP/总账、凭证生成、自动对账、税务申报或完整财务软件。
 **上级事实源**：[海音达OA-MVP需求规格说明书](./海音达OA-MVP需求规格说明书.md)
 **细则来源**：[报销、发票与附件规则](./报销发票附件规则.md)
 
@@ -15,8 +16,8 @@
 ### 1.1 目标
 
 - 员工能在 PC、手机和企业微信入口快速创建报销、上传发票和附件、提交审批。
-- 系统负责 OCR 识别、发票查重、发票与明细匹配、审批流接入和付款归档。
-- 财务能复核发票、处理重复例外、标记付款并导出财务台账。
+- 系统负责 OCR 识别、发票查重、发票与明细匹配、审批流接入、付款批次和回单留痕。
+- 财务能复核发票、处理重复例外、在线下完成付款后标记付款、维护回单和导出财务/代账交接摘要。
 - 报销审批必须进入 OA 统一审批中心，正式记录以 OA 为准。
 
 ### 1.2 暂不做范围
@@ -24,6 +25,7 @@
 - 不使用企业微信原生审批处理报销。
 - 不接入飞书报销、飞书审批或飞书文档归档。
 - 首批不做银行自动付款、企业卡自动对账、ERP 自动入账。
+- 首批不做银行直连真实支付、银行流水自动导入、ERP/总账、凭证生成、自动对账、税务申报或完整财务软件。
 - 首批不做复杂预算占用和多币种核算。
 - 首批不把企业微信文件作为发票或附件长期主库。
 - 报销单、发票原件、附件、银行回单、付款资料和代账交接资料不上传到企业微信原生审批或企业微信附件；企业微信只做脱敏提醒和 OA deeplink。
@@ -37,8 +39,8 @@
 | 角色 | 可做动作 | 权限边界 |
 | --- | --- | --- |
 | 员工/申请人 | 创建草稿、上传发票、上传附件、编辑明细、提交审批、查看自己的报销状态 | 只能操作本人可见的报销单和本人上传或授权使用的发票 |
-| 审批人 | 查看待办、查看发票和附件摘要、通过、驳回、退回、转审 | 只能处理分配给自己的 OA 审批任务 |
-| 财务 | 查看审批通过的报销、复核发票、处理重复例外、标记付款、导出 | 不默认拥有系统管理权限；例外动作必须审计 |
+| 审批人 | 查看待办、查看发票和附件摘要，在待我处理/审批详情中通过、驳回、退回、转审 | 只能处理分配给自己的 OA 审批任务；报销列表和普通报销详情不直接放审批动作 |
+| 财务 | 查看审批通过的报销、复核发票、处理重复例外、在线下付款后标记付款、维护回单、导出交接摘要 | 不默认拥有系统管理权限；例外动作必须审计 |
 | 财务主管 | 审核高风险或大额报销、审批重复例外、复核付款批次 | 权限应通过角色配置，不硬编码到个人 |
 | 管理员 | 维护费用类型、项目、部门、OCR 配置、权限和基础字典 | `admin` 不代表业务审批权，不能绕过流程直接替员工完成正式审批 |
 
@@ -52,6 +54,8 @@
 | 票据或发票添加弹窗 | 从报销草稿中添加发票 | 普通员工只看到“添加发票”，不暴露“发票池”等内部概念 |
 | 财务导出页 | 财务按期间、人员、项目、状态导出 | 导出前必须校验财务权限 |
 
+报销审批动作集中在 `待我处理`、审批详情或移动审批详情执行。报销列表和普通报销详情只显示审批状态、当前节点、历史、`查看处理`、`查看进度`、`补材料` 或进入审批任务入口，不直接放 `通过`、`驳回`、`退回`、`转审`。
+
 ---
 
 ## 3. 报销单对象与字段
@@ -285,6 +289,7 @@ BIZ8 阶段的图片 OCR 结论是“技术可行，但当前不开放为正式
 - 支持多文件上传。
 - 不参与 OCR。
 - 不参与发票查重。
+- 上传材料必须先明确类型：PDF 发票走发票/OCR 入口，支付截图、订单、聊天记录、情况说明、验收材料走普通附件入口，付款回单走财务回单入口；不同类型适用不同校验、权限、审计和展示位置，不使用万能附件入口混收。
 - 草稿和已退回状态允许上传、查看、删除。
 - 审批中、已通过、已付款、已完成状态原则上不允许普通员工删除。
 - 审批人和财务在处理报销时可查看附件。
@@ -298,11 +303,15 @@ BIZ8 阶段的图片 OCR 结论是“技术可行，但当前不开放为正式
 | --- | --- | --- |
 | 财务复核 | 报销已通过或进入财务复核节点 | 检查发票、附件、金额、项目和审批历史 |
 | 重复例外 | 发现重复但业务确需报销 | 记录原单号、原因和处理人，写入审计 |
-| 付款标记 | 审批通过且复核通过 | 写入付款批次号、付款时间、付款人、付款备注和状态 |
+| 付款标记 | 审批通过且复核通过，且线下银行或既有财务流程已完成付款 | 写入付款批次号、付款时间、付款人、付款备注、回单摘要和状态 |
 | 取消付款标记 | 发现误操作且有权限 | 必须填写原因并审计，首批可只允许管理员或财务主管 |
 | 导出 | 有财务导出权限 | 按期间、人员、项目、状态导出报销和发票摘要 |
 
-导出字段至少包括：报销单号、申请人、实际报销人、部门、项目、费用类型、明细金额、发票号码、开票日期、审批状态、付款状态、提交时间、通过时间、付款批次号、付款时间、付款人、付款备注、导出批次号、导出人、导出时间。
+报销付款相关动作集中在 `付款`、财务处理详情或付款批次详情执行。报销列表和普通报销详情只显示付款状态、回单状态、`查看付款`、`补回单` 或进入付款记录入口，不直接放 `标记已付款`、`取消付款`、`批量付款`、`执行付款`；付款动作前必须核对金额、报销对象、线下付款说明、发票/附件证据和回单要求。
+
+报销页的跨模块关联采用“摘要 + 跳转”：可以展示项目、采购/费用申请、合同、资产候选和付款记录的编号、名称、状态、金额/数量、负责人、证据完整性和下一步，但不在报销页复制项目管理、采购审批、合同正文下载、资产建卡或付款处理流程。需要处理时跳转到对应模块详情、审批任务或财务处理页。
+
+导出字段至少包括：报销单号、申请人、实际报销人、部门、项目、费用类型、明细金额、发票号码、开票日期、审批状态、付款状态、提交时间、通过时间、付款批次号、付款时间、付款人、付款备注、回单状态、导出批次号、导出人、导出时间。导出是代账交接和审计摘要，不代表 OA 已生成会计凭证或写入总账。
 
 ### 9.1 电子档案与归档包
 
@@ -315,12 +324,14 @@ BIZ8 阶段的图片 OCR 结论是“技术可行，但当前不开放为正式
 | OCR 结果 | 保留识别字段、识别状态、失败原因和人工修正记录 |
 | 附件 | 保留支付截图、订单、合同、聊天记录、情况说明等非发票材料 |
 | 审批历史 | 保留提交、通过、驳回、退回、撤回、转审和处理意见 |
-| 付款记录 | 保留付款批次号、付款人、付款时间、付款备注和取消付款原因 |
+| 付款记录 | 保留付款批次号、付款人、付款时间、付款备注、回单摘要和取消付款原因 |
 | 导出记录 | 保留导出批次号、导出人、导出时间、筛选条件和导出摘要 |
 | 审计日志 | 保留重复例外、人工复核、附件下载、字段修正、权限变更等敏感动作 |
 
 归档后普通员工不可修改核心字段。确需财务修正时，必须追加修正记录，不覆盖原始归档事实。
 
+报销删除、撤回、取消、作废和归档语义遵循产品体验事实源：草稿可删除；审批中按规则撤回；业务不继续报销用取消；已支付、已归档或需要冲销留痕的异常对象用作废或追加修正记录，不物理删除；所有非草稿终止动作保留原因、操作者、时间和审计。
+
 ---
 
 ## 10. 异常规则
@@ -335,6 +346,7 @@ BIZ8 阶段的图片 OCR 结论是“技术可行，但当前不开放为正式
 | 识别中提交 | 若关键字段未完成，不允许提交 | “发票仍在识别中，请稍后再提交” |
 | 附件缺失 | 按费用类型、金额或审批要求判断 | “请补充必要附件” |
 | 已付款后修改 | 普通用户不可修改；财务修正必须审计 | “已付款报销单不可修改” |
+| 银行/ERP 未接入 | 页面不得显示自动支付、自动入账或已同步完成 | “请在线下银行完成付款后回填回单；代账交接按导出摘要处理” |
 | 文件上传失败 | 不生成空附件或空发票记录 | “上传失败，请重新上传” |
 | 通知失败 | 不影响报销提交或审批结果 | 管理员在通知记录中查看失败原因 |
 
@@ -381,8 +393,8 @@ BIZ8 阶段的图片 OCR 结论是“技术可行，但当前不开放为正式
 | 多明细金额匹配 | 草稿有多条明细，发票金额唯一匹配其中一条 | 发票自动绑定匹配明细 |
 | 无法匹配创建明细 | 发票金额存在但无唯一明细 | 系统创建新明细或提示用户确认 |
 | 提交审批 | 员工补齐明细、发票、附件后提交 | 报销进入 OA 审批中，生成审批历史和待办 |
-| 审批通过到付款 | 审批人通过，财务复核并标记付款 | 报销状态进入已通过或已付款，付款记录可追溯 |
-| 财务导出 | 财务按期间和状态导出 | 导出包含报销、发票、审批和付款摘要字段 |
+| 审批通过到付款 | 审批人通过，财务复核，线下付款后标记付款 | 报销状态进入已通过或已付款，付款和回单记录可追溯 |
+| 财务导出 | 财务按期间和状态导出 | 导出包含报销、发票、审批、付款和回单摘要字段，不生成总账凭证 |
 | 重复阻断 | 员工上传已报销发票 | 系统阻断添加并显示可理解原因 |
 | 重复例外 | 财务主管处理特殊重复票据 | 记录原单号、原因、处理人和审计日志 |
 | OCR 失败处理 | 上传无法识别文件 | 显示失败原因，允许重试或人工补全 |
@@ -401,7 +413,7 @@ BIZ8 阶段的图片 OCR 结论是“技术可行，但当前不开放为正式
 - A4：发票与明细自动匹配、金额不一致提示和人工修正。
 - A5：附件上传、查看、删除和归档权限。
 - A6：报销接入统一审批中心，覆盖 PC、移动端、企业微信 deeplink。
-- A7：财务复核、付款标记、取消付款标记和导出。
+- A7：财务复核、付款批次、线下付款后的付款标记、回单留痕、取消付款标记和导出。
 - A8：报销主链路回归脚本和 Playwright PC/移动/企业微信 UA 验证。
 - A9：费用类型与材料要求矩阵落地，覆盖提交前预检和员工可理解提示。
 - A10：发票合规与人工复核落地，覆盖抬头税号、数电票号码、红冲/作废人工标记。
diff --git a/docs/需求-统一审批中心规约.md b/docs/需求-统一审批中心规约.md
index 812496ea..2632c320 100644
--- a/docs/需求-统一审批中心规约.md
+++ b/docs/需求-统一审批中心规约.md
@@ -135,10 +135,12 @@ OAFLOW1 后，OA 主办的报销审批规则增加 `ownerSelfFallbackRole`。当
 | --- | --- | --- | --- |
 | PC 审批待办 | `/workflow/tasks` | 审批人集中处理待办、已办、抄送或历史任务 | 应在 PC 主导航清晰可达 |
 | 移动审批 | `/mobile/approvals` | 手机端处理待办和查看审批历史 | 应适配企业微信 WebView 和普通手机浏览器 |
-| 业务详情页 | 报销、请假、采购、合同等详情页 | 从具体单据查看审批流和执行动作 | 状态、当前节点、历史记录必须与待办一致 |
+| 业务详情页 | 报销、请假、采购、合同等详情页 | 从具体单据查看审批流、进度和进入当前审批任务 | 状态、当前节点、历史记录必须与待办一致；不复制审批动作区 |
 | 企业微信消息 | deeplink 到 OA 页面或企微原生审批 | OA 主办审批回 OA，HR/考勤企微主办审批在企业微信处理 | 必须区分主办方，不把企微 HR 审批当作财务审批；OA 主办域附件不进入企微 |
 | Portal 待办摘要 | `/portal` 或首页卡片 | 提醒当前待处理数量 | 点击后进入 `/workflow/tasks` 或对应详情页 |
 
+审批动作承接位置统一为 `待我处理`、审批详情、移动审批详情或明确的当前任务处理面板。业务台账列表和普通业务详情只显示 `查看处理`、`查看进度`、`补材料` 或进入审批任务的入口，不直接放 `通过`、`驳回`、`退回`、`转审`。审批动作执行前必须展示同一套业务摘要、证据完整性、风险提示、后果说明和必要理由输入；批量审批默认不开放，后续启用必须另行定义后端资格标记、失败明细和审计语义。
+
 ### 3.2 任务列表要求
 
 - 待办列表至少展示：业务类型、业务编号、标题或摘要、申请人、金额或天数等关键值、当前节点、到达时间、状态。
diff --git a/docs/需求-资产管理规约.md b/docs/需求-资产管理规约.md
index 0360d1d3..d25b7a0f 100644
--- a/docs/需求-资产管理规约.md
+++ b/docs/需求-资产管理规约.md
@@ -47,12 +47,30 @@ OPOLICY1 后，资产台账先服务小团队 V1 的责任追踪、资料留存
 
 固定资产继续承接已有卡片、分类、领用、归还、调拨、盘点和移动扫码能力。适合电脑、显示器、仪器设备、办公家具、备份硬盘等可实物盘点资产。
 
+V1 管理口径以实物责任、流转、盘点和离职交接为准，不按完整财务固定资产账展开。需要归还、移交、盘点或承担安全责任的实物应登记为 `FA`；普通耗材不登记。折旧、残值、会计科目、月度折旧凭证和会计固定资产明细账暂由财务/代账系统主办；OA 只记录采购来源、业务编号、责任人/保管人、当前位置、流转状态、盘点结果和交接证据。
+
+采购/报销到固定资产的衔接采用“资产候选 + 管理员建卡”。采购明细或报销材料只标记可能形成资产的线索，不自动生成 `FA` 资产卡片。到货、验收或报销完成后，管理员核对实物、数量、归属、是否耗材、是否退货/赠品，再手动创建资产卡片并关联采购申请、报销单或付款来源。
+
+所有 `FA` 固定资产必须有资产编号。电脑、显示器、硬盘、设备、安全介质等可贴标实物应贴二维码标签，用于移动扫码查找、盘点、领用和归还确认。不适合贴标签的资产不强制贴，但必须记录序列号、保管人和位置；盘点以扫码优先、手工输入资产编号或序列号兜底，不强制复杂拍照盘点。
+
+固定资产盘点采用轻量频率。小团队 V1 默认每季度做一次固定资产轻盘点；离职、调拨、维修、报废等事件发生时做事件盘点；备份硬盘、安全介质和关键设备每月确认一次责任人和位置。盘点记录只要求资产、结果、责任人/位置变化和一句话备注，不强制复杂拍照盘点。
+
+固定资产处置采用“流转留痕、处置确认”。领用、归还、调拨由管理员直接记录并留痕。报废、丢失、出售、赠送等处置必须负责人确认并填写原因；涉及赔偿、金额或责任争议时另走审批或线下确认，资产页只记录确认结果、原因和证据摘要，不在资产页一键完成争议处理。
+
+### 电子资产共同口径
+
+`EA-DOC/EA-SYS/EA-REPO/EA-BKP` 只做责任、归档、权限回收和验证索引。代码仓库、系统、备份介质/集合在 OA 中只登记元数据、负责人、权限回收要求、备份/恢复验证日期和归档位置摘要；不保存源码包、密钥、token、完整配置、真实完整路径或备份内容。
+
+电子资产页面默认回答“谁负责、在哪里归档、何时验证、离职时如何回收权限或移交保管”。OA 不做文件库、密码库、源码托管、配置仓库或备份内容浏览器。
+
 ### 电子资料资产 `EA-DOC`
 
 电子资料只登记可控摘要和索引：资料名称、类型、hash、敏感级别、归档建议、负责人、关联项目/合同/付款摘要和脱敏外部引用。公网 OA 不上传 S3/S4 原文、真实完整路径、合同报价、银行账户、身份证件、账号凭据或未脱敏附件。
 
 `EA-DOC` 的职责是“索引和责任”，不是“文件夹同步”。公司资料主库继续保存全量原件、历史包和高敏材料；OA 只记录能支撑运营的最小元数据、复核状态、归档位置摘要和审计线索。
 
+`EA-DOC` 页面只展示资料名称、类型、hash/校验摘要、敏感级别、负责人、关联项目/合同/付款和归档位置摘要。合同正文、银行流水、证照原件、客户资料、高敏报价、工资社保、个人身份资料等高敏原文不进入普通资产页；业务必要原文走合同、报销、付款、项目等对应模块附件权限和下载审计，非业务必要高敏资料走线下受控归档。
+
 授权业务原文附件和 `EA-DOC` 索引要分开理解：
 
 | 对象 | 处理方式 |
@@ -61,6 +79,10 @@ OPOLICY1 后，资产台账先服务小团队 V1 的责任追踪、资料留存
 | 历史资料包、证照原件、高敏个人资料、工资社保、银行流水、客户原始资料 | 默认只建 `EA-DOC` 索引或线下受控归档，不进入普通业务附件区 |
 | 员工整理、外发复核、正式文件初审材料 | 进入任务/项目/待办协作，但默认使用脱敏副本、摘要或待确认清单 |
 
+资产列表只显示资产材料、盘点证据、归档索引和责任信息的完整性摘要、缺失提示和进入详情入口；资产材料预览、下载、删除、替换、批量打包、归档位置查看和敏感元数据处理必须进入资产详情、台账工具或授权审计路径。
+
+资产材料上传必须先明确材料类型，例如采购来源证明、领用/归还证明、盘点证据、处置证明、维修记录、电子资料索引或备份验证证据。不同类型适用不同权限、敏感级别、审计和展示位置；合同正文、发票原件、付款回单等业务原文仍走对应业务模块，不进入资产万能附件入口。
+
 历史目录第一轮只允许从 `/home/shunli/Projects/faculty-daily-assistant/公司/00_保密索引` 读取脱敏索引和元数据，默认 dry-run。公网写入真实索引必须另行确认并带写入开关。
 
 部署服务器空间不足时，不把普通办公电脑共享目录作为生产附件后端。优先顺序为：继续本地存储短期承载授权业务附件、只保存索引并由负责人线下调取原件、再评估腾讯云 COS 或受控 NAS/MinIO。家用群晖 NAS 可作为冷归档、备份或低风险 MinIO 试点；只有具备 VPN、私有 bucket、OA 服务账户、UPS、容量告警和备份恢复演练后，才可扩大使用范围。
@@ -96,6 +118,12 @@ OPOLICY1 后，资产台账先服务小团队 V1 的责任追踪、资料留存
 
 盘点不只面向实物。电子资料、系统、仓库和备份也要按周期记录“最近验证时间”，确认负责人、归档位置、备份策略和权限回收要求仍有效。
 
+固定资产常规盘点默认按季度创建；事件盘点由离职、调拨、维修、报废等状态变化触发；高风险实物资产按月确认责任人和位置。盘点逾期时页面应提示管理员处理，不自动改变资产状态。
+
+报废、丢失、出售、赠送等处置也应触发资产状态复核和必要盘点。若涉及赔偿、金额或责任争议，资产状态可先记录为待确认或异常，待审批/线下确认后再完成处置留痕。
+
+资产删除、取消、作废和归档语义遵循产品体验事实源：未提交的资产草稿或误建临时记录可删除；已编号 `FA/EA-*` 资产不物理删除，录入错误或不再有效用作废并保留编号、原因和操作者；实物不再使用按报废、丢失、出售、赠送等处置状态留痕；电子资料和电子系统完成交接或停用后归档只读，后续修正追加记录。
+
 ## 6. 当前实现边界
 
 ASSET1 只做统一资产台账 V1：
@@ -103,6 +131,13 @@ ASSET1 只做统一资产台账 V1：
 - 复用现有 `AssetCard`，扩展资产大类、敏感级别、负责人/保管人、归档位置、外部引用、hash、历史验证编号、保密要求、扩展元数据和最近验证日期。
 - 编号服务支持 `FA`、`EA-DOC`、`EA-SYS`、`EA-REPO`、`EA-BKP`。
 - 前端资产页支持类型、敏感级别和编号/hash/VER 搜索。
+- 采购/报销来源只作为资产候选和来源关联，不在审批通过、报销提交或付款后自动建卡。
+- 固定资产使用 `FA` 编号和二维码标签支撑扫码盘点；无法贴标时使用序列号、保管人和位置兜底。
+- 固定资产支持季度轻盘点、事件盘点和高风险资产月度确认三种频率口径。
+- 固定资产处置必须保留负责人确认、原因和证据摘要；赔偿、金额或责任争议不由资产页直接完成。
+- 电子资产只登记责任、归档、权限回收、备份/恢复验证和位置摘要，不保存源码包、密钥、token、完整配置、真实完整路径或备份内容。
+- `EA-DOC` 只登记资料索引、负责人、业务关联和归档位置摘要，高敏原文不进普通资产页。
+- 资产页展示采购、报销、合同、项目或付款来源时只显示摘要和跳转；不在资产页复制采购审批、报销发票/OCR、合同正文下载、付款处理或完整财务固定资产账流程。
 - 移动端继续优先固定资产扫码和盘点，不把复杂电子资料编辑搬到移动端。
 - QA 脚本只输出脱敏索引摘要；默认不写公网 OA。
 
@@ -120,7 +155,7 @@ ASSET1 后，管理员可按以下最小样例试录：
 
 | 样例 | 目标 |
 | --- | --- |
-| 新建 1 条 `FA` 固定资产 | 完成领用、归还、盘点 |
+| 新建 1 条 `FA` 固定资产 | 完成编号、标签或序列号兜底、领用、归还、季度轻盘点 |
 | 导入 3 条脱敏 `EA-DOC` 索引 | 不上传原文，不输出完整路径 |
 | 登记 1 条 `EA-SYS` OA 系统资产 | 记录负责人、入口、备份策略和到期项 |
 | 登记 1 条 `EA-REPO` 仓库资产 | 只保存 Git 元数据和责任人 |
diff --git a/docs/需求-采购费用审批规约.md b/docs/需求-采购费用审批规约.md
index f5caba57..7770daa5 100644
--- a/docs/需求-采购费用审批规约.md
+++ b/docs/需求-采购费用审批规约.md
@@ -3,12 +3,12 @@
 **版本**：1.0
 **日期**：2026-05-09
 **状态**：模块级开发规约
-**补充口径**：OPOLICY1 后，小团队 V1 将预算硬控、复杂招采和供应商生命周期管理后置；正式启用前以资金安排说明、预算外原因、管理层审批留痕和 OA 审计为主。
+**补充口径**：OPOLICY1 后，小团队 V1 将预算硬控、复杂招采、完整采购订单、库存、三单匹配和供应商生命周期管理后置；正式启用前以资金安排说明、预算外原因、管理层审批留痕、附件证据、轻量验收/归档和 OA 审计为主。
 **上级事实源**：[海音达OA-MVP需求规格说明书](./海音达OA-MVP需求规格说明书.md)
 **审批总依据**：[需求 - 统一审批中心规约](./需求-统一审批中心规约.md)
 **体验事实依据**：[产品体验事实源](./产品设计规则.md)；视觉与交互裁决以 `frontend-design` 为准。
 
-本规约细化采购申请和费用申请的业务边界、字段、状态、权限、异常、验收场景和后续开发拆分建议。审批动作、状态机、审批规则矩阵、权限数据范围和留痕要求，以统一审批中心规约为总依据；PC 和移动页面职责以产品体验事实源为依据；本规约只补充采购和费用业务自身规则。
+本规约细化采购申请和费用申请的业务边界、字段、状态、权限、异常、验收场景和后续开发拆分建议。采购台账 V1 是轻量申请审批和留痕，不是采购 ERP。审批动作、状态机、审批规则矩阵、权限数据范围和留痕要求，以统一审批中心规约为总依据；PC 和移动页面职责以产品体验事实源为依据；本规约只补充采购和费用业务自身规则。
 
 ---
 
@@ -19,6 +19,7 @@
 - 让员工在采购或费用发生前，通过 OA 提交申请并完成审批留痕。
 - 让主管、项目负责人、财务和老板能按金额、项目和事项风险审批。
 - 让采购和费用申请能关联项目、合同、附件、报销或后续付款记录。
+- 让采购执行后的轻量验收、归档和后续关联有证据可查。
 - 为 10 人以下科技公司试运行提供轻量流程，不引入复杂招采体系。
 
 ### 1.2 适用对象
@@ -38,16 +39,17 @@
 - 首批不做预算占用、预算冻结、预算释放和预算超额控制。
 - 首批不做支付执行、银行直连、ERP 入账或财务凭证生成。
 - 首批不做库存管理、资产自动入账、采购订单全生命周期或三单匹配。
+- 首批不从采购申请、报销单或付款结果自动生成固定资产卡片；采购明细只允许标记资产候选，后续由管理员在资产台账中手动建卡。
 - 不使用企业微信原生审批；企业微信只做脱敏通知和 deeplink。
 - 采购单、费用申请、报价、供应商资料、合同草稿、验收材料和附件不上传到企业微信原生审批或企业微信附件。
 - 不接入飞书审批、飞书项目或飞书文档作为正式流程。
 
 ### 1.4 OPOLICY1 小团队 V1 裁剪口径
 
-采购/费用在正式启用前采用“小团队 V1”口径：先满足申请、审批、关联项目/合同、付款/AP 留痕和审计，不把复杂预算或完整招采系统作为前置。
+采购/费用在正式启用前采用“小团队 V1”口径：先满足申请、审批、附件证据、轻量验收/归档、关联项目/合同、付款/AP 留痕和审计，不把复杂预算、完整采购订单或完整招采系统作为前置。
 
 - 预算降级为资金安排说明、预算外原因和管理层审批留痕；不得为了通过系统而在代码里硬编码未经确认的金额阈值。
-- 采购比价、招标、评标、供应商准入、供应商评分和黑名单继续作为 P2 后置能力；V1 只保留供应商摘要、风险说明、保密要求和项目/合同/付款关联。
+- 采购比价、招标、评标、供应商准入、供应商评分、黑名单、库存、三单匹配和完整采购订单继续作为 P2 后置能力；V1 只保留供应商摘要、风险说明、保密要求、验收/归档摘要和项目/合同/付款关联。
 - 审批异常 SOP 固定为阻断项：无审批人、自审、越权可见、附件含账号凭据或涉密原文、付款/AP 无法闭环时，当天建修复合同、人工绕行留风险或暂停对应流程。
 - P2 冻结项包括复杂 BPM、预算硬控、ERP/银行流水导入、真实支付直连和 AI 自动写规则；采纳前必须另建 Trellis task。
 
@@ -58,7 +60,7 @@
 | 角色 | 主要动作 | 权限边界 |
 | --- | --- | --- |
 | 申请人 | 创建草稿、填写采购/费用信息、上传附件、提交、撤回允许撤回的申请、查看本人申请 | 只能编辑本人草稿、已退回和规则允许重提的申请；不能审批自己的申请 |
-| 主管 | 审批团队成员的采购/费用申请、退回补充材料、转审给合适人员 | 只能处理分配给自己的待办；金额阈值由审批规则控制 |
+| 主管 | 在待我处理/审批详情中审批团队成员的采购/费用申请、退回补充材料、转审给合适人员 | 只能处理分配给自己的待办；金额阈值由审批规则控制；采购/费用列表和普通详情不直接放审批动作 |
 | 项目负责人 | 审核与自己负责项目相关的采购/费用必要性、项目归属和交付影响 | 只能查看和处理与自己项目相关或分配给自己的事项 |
 | 财务 | 复核金额、发票或后续报销关联、付款条件和财务风险 | 不自动拥有业务最终审批权；财务复核和例外处理必须留痕 |
 | 老板/总经理 | 审批中高额或高风险采购/费用 | 操作仍需进入 OA 审批历史，不允许线下口头审批替代正式记录 |
@@ -82,7 +84,11 @@
 
 ### 3.2 业务对象
 
-采购/费用申请至少包含申请单、明细、附件、审批实例和业务关联。首批可先实现单据主表加明细列表，不要求完整采购订单模型。
+采购/费用申请至少包含申请单、明细、附件、审批实例、轻量验收/归档摘要和业务关联。首批可先实现单据主表加明细列表，不要求完整采购订单模型，也不建立库存、三单匹配或供应商生命周期模型。
+
+采购/费用列表只显示附件完整性、验收/归档摘要、缺失提示和进入详情入口；报价、合同草稿、验收材料、付款证明等证据材料的预览、下载、删除、替换和批量打包必须进入详情页、详情命令区、台账工具或授权审计路径。
+
+采购/费用审批动作集中在 `待我处理`、审批详情或移动审批详情执行。采购/费用列表和普通详情只显示审批状态、当前节点、历史、`查看处理`、`查看进度`、`补材料` 或进入审批任务入口，不直接放 `通过`、`驳回`、`退回`、`转审`。
 
 ---
 
@@ -118,6 +124,7 @@
 | 单价 | 可选；若填写数量和单价，应自动计算小计 |
 | 小计金额 | 必填或由数量单价计算 |
 | 关联项目或任务 | 可选；用于项目成本汇总 |
+| 资产候选 | 可选；只表示后续可能需要登记固定资产，不代表已经入库、已验收或已生成资产卡片 |
 | 备注 | 可选 |
 
 ### 4.3 附件要求
@@ -135,6 +142,7 @@
 采购/费用附件按“业务附件受控入库”处理，不作为自由文件共享：
 
 - 报价、供应商资料、合同草稿、验收材料和交付证明可以作为授权业务原文附件进入采购/费用流程，但必须绑定申请单、项目、合同或付款对象。
+- 上传前必须明确材料类型，例如报价、供应商资料、合同草稿、验收材料、交付证明、付款证明或用途说明。不同类型适用不同校验、权限、审计和展示位置，不使用一个万能 `上传附件` 入口混收全部材料。
 - 待审批附件不得被普通员工跨业务浏览；审批人、项目负责人、采购/财务复核人按职责预览或下载。
 - 敏感报价、客户资料、账号截图、完整配置或供应商高敏资料默认只登记摘要和线下归档位置；如确需上传，应标记为保密或受限，并要求下载用途和审计。
 - 外发给供应商、客户或 AI/Codex 初审的材料只能使用脱敏副本或摘要，不得直接外发 OA 内部原文附件。
@@ -147,7 +155,7 @@
 | --- | --- | --- |
 | 草稿 | 申请人编辑中，未提交审批 | 保存、提交、删除草稿 |
 | 审批中 | 已进入统一审批中心 | 审批、退回、驳回、转审、按规则撤回 |
-| 已通过 | 审批完成，允许后续采购执行、报销关联或付款准备 | 查看、补充执行记录、发起关联动作 |
+| 已通过 | 审批完成，允许后续采购执行、报销关联或付款准备 | 查看、补充执行/验收记录、发起关联动作 |
 | 已驳回 | 审批被否决 | 查看原因、复制新建或按规则重提 |
 | 已退回 | 审批人要求补充或修改 | 修改后重提、撤回 |
 | 已撤回 | 申请人撤回，流程终止 | 查看历史、复制新建 |
@@ -156,6 +164,8 @@
 
 审批中的状态流转、转审、并发处理和通知失败处理，按统一审批中心规约执行。
 
+采购/费用删除、撤回、取消、作废和归档语义遵循产品体验事实源：草稿可删除；审批中按规则撤回；已通过后业务不执行用取消；已形成编号、合同、付款、资产候选或归档证据后如需失效应用作废或追加异常记录；完成后归档只读，后续修正追加记录并留审计。
+
 ---
 
 ## 6. 审批规则
@@ -177,7 +187,7 @@
 - 同一申请不得由申请人审批自己；如果申请人就是主管，应进入明确配置且非本人的老板/总经理或兜底审批节点。
 - 采购/费用审批链、直属主管、老板/总经理、自审禁止、`manager`、`ceo`、`admin` 的角色口径，以 [需求 - 统一审批中心规约](./需求-统一审批中心规约.md) 为准；本规约不重复维护第二套审批事实源。
 - 无审批人时阻断提交，不生成半截流程。
-- 审批通过不代表已经付款、入账或完成采购执行。
+- 审批通过不代表已经付款、入账、入库、形成固定资产或完成采购执行。
 
 ---
 
@@ -189,8 +199,13 @@
 | 报销/OCR | 费用发生后可关联报销单；发票、OCR、付款和导出仍由报销规约管理 |
 | 合同归档 | 大额采购或服务采购可关联合同台账；合同正文和敏感附件按合同规约处理 |
 | 项目轻管理 | 项目页汇总采购/费用事项，用于项目成本和风险参考 |
+| 资产台账 | 采购明细或报销材料可提供资产候选线索；到货、验收或报销完成后，由管理员核对实物、数量、归属、是否耗材、是否退货/赠品，再手动创建 `FA` 资产卡片并关联来源单据 |
 | 企业微信 | 只发送脱敏通知和 deeplink，审批动作回 OA 完成；采购、报价、供应商和附件不进企微原生审批或企微附件 |
 
+采购/费用页的跨模块关联采用“摘要 + 跳转”：可以展示项目、合同、报销、资产候选和付款/AP 的编号、名称、状态、金额/数量、负责人、证据完整性和下一步，但不在采购页复制项目管理、合同归档、报销发票/OCR、资产建卡或付款处理流程。需要处理时跳转到对应模块详情、审批任务或财务处理页。
+
+采购/费用列表和普通详情只显示付款/AP 状态、回单状态、`查看付款`、`补回单` 或进入付款记录入口，不直接放 `标记已付款`、`取消付款`、`批量付款`、`执行付款`。付款准备、付款批次、回单留痕和取消付款标记统一进入付款/财务处理详情，并按财务权限和审计执行。
+
 ---
 
 ## 8. 异常规则
@@ -215,6 +230,7 @@
 - 申请单快照、明细、附件清单和业务编号。
 - 提交、审批、退回、驳回、撤回、转审、取消和完成记录。
 - 附件上传、下载、删除或替换记录。
+- 轻量验收、归档和执行结果摘要。
 - 关联项目、合同、报销或付款记录的变更记录。
 - 财务复核、例外处理和管理员修正原因。
 
@@ -228,7 +244,7 @@
 | --- | --- | --- |
 | 小额费用申请 | 员工创建 300 元费用申请并提交；主管审批通过 | 单据进入已通过，审批历史、通知和状态一致 |
 | 中额费用财务复核 | 员工提交 2000 元费用申请；主管通过；财务复核通过 | 生成主管和财务两个节点，最终已通过 |
-| 大额采购审批 | 员工提交 8000 元采购申请并上传报价附件；主管、老板、财务依次处理 | 串行节点完整，附件可查看，审批通过后可关闭或关联后续事项 |
+| 大额采购审批 | 员工提交 8000 元采购申请并上传报价附件；主管、老板、财务依次处理 | 串行节点完整，附件可查看，审批通过后可补充验收/归档摘要或关联后续事项 |
 | 退回补充材料 | 审批人退回要求补充报价；申请人补充附件后重提 | 保留同一编号和退回历史，重新进入审批中 |
 | 无审批人阻断 | 删除或停用兜底审批人后提交 | 提交失败，不生成半截流程 |
 | 企业微信通知回 OA | 待办产生后发送企业微信消息；审批人点击 deeplink | 打开 OA 对应申请或审批页，不能在企业微信原生审批完成 |
@@ -244,7 +260,7 @@
 3. 采购/费用审批接入统一审批中心。
 4. 附件上传、下载、权限和审计。
 5. 金额阈值、费用类型和审批规则配置。
-6. 项目、合同、报销的业务关联。
+6. 项目、合同、报销、付款/AP 和轻量验收/归档的业务关联。
 7. PC 列表、移动入口和企业微信 deeplink。
 8. 回归测试：小额、中额、大额、退回、驳回、撤回、取消、无审批人和通知失败。
 
@@ -253,8 +269,8 @@
 ## 12. 后续 Backlog
 
 - 供应商管理、准入和评分。
-- 询比价、招采、评标和采购订单。
+- 询比价、招采、评标和采购订单全生命周期。
 - 预算占用、预算释放和超预算控制。
 - 付款计划、银行支付、ERP 入账和凭证生成。
-- 库存、固定资产自动入账和验收单。
+- 库存、三单匹配、固定资产自动入账和完整验收单管理。
 - 多币种、税率、复杂合同付款节点。
diff --git a/docs/需求-项目轻管理规约.md b/docs/需求-项目轻管理规约.md
index 6de93a70..9beb3790 100644
--- a/docs/需求-项目轻管理规约.md
+++ b/docs/需求-项目轻管理规约.md
@@ -3,6 +3,7 @@
 **版本**：1.0
 **日期**：2026-05-09
 **状态**：模块级开发规约
+**补充口径**：小团队 V1 只做轻项目台账，覆盖项目状态、负责人/成员、里程碑/任务、风险、交付记录和关联业务摘要；不做完整项目管理软件、甘特图、复杂任务依赖、工时、资源排期、OKR、项目组合管理或大型协同平台。
 **上级事实源**：[海音达OA-MVP需求规格说明书](./海音达OA-MVP需求规格说明书.md)
 **审批与体验事实依据**：[需求 - 统一审批中心规约](./需求-统一审批中心规约.md)、[产品体验事实源](./产品设计规则.md)；视觉与交互裁决以 `frontend-design` 为准。
 
@@ -15,9 +16,9 @@
 ### 1.1 目标
 
 - 建立轻量项目台账，统一项目名称、负责人、成员、状态、里程碑和风险。
-- 将报销、采购、费用、合同、差旅、周报、交付记录和审批事项关联到项目。
+- 将报销、采购、费用、合同、付款、差旅、周报、交付记录和审批事项关联到项目。
 - 让老板、项目负责人、成员和财务能从项目页看到关键事项摘要。
-- 在不引入重型项目管理系统的前提下，支持小团队试运行和后续扩展。
+- 在不引入重型项目管理系统、OKR 或大型协同平台的前提下，支持小团队试运行和后续扩展。
 
 ### 1.2 适用对象
 
@@ -26,14 +27,15 @@
 | 项目基本信息 | 项目名称、编号、客户、负责人、状态、起止时间 |
 | 项目成员 | 项目负责人、成员、财务关注人或管理员 |
 | 里程碑 | 关键交付节点、计划日期、完成状态 |
-| 任务 | 轻量待办或事项，不做复杂依赖和排产 |
+| 任务 | 轻量待办或事项，不做复杂依赖、工时和排产 |
 | 风险 | 进度、成本、交付、客户、资源等风险记录 |
 | 交付记录 | 文档、验收、版本、会议纪要或交付说明摘要 |
-| 业务关联 | 报销、采购、费用、合同、差旅、周报、审批待办 |
+| 业务关联 | 报销、采购、费用、合同、付款、差旅、周报、审批待办 |
 
 ### 1.3 暂不做范围
 
 - 首批不做重型甘特图、任务依赖网络、资源排产或工时容量规划。
+- 首批不做 OKR、绩效目标分解、跨团队协同空间或大型知识库。
 - 首批不做完整项目组合管理、项目财务核算或预算控制。
 - 首批不做 CRM、PLM、研发需求管理、缺陷管理或代码仓库集成。
 - 首批不做项目 IM、在线文档协同或会议系统。
@@ -64,10 +66,10 @@
 | 项目列表 | 查看项目状态、负责人、客户、风险和更新时间 | 支持按状态、负责人、客户或关键字筛选 |
 | 项目详情页 | 汇总项目信息、成员、里程碑、任务、风险、交付记录和业务关联 | 首屏应突出状态、负责人、近期事项和风险 |
 | Portal 项目摘要 | 老板或负责人快速查看重点项目 | 展示少量关键指标，不做复杂图表 |
-| 业务单据关联入口 | 报销、采购、费用、合同等选择项目 | 项目状态不可用时应限制关联 |
+| 业务单据关联入口 | 报销、采购、费用、合同、付款等选择项目 | 项目状态不可用时应限制关联 |
 | 移动端项目摘要 | 查看重点状态、待办和风险 | 首批以查看为主，支持简单任务或风险更新 |
 
-项目页是汇总入口，不替代报销、采购、合同或审批详情页。
+项目页是汇总入口，不替代报销、采购、合同、付款或审批详情页，也不是 OKR、工时或资源排期入口。
 
 ---
 
@@ -115,6 +117,8 @@
 | 说明 | 可选 |
 | 关联审批或业务单据 | 可选 |
 
+任务字段只服务轻量跟进，不记录工时、不配置复杂依赖、不做资源排期。
+
 ### 4.4 风险字段
 
 | 字段 | 要求 |
@@ -162,6 +166,7 @@
 | 报销 | 报销明细或报销单可关联项目，用于费用摘要；发票和 OCR 仍由报销模块管理 |
 | 采购/费用 | 采购和费用申请可关联项目，项目页展示金额、状态和当前节点 |
 | 合同 | 合同台账可关联项目，项目页展示合同编号、名称、状态和金额摘要 |
+| 付款/AP | 付款批次或应付账款可关联项目，项目页只展示摘要和状态；付款执行、回单和 AP 处理仍回到财务模块 |
 | 差旅 | 出差作为后续扩展；首批可预留项目字段 |
 | 周报 | 周报可关联项目，项目页展示最近周报摘要 |
 | 审批待办 | 项目页可展示与项目相关的待办数量或最近审批动态 |
@@ -169,6 +174,8 @@
 
 项目费用摘要首批只做汇总展示，不作为正式成本核算或预算控制依据。
 
+项目页的跨模块关联采用“摘要 + 跳转”：可以展示报销、采购、合同、付款、资产或交付对象的编号、名称、状态、金额/数量、负责人、证据完整性和下一步，但不在项目页直接审批采购、处理报销发票/OCR、标记付款、下载合同正文、删除附件或执行资产处置。需要操作时跳转到对应业务详情、审批任务或财务处理页，并继续按原模块权限和审计控制。
+
 ---
 
 ## 7. 权限与数据范围
@@ -215,7 +222,7 @@
 
 - 项目基本信息和成员快照。
 - 里程碑、任务、风险和交付记录摘要。
-- 关联合同、采购、费用、报销、差旅和周报清单。
+- 关联合同、采购、费用、报销、付款、差旅和周报清单。
 - 非涉密附件清单及归档位置。
 - 审批和审计摘要。
 
@@ -242,7 +249,7 @@
 2. 项目列表、详情、创建和编辑页面。
 3. 项目成员、负责人和权限数据范围。
 4. 里程碑、任务、风险和交付记录。
-5. 报销、采购、费用、合同、差旅和周报关联。
+5. 报销、采购、费用、合同、付款/AP、差旅和周报关联。
 6. Portal 项目摘要和移动项目摘要。
 7. 项目归档、导出摘要和审计日志。
 8. 回归测试：创建、状态变更、风险、关联单据、权限隔离、归档和移动查看。
@@ -251,8 +258,9 @@
 
 ## 12. 后续 Backlog
 
-- 甘特图、任务依赖、资源排产和工时容量。
+- 甘特图、任务依赖、资源排产、工时容量和 OKR。
 - 项目组合管理、预算控制和正式成本核算。
 - CRM、PLM、研发需求、缺陷和代码仓库集成。
+- 大型协同空间、项目 IM、在线文档协同和知识库。
 - AI 周报汇总、风险识别和自动排期建议。
 - 与专业项目管理工具的双向同步。