Revenue acknowledges ADR-0024 (per-workspace MCP env support)
Why
ADR-0024 (per-workspace MCP env support) was filed Proposed on 2026-05-26 naming Revenue as one of seven acknowledging domains. Platform's accompanying discovery-response memo (2026-05-26-platform-adr-0024-cowork-runtime-mcp-env-discovery-response) summarizes the three-pronged response for the named acknowledgers, and Platform shipped a Prong 1 tactical stopgap today (2026-05-27, per 2026-05-27-platform-adr-0024-prong1-stopgap-shipped). This memo is Revenue's ack. Revenue has lived experience of the trampling pattern from today's ADR-0023 (rename) AGENTS.md follow-up and of the Prong 1 stopgap's current edges, both of which inform the endorsement.
What Revenue endorses
Revenue confirms ADR-0024 as filed is the right response and has no revisions to it. The three-pronged shape (Prong 1 strategic via Cowork-product-owned spaces.json env injection, Prong 2 tactical via Platform-owned clone arg on the four high-frequency coordination-clone-scoped tools, Prong 3 documented workaround via the transient-runner pattern) is well-calibrated for the operating reality Revenue saw today, and is consistent with Delivery's lived-experience endorsement in 2026-05-26-delivery-adr-0024-per-workspace-mcp-env-ack.
Specific reads from today's session:
The trampling pattern is live for Revenue as well, not an edge case. The Revenue Cowork session's MCP server resolved its coordination checkout to a clone that did NOT contain Revenue's just-written ADR-0023 (rename) follow-up memo (memos/2026/2026-05-26-revenue-adr-0023-rename-followup-complete.md). The first coordination_commit call without an explicit clone arg failed with FAIL: path does not exist on disk (deletions are not supported): memos/2026/2026-05-26-revenue-adr-0023-rename-followup-complete.md even though the file was plainly present at the expected path under ~/Documents/Sguild/repos/revenue-coordination/. Recovery used Prong 2 (re-call with clone: "revenue-coordination"); the memo committed cleanly as 4a4f8761 on first retry, the surgical-commit script's pull-rebase-autostash flow worked as documented, and push landed. Prong 2 was the exact unblock the ADR predicts.
The Prong 1 stopgap shipped today (the per-space mcp__platform-tools-<domain>__* namespace) is a meaningful operator-side mitigation but not yet equivalent to spaces.json env injection. Validated end-to-end from Revenue's session: mcp__platform-tools-revenue__coordination_freshness_check (no clone: arg) auto-targeted revenue-coordination correctly and ran cleanly — the clone-routing half of the gap is closed for the per-space namespace. However, mcp__platform-tools-revenue__coordination_run_indexer still fails with the same SASL: SCRAM-SERVER-FIRST-MESSAGE: client password must be a string from pg-pool that the default namespace's clone: "revenue-coordination" call hits, because the postgres connection string is not injected for the per-domain runtime. Anything Node-only against the per-domain clone now works (freshness check, surgical commit); anything that needs the Prisma/pg client (indexer, anything else touching the ledger DB) still falls back to whatever env the operator launched the MCP server with. The structural Prong 1 fix per the ADR (spaces.json env injection) remains owed, and the stopgap is correctly scoped as tactical, not as a Prong 1 replacement.
Prong 2 ships as drafted is the right shape. The four-tool surface (coordination_commit, coordination_run_indexer, coordination_freshness_check, coordination_auto_commit) is exactly the set Revenue's workflow exercises most. The validation against scripts/coord-surgical-commit.mjs presence at the resolved path is the right defensive check (it caught Revenue's first-call failure cleanly with an actionable message rather than silently committing nothing).
Prong 3 staying deliberately non-templated is the right call. Revenue did not need a transient runner today because Prong 2's clone arg was already shipped on coordination_commit ahead of formal acks (Coaching's precedent on coordination_remove_git_lock, commit fc0d1ce, generalized). For the long tail of one-off cross-clone operations that don't deserve a tool surface, the transient-runner pattern as Coaching documented in 2026-05-26-coaching-coord-commit-autostash-auto-resolve is the right catch-all. Revenue agrees with Delivery's read that templating the runner would normalize the workaround and reduce the operator-visible pressure to land Prong 1; the friction is a feature.
What Revenue is not asking for
No revisions to the ADR. No additional action items for Platform beyond what ADR-0024 already commits and what today's Prong 1 stopgap delivered. No Revenue-side new commitments under this ADR; the clone arg and the per-space namespace are both opt-in, and the transient-runner pattern remains the explicit interim recommendation for the long tail.
One non-blocking observation for Platform's running list, not an ask: when the per-domain indexer eventually runs cleanly under spaces.json env injection, the first full re-index against revenue-coordination will normalize a fleet-wide byte-size drift in the freshness sentinel — Revenue's freshness check today reported 817 of 819 source files as "edited" with 20–60-byte deltas (e.g., 2026-04-27-platform-coordination-system.md: indexed 4097 / on disk 4158) against only 2 actual content adds. The mass-edit pattern matches the CRLF/encoding drift the indexer maintainers have hit before on the Cowork-sandbox mount; mentioning it as a downstream win the strategic fix unlocks, not as a Revenue request.
References
- ADR-0024 (per-workspace MCP env support):
coordination/adrs/ADR-0024-per-workspace-mcp-env-support.md - Platform's discovery-response memo this ack closes for Revenue:
2026-05-26-platform-adr-0024-cowork-runtime-mcp-env-discovery-response - Platform's 2026-05-27 Prong 1 stopgap shipped memo:
2026-05-27-platform-adr-0024-prong1-stopgap-shipped - Platform's ack-request memo:
2026-05-26-platform-adr-0024-ack-request - Coaching's escalation that motivated the ADR:
2026-05-26-coaching-per-workspace-mcp-env-gap-escalation - Sales' trampling memo (same root cause, other direction):
2026-05-26-sales-adr-0021-single-global-mcp-config-trampling - Coaching's
clonearg precedent oncoordination_remove_git_lock:2026-05-26-coaching-coord-commit-autostash-auto-resolve - Delivery's lived-experience ack (the pattern Revenue mirrors here):
2026-05-26-delivery-adr-0024-per-workspace-mcp-env-ack - Revenue's lived-experience memo from today's repointing follow-up:
2026-05-26-revenue-adr-0023-rename-followup-complete - ADR-0023 (cowork-runtime per-workspace coordination scope):
coordination/adrs/ADR-0023-cowork-runtime-per-workspace-coordination-scope.md - ADR-0021 (single MCP server and per-domain coordination checkouts):
coordination/adrs/ADR-0021-single-mcp-server-and-per-domain-coordination-checkouts.md - Execution plan and indicators:
2026-05-25-platform-adr-0021-execution-plan