Skip to content

feat(wiki): incremental regeneration so the generated wiki does not rot #359

Description

@cdeust

Context

A one-shot generator produces a wiki that was correct on the day it ran. Both halves of the alternative already exist and are not wired to each other:

  • ai-architect-mcp-codebase: detect_changes and co-change edges
  • Cortex: staleness detection, the groomer, wiki_reindex

Until they are connected, a generated wiki has the same decay profile as any one-shot tool, which removes the main reason to choose a pipeline with a memory layer in it.

Verified 2026-08-06: the nearest competing documentation generator writes into a date-stamped directory (<TOOL>-<YYYY-MM-DD>/) and has no regeneration path. A second run produces a second directory, not an update to the first. That is structural to a one-shot orchestration, not an oversight someone will patch. Freshness is therefore the one axis where a memory layer is a moat rather than a tax, and it is the least contested item in this series.

Scope

Wire change detection to selective page regeneration.

Acceptance criteria

  1. After a change touching N files, only the pages whose backing symbols changed are regenerated. Asserted with a fixed change set and a count assertion on regenerated pages — not "completed without exception".
  2. A page whose backing code changed and which was not regenerated is marked stale in its front-matter and in wiki_list. Both are asserted.
  3. A deleted symbol invalidates the claims citing it: a file:line citation pointing at code that no longer exists is detected, and the detection itself is asserted (the signal, not a downstream effect).
  4. Idempotent: running twice with no intervening change regenerates nothing. Asserted with a count of zero.
  5. Provenance tags survive regeneration; a regenerated page does not downgrade extracted claims to authored.
  6. Scoped mutation run on the changed files: zero surviving non-equivalent mutants, or each survivor documented as equivalent.
  7. Completion Ledger in the PR.

Depends on

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions