---
id: TST-PFM-SEC-207
title: Google acceptance unit checks
kind: unit
product_area: platform
module: security
revision: 2
status: draft
source_sha:
  services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1
repository: services-platform
files:
  - modules/security/tests/unit/services/invitations/google-acceptance.spec.js
implements:
  - ATS-PFM-SEC-005-07
environment: mock
implementation_state: implemented
latest_result: not-run
latest_run_at: null
latest_run_ref: null
conformance: not-verified
estimated_minutes: 1
isolation: The suite owns its input fixtures and installed doubles.
assertion_evidence:
  - provenance: test
    source: >-
      services-platform:modules/security/tests/unit/services/invitations/google-acceptance.spec.js#security
      capability: google acceptance
  - provenance: test
    source: >-
      services-platform:modules/security/tests/unit/services/invitations/google-acceptance.spec.js#begin
  - provenance: test
    source: >-
      services-platform:modules/security/tests/unit/services/invitations/google-acceptance.spec.js#proves
      the invitation by its token, writes a link session as the invited person and answers its nonce
      as the state
  - provenance: test
    source: >-
      services-platform:modules/security/tests/unit/services/invitations/google-acceptance.spec.js#refuses
      a malformed, unknown or spent token, and a user who is not invited, with the one sentence
  - provenance: test
    source: >-
      services-platform:modules/security/tests/unit/services/invitations/google-acceptance.spec.js#refuses
      an account whose Cognito account is not provisioned yet as 409
  - provenance: test
    source: >-
      services-platform:modules/security/tests/unit/services/invitations/google-acceptance.spec.js#complete
  - provenance: test
    source: >-
      services-platform:modules/security/tests/unit/services/invitations/google-acceptance.spec.js#activates
      the invited user when the signed-in Cognito subject is the canonical account, consuming the
      session once
  - provenance: test
    source: >-
      services-platform:modules/security/tests/unit/services/invitations/google-acceptance.spec.js#refuses
      a bearer token of another Cognito user, or one the pool does not verify (the nonce alone
      proves nothing)
  - provenance: test
    source: >-
      services-platform:modules/security/tests/unit/services/invitations/google-acceptance.spec.js#refuses
      an unknown, expired or spent session with the one sentence, and never activates a suspended
      account
  - provenance: test
    source: >-
      services-platform:modules/security/tests/unit/services/invitations/google-acceptance.spec.js#answers
      an already-active account as the success it already was
dependency_evidence: >-
  The production decision runs in-process. The suite substitutes message delivery, the clock where
  its dependency setup supplies them; those boundaries have no live-service proof here.
evidence:
  - 'services-platform:modules/security/tests/unit/services/invitations/google-acceptance.spec.js'
  - >-
    Static review at the recorded source revision; executable results remain not-run and conformance
    remains not-verified.
binding_note: >-
  Each binding names the scenario to which this file contributes assertions. A binding is not a
  recorded pass and does not extend the file’s dependency boundary.
examiner: codex
examined_at: '2026-10-23'
final_text: OpenAI
dependency_review:
  provenance: test
  source: 'services-platform:modules/security/tests/unit/services/invitations/google-acceptance.spec.js'
  explicit_no_doubles: false
  identified_double_boundaries:
    - message delivery
    - the clock
---
# Google acceptance unit checks

## Verification Boundary

The file evaluates production helpers with controlled inputs in-process. The assertion references identify the source checks for google acceptance.

## What This Suite Proves

The source assertions support the observations named in the bound scenarios. A scenario spanning multiple files must retain the other files’ contributions.

## What It Does Not Prove

This examination does not run the suite. Passing behavior, deployed conformance and the behavior of substituted dependencies require separate execution evidence.

## Real Dependencies and Test Doubles

The production decision runs in-process. The suite substitutes message delivery, the clock where its dependency setup supplies them; those boundaries have no live-service proof here.

## Must Not Be Doubled

Keep the production helper, schema, matcher or declaration under examination real. Substituting the decision itself would remove the behavior the assertions exercise.