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

这个提交包含在:
2026-05-29 13:59:38 +08:00
父节点 829843ceb9
当前提交 d7fec696dc
共修改 8 个文件,包含 168 行新增和 2 行删除
@@ -19,6 +19,10 @@ and verification contracts. Do not copy broad aesthetic guidance from
- When `frontend-design` and older project visual rules conflict, follow - When `frontend-design` and older project visual rules conflict, follow
`frontend-design` for visual direction while preserving security, privacy, `frontend-design` for visual direction while preserving security, privacy,
Trellis, deployment and business data boundaries. 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, - PC pages should keep dense but orderly OA layouts: clear header, filters,
table/list, status, details and predictable actions. table/list, status, details and predictable actions.
- Mobile pages must reuse the existing unified mobile shell, card/list rows, - 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 reimbursement detail should make the current user task obvious before exposing
secondary operations: 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 - First visible task surface should answer: what needs attention, what can be
started, and where recent progress lives. started, and where recent progress lives.
- Keep one primary action in the first screen. Allow at most two secondary - Keep one primary action in the first screen. Allow at most two secondary
entries; move export, batch, delete, templates, complex filters, statistics entries; move export, batch, delete, templates, complex filters, statistics
and admin/finance tools into `更多`, `高级 / 台账`, detail actions, role-only and admin/finance tools into `更多`, `高级 / 台账`, detail actions, role-only
panels or confirmation dialogs. 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 - Explanation text should only be default-visible for risk, exception or empty
states. Do not use repeated subtitles or notice cards to explain normal states. Do not use repeated subtitles or notice cards to explain normal
workflow steps that the layout can express. workflow steps that the layout can express.
@@ -19,6 +19,27 @@ tasks after TRELLIS2.
- Keep edits scoped to the current Trellis task. - Keep edits scoped to the current Trellis task.
- Commit in Chinese and include the Trellis task name or task ID. - 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 ## Stop Conditions
- Production config, deployment, database reset, migration drift, real data - Production config, deployment, database reset, migration drift, real data
@@ -0,0 +1,3 @@
{"file": ".trellis/spec/hyb-oa/project-governance.md", "reason": "Check project governance and solo-developer workflow constraints."}
{"file": ".trellis/spec/hyb-oa/frontend-react-vite-design.md", "reason": "Check frontend rules stay product-specific and do not duplicate broad visual design guidance."}
{"file": ".trellis/spec/hyb-oa/docs-and-evidence.md", "reason": "Check documentation update follows source-of-truth boundaries."}
@@ -0,0 +1,3 @@
{"file": ".trellis/spec/hyb-oa/project-governance.md", "reason": "Project-level Trellis and solo-developer governance rules."}
{"file": ".trellis/spec/hyb-oa/frontend-react-vite-design.md", "reason": "Frontend product simplification and task-first UI constraints."}
{"file": ".trellis/spec/hyb-oa/docs-and-evidence.md", "reason": "Documentation source-of-truth and evidence hygiene for rule updates."}
@@ -0,0 +1,22 @@
# Implementation Notes
## Sequence
1. Read existing product and Trellis rule sources.
2. Update `docs/产品设计规则.md` with the confirmed product background:
domestic tech startup, fewer than 10 people, natural Chinese workbench,
overlapping roles.
3. Update `.trellis/spec/hyb-oa/frontend-react-vite-design.md` with frontend
decision rules for small-team task-first pages and avoiding unapproved
platform-builder surfaces.
4. Update `.trellis/spec/hyb-oa/project-governance.md` with solo-developer
operating rules: small slices, validation first, reuse, rollback and
durable rule capture.
5. Run Trellis task validation, governance and whitespace checks.
## Safety Boundaries
- Documentation/spec-only change.
- No product code changes.
- No deployment.
- No real data access or writes.
@@ -0,0 +1,74 @@
# 沉淀小团队产品与单人开发规则
## Goal
将用户确认的长期背景沉淀为项目级规则:hyb-oa 面向国内、小于 10 人的科技初创公司,且系统由单人长期开发维护。后续功能开发、改进和重构必须默认遵守“小团队中文工作台”和“单人开发低风险工作流”。
## Scope
- 更新 `docs/产品设计规则.md` 中的用户与使用事实。
- 更新 `.trellis/spec/hyb-oa/frontend-react-vite-design.md` 中 A 类页面和前端改动的默认判断规则。
- 更新 `.trellis/spec/hyb-oa/project-governance.md` 中单人开发工作流约束。
- 不改业务功能、不改前端页面代码、不部署。
## What I Already Know
- 用户确认当前系统面向“国内小于 10 人的科技初创公司”,并强调界面要注意中文。
- 用户确认后续功能开发、改进、重构都要考虑该背景。
- 用户确认系统由一个人开发维护,需要整理工作流,减少出错、提高效率。
- `docs/产品设计规则.md` 已记录“10 人以下国内科技公司、角色重叠、审批链短、使用频次高”。
- `.trellis/spec/hyb-oa/frontend-react-vite-design.md` 已包含 A 类页面“任务优先、低频能力收起”的规则。
- `.trellis/spec/hyb-oa/project-governance.md` 已包含 Trellis-first 和提交治理规则,但还缺少单人开发低风险策略。
## Requirements
- 明确产品默认定位:
- 国内、小于 10 人、科技初创公司。
- 一人多岗,老板、财务、行政、项目负责人、员工角色会重叠。
- 中文优先,避免英文产品词残留和大企业 OA 式复杂表达。
- 明确功能和重构判断:
- 高频真实工作优先;低频管理能力收起但不消失。
- 默认不做平台化、审批设计器化、大企业多层级配置化,除非当前任务明确批准。
- 页面首屏优先回答“今天要办什么、谁卡住了、下一步点哪里”。
- 明确单人开发工作流:
- 小批量、可验证、可回滚。
- 新能力优先复用现有模块和共享组件。
- 每次改动必须有清晰验收和必要自动化门禁。
- 稳定经验沉淀到 docs/spec/task,减少靠记忆维护。
## Acceptance Criteria
- [x] 产品定位规则写入 `docs/产品设计规则.md`。
- [x] 前端重构默认判断写入 `.trellis/spec/hyb-oa/frontend-react-vite-design.md`。
- [x] 单人开发低风险工作流写入 `.trellis/spec/hyb-oa/project-governance.md`。
- [x] Trellis task validate 通过。
- [x] Trellis governance 通过。
- [x] `git diff --check` 通过。
## Definition Of Done
- 后续会话可以直接从 docs/spec 读取该背景,不需要依赖聊天记忆。
- 文档只记录产品事实和工程规则,不新增视觉审美细则。
- 本任务完成后提交中文 commit,commit message 引用任务名。
## Out Of Scope
- 不调整现有页面。
- 不新增前端组件。
- 不改权限、审批、状态机或数据库。
- 不部署公网。
## Test Plan
```bash
python3 ./.trellis/scripts/task.py validate 05-29-small-team-solo-dev-rules
node scripts/qa/check-trellis-governance.mjs
git diff --check
```
## Implementation Plan
1. 在产品事实源中补充小团队中文工作台定位。
2. 在前端规约中补充功能/页面重构的默认取舍规则。
3. 在项目治理规约中补充单人开发低风险工作流。
4. 跑文档和 Trellis 检查。
@@ -0,0 +1,30 @@
{
"id": "small-team-solo-dev-rules",
"name": "small-team-solo-dev-rules",
"title": "沉淀小团队产品与单人开发规则",
"description": "沉淀国内小于10人科技初创公司产品定位,以及单人开发低风险工作流。",
"status": "in_progress",
"dev_type": null,
"scope": "docs-spec-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": [
"docs/产品设计规则.md",
".trellis/spec/hyb-oa/frontend-react-vite-design.md",
".trellis/spec/hyb-oa/project-governance.md"
],
"notes": "",
"meta": {}
}
+4 -2
查看文件
@@ -14,11 +14,13 @@
## 用户与使用事实 ## 用户与使用事实
- 目标用户是 10 人以下的国内科技公司,角色重叠、审批链短、使用频次高。 - 目标用户是国内、小于 10 人的科技初创公司,角色重叠、审批链短、使用频次高。
- 默认使用者不是专职 OA 操作员,而是一人多岗:负责人、财务、行政、项目负责人和员工职责可能集中在少数人身上。
- 产品默认形态是“小团队中文工作台”:先帮助用户看清今天要办什么、谁卡住了、下一步点哪里,再提供低频管理能力。
- PC 端主要服务批量查看、对账、审批、财务复核、导出和管理配置。 - PC 端主要服务批量查看、对账、审批、财务复核、导出和管理配置。
- 手机/企业微信端主要服务提交、补材料、查状态、处理待办和从消息直达业务详情。 - 手机/企业微信端主要服务提交、补材料、查状态、处理待办和从消息直达业务详情。
- 系统应优先支持真实工作流,不做营销站式介绍页,也不把低频配置入口放到高频员工路径里。 - 系统应优先支持真实工作流,不做营销站式介绍页,也不把低频配置入口放到高频员工路径里。
- 页面可见内容应使用国内 OA 常见表达,例如待处理、草稿、审批中、已通过、已支付、已驳回、提交、保存、删除、撤回。 - 页面可见内容应使用自然中文和国内 OA 常见表达,例如待处理、草稿、审批中、已通过、已支付、已驳回、提交、保存、删除、撤回;避免把 `Portal`、`Dashboard`、`Workflow` 等英文产品词作为默认用户文案。
## 页面职责分层 ## 页面职责分层