wangsli/hyb-oa
1
0
派生 0
代码 工单 合并请求 工作流 8 软件包 项目 发布 百科 活动

治理 Trellis spec 占位噪音与规则口径（05-29-spec-governance-cleanup）

浏览代码
这个提交包含在：
wangsli
2026-05-29 09:56:22 +08:00
父节点 cdd56bc5df
当前提交 c192c77c7a
共修改 22 个文件，包含 306 行新增和 610 行删除
下载 Patch 文件 下载 Diff 文件 展开所有文件 折叠所有文件
.trellis/spec/backend/database-guidelines.md
-51
查看文件
@@ -1,51 +0,0 @@
# Database Guidelines
> Database patterns and conventions for this project.
---
## Overview
<!--
Document your project's database conventions here.
Questions to answer:
- What ORM/query library do you use?
- How are migrations managed?
- What are the naming conventions for tables/columns?
- How do you handle transactions?
-->
(To be filled by the team)
---
## Query Patterns
<!-- How should queries be written? Batch operations? -->
(To be filled by the team)
---
## Migrations
<!-- How to create and run migrations -->
(To be filled by the team)
---
## Naming Conventions
<!-- Table names, column names, index names -->
(To be filled by the team)
---
## Common Mistakes
<!-- Database-related mistakes your team has made -->
(To be filled by the team)
.trellis/spec/backend/directory-structure.md
-54
查看文件
@@ -1,54 +0,0 @@
# Directory Structure
> How backend code is organized in this project.
---
## Overview
<!--
Document your project's backend directory structure here.
Questions to answer:
- How are modules/packages organized?
- Where does business logic live?
- Where are API endpoints defined?
- How are utilities and helpers organized?
-->
(To be filled by the team)
---
## Directory Layout
```
<!-- Replace with your actual structure -->
src/
├── ...
└── ...
```
---
## Module Organization
<!-- How should new features/modules be organized? -->
(To be filled by the team)
---
## Naming Conventions
<!-- File and folder naming rules -->
(To be filled by the team)
---
## Examples
<!-- Link to well-organized modules as examples -->
(To be filled by the team)
.trellis/spec/backend/error-handling.md
-51
查看文件
@@ -1,51 +0,0 @@
# Error Handling
> How errors are handled in this project.
---
## Overview
<!--
Document your project's error handling conventions here.
Questions to answer:
- What error types do you define?
- How are errors propagated?
- How are errors logged?
- How are errors returned to clients?
-->
(To be filled by the team)
---
## Error Types
<!-- Custom error classes/types -->
(To be filled by the team)
---
## Error Handling Patterns
<!-- Try-catch patterns, error propagation -->
(To be filled by the team)
---
## API Error Responses
<!-- Standard error response format -->
(To be filled by the team)
---
## Common Mistakes
<!-- Error handling mistakes your team has made -->
(To be filled by the team)
.trellis/spec/backend/index.md
+11 -15
查看文件
@@ -1,30 +1,26 @@
# Backend Development Guidelines
# Backend Spec Redirect
---
## Overview
hyb-oa backend work uses Fastify, Prisma and PostgreSQL under `server/`.
The project-specific backend rules live in `../hyb-oa/backend-fastify-prisma.md`;
the files in this directory are Trellis default scaffolding and may be expanded
only when a later task needs deeper backend conventions.
hyb-oa backend work uses Fastify, Prisma and PostgreSQL under `server/`. The
active backend rules live in `../hyb-oa/backend-fastify-prisma.md`.
---
This directory intentionally contains no separate backend guideline files. The
old default scaffold files were removed because placeholder specs are noise for
future agents.
## Guidelines Index
## Read
| Guide | Description | Status |
|-------|-------------|--------|
| [hyb-oa Backend Rules](../hyb-oa/backend-fastify-prisma.md) | Current project backend rules | Current |
| [Directory Structure](./directory-structure.md) | Module organization and file layout | Scaffold |
| [Database Guidelines](./database-guidelines.md) | ORM patterns, queries, migrations | Scaffold |
| [Error Handling](./error-handling.md) | Error types, handling strategies | Scaffold |
| [Quality Guidelines](./quality-guidelines.md) | Code standards, forbidden patterns | Scaffold |
| [Logging Guidelines](./logging-guidelines.md) | Structured logging, log levels | Scaffold |
---
## Language
## Rule
Project rules are Chinese-first where they are user-facing. Short English files
generated by Trellis may remain when they are tool-facing scaffolding.
Add a new backend spec file only when a later Trellis task discovers concrete,
source-backed backend conventions that do not belong in the project-level
backend spec.
.trellis/spec/backend/logging-guidelines.md
-51
查看文件
@@ -1,51 +0,0 @@
# Logging Guidelines
> How logging is done in this project.
---
## Overview
<!--
Document your project's logging conventions here.
Questions to answer:
- What logging library do you use?
- What are the log levels and when to use each?
- What should be logged?
- What should NOT be logged (PII, secrets)?
-->
(To be filled by the team)
---
## Log Levels
<!-- When to use each level: debug, info, warn, error -->
(To be filled by the team)
---
## Structured Logging
<!-- Log format, required fields -->
(To be filled by the team)
---
## What to Log
<!-- Important events to log -->
(To be filled by the team)
---
## What NOT to Log
<!-- Sensitive data, PII, secrets -->
(To be filled by the team)
.trellis/spec/backend/quality-guidelines.md
-51
查看文件
@@ -1,51 +0,0 @@
# Quality Guidelines
> Code quality standards for backend development.
---
## Overview
<!--
Document your project's quality standards here.
Questions to answer:
- What patterns are forbidden?
- What linting rules do you enforce?
- What are your testing requirements?
- What code review standards apply?
-->
(To be filled by the team)
---
## Forbidden Patterns
<!-- Patterns that should never be used and why -->
(To be filled by the team)
---
## Required Patterns
<!-- Patterns that must always be used -->
(To be filled by the team)
---
## Testing Requirements
<!-- What level of testing is expected -->
(To be filled by the team)
---
## Code Review Checklist
<!-- What reviewers should check -->
(To be filled by the team)
.trellis/spec/frontend/component-guidelines.md
-59
查看文件
@@ -1,59 +0,0 @@
# Component Guidelines
> How components are built in this project.
---
## Overview
<!--
Document your project's component conventions here.
Questions to answer:
- What component patterns do you use?
- How are props defined?
- How do you handle composition?
- What accessibility standards apply?
-->
(To be filled by the team)
---
## Component Structure
<!-- Standard structure of a component file -->
(To be filled by the team)
---
## Props Conventions
<!-- How props should be defined and typed -->
(To be filled by the team)
---
## Styling Patterns
<!-- How styles are applied (CSS modules, styled-components, Tailwind, etc.) -->
(To be filled by the team)
---
## Accessibility
<!-- A11y requirements and patterns -->
(To be filled by the team)
---
## Common Mistakes
<!-- Component-related mistakes your team has made -->
(To be filled by the team)
.trellis/spec/frontend/directory-structure.md
-54
查看文件
@@ -1,54 +0,0 @@
# Directory Structure
> How frontend code is organized in this project.
---
## Overview
<!--
Document your project's frontend directory structure here.
Questions to answer:
- Where do components live?
- How are features/modules organized?
- Where are shared utilities?
- How are assets organized?
-->
(To be filled by the team)
---
## Directory Layout
```
<!-- Replace with your actual structure -->
src/
├── ...
└── ...
```
---
## Module Organization
<!-- How should new features be organized? -->
(To be filled by the team)
---
## Naming Conventions
<!-- File and folder naming rules -->
(To be filled by the team)
---
## Examples
<!-- Link to well-organized modules as examples -->
(To be filled by the team)
.trellis/spec/frontend/hook-guidelines.md
-51
查看文件
@@ -1,51 +0,0 @@
# Hook Guidelines
> How hooks are used in this project.
---
## Overview
<!--
Document your project's hook conventions here.
Questions to answer:
- What custom hooks do you have?
- How do you handle data fetching?
- What are the naming conventions?
- How do you share stateful logic?
-->
(To be filled by the team)
---
## Custom Hook Patterns
<!-- How to create and structure custom hooks -->
(To be filled by the team)
---
## Data Fetching
<!-- How data fetching is handled (React Query, SWR, etc.) -->
(To be filled by the team)
---
## Naming Conventions
<!-- Hook naming rules (use*, etc.) -->
(To be filled by the team)
---
## Common Mistakes
<!-- Hook-related mistakes your team has made -->
(To be filled by the team)
.trellis/spec/frontend/index.md
+11 -14
查看文件
@@ -1,32 +1,29 @@
# Frontend Development Guidelines
# Frontend Spec Redirect
---
## Overview
hyb-oa frontend work uses React, TypeScript, Vite and Tailwind under `client/`.
The project-specific frontend implementation rules live in
`../hyb-oa/frontend-react-vite-design.md`; product experience facts remain in
The active frontend implementation rules live in
`../hyb-oa/frontend-react-vite-design.md`. Product experience facts remain in
`docs/产品设计规则.md`. Visual and interaction design authority comes from the
installed `frontend-design` skill.
---
This directory intentionally contains no separate frontend guideline files. The
old default scaffold files were removed because placeholder specs are noise for
future agents.
## Guidelines Index
## Read
| Guide | Description | Status |
|-------|-------------|--------|
| [hyb-oa Frontend Rules](../hyb-oa/frontend-react-vite-design.md) | Current project frontend/design rules | Current |
| [Directory Structure](./directory-structure.md) | Module organization and file layout | Scaffold |
| [Component Guidelines](./component-guidelines.md) | Component patterns, props, composition | Scaffold |
| [Hook Guidelines](./hook-guidelines.md) | Custom hooks, data fetching patterns | Scaffold |
| [State Management](./state-management.md) | Local state, global state, server state | Scaffold |
| [Quality Guidelines](./quality-guidelines.md) | Code standards, forbidden patterns | Scaffold |
| [Type Safety](./type-safety.md) | Type patterns, validation | Scaffold |
---
## Language
## Rule
Project rules are Chinese-first where they are user-facing. Short English files
generated by Trellis may remain when they are tool-facing scaffolding.
Add a new frontend spec file only when a later Trellis task discovers concrete,
source-backed frontend conventions that do not belong in the project-level
frontend/design spec.
.trellis/spec/frontend/quality-guidelines.md
-51
查看文件
@@ -1,51 +0,0 @@
# Quality Guidelines
> Code quality standards for frontend development.
---
## Overview
<!--
Document your project's quality standards here.
Questions to answer:
- What patterns are forbidden?
- What linting rules do you enforce?
- What are your testing requirements?
- What code review standards apply?
-->
(To be filled by the team)
---
## Forbidden Patterns
<!-- Patterns that should never be used and why -->
(To be filled by the team)
---
## Required Patterns
<!-- Patterns that must always be used -->
(To be filled by the team)
---
## Testing Requirements
<!-- What level of testing is expected -->
(To be filled by the team)
---
## Code Review Checklist
<!-- What reviewers should check -->
(To be filled by the team)
.trellis/spec/frontend/state-management.md
-51
查看文件
@@ -1,51 +0,0 @@
# State Management
> How state is managed in this project.
---
## Overview
<!--
Document your project's state management conventions here.
Questions to answer:
- What state management solution do you use?
- How is local vs global state decided?
- How do you handle server state?
- What are the patterns for derived state?
-->
(To be filled by the team)
---
## State Categories
<!-- Local state, global state, server state, URL state -->
(To be filled by the team)
---
## When to Use Global State
<!-- Criteria for promoting state to global -->
(To be filled by the team)
---
## Server State
<!-- How server data is cached and synchronized -->
(To be filled by the team)
---
## Common Mistakes
<!-- State management mistakes your team has made -->
(To be filled by the team)
.trellis/spec/frontend/type-safety.md
-51
查看文件
@@ -1,51 +0,0 @@
# Type Safety
> Type safety patterns in this project.
---
## Overview
<!--
Document your project's type safety conventions here.
Questions to answer:
- What type system do you use?
- How are types organized?
- What validation library do you use?
- How do you handle type inference?
-->
(To be filled by the team)
---
## Type Organization
<!-- Where types are defined, shared types vs local types -->
(To be filled by the team)
---
## Validation
<!-- Runtime validation patterns (Zod, Yup, io-ts, etc.) -->
(To be filled by the team)
---
## Common Patterns
<!-- Type utilities, generics, type guards -->
(To be filled by the team)
---
## Forbidden Patterns
<!-- any, type assertions, etc. -->
(To be filled by the team)
.trellis/spec/hyb-oa/deployment-trialrun.md
+3 -3
查看文件
@@ -15,10 +15,10 @@ operations require explicit approval and evidence.
if the example contract drifts.
- After deployment, report commit hash, `/ready`, public smoke results and
whether the user can test.
- Real business writes are manual unless an Issue explicitly authorizes a
controlled test write.
- Real business writes are manual unless the current Trellis task explicitly
authorizes a controlled test write.
- Do not execute real payments, import bank statements, connect payment
providers or write ERP without a separate approved Issue.
providers or write ERP without a separate approved Trellis task.
## Scenario: Deployment Env Contract
.trellis/spec/hyb-oa/frontend-react-vite-design.md
+5 -1
查看文件
@@ -8,6 +8,10 @@ experience and business-boundary fact source, not a visual, brand or aesthetic
rulebook. For PC/mobile/WeCom pages, add Playwright or visual verification when
reasonable.
This spec keeps hyb-oa-specific React/Vite, shared-component, business-boundary
and verification contracts. Do not copy broad aesthetic guidance from
`frontend-design` into this file; use the skill directly for design judgment.
## Rules
- Use existing React/Vite/Tailwind patterns and shared components before adding
@@ -26,7 +30,7 @@ reasonable.
## Frozen / Boundary Items
Frozen modules and Enterprise WeChat-owned HR/attendance entries must be labeled
or hidden according to the active Issue; do not silently re-enable them.
or hidden according to the current Trellis task; do not silently re-enable them.
- Use the shared `WorkspaceNotice` pattern for trial boundaries, safety notes,
and post-trial capabilities instead of page-local warning blocks.
- Trial-facing PC lists must hide obvious TEST/SMOKE records by default when a
.trellis/spec/hyb-oa/reimbursement-invoice-ocr.md
+2 -2
查看文件
@@ -8,9 +8,9 @@ duplicate detection or attachment behavior.
## Rules
- PDF invoice OCR is the maintained main path.
- Image OCR remains frozen unless a later Issue explicitly reopens it.
- Image OCR remains frozen unless a later Trellis task explicitly reopens it.
- Do not write raw invoice images, sensitive form values or full OCR payloads to
repo docs, Issue CSV, Trellis task files or chat.
- Reimbursement flow tests should cover upload/OCR, duplicate handling,
submission, approval, payment batch, receipt attachment and AP export when the
Issue scope touches those areas.
Trellis task scope touches those areas.