• 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 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

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)

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

undefined

• 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.

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

• Dashboard：
• Alerts：
• Logs：

• Rollback：

• 缺口：
  • 期望补齐到的粒度：
  • 候选证据位置：
  • 影响：

undefined

• 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

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

• 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

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)

• 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

• 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)

• 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)