Document service interfaces and integration contracts

Structure the documentation file as follows: (1) Overview — purpose of the epic, Bufdir reporting context, pipeline summary; (2) Data Flow Diagram — Mermaid sequenceDiagram or flowchart showing the 5-stage pipeline; (3) Service Reference sections (one per service) — interface definition, parameters, return values, error handling, code example; (4) Integration Guide — complete orchestrator pattern showing services wired together; (5) Error Handling Reference — consolidated table of all exceptions across services. For code examples, use realistic but synthetic data (no real org names). Mermaid is preferred over ASCII for diagrams as it renders natively in GitHub and most documentation platforms. When documenting error contracts, distinguish between recoverable errors (e.g., missing attachment → logged, excluded) and fatal errors (e.g., database connection failure → exception propagated).

The integration guide example should mirror the pattern the orchestrator epic will actually use — coordinate with the orchestrator epic author to ensure alignment before finalizing.

No automated tests required for documentation tasks. Manual review checklist: (1) verify all public method signatures match current source code; (2) confirm code examples compile without errors by running dart analyze on snippets; (3) confirm Mermaid diagram renders correctly in GitHub Markdown preview; (4) peer review by one other developer who was not the author to confirm clarity and completeness.