@torus-engineering/tas-kit 1.14.0 → 2.1.0

package/.tas/commands/tas-adr.md

@@ -1,33 +1,37 @@
-# /tas-adr $ARGUMENTS
-
-Role: SE - Software Engineer
-Create or update Architecture Decision Record.
-
-## Actions
-1. Need context from .tas/templates/ADR.md
-2. Scan docs/adr/ to identify existing ADRs
-3. Determine mode based on $ARGUMENTS:
-
-### CREATE mode ($ARGUMENTS is new title, e.g., "Use CQRS for Order Service"):
-4. Determine next sequence number (ADR-001, ADR-002...)
-5. If docs/sad.md exists, need context from SAD to ensure ADR consistency
-6. Create file docs/adr/ADR-{NNN}-{slug}.md
-7. Update `project-status.yaml` per `.tas/rules/common/project-status.md` — add entry to `adrs`.
-
-### UPDATE mode ($ARGUMENTS is ADR ID, e.g., "ADR-001"):
-4. Need context from current ADR file
-5. Ask user what needs changing (update status, add consequences, supersede...)
-6. Update file, add changelog
-7. If supersede: update old ADR status to "Superseded by ADR-{NNN}"
-8. Update `project-status.yaml` per `.tas/rules/common/project-status.md` — update `adrs.{ADR_ID}.status`.
-
-## Principles
-- ADR must have: Context, Decision, Rationale, Consequences, Alternatives Considered
-- Status: Proposed | Accepted | Deprecated | Superseded
-- Each ADR is independent, self-contained with enough context to understand
-- Link to related ADRs if any (Supersedes, Related to)
-- Mermaid diagram rules: :::mermaid wrapper, no () in node labels
-
-## Final Step — Token Log
-
-Follow `.tas/rules/common/token-logging.md`: write AI Usage Log to working ADR file.
+---
+model: opus
+---
+
+# /tas-adr $ARGUMENTS
+
+Role: SE - Software Engineer
+Create or update Architecture Decision Record.
+
+## Actions
+1. Need context from .tas/templates/ADR.md
+2. Scan docs/adr/ to identify existing ADRs
+3. Determine mode based on $ARGUMENTS:
+
+### CREATE mode ($ARGUMENTS is new title, e.g., "Use CQRS for Order Service"):
+4. Determine next sequence number (ADR-001, ADR-002...)
+5. If docs/sad.md exists, need context from SAD to ensure ADR consistency
+6. Create file docs/adr/ADR-{NNN}-{slug}.md
+7. Update `project-status.yaml` per `.tas/rules/common/project-status.md` — add entry to `adrs`.
+
+### UPDATE mode ($ARGUMENTS is ADR ID, e.g., "ADR-001"):
+4. Need context from current ADR file
+5. Ask user what needs changing (update status, add consequences, supersede...)
+6. Update file, add changelog
+7. If supersede: update old ADR status to "Superseded by ADR-{NNN}"
+8. Update `project-status.yaml` per `.tas/rules/common/project-status.md` — update `adrs.{ADR_ID}.status`.
+
+## Principles
+- ADR must have: Context, Decision, Rationale, Consequences, Alternatives Considered
+- Status: Proposed | Accepted | Deprecated | Superseded
+- Each ADR is independent, self-contained with enough context to understand
+- Link to related ADRs if any (Supersedes, Related to)
+- Mermaid diagram rules: :::mermaid wrapper, no () in node labels
+
+## Final Step — Token Log
+
+Follow `.tas/rules/common/token-logging.md`: write AI Usage Log to working ADR file.

package/.tas/commands/tas-apitest-plan.md

@@ -1,173 +1,177 @@
-# /tas-apitest-plan $ARGUMENTS
-
-Role: SE - Software Engineer
-Generate API Test Specification (Markdown) from API Spec (OpenAPI 3.0, Markdown, YAML) or analyze API code.
-
-## Always / Ask / Never
-
-| | Action |
-|---|---|
-| **Always** | Read entire spec or analyze code before creating test spec |
-| **Always** | Organize test cases by API version — each version separate section |
-| **Always** | Append-only: don't modify sections in existing old version |
-| **Always** | Coverage matrix: each endpoint needs ≥1 happy path + ≥1 error path |
-| **Always** | Read `.tas/rules/csharp/api-testing.md` for conventions |
-| **Ask** | When spec unclear about expected response schema or business rule |
-| **Never** | Use version folder/syntax in test spec file (use section headers instead) |
-| **Never** | Skip error path — each endpoint needs cover validation errors |
-
-## Actions
-
-### Step 1 — Locate Inputs
-
-`$ARGUMENTS` is path to:
-- API Spec file (OpenAPI 3.0 JSON/YAML, Markdown)
-- Or Story ID — glob find `docs/epics/**/Story-{ID}*.md`
-- Or path to API code project to analyze
-
-If not provided → ask user:
-```
-Enter input for /tas-apitest-plan:
-1. Path to API Spec file (OpenAPI/Markdown/YAML)
-2. Story ID (to find spec link in Story)
-3. Path to API code to auto-analyze
-```
-
-### Step 2 — Detect Existing Test Spec
-
-Glob find `docs/tests/API-Test-Spec-*.md`.
-
-- **Found**: Read file, detect existing versions (find section headers `## v{N}`)
-- **Not found**: Create new with version v1
-
-### Step 3 — Parse Input
-
-**If API Spec file:**
-- Read and parse OpenAPI/Markdown/YAML
-- Collect for each endpoint:
-  - HTTP method + path, path/query params, request body schema
-  - Response schemas per status code
-  - Auth requirement, description/summary
-  - Tags to group endpoints
-
-**If Story:**
-- Read Story to find spec link in `## Technical Plan` or `## Acceptance Criteria`
-- Parse spec as above
-- Add AC mapping to test spec
-
-**If code path:**
-- Glob find controller/handler files (`.cs`, `.ts`, `.py` per stack)
-- Analyze attributes/routes to detect endpoints
-- Extract DTO classes to know request/response schema
-- Ask user confirm if detection unclear
-
-### Step 4 — Detect API Version
-
-Prioritize in order:
-1. `info.version` in OpenAPI
-2. Prefix in URL path (v1/, v2/)
-3. Ask user
-
-Version format: `v1`, `v2` (no dot).
-
-### Step 5 — Determine Output Path
-
-Output: `docs/tests/API-Test-Spec-{slug}.md`
-
-**Slug generation:**
-- From `api_name` in spec → lowercase, replace spaces with dashes
-- Or ask user for short slug (e.g., `users`, `orders`, `products`)
-
-### Step 6 — Determine Update Mode
-
-If spec file exists and version already exists:
-- **Append mode** (default): add new test cases to end of current version section
-- Ask user if want new version (v2, v3...):
-
-```
-Spec file already exists with version {current}. You want:
-1. Append test cases to version {current} (default)
-2. Create new version (v{next}) for test cases
-```
-
-### Step 7 — Generate Test Spec
-
-Read template `.tas/templates/API-Test-Spec.md` for structure.
-
-**Analyze endpoints to create coverage matrix:**
-
-For each endpoint, generate test cases for:
-1. **Happy path** (2xx) — always have
-2. **Unauthorized** (401) — if endpoint requires auth
-3. **Forbidden** (403) — if has RBAC/ownership check
-4. **Not found** (404) — if has path param
-5. **Validation error** (400/422) — if has required fields or business rules
-6. **Business rules** — from Story ACs or spec descriptions
-
-**Coverage matrix format:**
-```
-| Endpoint | Happy Path | 401 Unauthorized | 403 Forbidden | 404 Not Found | 400/422 Validation | Business Rule |
-|----------|:---------:|:----------------:|:-------------:|:-------------:|:------------------:|:-------------:|
-| GET /api/users | ✓ | ✓ | | | | |
-| POST /api/users | ✓ | ✓ | | | ✓ | |
-```
-
-**Test case detail format:**
-```
-#### TC-XXX: {Title} — {Modifier}
-- **Endpoint**: `{METHOD} {path}`
-- **Auth**: Required/Not Required
-- **Preconditions**:
-  - {List preconditions}
-- **Request Query/Path/Body**:
-  - {Request details}
-- **Expected Response**:
-  - Status: {code}
-  - Body: {schema}
-- **Assertions**:
-  - {List assertions}
-- **AC Reference**: AC-{N} (if any)
-- **Test Method Name**: `{Method}_{Resource}_Returns{Status}_When{Condition}`
-```
-
-### Step 8 — Write Test Spec File
-
-**File doesn't exist:** Create new from template.
-
-**File exists (append mode):**
-- Read current file
-- Find section `## v{N}` being worked on
-- Append new test cases to end of section before `## Version History` or `## Changelog`
-- Preserve all old content
-
-### Step 9 — Summary
-
-Display:
-1. Output file path
-2. Number of endpoints detected
-3. Number of test cases generated
-4. Coverage matrix
-5. Next steps:
-   - Review test spec file
-   - Run `/tas-apitest docs/tests/API-Test-Spec-{slug}.md` to generate code
-
-```
-## API Test Spec Generated
-
-**Output**: `docs/tests/API-Test-Spec-{slug}.md`
-**Version**: v{N}
-**Endpoints**: {N}
-**Test Cases**: {N}
-
-### Coverage Matrix
-[Print coverage matrix]
-
-### Next Steps
-1. Review test spec: `docs/tests/API-Test-Spec-{slug}.md`
-2. Generate test code: `/tas-apitest docs/tests/API-Test-Spec-{slug}.md`
-3. Run tests: `dotnet test tests/ApiTests/`
-```
-
-## Final Step — Token Log
-
-Follow `.tas/rules/common/token-logging.md`: write AI Usage Log to test spec file.
+---
+model: sonnet
+---
+
+# /tas-apitest-plan $ARGUMENTS
+
+Role: SE - Software Engineer
+Generate API Test Specification (Markdown) from API Spec (OpenAPI 3.0, Markdown, YAML) or analyze API code.
+
+## Always / Ask / Never
+
+| | Action |
+|---|---|
+| **Always** | Read entire spec or analyze code before creating test spec |
+| **Always** | Organize test cases by API version — each version separate section |
+| **Always** | Append-only: don't modify sections in existing old version |
+| **Always** | Coverage matrix: each endpoint needs ≥1 happy path + ≥1 error path |
+| **Always** | Read `.tas/rules/csharp/api-testing.md` for conventions |
+| **Ask** | When spec unclear about expected response schema or business rule |
+| **Never** | Use version folder/syntax in test spec file (use section headers instead) |
+| **Never** | Skip error path — each endpoint needs cover validation errors |
+
+## Actions
+
+### Step 1 — Locate Inputs
+
+`$ARGUMENTS` is path to:
+- API Spec file (OpenAPI 3.0 JSON/YAML, Markdown)
+- Or Feature ID — glob find `docs/features/{CODE}-Feature-{ID}-*/{CODE}-Feature-{ID}-*.md`
+- Or path to API code project to analyze
+
+If not provided → ask user:
+```
+Enter input for /tas-apitest-plan:
+1. Path to API Spec file (OpenAPI/Markdown/YAML)
+2. Feature ID (to find spec link in Feature/Feature-Technical)
+3. Path to API code to auto-analyze
+```
+
+### Step 2 — Detect Existing Test Spec
+
+Glob find `docs/tests/API-Test-Spec-*.md`.
+
+- **Found**: Read file, detect existing versions (find section headers `## v{N}`)
+- **Not found**: Create new with version v1
+
+### Step 3 — Parse Input
+
+**If API Spec file:**
+- Read and parse OpenAPI/Markdown/YAML
+- Collect for each endpoint:
+  - HTTP method + path, path/query params, request body schema
+  - Response schemas per status code
+  - Auth requirement, description/summary
+  - Tags to group endpoints
+
+**If Feature:**
+- Read Feature file (business AC) + Feature-Technical file (Logic Flow / Data Flow / API spec)
+- Parse spec as above
+- Add AC mapping to test spec (use `{PROJECT}_F{FEATURE}_AC{N}_*` ID scheme)
+
+**If code path:**
+- Glob find controller/handler files (`.cs`, `.ts`, `.py` per stack)
+- Analyze attributes/routes to detect endpoints
+- Extract DTO classes to know request/response schema
+- Ask user confirm if detection unclear
+
+### Step 4 — Detect API Version
+
+Prioritize in order:
+1. `info.version` in OpenAPI
+2. Prefix in URL path (v1/, v2/)
+3. Ask user
+
+Version format: `v1`, `v2` (no dot).
+
+### Step 5 — Determine Output Path
+
+Output: `docs/tests/API-Test-Spec-{slug}.md`
+
+**Slug generation:**
+- From `api_name` in spec → lowercase, replace spaces with dashes
+- Or ask user for short slug (e.g., `users`, `orders`, `products`)
+
+### Step 6 — Determine Update Mode
+
+If spec file exists and version already exists:
+- **Append mode** (default): add new test cases to end of current version section
+- Ask user if want new version (v2, v3...):
+
+```
+Spec file already exists with version {current}. You want:
+1. Append test cases to version {current} (default)
+2. Create new version (v{next}) for test cases
+```
+
+### Step 7 — Generate Test Spec
+
+Read template `.tas/templates/API-Test-Spec.md` for structure.
+
+**Analyze endpoints to create coverage matrix:**
+
+For each endpoint, generate test cases for:
+1. **Happy path** (2xx) — always have
+2. **Unauthorized** (401) — if endpoint requires auth
+3. **Forbidden** (403) — if has RBAC/ownership check
+4. **Not found** (404) — if has path param
+5. **Validation error** (400/422) — if has required fields or business rules
+6. **Business rules** — from Feature ACs or spec descriptions
+
+**Coverage matrix format:**
+```
+| Endpoint | Happy Path | 401 Unauthorized | 403 Forbidden | 404 Not Found | 400/422 Validation | Business Rule |
+|----------|:---------:|:----------------:|:-------------:|:-------------:|:------------------:|:-------------:|
+| GET /api/users | ✓ | ✓ | | | | |
+| POST /api/users | ✓ | ✓ | | | ✓ | |
+```
+
+**Test case detail format:**
+```
+#### TC-XXX: {Title} — {Modifier}
+- **Endpoint**: `{METHOD} {path}`
+- **Auth**: Required/Not Required
+- **Preconditions**:
+  - {List preconditions}
+- **Request Query/Path/Body**:
+  - {Request details}
+- **Expected Response**:
+  - Status: {code}
+  - Body: {schema}
+- **Assertions**:
+  - {List assertions}
+- **AC Reference**: AC-{N} (if any)
+- **Test Method Name**: `{Method}_{Resource}_Returns{Status}_When{Condition}`
+```
+
+### Step 8 — Write Test Spec File
+
+**File doesn't exist:** Create new from template.
+
+**File exists (append mode):**
+- Read current file
+- Find section `## v{N}` being worked on
+- Append new test cases to end of section before `## Version History` or `## Changelog`
+- Preserve all old content
+
+### Step 9 — Summary
+
+Display:
+1. Output file path
+2. Number of endpoints detected
+3. Number of test cases generated
+4. Coverage matrix
+5. Next steps:
+   - Review test spec file
+   - Run `/tas-apitest docs/tests/API-Test-Spec-{slug}.md` to generate code
+
+```
+## API Test Spec Generated
+
+**Output**: `docs/tests/API-Test-Spec-{slug}.md`
+**Version**: v{N}
+**Endpoints**: {N}
+**Test Cases**: {N}
+
+### Coverage Matrix
+[Print coverage matrix]
+
+### Next Steps
+1. Review test spec: `docs/tests/API-Test-Spec-{slug}.md`
+2. Generate test code: `/tas-apitest docs/tests/API-Test-Spec-{slug}.md`
+3. Run tests: `dotnet test tests/ApiTests/`
+```
+
+## Final Step — Token Log
+
+Follow `.tas/rules/common/token-logging.md`: write AI Usage Log to test spec file.