@torus-engineering/tas-kit 1.13.0 → 2.1.0

package/.tas/commands/tas-security.md

@@ -1,87 +1,91 @@
-# /tas-security $ARGUMENTS
-
-Check codebase security, save report to docs/security-report.md.
-
-## Stack Detection
-Read `.tas/rules/common/stack-detection.md`.
-
-## Actions
-
-### Step 1 — Determine scope
-`$ARGUMENTS` can be:
-- File path or directory → scan specified scope only
-- Empty → scan entire codebase
-- `--staged` → only scan staged files (like pre-commit hook), fast + used to self-test before commit
-
-With `--staged`: get list from `git diff --cached --name-only --diff-filter=ACM` and only review those files. Use same regex patterns as `.tas/hooks/security-scan.js` then supplement with deep review by agents below.
-
-Read `.tas/rules/common/security.md` for general checks. If stack identified, also read `.tas/rules/[stack]/security.md` for stack-specific items.
-
-### Step 2 — Parallel Security Scan
-
-Launch agents SIMULTANEOUSLY based on stack:
-
-**Agent 1 — `security-reviewer`** (always run):
-> Security audit [scope].
-> Read `.tas/rules/common/security.md`.
-> If stack identified, also read `.tas/rules/[stack]/security.md`.
-> Check OWASP Top 10: injection, broken auth, XSS, IDOR, security misconfiguration,
-> sensitive data exposure, insecure deserialization, vulnerable components, logging/monitoring.
-> Also check: hardcoded secrets, CORS config, anti-forgery tokens, rate limiting.
-> Format: findings by Critical / High / Medium / Low with file:line and specific remediation.
-> Each finding has: status = Open.
-
-**Agent 2 — `database-reviewer`** (only when `db_agent = database-reviewer`):
-> Database security review [scope].
-> Focus: parameterized queries vs string concatenation, ORM raw query usage,
-> sensitive data stored in plaintext, missing field-level encryption, excessive permissions.
-> Format: findings by Critical / High / Medium / Low with file:line and remediation.
-
-**Agent 3 — `aws-reviewer`** (only when `infra_agent = aws-reviewer`):
-> AWS infrastructure security review [scope].
-> Focus: IAM overpermission, S3 public access, secrets in env/config/code,
-> Lambda environment variables, API Gateway auth, VPC security groups.
-> Format: findings by Critical / High / Medium / Low with file:line and remediation.
-
-Wait for ALL agents to complete.
-
-### Step 3 — Synthesize and save report
-
-Combine findings from all agents, deduplicate (same file:line → merge), sort by severity.
-
-Check `docs/security-report.md`:
-- **Doesn't exist**: create new per template `.tas/templates/Security-Report.md`
-- **Exists**: append new report, update old findings status if fixed
-
-Report content includes:
-- Scan date, scope, stack
-- Findings by Critical / High / Medium / Low
-- Each finding: file:line, description, remediation, status (Open / Fixed / Accepted Risk)
-- Summary: total findings per severity, fixed vs open counts
-
-### Step 4 — Update project-status.yaml
-
-```yaml
-artifacts:
-  security_report:
-    file: docs/security-report.md
-    status: [Critical findings present | Clean]
-    last_updated: [today's date]
-```
-
-### Step 5 — Next actions
-
-If **Critical findings**:
-→ List clearly, require fix immediately before deploying to any environment.
-
-If **High findings**:
-→ List, recommend fixing before merging to main.
-
-If only **Medium/Low**:
-→ Summarize, suggest fixing in priority order.
-
-## Principles
-- Classification: Critical / High / Medium / Low
-- Each finding must have specific recommended fix
-- Finding has status: Open | In Progress | Fixed | Accepted Risk
-- DO NOT hardcode fix — propose remediation pattern, don't write replacement code
+---
+model: opus
+---
+
+# /tas-security $ARGUMENTS
+
+Check codebase security, save report to docs/security-report.md.
+
+## Stack Detection
+Read `.tas/rules/common/stack-detection.md`.
+
+## Actions
+
+### Step 1 — Determine scope
+`$ARGUMENTS` can be:
+- File path or directory → scan specified scope only
+- Empty → scan entire codebase
+- `--staged` → only scan staged files (like pre-commit hook), fast + used to self-test before commit
+
+With `--staged`: get list from `git diff --cached --name-only --diff-filter=ACM` and only review those files. Use same regex patterns as `.tas/hooks/security-scan.js` then supplement with deep review by agents below.
+
+Read `.tas/rules/common/security.md` for general checks. If stack identified, also read `.tas/rules/[stack]/security.md` for stack-specific items.
+
+### Step 2 — Parallel Security Scan
+
+Launch agents SIMULTANEOUSLY based on stack:
+
+**Agent 1 — `security-reviewer`** (always run):
+> Security audit [scope].
+> Read `.tas/rules/common/security.md`.
+> If stack identified, also read `.tas/rules/[stack]/security.md`.
+> Check OWASP Top 10: injection, broken auth, XSS, IDOR, security misconfiguration,
+> sensitive data exposure, insecure deserialization, vulnerable components, logging/monitoring.
+> Also check: hardcoded secrets, CORS config, anti-forgery tokens, rate limiting.
+> Format: findings by Critical / High / Medium / Low with file:line and specific remediation.
+> Each finding has: status = Open.
+
+**Agent 2 — `database-reviewer`** (only when `db_agent = database-reviewer`):
+> Database security review [scope].
+> Focus: parameterized queries vs string concatenation, ORM raw query usage,
+> sensitive data stored in plaintext, missing field-level encryption, excessive permissions.
+> Format: findings by Critical / High / Medium / Low with file:line and remediation.
+
+**Agent 3 — `aws-reviewer`** (only when `infra_agent = aws-reviewer`):
+> AWS infrastructure security review [scope].
+> Focus: IAM overpermission, S3 public access, secrets in env/config/code,
+> Lambda environment variables, API Gateway auth, VPC security groups.
+> Format: findings by Critical / High / Medium / Low with file:line and remediation.
+
+Wait for ALL agents to complete.
+
+### Step 3 — Synthesize and save report
+
+Combine findings from all agents, deduplicate (same file:line → merge), sort by severity.
+
+Check `docs/security-report.md`:
+- **Doesn't exist**: create new per template `.tas/templates/Security-Report.md`
+- **Exists**: append new report, update old findings status if fixed
+
+Report content includes:
+- Scan date, scope, stack
+- Findings by Critical / High / Medium / Low
+- Each finding: file:line, description, remediation, status (Open / Fixed / Accepted Risk)
+- Summary: total findings per severity, fixed vs open counts
+
+### Step 4 — Update project-status.yaml
+
+```yaml
+artifacts:
+  security_report:
+    file: docs/security-report.md
+    status: [Critical findings present | Clean]
+    last_updated: [today's date]
+```
+
+### Step 5 — Next actions
+
+If **Critical findings**:
+→ List clearly, require fix immediately before deploying to any environment.
+
+If **High findings**:
+→ List, recommend fixing before merging to main.
+
+If only **Medium/Low**:
+→ Summarize, suggest fixing in priority order.
+
+## Principles
+- Classification: Critical / High / Medium / Low
+- Each finding must have specific recommended fix
+- Finding has status: Open | In Progress | Fixed | Accepted Risk
+- DO NOT hardcode fix — propose remediation pattern, don't write replacement code

package/.tas/commands/tas-spec.md

@@ -1,50 +1,54 @@
-# /tas-spec $ARGUMENTS
-
-Create lightweight spec before coding — for solo dev, prototype, spike, internal tool.
-Differs from `/tas-fix`: has spec document, suitable for tasks > 2 hours or needs AC tracking.
-
-## Steps
-
-### 1 — Gather information
-`$ARGUMENTS` is task description. If not clear enough, ask max 3 questions:
-- **Goal**: What to build? What problem to solve?
-- **AC**: What does done look like? (2-5 specific, testable criteria)
-- **Constraints**: Tech constraints, out of scope?
-
-Don't ask if $ARGUMENTS is already clear enough.
-
-### 2 — Create SPEC.md
-Create file `SPEC.md` at project root:
-
-```markdown
-# {Title}
-> {one-line summary}
-
-**Status:** Draft | **Date:** {today}
-
-## Goal
-{Problem to solve — not solution}
-
-## Acceptance Criteria
-- [ ] {Given/When/Then or testable statement}
-- [ ] ...
-
-## Out of Scope
-- {What won't be done}
-
-## Constraints
-{Tech constraints, patterns to follow — omit if none}
-
-## Open Questions
-{Unanswered questions — omit if none}
-```
-
-### 3 — Next step
-> "SPEC.md created.
-> - Plan in detail: `/tas-plan SPEC.md`
-> - Code immediately: `/tas-dev` (requires `require_plan: false` in tas.yaml)"
-
-## Principles
-- SPEC.md is single source of truth — don't create additional files
-- Keep short: target < 1 page
-- If AC > 8 items or task > 1 day → suggest using `/tas-story` instead
+---
+model: sonnet
+---
+
+# /tas-spec $ARGUMENTS
+
+Create lightweight spec before coding — for solo dev, prototype, spike, internal tool.
+Differs from `/tas-fix`: has spec document, suitable for tasks > 2 hours or needs AC tracking.
+
+## Steps
+
+### 1 — Gather information
+`$ARGUMENTS` is task description. If not clear enough, ask max 3 questions:
+- **Goal**: What to build? What problem to solve?
+- **AC**: What does done look like? (2-5 specific, testable criteria)
+- **Constraints**: Tech constraints, out of scope?
+
+Don't ask if $ARGUMENTS is already clear enough.
+
+### 2 — Create SPEC.md
+Create file `SPEC.md` at project root:
+
+```markdown
+# {Title}
+> {one-line summary}
+
+**Status:** Draft | **Date:** {today}
+
+## Goal
+{Problem to solve — not solution}
+
+## Acceptance Criteria
+- [ ] {Given/When/Then or testable statement}
+- [ ] ...
+
+## Out of Scope
+- {What won't be done}
+
+## Constraints
+{Tech constraints, patterns to follow — omit if none}
+
+## Open Questions
+{Unanswered questions — omit if none}
+```
+
+### 3 — Next step
+> "SPEC.md created.
+> - Plan in detail: `/tas-plan SPEC.md`
+> - Code immediately: `/tas-dev` (requires `require_plan: false` in tas.yaml)"
+
+## Principles
+- SPEC.md is single source of truth — don't create additional files
+- Keep short: target < 1 page
+- If AC > 8 items or task > 1 day → suggest using `/tas-feature` instead

package/.tas/commands/tas-status.md

@@ -1,16 +1,25 @@
-# /tas-status
-
-Check current status of TAS project.
-
-## Actions
-1. Need context from root/project-status.yaml (ONLY read this file, DO NOT scan docs/ directory)
-2. Need context from root/tas.yaml to know workflow config
-3. Based on project-status.yaml, summarize:
-   - Number of artifacts created and their status
-   - Number of epics/features/stories by each status
-   - Current phase based on aggregated status
-4. Display phase status table and story details by status.
-
-## Notes
-- This is read-only command, does not change anything
-- If project-status.yaml seems out of sync, user can run /tas-init to rescan and sync
+---
+model: haiku
+---
+
+# /tas-status
+
+Check current status of TAS project.
+
+## Actions
+1. Read `root/project-status.yaml` (ONLY this file, DO NOT scan `docs/`)
+2. Read `root/tas.yaml` for workflow config
+3. Summarize from `project-status.yaml`:
+   - Number of artifacts created and their status (PRD, SAD, Design Spec...)
+   - Number of Features by each status (`New`, `In Design`, `In Development`, `Done`, `Removed`)
+   - Number of Bugs by status
+   - Current phase based on aggregated status
+4. Display:
+   - Phase status table
+   - Features grouped by status (with `stack:` shown beside each)
+   - Plan readiness: count Features with `plan_status: completed` vs `pending`
+
+## Notes
+- Read-only command, does not change anything
+- If `project-status.yaml` seems out of sync, run `/tas-init` to rescan and sync
+- Schema is flat — `features.{FEATURE_ID}` directly under root (no `epics.*.features.*.stories.*` nesting)

package/.tas/project-status-example.yaml

@@ -14,4 +14,6 @@ adrs: {}
 
 bugs: {}
 
-epics: {}
+# Flat features map (Epic + Story removed in kit v3)
+# Each Feature is a self-contained business flow per stack (app/web/service/integration).
+features: {}

package/.tas/rules/ado-integration.md

@@ -1,65 +1,67 @@
-# ADO Integration Rules
-
-Bidirectional sync between .md files in repo and work items on Azure DevOps.
-ADO sync is **intentional operation** — not automatic after each file edit.
-
-## When to Apply
-
-- User runs `/ado-create`, `/ado-update`, `/ado-status`, `/ado-get`, `/ado-delete`
-- DO NOT apply when: user only edits .md file normally without mentioning ADO
-
-## Always / Ask / Never
-
-| | Action |
-|---|---|
-| **Always** | Read `tas.yaml` and check `ado.enabled` before any operation |
-| **Always** | Display ADO ID and URL after each successful create/update |
-| **Always** | Update frontmatter `ado_id`, `ado_state`, `last_ado_sync` in .md file after sync |
-| **Ask** | When syncing multiple items at once — confirm list before running |
-| **Ask** | When detecting conflict between .md file and ADO item (which is source of truth?) |
-| **Ask** | When deleting work item — this is irreversible operation |
-| **Never** | Auto-sync whenever .md file is edited (too aggressive, creates noise) |
-| **Never** | Delete ADO item without clear user confirmation |
-| **Never** | Create duplicate work item if `ado_id` already exists in frontmatter |
-
-## First Step — Check ADO Enabled
-
-Before performing any operation, read `tas.yaml` at root and check `ado.enabled`:
-- If `ado.enabled: false` or field doesn't exist: notify "ADO integration is disabled in tas.yaml (`ado.enabled: false`). Enable if project uses ADO." then stop.
-- If `ado.enabled: true`: continue normally.
-
-## Prerequisites
-
-- Azure CLI + azure-devops extension: `az extension add --name azure-devops --upgrade`
-- Python 3.8+ with pyyaml: `pip install pyyaml`
-- PAT in .env file: `AzureDevops_Personal_AccessToken=your-pat-here`
-
-## Commands
-
-All ADO commands run via: `python .tas/tools/tas-ado.py <command> [args]`
-
-Or use slash commands:
-- `/ado-create <type> <temp-id> [--parent-id <id>]`
-- `/ado-get <ado-id>`
-- `/ado-update <type> <ado-id> [--assign <name>] [--status <state>]`
-- `/ado-status <ado-id> --status <state>`
-- `/ado-delete <type> <ado-id>`
-
-## File Convention
-
-- Filename: `{type}-{ado_id}-{slug-title}.md`
-- Each file has YAML frontmatter: `ado_id`, `ado_type`, `ado_state`, `last_ado_sync`
-- .md file is single source of truth, sync to ADO when needed
-
-## Red Flags
-
-- File has `ado_id` but state in file differs from ADO → confirm with user before overwriting
-- PAT expired → guide to rotate, don't log token to stdout
-- `ado.enabled: true` but project hasn't set up Azure CLI → check prerequisites first
-
-## Anti-Rationalization
-
-| Rationalization | Counter |
-|---|---|
-| "Auto-sync is more convenient, no need to remember" | Hook auto-sync causes unintended pushes when editing draft — sync must be intentional |
-| "Delete is OK, I know what I'm doing" | ADO delete has no undo — always confirm, even if user seems confident |
+# ADO Integration Rules
+
+Bidirectional sync between .md files in repo and work items on Azure DevOps.
+ADO sync is **intentional operation** — not automatic after each file edit.
+
+> **Kit v3:** Only `feature` and `bug` types are supported by `/ado-*` commands. Epic and User Story were removed because TAS uses Feature as the single business unit. Legacy ADO Epic / User Story items pulled via `/ado-get` are saved as local `feature-*.md` files (see `tools/tas-ado.py` `TYPE_REVERSE`).
+
+## When to Apply
+
+- User runs `/ado-create`, `/ado-update`, `/ado-status`, `/ado-get`, `/ado-delete`
+- DO NOT apply when: user only edits .md file normally without mentioning ADO
+
+## Always / Ask / Never
+
+| | Action |
+|---|---|
+| **Always** | Read `tas.yaml` and check `ado.enabled` before any operation |
+| **Always** | Display ADO ID and URL after each successful create/update |
+| **Always** | Update frontmatter `ado_id`, `ado_state`, `last_ado_sync` in .md file after sync |
+| **Ask** | When syncing multiple items at once — confirm list before running |
+| **Ask** | When detecting conflict between .md file and ADO item (which is source of truth?) |
+| **Ask** | When deleting work item — this is irreversible operation |
+| **Never** | Auto-sync whenever .md file is edited (too aggressive, creates noise) |
+| **Never** | Delete ADO item without clear user confirmation |
+| **Never** | Create duplicate work item if `ado_id` already exists in frontmatter |
+
+## First Step — Check ADO Enabled
+
+Before performing any operation, read `tas.yaml` at root and check `ado.enabled`:
+- If `ado.enabled: false` or field doesn't exist: notify "ADO integration is disabled in tas.yaml (`ado.enabled: false`). Enable if project uses ADO." then stop.
+- If `ado.enabled: true`: continue normally.
+
+## Prerequisites
+
+- Azure CLI + azure-devops extension: `az extension add --name azure-devops --upgrade`
+- Python 3.8+ with pyyaml: `pip install pyyaml`
+- PAT in .env file: `AzureDevops_Personal_AccessToken=your-pat-here`
+
+## Commands
+
+All ADO commands run via: `python .tas/tools/tas-ado.py <command> [args]`
+
+Or use slash commands:
+- `/ado-create <type> <temp-id> [--parent-id <id>]`
+- `/ado-get <ado-id>`
+- `/ado-update <type> <ado-id> [--assign <name>] [--status <state>]`
+- `/ado-status <ado-id> --status <state>`
+- `/ado-delete <type> <ado-id>`
+
+## File Convention
+
+- Filename: `{type}-{ado_id}-{slug-title}.md`
+- Each file has YAML frontmatter: `ado_id`, `ado_type`, `ado_state`, `last_ado_sync`
+- .md file is single source of truth, sync to ADO when needed
+
+## Red Flags
+
+- File has `ado_id` but state in file differs from ADO → confirm with user before overwriting
+- PAT expired → guide to rotate, don't log token to stdout
+- `ado.enabled: true` but project hasn't set up Azure CLI → check prerequisites first
+
+## Anti-Rationalization
+
+| Rationalization | Counter |
+|---|---|
+| "Auto-sync is more convenient, no need to remember" | Hook auto-sync causes unintended pushes when editing draft — sync must be intentional |
+| "Delete is OK, I know what I'm doing" | ADO delete has no undo — always confirm, even if user seems confident |