devlyn-cli 0.5.3 → 0.5.4
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.
|
@@ -6,6 +6,22 @@ $ARGUMENTS
|
|
|
6
6
|
|
|
7
7
|
<team_workflow>
|
|
8
8
|
|
|
9
|
+
<code_quality_standards>
|
|
10
|
+
Every line of code produced by this team must be **production-grade**. This is not a prototype — treat every fix and feature as code that ships to real users at scale.
|
|
11
|
+
|
|
12
|
+
**Non-negotiable standards**:
|
|
13
|
+
- **Root cause fixes only** — never workarounds, never "good enough for now" (see `<no_workarounds>` below)
|
|
14
|
+
- **Graceful error handling** — errors are caught, surfaced to the user with actionable context, and logged. No silent swallowing. No raw stack traces in UI. Every failure path has a recovery or clear error state.
|
|
15
|
+
- **Robust edge case coverage** — handle nulls, empty states, concurrent access, network failures, partial data, and boundary conditions. If it can happen in production, handle it.
|
|
16
|
+
- **Optimized for performance** — no unnecessary re-renders, no N+1 queries, no unbounded loops, no blocking I/O on hot paths. Profile before and after when touching performance-sensitive code.
|
|
17
|
+
- **Scalable patterns** — solutions must work at 10x the current load. Avoid patterns that degrade with data size (O(n²) where O(n) is possible, in-memory aggregation of unbounded datasets, missing pagination).
|
|
18
|
+
- **Best practice adherence** — follow the language/framework idioms of the codebase. Use established patterns over novel approaches. Leverage the type system. Prefer composition over inheritance. Keep functions focused and testable.
|
|
19
|
+
- **Clean interfaces** — clear contracts between modules. No leaky abstractions. Inputs validated at boundaries. Return types are explicit, not `any`.
|
|
20
|
+
- **Defensive but not paranoid** — validate external inputs rigorously, trust internal interfaces. Don't add guards for impossible states — instead, make impossible states unrepresentable through types.
|
|
21
|
+
|
|
22
|
+
Every teammate should evaluate their findings and recommendations against these standards. The Team Lead enforces them during synthesis and implementation.
|
|
23
|
+
</code_quality_standards>
|
|
24
|
+
|
|
9
25
|
## Phase 1: INTAKE (You are the Team Lead — work solo first)
|
|
10
26
|
|
|
11
27
|
Before spawning any teammates, do your own investigation:
|
|
@@ -487,8 +503,15 @@ Implementation order:
|
|
|
487
503
|
3. Incorporate security constraints from the Security Auditor (if present)
|
|
488
504
|
4. Respect architectural patterns flagged by the Architecture Reviewer (if present)
|
|
489
505
|
5. Apply UX requirements from the UX Designer and Accessibility Auditor (if present)
|
|
490
|
-
6.
|
|
491
|
-
|
|
506
|
+
6. **Quality gate** — before running tests, review your own code against `<code_quality_standards>`:
|
|
507
|
+
- Is error handling graceful and user-facing (not silent, not raw)?
|
|
508
|
+
- Are edge cases handled (nulls, empty, concurrent, partial data)?
|
|
509
|
+
- Is the solution performant at scale (no O(n²), no unbounded loops)?
|
|
510
|
+
- Does the code follow existing codebase patterns and idioms?
|
|
511
|
+
- Are interfaces clean and types explicit (no `any`, no leaky abstractions)?
|
|
512
|
+
- If any check fails, refactor BEFORE proceeding to tests
|
|
513
|
+
7. Run the failing test — if it still fails, revert and re-analyze (never layer fixes)
|
|
514
|
+
8. Run the full test suite for regressions
|
|
492
515
|
|
|
493
516
|
## Phase 6: CLEANUP
|
|
494
517
|
|
|
@@ -531,6 +554,12 @@ Present findings in this format:
|
|
|
531
554
|
### Verification
|
|
532
555
|
- [ ] Failing test now passes
|
|
533
556
|
- [ ] No regressions in full test suite
|
|
557
|
+
- [ ] Root cause addressed (no workarounds — see `<no_workarounds>` criteria)
|
|
558
|
+
- [ ] Error handling is graceful with user-facing messages
|
|
559
|
+
- [ ] Edge cases covered (nulls, empty states, boundaries, concurrent access)
|
|
560
|
+
- [ ] Performance verified (no O(n²), no N+1, no unbounded operations)
|
|
561
|
+
- [ ] Code follows existing codebase patterns and idioms
|
|
562
|
+
- [ ] Types are explicit, interfaces are clean, no `any` leaks
|
|
534
563
|
- [ ] UX/accessibility concerns addressed (if applicable)
|
|
535
564
|
- [ ] Manual verification (if applicable)
|
|
536
565
|
|