--- id: TST-PFM-SEC-163 title: Roles database and service checks kind: integration product_area: platform module: security revision: 2 status: draft source_sha: services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1 repository: services-platform files: - modules/security/tests/integration/services/persistence/roles.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: 3 isolation: Use the prepared test database and suite-owned fixture rows; retain shared seed records. assertion_evidence: - provenance: test source: >- services-platform:modules/security/tests/integration/services/persistence/roles.integration.spec.js#security persistence: security_roles - provenance: test source: >- services-platform:modules/security/tests/integration/services/persistence/roles.integration.spec.js#createRole - provenance: test source: >- services-platform:modules/security/tests/integration/services/persistence/roles.integration.spec.js#records a customer's own role with where it is meant to be assigned - provenance: test source: >- services-platform:modules/security/tests/integration/services/persistence/roles.integration.spec.js#records Rhythm's own role under its product key, owned by nobody, and may name a resource type - provenance: test source: >- services-platform:modules/security/tests/integration/services/persistence/roles.integration.spec.js#refuses a product role that names a customer, a custom role that names none, and an empty name - provenance: test source: >- services-platform:modules/security/tests/integration/services/persistence/roles.integration.spec.js#refuses an intended scope that is not one of the four - provenance: test source: >- services-platform:modules/security/tests/integration/services/persistence/roles.integration.spec.js#refuses a name the owner already uses in any case, a repeated product key, and an unknown customer - provenance: test source: >- services-platform:modules/security/tests/integration/services/persistence/roles.integration.spec.js#the reads - provenance: test source: >- services-platform:modules/security/tests/integration/services/persistence/roles.integration.spec.js#reads a role by id and a built-in by its product key, and the seeded built-ins are there - provenance: test source: >- services-platform:modules/security/tests/integration/services/persistence/roles.integration.spec.js#lists a customer its own roles and Rhythm's, never another customer's, and hides the archived - provenance: test source: >- services-platform:modules/security/tests/integration/services/persistence/roles.integration.spec.js#updateRole and bumpRoleVersion - provenance: test source: >- services-platform:modules/security/tests/integration/services/persistence/roles.integration.spec.js#renames a role, moves its intended scope and bumps the version - provenance: test source: >- services-platform:modules/security/tests/integration/services/persistence/roles.integration.spec.js#refuses a rename onto a name the owner already uses, leaving the row untouched, and an unknown role - provenance: test source: >- services-platform:modules/security/tests/integration/services/persistence/roles.integration.spec.js#bumps the version when what the role grants changed - provenance: test source: >- services-platform:modules/security/tests/integration/services/persistence/roles.integration.spec.js#archiveRole - provenance: test source: >- services-platform:modules/security/tests/integration/services/persistence/roles.integration.spec.js#archives an active role and keeps the row, so an assignment that names it stays legible - provenance: test source: >- services-platform:modules/security/tests/integration/services/persistence/roles.integration.spec.js#security persistence: security_role_policies - provenance: test source: >- services-platform:modules/security/tests/integration/services/persistence/roles.integration.spec.js#attachPolicyToRole - provenance: test source: >- services-platform:modules/security/tests/integration/services/persistence/roles.integration.spec.js#attaches the customer's own policy to its own role, and its product policies too - provenance: test source: >- services-platform:modules/security/tests/integration/services/persistence/roles.integration.spec.js#attaching the same policy twice changes nothing, because the pair is the key - provenance: test source: >- services-platform:modules/security/tests/integration/services/persistence/roles.integration.spec.js#refuses another customer's policy, which is what keeps authority inside a customer - provenance: test source: >- services-platform:modules/security/tests/integration/services/persistence/roles.integration.spec.js#refuses a customer's policy on a product role, which must mean the same thing for everybody - provenance: test source: >- services-platform:modules/security/tests/integration/services/persistence/roles.integration.spec.js#refuses an archived policy, a role that is not there and a policy that is not there - provenance: test source: >- services-platform:modules/security/tests/integration/services/persistence/roles.integration.spec.js#writes inside the transaction, so a refusal of either side leaves nothing behind - provenance: test source: >- services-platform:modules/security/tests/integration/services/persistence/roles.integration.spec.js#the reads - provenance: test source: >- services-platform:modules/security/tests/integration/services/persistence/roles.integration.spec.js#lists the active policies of a role in name order, and drops one that has been archived - provenance: test source: >- services-platform:modules/security/tests/integration/services/persistence/roles.integration.spec.js#answers which roles use a policy, in id order, which is the impact report’s first question - provenance: test source: >- services-platform:modules/security/tests/integration/services/persistence/roles.integration.spec.js#detachPolicyFromRole and setPoliciesOfRole - provenance: test source: >- services-platform:modules/security/tests/integration/services/persistence/roles.integration.spec.js#detaches a policy and says whether there was anything to detach - provenance: test source: >- services-platform:modules/security/tests/integration/services/persistence/roles.integration.spec.js#replaces the whole set, which is what the reconciler does when a built-in’s policies change - provenance: test source: >- services-platform:modules/security/tests/integration/services/persistence/roles.integration.spec.js#refuses to replace the set with another customer's policy, leaving the set it had dependency_evidence: >- The prepared PostgreSQL database supplies the persisted fixtures and constraints exercised here. The suite’s own dependency setup determines which external collaborators are controlled; registration alone does not certify them as live. evidence: - >- services-platform:modules/security/tests/integration/services/persistence/roles.integration.spec.js - >- Static review at the recorded source revision; executable results remain not-run and conformance remains not-verified. binding_note: >- The file has no scenario binding established by this examination. Its executable checks remain registered without assigning them broader acceptance coverage. examiner: codex examined_at: '2026-10-23' final_text: OpenAI dependency_review: provenance: test source: >- services-platform:modules/security/tests/integration/services/persistence/roles.integration.spec.js explicit_no_doubles: false identified_double_boundaries: [] --- # Roles database and service checks ## Verification Boundary The file exercises database or service behavior through the local integration harness. The assertion references identify the source checks for roles. ## What This Suite Proves The file supplies executable engineering checks for the named subject. No complete acceptance scenario is inferred from the file’s existence. ## 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 prepared PostgreSQL database supplies the persisted fixtures and constraints exercised here. The suite’s own dependency setup determines which external collaborators are controlled; registration alone does not certify them as live. ## Must Not Be Doubled Keep the queried database, applicable constraints and transaction boundaries real. Provider substitutes cannot establish delivery, cloud execution or cross-service recovery.