tlc-claude-code 1.5.7 → 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**
@@ -145,11 +145,35 @@ fi
145
145
  2. **Invoke each configured provider** (one chunk at a time if split):
146
146
 
147
147
  ```bash
148
- # For Codex (GPT-5.2) - use file attachment
149
- codex --print "Review this code diff for quality issues, bugs, security vulnerabilities, and test coverage. Respond with APPROVED or CHANGES_REQUESTED. File: /tmp/review-diff.patch"
150
-
151
- # For Gemini - use file attachment
152
- gemini --print "Review this code diff for quality and security issues. File: /tmp/review-diff.patch"
148
+ # For Codex (GPT-5.2) - detailed review prompt
149
+ codex --print "You are a senior code reviewer. Analyze this diff thoroughly:
150
+
151
+ 1. **Line-by-line Analysis**: Comment on specific lines with issues
152
+ 2. **Bugs**: Identify potential bugs, edge cases, null checks
153
+ 3. **Security**: SQL injection, XSS, command injection, auth issues
154
+ 4. **Performance**: N+1 queries, unnecessary loops, memory leaks
155
+ 5. **Code Quality**: Naming, duplication, complexity, SOLID principles
156
+ 6. **Test Coverage**: Are the changes properly tested?
157
+
158
+ For each issue found:
159
+ - File and line number
160
+ - Severity (critical/high/medium/low)
161
+ - What's wrong
162
+ - How to fix it
163
+
164
+ End with: APPROVED (no critical/high issues) or CHANGES_REQUESTED (has critical/high issues)
165
+
166
+ File: /tmp/review-diff.patch"
167
+
168
+ # For Gemini - detailed review prompt
169
+ gemini --print "Review this code diff as a senior engineer. Provide:
170
+ - Specific line-by-line feedback
171
+ - Security vulnerabilities with file:line references
172
+ - Performance concerns
173
+ - Code quality issues
174
+ - Missing test coverage
175
+
176
+ Be thorough and specific. File: /tmp/review-diff.patch"
153
177
  ```
154
178
 
155
179
  **Large Diff Handling:**
@@ -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.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "tlc-claude-code",
3
- "version": "1.5.7",
3
+ "version": "1.5.9",
4
4
  "description": "TLC - Test Led Coding for Claude Code",
5
5
  "bin": {
6
6
  "tlc": "./bin/tlc.js",