沉淀小团队产品与单人开发规则(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
|
||||
`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.
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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 端主要服务批量查看、对账、审批、财务复核、导出和管理配置。
|
||||
- 手机/企业微信端主要服务提交、补材料、查状态、处理待办和从消息直达业务详情。
|
||||
- 系统应优先支持真实工作流,不做营销站式介绍页,也不把低频配置入口放到高频员工路径里。
|
||||
- 页面可见内容应使用国内 OA 常见表达,例如待处理、草稿、审批中、已通过、已支付、已驳回、提交、保存、删除、撤回。
|
||||
- 页面可见内容应使用自然中文和国内 OA 常见表达,例如待处理、草稿、审批中、已通过、已支付、已驳回、提交、保存、删除、撤回;避免把 `Portal`、`Dashboard`、`Workflow` 等英文产品词作为默认用户文案。
|
||||
|
||||
## 页面职责分层
|
||||
|
||||
|
||||
在新工单中引用
屏蔽一个用户