tlc-claude-code 1.5.8 → 1.5.9
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.
|
@@ -2,6 +2,40 @@
|
|
|
2
2
|
|
|
3
3
|
Write failing tests, then implement to make them pass.
|
|
4
4
|
|
|
5
|
+
## Engineering Standards
|
|
6
|
+
|
|
7
|
+
**Code like a senior engineer with 15+ years experience.** Every line should reflect:
|
|
8
|
+
|
|
9
|
+
### Code Quality
|
|
10
|
+
- **Clean Architecture**: Separate concerns. Domain logic never depends on infrastructure.
|
|
11
|
+
- **SOLID Principles**: Single responsibility, open/closed, Liskov substitution, interface segregation, dependency inversion.
|
|
12
|
+
- **DRY but not premature**: Extract only after 3+ repetitions. Duplication is better than wrong abstraction.
|
|
13
|
+
- **Meaningful names**: Variables, functions, classes should reveal intent. No abbreviations except industry standards.
|
|
14
|
+
- **Small functions**: Each function does ONE thing. If you need comments to explain sections, extract them.
|
|
15
|
+
|
|
16
|
+
### Defensive Programming
|
|
17
|
+
- **Validate at boundaries**: All external input (user, API, file) gets validated immediately.
|
|
18
|
+
- **Fail fast**: Throw early with clear error messages. Don't let bad state propagate.
|
|
19
|
+
- **Handle edge cases**: null, undefined, empty arrays, empty strings, zero, negative numbers.
|
|
20
|
+
- **Type safety**: Use TypeScript strictly. No `any` except when interfacing with untyped libs.
|
|
21
|
+
|
|
22
|
+
### Performance Awareness
|
|
23
|
+
- **O(n) thinking**: Know the complexity of your algorithms. Avoid nested loops on large datasets.
|
|
24
|
+
- **Lazy loading**: Don't fetch/compute until needed.
|
|
25
|
+
- **Caching**: Identify expensive operations and cache appropriately.
|
|
26
|
+
- **Database queries**: No N+1. Use joins, batch operations, proper indexes.
|
|
27
|
+
|
|
28
|
+
### Security First
|
|
29
|
+
- **Never trust input**: Sanitize, escape, parameterize.
|
|
30
|
+
- **Least privilege**: Functions/modules only access what they need.
|
|
31
|
+
- **No secrets in code**: Environment variables for all credentials.
|
|
32
|
+
- **Audit trail**: Log security-relevant actions.
|
|
33
|
+
|
|
34
|
+
### Testability
|
|
35
|
+
- **Dependency injection**: Pass dependencies, don't import singletons.
|
|
36
|
+
- **Pure functions**: Same input = same output. No hidden state.
|
|
37
|
+
- **Mockable interfaces**: Code to interfaces, not implementations.
|
|
38
|
+
|
|
5
39
|
## What This Does
|
|
6
40
|
|
|
7
41
|
1. **Write failing tests** for all tasks in the phase
|
|
@@ -2,6 +2,26 @@
|
|
|
2
2
|
|
|
3
3
|
Research and create implementation plans with clear tasks.
|
|
4
4
|
|
|
5
|
+
## Architectural Standards
|
|
6
|
+
|
|
7
|
+
**Plan like a principal engineer designing for scale:**
|
|
8
|
+
|
|
9
|
+
### Structure
|
|
10
|
+
- **Layered architecture**: UI → Application → Domain → Infrastructure
|
|
11
|
+
- **Bounded contexts**: Group related functionality, minimize coupling
|
|
12
|
+
- **Dependency direction**: Always point inward (infrastructure depends on domain, never reverse)
|
|
13
|
+
|
|
14
|
+
### Design Decisions
|
|
15
|
+
- **Interface-first**: Define contracts before implementations
|
|
16
|
+
- **Extension points**: Where will this need to grow? Plan for it.
|
|
17
|
+
- **Error boundaries**: Where can failures occur? How are they handled?
|
|
18
|
+
- **Data flow**: How does data enter, transform, and exit the system?
|
|
19
|
+
|
|
20
|
+
### Task Breakdown
|
|
21
|
+
- **Vertical slices**: Each task delivers testable, visible progress
|
|
22
|
+
- **Risk-first**: Tackle unknowns and integrations early
|
|
23
|
+
- **Dependencies explicit**: Mark what blocks what
|
|
24
|
+
|
|
5
25
|
## What This Does
|
|
6
26
|
|
|
7
27
|
1. Researches how to implement the phase
|
|
@@ -2,6 +2,16 @@
|
|
|
2
2
|
|
|
3
3
|
For ad-hoc tasks that don't need full phase planning, but still deserve tests.
|
|
4
4
|
|
|
5
|
+
## Engineering Standards
|
|
6
|
+
|
|
7
|
+
Even quick tasks follow senior engineer standards:
|
|
8
|
+
- **Clean code**: Meaningful names, single responsibility, no magic values
|
|
9
|
+
- **Defensive**: Validate input, handle edge cases, fail fast
|
|
10
|
+
- **Secure**: No hardcoded secrets, sanitize user input
|
|
11
|
+
- **Testable**: Pure functions, injected dependencies
|
|
12
|
+
|
|
13
|
+
Quick doesn't mean sloppy. Every line should be production-ready.
|
|
14
|
+
|
|
5
15
|
## What This Does
|
|
6
16
|
|
|
7
17
|
1. **Ask what you want to do**
|
|
@@ -2,6 +2,18 @@
|
|
|
2
2
|
|
|
3
3
|
One command. Context-aware. Visual dashboard.
|
|
4
4
|
|
|
5
|
+
## Engineering Mindset
|
|
6
|
+
|
|
7
|
+
**All TLC code generation follows senior engineer standards:**
|
|
8
|
+
- Clean architecture with separated concerns
|
|
9
|
+
- SOLID principles strictly applied
|
|
10
|
+
- Defensive programming with validation at boundaries
|
|
11
|
+
- Performance-aware (O(n) thinking, no N+1 queries)
|
|
12
|
+
- Security-first (no secrets in code, sanitize all input)
|
|
13
|
+
- Fully testable (dependency injection, pure functions)
|
|
14
|
+
|
|
15
|
+
See `/tlc:build` for the complete engineering standards checklist.
|
|
16
|
+
|
|
5
17
|
## What This Does
|
|
6
18
|
|
|
7
19
|
Launches the TLC dashboard - a visual interface showing project state, phases, tests, and next actions.
|