FS anchor emitter
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 @@ editor: pointsav-engineering paired_with: fs-anchor-emitter.es.md --- **Correction (2026-08-02, verified against canonical `origin/main`):** the architecture below is reversed and the env vars are wrong. The real `service-fs/anchor-emitter/src/main.rs` reads `FS_ENDPOINT`, `FS_MODULE_ID`, and `REKOR_URL` — not `FS_LEDGER_ROOT`/`FS_SIGNING_KEY`/`FS_ANCHOR_INTERVAL` (those are `service-fs`'s own variables, not the emitter's). The real flow is: (1) `GET /v1/checkpoint` from `service-fs` — the emitter *fetches* an already-generated checkpoint, it does not itself read the tile tree or generate the checkpoint; (2) build a Sigstore hashedrekord entry; (3) `POST` to the Rekor v2 log; (4) `POST` the tlog entry back to `service-fs /v1/append`. The general subject (monthly Rekor anchoring of WORM checkpoints) is real and accurate — see the separately-verified `governance/doctrine-invention-7-rekor-anchoring.md`, which describes this correctly. **Flagged, not resolved** — this article's specific config/architecture section needs rewriting to match the real fetch-not-generate flow. `fs-anchor-emitter` is the component that generates signed checkpoints of the immutable [[worm-ledger-design|Write-Once-Read-Many ledger]] at hourly cadence and prepares them for external anchoring to the Sigstore Rekor transparency log on a monthly schedule — the mechanism that makes the platform's ledger state cryptographically auditable from outside the platform itself. The emitter operates at Layer 4 of the WORM stack as described in [[service-fs-architecture]], reads the latest state of the per-tenant tile tree, generates a `signed-note` checkpoint, and stores it at the authoritative path under `$FS_LEDGER_ROOT/<moduleId>/checkpoint`. The monthly workspace anchoring process consumes those checkpoints and posts them to the public transparency log. ## Configuration Requirements