沉淀小团队产品与单人开发规则（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.

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

@@ -19,6 +19,27 @@ tasks after TRELLIS2.
 - Keep edits scoped to the current Trellis task.
 - Commit in Chinese and include the Trellis task name or task ID.
 
+## Solo Developer Operating Mode
+
+hyb-oa is developed and maintained by one primary developer. Optimize every
+feature, improvement and refactor for low error rate, fast review, clear
+rollback and future self-maintenance.
+
+- Prefer small, independently verifiable slices over broad rewrites.
+- Before adding a new capability, ask whether it is high-frequency for a
+  domestic tech startup with fewer than 10 people; low-frequency capability
+  should be deferred, hidden behind advanced/admin entry, or kept as a manual
+  procedure unless the current Trellis task explicitly approves it.
+- Prefer existing modules, shared components, scripts and runbooks over new
+  abstractions. Add platform-like infrastructure only when it removes real
+  repeated work or reduces operational risk.
+- Every task should state the minimum useful validation command set before
+  implementation; do not rely on manual memory for gates.
+- Keep rollout and rollback obvious. For public-facing changes, record the
+  exact commit, deployment command, public check and whether the user can test.
+- Capture reusable lessons in `docs/`, `.trellis/spec/` or the current task
+  while they are fresh; do not depend on chat history for project rules.
+
 ## Stop Conditions
 
 - Production config, deployment, database reset, migration drift, real data