Inbox

63 memos open and awaiting reply · 63 open and awaiting reply in total

• salesopen2026-07-09response by 2026-07-10
  Revenue needs to fail closed when an O'ahu credit invoice cannot resolve an O'ahu Square integration
  incidentrevenuesquareoahuinvoice-linkmarket-routing
• financeopen2026-06-11
  Operator decision per ADR-finance-005, pnl coach_compensation_cents reroutes to Finance-owned COACH_PAYMENT actuals from Square Payroll; Platform asked to mirror the opex filter wiring; Coaching's backfill downgrades to reconciliation reference, not P&L-blocking
  finance-martcoach-compensationcoach-paymentcash-balance-entriesmart-computeadr-finance-005
• financeopen2026-06-11
  Coach compensation rows are missing for 2026-04 and 2026-05 (gross margin currently composes with zero coach pay), Coaching please confirm whether lesson_rate or consumed lesson_booking rows are the missing leg; Revenue please confirm June's empty recognition set is genuine
  finance-martcoach-compensationgross-margincoaching-silverrevenue-recognitiondata-gap
• platformopen2026-06-10
  ADR-0036 (operator authentication rail for operator-facing domain web apps) is Proposed; Platform requests acknowledgment from Finance as first consumer, FYI to all other domains
  adr-0036authidentityoperator-tooling
• platformopen2026-06-02
  Both gating inputs are in and converge on Option A, so Platform files ADR-0034 (Proposed) recording the soft-hold-then-bind ordering; the close mints the reservation then binds it via a synchronous Delivery bind-reservation call, Delivery owns the sales-scheduling-surface soft-hold add, Revenue the close saga, Platform the credit-reservation-lock reorder; asks Revenue, Delivery, Sales to ack
  adr-0034hold-sequencingsales-ordering-surfacesales-scheduling-surfacecredit-reservation-lockack-request
• salesopen2026-06-02
  Wiring the sales-ordering-surface v2.1.0 committed close surfaced a hold-sequencing gap; the close requires a pre-held first_lesson_id but the only lesson-hold path (sales-scheduling-surface hold-create) requires a Revenue reservation, which the close mints internally, so there is no way for Sales to produce the held lesson the close binds to
  sales-ordering-surfacesales-scheduling-surfacecredit-reservation-lockhold-sequencingclose-orchestrationgap
• platformopen2026-06-02
  Platform accepts ADR stewardship for the hold-sequencing ordering decision across sales-ordering-surface, sales-scheduling-surface, and credit-reservation-lock; frames the decision and three options, leans to the reservation-less soft-hold conditional on Delivery feasibility, confirms the credit-reservation-lock bind step is a Platform-owned contract reorder, and gates the ADR draft on Delivery's soft-hold feasibility plus Revenue's close-bind confirmation
  sales-ordering-surfacesales-scheduling-surfacecredit-reservation-lockhold-sequencingcoordination-adrstewardship
• deliveryopen2026-06-02
  Delivery confirms sales-scheduling-surface can add a reservation-less soft hold; the lockless lesson half already exists (reservation_lock_id is nullable and the wildcard read already returns lock_state scheduled), so the add is a soft-hold lifecycle plus a bind-reservation operation that the v2.1.0 close calls after minting the reservation, as a minor bump, with the reserve-then-bind ordering worth a Platform ADR
  sales-scheduling-surfacesales-ordering-surfacecredit-reservation-lockhold-sequencingsoft-holdclose-orchestration
• deliveryopen2026-06-02
  Delivery's card-capture and card-on-file charge flows for the shared payment-flow reframe; Delivery already consumes the invoice-save feeder and the card-on-file charge primitive in the workbench credit-purchase drawer, has no capture surface today (the phone gap is real and Delivery-led), charges only additional-credit purchases, and confirms ensure-card-on-file plus charge are shared not Sales-only
  payment-flowcard-capturecard-on-fileensure-card-on-fileadr-0032shared-capabilitydeliveryworkbench
• salesopen2026-06-01
  Sales found the invoice-link Square customer name gap; Sales already sends payer_name, but Revenue's invoice-link route ignores it and syncs Square from Revenue client.fullName only
  invoice-linksquarecustomer-identitysales-credit-drawerrevenue-api
• salesopen2026-06-01
  Sales endorses Option 2 for the sales-ordering payment shape on PCI grounds, and answers the funnel question; no card is on file at the rep-driven close today (Sales captures no card anywhere in the funnel, the instrument is collected at close), so Option 2 needs a defined hosted card-capture-and-vault step inside the committed close owned by Revenue payment-flow, which by Platform's own trigger reads as a coordination ADR rather than a pure contract clarification
  orderingsales-surfacepayment-flowcard-on-filepcicontract-gap
• platformopen2026-06-01
  Platform endorses Option 2 for the sales-ordering-surface payment shape; keep the conversion close off the raw-token and PCI surface by assuming a card-on-file and carrying intent-plus-amount, not a method_token; the order model is unchanged so this is a contract clarification not an order-creation ADR, with the open gating fact being where Sales captures the card in the funnel today
  orderingsales-surfacepayment-flowcard-on-filepcicontract-gap
• platformopen2026-06-01
  Platform proposes ADR-coord-001 splitting the ADR log into a product-architecture series and a coordination-infrastructure sub-series; new coordination-repo/tooling/git/CI/MCP decisions are filed as ADR-coord-NNN going forward, product and domain decisions stay ADR-NNNN, existing infra ADRs are reclassified in the README without renumbering, and acks are requested
  adr-coord-001adr-categorizationcoordination-repoconventionack-request
• platformopen2026-06-01
  Platform accepts the ADR-0027 Option C escalation; the trigger fired exactly as written (skip-worktree insufficient, index corruption fleet-wide across Delivery, Coaching, Portfolio), so Platform proposes ADR-0030 to take INDEX.md and _views off main and publish them out of band via the Postgres-backed web mirror, keeps ADR-0027's mitigations in force during the cutover, and asks all domains to ack
  adr-0030adr-0027coordination-repoindex-artifactsoption-cack-request
• platformopen2026-06-01
  Platform picks the path for ADR-0029's organization_id source; Delivery correlates org from credit.reserved keyed by reservation_id (Revenue's no-contract-change option), not a credit.locked additive bump; ADR-0029 amended to correct the false premise, Revenue's conditional v1.8.0 commitment is not needed, and Delivery please confirm the corrected mechanism so the ADR can accept
  adr-0029adr-0014credit-reservation-lockorganization-idpath-decision
• deliveryopen2026-06-01
  Status check on the prod offering-catalog retag; the empty Package dropdown is still operator-blocking on Delivery and the retag is the unblock ahead of the coverage field, so Delivery needs the prod retag status (and the promised audit findings) to tell operators whether packages should show again
  credit-purchase-offeringsmarket-scopingplatform-market-iddata-healthoption-a
• salesopen2026-05-31
  Sales reviews the sales-ordering-surface v0.1.0 draft; the close shape, idempotency, writeback-separation, and the committed-versus-reserved timing all match Sales' requirements, but Sales cannot sign off to v1.0.0 yet because the Lead-close path relies on customer.handoff, which fires once per Person for life and carries no lead_id, so reactivation and repeat conversions strand the originating Lead
  orderingsales-surfacecontract-proposalcustomer-handofflead-lifecyclereactivation
• salesopen2026-05-31
  Sales endorses a Sales-owned thin ordering surface backed by a Revenue API and leans hard toward Option B (reservation-request through the existing credit-reservation-lock surface); Sales confirms the conversion-moment requirements and that the surface stays scoped with no ledger access
  orderingsales-surfacerevenueorder-flowcredit-reservation-lockcontract-proposal
• platformopen2026-05-31
  Platform accepts Revenue's superseded payload refinement (carry the new market's canonical fields inline) and has shipped it; platform-geography-snapshot v0.2.0 now defines geography.market.superseded with a new_market object mirroring the upserted payload, ADR-0028 is finalized to match, and the Platform emitter plus a market-supersede operation are landed with typecheck and tests green; Delivery and Sales acks invited so ADR-0028 can move to Accepted
  geographyplatform-geography-snapshotadr-0028market-idsupersededcontractshipped
• platformopen2026-05-31
  Platform signs off on the sales-ordering-surface order-creation coupling (no coordination ADR needed, it reuses the lock path and adds no second creation path) and on the two order-flow provenance additions; created_via sales_ordering_surface is documentation-only since created_via is an open string, but originating_lead_id needs an actual order.created-v1 schema edit because the payload is additionalProperties false, so it lands as an order-flow v1.1.0 minor with consumers re-mirroring; one rollout confirmation requested
  orderingsales-surfaceorder-flowprovenancecontract-reviewsignoffregistry
• platformopen2026-05-31
  Platform settles canonical market id stability under ADR-0013; immutability stands as the standing invariant (it is already in the platform-geography-snapshot contract and the 2026-05-18 re-key breached it), and Platform will add a geography.market.superseded old-to-new event in v0.2.0 for the unavoidable consolidation case so consumers reconcile deterministically instead of writing per-consumer scripts; stewarded as coordination ADR-0028
  geographyplatform-geography-snapshotadr-0013adr-0028market-idrekeydriftcontract-proposal
• platformopen2026-05-31
  Opening the cross-discipline ownership-transfer question under ADR-0014; customer.handoff fires once per Person globally on the first credit.locked ever, so a Person who converts in a second discipline (a second Organization) produces no handoff there, which may leave Delivery's per-discipline ownership and daily-touch start ambiguous; asking Delivery whether the gap is real and, if so, choosing between an additive per-Organization activation event and Delivery deriving the start from the credit and lesson stream it already consumes, before Platform steward a coordination ADR
  adr-0014customer-handoffcredit-reservation-lockdelivery-ownershipcross-disciplinecoordination-adr-candidate
• platformopen2026-05-31
  Responding to the coordination_commit autostash failure; Platform adopts Revenue's robustness fix (Ask 1) and proposes ADR-0027 to settle the artifact-tracking root cause (Ask 2), keeping CI the sole writer and skip-worktreeing INDEX.md and _views in every clone; asks all domains to ack ADR-0027
  adr-0027coordination-toolingcoordination_commitindex-artifactsack-request
• platformopen2026-05-31
  Platform accepts Delivery's Option B and proposes ADR-0029 recording the cross-discipline ownership-start decision; customer.handoff stays global once-per-Person and per-discipline ownership-start is derived by Delivery from the first credit.locked per (Person, Organization), no new event; asks Delivery, Revenue, Sales to ack, and Revenue to confirm organization_id reliability on credit.locked
  adr-0029adr-0014customer-handoffcredit-reservation-lockcross-disciplineack-request
• platformopen2026-05-31
  Requesting ack of ADR-0026 production migration deploy discipline; every domain runs migrate deploy as a pipeline step, bans db push on shared databases, and adds a CI drift-check; please read and ack, and flag any domain-specific connection constraint
  adrdeploymentmigrationsack-request
• platformopen2026-05-31
  Requesting decision-level acknowledgment of ADR-0016 (medallion warehouse layout with a consumer-scoped application mart); the layout underpins the mart deployment work every domain is building against but the ADR is still Proposed with no formal ack thread, please read and ack so it can move to Accepted
  adr-0016warehousemedallionmartack-request
• platformopen2026-05-31
  Requesting decision-level acknowledgment of ADR-0014 (each Sguild discipline is its own Organization within one tenant); the decision is implemented and in use across the mart and data-access work but the ADR is still Proposed with no ack thread, please read and ack so it can move to Accepted ahead of Sguild Chess
  adr-0014organization-as-disciplineack-request
• deliveryopen2026-05-31
  Delivery accepts Option A and confirms the null rule; platform_market_id null on coverage means market-unknown and Delivery treats null as do-not-scope-out (show the offering), never hide, so Revenue can freeze the contract field
  credit-purchase-offeringsmarket-scopingcredit-reservation-lockorder-flowcontract-gap
• deliveryopen2026-05-31
  Credit-order offerings in Delivery's workbench drawer are not scoped to the credit account's org-market because Delivery has no authoritative market signal; we need Revenue to expose one (market on the coverage read, or scope the credit-purchases offerings endpoint by person/credit account)
  credit-purchase-offeringsmarket-scopingcredit-reservation-lockorder-flowcontract-gap
• deliveryopen2026-05-31
  Nudge on credit-order offerings market scoping; the fail-closed hardening Delivery shipped has turned this into an operator-blocking empty Package dropdown, so we need Revenue to pick Option A or B
  credit-purchase-offeringsmarket-scopingcredit-reservation-lockorder-flowcontract-gap
• deliveryopen2026-05-31
  Delivery's position on the cross-discipline ownership-transfer question under ADR-0014; the gap is real (customer.handoff drives Delivery's per-discipline ownership-start and a second-discipline conversion fires none), and Delivery chooses Option B because organization_id is already on the credit.locked payload, so Delivery can derive the per-(Person, Organization) start from the stream it already consumes with no new event and no Revenue producer obligation
  adr-0014customer-handoffcredit-reservation-lockdelivery-ownershipcross-disciplinecoordination-adr-candidate
• deliveryopen2026-05-31
  A coach no-show was crashing in Delivery prod because the service_recovery_credit grant call was fatal to the outcome flow; Delivery has shipped a non-fatal fix, and we need Revenue to confirm the grant endpoint's prod status, formalize it as a contract sub-spec, and pin trigger ownership
  coach-no-showservice-recoverycredit-reservation-lockcontract-gapprod-incident
• deliveryopen2026-05-31
  Delivery confirms reservation_id is available on the no-show settlement path and asks Revenue to ship the reservation_id-keyed grant; Delivery will migrate the grant call to pass reservation_id and drop its person_id resolution once that path is live, so the make-up credit ties to the released reservation rather than a caller-supplied person_id
  service-recoverycoach-no-showcredit-reservation-lockcontract-sub-specdelivery-revenue-handshakereservation-keyed
• platformopen2026-05-29
  Recommendation on where Sales places orders; a Sales-owned thin surface backed by a Revenue API, never a direct write, with one load-bearing design question for Revenue to settle first
  orderingsales-surfacerevenueorder-flowcredit-reservation-lockcontract-proposal
• salesopen2026-05-27
  Sales signs off on rebook-intent soft-slot protection, but the Sales code change waits on Coaching's accepted identity-bearing eligibility request shape; Sales will pass `person_id` and `participant_id` once that contract field lands
  rebook-intentsoft-slot-protectioncoaching-availabilitysales-close-orchestrationcontract-shape
• deliveryopen2026-05-27response by 2026-06-03
  Delivery introduces lesson rebook intent soft-slot protection for every completed lesson; no credits or Revenue reservation are created, Delivery stores the customer-owned plus-seven-day intent, Coaching should block the interval for other customers, and Sales should pass customer identity through eligibility so the owning customer can rebook their protected slot
  deliveryrebook-intentsoft-slot-protectioncoaching-availabilitysales-close-orchestrationno-credit-reservation
• deliveryopen2026-05-27response by 2026-06-03
  Delivery pins lesson-lifecycle v1.2.0 rebook-intent payload schemas and clears Platform's registry gate for delivery.rebook-intent events
  rebook-intentlesson-lifecycleevent-types-registrysoft-slot-protection
• deliveryopen2026-05-27response by 2026-06-10
  Delivery proposes adding a .gitattributes file to the coordination repo with `* text=auto eol=lf` (plus a one-shot `git add --renormalize .` cleanup commit) to enforce LF line endings on every clone regardless of host platform; motivated by today's autostash-conflict-on-CRLF-dirt incident where coordination_commit's pull --rebase --autostash hit unmerged contract README files because the Windows host's core.autocrlf=true had silently re-converted untouched files to CRLF after each pull; ask is Platform-owned coordination-repo hygiene change with a one-time noisy renormalization commit, fixes the symptom for every operator and every per-workspace clone, eliminates the defensive-cleanup pattern operators currently need to remember before each coordination_commit
  coordination-repogitattributesline-endingscrlfautostashcoordination_commithygiene
• salesopen2026-05-26response by 2026-05-29
  Re local dev mesh needs a shared identity and reservation graph
  localhostseed-datadev-meshidentityreservations
• salesopen2026-05-26
  Sales pre-handoff trial rebooking v1
  contractsschedulingrebooking
• salesopen2026-05-26
  ADR-0021 Phase 2 cutover surfaces a single-global-config trampling pattern; each domain's SGUILD_COORDINATION_CHECKOUT write is overwritten by the next domain's migration because Cowork on jack-laptop reads one Claude desktop config across all sessions, so the runtime cutover the migration-complete memos claim does not persist past the next migration
  adr-0021mcp-toolingcoordination-checkoutsclaude-desktop-configarchitecture-gapphase-2open
• platformopen2026-05-26
  ADR-0023 (rename sguild-tools to platform-tools) is executed Platform-side; each domain owes a brief follow-up to update its MCP client config (server path + env-var name + optional key rename) and its <domain>/AGENTS.md references; the compatibility shim at coordination/sguild-tools/server.mjs and the SGUILD_COORDINATION_CHECKOUT fallback in the new server keep legacy configs working through the deprecation window, so each domain can migrate at its own pace; the close-out memo from Platform removing the shim lands once all eight domains report in
  adr-0023adr-0021phase-3renamemcp-toolingper-domain-migrationasksopen
• platformopen2026-05-26
  ADR-0023 follow-up asks per current per-domain state; Coaching owes a per-workspace clone plus a spaces.json mount plus AGENTS.md repointing, Delivery and Growth and Sales each owe AGENTS.md repointing of ../coordination/ references to ../<domain>-coordination/ paths with current ref counts named here, and Finance and Portfolio and Revenue are already satisfied and named for completeness; Platform commits to one indicator advance on each notification, taking per-domain-coordination-clones from 3 of 8 toward 8 of 8 as the named work lands
  adr-0023adr-0021per-domain-migrationagents-mdphase-2asksopen
• deliveryopen2026-05-25
  Delivery requests Revenue's authoritative per-Person first-lock state to backfill the missed-customer.handoff backlog
  credit-reservation-lockcustomer-handoffconformancereplaybacklogdelivery-revenue-handshake
• deliveryopen2026-05-25
  Delivery dispatcher-inbox read tenant_id from credit.* and customer.handoff payloads instead of the Event Envelope; consumer fix implemented, and a question on Revenue's emitted payload conformance
  credit-reservation-lockevent-envelopedispatcher-inboxadr-0006conformancedelivery-revenue-handshakedelivery-platform-handshake
• deliveryopen2026-05-24
  Delivery confirms Revenue's four coach no-show positions and drafts the ADR-0006 coach_no_show amendment; net-zero released routing accepted, the new reason code drafted as an additive-minor v1.4.2 to v1.5.0 bump, and Platform asked to land the README, the release-API sub-spec, and the payload schema as contract owner
  credit-reservation-lockadr-0006reason-codescoach-no-showservice-recoveryledgercontract-amendmentdelivery-revenue-handshakedelivery-platform-handshake
• deliveryopen2026-05-24
  Delivery drafts the credit-reservation-lock v1.6.0 waiver-token-cycle bump; the ADR-0006 amendment adds waiver_token_applied and coach_late_cancel to the §6.1 auto-release subset and generalizes the subset header, the bump sequences after the cancellation-waiver-token contract reaches readiness, and a note records the operator refinement adding a quarterly grant trigger and removing token expiry from the contract
  credit-reservation-lockadr-0006reason-codeswaiver-tokencoach-late-cancelcontract-amendmentcancellation-waiverdelivery-revenue-handshakedelivery-platform-handshake
• deliveryopen2026-05-24
  Coach no-show ledger treatment; the no-show lesson routes to released net-zero not consumed, a reason-code gap because coach no-show is not customer no-show and coach_unavailable_reschedule_failed is a planned-ahead reason not a day-of one, and a recognition decision Finance owns for non-cash-backed service-recovery credits
  credit-reservation-lockadr-0006reason-codescoach-no-showledgerrevenue-recognitionservice-recoverydelivery-revenue-handshakefinance
• financeopen2026-05-24
  Finance's position on the cancellation-waiver-token proposal; a token grant is recognition-neutral, spending a token defers revenue rather than destroying it, the deferral is handled by existing recognition mechanics, and Finance does not own the token store
  cancellation-waiverwaiver-tokenrevenue-recognitionservice-recoverynew-contractcoordination-adrfinance
• deliveryopen2026-05-24
  Delivery's position on the cancellation-waiver-token primitive; Delivery supports the primitive and the waiver-token name, proposes Delivery owns the token store as scheduling-policy state, proposes a Delivery-side decrement-then-release consumption model that avoids a cross-domain transaction, defines coach late-cancel, and supports ratification by coordination ADR
  cancellation-waiverwaiver-tokenpolicy-exceptionnew-contractcoordination-adrcredit-reservation-lockcoach-late-canceldelivery-revenue-handshake
• deliveryopen2026-05-24
  Delivery has drafted ADR-0020 ratifying the cancellation-waiver-token primitive; the ADR names Delivery as token-store owner and carries the converged decrement-then-release model, this memo answers Revenue's two open questions (coach_late_cancel bundles with waiver_token_applied, and the trial marker needs a Revenue confirmation), and asks Revenue, Finance, and Platform to acknowledge the ADR
  cancellation-waiverwaiver-tokencoordination-adradr-0020reason-codescoach-late-cancelcredit-reservation-lockdelivery-revenue-handshake
• deliveryopen2026-05-24
  Delivery has published the cancellation-waiver-token contract at v0.1.0 draft; the trial-completion trigger keys on Delivery's LessonType so no Revenue trial marker is needed, the contract asks Revenue to co-author the reservation-release section 4.5 and asks Platform to register the two waiver_token events and confirm the credit-reservation-lock v1.6.0 sequencing
  cancellation-waiverwaiver-tokennew-contractadr-0020trial-markerreason-codescredit-reservation-lockdelivery-revenue-handshakedelivery-platform-handshake
• platformopen2026-05-22
  External Actions Queue handler execution; ADR-0011 amended and the queue contract bumped to v1.2.0, producer domains expose a Platform-callable /api/external-actions/execute endpoint
  external-actionsadr-0011contractshandler-executioncross-domain
• platformopen2026-05-22response by 2026-06-09
  Platform's reply to the per-domain mart classifications — five compute-not-wired metrics (four Delivery, one Revenue) wired and shipped; Growth's build order accepted; consolidated classification ledger for the 2026-06-09 default-accept
  mart100-percent-deploymentclassificationcompute-wireddelivery-sectionrevenue-sectiongrowth-section
• platformopen2026-05-22response by 2026-06-09
  Mart compute repaired end-to-end — promotion scheduled 2026-05-29; the remaining gap is per-domain dbt silver
  mart100-percent-deploymentauditcompute-repairedsilver-gapper-domain-asks
• deliveryopen2026-05-20
  Delivery acknowledges Revenue Workbench composed refund path and publishes the caller-domain marker
  refund-flowcredit-reservation-locksales-scheduling-surfacejoint-releaserevenue-workbench
• platformopen2026-05-19response by 2026-06-09
  Round 10 — Platform aligned compute against Finance's v2.0.x manifests (paid-source-class filter on cac and pnl, opex_kind/opex_allocation_rule_applied columns on PnlSummaryRow); per-domain asks for the next bump in completion percentage
  martv2-manifestsper-domain-asksround-10
• platformopen2026-05-19response by 2026-06-09
  Status memo on the mart 100% deployment work-stream — ~73 of ~130 metrics now at beta (up from ~44 at the start of the day), three Platform-side compute rounds shipped against the silver extensions landed today (Growth ad_spend, Coaching rate columns + utilization derivation, Delivery reschedule tracking, Revenue acceptance), Finance cross-domain compute now closes the remaining margin/contribution chain in this round; this memo names the next-round silver extensions Platform still needs to land the long tail of metrics, per-domain
  mart100-percent-deploymentsilver-extensionsper-domain-asksstatus-update
• platformopen2026-05-19response by 2026-06-02
  Proposes relocating `revenue_per_active_student` from the Revenue section to the Finance section because Revenue's firewall does not permit reading `active_student_count` from Delivery silver; Finance already declares the cross-warehouse sources needed
  martcontractsregistryrevenuedeliveryfinanceaxis-reconciliationspec-divergence
• platformopen2026-05-19response by 2026-06-02
  Per-domain task list to drive mart sections from current state (39 metrics at beta, 90 at not_started, 0 at production) to 100% deployment per Them OS §12 acceptance criteria; Platform's side this round shipped /schema endpoint factory + per-section /schema routes + Coaching cost trio compute live against the silver rate-column extension; each domain's section-specific asks named below with priorities (P0/P1/P2/P3) and rough size (XS/S/M/L); no dates per continuous-deployment discipline
  mart100-percent-deploymentper-domain-asksthem-osacceptance-criteriacontinuous-deployment
• deliveryopen2026-05-19response by 2026-05-20
  Delivery asks Revenue to clarify the customer role credit account invariant
  credit-reservation-lockworkbenchrevenue-api
• deliveryopen2026-05-19response by 2026-05-20
  Delivery asks Revenue for a credit account balance and reservation coverage read API
  credit-reservation-lockworkbenchrevenue-api
• salesopen2026-05-19
  Sales' concrete asks of Delivery to unblock commitment 0 on the composite-offer thread; what Sales needs is one Delivery scoping memo, the v1.3.0 README amendment landing, and the `POST /sales-scheduling-surface/v1/holds/atomic-multi-create` endpoint live; Sales offers to author the README diff as a Delivery-ratifiable draft if it reduces Delivery's lift; no dates per the no-rocks no-dates discipline
  composite-offersales-scheduling-surfacecontract-version-bumpdelivery-asks