@torus-engineering/tas-kit 1.14.0 → 2.1.0

package/.tas/commands/tas-e2e.md

@@ -1,102 +1,289 @@
-# /tas-e2e $ARGUMENTS
-
-Role: QA / PE
-Generate E2E test scenario documents from an Epic or user flow description.
-
-## IMPORTANT - Layer 3: E2E Testing
-- E2E tests verify ENTIRE flow linking multiple features/stories
-- E2E scenario MUST reference FT IDs from Layer 2 (Functional Tests)
-- E2E scripts (created by /tas-e2e-mobile or /tas-e2e-web) will REUSE helpers from Layer 2
-- Output is markdown scenario file, NOT test code
-
-## Actions
-
-### Step 1: Determine Input
-$ARGUMENTS can be:
-- **Epic ID** (e.g., "Epic-002", "AL-Epic-002-authentication") → generate scenarios from all features/stories in epic
-- **Flow description** (e.g., "user registration to first scan") → generate cross-epic scenario
-
-If no $ARGUMENTS: list existing Epics and ask user to choose.
-
-### Step 2: Gather Context
-
-#### If Epic ID:
-1. Read Epic file and all Feature files within
-2. Read all Story files of those Features
-3. Find all `Func-Test-*.md` files to get FT IDs
-
-#### If Flow Description:
-1. Search across `docs/epics/` to find related Features/Stories
-2. Identify related Epics (cross-epic scenario)
-3. Collect FT IDs from Func-Test-*.md files
-
-### Step 3: Read template
-Read `.tas/templates/E2E-Scenario.md`
-Read `root/tas.yaml` to get project code
-
-### Step 4: Generate Scenario
-
-#### Naming Convention:
-- **Single-epic**: `{PROJECT}_E{EPIC}_E2E_{NNN}_{MODIFIER}`
-  - Example: `AL_E002_E2E_001_H`
-- **Cross-epic**: `{PROJECT}_XEPIC_E2E_{NNN}_{MODIFIER}`
-  - Example: `AL_XEPIC_E2E_001_H`
-
-#### Scenario Steps Table:
-Each step MUST have "Builds on FT IDs" column to reference Layer 2:
-
-```markdown
-| Step | Screen/Page | Action | Expected Result | Builds on FT IDs |
-|------|-------------|--------|-----------------|-------------------|
-| 1 | Login Screen | User logs in | Home screen shown | AL_E002_F002_S001_FT_001_H |
-| 2 | Home Screen | View allergen list | List displayed | AL_E003_F001_S001_FT_001_H |
-```
-
-If step has NO FT reference → write "-" (new logic, no func test yet)
-
-#### Generated content:
-1. Flow Overview (narrative description)
-2. Scenario Steps table
-3. Step Details (detail each step)
-4. Alternate Flows (if any)
-5. Error Flows (if any)
-6. Test Data per environment
-7. Prerequisites checklist
-8. Success Criteria
-9. FT Reuse Map (map step → FT ID → helper function)
-
-### Step 5: Output File
-- **Single-epic**: `docs/epics/{epic-dir}/E2E-Scenario-{NNN}-{slug}.md`
-- **Cross-epic**: `docs/e2e-scenarios/E2E-Scenario-{NNN}-{slug}.md`
-
-Auto-create `docs/e2e-scenarios/` directory if not exists.
-
-### Step 6: Prompting
-After generating, ask user:
-- "Any alternate flows to cover?"
-- "Any error scenarios to add?"
-- "Test data for all environments sufficient?"
-- "Need to test on both mobile and web?"
-
-## FT Reuse Map
-Each scenario file has "FT Reuse Map" section to:
-- Map scenario step → FT ID → source file → helper function
-- /tas-e2e-mobile and /tas-e2e-web read this section to import helpers from Layer 2
-
-```markdown
-## FT Reuse Map
-| Step | FT ID | Source File | Helper Function |
-|------|-------|-------------|-----------------|
-| 1 | AL_E002_F002_S001_FT_001_H | features/auth/login/helpers.ts | fillLoginForm() |
-| 2 | AL_E003_F001_S001_FT_001_H | features/home/allergens/helpers.ts | viewAllergenList() |
-```
-
-## Status Flow
-Draft → Ready → Implemented → Verified
-
-## Principles
-- Output is MARKDOWN scenario, NOT test code
-- Test code created by /tas-e2e-mobile or /tas-e2e-web
-- Each step SHOULD reference FT IDs when possible (to reuse, not rewrite)
-- Scenario must be testable: has preconditions, test data, clear success criteria
-- Cross-epic scenarios use XEPIC prefix instead of Epic number
+# /tas-e2e $FEATURE_IDS $FLOW_DESCRIPTION
+
+You are a Senior QA Engineer creating End-to-End (E2E) Test Specifications by combining multiple Functional Test Specifications into complete user journey workflows.
+
+## Purpose
+
+Generate E2E test scenarios that validate complete user journeys across multiple features, simulating real-world workflows and validating integration points between systems.
+
+## When to Use
+
+- Run after Functional Test Specifications are complete
+- Run when you need to validate cross-feature workflows
+- Run before implementing E2E automation
+- Run when critical user journeys need validation
+
+## Prerequisites
+
+1. One or more Functional Test Specifications exist (`*-FuncTest-Spec.md`)
+2. Feature documents exist for context
+3. Template exists at `.tas/templates/E2E-Test-Spec.md`
+4. `tas.yaml` exists at project root
+
+## Step-by-Step Actions
+
+### Step 1: Determine Input Scope
+
+**Input options:**
+1. **$FEATURE_IDS** (comma-separated): E.g., "Feature-001,Feature-005,Feature-012"
+   - Generate E2E scenarios chaining these specific features
+
+2. **$FLOW_DESCRIPTION** (text): E.g., "complete purchase journey from browse to payment"
+   - Search features that match this flow
+   - Generate scenarios based on the described workflow
+
+3. **No arguments:**
+   - Scan directory for `*-FuncTest-Spec.md` files
+   - Group features by business domain
+   - Ask user to select features for the E2E flow
+
+### Step 2: Gather Context Documents
+
+For each feature in the flow:
+
+1. **Read Feature Document:**
+   - File: `*-Feature-*.md`
+   - Extract: Feature ID, Feature Name, Epic ID, Acceptance Criteria
+
+2. **Read Functional Test Spec:**
+   - File: `*-FuncTest-Spec.md`
+   - Extract: All test cases, TC IDs, test types, priorities
+   - Note which test cases are automatable (Autoable=Yes)
+
+3. **Identify User Journey:**
+   - Determine the logical flow between features
+   - Identify entry point (where user starts)
+   - Identify exit point (where user ends)
+   - Map touchpoints between features
+
+### Step 3: Read Template
+
+Read `.tas/templates/E2E-Test-Spec.md` to understand structure.
+
+### Step 4: Design E2E Scenarios
+
+#### A. Identify User Personas
+Determine who performs this journey:
+- Customer/User
+- Admin/Staff
+- Partner/External
+- Multiple personas (complex flows)
+
+#### B. Map Functional TCs to E2E Steps
+
+For each logical step in the user journey:
+1. Find corresponding Functional Test Cases
+2. Group related TCs into E2E steps
+3. Identify integration points between steps
+4. Note data flow dependencies
+
+**Mapping example:**
+```
+E2E Step 1: Browse Products
+└─ Uses: Feature-001 → FT-001_H, FT-002_H
+
+E2E Step 2: Add to Cart
+└─ Uses: Feature-001 → FT-005_H, FT-006_N
+
+E2E Step 3: Checkout
+└─ Uses: Feature-002 → FT-010_H, FT-012_H
+
+E2E Step 4: Payment
+└─ Uses: Feature-003 → FT-020_H, FT-025_NEG
+```
+
+#### C. Generate E2E Test Scenarios
+
+Create 4 types of E2E scenarios:
+
+**1. Happy Path (HP):**
+- Main user journey from start to finish
+- All steps succeed
+- Primary business value achieved
+- At least 1 per flow (P0)
+
+**2. Negative Flows (NEG):**
+- Error scenarios at integration points
+- System failures (payment gateway, email service)
+- Invalid data handling
+- User errors and recovery
+
+**3. Edge Cases (EDGE):**
+- Boundary conditions
+- Concurrent operations
+- Large data volumes
+- Unusual but valid scenarios
+
+**4. Performance Flows (PERF):**
+- Load testing scenarios
+- Response time validation
+- Concurrent user simulation
+
+### Step 5: Fill Template Sections
+
+#### Frontmatter:
+```yaml
+created_date: {YYYY-MM-DD}
+updated_date: {YYYY-MM-DD}
+executor: {User or placeholder}
+reviewer: {Placeholder}
+status: Draft
+epic_id: {From features}
+feature_ids: [Feature-001, Feature-002, ...]
+scenario_id: {E2E_001, E2E_002, ...}
+platform: {web | mobile | backend | cross-stack}
+tags: [e2e, {flow_name}]
+ver: 1.0
+```
+
+#### Section 1: Scenario Overview
+- Scenario Name: {Business Flow Name}
+- Business Value: Why this flow matters
+- User Persona: Who performs it
+- Entry/Exit Points
+- Success Criteria
+
+#### Section 2: Integrated Systems
+- List all systems involved
+- Integration types
+- Failure impacts
+- Prerequisites
+
+#### Section 3: Functional TC Mapping
+- Map E2E steps to Functional TCs
+- Show traceability
+
+#### Section 4: E2E Test Scenarios
+Generate detailed tables for:
+- 4.1 Happy Path E2E Scenarios
+- 4.2 Negative Flow E2E Scenarios
+- 4.3 Edge Case E2E Scenarios
+- 4.4 Performance E2E Scenarios
+
+**Each E2E scenario includes:**
+- E2E Case ID: `{PROJECT}_E2E_{SCENARIO_ID}_{TYPE}_{NUMBER}`
+- User Persona
+- Business Flow
+- Pre-Conditions
+- Cross-Functional Steps (with system/module labels)
+- Expected Final State
+- Priority (P0/P1/P2)
+- Autoable (Yes/None)
+- Traceability to Functional TCs
+
+#### Section 5: Data Flow Validation
+- Critical data points to verify
+- Source systems
+- Expected values
+- Verification methods (SQL queries, API calls)
+
+#### Section 6: Integration Points
+- Critical checkpoints between systems
+- Test methods
+- Success criteria
+- Failure handling
+
+#### Section 7: Platform Matrix
+- Browsers, devices, versions
+- Required vs optional
+
+#### Section 8: Success Criteria
+- Must Have (P0)
+- Should Have (P1)
+- Nice to Have (P2)
+
+#### Section 9: Risk Matrix
+- Integration risks
+- Mitigation strategies
+- Owners
+
+#### Section 10: Automation Strategy
+- Framework recommendations
+- Execution commands
+- CI/CD integration
+
+#### Section 11: Coverage Summary
+- Feature coverage
+- Scenario breakdown
+- Automatable vs manual
+
+### Step 6: Write Output File
+
+Create file: `{Scenario_ID}-E2E-Test-Spec.md`
+
+**Location options:**
+1. In `docs/e2e-scenarios/` (create if missing)
+2. In feature directory if single-feature E2E
+3. In project root if cross-project
+
+### Step 7: Output Summary
+
+Report to user:
+```
+✓ E2E Test Spec created: {filename}
+
+Scope:
+├─ Features Linked: {count}
+│  └─ {Feature-001}, {Feature-002}, ...
+├─ Epic: {Epic_ID}
+└─ Scenario: {Scenario_ID}
+
+Scenarios Generated:
+├─ Total E2E Scenarios: {count}
+│  ├─ Happy Path: {count}
+│  ├─ Negative Flows: {count}
+│  ├─ Edge Cases: {count}
+│  └─ Performance: {count}
+
+Integration Points:
+├─ Systems Involved: {count}
+├─ External APIs: {count}
+└─ Data Validations: {count}
+
+Automation Readiness:
+├─ Automatable: {count} ({percent}%)
+└─ Manual Only: {count} ({percent}%)
+
+Next Steps:
+1. Review E2E scenarios with stakeholders
+2. Verify integration test data setup
+3. Implement E2E automation using {framework}
+4. Schedule E2E runs in CI/CD pipeline
+```
+
+## Important Notes
+
+1. **E2E ≠ Functional:** E2E tests complete workflows, not single features
+2. **Traceability:** Each E2E step should reference Functional TCs
+3. **Integration Focus:** Emphasize system boundaries and data flow
+4. **Real User Journeys:** Simulate actual user behavior, not artificial flows
+5. **Automation First:** Most E2E scenarios should be automatable
+6. **Environment Matters:** E2E requires production-like staging environment
+
+## Best Practices
+
+1. **Start with Happy Path:** Ensure main flow works before testing edge cases
+2. **Think Like a User:** What would a real user actually do?
+3. **Validate Data:** Don't just check UI - verify database state
+4. **Test Integrations:** Pay special attention to third-party systems
+5. **Handle Failures:** Test what happens when systems fail
+6. **Performance Matters:** E2E flows should meet SLA requirements
+
+## Error Handling
+
+- No Functional Specs found: "No FuncTest-Spec.md files found. Run /tas-functest first."
+- Features don't form logical flow: "Warning: Features may not form a coherent workflow. Continue anyway?"
+- Template missing: "Error: E2E-Test-Spec.md template not found in .tas/templates/"
+- No integration points identified: "Warning: No integration points found. This may be a single-feature E2E."
+
+## Difference from Functional Tests
+
+| Aspect | Functional Tests | E2E Tests |
+|--------|-----------------|-----------|
+| Scope | Single feature | Multiple features |
+| Focus | Feature logic | User journey |
+| Data | Isolated | Shared across steps |
+| Systems | One module | Multiple systems |
+| Duration | Fast | Slower |
+| Maintenance | Lower | Higher |
+| Priority | P0-P2 | P0 (critical flows) |

package/.tas/commands/tas-feature.md

@@ -1,47 +1,181 @@
-# /tas-feature $ARGUMENTS
-
-Role: PE - Product Engineer
-Create or update Feature document, including Integration Test and E2E/Acceptance Test design.
-
-## Prerequisite
-- At least one Epic must exist in docs/epics/
-
-## Actions
-1. Need context from root/tas.yaml
-2. Need context from .tas/templates/Feature.md
-3. Determine mode based on $ARGUMENTS:
-
-### CREATE mode ($ARGUMENTS is new Feature description, or no $ARGUMENTS):
-4. Read project.code from root/tas.yaml. List existing Epics, ask user which Epic this Feature belongs to.
-5. Scan selected Epic directory to determine Feature sequence number.
-6. Create directory docs/epics/{code}-Epic-{NNN}-{slug}/{code}-Feature-{NNN}-{slug}/
-7. Create file {code}-Feature-{NNN}-{slug}.md in that directory
-8. After PE fills description and acceptance criteria, AUTOMATICALLY switch to test design:
-   a. **Integration Test Cases**: Ask PE:
-      - "Which services/modules does this Feature interact with?"
-      - "What linked flows between stories need testing?"
-      - "Any data flows needing end-to-end verification within this feature?"
-      Write to Integration Test Cases section.
-   b. **E2E / Acceptance Test Cases**: Ask PE:
-      - "What's the main user scenario to verify this feature on Staging?"
-      - "Any scenarios needing real or near-real data testing?"
-      - "Which acceptance criteria need manual PE verification?"
-      Write to E2E Test Cases section. This is the checklist PE uses in Phase 2 when running /tas-functest + /tas-e2e.
-9. Update `project-status.yaml` per `.tas/rules/common/project-status.md` — add entry to `epics.{EPIC_ID}.features`.
-
-### UPDATE mode ($ARGUMENTS is Feature ID, e.g., "Feature-003"):
-4. Find Feature file in docs/epics/ tree (using glob)
-5. Need context from current Feature file
-6. Ask user what needs changing (add story, update AC, add test cases, change status...)
-7. Update file, add changelog
-8. Update `project-status.yaml` per `.tas/rules/common/project-status.md` — update `epics.{EPIC_ID}.features.{FEATURE_ID}.status`.
-
-## Principles
-- Feature is a specific function that can be demoed
-- Feature MUST have clear, testable acceptance criteria
-- Integration Test Cases MUST cover linked flows between stories
-- E2E Test Cases MUST be sufficient for PE to verify feature on Staging in Phase 2
-
-## Final Step — Token Log
-
-Follow `.tas/rules/common/token-logging.md`: write AI Usage Log to working Feature file.
+---
+model: sonnet
+---
+
+# /tas-feature $ARGUMENTS
+
+Role: PE - Product Engineer
+Create or update a Feature document. Feature is the **only** unit of business work in TAS — Epic and Story are removed.
+
+**Scope:** Business logic, AC, NFR.
+**Out of scope:** Technical implementation, file changes, ERD, ADR — that's `/tas-plan`'s job (writes `Feature-{NNN}-Technical.md`).
+
+## Always / Ask / Never
+
+| | Action |
+|---|---|
+| **Always** | Write AC in Given/When/Then format |
+| **Always** | Set `plan_status: pending` for new Feature |
+| **Always** | Read PRD + SAD before proposing Features |
+| **Always** | Infer stacks from SAD architecture — do NOT ask user to specify stacks |
+| **Always** | In ad-hoc mode: write Feature first (Gate 1), then PRD delta (Gate 2) — never show both drafts simultaneously |
+| **Always** | In ad-hoc mode: check ADRs for conflicts before drafting |
+| **Never** | Write Technical Plan content here |
+| **Never** | Suggest or create ADRs — `/tas-plan` documents decisions, human approves ADRs |
+| **Never** | Use SAD for technical analysis — read SAD only for system layers and dependency order |
+| **Never** | Write PRD before Feature is approved in ad-hoc mode |
+
+## Prerequisites
+- `tas.yaml` exists at project root
+- (Optional but preferred) `docs/prd.md` — for FR list and business context
+- (Optional but preferred) `docs/sad.md` (or linked SAD file) — for system architecture layers and component dependency order
+
+## Actions
+
+### CREATE mode (`$ARGUMENTS` is new Feature description, or no `$ARGUMENTS`)
+
+**Step 1 — Read context**
+- Read `project.code` from root `tas.yaml`
+- Read `docs/prd.md` if exists — extract FR list and business context per FR
+- Read SAD if exists — extract:
+  - Which layers/stacks exist in this system (`app`, `web`, `service`, `integration` — only layers actually present)
+  - Component or layer dependencies (which components must exist before others)
+
+**Step 1.5 — Match $ARGUMENTS against PRD (only when $ARGUMENTS is a description)**
+
+If `$ARGUMENTS` is a description (not a Feature ID, not empty):
+- Compare against existing FRs in PRD
+- If **clear match found** → continue to Step 2 (normal flow for that FR)
+- If **no match** → enter **Ad-hoc Mode** below
+
+#### Ad-hoc Mode — New Requirement Not in PRD
+
+Used when customer brings a requirement not covered by existing PRD FRs.
+
+**a. Announce:**
+> "Requirement not found in PRD. Entering ad-hoc mode — will survey, create Feature, then update PRD."
+
+**b. Q&A — use `AskUserQuestion` tool (popup UI), split into 2 calls:**
+
+**Popup call 1** (up to 4 questions):
+- "What business value does this deliver? Who benefits?" — header: `Business`
+- "Who are the actors / triggers? Any external systems?" — header: `Actors`
+- "Key business rules or constraints?" — header: `Rules`
+- "NFR priorities?" — header: `NFR`, `multiSelect: true`, options: Performance / Security / Compliance / Scalability / Accessibility
+
+**Popup call 2** (after call 1 answers received):
+- "Which stacks does this touch?" — header: `Stacks`, `multiSelect: true`, options: list only stacks found in SAD (web / service / integration / app — only those present)
+
+Wait for all answers before proceeding to step c.
+
+**c. ADR conflict check:**
+Read `docs/adr/*.md` if exists. Flag any conflict:
+> "⚠️ Conflict with ADR-XXX: [decision]. This requirement may require revisiting [constraint]."
+
+**d. Draft Feature (in-conversation):**
+Using PE answers + ADR check, draft full Feature content following `.tas/templates/Feature.md` structure (Description, User Story, Actor, Business Flow, Business Rules, UI/UX, NFR, AC in Given/When/Then).
+
+**e. Gate 1 — Feature approval:**
+> "Feature draft above OK? Approve to write file."
+- Approved → assign next Feature ID (scan `docs/features/`), create directory + write file → **skip Steps 2–6, go to step f**
+- Feedback → update draft, ask again
+
+**f. Draft PRD delta (in-conversation):**
+After Feature file written, draft PRD addition for the new FR. Default: FR title + one-line description + reference to Feature file. Show draft and note:
+> "Default: minimal FR entry. Expand if more business context needed."
+
+**g. Gate 2 — PRD approval:**
+> "PRD update above OK? Approve to write."
+- Approved → append new FR to `docs/prd.md` (in appropriate section)
+- Feedback → update draft, ask again
+
+**h. Proceed to Step 7** (update `project-status.yaml`)
+
+**i. Update master plan (if exists):**
+- Check if `docs/master-plan.md` exists
+- If exists → invoke `/tas-master-plan AMEND` inline (follow that command's AMEND mode steps); do not end turn, wait for result before continuing
+- If not → skip
+
+**Proceed to Step 8** (notify).
+
+---
+
+**Step 2 — Infer stacks per FR + determine order**
+- For each FR in PRD:
+  - Read FR description and understand what parts of the system it touches
+  - Cross-reference SAD architecture to confirm which layers are involved
+  - Example: "User Login FR" touching web UI + auth API + external IdP → inferred stacks: `web`, `service`, `integration`
+- Order FRs by SAD dependency (foundation layers first — e.g., `service` before `web`, `web` before `integration` adapters)
+- Result: one Feature per FR, with inferred stacks noted as context for PE
+
+**Step 3 — Present proposed Feature list + confirm**
+
+Show ordered list with inferred stacks as context. Example:
+
+```
+Proposed Features (ordered by dependency):
+
+[ ] Feature-NNN-auth        FR-001: Authentication   (touches: service, integration, web)
+[ ] Feature-NNN-checkout    FR-002: Checkout         (touches: service, web)
+
+Select which to create now (all, or specific numbers):
+```
+
+User can select all or a subset. Proceed only for selected items.
+
+**Step 4 — Assign Feature IDs**
+- Scan `docs/features/` for existing `{CODE}-Feature-NNN-*` directories
+- Assign next sequential ID (max existing NNN + 1, +1 per new Feature in this batch)
+- IDs assigned in the order shown in Step 3
+
+**Step 5 — Create directory + file for each selected Feature**
+- Directory: `docs/features/{CODE}-Feature-{NNN}-{slug}/`
+- File: `docs/features/{CODE}-Feature-{NNN}-{slug}/{CODE}-Feature-{NNN}-{slug}.md`
+- Use template `.tas/templates/Feature.md`
+- Frontmatter: `plan_status: pending`, `plan_date:` empty
+
+**Step 6 — Walk PE through filling each Feature (one at a time)**
+
+For each created Feature file, ask PE to provide:
+
+a. **Description**: short summary + business value
+b. **User Story**: "As a [role], I want [goal], so that [benefit]"
+c. **Actor**: "Who interacts with this Feature? Roles, personas, external systems?"
+d. **Business Flow**: "Step-by-step business flow / user journey?"
+e. **Business Rules**: "BR-1, BR-2... validations, constraints, calculations?"
+f. **UI/UX Rules**: "Any UI/UX rules or design-spec.md ref? (skip if backend-only)"
+g. **Non-Functional Requirements**: "Performance, security, scalability, accessibility — measurable?"
+h. **Acceptance Criteria** (Given/When/Then): "AC-1, AC-2... each testable?"
+
+After completing one Feature, move to next selected Feature.
+
+**Step 7 — Update `project-status.yaml`**
+- Per `.tas/rules/common/project-status.md` — add one entry per created Feature to flat `features.{FEATURE_ID}` map.
+
+**Step 8 — Notify next step**
+> "Features created. For each Feature, run `/tas-plan {Feature-ID}` to generate `Feature-{NNN}-Technical.md` before SE codes."
+
+---
+
+### UPDATE mode (`$ARGUMENTS` is Feature ID, e.g., `Feature-003`)
+
+1. Find file via glob `docs/features/{CODE}-Feature-{ID}-*/**.md` (excluding `*-Technical.md`)
+2. Read current Feature file
+3. Ask user what to change (description, actor, business flow, business rules, UI/UX, NFR, AC, status...)
+4. Update file, add Changelog entry: date + changes + author
+5. Update `project-status.yaml` per `.tas/rules/common/project-status.md` — update `features.{FEATURE_ID}.status`
+6. If AC changed: warn user that downstream artifacts may be stale — `Feature-{NNN}-Technical.md`, `Func-Test-*.md`
+
+## Principles
+- Feature is a **complete business flow** that can be released to production after coding
+- One Feature = one business requirement. A Feature may span multiple stacks (`app`, `web`, `service`, `integration`) — per-stack technical breakdown lives in `Feature-{NNN}-Technical.md`
+- Each Feature lives in its own directory under `docs/features/`
+- Feature MUST have clear, testable Acceptance Criteria in Given/When/Then format
+- Business Rules MUST be unambiguous and verifiable
+- Non-Functional Requirements MUST be measurable when applicable
+- Test cases (Functional / E2E) live in separate files in same directory — NOT in Feature doc
+- Technical content (ERD, files, config, ADR, per-stack breakdown) lives in `Feature-{NNN}-Technical.md` — generated by `/tas-plan`
+
+## Final Step — Token Log
+
+Follow `.tas/rules/common/token-logging.md`: write AI Usage Log to working Feature file.