--- id: TST-PFM-MTD-109 title: custom field rules table kind: integration product_area: platform module: metadata revision: 1 status: draft source_sha: services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1 repository: services-platform files: - modules/metadata/tests/integration/db/custom-field-rules.table.integration.spec.js implements: - ATS-PFM-MTD-006-01 - ATS-PFM-MTD-006-05 - ATS-PFM-MTD-006-08 environment: local implementation_state: implemented latest_result: not-run latest_run_at: null latest_run_ref: null conformance: not-verified estimated_minutes: 5 isolation: >- Prepared integration database and the suite fixture records; fixture teardown restores or removes its own rows. evidence: - 'services-platform:modules/metadata/tests/integration/db/custom-field-rules.table.integration.spec.js' - >- services-platform:modules/metadata/tests/integration/db/custom-field-rules.table.integration.spec.js#modules/metadata/db/custom-field-rules.table.ts - >- services-platform:modules/metadata/tests/integration/db/custom-field-rules.table.integration.spec.js#accepts a well-formed condition rule, so each refusal below is about the column it spoils - >- services-platform:modules/metadata/tests/integration/db/custom-field-rules.table.integration.spec.js#refuses a second rule of the same kind on the field, by the primary key - >- services-platform:modules/metadata/tests/integration/db/custom-field-rules.table.integration.spec.js#accepts rules of two kinds on one field - >- services-platform:modules/metadata/tests/integration/db/custom-field-rules.table.integration.spec.js#refuses a rule of a field the object does not have, by the field foreign key - >- services-platform:modules/metadata/tests/integration/db/custom-field-rules.table.integration.spec.js#refuses a tenant that does not exist, by the tenant foreign key - >- services-platform:modules/metadata/tests/integration/db/custom-field-rules.table.integration.spec.js#refuses a kind outside the five, by the kind check - >- services-platform:modules/metadata/tests/integration/db/custom-field-rules.table.integration.spec.js#refuses a condition rule without its condition, by the shape check - >- services-platform:modules/metadata/tests/integration/db/custom-field-rules.table.integration.spec.js#refuses a condition rule that also carries a value, by the shape check - >- services-platform:modules/metadata/tests/integration/db/custom-field-rules.table.integration.spec.js#refuses a unique rule carrying a condition, by the shape check - >- services-platform:modules/metadata/tests/integration/db/custom-field-rules.table.integration.spec.js#refuses an exposure rule without its value, by the shape check - >- services-platform:modules/metadata/tests/integration/db/custom-field-rules.table.integration.spec.js#accepts an exposure rule with its value - >- services-platform:modules/metadata/tests/integration/db/custom-field-rules.table.integration.spec.js#refuses a condition over 16 KiB, by the condition size check - >- services-platform:modules/metadata/tests/integration/db/custom-field-rules.table.integration.spec.js#refuses a sys_locked value outside the two the standard defines, by the locked check - >- services-platform:modules/metadata/tests/integration/db/custom-field-rules.table.integration.spec.js#refuses a blank kind: the trigger nulls it and the column refuses the null - >- services-platform:modules/metadata/tests/integration/db/custom-field-rules.table.integration.spec.js#moves the tenant’s query description stamp when a rule is written - >- services-platform:modules/metadata/tests/integration/db/custom-field-rules.table.integration.spec.js#goes with its field when the field is deleted - >- services-platform:modules/metadata/tests/integration/db/custom-field-rules.table.integration.spec.js#lets a tenant’s transaction read its own rule, the premise of the case below - >- services-platform:modules/metadata/tests/integration/db/custom-field-rules.table.integration.spec.js#hides another tenant’s rule from a tenant’s transaction, with no predicate of its own fixture_imports: - drizzle-orm - '@rhythmsoftware/macroservice-testing/refusals' - ../../../db/custom-field-rules.table - ../../../db/custom-fields.table - ../support test_doubles: [] limitations: [] unmatched_specification: null binding_assertions: - scenario: ATS-PFM-MTD-006-01 provenance: test source: - >- services-platform:modules/metadata/tests/integration/db/custom-field-rules.table.integration.spec.js#refuses a second rule of the same kind on the field, by the primary key note: >- These references identify the assertions this suite contributes; bindings to additional suites remain part of the scenario’s proof. - scenario: ATS-PFM-MTD-006-05 provenance: test source: - >- services-platform:modules/metadata/tests/integration/db/custom-field-rules.table.integration.spec.js#refuses an exposure rule without its value, by the shape check note: >- These references identify the assertions this suite contributes; bindings to additional suites remain part of the scenario’s proof. - scenario: ATS-PFM-MTD-006-08 provenance: test source: - >- services-platform:modules/metadata/tests/integration/db/custom-field-rules.table.integration.spec.js#moves the tenant’s query description stamp when a rule is written note: >- These references identify the assertions this suite contributes; bindings to additional suites remain part of the scenario’s proof. --- # Custom field rules table ## Verification Boundary This integration suite checks record descriptions and field configuration within the local test harness. The registered file and pinned revision define its boundary. ## What This Suite Proves The bindings identify the detailed or feature scenarios whose outcomes have assertions in this suite. Original case references remain attached to the detailed scenarios so a reviewer can inspect the exact assertion. Assertions are evidence of implemented checks; no execution result is claimed. ## What It Does Not Prove The register does not establish a current passing run or full specification conformance. Behavior outside the suite’s fixtures and assertions remains unverified. ## Real Dependencies and Test Doubles The fixture uses PostgreSQL and the imported persistence or API code. The fixture imports identify the setup seams; this register makes no broader claim that dependencies are undoubled. ## Must Not Be Doubled The operation under examination and its asserted stored outcomes must remain real within the declared harness. A fixture cannot replace the write, refusal or transactional effect that the bound scenario checks.