沉淀小团队产品与单人开发规则(small-team-solo-dev-rules)
这个提交包含在:
@@ -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` 等英文产品词作为默认用户文案。
|
||||||
|
|
||||||
## 页面职责分层
|
## 页面职责分层
|
||||||
|
|
||||||
|
|||||||
在新工单中引用
屏蔽一个用户