---
id: TST-PFM-OPS-097
title: Hubspot company syncs queries
kind: integration
product_area: platform
module: operations
revision: 1
status: draft
source_sha:
  services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1
repository: services-platform
files:
  - >-
    modules/licensing/tests/integration/services/persistence/hubspot-company-syncs.queries.integration.spec.js
implements: []
environment: local
implementation_state: implemented
latest_result: not-run
latest_run_at: null
latest_run_ref: null
conformance: not-verified
estimated_minutes: 5
estimate_basis: Scheduling estimate only; no duration is measured during this documentation pass.
isolation: >-
  The prepared local test database and suite-owned identifiers; existing hooks control rollback or
  cleanup.
evidence:
  - >-
    services-platform:modules/licensing/tests/integration/services/persistence/hubspot-company-syncs.queries.integration.spec.js
    at ad3f6a6582843008ed0f5a17b131878d15829af1: existing suite body, setup, assertions and cleanup.
binding_note: This existing engineering suite is registered without claiming a complete specification scenario.
assertion_sources:
  - >-
    services-platform:modules/licensing/tests/integration/services/persistence/hubspot-company-syncs.queries.integration.spec.js#answers
    every element of the record, the attempt, the success, the outcome and the count
  - >-
    services-platform:modules/licensing/tests/integration/services/persistence/hubspot-company-syncs.queries.integration.spec.js#answers
    nothing for a company nothing has ever tried to read, which is not the same as a failure
  - >-
    services-platform:modules/licensing/tests/integration/services/persistence/hubspot-company-syncs.queries.integration.spec.js#puts
    the failures first, so the thing to look at is the first thing on the screen
  - >-
    services-platform:modules/licensing/tests/integration/services/persistence/hubspot-company-syncs.queries.integration.spec.js#puts
    a company with no HubSpot to read after the failures and before the successes
  - >-
    services-platform:modules/licensing/tests/integration/services/persistence/hubspot-company-syncs.queries.integration.spec.js#puts
    the longest-unread success before the most recent one
  - >-
    services-platform:modules/licensing/tests/integration/services/persistence/hubspot-company-syncs.queries.integration.spec.js#lists
    no company nothing has ever tried to read, because there is no row for one
  - >-
    services-platform:modules/licensing/tests/integration/services/persistence/hubspot-company-syncs.queries.integration.spec.js#answers
    at most the rows asked for, which is what bounds a staff screen
  - >-
    services-platform:modules/licensing/tests/integration/services/persistence/hubspot-company-syncs.queries.integration.spec.js#answers
    a map keyed by company id, with each record mapped
---

# Hubspot company syncs queries

## Verification Boundary

This suite exercises application licensing through production operations against the local database. Its implementation is present at the pinned source revision, and this register records no execution result.

## What This Suite Proves

The checks exercise hubspot company syncs queries within the file’s declared setup and assertion boundary. The structured assertion anchors distinguish these checks from the surrounding feature flows. No complete specification scenario is attributed to this suite yet.

## What It Does Not Prove

Local execution does not establish deployed infrastructure, live commercial-provider configuration or authorization-cache completion. Registration and an implemented suite do not establish a passing result.

## Real Dependencies and Test Doubles

The prepared PostgreSQL database and production operations under test are real. The suite controls time where boundary checks require it.

## Must Not Be Doubled

The persistence operations, database constraints and reads under assertion remain real.