@arvorco/relentless 0.1.20 → 0.1.22

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.
@@ -0,0 +1,393 @@
1
+ # Relentless Project Constitution
2
+
3
+ **Version:** 2.0.0
4
+ **Ratified:** 2026-01-13
5
+ **Last Amended:** 2026-01-13
6
+
7
+ ---
8
+
9
+ ## Preamble
10
+
11
+ Relentless is a universal AI agent orchestrator that empowers developers to run any AI coding agent autonomously until all tasks are complete. This constitution establishes the governing principles, patterns, and constraints that guide development and ensure Relentless remains performant, reliable, and cost-effective.
12
+
13
+ Our mission is to build one of the best AI orchestration tools in the world - simple, genius, and efficient.
14
+
15
+ ---
16
+
17
+ ## Core Identity
18
+
19
+ **Project:** Relentless
20
+ **Organization:** Arvor
21
+ **Purpose:** Universal AI Agent Orchestrator
22
+ **Languages:** TypeScript (strict mode)
23
+ **Runtime:** Bun (not Node.js)
24
+ **License:** MIT
25
+
26
+ ---
27
+
28
+ ## Part I: Foundational Principles
29
+
30
+ ### Principle 1: Test-Driven Development (TDD)
31
+
32
+ **MUST:**
33
+ - All new features MUST have tests written BEFORE implementation begins
34
+ - Tests MUST define expected behavior with clear assertions
35
+ - Implementation MUST NOT proceed until failing tests exist
36
+ - All tests MUST pass before any story is marked complete
37
+ - E2E tests MUST exist for critical user workflows
38
+
39
+ **SHOULD:**
40
+ - Aim for >80% code coverage on new features
41
+ - Write tests that serve as living documentation
42
+ - Use property-based testing for complex logic
43
+ - Include edge case tests for all boundary conditions
44
+
45
+ **Rationale:** TDD prevents regressions in long autonomous runs where agents may introduce subtle bugs. Tests serve as contracts that agents must satisfy, providing fast feedback loops essential for AI-driven development. Reference: [Test-Driven Development with AI](https://www.builder.io/blog/test-driven-development-ai)
46
+
47
+ ---
48
+
49
+ ### Principle 2: Smart Model Routing
50
+
51
+ **MUST:**
52
+ - Planning phase MUST evaluate task complexity before assigning models
53
+ - Each specification MUST ask user whether smart routing is desired
54
+ - Routing decisions MUST be made at planning time, not runtime
55
+ - Model/harness performance history MUST be tracked for future planning
56
+ - Simple tasks MUST be routable to cheaper/free models when user opts in
57
+ - Complex tasks and final reviews MUST use SOTA models (Opus 4.5, GPT-5-2, etc.)
58
+
59
+ **SHOULD:**
60
+ - Maintain a knowledge base of model/harness capabilities and strengths
61
+ - Update routing heuristics based on observed task outcomes
62
+ - Consider task dependencies when routing parallel work
63
+ - Balance cost optimization with quality requirements
64
+
65
+ **Rationale:** Different models excel at different tasks. Strategic routing saves costs (up to 75% reduction) while maintaining quality. SOTA models handle complex reasoning; lighter models handle boilerplate. Reference: [MasRouter](https://aclanthology.org/2025.acl-long.757.pdf), [Dynamic LLM Routing](https://arxiv.org/abs/2502.16696)
66
+
67
+ ---
68
+
69
+ ### Principle 3: Parallel Execution with Git Worktrees
70
+
71
+ **MUST:**
72
+ - Parallel tasks MUST use git worktrees for clean isolation
73
+ - Each worktree MUST be on an independent branch
74
+ - Merge strategy MUST be defined before parallel execution begins
75
+ - Post-merge testing MUST validate combined implementations
76
+ - Worktrees MUST be cleaned up after successful merge
77
+ - Circular dependencies MUST be detected and prevented before parallelization
78
+
79
+ **SHOULD:**
80
+ - Limit parallel worktrees to prevent resource exhaustion
81
+ - Prefer parallel execution for independent tasks only
82
+ - Run integration tests after merging worktrees
83
+ - Log all worktree operations for debugging
84
+
85
+ **Rationale:** Git worktrees enable up to 50 agents working in parallel with clean isolation and easy merging. Cleanup prevents workspace pollution. Reference: [Parallelizing AI Coding Agents](https://ainativedev.io/news/how-to-parallelize-ai-coding-agents)
86
+
87
+ ---
88
+
89
+ ### Principle 4: Queued Prompts (Mid-Run Input)
90
+
91
+ **MUST:**
92
+ - Implement file-based queue (.queue.txt) for mid-run user input
93
+ - Agents MUST check queue between iterations
94
+ - Queued prompts MUST persist in memory for subsequent iterations
95
+ - Queue MUST be processed in FIFO order
96
+ - Acknowledge queued prompts in progress.txt
97
+
98
+ **SHOULD:**
99
+ - Support priority flags in queued messages
100
+ - Allow queue inspection without modifying it
101
+ - Clear processed items from queue after acknowledgment
102
+ - Support structured commands (pause, skip, abort) in queue
103
+
104
+ **Rationale:** Long autonomous runs need human intervention capability without interrupting the flow. File-based queues are simple, debuggable, and work across all agents. Reference: [Human-in-the-Loop Best Practices](https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/ai-agent-design-patterns)
105
+
106
+ ---
107
+
108
+ ### Principle 5: Adaptive Final Review
109
+
110
+ **MUST:**
111
+ - Every feature MUST have a final review phase before completion
112
+ - Review MUST be performed by SOTA model (Opus 4.5, GPT-5-2, or equivalent)
113
+ - Review scope MUST adapt to feature size:
114
+ - Small features: Full codebase review in single context
115
+ - Large features: Multi-context review with summary aggregation
116
+ - Review MUST check for: bugs, code quality, unnecessary artifacts, duplicate code, slop removal
117
+ - Review findings MUST be documented and acted upon
118
+
119
+ **SHOULD:**
120
+ - Use automated pre-checks before SOTA review to optimize costs
121
+ - Flag high-risk areas for deeper analysis
122
+ - Generate review report with actionable items
123
+ - Track review quality metrics over time
124
+
125
+ **Rationale:** AI agents can produce "slop" - unnecessary code, duplications, or artifacts. A final expert review catches issues that accumulated over many iterations. Adaptive scoping ensures thoroughness without waste.
126
+
127
+ ---
128
+
129
+ ### Principle 6: Agent-Aware Best Practices
130
+
131
+ **MUST:**
132
+ - Maintain up-to-date knowledge of each agent's capabilities
133
+ - Document agent-specific best practices and limitations
134
+ - Respect agent rate limits with intelligent fallback
135
+ - Use agent-appropriate prompting styles
136
+ - Track agent performance for routing optimization
137
+
138
+ **SHOULD:**
139
+ - Auto-detect agent availability and health
140
+ - Implement graceful degradation between agent tiers
141
+ - Share learned patterns across agent runs via progress.txt
142
+ - Monitor harness/model ecosystem for new capabilities
143
+
144
+ **Rationale:** Each agent (Claude, Amp, OpenCode, Codex, Droid, Gemini) has unique strengths. Leveraging these differences maximizes effectiveness and minimizes costs. Reference: [AI Agent Orchestration Frameworks](https://blog.n8n.io/ai-agent-orchestration-frameworks/)
145
+
146
+ ---
147
+
148
+ ## Part II: Code Quality Standards
149
+
150
+ ### Principle 7: Zero-Lint Policy
151
+
152
+ **MUST:**
153
+ - All code MUST pass lint with zero warnings (not just errors)
154
+ - All code MUST pass typecheck with zero errors
155
+ - No subterfuges or workarounds to suppress legitimate lint issues
156
+ - Fix lints properly as an expert developer (IQ 300 approach)
157
+ - Run lint and typecheck before every commit
158
+
159
+ **SHOULD:**
160
+ - Configure strictest reasonable lint rules
161
+ - Use automated formatting (Prettier, etc.)
162
+ - Address lint issues immediately, not as technical debt
163
+
164
+ **Rationale:** Clean code performs better and maintains clarity. Lint warnings often signal real issues that compound over time.
165
+
166
+ ---
167
+
168
+ ### Principle 8: TypeScript Strictness
169
+
170
+ **MUST:**
171
+ - Use TypeScript strict mode throughout
172
+ - Avoid `any` type - use `unknown` or proper types
173
+ - Export types alongside implementations
174
+ - Use Zod schemas for runtime validation
175
+ - Document complex type constraints
176
+
177
+ **SHOULD:**
178
+ - Prefer type inference where clear
179
+ - Use interfaces for public APIs
180
+ - Use types for unions/intersections
181
+ - Add explicit return types on exported functions
182
+
183
+ **Rationale:** Type safety prevents runtime errors and enables better tooling. Strict mode catches issues at compile time rather than production.
184
+
185
+ ---
186
+
187
+ ### Principle 9: Minimal Dependencies
188
+
189
+ **MUST NOT:**
190
+ - Add dependencies without clear justification
191
+ - Include deprecated packages
192
+ - Use packages with known security vulnerabilities
193
+
194
+ **MUST:**
195
+ - Prefer built-in solutions over external dependencies
196
+ - Audit dependencies regularly
197
+ - Pin versions for reproducibility
198
+
199
+ **SHOULD:**
200
+ - Consider bundle size impact
201
+ - Evaluate maintenance status of dependencies
202
+ - Prefer well-maintained, popular packages
203
+
204
+ **Rationale:** Every dependency is a potential security risk, maintenance burden, and performance cost. Minimalism keeps the codebase lean and secure.
205
+
206
+ ---
207
+
208
+ ## Part III: Architecture Principles
209
+
210
+ ### Principle 10: Clean Architecture
211
+
212
+ **MUST:**
213
+ - Maintain clear separation of concerns
214
+ - Keep modules focused and single-purpose
215
+ - Use dependency injection for testability
216
+ - Follow existing code structure patterns
217
+
218
+ **SHOULD:**
219
+ - Prefer composition over inheritance
220
+ - Keep functions small and focused (<30 lines)
221
+ - Write self-documenting code
222
+ - Use meaningful names that reveal intent
223
+
224
+ **Rationale:** Clean architecture enables parallel development, easier testing, and maintainable codebases. AI agents work better with well-organized code.
225
+
226
+ ---
227
+
228
+ ### Principle 11: Performance First
229
+
230
+ **MUST:**
231
+ - Maintain fast startup time (<1s)
232
+ - Ensure responsive CLI commands
233
+ - Optimize file operations for large codebases
234
+ - Keep memory footprint minimal
235
+
236
+ **SHOULD:**
237
+ - Use lazy loading for heavy modules
238
+ - Cache repeated operations
239
+ - Profile performance regularly
240
+ - Parallelize where safe
241
+
242
+ **Rationale:** Performance directly impacts developer experience and agent efficiency. Slow tools waste time and money.
243
+
244
+ ---
245
+
246
+ ### Principle 12: Error Handling Excellence
247
+
248
+ **MUST:**
249
+ - Surface errors clearly - never hide failures
250
+ - Provide descriptive error messages with context
251
+ - Validate inputs at system boundaries
252
+ - Implement graceful degradation
253
+
254
+ **SHOULD:**
255
+ - Include recovery suggestions in errors
256
+ - Log errors with sufficient context for debugging
257
+ - Use circuit breaker patterns for external dependencies
258
+ - Consider error handling in design
259
+
260
+ **Rationale:** Autonomous agents need clear error signals to self-correct. Hidden errors cause cascading failures in long runs. Reference: [AI Agent Error Handling](https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/ai-agent-design-patterns)
261
+
262
+ ---
263
+
264
+ ## Part IV: Version Control & Documentation
265
+
266
+ ### Principle 13: Git Discipline
267
+
268
+ **MUST:**
269
+ - Write clear, descriptive commit messages
270
+ - Reference story IDs: `feat: [US-XXX] - Description`
271
+ - Keep commits focused and atomic
272
+ - Never commit broken code
273
+ - Never commit secrets
274
+
275
+ **SHOULD:**
276
+ - Maintain clean commit history
277
+ - Use meaningful branch names
278
+ - Squash WIP commits before merge
279
+ - Update docs with code changes
280
+
281
+ **Rationale:** Git history is memory for AI agents across iterations. Clean history enables better context and debugging.
282
+
283
+ ---
284
+
285
+ ### Principle 14: Documentation Standards
286
+
287
+ **MUST:**
288
+ - Document public APIs and interfaces
289
+ - Document complex algorithms
290
+ - Keep README up to date
291
+ - Document breaking changes
292
+
293
+ **SHOULD:**
294
+ - Write self-documenting code first
295
+ - Document "why" not just "what"
296
+ - Keep docs in sync with code
297
+ - Include troubleshooting guides
298
+
299
+ **Rationale:** Documentation helps both humans and AI agents understand the codebase. Good docs reduce errors and speed up development.
300
+
301
+ ---
302
+
303
+ ## Part V: Security & Compliance
304
+
305
+ ### Principle 15: Security First
306
+
307
+ **MUST:**
308
+ - Never commit secrets to git
309
+ - Validate all external inputs
310
+ - Use safe file system operations
311
+ - Follow principle of least privilege
312
+ - Log sensitive operations
313
+
314
+ **SHOULD:**
315
+ - Regular dependency audits
316
+ - Rate limiting where appropriate
317
+ - Security-focused code review
318
+ - Keep security patches current
319
+
320
+ **Rationale:** Security vulnerabilities in orchestration tools can have wide-reaching impact. Proactive security prevents costly incidents.
321
+
322
+ ---
323
+
324
+ ## Part VI: Future Roadmap Principles
325
+
326
+ The following are strategic directions that guide future development:
327
+
328
+ ### Cost & Metrics Dashboard
329
+ - Investigate harness-specific methods for cost/usage tracking
330
+ - Consider integration with existing tools like Claude Code's /status
331
+ - Build unified dashboard when implementation path is clear
332
+
333
+ ### Enhanced Model Routing Intelligence
334
+ - Build and maintain model capability knowledge base
335
+ - Track task outcomes for routing optimization
336
+ - Develop routing heuristics from empirical data
337
+
338
+ ### Extended Parallel Execution
339
+ - Support for containerized agent isolation (future option)
340
+ - Cross-worktree dependency management
341
+ - Distributed execution across machines
342
+
343
+ ### Integration Ecosystem
344
+ - GitHub Actions integration
345
+ - CI/CD pipeline templates
346
+ - IDE extensions for orchestration control
347
+
348
+ ---
349
+
350
+ ## Governance
351
+
352
+ ### Amendment Process
353
+
354
+ 1. **Propose:** Create PR with proposed changes
355
+ 2. **Discuss:** Gather feedback from team and community
356
+ 3. **Update:** Increment version semantically:
357
+ - **MAJOR:** Breaking changes to principles
358
+ - **MINOR:** New principles added
359
+ - **PATCH:** Clarifications, typo fixes
360
+ 4. **Document:** Record rationale for changes
361
+ 5. **Ratify:** Merge after approval
362
+
363
+ ### Compliance
364
+
365
+ - Constitution checked before each feature implementation
366
+ - Violations block story completion
367
+ - Agents must reference constitution in progress.txt
368
+ - Regular review at project milestones
369
+
370
+ ### Version History
371
+
372
+ | Version | Date | Changes |
373
+ |---------|------|---------|
374
+ | 2.0.0 | 2026-01-13 | Major revision: Added smart routing, parallel execution, queued prompts, adaptive review, TDD requirements, agent-aware practices |
375
+ | 1.0.0 | Previous | Initial constitution |
376
+
377
+ ---
378
+
379
+ ## References
380
+
381
+ - [AI Agent Orchestration Frameworks](https://blog.n8n.io/ai-agent-orchestration-frameworks/)
382
+ - [MasRouter: Learning to Route LLMs](https://aclanthology.org/2025.acl-long.757.pdf)
383
+ - [Dynamic LLM Routing](https://arxiv.org/abs/2502.16696)
384
+ - [Difficulty-Aware Agent Orchestration](https://arxiv.org/html/2509.11079v1)
385
+ - [Parallelizing AI Coding Agents](https://ainativedev.io/news/how-to-parallelize-ai-coding-agents)
386
+ - [Test-Driven Development with AI](https://www.builder.io/blog/test-driven-development-ai)
387
+ - [TDD, AI agents and coding with Kent Beck](https://newsletter.pragmaticengineer.com/p/tdd-ai-agents-and-coding-with-kent)
388
+ - [Azure AI Agent Design Patterns](https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/ai-agent-design-patterns)
389
+ - [LLM Cost Optimization Guide](https://futureagi.com/blogs/llm-cost-optimization-2025)
390
+
391
+ ---
392
+
393
+ *This constitution is the foundation for all Relentless development. Reference it during specification, planning, and implementation.*
@@ -1,22 +1,76 @@
1
1
  # Relentless Agent Instructions
2
2
 
3
- You are an autonomous coding agent working on a software project.
3
+ You are an autonomous coding agent working on the Relentless project - a universal AI agent orchestrator.
4
+
5
+ ---
6
+
7
+ ## CRITICAL: Quality Gates (Non-Negotiable)
8
+
9
+ Before marking ANY story as complete, ALL checks must pass:
10
+
11
+ ```bash
12
+ # TypeScript strict mode check
13
+ bun run typecheck
14
+
15
+ # ESLint with zero warnings policy
16
+ bun run lint
17
+
18
+ # All tests must pass
19
+ bun test
20
+ ```
21
+
22
+ **If ANY check fails, DO NOT mark the story as complete. Fix the issues first.**
23
+
24
+ ---
4
25
 
5
26
  ## Before You Start
6
27
 
7
- 1. **Review the codebase** - Understand the current state, architecture, and patterns
8
- 2. **Read progress.txt** - Check the Codebase Patterns section for learnings from previous iterations
9
- 3. **Read the PRD** - Understand what needs to be done
28
+ 1. **Read the Constitution** - Review `relentless/constitution.md` for project principles
29
+ 2. **Review the Codebase** - Understand current state, architecture, and patterns
30
+ 3. **Read progress.txt** - Check the Codebase Patterns section for learnings from previous iterations
31
+ 4. **Read the PRD** - Understand what needs to be done
32
+ 5. **Check the Queue** - Look for `.queue.txt` for any mid-run user input
33
+
34
+ ---
10
35
 
11
36
  ## Your Task
12
37
 
13
38
  1. Read the PRD at `relentless/features/<feature>/prd.json`
14
39
  2. Read the progress log at `relentless/features/<feature>/progress.txt`
15
40
  3. Check you're on the correct branch from PRD `branchName`. If not, check it out or create from main.
16
- 4. Pick the **highest priority** user story where `passes: false`
41
+ 4. Pick the **highest priority** user story where `passes: false` and all dependencies are met
17
42
  5. **Review relevant code** before implementing - understand existing patterns
18
43
 
19
- ### Research Phase (if story has `research: true`)
44
+ ---
45
+
46
+ ## TDD Workflow (MANDATORY)
47
+
48
+ Relentless follows strict Test-Driven Development. For EVERY story:
49
+
50
+ ### Step 1: Write Failing Tests First
51
+ ```bash
52
+ # Create test file if needed
53
+ # Write tests that define expected behavior
54
+ bun test # Tests MUST fail (red phase)
55
+ ```
56
+
57
+ ### Step 2: Implement Minimum Code
58
+ ```bash
59
+ # Write only enough code to pass tests
60
+ bun test # Tests MUST pass (green phase)
61
+ ```
62
+
63
+ ### Step 3: Refactor
64
+ ```bash
65
+ # Clean up while keeping tests green
66
+ bun test # Tests MUST still pass
67
+ ```
68
+
69
+ **Do NOT skip TDD. Tests are contracts that validate your implementation.**
70
+
71
+ ---
72
+
73
+ ## Research Phase (if story has `research: true`)
20
74
 
21
75
  If the current story has `research: true` and no research file exists yet:
22
76
 
@@ -30,50 +84,167 @@ If the current story has `research: true` and no research file exists yet:
30
84
  3. **Do NOT implement** - only research and document
31
85
  4. Save your findings to the research file and end your turn
32
86
 
33
- ### Implementation Phase
87
+ ---
88
+
89
+ ## Implementation Phase
34
90
 
35
91
  If research findings exist (or research is not required):
36
92
 
37
- 6. Implement that single user story (using research findings if available)
38
- 7. Run quality checks (typecheck, lint, test - whatever your project requires)
39
- 8. If checks pass, commit ALL changes with message: `feat: [Story ID] - [Story Title]`
40
- 9. Update the PRD to set `passes: true` for the completed story
41
- 10. Append your progress to `relentless/features/<feature>/progress.txt`
93
+ 1. **Write tests first** (TDD - mandatory)
94
+ 2. Implement that single user story (using research findings if available)
95
+ 3. Run quality checks (typecheck, lint, test)
96
+ 4. If checks pass, commit ALL changes with message: `feat: [Story ID] - [Story Title]`
97
+ 5. Update the PRD to set `passes: true` for the completed story
98
+ 6. Append your progress to `relentless/features/<feature>/progress.txt`
99
+
100
+ ---
101
+
102
+ ## Check for Queued Prompts
103
+
104
+ Between iterations, check `.queue.txt` for user input:
105
+
106
+ ```bash
107
+ # If .queue.txt exists, read and process it
108
+ # Acknowledge in progress.txt
109
+ # Process in FIFO order
110
+ ```
111
+
112
+ ---
42
113
 
43
114
  ## Progress Report Format
44
115
 
45
116
  APPEND to progress.txt (never replace, always append):
117
+
46
118
  ```
47
119
  ## [Date/Time] - [Story ID]
48
120
  - What was implemented
49
121
  - Files changed
122
+ - Tests added/modified
50
123
  - **Learnings for future iterations:**
51
124
  - Patterns discovered
52
125
  - Gotchas encountered
53
126
  - Useful context
127
+ - **Constitution compliance:** [list principles followed]
54
128
  ---
55
129
  ```
56
130
 
131
+ ---
132
+
57
133
  ## Quality Requirements
58
134
 
59
- - ALL commits must pass your project's quality checks (typecheck, lint, test)
60
- - Do NOT commit broken code
61
- - Keep changes focused and minimal
62
- - Follow existing code patterns
63
- - Review code before modifying it
135
+ ### Code Quality (Zero-Lint Policy)
136
+ - All commits MUST pass typecheck with 0 errors
137
+ - All commits MUST pass lint with 0 warnings (not just errors)
138
+ - No subterfuges to escape linting - fix issues properly
139
+ - All new features MUST include appropriate tests
140
+
141
+ ### Testing Requirements
142
+ - Unit tests for all business logic
143
+ - Integration tests for API endpoints
144
+ - E2E tests for critical user workflows
145
+ - Tests MUST be written BEFORE implementation (TDD)
146
+
147
+ ### TypeScript Strictness
148
+ - Use strict mode throughout
149
+ - Avoid `any` type - use `unknown` or proper types
150
+ - Use Zod for runtime validation
151
+
152
+ ---
153
+
154
+ ## Project-Specific Patterns
155
+
156
+ ### Directory Structure
157
+ ```
158
+ relentless/
159
+ ├── bin/ # CLI entry point (relentless.ts)
160
+ ├── src/ # Core TypeScript implementation
161
+ │ ├── agents/ # Agent adapters (claude, amp, opencode, codex, droid, gemini)
162
+ │ ├── config/ # Configuration schema and loading
163
+ │ ├── prd/ # PRD parsing and validation
164
+ │ ├── execution/ # Orchestration loop and routing
165
+ │ └── init/ # Project initialization scaffolder
166
+ ├── templates/ # Templates copied to projects on init
167
+ ├── .claude/ # Skills and commands
168
+ │ ├── skills/ # Skill implementations
169
+ │ └── commands/ # Command wrappers
170
+ └── relentless/ # Relentless workspace
171
+ ├── config.json
172
+ ├── constitution.md
173
+ ├── prompt.md
174
+ └── features/
175
+ ```
176
+
177
+ ### Key Technologies
178
+ - **Runtime:** Bun (NOT Node.js)
179
+ - **Language:** TypeScript (strict mode)
180
+ - **Validation:** Zod schemas
181
+ - **CLI:** Commander
182
+ - **Formatting:** Chalk
183
+ - **UI:** Ink (React for CLI)
184
+
185
+ ### Test File Patterns
186
+ - Unit tests: `*.test.ts` alongside source files
187
+ - Integration tests: `tests/integration/`
188
+ - E2E tests: `tests/e2e/`
189
+
190
+ ---
191
+
192
+ ## Agent-Specific Guidelines
193
+
194
+ ### Rate Limit Awareness
195
+ - If you hit rate limits, note in progress.txt for future planning
196
+ - Relentless will auto-fallback to other agents when limits hit
197
+
198
+ ### Model Routing Notes
199
+ - Simple tasks: Cheaper models acceptable
200
+ - Complex logic: Use capable models
201
+ - Final reviews: Always use SOTA models (Opus 4.5, GPT-5-2)
202
+
203
+ ### Parallel Execution
204
+ - Tasks marked `[P]` in tasks.md can run in parallel
205
+ - Use git worktrees for parallel work
206
+ - Clean up worktrees after merge
207
+ - Run integration tests after merging parallel work
208
+
209
+ ---
210
+
211
+ ## Common Pitfalls to Avoid
212
+
213
+ 1. **Skipping TDD** - Never implement without tests first
214
+ 2. **Suppressing lints** - Fix issues properly, don't disable rules
215
+ 3. **Large commits** - Keep commits focused and atomic
216
+ 4. **Missing typecheck** - Always run `bun run typecheck` before commit
217
+ 5. **Ignoring progress.txt** - Read learnings from previous iterations
218
+ 6. **Not checking queue** - Always check `.queue.txt` for user input
219
+ 7. **Using Node.js APIs** - Use Bun APIs instead
220
+ 8. **Adding unnecessary dependencies** - Prefer built-in solutions
221
+
222
+ ---
64
223
 
65
224
  ## Stop Condition
66
225
 
67
226
  After completing a user story, check if ALL stories have `passes: true`.
68
227
 
69
228
  If ALL stories are complete and passing, reply with:
70
- <promise>COMPLETE</promise>
229
+ `<promise>COMPLETE</promise>`
71
230
 
72
231
  If there are still stories with `passes: false`, end your response normally (another iteration will pick up the next story).
73
232
 
74
- ## Important
233
+ ---
234
+
235
+ ## Important Reminders
75
236
 
76
237
  - Work on ONE story per iteration
238
+ - Write tests BEFORE implementation (TDD)
77
239
  - Review existing code before implementing
78
- - Commit frequently
79
- - Keep CI green
240
+ - Commit frequently with proper message format
241
+ - Keep all quality checks passing
242
+ - Check `.queue.txt` for mid-run input
243
+ - Reference constitution principles in progress.txt
244
+ - Clean up any worktrees after merging
245
+
246
+ ---
247
+
248
+ **Personalized for Relentless**
249
+ **Generated:** 2026-01-13
250
+ **Re-generate:** /relentless.constitution