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

这个提交包含在:
2026-05-29 09:56:22 +08:00
父节点 cdd56bc5df
当前提交 c192c77c7a
共修改 22 个文件,包含 306 行新增和 610 行删除
@@ -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)
@@ -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)
-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)
+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.
@@ -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)
@@ -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)
-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)