DataGraph Federation: From app-orchestration-slm to app-orchestration-graph
fix(architecture): add dated Correction callouts to 13 of 28 architecture/ articles, verified against canonical origin/main — repeated Apache-2.0-for-core-OSes license error (3 articles), fictional os-orchestration-graph design (already shipped differently), doctrine document citing a source that doesn't contain it (internally contradictory 52-vs-54 claim count), fabricated marketplace pricing, wrong Tier A model size contradicting sibling article, 4-tier pairing model repeating the how-to/ systemic defect; 11 verified clean, 4 already self-corrected
@@ -97,6 +97,8 @@ non-trivial DataGraphs, or the appearance of a second consumer. ## What app-orchestration-graph Is Intended to Own **Correction (2026-08-02, verified against canonical `origin/main`):** `app-orchestration-graph` isn't a future extraction target — it already exists as a substantial scaffold (`src/main.rs`, `src/capability.rs`), and its real, already-built design differs from every prediction below. The real endpoint is `GET /v1/graph/context`, not `POST /v1/graph/federated`; real archive discovery is a static `ORCHESTRATION_GRAPH_TARGETS` env var of `archive_name|endpoint|module_id` triples, not automatic FleetRegistry-based fanout; the real response includes `warnings`/`archives_queried`/`archives_responding` fields, not a `partial: true` flag; and the real code implements Ed25519 capability-forwarding/pairing, unmentioned anywhere below. Port `:9181` is independently confirmed correct. **Flagged, not resolved** — this section needs a rewrite around the real, already-shipped design rather than a still-future intent. When extracted, `app-orchestration-graph` is intended to own: - The `POST /v1/graph/federated` endpoint and all fanout logic (moved from