The milestone you are describing is the right one to celebrate, because a human approval gate sitting in the middle of the loop is the part most demos skip and the part that decides whether anyone trusts the output.
The question I would start asking at this stage is what happens on the second run. Generated docs are only useful if they track the repo, so the interesting problem shifts from generating them to detecting that a merged PR invalidated a section, and re-review fatigue is what kills these systems: if every commit reopens the whole approval screen, people start clicking approve without reading.
Scoping the diff so review covers only what actually changed is probably the next thing worth building.
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.
Ahmet Özel
The milestone you are describing is the right one to celebrate, because a human approval gate sitting in the middle of the loop is the part most demos skip and the part that decides whether anyone trusts the output.
The question I would start asking at this stage is what happens on the second run. Generated docs are only useful if they track the repo, so the interesting problem shifts from generating them to detecting that a merged PR invalidated a section, and re-review fatigue is what kills these systems: if every commit reopens the whole approval screen, people start clicking approve without reading.
Scoping the diff so review covers only what actually changed is probably the next thing worth building.