Great catch — you're describing exactly the tension I'm sitting in.

The second-run story is partially built: the pipeline's first node diffs against last_processed_commit, so incremental runs only re-parse and re-generate docs for changed files, and the review queue is scoped to those. The full-repo re-approval problem doesn't exist on paper.

The honest gap is what you hinted at with "invalidated a section": Invalidation is file-level, not dependency-aware. If auth.py changes, the docs for modules importing it aren't flagged. The AST call graph is already extracted by the parser, so dependent-aware invalidation is the natural next step — likely a Part 8 topic. Thanks for reading so closely.

That clarifies the second-run behavior: changed-file review is already scoped, and dependency invalidation is the remaining gap. I would start that extension with a distinction between interface changes and implementation-only changes, rather than reopening every transitive dependent whenever auth.py changes.

A reverse dependency graph can identify candidates, but each queued section should say which referenced contract changed and why its documentation might now be wrong. A small replay test with one changed return type and one internal refactor would show whether the expansion catches real invalidation without bringing back the review fatigue you have already avoided.