---
name: tcoc-incident-review
description: |
  Daily review of TCOC Jira Incident tickets. Fetches recent Incident issues,
  analyzes title and description to identify mis-classified tickets that are not
  real incidents (quota requests, billing questions, feature requests, resource
  reservations, UI feedback, etc.), presents a review table for confirmation,
  then batch-updates issue types via Jira API.
  Use when: user asks to review/triage TCOC incidents, daily incident cleanup,
  or ticket type audit.
---

# TCOC Incident Review

Daily workflow to audit TCOC Incident tickets and reclassify non-incidents.

## Prerequisites

Environment variables (should be in `~/.bashrc`):

```
JIRA_EMAIL=<your-email>@pingcap.com
JIRA_API_TOKEN=<your-jira-api-token>
JIRA_BASE_URL=https://tidb.atlassian.net/
```

## TCOC Project Issue Types

| ID | Type |
|----|------|
| 10029 | Incident |
| 10028 | Customer Question |
| 10007 | Task |
| 10008 | Sub-task |
| 14062 | POC Issues |

## Step 1: Fetch Incident Tickets

Pull all Incident tickets created in the review window (default: last 1 day, adjustable).

```bash
curl -s -u "${JIRA_EMAIL}:${JIRA_API_TOKEN}" -H "Content-Type: application/json" \
  -X POST "${JIRA_BASE_URL}rest/api/3/search/jql" \
  -d '{
    "jql": "project = TCOC AND issuetype = Incident AND created >= -1d ORDER BY created DESC",
    "maxResults": 100,
    "fields": ["summary", "description", "created", "status", "priority", "labels"]
  }'
```

If `isLast` is false, paginate using `nextPageToken`.

## Step 2: Analyze and Classify

For each ticket, read the title and description. Classify as **keep Incident** or **reclassify** based on the rules below.

### Classification Rules

#### Reclassify to Task

| Pattern | Example |
|---------|---------|
| Resource quota increase / node count change | "Request to increase node count quota" |
| Resource reservation requests | "production instance, 1day reserve" |
| Feature enablement requests | "export large scale data - need to enable export feature" |
| Scheduled operation requests (upgrade, migration) | "The upgrade has not started yet" (催促执行计划内操作) |

#### Reclassify to Customer Question

| Pattern | Example |
|---------|---------|
| Billing / pricing inquiries | "Changefeed price differs from documentation" |
| UI/UX feedback or suggestions | "Export task control buttons are hard to locate" |
| Product feature questions (no outage) | "Cannot increase Backup Retention after upgrade" |
| Storage/usage confusion (no actual outage) | "Excessive storage usage despite tiny database size" |
| Asking about system behavior with NO business impact | "TiKV CPU usage unbalanced, please investigate cause" |
| User-caused issue (their own traffic spike, config change) with no platform fault | "Changefeed lag after customer switched write workload" |

#### Keep as Incident

| Pattern | Example |
|---------|---------|
| Service outage, SLA break | "us-east-1-f01 SLA Break" |
| Node crash, restart, OOM | "TiDB node restarted", "TiKV OOM risk" |
| Data loss, backup/restore failure | "backup misses SST file causing restore failure" |
| Performance degradation affecting queries/business | "sql duration increase", "duration jitter" |
| Monitoring/metrics unavailable (user-facing) | "Monitoring page shows no metrics" |
| Platform bug causing errors | "TLS session resumption bug", "VPC Peering stuck" |
| Cluster operations stuck | "Create new premium got stuck" |
| Changefeed/DM errors (platform side) | "changefeed deleted but data still flowing" |
| Customer explicitly reports business impact | "[Mercari] Degradation observed in UPDATE SQL" |
| Supplementary tickets (补单) for real incidents | "问题已解决，补单" - keep as Incident |

### Key Judgment Principles

1. **Business impact is the primary signal.** If the customer reports query latency increase, error rates, or service disruption, it is an Incident even if the root cause is trivial.
2. **"Please investigate cause" without business impact** leans toward Customer Question.
3. **User-caused issues** (traffic spike, config change, workload switch) where the platform behaved correctly are Customer Question, even if user experienced degradation.
4. **Supplementary tickets (补单)** are always kept as Incident - they record real past incidents.
5. **When in doubt, keep as Incident.** False negatives (missing a real incident) are worse than false positives.

## Step 3: Present Review

Show the user a table of tickets proposed for reclassification:

```
| Ticket | Current Type | Proposed Type | Title | Reason |
|--------|-------------|---------------|-------|--------|
| TCOC-XXXX | Incident | Task | ... | Resource quota request |
| TCOC-YYYY | Incident | Customer Question | ... | Pricing inquiry |
```

Also show the remaining Incident list with count summary. Wait for user confirmation or adjustments before proceeding.

## Step 4: Execute Changes

After user confirms, update issue types via Jira API:

```bash
# Change to Task (id: 10007)
curl -s -u "${JIRA_EMAIL}:${JIRA_API_TOKEN}" \
  -H "Content-Type: application/json" \
  -X PUT "${JIRA_BASE_URL}rest/api/3/issue/TCOC-XXXX" \
  -d '{"fields":{"issuetype":{"id":"10007"}}}'

# Change to Customer Question (id: 10028)
curl -s -u "${JIRA_EMAIL}:${JIRA_API_TOKEN}" \
  -H "Content-Type: application/json" \
  -X PUT "${JIRA_BASE_URL}rest/api/3/issue/TCOC-YYYY" \
  -d '{"fields":{"issuetype":{"id":"10028"}}}'
```

HTTP 204 = success. Print result for each ticket.

## Step 5: Final Summary

After all changes, re-query Incident tickets and show updated counts:
- Total Incident count
- By priority (P0-P4)
- By status
- Full ticket list