project-discover-products-ops-dod

project-discover-products-ops-dod (Step5+6+7+11: Products + Ops + DoD + incremental maintenance)

Overview

This stage upgrades Discover from "able to write it out" to "able to govern it, able to keep it continuously usable":

• Products: consolidate the business module map to a governable number (default <= 6), providing a stable semantic anchor for the requirements stage
• Ops: fix the entry points for "can run, can verify, can roll back, can troubleshoot" (high ROI)
• DoD: use gate rules to decide whether the index check is allowed (the index check only reflects facts)
• Delta Discover / stale: enable the knowledge base to update incrementally as the code changes, without quickly becoming stale

At the start, announce:"I am using the project-discover-products-ops-dod skill to consolidate Products, establish Ops entry points, and execute the DoD and incremental maintenance gate."

Products (business module aggregation and consolidation <= 6)

Core principles

• Products is thebusiness map, not an exhaustive list of features
• Prioritize clustering by "data ownership + external capabilities + organizational boundaries"
• Default target: <= 6; if consolidation is not possible, the reason and the governance recommendation entry point must be stated

High-signal clues for reverse-engineering Products from code (recommended order)

1. Data ownership: which components primarily write which core objects (from the module page ## Data Contract）
2. External capability boundaries: which APIs are stable commitments (from the module page ## API Contract）
3. Organizational boundaries: owner/team division (from components/index.md）
4. Runtime boundaries: units that are independently deployed/with SLOs (if evidence exists)

products/index.md Minimal template (navigation only)

# Products Index（业务地图：只导航）

> 建议收敛到 <= 6 个业务模块。这里不是功能清单。

| product | owner | entry | related_components | status |
|---|---|---|---|---|
| commerce | team-a | ./commerce.md | auth, order, payment | - [ ] |

products/{product}.md It is recommended to write only an "entry-level summary"

• TL;DR (one-sentence business boundary)
• Capability Catalog (CAP-001 granularity: capability name + one sentence + evidence entry point)
• Business Rules Index (rule name + one sentence + code evidence entry point)
• Domain Events (event name + one-sentence semantics + evidence entry point)

Prohibited: writing the product page as an exhaustive list of fields/interfaces/detailed sequence diagrams; details point to code or module pages through evidence entry points.

Ops (runtime entry points and evidence chain)

Objective

Fix the entry points for "can run, can verify, can roll back, can troubleshoot". The Ops pageonly does entry points and key points, without repeating long operation manuals.

Recommended on-disk structure

.aisdlc/project/ops/
  index.md
  runbook.md
  monitoring.md
  rollback.md

ops/index.md Minimal template

# Ops Index（入口页）

## 运行入口
- 本地启动：../memory/structure.md#入口
- 环境变量/配置：<权威入口>

## 可观测入口
- Dashboard：
- Alerts：
- Logs：

## 回滚入口
- Rollback：

## Evidence Gaps（缺口清单）
- 缺口：
  - 期望补齐到的粒度：
  - 候选证据位置：
  - 影响：

DoD (Definition of Done) and gate

Project-level DoD (minimal self-check)

• Level-0 four Memory documents have "clear entry points/clear boundaries/navigable"
• Level-1 index skeleton has been generated (components/products), and the index only navigates
• components/index.md Includes a cross-module dependency graph (Mermaid, direct only)
• Each P0 module page satisfies: module page exists + fixed headings are complete (including ## Evidence and ## Evidence Gaps) + frontmatter metadata is complete + contract sections have authoritative entry points/invariants/evidence entry points
• Products converge to <= 6; or the reason for non-convergence and the governance recommendation entry point have been recorded

State consistency gate (SSOT, must be followed)

Single source of truth: whether the module is allowed to be checked at components/index.md is determined only by whether that module page meets the standard.

• P0 modules allow - [x] prerequisites for
  • Module page exists and is navigable:.aisdlc/project/components/{module}.md
  • Module page contains fixed headings:## TL;DR、## API Contract、## Data Contract、## Evidence（证据入口）、## Evidence Gaps（缺口清单）
  • Module page frontmatter contains:change_frequency、last_verified_at、source_files
  • ## API Contract and ## Data Contract both contain:
    • Authoritative entry point (locatable)
    • 3–7 invariant summary
    • Evidence entry point (minimum granularity at file/class/job/command level)
  • The module page body must not be scattered with placeholder sentences such as "to be added/not found/to be filled in after.../to be added later"; gaps may only be written into ## Evidence Gaps（缺口清单）
  • If gaps exist, they must be written into ## Evidence Gaps（缺口清单）, andmust notbe checked
• P1 modules allow - [x] downgrade conditions for
  • Module page exists; either API or Data may be missing, but gaps must be structurally written into Evidence Gaps
• P2 modules
  • Not checked by default; placeholder navigation is sufficient

Incremental Discover (Delta Discover) and stale detection (stale)

When to trigger Delta Discover

• When Merge-back is completed (introducing new ADRs/contracts/capabilities)
• When a PR involves changes to key source files of P0/P1 modules
• When a module is marked as stale (outdated)

Minimum execution scope of Delta Discover (stop-loss)

1. Identify affected modules (based on the changed file list and module page source_files）
2. Only update these modules':
   • .aisdlc/project/components/{module}.md(TL;DR, contract paragraphs, invariants, Evidence/Evidence Gaps)
   • .aisdlc/project/components/index.md(navigation links, dependency graph, check status)
3. Update module page metadata:
   • last_verified_at
   • source_files(if the boundary changes)

Suggested way to write stale (not a mandatory on-disk form)

• Module page reflects "freshness" through last_verified_at Reflects “freshness”
• When a module is stale:
  • Do not continue writing requirements/design using "ignore outdated"
  • First do Delta Discover (minimum scope) to update key invariants and evidence entry points to a usable state

Red flag checklist

• Products is written as a feature list of dozens of modules (map becomes ineffective)
• Ops is written as a long operation manual (should only provide entry points and key points)
• Checking without looking at module page content (violates the SSOT gate)
• A module is stale but is still treated as authoritative input (Delta Discover should be done first)

Common mistakes

• Using "to be added/not found" placeholders instead of Evidence Gaps (gaps will be scattered forever)
• Doing only one full Discover without incremental maintenance (knowledge quickly becomes outdated)