# TC ID Convention — Single Source of Truth

**Purpose:** Define TC ID formats for all test types in the TAS Kit. Every test command generating TC IDs must follow this file — no local redefinition.

**Used by:** `/tas-TestChecklist`, `/tas-functest`, `/tas-apitest-plan`, `/tas-e2e`, `/tas-release-plan`

---

## 1. ID Hierarchy

```
Project → Feature → AC → Test Point → Test Case
{PROJECT}  F{NNN}   AC{N}  {CAT}-{N}   {TC_ID}
```

All IDs are **feature-scoped** (not project-scoped) except `TD-{NNN}` (test data, reusable across features).

---

## 2. Functional Test IDs (tas-TestChecklist + tas-functest)

### Flow ID
```
{FEAT}-F{NNN}-AC{N}
```
| Part | Rule | Example |
|---|---|---|
| `{FEAT}` | Feature ID from `feature_id:` frontmatter (e.g. `F003`) | `F003` |
| `F{NNN}` | Flow number, zero-padded 3 digits | `F001` |
| `AC{N}` | AC number from Feature.md | `AC2` |

Example: `F003-F001-AC2`

### Test Point ID (TestChecklist)
```
{FEAT}-{CAT}-{N}
```
| Part | Rule | Example |
|---|---|---|
| `{FEAT}` | Feature ID | `F003` |
| `{CAT}` | Category code (see §4) | `VAL` |
| `{N}` | Sequence, zero-padded 3 digits | `001` |

Example: `F003-VAL-001`

### Functional TC ID (FuncTest)
```
{FEAT}_{AC_ID}_{CAT}_{SEQ}[{variant}]
```
| Part | Rule | Example |
|---|---|---|
| `{FEAT}` | Feature ID | `F003` |
| `{AC_ID}` | `AC{N}` | `AC2` |
| `{CAT}` | Category code (see §4) | `VAL` |
| `{SEQ}` | Sequence, zero-padded 3 digits | `003` |
| `{variant}` | Optional suffix for BVA/EP variants: `a`, `b`, `c`, `d` | `a` |

Example: `F003_AC2_VAL_003` (single) or `F003_AC2_VAL_003a` (BVA variant)

**Critical:** Extract `{FEAT}` from `feature_id:` frontmatter or TestChecklist §1.1 Flow ID — NEVER fall back to `feature_code` (e.g. `PROJ-Feature-001`). If it looks like `PROJ-Feature-001` → STOP, raise error.

---

## 3. API TC IDs (tas-apitest-plan)

### When Feature-linked (Feature ID known)
```
{PROJECT}_F{FID}_AC{N}_{SECTION}_{NNN}_{MOD}
```
| Part | Rule | Example |
|---|---|---|
| `{PROJECT}` | Project code from `tas.yaml` | `TAS` |
| `F{FID}` | Feature ID, zero-padded | `F003` |
| `AC{N}` | AC number; use `X` for cross-cutting TCs | `AC2` or `ACX` |
| `{SECTION}` | Test section (see §3.1) | `API` |
| `{NNN}` | Sequence, zero-padded 3 digits | `001` |
| `{MOD}` | Modifier: `H`=Happy, `E`=Error, `S`=Security, `N`=NFR, `B`=BackwardCompat | `H` |

Example: `TAS_F003_AC2_API_001_H`

### When spec-only (no Feature link)
```
TC-{NNN}
```
Use only when input is a raw API spec file with no Feature context. Upgrade to Feature-linked format as soon as Feature ID is known.

### 3.1 Section codes for API TC IDs

| Section code | Test section | When |
|---|---|---|
| `API` | §1 Contract tests | Happy/error path per endpoint |
| `INT` | §2 Integration tests | Cross-service, external dependency |
| `BCK` | §3 Backward-compat tests | Schema evolution, deprecation |
| `NFR` | §4 NFR tests | Perf, Security, Pentest |
| `MALFORMED` | Cross-cutting malformed request | Shared across POST/PUT/PATCH |
| `DBFAIL` | Cross-cutting DB failure | Per endpoint type touching DB |

Examples:
- `TAS_F003_ACX_INT_001_E` — Integration test, error scenario
- `TAS_F003_ACX_BCK_001_B` — Backward-compat
- `TAS_F003_ACX_NFR_001_N` — NFR
- `TAS_F003_ACX_MALFORMED_001_E` — Cross-cutting malformed request

---

## 4. Category Codes (All Test Types)

| Code | Category | Used in |
|---|---|---|
| `GUI` | UI layout, visual, responsive | FuncTest |
| `VAL` | Input validation, BVA/EP | FuncTest, API contract |
| `BL` | Business logic, state transitions | FuncTest, API |
| `EXC` | Exception handling, error recovery | FuncTest, API |
| `SEC` | Security, auth bypass, XSS/SQLi | FuncTest, API |
| `INT` | Integration, external system | FuncTest, API |
| `PERF` | Performance, NFR thresholds | API §4 |
| `STATE` | State transition, workflow | TestChecklist TP |
| `NFR` | Non-functional (platform baselines) | TestChecklist TP |

---

## 5. Supporting IDs

| ID | Format | Scope | Example |
|---|---|---|---|
| **Test Data** | `TD-{NNN}` | Project-wide reusable | `TD-042` |
| **Risk** | `R-{NNN}` | Feature-unique | `R-007` |
| **Coverage Gap** | `GAP-{NNN}` | Per test spec | `GAP-001` |

---

## 6. Validation Rules

Before writing any test output file, verify:

1. All TC IDs unique within the file.
2. `{FEAT}` part does NOT contain hyphens without F-prefix (no `PROJ-Feature-001`).
3. BVA/EP variants use `a`/`b`/`c`/`d` suffix — NOT `_1`/`_2`.
4. Cross-cutting TCs use `ACX` as AC segment.
5. API section code matches the section the TC was generated in.
6. `{MOD}` is one of: `H`, `E`, `S`, `N`, `B`.

**On validation failure:** STOP, emit specific error with failing TC ID and rule number. Do NOT write file.