Skip to content

[R2-13][P4] Raise public API doc coverage from 14.6% → ≥40% #852

Description

@MichaelFisher1997

Part of #839 — [Audit][Round 2] A++ umbrella.
Phase: P4 · Finding: R2-13

Problem

Public API /// doc coverage is 14.6% (331 of 2,273 non-test pub fn). AGENTS.md mandates: "Use //! for module-level docs, /// for public API documentation". The RHI, world-runtime, and game-ui public surfaces — the boundaries other modules consume — are especially underspecified.

This issue is a sibling of #609#615 (generated API docs pipeline) — those cover generation; this covers content.

Evidence

Round 2 readability audit:

  • Top-level //! module docs: strong — present in major files (lod_manager.zig, log.zig, world.zig)
  • pub const types: mixed — many documented, many not
  • Hot-path pub fn: undocumented — e.g. chooseVertexCapacityMb, processGpuMeshing, applyBlockMutation, renderShadowPass
  • Worst-documented clusters: game-ui screens, engine-rhi interface methods
  • Best-documented clusters: lod_* modules

Coverage by area (approximate)

Area /// coverage Priority
engine-rhi/src/rhi.zig (19 interfaces + 5 wrappers) ~25% High (the central contract)
world-runtime/src/world.zig (33-method vtable) ~15% High (consumed by game layer)
game-ui/src/screens/*.zig ~5% Medium
engine-math, world-core, world-meshing ~40% Low (already decent)

Fix

Tier the work by leverage:

Tier 1 — Document the RHI contract (engine-rhi)

Document every method on every I*Context interface (rhi.zig:107-1089) and every wrapper method. Each /// should answer:

  • Purpose: what does this do?
  • Preconditions: what state must the caller guarantee?
  • Postconditions: what does the backend guarantee?
  • Errors: which RhiError variants and what they mean
  • Threading: main-thread-only? safe from workers?

Pattern:

/// Stages a buffer upload for the next frame's command buffer.
///
/// `offset` is relative to the start of `handle`'s device memory.
/// The upload is queued; it completes no later than the next call to `endFrame`.
///
/// **Errors:**
/// - `RhiError.OutOfMemory` if the staging arena is full
/// - `RhiError.InvalidHandle` if `handle` is 0 or stale
///
/// **Threading:** main thread only.
pub fn uploadBuffer(self: IResourceFactory, handle: BufferHandle, offset: u64, data: []const u8) RhiError!void

Target: 100% /// coverage on engine-rhi. ~150 functions. Lifts overall coverage by ~6%.

Tier 2 — Document the IWorld facade (world-runtime)

Document every method on the 33-method vtable (world.zig) and the 3 role interfaces (IWorldSimulation/Render/Telemetry). Same pattern as Tier 1.

Target: 100% /// coverage on world-runtime public surface. ~165 functions. Lifts overall coverage by ~7%.

Tier 3 — Document game-ui screen lifecycles

Document the public entry points of each screen (init, deinit, update, draw, onInput, onNavigate). Focus on lifecycle invariants — when can each be called?

Target: 80% /// coverage on game-ui. ~85 functions.

Tier 4 — Sweep remaining modules

Add /// to any undocumented pub fn in engine-math (gap), world-core, world-meshing, engine-graphics, etc. Use grep -rE '^pub fn' modules/ | grep -B1 -v '^[^-]*///' to find undocumented ones.

Target end state

  • Overall /// coverage: ≥ 40% (currently 14.6%)
  • Tier 1 + Tier 2 modules: ≥ 90% (the contracts)
  • All pub const types: ≥ 60%

Verification

Constraints

  • Documentation-only PRs — no code changes.
  • One PR per tier (or per module within a tier for reviewability).
  • Conventional commit: docs(engine-rhi): document I*Context vtables, docs(world-runtime): document IWorld facade, etc.
  • Do not add /// to test blocks or fn (non-pub) — out of scope.
  • Each doc comment should answer a real question a consumer would ask. Avoid stub docs like /// Initializes — be specific.

Notes

Tracking: #839

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingdocumentationImprovements or additions to documentationenginegamequestionFurther information is requestedworld

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions