suriyel/longtaskforagent/long-task-ats

LANGUAGE RULE: You MUST respond to the user in Chinese (Simplified). All generated documents, reports, and user-facing output must be written in Chinese. Skill names, code identifiers, and JSON field names remain in English.

Acceptance Test Strategy (ATS) Generation

Take the approved SRS, Design, and UCD (if applicable) as input. Produce a global Acceptance Test Strategy document that maps every requirement to acceptance scenarios with required test categories — constraining downstream feature-st (test case derivation via srs_trace).

Announce at start: "I'm using the long-task-ats skill to generate the Acceptance Test Strategy."

<HARD-GATE> Do NOT invoke any implementation skill, write any code, scaffold any project, run init_project.py, or take any implementation action until the ATS document is approved. This applies to EVERY project regardless of perceived simplicity. </HARD-GATE>

Why ATS Exists

Without a global acceptance test strategy, per-feature ST test cases suffer from:

• Category imbalance (heavy FUNC/BNDRY, near-zero SEC/PERF/UI)
• NFR test methods decided ad-hoc during feature-st
• Cross-feature integration scenarios discovered too late in ST phase
• Risk-based test prioritization missing entirely

ATS front-loads these decisions so Init and feature-st have concrete, auditable constraints.

Scaling Guide

Auto-skip rule for Tiny projects: If the design document exists and the SRS has ≤ 5 functional requirements (FR-xxx), this skill embeds the ATS mapping table into the design doc's testing strategy section and creates a minimal docs/plans/*-ats.md stub containing only a reference to that section. The router then detects the ATS stub and proceeds to Init.

Checklist

You MUST create a TodoWrite task for each step and complete them in order:

1. Read Input Documents

1. Read the approved SRS document from docs/plans/*-srs.md
2. Read the approved design document from docs/plans/*-design.md
3. Read the approved UCD style guide from docs/plans/*-ucd.md (if it exists — only for UI projects)
4. Check for a custom ATS template:

• If user has specified a template path → read and validate it
• Else → use default template at docs/templates/ats-template.md

1. Check for a custom ATS example:

• If user has specified an example path → read the example file — adapt style, language, and detail level

2. Extract All Requirements

From the SRS, extract a complete list of:

• FR-xxx: Functional Requirements — with acceptance criteria (Given/When/Then)
• NFR-xxx: Non-Functional Requirements — with measurable thresholds
• IFR-xxx: Interface Requirements — with protocols and data formats
• CON-xxx: Constraints — hard limits
• ASM-xxx: Assumptions — implicit beliefs

Count FR-xxx requirements. If ≤ 5, apply the Tiny project auto-skip rule (see Scaling Guide above).

3. Generate Requirement → Acceptance Scenario Mapping

For each FR/NFR/IFR, generate one or more acceptance scenarios with:

| Req ID | Requirement Summary | Acceptance Scenarios | Required Categories | Priority | Notes |
|--------|---------------------|----------------------|---------------------|----------|-------|
| FR-001 | User login | Normal login/wrong password/account lockout/session expiry | FUNC,BNDRY,SEC | Critical | Handles user input→SEC required |
| NFR-001 | Response time<200ms | P95 latency/concurrent load/degradation/cold start | PERF | High | Threshold: P95<200ms @100 concurrent |
| FR-010 | Search results page | Search/empty results/pagination/sorting/filtering | FUNC,BNDRY,UI | High | ui:true→UI required |

Category assignment rules:

Automation feasibility assessment (optional column `自动化可行性`):

For each acceptance scenario, assess whether it can be fully automated with the project's tech stack:

• Auto (default) — standard test tooling can execute and verify (CLI, API, Chrome DevTools MCP)
• Manual: physical-device — requires hardware access (USB, printer, IoT device)
• Manual: visual-judgment — requires human visual assessment beyond automated screenshot comparison
• Manual: external-action — requires external human action (receive email, make phone call, approve in third-party system)
• Manual: other: {description} — other reason

This column propagates downstream: Feature-ST reads it to set 已自动化: No + 手动测试原因 on derived test cases. The human will be interrupted via AskUserQuestion during Feature-ST execution to perform and report manual test results.

Conservative flagging: Only mark as Manual when automation is genuinely impossible, not merely difficult. Chrome DevTools MCP covers most UI testing; mock services cover most external dependencies. Reserve Manual for true gaps.

4. Define Test Category Strategies

For each test category, specify the strategy:

• FUNC: Every FR must cover at least one happy-path + one error-path scenario
• BNDRY: Boundary value analysis + equivalence class partitioning requirements per FR
• SEC: Input validation (SQL injection, XSS, path traversal), authentication bypass, authorization escalation, data leakage
• PERF: NFR metric thresholds + load scenarios + tool specification + pass criteria
• UI: Chrome DevTools MCP interaction chains — navigate → interact → verify → three-layer detection

5. NFR Test Method Matrix

For each NFR-xxx with measurable thresholds:

| NFR ID | Test Method | Tool | Pass Criteria | Load Parameters | Related Feature |
|--------|---------|------|---------|---------|-------------|
| NFR-001 | Load test | k6/locust/ab | P95 < 200ms | 100 concurrent, 60s ramp | Feature 15, 16 |
| NFR-002 | Memory profiling | tracemalloc/heapdump | RSS < 512MB | 10K records | Feature 8 |

6. Cross-Feature Integration Scenarios

Identify critical data flow paths that span multiple features:

| Scenario ID | Description | Features Involved | Data Flow Path | Verification Points | ST Phase Coverage |
|-------------|-------------|-------------------|----------------|---------------------|-------------------|
| INT-001 | User register → login → first action | F1, F2, F5 | POST /register → POST /login → GET /dashboard | Session propagation, data consistency | System ST |

§6.2-driven integration scenario derivation: For each row in Design §6.2 Internal API Contracts:

1. Create at least one integration scenario covering the happy-path data flow (Provider produces → Consumer receives → Consumer processes correctly)
2. Create at least one error scenario covering Provider error codes (e.g., Provider returns 404 → Consumer handles gracefully)
3. If the contract involves shared persistent state (same DB table), create a consistency scenario (concurrent access, stale reads)
4. Reference the Contract ID (IAPI-xxx) in the scenario's "Data Flow Path" column

7. Risk-Driven Test Priority

Assess risk per requirement and assign test depth:

| Risk Area | Risk Level | Impact Scope | Test Depth | Rationale |
|-----------|------------|--------------|------------|-----------|
| User authentication | High | System-wide | Deep (SEC+FUNC+BNDRY) | Security boundary |
| Data import | Medium | Feature 3-5 | Standard (FUNC+BNDRY) | Data integrity |

8. Section-by-Section User Approval

Present each section to the user for approval (same pattern as design skill):

1. Requirement → Scenario mapping table (Step 3)
2. Test category strategies (Step 4)
3. NFR test method matrix (Step 5) — skip if no NFRs with metrics
4. Cross-feature integration scenarios (Step 6)
5. Risk-driven priority (Step 7)

Present each section. Wait for user feedback. Incorporate changes before moving to the next.

For Small projects (5-15 features): Combine into 2 approval steps: (a) mapping table + categories, (b) everything else.

9. Subagent Review

Dispatch the ATS reviewer subagent for independent quality review:

Agent(
  subagent_type="general-purpose",
  prompt="""
  You are an independent ATS reviewer.
  Read the reviewer definition at: agents/ats-reviewer.md
 
  ## Input Documents
  - ATS document (draft): {ats_content}
  - SRS document: {srs_path} — read it
  - Design document: {design_path} — read it
  - UCD document (if applicable): {ucd_path} — read it
 
  ## Task
  Execute all review dimensions (R1-R8) defined in agents/ats-reviewer.md.
  Output a structured review report.
  Do NOT suggest improvements beyond defect identification.
  Do NOT read any implementation code — this is a requirements-level review.
  """
)

Isolation guarantees:

• Subagent reads ONLY ATS + SRS + Design + UCD + reviewer definition (agents/ats-reviewer.md)
• Subagent does NOT read implementation code or test code
• Subagent does NOT modify any files — returns structured report only
• Main skill processes the report and decides on fixes

10. Process Review Report

Parse the subagent's review report:

1. 0 Major defects → PASS → proceed to Step 10.5
2. Has Major defects → fix the ATS document per defect descriptions → re-run Step 9 (max 2 review rounds)
3. Third round still FAIL → present full report to user via AskUserQuestion:

• Show all remaining Major defects
• Options: fix manually / accept with known gaps / terminate
• If user accepts with gaps: document gaps in ATS footer section

10.5 Process Cross-Reference Conflicts

If the review report contains [CROSS-REF CONFLICT] items (from R8 cross-validation):

1. Collect all [CROSS-REF CONFLICT] items from the Cross-Reference Conflicts table in the review report
2. For each conflict, present to the user via AskUserQuestion:

• Source document value + section reference
• ATS value + section reference
• Nature: omission / contradiction / distortion
• Options:
• A: Use source document value (modify ATS)
• B: Use ATS value (update SRS/Design to match)
• C: Neither is correct (user provides the correct value)

1. Apply user decisions to the relevant documents
2. Record each decision in the ATS appendix (Review Report section) with format:

```

```

1. If any source documents (SRS/Design) were modified, git commit the changes:

`` docs: resolve ATS cross-reference conflicts per user decision ``

1. Proceed to Step 11

11. Save ATS Document

1. Save the approved ATS to docs/plans/YYYY-MM-DD-<topic>-ats.md
2. Append the final review report as an appendix section
3. Git commit:

``` docs: add acceptance test strategy (ATS)

Maps N requirements to acceptance scenarios Categories: FUNC, BNDRY, SEC, PERF, UI Reviewed: [PASS / CONDITIONAL PASS with N gaps] ```

12. Transition to Initializer

Once the ATS document is saved and committed: