sqlew 4.0.2 → 4.0.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.
- package/CHANGELOG.md +79 -0
- package/README.md +17 -105
- package/assets/claude-md-snippets/plan-mode-integration.md +13 -0
- package/assets/config.example.toml +16 -0
- package/assets/sample-agents/sqlew-architect.md +1 -0
- package/assets/sample-agents/sqlew-researcher.md +1 -0
- package/assets/sample-agents/sqlew-scrum-master.md +1 -0
- package/assets/sample-commands/sqlew.md +144 -0
- package/assets/sample-skills/sqlew-plan-guidance/SKILL.md +55 -0
- package/dist/config/minimal-generator.d.ts.map +1 -1
- package/dist/config/minimal-generator.js +72 -91
- package/dist/config/minimal-generator.js.map +1 -1
- package/dist/config/types.d.ts +2 -12
- package/dist/config/types.d.ts.map +1 -1
- package/dist/config/types.js +1 -6
- package/dist/config/types.js.map +1 -1
- package/dist/init-commands.d.ts +5 -2
- package/dist/init-commands.d.ts.map +1 -1
- package/dist/init-commands.js +36 -175
- package/dist/init-commands.js.map +1 -1
- package/dist/init-skills.d.ts +19 -0
- package/dist/init-skills.d.ts.map +1 -0
- package/dist/init-skills.js +104 -0
- package/dist/init-skills.js.map +1 -0
- package/dist/server/setup.d.ts.map +1 -1
- package/dist/server/setup.js +9 -0
- package/dist/server/setup.js.map +1 -1
- package/dist/sync-commands.d.ts.map +1 -1
- package/dist/sync-commands.js +2 -7
- package/dist/sync-commands.js.map +1 -1
- package/dist/tests/unit/case-insensitive-validator.test.d.ts +14 -0
- package/dist/tests/unit/case-insensitive-validator.test.d.ts.map +1 -0
- package/dist/tests/unit/case-insensitive-validator.test.js +390 -0
- package/dist/tests/unit/case-insensitive-validator.test.js.map +1 -0
- package/dist/tools/tasks/actions/get.d.ts.map +1 -1
- package/dist/tools/tasks/actions/get.js +1 -4
- package/dist/tools/tasks/actions/get.js.map +1 -1
- package/dist/tools/tasks/internal/task-queries.d.ts.map +1 -1
- package/dist/tools/tasks/internal/task-queries.js +2 -8
- package/dist/tools/tasks/internal/task-queries.js.map +1 -1
- package/docs/SLASH_COMMANDS.md +192 -478
- package/docs/SPECIALIZED_AGENTS.md +81 -43
- package/package.json +1 -1
- package/assets/sample-commands/sqw-documentor.md +0 -204
- package/assets/sample-commands/sqw-plan.md +0 -348
- package/assets/sample-commands/sqw-research.md +0 -359
- package/assets/sample-commands/sqw-review.md +0 -377
- package/assets/sample-commands/sqw-scrum.md +0 -457
|
@@ -1,377 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
description: Validate architectural consistency - research context, then verify decisions and constraints
|
|
3
|
-
---
|
|
4
|
-
|
|
5
|
-
# Sqlew Review Workflow
|
|
6
|
-
|
|
7
|
-
Validation and consistency checking workflow - invokes researcher for context analysis, then architect for validation.
|
|
8
|
-
|
|
9
|
-
## Agent Invocation
|
|
10
|
-
|
|
11
|
-
This workflow uses two specialized sqlew agents in sequence:
|
|
12
|
-
|
|
13
|
-
```
|
|
14
|
-
Phase 1: Task tool → subagent_type: "sqlew-researcher" (haiku)
|
|
15
|
-
Phase 2: Task tool → subagent_type: "sqlew-architect" (opus)
|
|
16
|
-
```
|
|
17
|
-
|
|
18
|
-
**Example:**
|
|
19
|
-
```typescript
|
|
20
|
-
// Phase 1: Research context
|
|
21
|
-
Task({
|
|
22
|
-
subagent_type: "sqlew-researcher",
|
|
23
|
-
prompt: "Research context for: [review target]. Analyze decisions, constraints, and tasks. Identify patterns and inconsistencies."
|
|
24
|
-
})
|
|
25
|
-
|
|
26
|
-
// Phase 2: Architectural validation
|
|
27
|
-
Task({
|
|
28
|
-
subagent_type: "sqlew-architect",
|
|
29
|
-
prompt: "Based on the research findings, validate architectural consistency. Check constraint compliance and recommend corrections."
|
|
30
|
-
})
|
|
31
|
-
```
|
|
32
|
-
|
|
33
|
-
## Purpose
|
|
34
|
-
|
|
35
|
-
Verify architectural consistency, validate decision implementation, and ensure constraints are followed. A two-phase workflow combining historical analysis with expert validation.
|
|
36
|
-
|
|
37
|
-
## What It Does
|
|
38
|
-
|
|
39
|
-
### Phase 1: Research Context (Research Agent)
|
|
40
|
-
1. Analyzes relevant decisions, constraints, and tasks
|
|
41
|
-
2. **Uses constraint suggest** (v4.0) to find related constraints efficiently
|
|
42
|
-
3. Identifies patterns and relationships
|
|
43
|
-
4. Detects gaps or inconsistencies
|
|
44
|
-
5. Provides evidence-based findings
|
|
45
|
-
|
|
46
|
-
### Phase 2: Architectural Validation (Architect Agent)
|
|
47
|
-
1. Reviews research findings
|
|
48
|
-
2. Validates decision consistency
|
|
49
|
-
3. Checks constraint compliance
|
|
50
|
-
4. Recommends corrections or updates
|
|
51
|
-
5. Documents new decisions if needed
|
|
52
|
-
|
|
53
|
-
## Usage
|
|
54
|
-
|
|
55
|
-
### Interactive Mode
|
|
56
|
-
```bash
|
|
57
|
-
/sqw-review
|
|
58
|
-
```
|
|
59
|
-
Prompts for what to review and guides through both phases.
|
|
60
|
-
|
|
61
|
-
### With Arguments
|
|
62
|
-
```bash
|
|
63
|
-
/sqw-review authentication implementation
|
|
64
|
-
/sqw-review security decisions
|
|
65
|
-
/sqw-review performance constraints
|
|
66
|
-
/sqw-review backend agent work
|
|
67
|
-
```
|
|
68
|
-
|
|
69
|
-
## Workflow
|
|
70
|
-
|
|
71
|
-
### Phase 1: Researcher Analyzes Context
|
|
72
|
-
|
|
73
|
-
**Researcher examines:**
|
|
74
|
-
- Related decisions and their versions (using `suggest.by_key`, `suggest.by_tags`)
|
|
75
|
-
- Relevant constraints (v4.0: using `suggest.by_context` with `target: "constraint"`)
|
|
76
|
-
- Constraint compliance with decisions
|
|
77
|
-
- Implementation tasks (completed, in-progress, blocked)
|
|
78
|
-
- Cross-references and relationships
|
|
79
|
-
|
|
80
|
-
**Example interaction:**
|
|
81
|
-
|
|
82
|
-
> **Researcher**: Analyzing authentication implementation...
|
|
83
|
-
>
|
|
84
|
-
> *Runs suggest({ action: "by_key", key: "authentication" })*
|
|
85
|
-
> *Runs suggest({ action: "by_context", target: "constraint", text: "authentication", tags: ["security"] })*
|
|
86
|
-
>
|
|
87
|
-
> **Decisions Found** (3):
|
|
88
|
-
> 1. "api-authentication-method" - JWT tokens (v2, last updated 3 days ago)
|
|
89
|
-
> 2. "jwt-token-expiration-policy" - 15min access, 7d refresh (v1)
|
|
90
|
-
> 3. "session-management-strategy" - stateless sessions (v1)
|
|
91
|
-
>
|
|
92
|
-
> **Constraints Found** (2) via suggest (v4.0):
|
|
93
|
-
> 1. "All API endpoints must verify JWT tokens" (security, priority 4, score: 85)
|
|
94
|
-
> 2. "Token refresh must use rotation strategy" (security, priority 3, score: 72)
|
|
95
|
-
>
|
|
96
|
-
> **Implementation Tasks** (8):
|
|
97
|
-
> - ✅ 6 completed: JWT service, middleware, token rotation, tests
|
|
98
|
-
> - ⏳ 1 in-progress: Add OAuth2 social login
|
|
99
|
-
> - ❌ 1 blocked: None
|
|
100
|
-
>
|
|
101
|
-
> **Potential Issues Detected**:
|
|
102
|
-
> 1. Decision "jwt-token-expiration-policy" doesn't mention refresh token rotation, but constraint requires it
|
|
103
|
-
> 2. OAuth2 task not linked to authentication decisions
|
|
104
|
-
> 3. No constraint for OAuth2 token-to-JWT mapping
|
|
105
|
-
>
|
|
106
|
-
> Handing off to architect for validation...
|
|
107
|
-
|
|
108
|
-
### Phase 2: Architect Validates
|
|
109
|
-
|
|
110
|
-
**Architect reviews findings:**
|
|
111
|
-
|
|
112
|
-
> **Architect**: Reviewing authentication consistency...
|
|
113
|
-
>
|
|
114
|
-
> **Issue 1: Decision-Constraint Mismatch**
|
|
115
|
-
> - Decision: "jwt-token-expiration-policy" (missing rotation details)
|
|
116
|
-
> - Constraint: "Token refresh must use rotation strategy" (requires rotation)
|
|
117
|
-
> - **Action**: Update decision to include rotation strategy, or document as separate decision
|
|
118
|
-
>
|
|
119
|
-
> **Issue 2: Missing Task Links**
|
|
120
|
-
> - Task: "Add OAuth2 social login" (in-progress)
|
|
121
|
-
> - Missing link to: "api-authentication-method" decision
|
|
122
|
-
> - **Action**: Link task to decision for traceability
|
|
123
|
-
>
|
|
124
|
-
> **Issue 3: Missing OAuth2 Constraint**
|
|
125
|
-
> - OAuth2 implementation starting
|
|
126
|
-
> - No constraint for token mapping strategy
|
|
127
|
-
> - **Action**: Create constraint "OAuth2 tokens must be converted to internal JWT format"
|
|
128
|
-
>
|
|
129
|
-
> **Recommendations**:
|
|
130
|
-
> 1. Version "jwt-token-expiration-policy" to v2 with rotation details
|
|
131
|
-
> 2. Link OAuth2 task to authentication decisions
|
|
132
|
-
> 3. Create OAuth2-to-JWT mapping constraint
|
|
133
|
-
> 4. Consider documenting OAuth2 provider selection as decision
|
|
134
|
-
>
|
|
135
|
-
> Should I implement these recommendations?
|
|
136
|
-
|
|
137
|
-
## When to Use
|
|
138
|
-
|
|
139
|
-
Use `/sqw-review` when:
|
|
140
|
-
- Verifying implementation follows decisions
|
|
141
|
-
- Checking architectural consistency
|
|
142
|
-
- Auditing constraint compliance
|
|
143
|
-
- Validating completed work
|
|
144
|
-
- Investigating potential issues
|
|
145
|
-
|
|
146
|
-
**Don't use when:**
|
|
147
|
-
- Creating new decisions (use `/sqw-documentor` instead)
|
|
148
|
-
- Planning new work (use `/sqw-plan` instead)
|
|
149
|
-
- Just querying history (use `/sqw-research` instead)
|
|
150
|
-
|
|
151
|
-
## Review Types
|
|
152
|
-
|
|
153
|
-
### Decision Consistency Review
|
|
154
|
-
Verify decisions are:
|
|
155
|
-
- Complete and well-documented
|
|
156
|
-
- Consistent with each other
|
|
157
|
-
- Implemented by tasks
|
|
158
|
-
- Compliant with constraints
|
|
159
|
-
- Properly versioned
|
|
160
|
-
|
|
161
|
-
### Implementation Review
|
|
162
|
-
Verify tasks:
|
|
163
|
-
- Linked to decisions they implement
|
|
164
|
-
- Following constraint guidelines
|
|
165
|
-
- Properly prioritized
|
|
166
|
-
- Not blocked unnecessarily
|
|
167
|
-
- Completed work matches decisions
|
|
168
|
-
|
|
169
|
-
### Constraint Compliance Review
|
|
170
|
-
Verify constraints are:
|
|
171
|
-
- Clear and actionable
|
|
172
|
-
- Reflected in decisions
|
|
173
|
-
- Enforced by task acceptance criteria
|
|
174
|
-
- Not conflicting with each other
|
|
175
|
-
- Appropriate priority level
|
|
176
|
-
|
|
177
|
-
### Agent Workload Review
|
|
178
|
-
Verify agents have:
|
|
179
|
-
- Balanced workload
|
|
180
|
-
- Clear task assignments
|
|
181
|
-
- No prolonged blocked tasks
|
|
182
|
-
- Consistent work patterns
|
|
183
|
-
- Appropriate expertise matches
|
|
184
|
-
|
|
185
|
-
## Example: Complete Review Session
|
|
186
|
-
|
|
187
|
-
```bash
|
|
188
|
-
/sqw-review security architecture
|
|
189
|
-
```
|
|
190
|
-
|
|
191
|
-
### Phase 1: Researcher
|
|
192
|
-
|
|
193
|
-
> **Researcher**: Analyzing security architecture...
|
|
194
|
-
>
|
|
195
|
-
> *Runs suggest({ action: "by_tags", tags: ["security"] })*
|
|
196
|
-
> *Runs suggest({ action: "by_context", target: "constraint", tags: ["security"], layer: "cross-cutting" })*
|
|
197
|
-
>
|
|
198
|
-
> **Security Decisions** (5):
|
|
199
|
-
> 1. "api-authentication-method" - JWT tokens
|
|
200
|
-
> 2. "api-authorization-approach" - role-based access control
|
|
201
|
-
> 3. "password-hashing-algorithm" - bcrypt with work factor 12
|
|
202
|
-
> 4. "https-enforcement-strategy" - HTTPS-only in production
|
|
203
|
-
> 5. "security-headers-policy" - strict CSP, HSTS, X-Frame-Options
|
|
204
|
-
>
|
|
205
|
-
> **Security Constraints Found** (4) via suggest (v4.0):
|
|
206
|
-
> 1. "All passwords must be hashed with bcrypt" (security, priority 4, score: 88)
|
|
207
|
-
> 2. "All API endpoints must verify authentication" (security, priority 4, score: 85)
|
|
208
|
-
> 3. "Production must enforce HTTPS" (security, priority 4, score: 80)
|
|
209
|
-
> 4. "All responses must include security headers" (security, priority 3, score: 72)
|
|
210
|
-
>
|
|
211
|
-
> **Security Tasks** (12 total):
|
|
212
|
-
> - ✅ 9 completed
|
|
213
|
-
> - ⏳ 2 in-progress: HTTPS redirect middleware, CSP configuration
|
|
214
|
-
> - ❌ 1 blocked: Security audit (waiting for external auditor)
|
|
215
|
-
>
|
|
216
|
-
> **Cross-Layer Analysis**:
|
|
217
|
-
> - Presentation: 3 tasks (HTTPS, CSP, HSTS)
|
|
218
|
-
> - Business: 4 tasks (auth, authz, password hashing)
|
|
219
|
-
> - Cross-cutting: 5 tasks (security middleware, logging)
|
|
220
|
-
>
|
|
221
|
-
> **Findings**:
|
|
222
|
-
> 1. ✅ All decisions have implementing tasks
|
|
223
|
-
> 2. ✅ All constraints aligned with decisions
|
|
224
|
-
> 3. ⚠️ CSP configuration task in-progress for 5 days (possible stale)
|
|
225
|
-
> 4. ⚠️ No decision documented for session timeout policy
|
|
226
|
-
> 5. ⚠️ HTTPS redirect task not linked to "https-enforcement-strategy" decision
|
|
227
|
-
>
|
|
228
|
-
> Handing to architect for validation...
|
|
229
|
-
|
|
230
|
-
### Phase 2: Architect
|
|
231
|
-
|
|
232
|
-
> **Architect**: Security architecture validation...
|
|
233
|
-
>
|
|
234
|
-
> **Overall Assessment**: Strong security foundation with minor gaps
|
|
235
|
-
>
|
|
236
|
-
> **Issue 1: Stale CSP Configuration Task**
|
|
237
|
-
> - Task in-progress for 5 days without updates
|
|
238
|
-
> - **Action**: Check if task is blocked, move to waiting_review, or reassign
|
|
239
|
-
>
|
|
240
|
-
> **Issue 2: Missing Session Timeout Decision**
|
|
241
|
-
> - Multiple authentication decisions but no session timeout policy
|
|
242
|
-
> - Constraint: "All API endpoints must verify authentication" implies timeout needed
|
|
243
|
-
> - **Action**: Document "session-timeout-policy" decision
|
|
244
|
-
>
|
|
245
|
-
> **Issue 3: Missing Task Link**
|
|
246
|
-
> - HTTPS redirect task not linked to HTTPS enforcement decision
|
|
247
|
-
> - **Action**: Link task to decision for traceability
|
|
248
|
-
>
|
|
249
|
-
> **Issue 4: Password Reset Security Not Addressed**
|
|
250
|
-
> - Password hashing documented but not reset/recovery security
|
|
251
|
-
> - **Action**: Consider documenting "password-reset-security" decision
|
|
252
|
-
>
|
|
253
|
-
> **Constraint Compliance**: ✅ All active
|
|
254
|
-
> - Password hashing: ✅ Implemented (bcrypt work factor 12)
|
|
255
|
-
> - Authentication verification: ✅ Middleware in place
|
|
256
|
-
> - HTTPS enforcement: ⏳ In progress (nearly complete)
|
|
257
|
-
> - Security headers: ⏳ In progress (CSP configuration)
|
|
258
|
-
>
|
|
259
|
-
> **Recommendations**:
|
|
260
|
-
> 1. Investigate CSP configuration task (5 days stale)
|
|
261
|
-
> 2. Document session timeout policy decision
|
|
262
|
-
> 3. Link HTTPS redirect task to enforcement decision
|
|
263
|
-
> 4. Consider password reset security decision
|
|
264
|
-
> 5. Create constraint for session timeout after decision documented
|
|
265
|
-
>
|
|
266
|
-
> **Priority Actions** (next 24 hours):
|
|
267
|
-
> 1. Check CSP task status (possibly blocked?)
|
|
268
|
-
> 2. Document session timeout decision (closes security gap)
|
|
269
|
-
>
|
|
270
|
-
> Should I implement these recommendations?
|
|
271
|
-
|
|
272
|
-
## Integration with Other Workflows
|
|
273
|
-
|
|
274
|
-
This workflow combines:
|
|
275
|
-
- `/sqw-research` - Context analysis (researcher phase)
|
|
276
|
-
- `/sqw-documentor` - Decision updates (architect phase)
|
|
277
|
-
|
|
278
|
-
Use with:
|
|
279
|
-
- **Before review**: Complete implementation work
|
|
280
|
-
- **During review**: Researcher → architect validation
|
|
281
|
-
- **After review**: Implement recommendations, create corrective tasks
|
|
282
|
-
|
|
283
|
-
## Token Efficiency
|
|
284
|
-
|
|
285
|
-
This workflow is efficient for comprehensive validation:
|
|
286
|
-
|
|
287
|
-
**Manual validation**:
|
|
288
|
-
- Query decisions: 3k tokens
|
|
289
|
-
- Query constraints: 2k tokens
|
|
290
|
-
- Query tasks: 4k tokens
|
|
291
|
-
- Cross-reference: 2k tokens
|
|
292
|
-
- Validate: 3k tokens
|
|
293
|
-
- Total: 14k tokens
|
|
294
|
-
|
|
295
|
-
**Combined /sqw-review (v4.0)**:
|
|
296
|
-
- Research phase: 5k tokens (using suggest for constraints)
|
|
297
|
-
- Architect phase: 4k tokens (validation)
|
|
298
|
-
- **Total**: 9k tokens (35% savings)
|
|
299
|
-
- Constraint suggest reduces query overhead significantly
|
|
300
|
-
|
|
301
|
-
**Estimated Token Usage**: 10,000-20,000 tokens per review session
|
|
302
|
-
|
|
303
|
-
**AI Time Estimate**:
|
|
304
|
-
- Research phase: 10-20 minutes
|
|
305
|
-
- Architect phase: 15-25 minutes
|
|
306
|
-
- **Total**: 25-45 minutes
|
|
307
|
-
|
|
308
|
-
## Review Checklist
|
|
309
|
-
|
|
310
|
-
The workflow automatically checks:
|
|
311
|
-
|
|
312
|
-
### Decision Quality
|
|
313
|
-
- [ ] Key decisions documented
|
|
314
|
-
- [ ] Rationale provided
|
|
315
|
-
- [ ] Alternatives considered
|
|
316
|
-
- [ ] Tradeoffs acknowledged
|
|
317
|
-
- [ ] Properly tagged
|
|
318
|
-
- [ ] Appropriate layer assigned
|
|
319
|
-
|
|
320
|
-
### Decision Consistency
|
|
321
|
-
- [ ] No conflicting decisions
|
|
322
|
-
- [ ] Versions tracked properly
|
|
323
|
-
- [ ] Related decisions linked
|
|
324
|
-
- [ ] Decision context complete
|
|
325
|
-
|
|
326
|
-
### Implementation Coverage
|
|
327
|
-
- [ ] Decisions have implementing tasks
|
|
328
|
-
- [ ] Tasks linked to decisions
|
|
329
|
-
- [ ] Acceptance criteria match decisions
|
|
330
|
-
- [ ] No orphaned implementations
|
|
331
|
-
|
|
332
|
-
### Constraint Compliance
|
|
333
|
-
- [ ] Constraints documented
|
|
334
|
-
- [ ] Constraints aligned with decisions
|
|
335
|
-
- [ ] Tasks follow constraints
|
|
336
|
-
- [ ] Priorities appropriate
|
|
337
|
-
|
|
338
|
-
### Task Health
|
|
339
|
-
- [ ] No stale in-progress tasks
|
|
340
|
-
- [ ] Blocked tasks have valid reasons
|
|
341
|
-
- [ ] Dependencies logical
|
|
342
|
-
- [ ] Agent assignments appropriate
|
|
343
|
-
|
|
344
|
-
## Tips
|
|
345
|
-
|
|
346
|
-
1. **Be specific about review scope** - "authentication" vs "entire security architecture"
|
|
347
|
-
2. **Review regularly** - catch issues early (weekly for active projects)
|
|
348
|
-
3. **Act on findings** - researcher + architect provide actionable recommendations
|
|
349
|
-
4. **Document corrections** - update decisions when inconsistencies found
|
|
350
|
-
5. **Link everything** - tasks ↔ decisions ↔ constraints for traceability
|
|
351
|
-
|
|
352
|
-
## Review Triggers
|
|
353
|
-
|
|
354
|
-
Consider running `/sqw-review` when:
|
|
355
|
-
- Completing a major feature
|
|
356
|
-
- Before starting related work
|
|
357
|
-
- After significant decision changes
|
|
358
|
-
- Investigating quality issues
|
|
359
|
-
- Onboarding new team members
|
|
360
|
-
- Preparing for code review
|
|
361
|
-
- Quarterly architecture audits
|
|
362
|
-
|
|
363
|
-
## Error Recovery
|
|
364
|
-
|
|
365
|
-
If research finds too many issues:
|
|
366
|
-
- Break review into smaller scopes
|
|
367
|
-
- Prioritize critical issues first
|
|
368
|
-
- Create corrective tasks via scrum master
|
|
369
|
-
- Schedule follow-up review
|
|
370
|
-
|
|
371
|
-
If architect validation is unclear:
|
|
372
|
-
- Request more specific research
|
|
373
|
-
- Break complex issues into sub-reviews
|
|
374
|
-
- Consult original decision authors
|
|
375
|
-
- Document uncertainty as new decision
|
|
376
|
-
|
|
377
|
-
You get comprehensive validation combining data-driven research with expert architectural analysis.
|