@seanyao/roll 2026.424.1 → 2026.424.3

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/bin/roll CHANGED
@@ -4,7 +4,7 @@ set -euo pipefail
4
4
  # Roll — AI Agent Convention Manager
5
5
  # Single source of truth for how all AI coding agents behave.
6
6
 
7
- VERSION="2026.424.1"
7
+ VERSION="2026.424.3"
8
8
  ROLL_HOME="${ROLL_HOME:-${HOME}/.roll}"
9
9
  ROLL_CONFIG="${ROLL_HOME}/config.yaml"
10
10
  ROLL_GLOBAL="${ROLL_HOME}/conventions/global"
@@ -351,7 +351,7 @@ _sync_convention_for_tool() {
351
351
  local main_dst="$2" # target: ~/.claude/CLAUDE.md
352
352
  local force="$3"
353
353
 
354
- [[ -f "$src" ]] || return
354
+ [[ -f "$src" ]] || return 0
355
355
  local dst_dir
356
356
  dst_dir="$(dirname "$main_dst")"
357
357
 
@@ -1,100 +1,24 @@
1
- # Global Agent Conventions — Sean Yao
2
-
3
- > Master conventions file. All AI coding agents follow these principles.
4
- > Tool-specific files (CLAUDE.md, GEMINI.md, .cursor-rules) extend this document.
5
-
6
- ## Communication
7
-
8
- - Respond in the language I write in. Chinese message → Chinese response. English → English.
9
- - Code, commit messages, variable names, comments: always English.
10
- - Error messages in API responses: English.
11
- - UI-facing text: Chinese (internal tool for Chinese-speaking team).
12
- - Be concise. Don't summarize what you just did I can read the diff.
13
- - Don't ask for confirmation on routine actions. Just do it and show the result.
14
- - If something is ambiguous, make a reasonable judgment call. Only ask when the choice has real consequences.
15
- - Use plain language. No academic jargon or pretentious framing.
16
- - **Roll workflow milestones may be narrated.** It's fine to report high-level progress such as running baseline, sketching a design, completing an Action, passing a Verification Gate, or finishing TCR (Green/Commit or Red/Revert).
17
- - **Implementation details are invisible.** Do not include code diffs, file paths, line numbers, function names, variable names, test scripts, model parameters, or raw git output in conversational responses.
18
- - **Strategic reasoning is okay; tactical code-walking is not.** You may explain *why* a design choice was made at the product/business level. Do not narrate step-by-step code modifications or internal debugging monologues.
19
- - **Report in user-centric outcomes.** After making changes, summarize what improved for the user or product in 1–2 sentences.
20
- - **No code dumps unless explicitly asked.** Never paste code snippets, stack traces, or technical speculations into the chat.
21
- - **Business context over technical mechanics.** When explaining a bug or fix, lead with the user-visible effect. Root causes, if mentioned at all, belong in a single trailing sentence.
22
-
23
- ## Code Style
24
-
25
- - TypeScript strict mode. No `any` unless absolutely unavoidable.
26
- - Functional components with hooks. No class components.
27
- - Prefer `const` over `let`. Never `var`.
28
- - Early returns over nested conditionals.
29
- - Name things clearly — no abbreviations except well-known ones (e.g., `id`, `url`, `api`).
30
- - Keep functions short and single-purpose. If it needs a comment to explain, it's too complex.
31
- - Don't add comments unless the logic is genuinely non-obvious.
32
- - Don't add docstrings, JSDoc, or type annotations to code you didn't change.
33
-
34
- ## Git
35
-
36
- - Conventional commit format: `feat:`, `fix:`, `chore:`, `docs:`, `refactor:`, `test:`
37
- - Write in English, concise, imperative mood.
38
- - Never force push to main.
39
- - Never skip hooks (`--no-verify`).
40
- - Never commit `.env`, credentials, or secrets.
41
-
42
- ## Behavior
43
-
44
- - Do not refactor files unrelated to the current task.
45
- - Do not add features, refactoring, or "improvements" not requested.
46
- - Always ask before making structural changes (directory reorganization, architecture changes).
47
- - Don't wrap simple things in abstractions. Three similar lines > a premature helper.
48
- - Don't add error handling for impossible scenarios. Trust the framework.
49
- - Delete unused things completely — no `// removed` comments, no backward-compat shims.
50
- - Don't create README.md or documentation files unless asked.
51
-
52
- ## Testing
53
-
54
- - All business logic must have unit tests (coverage >80%).
55
- - All API endpoints must have integration tests — no DB mocks.
56
- - Critical user flows must have E2E tests (Playwright).
57
- - New architecture introductions (State/Cache/EventBus) must have data flow integration tests.
58
- - Run existing tests before pushing to verify no regressions.
59
-
60
- ## Engineering Common Sense
61
-
62
- Non-negotiable requirements for all code changes. Violating these is a bug:
63
-
64
- - **Idempotency**: Same operation N times = same result. Test by running 3 times.
65
- - **Cross-module contract**: Shared IDs, formats, algorithms must be identical across modules.
66
- - **Data flow integrity**: Producer → Storage → Consumer chain must be complete and tested.
67
- - **Atomicity**: Operations complete fully or not at all. Partial failure → rollback.
68
- - **Input validation**: All external input (API, user, file) must be validated.
69
- - **Graceful degradation**: Dependency fails → limited functionality, not crash.
70
- - **Observability**: User must see progress, state, and errors.
71
- - **Concurrency safety**: Shared resources under multi-thread/multi-process access must be safe.
72
-
73
- ## Roll Workflow (When Project Has It)
74
-
75
- When a project has Roll workflow configured:
76
-
77
- ### Workspace Structure
78
-
79
- - `BACKLOG.md` = index table, one-line summary per story only.
80
- - `docs/features/<feature>.md` = US details (AC, Files, Dependencies).
81
- - `docs/features/<feature>-plan.md` = architecture design doc (optional).
82
- - Never write project docs to `~/.kimi/` or any global config directory.
83
-
84
- ### Development Discipline
85
-
86
- - **TCR mandatory**: All code changes follow Test → Green = Commit / Red = Revert. No WIP commits.
87
- - **Action granularity**: Each Action independently deployable, completable in 2–5 min. No placeholders (no TBD/TODO/pending).
88
- - **Verification Gate**: Before marking done, provide fresh evidence (test output, screenshot, curl). "I confirmed it works" is not evidence.
89
- - **Complete delivery**: push to GitHub + CI passes + deployed online. Local-only done is not done.
90
-
91
- ### Skill Selection
92
-
93
- ```
94
- Uncertain approach? → $roll-design
95
- Want to ship something? → $roll-build (handles US-XXX, FIX-XXX, or vague ideas)
96
- Single bug fix? → $roll-fix
97
- High-risk logic? → $roll-spar
98
- Page/production issue? → $roll-debug
99
- Initialize new project? → roll init (CLI command, not a skill)
100
- ```
1
+ # Agent Conventions
2
+
3
+ > Baseline for AI-agent-friendly projects. Extend with project-specific rules.
4
+
5
+ ## 1. Communication
6
+ - User's language. Code/Git/Comments: English. UI: Chinese.
7
+ - Concise. No summaries/code-walking. Implementation invisible.
8
+ - Strategy (Why) OK; Tactics (How) NO. Outcomes only.
9
+
10
+ ## 2. Code
11
+ - **TS**: Strict, no `any`. Functional hooks. Early returns.
12
+ - **Git**: No force-push main. No `--no-verify`. No secrets in git.
13
+ - **Behavior**: No unrelated refactoring. No speculative abstractions.
14
+
15
+ ## 3. Engineering
16
+ - **Idempotency**: Same op N times = same result.
17
+ - **Atomicity**: Complete fully or rollback. No partial state.
18
+ - **Validation**: All external input validated. Fail fast on startup.
19
+ - **Testing**: Unit >80%. E2E for flows. No DB mocks.
20
+
21
+ ## 4. Workflow
22
+ - **TCR**: Test -> Green = Commit / Red = Revert. No WIP commits.
23
+ - **Workspace**: `BACKLOG.md` index. `docs/features/` for details.
24
+ - **Done**: Push + CI passes + deployed. Local-only is not done.
@@ -1,88 +1,27 @@
1
1
  # Project Conventions — Backend Service
2
2
 
3
- > Project-type-specific conventions reference material for skills.
4
- > **Note: Reference Template** — used by skills to infer project conventions. Not selected by users.
3
+ > Reference for skills to infer backend project conventions.
5
4
 
6
- ## API Design
5
+ ## 1. Design
6
+ - **API**: RESTful `/api/{res}/{id}`. Structured JSON errors.
7
+ - **Config**: `.env` (validate at start). Flags > Env > File.
8
+ - **Logging**: Structured JSON (pino/winston). No secrets/PII.
7
9
 
8
- - RESTful API with consistent URL structure: `/api/{resource}/{id}`.
9
- - For internal microservices, gRPC is acceptable.
10
- - Structured error responses: `{ error: string, code: string, details?: object }`.
11
- - Health check endpoint: `GET /api/health` returning `{ status: "ok", version: string }`.
12
- - API versioning via URL prefix (`/api/v1/`) when breaking changes are needed.
13
-
14
- ## Configuration
15
-
16
- - Environment config via `.env`. Never hardcode secrets.
17
- - Use `.env.example` as the template with all required variables documented.
18
- - Validate all env vars at startup — fail fast if missing.
19
- - Separate configs for development, staging, production.
20
-
21
- ## Logging
22
-
23
- - Structured JSON logging (e.g., pino, winston with JSON transport).
24
- - Log levels: `error`, `warn`, `info`, `debug`. Default to `info` in production.
25
- - Include correlation IDs for request tracing.
26
- - Never log secrets, tokens, or PII.
27
-
28
- ## Error Handling
29
-
30
- - Domain errors: typed error classes with error codes.
31
- - HTTP errors: map domain errors to appropriate status codes.
32
- - Unhandled errors: catch-all middleware, log full stack, return 500 with safe message.
33
- - Validation errors: 400 with detailed field-level error messages.
34
-
35
- ## Project Structure
10
+ ## 2. Architecture
11
+ - **DDD**: Organize by business domain, not tech layer.
12
+ - **Clean**: Routes (thin) -> Services (logic) -> Models (data).
13
+ - **Database**: Migrations mandatory. Transactions for multi-table.
36
14
 
15
+ ## 3. Structure
37
16
  ```
38
17
  src/
39
- ├── routes/ # HTTP route handlers (thin — delegate to services)
40
- ├── services/ # business logic (pure functions where possible)
41
- ├── models/ # data models, ORM entities, schemas
42
- ├── middleware/ # auth, logging, error handling, validation
43
- ├── utils/ # shared utilities
44
- ├── types/ # TypeScript type definitions
45
- ├── config/ # environment config, constants
46
- └── index.ts # entry point, server bootstrap
47
-
48
- tests/
49
- ├── unit/ # service/model unit tests
50
- ├── integration/ # API endpoint tests (supertest)
51
- └── regression/ # Sentinel regression
18
+ ├── routes/ # thin handlers
19
+ ├── services/ # business logic
20
+ ├── models/ # schemas/entities
21
+ └── middleware/ # auth/log/error
52
22
  ```
53
23
 
54
- ## Database
55
-
56
- - Migrations managed via a migration tool (Prisma, Drizzle, Knex).
57
- - Never modify production data manually — always through migrations.
58
- - Index frequently queried columns. Monitor slow queries.
59
- - Use transactions for multi-table operations.
60
-
61
- ## Security
62
-
63
- - Input validation on all endpoints (zod, joi, or similar).
64
- - Rate limiting on public endpoints.
65
- - CORS configured explicitly — no wildcard in production.
66
- - Authentication middleware applied at route level, not globally.
67
- - Secrets rotated periodically. Never in git history.
68
-
69
- ## Architecture Constraints
70
-
71
- - **Domain Driven**: organize code by business domain, not technical layer. `src/services/` contains domain logic, not generic utilities.
72
- - **Clean Architecture**: routes (thin) → services (business logic) → models (data) ← infrastructure (DB/external APIs). Routes delegate; they don't contain business logic.
73
- - **Data Schema First**: define types/schemas before writing business logic.
74
- - **API Contract**: typed request/response schemas. API changes must bump version or be backward-compatible.
75
-
76
- ## Development Discipline
77
-
78
- - **TCR mandatory**: All code changes follow Test → Green = Commit / Red = Revert. No WIP commits.
79
- - **Action granularity**: Each Action independently deployable, completable in 2–5 min. No placeholders (no TBD/TODO/pending).
80
- - **Verification Gate**: Before marking done, provide fresh evidence (test output, curl response). "I confirmed it works" is not evidence.
81
- - **Complete delivery**: push to GitHub + CI passes + deployed online. Local-only done is not done.
82
-
83
- ## Workspace Structure
84
-
85
- - `BACKLOG.md` = index table, one-line summary per story only.
86
- - `docs/features/<feature>.md` = US details (AC, Files, Dependencies).
87
- - `docs/features/<feature>-plan.md` = architecture design doc (optional).
88
- - Never write project docs to `~/.kimi/` or any global config directory.
24
+ ## 4. Discipline
25
+ - **TCR**: Mandatory.
26
+ - **Security**: Input validation (zod), Rate limiting, Secrets rotation.
27
+ - **Workspace**: `BACKLOG.md` + `docs/features/`.
@@ -1,66 +1,29 @@
1
1
  # Project Conventions — CLI Tool
2
2
 
3
- > Project-type-specific conventions reference material for skills.
4
- > **Note: Reference Template** — used by skills to infer project conventions. Not selected by users.
3
+ > Reference for skills to infer CLI project conventions.
5
4
 
6
- ## Design Principles
5
+ ## 1. Principles
6
+ - **Lightweight**: No server/frontend.
7
+ - **Commands**: `tool <cmd> [opts]`. One file per cmd in `src/commands/`.
8
+ - **Exit Codes**: 0 success, 1 user error, 2 system error.
7
9
 
8
- - Lightweight. No server, no frontend, no heavy frameworks.
9
- - Clear command structure: `tool <command> [options] [args]`.
10
- - Helpful error messages with actionable suggestions.
11
- - Consistent exit codes: 0 = success, 1 = user error, 2 = system error.
12
- - Support `--help` and `--version` on every command.
13
- - Respect `NO_COLOR` env var for output formatting.
14
-
15
- ## Architecture
16
-
17
- - Single entry point dispatching to command handlers.
18
- - Each command in its own file — easy to find, easy to test.
19
- - Config loading: CLI flags > environment variables > config file > defaults.
20
- - Use a CLI framework (commander, yargs, or citty) for argument parsing.
21
-
22
- ## Output
23
-
24
- - Default to human-readable output. Support `--json` for machine-readable.
25
- - Progress indicators for long operations (ora, cli-progress).
26
- - Errors to stderr, results to stdout.
27
- - Quiet mode (`--quiet` or `-q`) suppresses non-essential output.
28
-
29
- ## Project Structure
10
+ ## 2. Architecture
11
+ - **Entry**: `src/index.ts` bootstrap.
12
+ - **Config**: Flags > Env > File > Defaults.
13
+ - **Output**: Human-friendly default, `--json` support. Errors to stderr.
30
14
 
15
+ ## 3. Structure
31
16
  ```
32
17
  src/
33
- ├── index.ts # entry point, CLI bootstrap
34
- ├── commands/ # one file per command
35
- │ ├── init.ts
36
- │ ├── build.ts
37
- │ └── ...
38
- ├── utils/ # shared utilities
39
- ├── types/ # type definitions
40
- └── config.ts # config loading logic
41
-
18
+ ├── index.ts # bootstrap
19
+ ├── commands/ # handlers
20
+ └── config.ts # logic
42
21
  tests/
43
- ├── unit/ # command logic tests
44
- └── integration/ # full CLI invocation tests (execa)
22
+ ├── unit/ # logic
23
+ └── integration/ # execa
45
24
  ```
46
25
 
47
- ## Distribution
48
-
49
- - Compile to single executable or publish to npm.
50
- - Include `bin` field in `package.json`.
51
- - Test installation flow: `npm install -g` should work cleanly.
52
- - Include a man page or `--help` output that covers all commands.
53
-
54
- ## Development Discipline
55
-
56
- - **TCR mandatory**: All code changes follow Test → Green = Commit / Red = Revert. No WIP commits.
57
- - **Action granularity**: Each Action independently deployable, completable in 2–5 min. No placeholders (no TBD/TODO/pending).
58
- - **Verification Gate**: Before marking done, run the actual command and paste the output. "I confirmed it works" is not evidence.
59
- - **Complete delivery**: push to GitHub + CI passes + published/deployed. Local-only done is not done.
60
-
61
- ## Workspace Structure
62
-
63
- - `BACKLOG.md` = index table, one-line summary per story only.
64
- - `docs/features/<feature>.md` = US details (AC, Files, Dependencies).
65
- - `docs/features/<feature>-plan.md` = architecture design doc (optional).
66
- - Never write project docs to `~/.kimi/` or any global config directory.
26
+ ## 4. Discipline
27
+ - **TCR**: Mandatory.
28
+ - **Distribution**: `bin` in `package.json`, test `npm i -g`.
29
+ - **Workspace**: `BACKLOG.md` + `docs/features/`.
@@ -1,71 +1,26 @@
1
1
  # Project Conventions — Frontend Only
2
2
 
3
- > Project-type-specific conventions reference material for skills.
4
- > **Note: Reference Template** — used by skills to infer project conventions. Not selected by users.
3
+ > Reference for skills to infer frontend project conventions.
5
4
 
6
- ## Frontend
5
+ ## 1. Stack
6
+ - **Core**: React 18+ / TS / Vite / Tailwind / shadcn/ui.
7
+ - **State**: React state (simple), Zustand/Jotai (complex), TanStack Query (server).
8
+ - **Structure**: `src/domains/{domain}/` for DDD.
7
9
 
8
- - Stack: React 18+ / TypeScript / Vite / Tailwind CSS / shadcn/ui / Lucide React
9
- - Use shadcn/ui components first. Custom components only when shadcn doesn't cover it.
10
- - `src/components/ui/` is shadcn-generated never edit manually.
11
- - `src/components/[feature]/` for custom feature components.
12
- - Tailwind utility classes only. No inline styles, no CSS modules.
13
- - Organize by domain: `src/domains/{domain}/components/`, `hooks/`, `services/`, `types.ts`
14
- - Shared utilities in `src/shared/` (api/, types/, utils/, hooks/).
15
-
16
- ## Architecture
17
-
18
- - **Domain Driven Design**: organize code by business domain, not technical layer.
19
- - **Clean Architecture**: UI → Application (hooks) → Domain (services) → Infrastructure (API client).
20
- - **Decoupling**: UI renders only, logic lives in hooks. API calls wrapped in services.
21
- - **Data Schema First**: define types/schemas before writing business logic.
22
- - No backend code in this project. API consumption only.
23
-
24
- ## State Management
25
-
26
- - Prefer React built-in state (useState, useReducer, useContext) for simple cases.
27
- - Use a state library (Zustand, Jotai) only when shared state gets complex.
28
- - Server state via TanStack Query (React Query) for API data fetching and caching.
29
-
30
- ## Project Structure
10
+ ## 2. Architecture
11
+ - **DDD**: Logic in hooks/services, not components.
12
+ - **Decoupling**: UI renders only, logic in hooks.
13
+ - **Data**: Define schemas before logic.
31
14
 
15
+ ## 3. Structure
32
16
  ```
33
17
  src/
34
- ├── components/ui/ # shadcn/ui (generated, don't edit)
35
- ├── domains/ # DDD by business domain
36
- └── {domain}/
37
- │ ├── components/ # domain-specific UI
38
- │ ├── hooks/ # domain logic + state
39
- │ ├── services/ # API client calls
40
- │ └── types.ts # domain types
41
- ├── shared/
42
- │ ├── api/ # HTTP client, interceptors
43
- │ ├── types/ # shared type definitions
44
- │ └── utils/ # utility functions
45
- ├── App.tsx
46
- └── main.tsx
47
-
48
- tests/
49
- ├── unit/ # Vitest + Testing Library
50
- └── e2e/ # Playwright
18
+ ├── components/ui/ # shadcn (don't edit)
19
+ ├── domains/ # DDD components/hooks/services
20
+ └── shared/ # api/types/utils
51
21
  ```
52
22
 
53
- ## Development Discipline
54
-
55
- - **TCR mandatory**: All code changes follow Test → Green = Commit / Red = Revert. No WIP commits.
56
- - **Action granularity**: Each Action independently deployable, completable in 2–5 min. No placeholders (no TBD/TODO/pending).
57
- - **Verification Gate**: Before marking done, provide fresh evidence (test output, screenshot). "I confirmed it works" is not evidence.
58
- - **Complete delivery**: push to GitHub + CI passes + deployed online. Local-only done is not done.
59
-
60
- ## Testing Requirements
61
-
62
- - All hooks and domain logic must have unit tests (Vitest + Testing Library, coverage >80%).
63
- - Critical user flows must have E2E tests (Playwright).
64
- - Run existing tests before pushing to verify no regressions.
65
-
66
- ## Workspace Structure
67
-
68
- - `BACKLOG.md` = index table, one-line summary per story only.
69
- - `docs/features/<feature>.md` = US details (AC, Files, Dependencies).
70
- - `docs/features/<feature>-plan.md` = architecture design doc (optional).
71
- - Never write project docs to `~/.kimi/` or any global config directory.
23
+ ## 4. Discipline
24
+ - **TCR**: Mandatory.
25
+ - **Testing**: Unit (hooks/logic) >80%, E2E (Playwright).
26
+ - **Workspace**: `BACKLOG.md` + `docs/features/`.
@@ -1,87 +1,29 @@
1
1
  # Project Conventions — Fullstack Web
2
2
 
3
- > Project-type-specific conventions reference material for skills.
4
- > **Note: Reference Template** — used by skills to infer project conventions. Not selected by users.
3
+ > Reference for skills to infer fullstack project conventions.
5
4
 
6
- ## Frontend
5
+ ## 1. Stack
6
+ - **Frontend**: React 18+ / TS / Vite / Tailwind / shadcn/ui.
7
+ - **Backend**: Node.js REST API.
8
+ - **Structure**: `src/domains/{domain}/` for DDD. `api/` for backend.
7
9
 
8
- - Stack: React 18+ / TypeScript / Vite / Tailwind CSS / shadcn/ui / Lucide React
9
- - Use shadcn/ui components first. Custom components only when shadcn doesn't cover it.
10
- - `src/components/ui/` is shadcn-generated never edit manually.
11
- - `src/components/[feature]/` for custom feature components.
12
- - Tailwind utility classes only. No inline styles, no CSS modules.
13
- - Organize by domain: `src/domains/{domain}/components/`, `hooks/`, `services/`, `types.ts`
14
- - Shared utilities in `src/shared/` (api/, types/, utils/, hooks/).
15
-
16
- ## Backend
17
-
18
- - RESTful API conventions. Consistent URL structure: `/api/{resource}/{id}`.
19
- - Structured error responses: `{ error: string, code: string, details?: object }`.
20
- - Environment-based config via `.env`. Never hardcode secrets.
21
- - Folder structure:
22
- - `src/routes/` or `api/routes/` — route handlers
23
- - `src/services/` or `api/services/` — business logic
24
- - `src/models/` or `api/models/` — data models and schemas
25
- - Health check endpoint: `GET /api/health`
26
- - Authentication: JWT in httpOnly cookies.
27
-
28
- ## Architecture
29
-
30
- - **Domain Driven Design**: organize code by business domain, not technical layer.
31
- - **Clean Architecture**: UI → Application (hooks) → Domain (services) → Infrastructure (API/DB).
32
- - **Decoupling**: UI renders only, logic lives in hooks. API calls wrapped in services.
33
- - **Data Schema First**: define types/schemas before writing business logic.
34
- - **Frontend-Backend Contract**: API changes must sync `shared/types/`. Errors use unified format.
35
-
36
- ## Project Structure
10
+ ## 2. Architecture
11
+ - **DDD**: Logic in hooks/services, not components.
12
+ - **Contract**: API changes must sync `shared/types/`.
13
+ - **Data**: Define schemas before logic.
37
14
 
15
+ ## 3. Structure
38
16
  ```
39
17
  src/
40
- ├── components/ui/ # shadcn/ui (generated, don't edit)
41
- ├── domains/ # DDD by business domain
42
- └── {domain}/
43
- │ ├── components/ # domain-specific UI
44
- │ ├── hooks/ # domain logic
45
- │ ├── services/ # API calls
46
- │ └── types.ts # domain types
47
- ├── shared/
48
- │ ├── api/ # HTTP client, interceptors
49
- │ ├── types/ # shared type definitions
50
- │ └── utils/ # utility functions
51
- ├── App.tsx
52
- └── main.tsx
53
-
18
+ ├── components/ui/ # shadcn (don't edit)
19
+ ├── domains/ # DDD components/hooks/services
20
+ └── shared/ # api/types/utils
54
21
  api/
55
- ├── routes/ # RESTful route handlers
56
- ├── services/ # business logic
57
- ├── models/ # data models
58
- └── types.ts # API contract types
59
-
60
- schema/ # data contract definitions
61
- tests/
62
- ├── unit/ # Vitest
63
- ├── e2e/ # Playwright
64
- └── regression/ # Sentinel regression
22
+ ├── routes/ # thin handlers
23
+ └── services/ # business logic
65
24
  ```
66
25
 
67
- ## Development Discipline
68
-
69
- - **TCR mandatory**: All code changes follow Test → Green = Commit / Red = Revert. No WIP commits.
70
- - **Action granularity**: Each Action independently deployable, completable in 2–5 min. No placeholders (no TBD/TODO/pending).
71
- - **Verification Gate**: Before marking done, provide fresh evidence (test output, screenshot, curl). "I confirmed it works" is not evidence.
72
- - **Complete delivery**: push to GitHub + CI passes + deployed online. Local-only done is not done.
73
-
74
- ## Testing Requirements
75
-
76
- - All business logic must have unit tests (coverage >80%).
77
- - All API endpoints must have integration tests — no DB mocks, use real database.
78
- - Critical user flows must have E2E tests (Playwright).
79
- - New architecture introductions (State/Cache/EventBus) must have data flow integration tests.
80
- - Sentinel will periodically regression-test completed Stories.
81
-
82
- ## Workspace Structure
83
-
84
- - `BACKLOG.md` = index table, one-line summary per story only.
85
- - `docs/features/<feature>.md` = US details (AC, Files, Dependencies).
86
- - `docs/features/<feature>-plan.md` = architecture design doc (optional).
87
- - Never write project docs to `~/.kimi/` or any global config directory.
26
+ ## 4. Discipline
27
+ - **TCR**: Mandatory.
28
+ - **Testing**: Unit >80%, E2E for critical flows.
29
+ - **Workspace**: `BACKLOG.md` + `docs/features/`.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@seanyao/roll",
3
- "version": "2026.424.1",
3
+ "version": "2026.424.3",
4
4
  "description": "Roll — Roll out features with AI agents",
5
5
  "scripts": {
6
6
  "test": "find tests/unit tests/integration -name '*.bats' | sort | xargs ./tests/helpers/bats-core/bin/bats"
@@ -1,80 +1,26 @@
1
- # Project Agents Configuration
1
+ # Agent Conventions
2
2
 
3
- ## Workspace Configuration
3
+ > Project template. Customize section 5 with project-specific rules.
4
4
 
5
- ### Plan Documents Location
6
- **All Plan documents must be stored under the project directory. Writing to the `.kimi/` directory is prohibited.**
5
+ ## 1. Communication
6
+ - User's language. Code/Git/Comments: English. UI: Chinese.
7
+ - Concise. No summaries/code-walking. Outcomes only.
7
8
 
8
- ```yaml
9
- # Plan file storage configuration
10
- plans:
11
- base_dir: docs/plans/ # Relative to the project root
12
- auto_create: true # Auto-create directory if it doesn't exist
13
- naming_convention: "{topic}.md" # Naming convention
14
- ```
9
+ ## 2. Standards
10
+ - **TS**: Strict, no `any`. Functional hooks.
11
+ - **Test**: Unit >80%, E2E for flows. No WIP commits.
12
+ - **Done**: Push + CI passes + deployed. Local-only is not done.
15
13
 
16
- **Rules:**
17
- 1. **Preferred location**: `{project_root}/docs/plans/`
18
- 2. **Auto-create**: If `docs/plans/` doesn't exist, create the directory automatically
19
- 3. **Prohibited location**: Absolutely no writing to `~/.kimi/` or any global config directory
20
- 4. **Non-project Plans**: Only allowed to use a temporary location when there is no project context
14
+ ## 3. Roll Workflow
15
+ - **Design**: `$roll-design` -> Stories -> `BACKLOG.md`
16
+ - **Build**: `$roll-build` / `$roll-fix` -> TCR (Green=Commit, Red=Revert)
17
+ - **Patrol**: `$roll-sentinel` periodic + `$roll-debug` on failure
18
+ - **Workspace**: `BACKLOG.md` index. `docs/features/<feat>.md` for details.
21
19
 
22
- **Examples:**
23
- - `my-project/docs/plans/auth-system.md`
24
- - `my-project/docs/plans/api-redesign.md`
25
- - `~/.kimi/skills/some-plan.md`
26
- - ❌ Any global location outside the project
20
+ ## 4. Architecture
21
+ - **Schema First**: Define types before logic.
22
+ - **Domain Driven**: Organize by business domain, not tech layer.
23
+ - **Decoupling**: UI renders only. Logic in hooks/services.
27
24
 
28
- ## Workflow
29
-
30
- ### Design → $roll-design
31
- - Solution exploration, architecture design
32
- - Split into Stories
33
- - Write to BACKLOG.md
34
-
35
- ### Build → $roll-build / $roll-fix
36
- - Read BACKLOG and execute
37
- - TCR development (independent Actions auto-parallelized + Worktree isolation)
38
- - CI/CD deployment
39
-
40
- ### Check → $roll-sentinel / $roll-debug
41
- - Sentinel: Scheduled patrol
42
- - $roll-debug: Deep diagnosis
43
-
44
- ### Fix → $roll-fix / $roll-design
45
- - Fix issues
46
- - Or re-plan
47
-
48
- ## Architecture Constraints
49
-
50
- ### Agent First
51
- - System designed for AI Agents
52
- - Agent is the primary user
53
- - UI is only a supplementary interface
54
-
55
- ### Data Schema
56
- - Clear data structure definitions
57
- - Type/Schema is the contract between humans and Agents
58
- - Define Schema first, then write business logic
59
-
60
- ### Domain Driven
61
- - Model by business domain
62
- - Not database table design
63
- - Help Agents understand the business
64
-
65
- ### Decoupling Rules
66
- - UI layer only handles rendering; logic lives in Hooks
67
- - API calls encapsulated in services/
68
- - Shared types placed in shared/types/
69
-
70
- ### Testing Requirements
71
- - All business logic must have unit tests
72
- - APIs have integration tests
73
- - Critical flows have E2E tests
74
- - Sentinel runs periodic regression tests
75
-
76
- ## Conventions
77
-
78
- - All work tracked in BACKLOG.md
79
- - Sentinel patrols every 6 hours
80
- - TCR required for all changes
25
+ ## 5. Project Specifics
26
+ <!-- Add project-specific stack, structure, and constraints. -->