mat

0 Followers · 0 Following

• Joined on 2025-11-02

Repositories

1

Projects Packages Public Activity Starred Repositories

rust-crate-docgen (0.1.43)

Published 2026-04-26 11:06:32 +02:00 by mat

Installation

Set up this registry in the Cargo configuration file (for example ~/.cargo/config.toml):

[registry]
default = "gitea"

[registries.gitea]
index = "sparse+" # Sparse index
# index = "" # Git

[net]
git-fetch-with-cli = true

To install the package using Cargo, run the following command:

cargo add rust-crate-docgen@0.1.43

For more information on the Cargo registry, see the documentation.

About this package

rust-crate-docgen

Bootstrap pack for a structure-first Rust crate documentation automation tool.

Purpose

rust-crate-docgen is intended to automate documentation generation, validation, and publication-readiness for Rust crates by discovering facts from repository structure instead of relying on hand-maintained adapters.

Target outcome:

1. generated docs stay aligned with current code
2. published crate docs on docs.rs stay discoverable
3. examples and snippets are validated, not trusted
4. the tool can document itself using the same structure it expects from other crates

Why this project exists

Current crates in this repository already show the same recurring problems:

• public capability exists in code, but is hard to discover in published docs
• generated API references exist, but they are raw and hard to use as onboarding docs
• runnable examples drift from current structure or only demonstrate inline usage
• design docs and current supported contract get mixed together
• LLM-authored prose can drift unless machine-validated against code and examples

This project is meant to solve those problems once in a reusable way for:

• agent-flow
• plan-kit
• later agent-cli
• other Rust crates following the same structure

Primary design decision

Version 1 is structure-first:

• no project-specific adapters
• no hand-maintained semantic mapping layer
• repository convention is the contract
• tool discovers everything it can from folder structure, code, examples, tests, and generated artifacts

If a future problem cannot be solved through structure, it may justify a narrow configuration layer later. That is not part of the initial design.

Current bootstrap surfaces

This folder now contains bootstrap assets for autonomous implementation:

• machine-readable repository contract in docgen/spec/
• fixture matrix in docgen/spec/fixture-matrix.json
• ordered workpacks in docgen/workpacks/
• minimal crate scaffold in Cargo.toml, src/, examples/
• fixture crates in tests/fixtures/
• hook and version-bump wiring in repository root

Current code now exposes scan/generate/verify through library facade and CLI, while keeping bootstrap inspection commands for compatibility.

Generated docs under docgen/generated/ are committed publish inputs for this crate. Normal crate changes should regenerate those files before commit, then commit source plus generated docs together:

cargo run --quiet --manifest-path rust-crate-docgen/Cargo.toml -- generate rust-crate-docgen

bash rust-crate-docgen/run-unit-tests.sh and source-publish workflow both fail when committed generated artifacts are stale. Publish uses committed tree and checks packaged source crate still contains every committed generated file.

Install CLI

rust-crate-docgen keeps one version for source crate publish and CLI bundle distribution. Same publish workflow run that pushes crate to Gitea registry also uploads linux x86_64 CLI bundle artifact from same commit.

• install from source crate registry when local Rust toolchain is fine:

cargo install --locked --registry gitea rust-crate-docgen --version <version>

• download prebuilt workflow artifact rust-crate-docgen-cli-linux-x86_64-v<version> when consumer wants standalone executable. Uploaded bundle contains:
  • rust-crate-docgen-v<version>-linux-x86_64.tar.gz
  • rust-crate-docgen-v<version>-linux-x86_64.tar.gz.sha256
  • binary-release-manifest.json

tar -xzf rust-crate-docgen-v<version>-linux-x86_64.tar.gz
./rust-crate-docgen-v<version>-linux-x86_64/rust-crate-docgen scan <crate-root>

Two usage modes

The final project should support two equally important ways of use.

1. CLI tool use

Run against a crate root and perform tasks such as:

• extract facts
• generate docs
• generate example assets
• verify freshness with explicit verify-freshness command
• validate snippets
• smoke-test examples

Final command shape:

rust-crate-docgen scan <crate-root>
rust-crate-docgen generate <crate-root>
rust-crate-docgen verify <crate-root>

Current command shape:

rust-crate-docgen scan <crate-root>
rust-crate-docgen generate <crate-root>
rust-crate-docgen verify <crate-root>
rust-crate-docgen quality-report <crate-root>
rust-crate-docgen verify-freshness <crate-root>
rust-crate-docgen bootstrap-status <crate-root>
rust-crate-docgen contract print <crate-root>

verify-freshness replaces ambiguous verify freshness so rust-crate-docgen verify freshness now honors documented verify [crate-root] contract for crate roots literally named freshness.

2. Programmatic dependency use

Other tools and pipelines should be able to depend on the library and call it directly.

Expected consumers:

• release automation
• doc pipelines in other Rust tools
• larger orchestration tools that want doc generation/verification as one stage

Final API shape:

let facts = rust_crate_docgen::scan(crate_root)?;
let artifacts = rust_crate_docgen::generate(&facts)?;
rust_crate_docgen::verify(crate_root, &artifacts)?;

Current library API shape:

use rust_crate_docgen::api::{generate, scan, verify, ScanRequest};

let scan_report = scan(&ScanRequest::new(crate_root))?;
let generated = generate(&scan_report.generate_request())?;
let verified = verify(&scan_report.verify_request())?;
assert!(generated.docs_fragments.fragment_count > 0);
assert!(verified.is_success());

Machine-readable quality summary:

use rust_crate_docgen::api::{quality_report, scan, ScanRequest};

let scan_report = scan(&ScanRequest::new(crate_root))?;
let quality = quality_report(&scan_report.verify_request())?;
assert!(matches!(quality.status, rust_crate_docgen::api::QualityStatus::Pass));
# Ok::<(), Box<dyn std::error::Error>>(())

Self-hosting goal

The project should be able to generate and validate documentation for itself.

That means repository structure defined here is not only internal plan; it is first real example future tool should be able to consume.

Repository structure

Current canonical layout:

rust-crate-docgen/
  Cargo.toml
  Cargo.lock
  README.md
  src/
  examples/
  tests/
    fixtures/
  docs/
    contract/
    design/
  docgen/
    generated/
    scenarios/
    spec/
    workpacks/

Important documents and machine inputs

• docs/design/findings.md — motivation gathered from repo review
• docs/design/architecture.md — top-to-bottom design for library and CLI
• docs/design/roadmap.md — implementation phases
• docs/contract/published-surfaces.md — docs.rs contract
• docs/contract/repository-structure.md — canonical repository layout contract
• docgen/spec/repository-contract.json — machine-readable repository contract
• docgen/spec/fixture-matrix.json — machine-readable fixture inventory
• docgen/workpacks/index.json — ordered implementation queue

Current state

This crate now ships library facade plus CLI facade over same engine.

Dependencies

ID	Version
serde	^1
serde_json	^1
syn	^2
thiserror	^2
toml	^0.8

Details

Cargo

2026-04-26 11:06:32 +02:00

3

86 KiB

Assets (1)

rust-crate-docgen-0.1.43.crate 86 KiB

Versions (5) View all

0.1.51 2026-04-27

0.1.50 2026-04-26

0.1.47 2026-04-26

0.1.44 2026-04-26

0.1.43 2026-04-26