Architecture

System Overview

The diagram above shows how Git2Docs processes your code and delivers documentation to users. Each component plays a specific role in the pipeline.

Data Flow

1. Trigger - A GitHub release event or manual trigger initiates the process.
2. Clone - The worker clones your repository at the specified tag/branch.
3. Analyze - The documentation engine analyzes the codebase structure and content.
4. Generate - AI processes the analysis and generates documentation content.
5. Store - Generated content is stored in the database with version tracking.
6. Serve - The web app serves documentation to users through the portal.

Feedback Loop

Git2Docs has three feedback paths that all converge on the same consolidator-and-regen pipeline:

• Tell AI — maintainer leaves structured feedback on any section. Submit Review batches the open comments, Claude proposes a brief patch + the affected pages, Apply commits the brief and queues per-page regens. The primary refinement path for routine fine-tuning.
• Runtime validation (Tier 1) — an external coding agent exercises every documented CLI / API call against the live deployment and produces a findings file. Failed findings ingest as doc_comment rows tagged with the validator's identity; the maintainer clicks Tell AI on each real failure and the same consolidator picks them up.
• Hand-edit — direct edits to a section flip it to human_owned; future AI regeneration leaves it alone. Reserved for surgical changes where invoking the AI would be overkill. If AI detects that the underlying code changed in a way that affects a human_owned section, it raises a contested state for review.

Three paths, one pipeline. Maintainer feedback and validator findings both become structured signals the synthesizer reads on the next pass — the docs converge on reality without anyone rewriting them by hand.

Deployment

Git2Docs is designed for cloud deployment with the following components: