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

Overview

This phase upgrades Discover from "can be written" to "governable and continuously usable":

Products: Converge the business module map to a governable number (default <= 6), providing stable semantic anchors for the requirement phase
Ops: Fix entry points for "runnable, verifiable, rollbackable, troubleshootable" (high ROI)
DoD: Use access control rules to decide whether to allow indexing checkmarks (index checking only reflects facts)
Delta Discover / stale: Enable the knowledge base to be updated incrementally with code changes without rapid expiration

Announce at start: "I am using the project-discover-products-ops-dod skill to converge Products, establish Ops entry points, and implement DoD and incremental maintenance access control."

Products (Business Module Aggregation and Convergence <= 6)

Core Principles

Products are business maps, not full feature lists
Prioritize clustering by "data ownership + external capabilities + organizational boundaries"
Default goal: <= 6; if convergence is not possible, the reason and governance suggestion entry must be clearly stated

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

Data ownership: Which component is primarily responsible for writing which core objects (from module page
```
## Data Contract
```
)
External capability boundary: Which APIs are stable commitments (from module page
```
## API Contract
```
)
Organizational boundary: owner/team division (from
```
components/index.md
```
)
Runtime boundary: Units with independent deployment/SLO (if evidence exists)

products/index.md

minimal template (navigation only)

markdown

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

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

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

products/{product}.md

is recommended to only include "entry-level summaries"

TL;DR (one sentence describing business boundaries)
Capability Catalog (CAP-001 granularity: capability name + one sentence description + evidence entry)
Business Rules Index (rule name + one sentence description + code evidence entry)
Domain Events (event name + one sentence semantic description + evidence entry)

Prohibited: Writing product pages as full lists of fields/interfaces/detailed timelines; details point to code or module pages through evidence entry points.

Ops (Operation Entry Points and Evidence Chain)

Goal

Fix the entry points for "runnable, verifiable, rollbackable, troubleshootable". The Ops page only includes entry points and key points, and does not duplicate long operation manuals.

Recommended storage structure

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

ops/index.md

minimal template

markdown

# Ops Index（入口页）

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

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

## 回滚入口
- Rollback：

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

DoD (Definition of Done) and Access Control

Project-level DoD (minimum self-check)

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

Status consistency access control (SSOT, mandatory compliance)

Single source of truth: Whether a module is allowed to be checked in
components/index.md
is only determined by whether the module page meets the standards.

Prerequisites for allowing
- [x]
for P0 modules
- Module page exists and is navigable:
```
.aisdlc/project/components/{module}.md
```
- Module page includes fixed headings:
```
## TL;DR
```
  ,
```
## API Contract
```
  ,
```
## Data Contract
```
  ,
```
## Evidence (evidence entry)
```
  ,
```
## Evidence Gaps (gap list)
```
- Module page frontmatter includes:
```
change_frequency
```
  ,
```
last_verified_at
```
  ,
```
source_files
```
- Both
```
## API Contract
```
  and
```
## Data Contract
```
  include:
  - Authoritative entry point (locatable)
  - 3–7 invariant summaries
  - Evidence entry point (minimum granularity of file/class/job/command level)
- Module page body must not contain placeholder sentences such as "to be filled/not found/to be filled after.../fill later"; gaps can only be written in
```
## Evidence Gaps (gap list)
```
- If there are gaps, they must be written in
```
## Evidence Gaps (gap list)
```
  , and must not be checked
Degraded conditions for allowing
- [x]
for P1 modules
- Module page exists; either API or Data can be missing, but gaps must be structured and written in
```
Evidence Gaps
```
P2 modules
- Not checked by default; only placeholder navigation is required

Incremental Discover (Delta Discover) and Expiration Detection (stale)

When to trigger Delta Discover

When Merge-back is completed (new ADR/contract/capability introduced)
When PR involves changes to key source files of P0/P1 modules
When a module is marked as stale

Minimum execution scope of Delta Discover (stop loss)

Identify affected modules (according to the changed file list and module page
```
source_files
```
)
Only update the following content for these modules:
- ```
.aisdlc/project/components/{module}.md
```
  (TL;DR, contract sections, invariants, Evidence/Evidence Gaps)
- ```
.aisdlc/project/components/index.md
```
  (navigation links, dependency graph, check status)
Update module page metadata:
- ```
last_verified_at
```
- ```
source_files
```
  (if boundaries change)

Writing suggestions for stale (storage format not mandatory)

Module page reflects "freshness" through
```
last_verified_at
```
When a module is stale:
- Do not continue writing requirements/designs by "ignoring expiration"
- First perform Delta Discover (minimum scope) to update key invariants and evidence entry points to usable status

Red Flag List

Products are written as feature lists of dozens of modules (map becomes invalid)
Ops is written as a long operation manual (should only include entry points and key points)
Checkmark is given without checking module page content (violates SSOT access control)
Continue to use stale modules as authoritative input (should perform Delta Discover first)

Common Mistakes

Using placeholders like "to be filled/not found" instead of Evidence Gaps (gaps will always be scattered)
Only do full Discover once, no incremental maintenance (knowledge expires quickly)

project-discover-products-ops-dod

NPX Install

Tags

SKILL.md Content (Chinese)