project-discover-preflight-scope

project-discover-preflight-scope (Step0+1: Evidence Entry Inventory + Scope Stop-Loss)

Overview

The goal of Preflight is not to "write out all the information," but first to executable/locatable evidence entry points take clear inventory of; the goal of Scope is first to coverage stop-loss(P0/P1/P2), to avoid reverse engineering becoming "write everything but unmaintainable."

At the start, announce:"I am using the project-discover-preflight-scope skill to execute Discover's Preflight and Scope stop-loss."

Input / Output

• Input
  • Repository root directory (code, configuration, dependencies, CI/CD configuration)
  • Existing documentation entry points (README/Makefile/package.json/scripts, etc.)
  • Observability/ops entry points (if present: dashboard, alerts, runbook, rollback)
• Output (written to disk)
  • .aisdlc/project/components/index.md: Module inventory + P0/P1/P2 + code_entry + checkboxes (not checked at this point)
  • .aisdlc/project/memory/structure.md: Pin down the entry points for "how to run/how to verify/how to release" in the form of links (the next sub-skill will formally write them)
  • Note: Preflight's "evidence entry inventory" does not need a separate new file; it is recommended to gradually distribute and place it as "entry links + Evidence Gaps" into memory/*, module pages and ops/*

Core Principles (Preflight)

1. Prioritize executable evidence
   • Priority: scripts/CI jobs/contract files/migrations/generation commands > descriptive documentation > verbal experience
2. Only record "entry points," do not write inferences
   • What you need to write is "where to enter from, how to locate it, which file/which job the evidence is in," not "how it should work"
3. Missing evidence = structured gap
   • Write into the subsequent documentation's ## Evidence Gaps: gap/expected granularity/candidate location/impact

Preflight Minimum Checklist (find evidence entry points)

As long as a specific file or job name can be located, it counts as a valid entry point; do not make things up just to "write complete documentation."

• Run entry points
  • Local startup script/command entry points (for example:package.json scripts、Makefile、*.ps1/*.sh、docker-compose、k8s manifest）
  • Environment variable entry points (for example:.env.example, configuration templates, helm values)
• Test entry points
  • Command entry points and directory entry points for unit/integration/E2E tests
  • Coverage/quality gate entry points (for example: CI jobs, test threshold configuration)
• CI/CD entry points
  • workflow/pipeline file locations + key job names
  • Whether there are quality gates such as docs/link-check (if not, this can serve as a subsequent suggestion)
• Contract/structured fact entry points
  • OpenAPI/Proto/GraphQL schema
  • DB migrations/DDL/ORM models
• Observability/ops entry points (if any)
  • dashboard, alerts, log query entry points, runbook, rollback entry points

Scope (P0/P1/P2) Rules

Tiering suggestions (aligned with Discover DoD)

• P0 (must): high-frequency changes, cross-team boundaries, many external integrations, incident/failure hotspots, high compliance risk
• P1 (recommended): Stable but frequently referenced/asked about/depended-upon foundational capabilities
• P2 (on demand): Low risk, low collaboration, short lifecycle; create an index placeholder first, upgrade later if necessary

Reverse-engineering depth stop-loss (hard constraint)

• P0: Must ultimately have a module page .aisdlc/project/components/{module}.md, and the page must simultaneously contain ## API Contract + ## Data Contract + ## Evidence(gaps can only be written to Evidence Gaps, and this module must not be checked off)
• P1: Must ultimately have a module page; one of API or Data may be downgraded to Evidence Gaps (recording gaps and impact)
• P2: Only index placeholder navigation (no module page created by default)

components/index.md(Scope persisted) minimal template

Index navigates only: This table does not write invariants, does not write fields, and does not write "to be filled in/not found". Gaps are uniformly left to the module page's Evidence Gaps。

# Components Index（地图层：只导航）

| module | priority | owner | code_entry | api_contract | data_contract | ops_entry | status |
|--------|----------|-------|------------|--------------|---------------|-----------|--------|
| auth | P0 | team-x | `src/auth/` | [api](./auth.md#api-contract) | [data](./auth.md#data-contract) | [ops](../ops/index.md) | - [ ] |
| order | P1 | team-y | `src/order/` | [api](./order.md#api-contract) | [data](./order.md#data-contract) |  | - [ ] |
| legacy-tooling | P2 |  | `tools/legacy/` |  |  |  | - [ ] |

Parallelization suggestions

When entry-point inventory tasks are mutually independent, parallelization is recommended:

• Agent A: Runtime entry points + environment variable entry points
• Agent B: Test entry points + quality gate entry points
• Agent C: CI/CD entry points
• Agent D: Contract/Schema/DDL entry points + Ops entry points

Red flag checklist

• Scope hasn't been done yet, and you start writing details for a bunch of modules (scope will inevitably spiral out of control)
• Using "I guess it should be..." to fill in runtime/test/contract (Evidence Gaps must be written)
• Writing "main classes/core tables/error codes/field lists" in the index (the index only navigates)

Common mistakes

• Turning Preflight into "writing a README tutorial" (it should only fix entry points and the evidence chain)
• Trying to cover all modules at once (the P0 trio should come first)