沉淀小团队产品与单人开发规则（small-team-solo-dev-rules）

.trellis/spec/hyb-oa/frontend-react-vite-design.md

@@ -19,6 +19,10 @@ and verification contracts. Do not copy broad aesthetic guidance from
 - When `frontend-design` and older project visual rules conflict, follow
   `frontend-design` for visual direction while preserving security, privacy,
   Trellis, deployment and business data boundaries.
+- Default product framing is a small-team Chinese workbench for domestic tech
+  startups with fewer than 10 people. User-facing copy should be natural
+  Chinese; avoid English product words such as `Portal`, `Dashboard` and
+  `Workflow` unless they are internal test fixtures or technical identifiers.
 - PC pages should keep dense but orderly OA layouts: clear header, filters,
   table/list, status, details and predictable actions.
 - Mobile pages must reuse the existing unified mobile shell, card/list rows,
@@ -201,12 +205,19 @@ point and prevents each route from inventing a different title/action layout.
 reimbursement detail should make the current user task obvious before exposing
 secondary operations:
 
+- Treat the primary persona as a small-team operator wearing multiple hats, not
+  a dedicated OA clerk. The first screen should reduce decision cost for a
+  founder, finance/admin owner, project lead or employee who may switch roles
+  during the same session.
 - First visible task surface should answer: what needs attention, what can be
   started, and where recent progress lives.
 - Keep one primary action in the first screen. Allow at most two secondary
   entries; move export, batch, delete, templates, complex filters, statistics
   and admin/finance tools into `更多`, `高级 / 台账`, detail actions, role-only
   panels or confirmation dialogs.
+- Do not turn small-team workflows into platform-builder surfaces by default:
+  approval designers, broad configuration matrices, multi-level enterprise
+  dashboards and batch admin consoles need explicit Trellis task scope.
 - Explanation text should only be default-visible for risk, exception or empty
   states. Do not use repeated subtitles or notice cards to explain normal
   workflow steps that the layout can express.