@c-d-cc/reap 0.1.0
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/README.ko.md +309 -0
- package/README.md +308 -0
- package/dist/cli.js +9982 -0
- package/dist/templates/artifacts/01-objective.md +29 -0
- package/dist/templates/artifacts/02-planning.md +14 -0
- package/dist/templates/artifacts/03-implementation.md +19 -0
- package/dist/templates/artifacts/04-validation.md +20 -0
- package/dist/templates/artifacts/05-completion.md +47 -0
- package/dist/templates/commands/reap.back.md +54 -0
- package/dist/templates/commands/reap.completion.md +96 -0
- package/dist/templates/commands/reap.evolve.md +48 -0
- package/dist/templates/commands/reap.help.md +61 -0
- package/dist/templates/commands/reap.implementation.md +102 -0
- package/dist/templates/commands/reap.next.md +53 -0
- package/dist/templates/commands/reap.objective.md +171 -0
- package/dist/templates/commands/reap.planning.md +88 -0
- package/dist/templates/commands/reap.start.md +44 -0
- package/dist/templates/commands/reap.status.md +70 -0
- package/dist/templates/commands/reap.sync.md +95 -0
- package/dist/templates/commands/reap.validation.md +85 -0
- package/dist/templates/genome/constraints.md +38 -0
- package/dist/templates/genome/conventions.md +35 -0
- package/dist/templates/genome/domain/README.md +96 -0
- package/dist/templates/genome/principles.md +31 -0
- package/dist/templates/help/en.txt +32 -0
- package/dist/templates/help/ko.txt +32 -0
- package/dist/templates/hooks/reap-guide.md +188 -0
- package/dist/templates/hooks/session-start.sh +163 -0
- package/dist/templates/presets/bun-hono-react/constraints.md +28 -0
- package/dist/templates/presets/bun-hono-react/conventions.md +28 -0
- package/dist/templates/presets/bun-hono-react/principles.md +28 -0
- package/package.json +45 -0
|
@@ -0,0 +1,96 @@
|
|
|
1
|
+
# Domain Rules — Writing Guide
|
|
2
|
+
|
|
3
|
+
> `genome/domain/` is a space for recording the **business domain rules** of the project.
|
|
4
|
+
> If `principles.md`, `conventions.md`, and `constraints.md` are the map of "what to do",
|
|
5
|
+
> `domain/` holds the details of "how, why, and how much".
|
|
6
|
+
|
|
7
|
+
## domain/ vs Upper-level Genome Files
|
|
8
|
+
|
|
9
|
+
| Upper-level Genome File | domain/ File |
|
|
10
|
+
|-------------------------|-------------|
|
|
11
|
+
| One-line architecture decision | Detailed rules, flows, and state transitions for that decision |
|
|
12
|
+
| Technical constraint summary | Thresholds, frequencies, conditions, and policy intent |
|
|
13
|
+
| Code pattern name | Pattern inputs/outputs, triggers, and exception cases |
|
|
14
|
+
|
|
15
|
+
**Example**: A one-liner in constraints.md: "Moderation suspension escalation: 3 times/1h → 30 min"
|
|
16
|
+
→ domain/moderation-policy.md contains the full pipeline, threshold table, and state transition details
|
|
17
|
+
|
|
18
|
+
## File Organization Principles
|
|
19
|
+
|
|
20
|
+
### 1. Separate by Business Domain Unit
|
|
21
|
+
|
|
22
|
+
Split files by **business rule grouping**, not by code structure (files, directories).
|
|
23
|
+
|
|
24
|
+
- **Good examples**: `interview-protocol.md`, `billing-rules.md`, `moderation-policy.md`
|
|
25
|
+
- **Bad examples**: `api-routes.md`, `database-tables.md`, `components.md`
|
|
26
|
+
|
|
27
|
+
Each domain file corresponds to one "topic you would ask a domain expert about".
|
|
28
|
+
|
|
29
|
+
### 2. Record Knowledge Not Directly Readable from Code
|
|
30
|
+
|
|
31
|
+
Do not write down things that can be learned by reading the code (function signatures, type definitions).
|
|
32
|
+
Record things that are difficult to determine from code alone:
|
|
33
|
+
|
|
34
|
+
- **Policy intent**: Why this threshold, why this order
|
|
35
|
+
- **Values and conditions**: Frequency (20–30%), limits (max 2), escalation steps
|
|
36
|
+
- **State machines**: Trigger → state transition → result
|
|
37
|
+
- **Domain term definitions**: Precise meaning of project-specific concepts
|
|
38
|
+
|
|
39
|
+
### 3. Agent-Implementable Level
|
|
40
|
+
|
|
41
|
+
An agent reading a domain file should be able to implement or modify the feature without additional questions.
|
|
42
|
+
|
|
43
|
+
- Structure with tables/diagrams
|
|
44
|
+
- Specify concrete values and conditions
|
|
45
|
+
- Include exception cases and edge cases
|
|
46
|
+
- Prohibit vague expressions like "it depends on the situation"
|
|
47
|
+
|
|
48
|
+
### 4. File Size
|
|
49
|
+
|
|
50
|
+
- Recommended: 40–80 lines
|
|
51
|
+
- Upper limit: 100 lines (same as the genome map principle)
|
|
52
|
+
- If exceeding 100 lines, split into sub-topics
|
|
53
|
+
|
|
54
|
+
### 5. Genome Total Budget (SessionStart Load)
|
|
55
|
+
|
|
56
|
+
- **L1** (upper-level genome files: principles, conventions, constraints): ~500 line limit. Always loaded in full
|
|
57
|
+
- **L2** (domain/ files): ~200 line limit. Loaded in full within budget; if exceeded, only titles + summaries are loaded (on-demand reading)
|
|
58
|
+
- As domain files grow, keep each file more concise or consolidate files with low reference frequency
|
|
59
|
+
|
|
60
|
+
## File Structure Template
|
|
61
|
+
|
|
62
|
+
```markdown
|
|
63
|
+
# [Domain Rule Name]
|
|
64
|
+
|
|
65
|
+
> [One-line description: scope covered by this file]
|
|
66
|
+
|
|
67
|
+
## [Core Concepts/Flows]
|
|
68
|
+
(Explain the core process or concepts of this domain)
|
|
69
|
+
|
|
70
|
+
## [Rules/Policy Table]
|
|
71
|
+
(Structure values, conditions, thresholds, etc. as a table)
|
|
72
|
+
|
|
73
|
+
## [State Transitions / Triggers]
|
|
74
|
+
(When does what occur)
|
|
75
|
+
|
|
76
|
+
## [Exceptions/Edge Cases]
|
|
77
|
+
(Exceptions to the general rules)
|
|
78
|
+
```
|
|
79
|
+
|
|
80
|
+
## Naming Rules
|
|
81
|
+
|
|
82
|
+
- Filename: `kebab-case.md`
|
|
83
|
+
- Names that intuitively represent the business domain
|
|
84
|
+
- Examples: `interview-protocol.md`, `article-generation.md`, `subscription-billing.md`
|
|
85
|
+
|
|
86
|
+
## When to Create a Domain File
|
|
87
|
+
|
|
88
|
+
- When a single item in an upper-level genome file requires 3+ lines of explanation
|
|
89
|
+
- When new business rules are added that don't fit the scope of existing files
|
|
90
|
+
- When a topic is something an agent implementing a feature would ask "where is this rule?"
|
|
91
|
+
|
|
92
|
+
## When NOT to Create a Domain File
|
|
93
|
+
|
|
94
|
+
- Implementation details that can be understood by reading the code
|
|
95
|
+
- One-off task notes (record these in life/)
|
|
96
|
+
- External library usage (refer to official documentation for these)
|
|
@@ -0,0 +1,31 @@
|
|
|
1
|
+
# Architecture Principles
|
|
2
|
+
|
|
3
|
+
> **Writing principle**: This file should be a **map** of ~100 lines or fewer.
|
|
4
|
+
> Write at a level where agents can act immediately.
|
|
5
|
+
> Separate detailed content into files under `domain/`.
|
|
6
|
+
> Modified only during the Birth phase.
|
|
7
|
+
|
|
8
|
+
## Core Beliefs
|
|
9
|
+
|
|
10
|
+
Describe core principles that both agents and humans must follow.
|
|
11
|
+
Principles should be specific and verifiable. Instead of "write good code",
|
|
12
|
+
describe it as "all external inputs are parsed/validated at the system boundary".
|
|
13
|
+
|
|
14
|
+
- (Add architecture principles here)
|
|
15
|
+
|
|
16
|
+
## Architecture Decisions
|
|
17
|
+
|
|
18
|
+
Record major architecture decisions in ADR (Architecture Decision Record) format.
|
|
19
|
+
Agents should be able to reason about "why it is this way".
|
|
20
|
+
|
|
21
|
+
| ID | Decision | Rationale | Date |
|
|
22
|
+
|----|----------|-----------|------|
|
|
23
|
+
| | | | |
|
|
24
|
+
|
|
25
|
+
## Layer Map
|
|
26
|
+
|
|
27
|
+
Describe the project's layer structure and dependency direction.
|
|
28
|
+
Specify which layers can depend on which layers.
|
|
29
|
+
Write detailed layer rules in files under `domain/`.
|
|
30
|
+
|
|
31
|
+
- (Describe layer structure here)
|
|
@@ -0,0 +1,32 @@
|
|
|
1
|
+
REAP — Recursive Evolutionary Autonomous Pipeline
|
|
2
|
+
|
|
3
|
+
CLI Commands:
|
|
4
|
+
reap init [name] Initialize a new REAP project
|
|
5
|
+
reap status Show current project and Generation status
|
|
6
|
+
reap update Sync slash commands, templates, and hooks
|
|
7
|
+
reap fix Diagnose and repair .reap/ directory
|
|
8
|
+
reap help Show this help message
|
|
9
|
+
|
|
10
|
+
Slash Commands (use in Claude Code):
|
|
11
|
+
/reap.start Start a new Generation
|
|
12
|
+
/reap.evolve Run the full lifecycle autonomously
|
|
13
|
+
/reap.objective Define goal + requirements
|
|
14
|
+
/reap.planning Task decomposition + implementation plan
|
|
15
|
+
/reap.implementation Code implementation
|
|
16
|
+
/reap.validation Run tests + check completion criteria
|
|
17
|
+
/reap.completion Retrospective + genome updates
|
|
18
|
+
/reap.next Advance to the next stage
|
|
19
|
+
/reap.back Return to a previous stage
|
|
20
|
+
/reap.status Show current state
|
|
21
|
+
/reap.sync Synchronize Genome with source code
|
|
22
|
+
/reap.help Contextual help (AI-powered)
|
|
23
|
+
|
|
24
|
+
Quick Start:
|
|
25
|
+
1. reap init my-project
|
|
26
|
+
2. /reap.evolve (runs the full lifecycle)
|
|
27
|
+
— or step by step: /reap.start → /reap.objective → /reap.next → ...
|
|
28
|
+
|
|
29
|
+
Config: .reap/config.yml
|
|
30
|
+
strict: true/false Restrict code changes to REAP workflow only
|
|
31
|
+
|
|
32
|
+
Docs: https://github.com/c-d-cc/reap
|
|
@@ -0,0 +1,32 @@
|
|
|
1
|
+
REAP — Recursive Evolutionary Autonomous Pipeline
|
|
2
|
+
|
|
3
|
+
CLI 명령어:
|
|
4
|
+
reap init [name] 새 REAP 프로젝트 초기화
|
|
5
|
+
reap status 현재 프로젝트 및 Generation 상태 확인
|
|
6
|
+
reap update 슬래시 커맨드, 템플릿, 훅을 최신 버전으로 동기화
|
|
7
|
+
reap fix .reap/ 디렉토리 구조 진단 및 복구
|
|
8
|
+
reap help 이 도움말 표시
|
|
9
|
+
|
|
10
|
+
슬래시 커맨드 (Claude Code에서 사용):
|
|
11
|
+
/reap.start 새 Generation 시작
|
|
12
|
+
/reap.evolve 전체 라이프사이클 자율 실행
|
|
13
|
+
/reap.objective 목표 + 요구사항 정의
|
|
14
|
+
/reap.planning 작업 분해 + 구현 계획
|
|
15
|
+
/reap.implementation 코드 구현
|
|
16
|
+
/reap.validation 테스트 실행 + 완료 기준 확인
|
|
17
|
+
/reap.completion 회고 + Genome 업데이트
|
|
18
|
+
/reap.next 다음 단계로 전진
|
|
19
|
+
/reap.back 이전 단계로 회귀
|
|
20
|
+
/reap.status 현재 상태 확인
|
|
21
|
+
/reap.sync Genome을 소스 코드와 동기화
|
|
22
|
+
/reap.help 상황별 도움말 (AI 기반)
|
|
23
|
+
|
|
24
|
+
빠른 시작:
|
|
25
|
+
1. reap init my-project
|
|
26
|
+
2. /reap.evolve (전체 라이프사이클 실행)
|
|
27
|
+
— 또는 단계별: /reap.start → /reap.objective → /reap.next → ...
|
|
28
|
+
|
|
29
|
+
설정: .reap/config.yml
|
|
30
|
+
strict: true/false 코드 변경을 REAP 워크플로우로 제한
|
|
31
|
+
|
|
32
|
+
문서: https://github.com/c-d-cc/reap
|
|
@@ -0,0 +1,188 @@
|
|
|
1
|
+
# REAP Guide
|
|
2
|
+
|
|
3
|
+
## What is REAP
|
|
4
|
+
|
|
5
|
+
REAP (Recursive Evolutionary Autonomous Pipeline) is a development pipeline where AI and humans collaborate to incrementally evolve an Application across successive Generations.
|
|
6
|
+
|
|
7
|
+
## 3-Layer Model
|
|
8
|
+
|
|
9
|
+
```
|
|
10
|
+
Genome (Genetic Information) → Evolution (Cross-generational Evolution) → Civilization (Source Code)
|
|
11
|
+
Design and knowledge Life cycle, mutation, adaptation Accumulated artifacts
|
|
12
|
+
```
|
|
13
|
+
|
|
14
|
+
- **Genome** — Design and knowledge for building the Application. Stored in `.reap/genome/`.
|
|
15
|
+
- **Evolution** — The process by which Genome evolves and Civilization grows through repeated Generations.
|
|
16
|
+
- **Civilization** — Source Code. The entire project codebase outside `.reap/`.
|
|
17
|
+
|
|
18
|
+
## Genome Structure
|
|
19
|
+
|
|
20
|
+
```
|
|
21
|
+
.reap/genome/
|
|
22
|
+
├── principles.md # Architecture principles/decisions (ADR style)
|
|
23
|
+
├── domain/ # Business rules (separated by module)
|
|
24
|
+
├── conventions.md # Development rules/conventions + Enforced Rules
|
|
25
|
+
└── constraints.md # Technical constraints/choices + Validation Commands
|
|
26
|
+
```
|
|
27
|
+
|
|
28
|
+
**Genome Immutability Principle**: The current generation does not modify Genome directly. Issues discovered during Implementation are recorded in the backlog as `type: genome-change` and applied to Genome only during the Completion stage.
|
|
29
|
+
|
|
30
|
+
**Environment Immutability Principle**: The current generation does not modify Environment directly. External environment changes discovered during a generation are recorded in the backlog as `type: environment-change` and applied during the Completion stage.
|
|
31
|
+
|
|
32
|
+
## .reap/ 4-Axis Structure
|
|
33
|
+
|
|
34
|
+
| Axis | Path | Role |
|
|
35
|
+
|------|------|------|
|
|
36
|
+
| **Genome** | `.reap/genome/` | Genetic information. Collection of principles, rules, and decisions |
|
|
37
|
+
| **Environment** | `.reap/environment/` | External environment. API docs, infrastructure info, business constraints |
|
|
38
|
+
| **Life** | `.reap/life/` | Current generation's life cycle. Progress state and artifacts |
|
|
39
|
+
| **Lineage** | `.reap/lineage/` | Genealogy. Archive of completed generations |
|
|
40
|
+
|
|
41
|
+
## Life Cycle (A Single Generation's Lifespan)
|
|
42
|
+
|
|
43
|
+
```
|
|
44
|
+
Objective → Planning → Implementation ⟷ Validation → Completion
|
|
45
|
+
```
|
|
46
|
+
|
|
47
|
+
| Stage | Description | What it does | Artifact |
|
|
48
|
+
|-------|-------------|--------------|----------|
|
|
49
|
+
| **Objective** | Goal definition | Define this generation's goal + requirements. Reference environment, backlog, genome | `01-objective.md` |
|
|
50
|
+
| **Planning** | Plan formulation | Task decomposition, dependencies, implementation approach | `02-planning.md` |
|
|
51
|
+
| **Implementation** | Implementation | AI+Human collaboration to write code. Record genome defects in backlog when found | `03-implementation.md` |
|
|
52
|
+
| **Validation** | Verification | Run tests, check completion criteria. Can regress to Implementation on failure | `04-validation.md` |
|
|
53
|
+
| **Completion** | Finalization | Retrospective + backlog review + apply genome changes + archiving | `05-completion.md` |
|
|
54
|
+
|
|
55
|
+
## Key Concepts
|
|
56
|
+
|
|
57
|
+
### Generation
|
|
58
|
+
A single generation. Carries one goal through the Life Cycle. State is tracked in `life/current.yml`.
|
|
59
|
+
|
|
60
|
+
### Backlog
|
|
61
|
+
All items to be carried forward to the next generation are stored in `.reap/life/backlog/`. Each item uses markdown + frontmatter format:
|
|
62
|
+
- `type: genome-change` — Applied to genome during Completion (genome defects discovered mid-generation)
|
|
63
|
+
- `type: environment-change` — Applied to environment during Completion (external environment changes discovered mid-generation)
|
|
64
|
+
- `type: task` — Referenced as goal candidates in the next Objective (deferred tasks, tech debt, etc.)
|
|
65
|
+
|
|
66
|
+
Each item also carries a `status` field:
|
|
67
|
+
- `status: pending` — Not yet processed (default; absent field treated as pending)
|
|
68
|
+
- `status: consumed` — Processed in the current generation (requires `consumedBy: gen-XXX`)
|
|
69
|
+
|
|
70
|
+
Marking rules:
|
|
71
|
+
- `/reap.start`: backlog items chosen as the generation's goal → mark `consumed`
|
|
72
|
+
- `/reap.completion`: applied `genome-change` / `environment-change` items → mark `consumed`
|
|
73
|
+
|
|
74
|
+
Archiving rules (`/reap.next` from completion):
|
|
75
|
+
- `consumed` items → moved to lineage
|
|
76
|
+
- `pending` items → copied to lineage + carried forward to the new generation's backlog
|
|
77
|
+
|
|
78
|
+
### Task Deferral
|
|
79
|
+
Tasks that depend on Genome changes cannot be completed in the current generation. Mark as `[deferred]` and add to backlog as `type: task`. Partial completion is normal.
|
|
80
|
+
|
|
81
|
+
### Micro Loop (Regression to a Previous Stage)
|
|
82
|
+
Any stage can regress to a previous stage. Use `/reap.back` to go back one stage, or `/reap.back [stage]` to regress to a specific stage.
|
|
83
|
+
|
|
84
|
+
Artifact handling rules:
|
|
85
|
+
- **Before target stage**: Preserved
|
|
86
|
+
- **Target stage**: Overwritten (implementation only appends)
|
|
87
|
+
- **After target stage**: Preserved, overwritten upon re-entry
|
|
88
|
+
|
|
89
|
+
Regression reason is recorded as a `## Regression` section in the target stage's artifact.
|
|
90
|
+
|
|
91
|
+
### Minor Fix
|
|
92
|
+
Trivial issues (typos, lint errors, etc.) are fixed directly in the current stage without a stage transition and recorded in the artifact. Judgment criterion: resolvable within 5 minutes without design changes.
|
|
93
|
+
|
|
94
|
+
### Lineage Compression
|
|
95
|
+
As generations accumulate, lineage grows. Auto-compression triggers when total exceeds 10,000 lines + 5 or more generations:
|
|
96
|
+
- **Level 1**: Generation folder → single .md (40 lines). Only goal + result + notable items preserved.
|
|
97
|
+
- **Level 2**: 5 Level 1 entries → epoch .md (60 lines). Only key flow preserved.
|
|
98
|
+
|
|
99
|
+
Compression runs automatically during `/reap.next` (archiving after completion).
|
|
100
|
+
|
|
101
|
+
## REAP Hooks
|
|
102
|
+
|
|
103
|
+
Projects can define hooks in `.reap/config.yml` to run commands or prompts at lifecycle events:
|
|
104
|
+
|
|
105
|
+
```yaml
|
|
106
|
+
hooks:
|
|
107
|
+
onGenerationStart:
|
|
108
|
+
- command: "echo 'Generation started'"
|
|
109
|
+
onStageTransition:
|
|
110
|
+
- command: "echo 'Stage changed'"
|
|
111
|
+
onGenerationComplete:
|
|
112
|
+
- command: "reap update"
|
|
113
|
+
- prompt: "Check if README needs updating based on this generation's changes."
|
|
114
|
+
onRegression:
|
|
115
|
+
- command: "echo 'Regressed'"
|
|
116
|
+
```
|
|
117
|
+
|
|
118
|
+
Each hook entry supports two types:
|
|
119
|
+
- `command` — Run a shell command in the project root directory
|
|
120
|
+
- `prompt` — AI agent instruction. The agent reads and executes the described task.
|
|
121
|
+
|
|
122
|
+
Only one of `command` or `prompt` should be set per entry.
|
|
123
|
+
|
|
124
|
+
| Event | Trigger |
|
|
125
|
+
|-------|---------|
|
|
126
|
+
| `onGenerationStart` | After `/reap.start` creates a new generation |
|
|
127
|
+
| `onStageTransition` | After `/reap.next` advances to the next stage |
|
|
128
|
+
| `onGenerationComplete` | After `/reap.next` archives a completed generation (after commit) |
|
|
129
|
+
| `onRegression` | After `/reap.back` returns to a previous stage |
|
|
130
|
+
|
|
131
|
+
Hooks are executed by the AI agent.
|
|
132
|
+
|
|
133
|
+
## Role Separation
|
|
134
|
+
|
|
135
|
+
| Component | Role |
|
|
136
|
+
|-----------|------|
|
|
137
|
+
| **CLI (`reap`)** | Project setup and maintenance. Init, status, update, fix |
|
|
138
|
+
| **AI Agent** | Workflow executor. Performs each stage's work via slash commands |
|
|
139
|
+
| **Human** | Decision maker. Sets goals, finalizes specs, reviews code, approves stage transitions |
|
|
140
|
+
|
|
141
|
+
## Execution Flow
|
|
142
|
+
|
|
143
|
+
```
|
|
144
|
+
1. /reap.start → Start a new Generation
|
|
145
|
+
2. /reap.objective → Define goal + requirements
|
|
146
|
+
3. /reap.next
|
|
147
|
+
4. /reap.planning → Task decomposition + implementation plan
|
|
148
|
+
5. /reap.next
|
|
149
|
+
6. /reap.implementation → Code implementation
|
|
150
|
+
7. /reap.next
|
|
151
|
+
8. /reap.validation → Verification
|
|
152
|
+
9. /reap.next
|
|
153
|
+
10. /reap.completion → Retrospective + genome updates
|
|
154
|
+
11. /reap.next → Archiving, generation ends
|
|
155
|
+
```
|
|
156
|
+
|
|
157
|
+
Each slash command follows a 3-step structure: Gate (precondition check) → Steps (work execution) → Artifact generation.
|
|
158
|
+
|
|
159
|
+
## Language
|
|
160
|
+
|
|
161
|
+
All REAP artifacts and user interactions MUST follow the user's configured language setting (from `~/.claude/settings.json` `language` field or the system prompt's language instruction).
|
|
162
|
+
|
|
163
|
+
- **Artifacts** (01-objective.md through 05-completion.md): Write in the user's language. Template section headings (Goal, Completion Criteria, etc.) may remain in English, but all content/descriptions must be in the user's language.
|
|
164
|
+
- **User interactions**: Communicate with the user in their configured language — questions, status updates, confirmations, error messages.
|
|
165
|
+
- **Backlog items**: Write in the user's language.
|
|
166
|
+
- **Genome files**: Write in the user's configured language. When modifying genome during Completion, use the user's language.
|
|
167
|
+
- **If no language is configured**: Default to English.
|
|
168
|
+
|
|
169
|
+
## Strict Mode
|
|
170
|
+
|
|
171
|
+
When `strict: true` is set in `.reap/config.yml`, the AI agent enforces code modification restrictions:
|
|
172
|
+
|
|
173
|
+
| Condition | Code Modification | Allowed Actions |
|
|
174
|
+
|-----------|------------------|-----------------|
|
|
175
|
+
| No active Generation | **BLOCKED** | Read, analyze, answer questions |
|
|
176
|
+
| Active Generation, not implementation stage | **BLOCKED** | Read, analyze, answer questions, write REAP artifacts |
|
|
177
|
+
| Active Generation, implementation stage | **SCOPED** — only files/modules listed in 02-planning.md | Full development within plan scope |
|
|
178
|
+
|
|
179
|
+
- **Escape hatch**: If the user explicitly requests to bypass strict mode (e.g., "override", "bypass strict", "just do it"), the agent may proceed but must inform the user that strict mode is being bypassed.
|
|
180
|
+
- **Default**: `strict: false` (no restrictions beyond normal REAP workflow guidance).
|
|
181
|
+
|
|
182
|
+
## Critical Rules
|
|
183
|
+
|
|
184
|
+
1. **NEVER modify `current.yml` directly.** Stage transitions MUST go through `/reap.next` (forward) or `/reap.back` (regression). Direct modification bypasses artifact creation and breaks the lifecycle.
|
|
185
|
+
2. **NEVER skip a stage.** Each stage command must be executed and its artifact must exist before advancing. `/reap.next` enforces this by creating the next artifact from template.
|
|
186
|
+
3. **ALL development work MUST follow the REAP lifecycle.** Do NOT bypass it unless the human explicitly asks.
|
|
187
|
+
4. **Genome is the authoritative source of truth.** When making any decision about architecture, conventions, constraints, or domain rules, ALWAYS consult the Genome first. If you observe code that contradicts the Genome, flag it as a potential `genome-change` backlog item. Do NOT silently ignore discrepancies.
|
|
188
|
+
5. **Keep Genome fresh.** If you notice the Genome is missing information about current code patterns, or contains outdated information, inform the human and suggest `/reap.sync`. The human may choose to defer sync — respect that choice, but always flag the staleness.
|
|
@@ -0,0 +1,163 @@
|
|
|
1
|
+
#!/usr/bin/env bash
|
|
2
|
+
# REAP SessionStart hook — injects REAP guide + Genome + current generation context into every Claude session
|
|
3
|
+
# This script runs from the package directory but uses cwd to find the project's .reap/
|
|
4
|
+
set -euo pipefail
|
|
5
|
+
|
|
6
|
+
# Script directory (package-internal) for guide file
|
|
7
|
+
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]:-$0}")" && pwd)"
|
|
8
|
+
|
|
9
|
+
# Project directory is cwd (where Claude Code session started)
|
|
10
|
+
PROJECT_ROOT="$(pwd)"
|
|
11
|
+
REAP_DIR="${PROJECT_ROOT}/.reap"
|
|
12
|
+
CURRENT_YML="${REAP_DIR}/life/current.yml"
|
|
13
|
+
GUIDE_FILE="${SCRIPT_DIR}/reap-guide.md"
|
|
14
|
+
GENOME_DIR="${REAP_DIR}/genome"
|
|
15
|
+
|
|
16
|
+
# Check if this is a REAP project
|
|
17
|
+
if [ ! -d "$REAP_DIR" ]; then
|
|
18
|
+
exit 0
|
|
19
|
+
fi
|
|
20
|
+
|
|
21
|
+
# Read REAP guide
|
|
22
|
+
reap_guide=""
|
|
23
|
+
if [ -f "$GUIDE_FILE" ]; then
|
|
24
|
+
reap_guide=$(cat "$GUIDE_FILE")
|
|
25
|
+
fi
|
|
26
|
+
|
|
27
|
+
# Read Genome files with tiered loading
|
|
28
|
+
# L1 (~500 lines max): principles.md, conventions.md, constraints.md — always full load
|
|
29
|
+
# L2 (~200 lines max): domain/*.md — full load if within budget, otherwise title+summary only
|
|
30
|
+
L1_LIMIT=500
|
|
31
|
+
L2_LIMIT=200
|
|
32
|
+
|
|
33
|
+
genome_content=""
|
|
34
|
+
l1_lines=0
|
|
35
|
+
if [ -d "$GENOME_DIR" ]; then
|
|
36
|
+
for f in "$GENOME_DIR"/principles.md "$GENOME_DIR"/conventions.md "$GENOME_DIR"/constraints.md; do
|
|
37
|
+
if [ -f "$f" ]; then
|
|
38
|
+
file_content=$(cat "$f")
|
|
39
|
+
file_lines=$(echo "$file_content" | wc -l | tr -d ' ')
|
|
40
|
+
l1_lines=$((l1_lines + file_lines))
|
|
41
|
+
if [ "$l1_lines" -le "$L1_LIMIT" ]; then
|
|
42
|
+
genome_content="${genome_content}\n### $(basename "$f")\n${file_content}\n"
|
|
43
|
+
else
|
|
44
|
+
# L1 budget exceeded — include truncated with warning
|
|
45
|
+
genome_content="${genome_content}\n### $(basename "$f") [TRUNCATED — L1 budget exceeded, read full file directly]\n$(echo "$file_content" | head -20)\n...\n"
|
|
46
|
+
fi
|
|
47
|
+
fi
|
|
48
|
+
done
|
|
49
|
+
|
|
50
|
+
# L2: domain/ files
|
|
51
|
+
if [ -d "$GENOME_DIR/domain" ]; then
|
|
52
|
+
l2_lines=0
|
|
53
|
+
l2_overflow=false
|
|
54
|
+
for f in "$GENOME_DIR"/domain/*.md; do
|
|
55
|
+
if [ -f "$f" ]; then
|
|
56
|
+
file_content=$(cat "$f")
|
|
57
|
+
file_lines=$(echo "$file_content" | wc -l | tr -d ' ')
|
|
58
|
+
l2_lines=$((l2_lines + file_lines))
|
|
59
|
+
if [ "$l2_overflow" = false ] && [ "$l2_lines" -le "$L2_LIMIT" ]; then
|
|
60
|
+
genome_content="${genome_content}\n### domain/$(basename "$f")\n${file_content}\n"
|
|
61
|
+
else
|
|
62
|
+
# L2 budget exceeded — title + first line only
|
|
63
|
+
l2_overflow=true
|
|
64
|
+
first_line=$(echo "$file_content" | grep -m1 "^>" || echo "$file_content" | head -1)
|
|
65
|
+
genome_content="${genome_content}\n### domain/$(basename "$f") [summary — read full file for details]\n${first_line}\n"
|
|
66
|
+
fi
|
|
67
|
+
fi
|
|
68
|
+
done
|
|
69
|
+
fi
|
|
70
|
+
fi
|
|
71
|
+
|
|
72
|
+
# Detect Genome staleness — count commits since last Genome modification
|
|
73
|
+
genome_stale_warning=""
|
|
74
|
+
if command -v git &>/dev/null && [ -d "$PROJECT_ROOT/.git" ]; then
|
|
75
|
+
last_genome_commit=$(git -C "$PROJECT_ROOT" log -1 --format="%H" -- ".reap/genome/" 2>/dev/null || echo "")
|
|
76
|
+
if [ -n "$last_genome_commit" ]; then
|
|
77
|
+
commits_since=$(git -C "$PROJECT_ROOT" rev-list --count "${last_genome_commit}..HEAD" 2>/dev/null || echo "0")
|
|
78
|
+
if [ "$commits_since" -gt 10 ]; then
|
|
79
|
+
genome_stale_warning="WARNING: Genome may be stale — ${commits_since} commits since last Genome update. Consider running /reap.sync to synchronize."
|
|
80
|
+
fi
|
|
81
|
+
fi
|
|
82
|
+
fi
|
|
83
|
+
|
|
84
|
+
# Read strict mode from config.yml
|
|
85
|
+
strict_mode=false
|
|
86
|
+
CONFIG_FILE="${REAP_DIR}/config.yml"
|
|
87
|
+
if [ -f "$CONFIG_FILE" ]; then
|
|
88
|
+
strict_val=$(grep "^strict:" "$CONFIG_FILE" 2>/dev/null | sed 's/^strict: *//' | tr -d ' ' || true)
|
|
89
|
+
if [ "$strict_val" = "true" ]; then
|
|
90
|
+
strict_mode=true
|
|
91
|
+
fi
|
|
92
|
+
fi
|
|
93
|
+
|
|
94
|
+
# Read current.yml
|
|
95
|
+
gen_stage="none"
|
|
96
|
+
if [ ! -f "$CURRENT_YML" ]; then
|
|
97
|
+
generation_context="No active Generation. Run \`/reap.start\` to start one."
|
|
98
|
+
else
|
|
99
|
+
content=$(cat "$CURRENT_YML")
|
|
100
|
+
if [ -z "$content" ]; then
|
|
101
|
+
generation_context="No active Generation. Run \`/reap.start\` to start one."
|
|
102
|
+
else
|
|
103
|
+
# Parse YAML fields (simple grep-based, no external deps)
|
|
104
|
+
gen_id=$(echo "$content" | grep "^id:" | sed 's/^id: *//')
|
|
105
|
+
gen_goal=$(echo "$content" | grep "^goal:" | sed 's/^goal: *//')
|
|
106
|
+
gen_stage=$(echo "$content" | grep "^stage:" | sed 's/^stage: *//')
|
|
107
|
+
generation_context="Active Generation: ${gen_id} | Goal: ${gen_goal} | Stage: ${gen_stage}"
|
|
108
|
+
fi
|
|
109
|
+
fi
|
|
110
|
+
|
|
111
|
+
# Map stage to command
|
|
112
|
+
case "${gen_stage}" in
|
|
113
|
+
objective) next_cmd="/reap.objective" ;;
|
|
114
|
+
planning) next_cmd="/reap.planning" ;;
|
|
115
|
+
implementation) next_cmd="/reap.implementation" ;;
|
|
116
|
+
validation) next_cmd="/reap.validation" ;;
|
|
117
|
+
completion) next_cmd="/reap.completion" ;;
|
|
118
|
+
*) next_cmd="/reap.start" ;;
|
|
119
|
+
esac
|
|
120
|
+
|
|
121
|
+
# Escape for JSON
|
|
122
|
+
escape_for_json() {
|
|
123
|
+
local s="$1"
|
|
124
|
+
s="${s//\\/\\\\}"
|
|
125
|
+
s="${s//\"/\\\"}"
|
|
126
|
+
s="${s//$'\n'/\\n}"
|
|
127
|
+
s="${s//$'\r'/\\r}"
|
|
128
|
+
s="${s//$'\t'/\\t}"
|
|
129
|
+
printf '%s' "$s"
|
|
130
|
+
}
|
|
131
|
+
|
|
132
|
+
# Build strict mode section
|
|
133
|
+
strict_section=""
|
|
134
|
+
if [ "$strict_mode" = true ]; then
|
|
135
|
+
if [ "$gen_stage" = "implementation" ]; then
|
|
136
|
+
strict_section="\n\n## Strict Mode (ACTIVE — SCOPED MODIFICATION ALLOWED)\n<HARD-GATE>\nStrict mode is enabled. Code modification is ALLOWED only within the scope of the current Generation's plan.\n- You MUST read \`.reap/life/02-planning.md\` before writing any code.\n- You may ONLY modify files and modules listed in the plan's task list.\n- Changes outside the plan's scope are BLOCKED. If you discover out-of-scope work is needed, add it to the backlog instead of implementing it.\n- If the user explicitly requests to bypass strict mode (e.g., \"override\", \"bypass strict\"), you may proceed — but inform them that strict mode is being bypassed.\n</HARD-GATE>"
|
|
137
|
+
elif [ "$gen_stage" = "none" ]; then
|
|
138
|
+
strict_section="\n\n## Strict Mode (ACTIVE — CODE MODIFICATION BLOCKED)\n<HARD-GATE>\nStrict mode is enabled and there is NO active Generation.\nYou MUST NOT write, edit, or create any source code files.\nAllowed actions: reading files, analyzing code, answering questions, running commands.\nTo start coding, the user must first run \`/reap.start\` and advance to the implementation stage.\nIf the user explicitly requests to bypass strict mode (e.g., \"override\", \"bypass strict\", \"just do it\"), you may proceed — but inform them that strict mode is being bypassed.\n</HARD-GATE>"
|
|
139
|
+
else
|
|
140
|
+
strict_section="\n\n## Strict Mode (ACTIVE — CODE MODIFICATION BLOCKED)\n<HARD-GATE>\nStrict mode is enabled. Current stage is '${gen_stage}', which is NOT the implementation stage.\nYou MUST NOT write, edit, or create any source code files.\nAllowed actions: reading files, analyzing code, answering questions, running commands, writing REAP artifacts.\nAdvance to the implementation stage via the REAP lifecycle to unlock code modification.\nIf the user explicitly requests to bypass strict mode (e.g., \"override\", \"bypass strict\", \"just do it\"), you may proceed — but inform them that strict mode is being bypassed.\n</HARD-GATE>"
|
|
141
|
+
fi
|
|
142
|
+
fi
|
|
143
|
+
|
|
144
|
+
# Build staleness section
|
|
145
|
+
stale_section=""
|
|
146
|
+
if [ -n "$genome_stale_warning" ]; then
|
|
147
|
+
stale_section="\n\n## Genome Staleness\n${genome_stale_warning}\nIf the user wants to proceed without syncing, ask: \"The Genome may be stale. Would you like to run /reap.sync now, or do it later?\" and respect their choice."
|
|
148
|
+
fi
|
|
149
|
+
|
|
150
|
+
reap_context="<REAP_WORKFLOW>\n${reap_guide}\n\n---\n\n## Genome (Project Knowledge — treat as authoritative source of truth)\n${genome_content}\n\n---\n\n## Current State\n${generation_context}${stale_section}${strict_section}\n\n## Rules\n1. ALL development work MUST follow the REAP lifecycle. Do NOT bypass it.\n2. Before writing any code, check if a Generation is active and what stage it is in.\n3. If a Generation is active, use \`${next_cmd}\` to proceed with the current stage.\n4. If no Generation is active, use \`/reap.start\` to start a new one.\n5. Do NOT implement features, fix bugs, or make changes outside of the REAP lifecycle unless the user explicitly asks to bypass it.\n6. When the user says \"reap evolve\", \"next stage\", \"proceed\", or similar — invoke the appropriate REAP skill.\n7. **Genome is the authoritative knowledge source.** When making decisions about architecture, conventions, or constraints, ALWAYS reference the Genome first. If code contradicts Genome, flag it as a potential genome-change backlog item.\n8. If you notice the Genome is outdated or missing information relevant to your current task, inform the user and suggest running \`/reap.sync\`.\n</REAP_WORKFLOW>"
|
|
151
|
+
|
|
152
|
+
escaped_context=$(escape_for_json "$reap_context")
|
|
153
|
+
|
|
154
|
+
cat <<EOF
|
|
155
|
+
{
|
|
156
|
+
"hookSpecificOutput": {
|
|
157
|
+
"hookEventName": "SessionStart",
|
|
158
|
+
"additionalContext": "${escaped_context}"
|
|
159
|
+
}
|
|
160
|
+
}
|
|
161
|
+
EOF
|
|
162
|
+
|
|
163
|
+
exit 0
|
|
@@ -0,0 +1,28 @@
|
|
|
1
|
+
# Technical Constraints
|
|
2
|
+
|
|
3
|
+
> Modified only during the Birth stage.
|
|
4
|
+
|
|
5
|
+
## Tech Stack
|
|
6
|
+
|
|
7
|
+
- **Language**: TypeScript 5.x
|
|
8
|
+
- **Runtime**: Bun 1.x
|
|
9
|
+
- **Backend**: Hono — Web Standard API, middleware
|
|
10
|
+
- **Frontend**: React 19 — Component UI
|
|
11
|
+
- **Package Manager**: bun
|
|
12
|
+
|
|
13
|
+
## Constraints
|
|
14
|
+
|
|
15
|
+
- Use `shared/` directory when sharing types between server and client
|
|
16
|
+
- API responses must always be JSON
|
|
17
|
+
- Environment variables are managed via `.env`; no hardcoding in source code
|
|
18
|
+
|
|
19
|
+
## Validation Commands
|
|
20
|
+
|
|
21
|
+
| Purpose | Command | Description |
|
|
22
|
+
|---------|---------|-------------|
|
|
23
|
+
| Test | `bun test` | Run all tests |
|
|
24
|
+
| Type check | `bunx tsc --noEmit` | TypeScript compilation verification |
|
|
25
|
+
|
|
26
|
+
## External Dependencies
|
|
27
|
+
|
|
28
|
+
- (Add as needed for the project)
|
|
@@ -0,0 +1,28 @@
|
|
|
1
|
+
# Development Conventions
|
|
2
|
+
|
|
3
|
+
> Modified only during the Birth stage.
|
|
4
|
+
|
|
5
|
+
## Code Style
|
|
6
|
+
|
|
7
|
+
- TypeScript strict mode
|
|
8
|
+
- Functions should have a single responsibility, recommended 50 lines or fewer
|
|
9
|
+
- Use `async/await`
|
|
10
|
+
|
|
11
|
+
## Naming Conventions
|
|
12
|
+
|
|
13
|
+
- File names: `kebab-case.ts` / `kebab-case.tsx`
|
|
14
|
+
- Components: `PascalCase`
|
|
15
|
+
- Functions/variables: `camelCase`
|
|
16
|
+
- API routes: `/api/v1/resource-name`
|
|
17
|
+
|
|
18
|
+
## Git Conventions
|
|
19
|
+
|
|
20
|
+
- Commit messages: `type: description` (feat, fix, test, chore, docs)
|
|
21
|
+
- One commit = one logical change
|
|
22
|
+
|
|
23
|
+
## Enforced Rules
|
|
24
|
+
|
|
25
|
+
| Rule | Validation Tool | Command |
|
|
26
|
+
|------|-----------------|---------|
|
|
27
|
+
| All tests pass | bun test | `bun test` |
|
|
28
|
+
| TypeScript compilation | tsc | `bunx tsc --noEmit` |
|
|
@@ -0,0 +1,28 @@
|
|
|
1
|
+
# Architecture Principles
|
|
2
|
+
|
|
3
|
+
> Modified only during the Birth stage.
|
|
4
|
+
|
|
5
|
+
## Core Beliefs
|
|
6
|
+
|
|
7
|
+
- **API-First** — Design REST/RPC APIs with Hono first; React is a client that consumes the APIs
|
|
8
|
+
- **Type-Safe Full Stack** — Server and client share the same TypeScript types
|
|
9
|
+
- **Edge-Ready** — Fast startup with Bun runtime, portability through Hono's Web Standard API
|
|
10
|
+
- **Colocation** — Keep related code close together (route + handler + schema)
|
|
11
|
+
|
|
12
|
+
## Architecture Decisions
|
|
13
|
+
|
|
14
|
+
| ID | Decision | Rationale | Date |
|
|
15
|
+
|----|----------|-----------|------|
|
|
16
|
+
| ADR-001 | Bun + TypeScript | Fast execution, built-in testing, native TS support | - |
|
|
17
|
+
| ADR-002 | Hono (Web Framework) | Lightweight, Web Standard, middleware system | - |
|
|
18
|
+
| ADR-003 | React (Frontend) | Ecosystem, component model | - |
|
|
19
|
+
|
|
20
|
+
## Layer Map
|
|
21
|
+
|
|
22
|
+
```
|
|
23
|
+
src/
|
|
24
|
+
├── server/ → Hono API routes + middleware
|
|
25
|
+
├── client/ → React components + pages
|
|
26
|
+
├── shared/ → Shared types and utilities for server/client
|
|
27
|
+
└── db/ → Data access layer
|
|
28
|
+
```
|