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

Overview

• 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

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)

1. Data ownership: Which component is primarily responsible for writing which core objects (from module page

   ## Data Contract

   )
2. External capability boundary: Which APIs are stable commitments (from module page

   ## API Contract

   )
3. Organizational boundary: owner/team division (from

   components/index.md

   )
4. Runtime boundary: Units with independent deployment/SLO (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

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

Recommended storage 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 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)

1. Identify affected modules (according to the changed file list and module page

   source_files

   )
2. 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)
3. 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)