qa-resource-risk-gantt

name	qa-resource-risk-gantt
description	Update or create QA/resource risk warning Gantt charts for one or more business teams from Google Sheets scheduling documents. Use when the user asks to 更新QA资源风险预警甘特图, 生成业务团队资源预警甘特图, update QA risk Gantt for a team, detect QA resource risks, compare Dev提测时间 and QA测试开始时间, calculate QA Gap, add a new business team's scheduling document, or refresh the shared QA资源预警 spreadsheet.

QA Resource Risk Gantt

Workflow

Use Google Sheets MCP tools to update a business team's QA resource risk warning Gantt chart.

1. Load references/business-registry.md and references/sheet-contract.md.
2. Discover Google Sheets tools with tool_search if mcp__google_sheets__ or mcp__google_docs__ tools are not already available.
3. Resolve the business team:
   • Use the team named by the user.
   • If the user does not name a team and exactly one default business exists in the registry, use it.
   • If multiple businesses could match, ask the user which business team to update.
4. Resolve the source scheduling document:
   • First check the registry for the business team's source link.
   • Then check the shared target spreadsheet for an existing business sheet whose metadata contains the business name or source link.
   • If no source link is known and the user did not provide one, stop and ask the user to provide the business team's scheduling document link.
5. Resolve the target sheet:
   • If a target sheet already exists for the business, update it.
   • If the business is new and a source link is available, create a new sheet in the shared target spreadsheet before generating the Gantt chart.
6. Read the source scheduling spreadsheet and current target sheet.
7. Build the effective date window:
   • Use the user's explicit range if provided.
   • If today is Monday, rebuild the window as today through the next 30 calendar days.
   • Otherwise reuse the target sheet date headers if present; if blank, use today through the next 30 calendar days.
8. Extract demands in the window with Dev schedule, Dev submit date, QA start date, QA owner, Jira/POP IDs, summary, status, and source notes.
9. Calculate Gap = QA测试开始时间 - 需求提测时间.
10. Mark a risk when Gap is greater than the threshold. Use the user-provided threshold when present; otherwise use 2 working days.
11. Generate the target Gantt matrix and compare it with the current target sheet values.
12. If different, clear the stale target range and write the refreshed matrix. If unchanged, report that no update was needed.
13. Summarize business team, source document, target sheet, date window, updated rows, warning demands, missing date fields, and assumptions.

New Business Handling

When the user provides a new business team and a scheduling document link:

• Inspect the scheduling spreadsheet title, sheet names, and first rows to infer source tabs and columns.
• Create a target sheet named <business-team>-甘特图 unless the user names a specific target sheet.
• Write metadata in row 1 so future runs can find the business without relying only on the local registry.
• Generate the Gantt chart using the same output contract.
• Report the new target sheet link.

Do not silently create a new business sheet when the source scheduling document link is missing.

Source Preference

For registered WFM/Driver/Asset/Basic data, read these tabs together:

• 需求设计阶段: authoritative demand list, owner, status, Jira task, FixVersion, long update notes, and functional owners.
• 26Q1 Requirement Gantt: normalized execution/Gantt view with team, task, QA owner, status, waiting category, and timeline.
• [BPM]Q1 26 Roadmap: use only as a fallback for Target UAT/Live context when the first two tabs lack dates.

For new business teams, use the generic tab and column discovery rules in references/sheet-contract.md.

Guardrails

• Never overwrite the 示例 tab.
• Do not update a target sheet if the generated matrix is identical after trimming trailing blanks.
• If source rows have missing or ambiguous dates, keep them in the output warning summary instead of inventing dates.
• Prefer working-day Gap for warnings; include raw dates in the card so humans can audit.
• Treat Done, Live, and Closed demands outside the date window as historical context, not current risk.