HubSpot

the deal and ticket stage vocabularies. Derived from canon's own DEAL_PIPELINE and TicketStatus sets rather than from artifact rows — a pipeline is org configuration, not simulation output, which is exactly why canon holds it as a static table. Projected into renderer-hubspot/src/pipelines.ts because no renderer in this fleet depends on @sandboxapis/canon, and held to canon stage-for-stage by conformance

SERVED. A pipeline audit lists the CHANGES made to a pipeline, and nothing in this simulation ever edits one: canon's DEAL_PIPELINE is a static table precisely so a deal's probability cannot move under a pinned customer, and the ticket statuses are Zendesk's fixed six. Both pipelines are the portal's DEFAULT pipelines — the document's own `createdAt = 0` case — and an unedited default pipeline has an empty audit trail upstream too. This is not difficulty laundered as coverage: there is no audit canon being withheld, and the day the simulation grows pipeline editing the row goes red rather than hiding it

search is a READ HubSpot expresses as a POST, because its criteria are a document rather than a query string. All thirteen Filter.operator members, both filter-group levels, `query`, `sorts` and cursor paging are evaluated against the property map each record renders to — the same map the object read serves, so a filter written against what a caller can see selects what a caller expects

deals, from the hello-14 CRM canon. The path reads `0-3` rather than `deals` because that is how HubSpot's own pinned document writes the object type — upstream's asymmetry, carried rather than corrected, and the `deals` spelling real HubSpot also answers is deliberately NOT served (no vendored document declares it)

SERVED, and the empty SURVIVED the CRM canon — which is the re-review the prep wave owed this one (review §3: 'if hello-14 introduces a custom object type for olympus-labs, this row becomes derive and the empty is wrong'). It did not. This endpoint lists CUSTOM object schemas, and the document says so three times over — the operation summary is 'Retrieve all custom object schemas.', the single read's is 'Retrieve the schema of a specified custom object.', and info.x-hubspot-introduction reads 'Use the custom objects schema API to define new types of CRM records in your account.' hello-14 adds STANDARD objects (companies, contacts, deals, tickets), which this API never lists. So the empty is true, it is true for a reason that does not expire, and conformance.test.ts now asserts BOTH halves: that the CRM is demonstrably non-empty on this artifact and that this list still is

refuse — SERVED as HubSpot's own not-found, which is the truthful answer for every object type a caller can name here. olympus-labs defines no CUSTOM object types, so there is no schema to fetch; and a STANDARD type (companies, contacts, deals, tickets) is refused too, for the same reason the collection above does not list one — this is the custom-object API. The prep wave left this `generate` because 'the shape of that 404 is not settled'; it is settled the way every other refusal on this host is, in HubSpot's own Error envelope, and it carries NO coverage header because the endpoint IS served and the schema is what does not exist

the go-to-market roster, and the identity join review §8.2 called the serving wave's second deliverable: every CRM record's hubspot_owner_id resolves to an owner whose email is a canonical person's, and parity/hubspot-crm-parity.test.ts walks that join through the hosts rather than through the artifact

the property catalogue. The prep wave left this `generate` because 'the pinned documents declare the SHAPE of a property and never the default LIST, so serving one now would mean publishing a catalogue transcribed from memory'. That objection is answered rather than waived: the catalogue is olympus-labs' OWN, derived from canon's columns, and every enumerated property DECLARES its vocabulary in its own `options` — which is how a real HubSpot portal works, since option sets are per-portal configuration. The one thing that IS transcribed from the document is the DEFAULT property set, which each of the four object documents prints in info.description as a table ('Properties returned by default')