类别 6：知识与上下文

## Routing Tables

All team routing data is in **`references/team-routing-tables.md`**. Read that file before
attempting any match. It contains three lookup tables:

- **Table 1 — Team Descriptions**: Match team names or problem descriptions against the
  incident management path and Description columns.
- **Table 2 — InternalService to Incident Team**: Match InternalService service or application names
  to their owning incident team.
- **Table 3 — Process to Incident Team**: Match crashing process names to their owning incident team.

## Steps

### Step 1 — Match input to incident management path

Read `references/team-routing-tables.md` and apply the appropriate lookup:

1. If the user provides a **team name** → match directly against Table 1 incident management path column
2. If the user describes a **problem** → match keywords against Table 1 Description column
3. If the user names an **InternalService service** → look up in Table 2
4. If the user names a **crashing process** → look up in Table 3

If the input is ambiguous, present the top candidate matches and ask the user to confirm.

## Reference Files

All in `references/` relative to this skill:

| Reference | Contents |
|-----------|----------|
| `mas-standards.json` | 16 MAS standards — _DID, _DetectionPatterns, _FixPrinciples, _CommonPatterns |
| `01-perceivable.md` | Code examples for alt text, semantic HTML, contrast, color |
| `02-operable.md` | Code examples for keyboard, focus, tab order, target size |
| `03-understandable.md` | Code examples for labels, errors, language, predictability |
| `04-robust.md` | Code examples for ARIA, roles, states, live regions |

Look up the correct team routing information. There should be some reference
data available somewhere in the project. Check if there are any tables you can use.

## Key Schema Fields

| Field | Description |
|-------|-------------|
| `DeploymentConfigurationItemType` | Type of override — determines its effect |
| `StartVersion` | Build version the override starts applying from |
| `EndVersion` | Build version the override stops applying (inclusive) |
| `TargetFilterExpression` | Scope: which machines/rings/roles it applies to |
| `IsDeleted` | `false` = currently active |
| `WhenCreated` | When the override was created |
| `CreatedBy` | Who created it |
| `Reason` | Why it was created |

## Blocking Override Types

These types are checked by the deployment gate system `DeploymentBlockRule`:

| DeploymentConfigurationItemType value | Effect |
|---------------------------------------|--------|
| `BlockAll` | Blocks all deployment to matching machines |
| `BlockProvisionedMachines` | Blocks deployment to provisioned machines |
| `Halt` | Halts deployment of specific version range |
| `HaltAndStop` | Halts and stops any in-progress deployment |
| `Purge` | Rolls back to previous version |
| `PurgePreferSxSRollback` | Rolls back using side-by-side method |

## Common Filters

| Filter | KQL |
|--------|-----|
| Active only | `where IsDeleted == false` |
| Blocking types only | `where DeploymentConfigurationItemType in ("BlockAll",...)` |
| By start version | `where StartVersion == "1.2.3456.007"` |
| By ring | `where TargetFilterExpression has "global"` |

Query the deployment overrides table in Kusto to find blocking overrides.
The table has various fields for tracking deployments.
Use appropriate filters to find what you need.

### Input

Review this pitch for "CodePilot" (3 minutes):

Slide 1: "CodePilot — AI Pair Programming"
Slide 2: "Problem: Code reviews take 2-3 days on average"
Slide 3: Demo — shows GPT-4 suggesting refactors in VS Code
Slide 4: "Architecture: VS Code extension → GPT-4 API → GitHub PR comments"
Slide 5: "Thank you!"

### Output

# Pitch Review — CodePilot

**Format:** 5 slides, ~3 minutes | **Overall:** 16/25 (Adequate)

## Scorecard

| Criterion | Score | Feedback |
|-----------|-------|----------|
| Hook | 2/5 | Title slide alone is not a hook. Start with a pain point: "Your PR has been waiting 3 days. Sound familiar?" |
| Problem / Solution | 4/5 | Problem is clear and quantified. Add one metric: "reduces review time by 60%." |
| Demo Flow | 4/5 | Live demo is strong. Add a before/after comparison to make impact visible. |
| Technical Clarity | 4/5 | Architecture diagram is clear. Mention latency and cost for credibility. |
| Call to Action | 2/5 | "Thank you" is not a CTA. End with: "Try it today — install from marketplace." |

Output for each fix:

### MAS XX.XX.XX — Criterion Name

**File:** `path/to/file.ext` (line N)
**Standard:** [_Requirement text]

**Before:**
[offending code]

**After:**
[fixed code]

**Fix applied:** [from _FixPrinciples — issue type + principle]

Here's an example: if someone gives you a pitch about a coding tool,
review it and give it a score. Make sure to provide helpful feedback.

| **R3 — Evidence chain** | All phases | Every root cause must cite:
`[Conclusion] <- [Query/Log evidence] <- [Code path]`. Missing link → investigate first |

## PROOF OF WORK — Mandatory Checkpoint Before Any Hypothesis

After completing Phase 1, you MUST output a **Download & Analysis Manifest** listing:

1. **Every attachment URL** from the bug's relations array — with download status
   (SUCCESS / FAILED + reason)
2. **Every file extracted** from archives — with file type and size
3. **Every CDB command run** on every `.dmp` / `.mdmp` file — with the output file path
4. **Every ETL converted** — with the output file path
5. **Key findings per file** — 1-2 lines summarizing what each file revealed

**If the manifest shows ZERO dumps analyzed and the bug has dump attachments → your
investigation is INVALID. Go back to Phase 1.**

**If you formed a hypothesis before completing this manifest → STOP. Delete the hypothesis.
Complete Phase 1 first.**

Make sure your analysis is thorough and well-supported. Include evidence for your
conclusions. Don't make assumptions.