Message courier service
← All revisions
fix(services): add dated Correction callouts to 10 of 13 services/ batch-1 articles — worst defect ratio of any category (fabricated proofreader/message-courier/chart-of-accounts mechanics, reversed egress data-flow direction, wrong Graph vs real EWS integration, wrong extraction routing model, understated service-fs capability; private-git-paid-customer-endpoint.md finding disproven, agent checked wrong crate, no correction applied; service-input.md and service-fs-data-lake.md already correctly self-corrected
@@ -15,6 +15,8 @@ cites: [] paired_with: message-courier.es.md --- **Correction (2026-08-02, verified against canonical `origin/main`):** the real `service-message-courier.py` (60 lines) is a thin CLI that dynamically loads a private adapter module and calls `execute_payload()` — the "Query (poll WORM ledger) → Execute → Write-back" three-step engine-level cycle described below is not present in the engine itself; no WORM-ledger or browser-automation code exists at the engine layer in the real codebase. **Flagged, not resolved.** **`service-message-courier`** is the headless web-automation engine that bridges the platform's internal [[service-people|identity ledger]] with external web portals — without embedding any client-specific logic in the open-source codebase. The core engine reads pending dispatch records from the [[worm-ledger-design|WORM ledger]], executes portal interactions through privately distributed runtime adapters, and writes completion timestamps back; the engine itself remains free of hard-coded selectors, credentials, or target URLs. The adapter directory (`private-adapters/`) is excluded from version control so proprietary client operational data never enters the public Git history. ## Key Takeaways