Salesforce

SERVED (wave W5). describeGlobal's `sobjects` array is the SUMMARY half of the describe this host already serves, and the wave made that literally true rather than nearly true: `objectDescribe()` in packages/renderer-salesforce/src/describe.ts is the full describe MINUS `fields` and `childRelationships`, computed by deleting those two keys rather than by writing a second literal, which is Salesforce's own relationship between its two describe types. So this host cannot report `queryable: true` on one surface and `queryable: false` on the other for the same object, and conformance asserts the global summary against the describe ROUTE as well as against the renderer. `encoding` and `maxBatchSize` are facts about the API rather than about the org. The operation's evidence was `path-only`, so this wave declared its shape under the `hand-authored` class the describe row established. Listing exactly the four served objects is a true statement about THIS replica — the same statement the describe's coverage 404 makes about a fifth

SERVED for Account, Contact, Opportunity and Case — the founder-scoped core. The field list is not assembled from recollection: it is GENERATED from the same served-field table the record projection and the SOQL name resolver read, so describe cannot advertise a field a record does not carry or omit one a query would accept. Picklist values are derived from the canon enums' projection tables, so the metadata cannot offer a value no row could hold; child relationships are declared only where the child really carries the foreign key. Every write flag is false because that is TRUE of a read-only replica, which is what lets a client discover the boundary without hitting it. An sObject outside the four answers the coverage 404 — a real org has Leads and we have not built them, and the 404 says which of those two it means

generate — a compact layout is ORG UI CONFIGURATION — the field set a record's highlights panel shows, per record type — and canon models no layout of any kind; the describe this host serves reports `compactLayoutable: false` for exactly that reason. New canon entity CompactLayout. Nothing about a generation blocks it: the four sObjects are described today

generate — a quick action is ORG UI CONFIGURATION — the create, update and log-a-call actions an admin defines on an object — and canon models none of them. New canon entity QuickAction. READ-ONLY IS NOT THE BLOCKER: reading an action's DEFINITION is not performing it, and this host would report one the way the describe already reports `createable: false`. Nothing about a generation blocks it: the four sObjects are described today

generate — the Reports and Dashboards API is a separate product surface over the same records: it needs the CRM canon first, and then report definitions the canon does not model

generate — the Reports and Dashboards API is a separate product surface over the same records: it needs the CRM canon first, and then report definitions the canon does not model

generate — the Reports and Dashboards API is a separate product surface over the same records: it needs the CRM canon first, and then report definitions the canon does not model

generate — Bulk 2.0 job state is a record of asynchronous work; a read-only universe has no jobs until the canon generates a history of them

generate — Bulk 2.0 job state is a record of asynchronous work; a read-only universe has no jobs until the canon generates a history of them

generate — Bulk 2.0 job state is a record of asynchronous work; a read-only universe has no jobs until the canon generates a history of them

generate — a list view is org configuration plus the records it selects — both are CRM canon (hello-14)

generate — a list view is org configuration plus the records it selects — both are CRM canon (hello-14)

SERVED. Both blockers named on this row are cleared: hello-14 supplies the records, and the serving wave supplied the BOUNDED SOQL PARSER — SELECT (incl. COUNT()), FROM over the four serve-plan objects, WHERE with AND/OR/NOT/parens/IN/LIKE, ORDER BY with NULLS placement, LIMIT and OFFSET. Every construct outside that subset is refused BY NAME with a 400 and the query coverage headers, never approximated and never silently dropped — a WHERE clause the parser did not understand and skipped would return more rows than the caller asked for and look exactly like a correct answer, which the caller cannot detect. Relative date literals resolve against the artifact ANCHOR, not the wall clock, so a pinned snapshot answers the same query forever. renderer-jira's bounded JQL is the precedent, including its two-tier error: a coverage refusal carries the pointer, a caller's syntax error does not

refuse — this host never issues a query locator - one is minted only when a result exceeds QUERY_BATCH_SIZE (2000, renderer-salesforce/src/soql.ts) and the largest served object has 120 records - so the route can only be reached with a locator it did not issue, and Salesforce's own INVALID_QUERY_LOCATOR is the whole answer (the proposal already stands in coverage/reviews/2026-09-08-modes-generation-claims.md). RULED by the founder 2026-09-12 (round 19), coverage wave W5. 400, because this is a malformed continuation rather than a missing resource: the route exists and was reached, and it was the ARGUMENT that could not be honoured

SERVED (wave W5), by the SAME bounded SOSL engine `/search` runs — one grammar, two spellings, so `what does the word acme match` has exactly one answer on this host. Both blockers this row named are cleared: the CRM canon landed with hello-14 and the query grammar with the SOQL parser on 2026-09-04, and what was left was renderer work of exactly the kind soql.ts already did. `q` goes through the same term parser that reads the inside of a `FIND {}` clause; `sobject`, `fields`, `in` and `overallLimit` are covered; and an unrecognized parameter is refused BY NAME rather than ignored, because `spellCorrection`, `highlight`, `netId` and the per-object `where` family each NARROW or ANNOTATE a result and honouring the request minus one returns a wider answer than the caller asked for

generate — SOSL searches across objects, so it needs the CRM canon AND the query grammar SOQL needs; it follows /query rather than leading it

no user has viewed a record in this replica - the recently-viewed list is per-user UI state written by the Salesforce web app, this universe carries no Salesforce session, and the served describe reports mruEnabled false for exactly that reason; Salesforce's own answer for a user who has viewed nothing is [] at 200. RULED by the founder 2026-09-12 (round 19), coverage wave W5. This is the row that gives `mruEnabled: false` a resource behind it: the conformance entry asserts both halves, so the flag and the list cannot come to say different things

generate — tabs, theme, recently-viewed and the app menu are per-org and per-USER state; nothing in this universe carries a Salesforce user's recent-item list yet

olympus-labs' Salesforce org defines no custom invocable action - canon models no Flow, no Apex class and no automation on the CRM side, and this replica accepts no writes; Salesforce's own answer for an org with none is an empty actions collection at 200. RULED by the founder 2026-09-12 (round 19), coverage wave W5

generate — the invocable-action catalogue reflects an org's automation, which the CRM canon does not model yet and no capture reaches

olympus-labs' Salesforce org defines no approval process - canon models no approval automation on the CRM side (the one approval_rule row is a code-review rule over repo-01) and this replica accepts no writes; Salesforce's own answer for an org with none is an empty approvals collection at 200. RULED by the founder 2026-09-12 (round 19), coverage wave W5. The collection is a MAP keyed by sObject name rather than an array, which is Salesforce's own shape, so the empty one is {}

olympus-labs' Salesforce org defines no workflow rule - canon models no CRM automation and this replica accepts no writes; Salesforce's own answer for an org with none is {"rules": []} at 200. RULED by the founder 2026-09-12 (round 19), coverage wave W5. Asserted on all four served objects, because `no workflow rule anywhere` is a claim about every one of them; an object this replica does not serve still earns the coverage 404, so the ruling never answers a typo confidently

SERVED (wave W5): retrieve by EXTERNAL ID over the `idLookup` fields the describe already advertises — every Id, plus Contact.Email and Case.CaseNumber. Conformance asserts the record it answers is BYTE-IDENTICAL to the one the by-id retrieve answers, and walks every field the describe marks idLookup so a flag this host publishes cannot advertise a lookup that does not work. The ruling this row owed is made: a lookup on a field whose `idLookup` is FALSE is refused BY NAME with a 400 and `INVALID_FIELD`, naming the field and listing the ones that would work — and with NO coverage pointer, because the real API refuses it too and pointing at our manifest would misdirect somebody who needs to look at their own request. A field this replica does not serve at all is the other refusal and does carry the pointer, because the served field list is a subset of the real object's. A value that is not unique on its field answers Salesforce's own 300 with the matching record paths, rather than the first match

SERVED (wave W5): a parent traversal reads the PARENT RECORD, and every foreign key it walks was already served — Contact.AccountId, Case.AccountId, Case.ContactId and Contact.ReportsToId all name objects this host describes and projects. Conformance walks EVERY non-null reference on all four objects and asserts the traversal answers byte-identically to fetching that parent by Id, which is invariant #5 at the one route whose whole job is to follow a reference. Three branches are decisions rather than plumbing: a relationship name the object does not have is a plain 400 naming the ones it does (callers most often write the FIELD name, `AccountId`, where the API wants the RELATIONSHIP name, `Account`); `OwnerId` references `User`, which is not among the four founder-scoped objects, so `Owner` answers the coverage 404 until a User sObject ships; and a reference that is NULL answers 204 No Content, because the record was found and the relationship is empty, which is a different statement from `no such record`. THE PATH SHAPE IS SHARED with the external-id retrieve and is disambiguated the way the real API does it — whether the middle segment is a well-formed Salesforce id whose key prefix is this object's

nothing in this universe is ever deleted - the generator writes an append-only event log, this replica accepts no writes, and IsDeleted is false on every record the describe publishes (renderer-salesforce/src/sobjects.ts:472); Salesforce's own answer for a window with no deletions is {"deletedRecords": [], "earliestDateAvailable": ..., "latestDateCovered": ...} at 200. RULED by the founder 2026-09-12 (round 19), coverage wave W5. `earliestDateAvailable` is the instant this snapshot's history of the object begins - the earliest CreatedDate among its records - because this replica's horizon is the artifact's own history rather than the rolling 30-day retention real Salesforce reports there; reporting a retention window this host does not implement would be the invention

SERVED (wave W5). The blocker this row named — `serving numbers before the CRM canon exists would mean inventing them` — was cleared by hello-14, which ships the CRM canon and rides every artifact from `sf-v67-g9` forward. recordCount is `{sObjects: [{count, name}]}` over exactly the four objects this host describes, every count is a row count in the artifact, and conformance asserts each against a `SELECT COUNT()` on the same object so the two surfaces cannot disagree. `/limits` ITSELF STAYS UNSERVED and that is the honest half of this row: an org's API request allowances, storage figures and license counts are facts this universe does not carry, and recordCount is the one part of that resource that is nothing but a count of rows already served. An object this replica does not serve earns the coverage refusal rather than a silent omission — a missing row would report nothing for an object that has plenty

SERVED (wave W5). The reason this row carried until 2026-09-12 — `composite batches the operations above; it can be no more real than they are` — was true and is now an argument FOR serving it: the operation it batches IS served, so the batch is exactly as real as the retrieve. It reads up to 800 records of one type by Id, every one of them a record the by-id projection already produces, and conformance asserts the batch equals the one-by-one reads element for element. An Id that names nothing is a `null` IN POSITION, which is Salesforce's own answer and the reason the response is positional: dropping a miss would shift every record after it onto the wrong id. `fields` is required on the GET form, the 800-record limit is enforced rather than quietly honoured, and both refusals carry the operation's own `INVALID_INPUT`

derive — NOT canon-blocked, and the distinction is the point of classifying it separately: the resource map is a list of the resources THIS replica routes, so it is buildable the day somebody writes it rather than the day a pin rides the CRM canon. It is unserved for one reason only — no capture reaches it (401 before routing, recorded under salesforce.capture-pending) and the hand-authored document therefore declares no shape for it, so serving one would mean publishing a body nobody has seen

SERVED, and served VERBATIM from a captured response (packages/conformance/specs/salesforce/captures/versions.json, sha-pinned in coverage/provider-pins.yaml under salesforce.captures-file) — the pagerduty /abilities precedent. This is the ONLY Salesforce response anybody can observe without an org: every path under /services/data/v{version}/ answers 401 to an anonymous caller because auth runs before routing. Thirty-seven entries, v31.0 to v67.0, including the one label upstream spells with U+2019 rather than an apostrophe; salesforce/versions.test.ts binds the renderer's constant to the capture and to its sha so a well-meaning ASCII cleanup cannot turn the capture into a construction