@torus-engineering/tas-kit 1.14.0 → 2.1.0

package/.tas/commands/tas-checklist.md

@@ -0,0 +1,180 @@
+# /tas-checklist $FEATURE_FILE
+
+You are a Senior QA Engineer creating a comprehensive Test Checklist for a feature based on its business requirements document.
+
+## Purpose
+
+Generate a structured Test Checklist by analyzing the Feature document, identifying all test scenarios across multiple categories (GUI, Validation, Business Logic, Exception Handling, Security, Performance, Integration).
+
+## When to Use
+
+- Run after Feature document is approved
+- Run before writing detailed Test Cases
+- Run when Feature document changes (regression checklist update)
+
+## Prerequisites
+
+1. Feature document exists in current directory (pattern: `*-Feature-*.md`)
+2. Template exists at `.tas/templates/TestChecklist.md`
+3. `tas.yaml` exists at project root (for project context)
+
+## Step-by-Step Actions
+
+### Step 1: Locate and Read Feature Document
+
+1. If `$FEATURE_FILE` is provided, use that file
+2. Otherwise, search for Feature files in current directory:
+   - Pattern: `*-Feature-*.md`
+   - If multiple found, ask user to select
+   - If none found, error: "No Feature document found. Please run in feature directory."
+
+3. Read the Feature document and extract:
+   - Feature Code (e.g., TAS-Feature-001)
+   - Feature Name
+   - Feature Code from filename
+   - Business Requirements
+   - Acceptance Criteria (Given/When/Then format)
+   - User Stories
+   - Business Rules
+   - Technical Constraints (if mentioned)
+
+### Step 2: Read Template
+
+Read `.tas/templates/TestChecklist.md` to understand the structure.
+
+### Step 3: Parse Requirements into Test Points
+
+Analyze the Feature document and generate test checklist items for each category:
+
+#### GUI & UX
+- Identify UI elements mentioned (forms, buttons, tables, modals, etc.)
+- Check for responsive design requirements
+- Check for accessibility requirements
+- Check for UX flows mentioned
+
+#### Validation
+- Extract field-level validations from requirements
+- Identify required fields
+- Identify data type constraints (number, email, date, etc.)
+- Identify length/format constraints
+- Identify range constraints (min/max values)
+- Identify unique constraints
+
+#### Business Logic (CRITICAL - P0)
+- Extract all business rules from Acceptance Criteria
+- Identify main user flows (happy paths)
+- Identify conditional logic (if/else scenarios)
+- Identify calculations/formulas
+- Identify state transitions (status changes)
+- Identify cross-feature dependencies
+
+#### Exception Handling
+- Identify error scenarios from requirements
+- Consider edge cases (empty data, maximum values, boundary conditions)
+- Consider system failures (network errors, timeouts)
+- Consider invalid user actions (double-click, concurrent access)
+- Consider data conflicts (duplicate, stale data)
+
+#### Security
+- Identify authentication requirements
+- Identify authorization/role-based access
+- Identify sensitive data handling
+- Identify input validation for security (XSS, injection)
+- Identify API security requirements
+
+#### Performance
+- Identify response time requirements
+- Identify load/concurrency requirements
+- Identify database query concerns
+- Identify large data handling
+
+#### Integration
+- Identify external API calls
+- Identify database operations
+- Identify third-party service integrations
+- Identify message queue/events (if any)
+
+### Step 4: Assign Priority
+
+For each test point, assign priority:
+- **P0:** Critical - Core business functionality, data integrity, security
+- **P1:** High - Important business rules, error handling
+- **P2:** Medium - UI/UX, non-critical validations
+- **P3:** Low - Nice to have, cosmetic
+
+### Step 5: Generate Checklist File
+
+Create file: `{CODE}-Feature-{NNN}-TestChecklist.md`
+
+Fill in the template with:
+1. **Header information:**
+   - Feature Name, Code, Created Date, Tester, Reviewer
+
+2. **Feature Overview:**
+   - Feature Description (from Feature doc)
+   - Business Objective (from Feature doc)
+   - Scope (In scope: what's in the doc, Out of scope: assumptions)
+
+3. **Checklist Matrix:**
+   - Populate all 7 categories with parsed test points
+   - Include Point to Check, Priority, Requirement ID (link to AC)
+   - Leave Test Case ID empty (to be filled later)
+
+4. **Coverage Summary:**
+   - Calculate total points per category
+   - Calculate coverage percentage
+
+5. **Risk Assessment:**
+   - Identify 3-5 key risks based on complexity
+   - Suggest mitigations
+
+### Step 6: Output Summary
+
+Report to user:
+- Checklist file created: `{filename}`
+- Total test points: `{count}`
+- Breakdown by category
+- P0 items: `{count}`
+- Coverage target: 90%
+
+## Important Notes
+
+1. **One test point per row** - Don't combine multiple checks
+2. **Use requirement IDs** - Link each test point to specific Acceptance Criteria
+3. **Focus on high-risk areas** - P0 should be the core business logic
+4. **Be specific** - "Check login validation" → "Check login rejects invalid email format"
+5. **Think like a tester** - Consider edge cases, negative scenarios, security
+6. **Maintain traceability** - Every test point should map to a requirement
+
+## Example Output
+
+```
+✓ Test Checklist created: TAS-Feature-001-Login-TestChecklist.md
+
+Summary:
+├─ Total Test Points: 47
+├─ GUI & UX: 8 (17%)
+├─ Validation: 12 (26%)
+├─ Business Logic: 10 (21%)
+├─ Exception Handling: 6 (13%)
+├─ Security: 6 (13%)
+├─ Performance: 3 (6%)
+└─ Integration: 2 (4%)
+
+Priority Breakdown:
+├─ P0 (Critical): 18
+├─ P1 (High): 15
+├─ P2 (Medium): 10
+└─ P3 (Low): 4
+
+Next Steps:
+1. Review checklist with Senior QA
+2. Create detailed Test Cases for each point
+3. Link Test Case IDs when ready
+```
+
+## Error Handling
+
+- If Feature file not found: "No Feature document found in current directory. Please run in a feature directory or specify file: /tas-checklist <filename>"
+- If Feature file has no Acceptance Criteria: "Warning: No Acceptance Criteria found. Checklist may be incomplete."
+- If template not found: "Error: TestChecklist.md template not found in .tas/templates/"

package/.tas/commands/tas-debug.md

@@ -0,0 +1,103 @@
+---
+model: sonnet
+---
+
+# /tas-debug $ARGUMENTS
+
+Role: SE - Software Engineer
+Debug and resolve build/runtime/functional errors for an already-implemented feature or stack.
+Use when: feature is coded but broken, server crashes on start, browser shows errors, tests fail after merge.
+Differs from /tas-fix: runs full build-debug loop (start server → capture logs → browser check → auto-resolve up to N times).
+Differs from /tas-dev Step 3.5: standalone — no implementation phase, targets existing code.
+
+## Stack Detection
+Read `.tas/rules/common/stack-detection.md`.
+
+## Actions
+
+### Step 1 — Identify target
+
+`$ARGUMENTS` may be:
+- Feature ID (e.g. `TAS-042`) → read Feature file + Technical file from `docs/features/`
+- Stack directory path (e.g. `apps/web`) → skip Feature files, infer stack from contents
+- Error message / stack trace (no ID) → ask user: "Which stack/dir is broken?"
+- Empty → read `project-status.yaml`, find features with `status: In Development`. If multiple, list for user to choose.
+
+From target, determine:
+- `stack` — detected from Feature frontmatter OR inferred from `package.json` / `*.csproj` / `*.py` / `*.sln` in dir
+- `working_dir` — root dir for that stack's server process
+- `changed_files` — if Feature file exists: read Technical file `## File Changes`. Else: `git diff --name-only HEAD` in working_dir.
+- `ac_list` — if Feature file exists: extract AC lines (Given/When/Then). Else: empty (skip functional check).
+
+### Step 2 — Snapshot current error (optional fast-path)
+
+If `$ARGUMENTS` contains an error message or stack trace:
+- Pass directly to `build-resolver` agent as pre-diagnosis context
+- Apply returned fix first, then enter build-debug loop at attempt 1
+
+If no error provided: go straight to loop.
+
+### Step 2.5 — Triage Ladder (before loop)
+
+Enumerate hypotheses for the reported symptom. Probe cheapest first. Stop at first level that produces divergence from expected.
+
+For "page broken" symptom:
+- **L1. HTTP status** — `curl -sI {url}` (headers only, ~5 lines)
+- **L2. Server log** — already streaming from loop; check last 20 lines
+- **L3. HTML snapshot** — `curl -s {url} > .tas/tmp/snap.html` (single fetch, reuse for L4)
+- **L4. Section presence** — Grep against `snap.html` for expected markers (titles, ids, data attrs)
+- **L5. Template/render code** — `Read` with `offset` + `limit` at suspect range (never full file unless ≤ 80 lines)
+
+For "API broken" symptom: L1 → L2 → curl JSON body → Grep handler → Read handler range.
+
+For "test failing": jump to error line in test output → Grep target symbol → Read narrow range.
+
+**Rules**:
+- One snapshot per URL per session. Re-Grep the cached `snap.html`, do not re-fetch.
+- Drop levels above the divergence point — do not probe further once cause located.
+
+### Step 3 — Build & Debug Loop
+
+Read `.tas/rules/common/build-debug-loop.md`. Follow loop protocol exactly.
+
+```
+max_attempts = tas.yaml[build_debug_attempts] ?? 3
+```
+
+Run loop for each stack identified in Step 1.
+If multiple stacks (monorepo): run sequentially, stack order from Technical Plan (or alphabetical if no plan).
+
+**build-resolver call context**: stack, command, attempt N/max, exit code, last 50 lines stdout+stderr, browser errors (if any), AC text (if functional check), changed_files list.
+
+### Step 4 — Wrap up
+
+**Before anything else: confirm Tear Down ran.** Loop protocol mandates kill_server() on all exit paths. Verify no dev server PID still alive (check port / process list). If orphan detected → kill via Tear Down snippet from `build-debug-loop.md` before logging.
+
+**If loop PASSED:**
+- Append `## Build Debug Log` to Technical file (or create standalone log file `docs/debug/{FEATURE_ID}-debug-{date}.md` if no Technical file)
+- **SAD Impact Heuristic** — read `.tas/rules/common/sad-impact.md` "Quick Heuristic". Grep changed files for trigger patterns (deps add, ENV add, Dockerfile EXPOSE/ENV, migrations, IaC, CI, new top-level dirs).
+  - **Hit & target = Feature ID:** auto-invoke `/tas-sad "Feature-{NNN}: {summary of triggers hit}" --autonomous={mode}`; verify `Feature-{NNN}` in Changelog before wrap.
+  - **Hit & target = standalone dir (no Feature):** STOP wrap, surface: "Debug fix touches SAD trigger ({signal}). Re-run as `/tas-bug` or run `/tas-sad` manually before committing."
+  - **No hit:** continue normally.
+- Output commit message: `fix: resolve {stack} build/runtime errors for {Feature ID or dir}`
+- Suggest: "Run `/tas-functest {Feature ID}` to verify AC end-to-end."
+- If fix touched ≥ 3 files or changed architecture: suggest `/tas-review {Feature ID}` for post-fix review.
+
+**If loop FAILED (max attempts exceeded):**
+- Output warning block (format from `build-debug-loop.md`)
+- Do NOT commit partial fixes
+- Suggest: `/tas-bug` if issue is severe enough for full tracking.
+
+## Principles
+- DO NOT implement new features — only fix what's broken
+- DO NOT read more than 5 files outside the broken stack without user confirmation
+- DO NOT read sibling working files until root-cause hypothesis is named (one sentence stating which layer is suspect)
+- DO NOT read migration files when a D1/SQL query result answers the same question — query first, read schema only if query result is unexpected
+- Read full file only when ≤ 80 lines OR Grep has already pinpointed a line range — otherwise use `offset` + `limit`
+- Fix at root cause — do not patch symptoms
+- If fix requires architectural change → stop, surface to user, suggest `/tas-adr`
+- If changed files match SAD Impact Heuristic → auto-invoke `/tas-sad` (Feature target) or escalate to `/tas-bug` (standalone target)
+
+## Final Step — Token Log
+
+Follow `.tas/rules/common/token-logging.md`: write AI Usage Log to Feature file (if exists) or debug log file.

package/.tas/commands/tas-design.md

@@ -1,37 +1,41 @@
-# /tas-design $ARGUMENTS
-
-Role: PE - Product Engineer
-Create or update Design Specification document (UI/UX flows, wireframe descriptions).
-
-## Prerequisite
-- docs/prd.md must exist
-
-## Actions
-1. Need context from root/tas.yaml and docs/prd.md
-2. Check if docs/design-spec.md already exists:
-
-### CREATE mode (file doesn't exist):
-3. Need context from .tas/templates/Design-Spec.md
-4. $ARGUMENTS is design scope description. If not provided, base on PRD.
-5. Create file docs/design-spec.md containing:
-   - User flows (Mermaid flowchart)
-   - Screen descriptions
-   - Navigation structure
-   - Interaction patterns
-   - Responsive behavior notes
-6. Update `project-status.yaml` per `.tas/rules/common/project-status.md` — add `artifacts.design_spec`.
-
-### UPDATE mode (file exists):
-3. Need context from current docs/design-spec.md
-4. $ARGUMENTS is change description. If not provided, ask user which section to update.
-5. Update file, add changelog
-6. Update `project-status.yaml` per `.tas/rules/common/project-status.md` — update `artifacts.design_spec`.
-
-## Principles
-- Focus on flows and behavior, not pixel-perfect design
-- Each screen needs: purpose, key elements, actions available
-- Mermaid compliance: :::mermaid wrapper, no () in node labels
-
-## Final Step — Token Log
-
-Follow `.tas/rules/common/token-logging.md`: write AI Usage Log to `docs/design-spec.md`.
+---
+model: sonnet
+---
+
+# /tas-design $ARGUMENTS
+
+Role: PE - Product Engineer
+Create or update Design Specification document (UI/UX flows, wireframe descriptions).
+
+## Prerequisite
+- docs/prd.md must exist
+
+## Actions
+1. Need context from root/tas.yaml and docs/prd.md
+2. Check if docs/design-spec.md already exists:
+
+### CREATE mode (file doesn't exist):
+3. Need context from .tas/templates/Design-Spec.md
+4. $ARGUMENTS is design scope description. If not provided, base on PRD.
+5. Create file docs/design-spec.md containing:
+   - User flows (Mermaid flowchart)
+   - Screen descriptions
+   - Navigation structure
+   - Interaction patterns
+   - Responsive behavior notes
+6. Update `project-status.yaml` per `.tas/rules/common/project-status.md` — add `artifacts.design_spec`.
+
+### UPDATE mode (file exists):
+3. Need context from current docs/design-spec.md
+4. $ARGUMENTS is change description. If not provided, ask user which section to update.
+5. Update file, add changelog
+6. Update `project-status.yaml` per `.tas/rules/common/project-status.md` — update `artifacts.design_spec`.
+
+## Principles
+- Focus on flows and behavior, not pixel-perfect design
+- Each screen needs: purpose, key elements, actions available
+- Mermaid compliance: :::mermaid wrapper, no () in node labels
+
+## Final Step — Token Log
+
+Follow `.tas/rules/common/token-logging.md`: write AI Usage Log to `docs/design-spec.md`.