Pre-Flight Readiness Check

Updated: 2026-07-21 10:41 ET

TL;DR: A short, chainable inventory pass answering one question for a feature area: what is still pending here? Run the seven checks below, produce the pending-items table, and hand it to whatever comes next — a Fresh-Eyes Panel (it becomes the exclusion-list input), a tester graduation, a device/pipeline build, or a release note. This SOP finds and lists; it never fixes, and it makes no judgment calls beyond "pending vs settled".

The panel and the pre-flight are deliberately separate: the panel is discovery ("what doesn't make sense?"), the pre-flight is inventory ("what's already known to be open?"). Chaining them in that order keeps the panel from rediscovering the backlog.

1 · When to run

Before a Fresh-Eyes Panel — its output is the panel's Phase-1 exclusion list.
Before graduating an area to testers (To Test row, walkthrough publication).
Before requesting a device/pipeline build for stakeholder testing.
Before a release cut that includes the area.

2 · The seven checks

#	Check	How
1	Open work items touching the area	`az boards query` (WIQL) for non-Closed items whose title/area matches; include the parent Epic's children. Note state and blocker relationships.
2	Unmerged PRs touching the area's files	`az repos pr list --status active`; flag any that would conflict with or invalidate current findings.
3	Open design questions	design-questions.html — DQ rows still badged Open that name the area's components.
4	Audit rows not yet FIXED	The area's audit doc — any finding row without a closing disposition, plus explicit keep-decisions (those are settled, but list them: downstream steps need to know they exist).
5	Known backend/service outages the area depends on	Open Bugs of the AB#2300 class (service returns errors independent of app code) and any mock-pinned data paths awaiting a rollout.
6	Test posture	Latest suite run for the area: which tests skip and why (credential gates, environment), which are flaky, and whether the readiness-page row states (VM/DATA/CMD/CMP chips) match reality.
7	Doc currency	Walkthrough vs current UI (do screenshots/clips show the shipped design?), tester-guide row mirror, spec-doc timestamps on the area's components.

3 · Output — the pending-items table

One table, one row per pending item: [source check] [item] [state] [owner/blocked-on] [affects next step how]. Settled-but-relevant records (keep-decisions, dispositioned audit rows) go in a second short list — they are not pending, but the next step's operator must know they exist. Post the table in the conversation or, when the next step is formal (release, graduation), as a dated section in the area's audit doc.

4 · Chaining

→ Fresh-Eyes Panel: pending-items table + settled-records list = the panel's exclusion list (Phase 1). Run the pre-flight first, always.
→ Tester graduation: checks 6–7 gate the To Test row; checks 1–5 feed the walkthrough's "What's not covered yet" section.
→ Device/pipeline build: the pending table goes in the build handoff note so the person testing on device knows what is expected to be broken (e.g. a known 503) versus new.

5 · Rules

Inventory only. Nothing is fixed, closed, or re-prioritized during a pre-flight — that's triage, and it happens with the user afterward.
Query, don't recall. Every check hits the live source (Boards, PR list, the actual docs) — never memory of them. Stale registries are how "done" areas ship with open Bugs.
Time-box it. A pre-flight is minutes, not hours. If a check spawns real investigation, that investigation is a finding for the table, not a detour.

Fresh-Eyes Panel Procedure — the discovery pass this feeds
Feature Alignment Check — architectural readiness counterpart
Tester Guide · Testing