Summary: docs/API.md's table of contents lists sections for Dispute Resolution, Fleet Management, Identity Reputation, and Settlement contracts — none of the four actually appear anywhere in the document body, which only covers Escrow, Delivery, and Shared Types.
Background: docs/API.md:6-12:
- [Escrow Contract](#escrow-contract)
- [Delivery Contract](#delivery-contract)
- [Dispute Resolution Contract](#dispute-resolution-contract)
- [Fleet Management Contract](#fleet-management-contract)
- [Identity Reputation Contract](#identity-reputation-contract)
- [Settlement Contract](#settlement-contract)
- [Shared Types](#shared-types)
Scanning the full document (docs/API.md, 588 lines) confirms ## Escrow Contract (:16), ## Delivery Contract (:234), and ## Shared Types (:394) are the only top-level sections that actually exist — there is no ## Dispute Resolution Contract, ## Fleet Management Contract, ## Identity Reputation Contract, or ## Settlement Contract heading anywhere in the file.
Problem Statement: docs/API.md bills itself as "Complete API documentation for all FaniLab smart contracts," but over half the deployed contracts have zero function-level documentation — no parameters, no authorization requirements, no error tables, nothing — despite the ToC implying otherwise. Anyone clicking those ToC links lands nowhere (broken in-page anchors), and anyone integrating against fleet_management_contract or identity_reputation_contract has no API reference at all, unlike escrow_contract/delivery_contract integrators.
Proposed Solution: Add the four missing sections, documenting each public function's parameters, authorization requirements, errors, events, and state changes, following the exact format already established for the Escrow and Delivery sections.
Acceptance Criteria:
Technical Notes: This is a large but mechanical documentation task — the actual function signatures, authorization checks, and error variants are all directly readable from each contract's lib.rs.
Relevant Files: docs/API.md:1-13, 234-392 (existing pattern to follow)
Testing Requirements: N/A (documentation-only); consider a lightweight CI check (e.g., a script asserting every ToC anchor has a matching heading) to prevent this from recurring.
Definition of Done: docs/API.md's table of contents and body are fully consistent — every linked section exists and documents its contract's real public interface.
Summary:
docs/API.md's table of contents lists sections for Dispute Resolution, Fleet Management, Identity Reputation, and Settlement contracts — none of the four actually appear anywhere in the document body, which only covers Escrow, Delivery, and Shared Types.Background:
docs/API.md:6-12:Scanning the full document (
docs/API.md, 588 lines) confirms## Escrow Contract(:16),## Delivery Contract(:234), and## Shared Types(:394) are the only top-level sections that actually exist — there is no## Dispute Resolution Contract,## Fleet Management Contract,## Identity Reputation Contract, or## Settlement Contractheading anywhere in the file.Problem Statement:
docs/API.mdbills itself as "Complete API documentation for all FaniLab smart contracts," but over half the deployed contracts have zero function-level documentation — no parameters, no authorization requirements, no error tables, nothing — despite the ToC implying otherwise. Anyone clicking those ToC links lands nowhere (broken in-page anchors), and anyone integrating againstfleet_management_contractoridentity_reputation_contracthas no API reference at all, unlikeescrow_contract/delivery_contractintegrators.Proposed Solution: Add the four missing sections, documenting each public function's parameters, authorization requirements, errors, events, and state changes, following the exact format already established for the Escrow and Delivery sections.
Acceptance Criteria:
docs/API.mdcontains a real section for every contract listed in its own table of contents.Technical Notes: This is a large but mechanical documentation task — the actual function signatures, authorization checks, and error variants are all directly readable from each contract's
lib.rs.Relevant Files:
docs/API.md:1-13, 234-392(existing pattern to follow)Testing Requirements: N/A (documentation-only); consider a lightweight CI check (e.g., a script asserting every ToC anchor has a matching heading) to prevent this from recurring.
Definition of Done:
docs/API.md's table of contents and body are fully consistent — every linked section exists and documents its contract's real public interface.