--- source_sha: services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1 services-crm: a8d1364f1dd44b723bb5f9acba12f983e9ec8d69 services-commerce: c8b66a98e2490617aec38ba5c8165dd9bd0a8f9b services-committees: 36129c24daeaadcdb339218c38cdeaff9861359d services-membership: 5994c270e8a37a30f848e99ba5b5ee6b87c08893 services-submissions: 64236c19be89579ef5897aad7de3925ed3ce03bf services-websites: 5fc6823c69d5e6f208c21dba8c0eb3132f8bdc4c services-marketing: d071a159fe9782bb71ff246d5c67d5bbfe07fbfa control_gap_evidence: - finding: FND-PFM-TNL-057 controls: - TC-DAT-004 - TC-PI-004 provenance: observed source: >- services-platform:modules/tenants/services/access/tenant-availability.ts; services-crm, services-commerce, services-submissions, services-websites:modules/tenant-lifecycle/services/lifecycle/tenant-availability.ts related_finding: FND-PFM-TNL-040 - finding: FND-PFM-TNL-058 controls: - TC-MON-002 provenance: observed source: >- services-platform:modules/tenants/services/reset/tenant-reset-workflow.ts:ensureTenantResetJobTypeRegistered (no requester notice, no failure consequence) related_finding: FND-PFM-TNL-041 - finding: FND-PFM-TNL-059 controls: - TC-LOG-001 - TC-DAT-004 - TC-PI-004 - TC-AVL-004 provenance: observed source: >- services-platform:modules/tenants/services/deletion/tenant-purge-operations.ts (finalize); tenant-purge-failure.ts:applyTenantPurgeFailure; operator-recovery.ts:retryTenantPurge related_finding: FND-PFM-TNL-043 - finding: FND-PFM-TNL-060 controls: - TC-PI-002 provenance: observed source: >- services-commerce:modules/tenant-lifecycle/services/participants/orders-participant.ts (seedBuiltInPricingAudiences, seedStorePlacements; no tenant_seed_applications in the repository) related_finding: FND-PFM-TNL-044 - finding: FND-PFM-TNL-061 controls: - TC-PI-005 provenance: observed source: >- services-platform:modules/tenants/services/persistence/tenants.ts:activateLoadedTenant, enterTenantLoading; services/reset/tenant-reset-operations.ts related_finding: FND-PFM-TNL-045 - finding: FND-PFM-TNL-062 controls: - TC-PI-005 provenance: observed source: >- services-platform:modules/tenants/services/persistence/tenant-resources.ts:recordTenantResource, setTenantResourceState; modules/tenants/db/tenant-resources.table.ts related_finding: FND-PFM-TNL-046 - finding: FND-PFM-TNL-063 controls: - TC-AVL-004 - TC-PI-004 - TC-DAT-004 provenance: observed source: >- services-platform:modules/tenants/services/deletion/tenant-purge-operations.ts:finalizeOperation, requirePurgeAuthority; modules/tenants/services/deletion/operator-recovery.ts:retryTenantPurge related_finding: FND-PFM-TNL-051 - finding: FND-PFM-TNL-064 controls: - TC-AVL-004 - TC-PI-004 provenance: observed source: >- services-platform:modules/tenants/services/deletion/operator-recovery.ts:resumeTenantDeletionSchedule, retryTenantPurge related_finding: FND-PFM-TNL-052 - finding: FND-PFM-TNL-065 controls: - TC-MON-002 - TC-PI-004 provenance: observed source: >- services-platform:modules/tenants/services/deletion/deletion-holds.ts:cancelTenantDeletion; modules/tenants/services/deletion/tenant-deletion-schedule-operations.ts:requestOfJob related_finding: FND-PFM-TNL-053 testing_coverage_gaps: - id: FND-PFM-TNL-066 capability: CAP-PFM-TNL-001 missing_categories: - edge - boundary - concurrency - rule - interaction - transition must_prove_without_scenario: - BR-CAP-PFM-TNL-001-08 related_without_combined_scenario: - CAP-PFM-TNL-004 - CAP-PFM-TNL-018 permissions_to_audit: - hq.tenants.provision state_models_requiring_complete_transition_proof: - STATE-PFM-TNL-001 - STATE-PFM-TNL-002 provenance: documented source: >- rhythm-v2-docs:specs/platform/tenant-lifecycle/planning/capabilities/CAP-PFM-TNL-001-ask-for-a-new-workspace-and-have-every-application-build-it.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/design/state-models/STATE-PFM-TNL-001-workspace-lifecycle.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/design/state-models/STATE-PFM-TNL-002-provisioning-attempt.md statement: >- Coverage for request a complete customer workspace still lacks a complete check of edge, boundary, concurrency, rule, interaction, transition. Existing examples do not establish every state-model guard, every authority boundary or every related-capability handoff; the structured inventory identifies the remaining proof obligations. - id: FND-PFM-TNL-067 capability: CAP-PFM-TNL-002 missing_categories: - permission - edge - boundary - concurrency - rule - interaction - transition must_prove_without_scenario: - BR-CAP-PFM-TNL-002-08 related_without_combined_scenario: - CAP-PFM-TNL-003 permissions_to_audit: - hq.tenants.provision state_models_requiring_complete_transition_proof: - STATE-PFM-TNL-001 - STATE-PFM-TNL-002 provenance: documented source: >- rhythm-v2-docs:specs/platform/tenant-lifecycle/planning/capabilities/CAP-PFM-TNL-002-open-a-new-workspace-only-when-every-application-reports-it.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/design/state-models/STATE-PFM-TNL-001-workspace-lifecycle.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/design/state-models/STATE-PFM-TNL-002-provisioning-attempt.md statement: >- Coverage for open a workspace after its applications are ready still lacks a complete check of permission, edge, boundary, concurrency, rule, interaction, transition. Existing examples do not establish every state-model guard, every authority boundary or every related-capability handoff; the structured inventory identifies the remaining proof obligations. - id: FND-PFM-TNL-068 capability: CAP-PFM-TNL-003 missing_categories: - validation - boundary - concurrency - transition must_prove_without_scenario: [] related_without_combined_scenario: [] permissions_to_audit: - hq.tenants.read - hq.tenants.provision state_models_requiring_complete_transition_proof: - STATE-PFM-TNL-001 - STATE-PFM-TNL-002 provenance: documented source: >- rhythm-v2-docs:specs/platform/tenant-lifecycle/planning/capabilities/CAP-PFM-TNL-003-follow-a-provisioning-retry-it-and-hear-how-it-ended.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/design/state-models/STATE-PFM-TNL-001-workspace-lifecycle.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/design/state-models/STATE-PFM-TNL-002-provisioning-attempt.md statement: >- Coverage for understand and recover a workspace build still lacks a complete check of validation, boundary, concurrency, transition. Existing examples do not establish every state-model guard, every authority boundary or every related-capability handoff; the structured inventory identifies the remaining proof obligations. - id: FND-PFM-TNL-069 capability: CAP-PFM-TNL-004 missing_categories: - permission - edge - failure - concurrency - transition must_prove_without_scenario: [] related_without_combined_scenario: [] permissions_to_audit: - hq.tenants.provision state_models_requiring_complete_transition_proof: - STATE-PFM-TNL-001 - STATE-PFM-TNL-002 provenance: documented source: >- rhythm-v2-docs:specs/platform/tenant-lifecycle/planning/capabilities/CAP-PFM-TNL-004-give-a-new-customer-its-first-administrator-and-its-own-e.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/design/state-models/STATE-PFM-TNL-001-workspace-lifecycle.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/design/state-models/STATE-PFM-TNL-002-provisioning-attempt.md statement: >- Coverage for prepare the customer’s first access and sender still lacks a complete check of permission, edge, failure, concurrency, transition. Existing examples do not establish every state-model guard, every authority boundary or every related-capability handoff; the structured inventory identifies the remaining proof obligations. - id: FND-PFM-TNL-070 capability: CAP-PFM-TNL-005 missing_categories: - validation - failure - concurrency - invariant - interaction - transition must_prove_without_scenario: [] related_without_combined_scenario: - CAP-PFM-TNL-013 - CAP-PFM-TNL-016 permissions_to_audit: [] state_models_requiring_complete_transition_proof: - STATE-PFM-TNL-001 provenance: documented source: >- rhythm-v2-docs:specs/platform/tenant-lifecycle/planning/capabilities/CAP-PFM-TNL-005-keep-people-and-background-work-out-of-a-workspace-that-is.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/design/state-models/STATE-PFM-TNL-001-workspace-lifecycle.md statement: >- Coverage for apply workspace availability consistently still lacks a complete check of validation, failure, concurrency, invariant, interaction, transition. Existing examples do not establish every state-model guard, every authority boundary or every related-capability handoff; the structured inventory identifies the remaining proof obligations. - id: FND-PFM-TNL-071 capability: CAP-PFM-TNL-006 missing_categories: - rule - validation - edge - failure - concurrency - interaction - transition must_prove_without_scenario: [] related_without_combined_scenario: - CAP-PFM-TNL-002 - CAP-PFM-TNL-011 - CAP-PFM-TNL-016 permissions_to_audit: - platform.tenants.manage-status state_models_requiring_complete_transition_proof: - STATE-PFM-TNL-001 provenance: documented source: >- rhythm-v2-docs:specs/platform/tenant-lifecycle/planning/capabilities/CAP-PFM-TNL-006-keep-every-workspace-s-lifecycle-state-truthful.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/design/state-models/STATE-PFM-TNL-001-workspace-lifecycle.md statement: >- Coverage for preserve valid workspace lifecycle states still lacks a complete check of rule, validation, edge, failure, concurrency, interaction, transition. Existing examples do not establish every state-model guard, every authority boundary or every related-capability handoff; the structured inventory identifies the remaining proof obligations. - id: FND-PFM-TNL-072 capability: CAP-PFM-TNL-007 missing_categories: - transition - edge - failure - concurrency - rule - interaction must_prove_without_scenario: - BR-CAP-PFM-TNL-007-08 related_without_combined_scenario: - CAP-PFM-TNL-008 - CAP-PFM-TNL-010 permissions_to_audit: [] state_models_requiring_complete_transition_proof: - STATE-PFM-TNL-006 provenance: documented source: >- rhythm-v2-docs:specs/platform/tenant-lifecycle/planning/capabilities/CAP-PFM-TNL-007-register-each-application-s-part-in-a-workspace-s-life.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/design/state-models/STATE-PFM-TNL-006-registered-external-resource.md statement: >- Coverage for account for each application’s lifecycle responsibilities still lacks a complete check of transition, edge, failure, concurrency, rule, interaction. Existing examples do not establish every state-model guard, every authority boundary or every related-capability handoff; the structured inventory identifies the remaining proof obligations. - id: FND-PFM-TNL-073 capability: CAP-PFM-TNL-008 missing_categories: - transition - failure - concurrency - rule must_prove_without_scenario: - BR-CAP-PFM-TNL-008-04 related_without_combined_scenario: [] permissions_to_audit: [] state_models_requiring_complete_transition_proof: [] provenance: documented source: >- rhythm-v2-docs:specs/platform/tenant-lifecycle/planning/capabilities/CAP-PFM-TNL-008-give-every-workspace-its-default-configuration-exactly-once.md statement: >- Coverage for apply defaults without undoing customer choices still lacks a complete check of transition, failure, concurrency, rule. Existing examples do not establish every state-model guard, every authority boundary or every related-capability handoff; the structured inventory identifies the remaining proof obligations. - id: FND-PFM-TNL-074 capability: CAP-PFM-TNL-009 missing_categories: - transition - permission - edge - boundary - concurrency - rule must_prove_without_scenario: - BR-CAP-PFM-TNL-009-06 related_without_combined_scenario: [] permissions_to_audit: - hq.tenants.provision state_models_requiring_complete_transition_proof: [] provenance: documented source: >- rhythm-v2-docs:specs/platform/tenant-lifecycle/planning/capabilities/CAP-PFM-TNL-009-bring-every-existing-workspace-up-to-the-current-baseline.md statement: >- Coverage for maintain the baseline of existing workspaces still lacks a complete check of transition, permission, edge, boundary, concurrency, rule. Existing examples do not establish every state-model guard, every authority boundary or every related-capability handoff; the structured inventory identifies the remaining proof obligations. - id: FND-PFM-TNL-075 capability: CAP-PFM-TNL-010 missing_categories: - edge - failure - concurrency must_prove_without_scenario: [] related_without_combined_scenario: [] permissions_to_audit: [] state_models_requiring_complete_transition_proof: [] provenance: documented source: >- rhythm-v2-docs:specs/platform/tenant-lifecycle/planning/capabilities/CAP-PFM-TNL-010-contribute-each-application-s-records-to-a-whole-workspace.md statement: >- Coverage for supply application data for workspace exports still lacks a complete check of edge, failure, concurrency. Existing examples do not establish every state-model guard, every authority boundary or every related-capability handoff; the structured inventory identifies the remaining proof obligations. - id: FND-PFM-TNL-076 capability: CAP-PFM-TNL-011 missing_categories: - rule - edge - failure - boundary - concurrency - invariant - transition must_prove_without_scenario: - BR-CAP-PFM-TNL-011-06 related_without_combined_scenario: [] permissions_to_audit: - hq.data-runs.manage - hq.tenants.activate state_models_requiring_complete_transition_proof: - STATE-PFM-TNL-001 - STATE-PFM-TNL-003 provenance: documented source: >- rhythm-v2-docs:specs/platform/tenant-lifecycle/planning/capabilities/CAP-PFM-TNL-011-open-a-workspace-for-its-initial-import-and-let-its-people.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/design/state-models/STATE-PFM-TNL-001-workspace-lifecycle.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/design/state-models/STATE-PFM-TNL-003-initial-load-and-its-resets.md statement: >- Coverage for control the initial import and subsequent opening still lacks a complete check of rule, edge, failure, boundary, concurrency, invariant, transition. Existing examples do not establish every state-model guard, every authority boundary or every related-capability handoff; the structured inventory identifies the remaining proof obligations. - id: FND-PFM-TNL-077 capability: CAP-PFM-TNL-012 missing_categories: - edge - boundary - rule - transition must_prove_without_scenario: - BR-CAP-PFM-TNL-012-10 related_without_combined_scenario: [] permissions_to_audit: - hq.data-runs.manage state_models_requiring_complete_transition_proof: - STATE-PFM-TNL-001 - STATE-PFM-TNL-003 provenance: documented source: >- rhythm-v2-docs:specs/platform/tenant-lifecycle/planning/capabilities/CAP-PFM-TNL-012-empty-a-loading-workspace-so-it-can-be-loaded-again.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/design/state-models/STATE-PFM-TNL-001-workspace-lifecycle.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/design/state-models/STATE-PFM-TNL-003-initial-load-and-its-resets.md statement: >- Coverage for recover an incorrect initial import still lacks a complete check of edge, boundary, rule, transition. Existing examples do not establish every state-model guard, every authority boundary or every related-capability handoff; the structured inventory identifies the remaining proof obligations. - id: FND-PFM-TNL-078 capability: CAP-PFM-TNL-013 missing_categories: - rule - edge - failure - invariant - interaction - transition must_prove_without_scenario: - BR-CAP-PFM-TNL-013-11 related_without_combined_scenario: - CAP-PFM-TNL-003 permissions_to_audit: - platform.tenants.deletion-request state_models_requiring_complete_transition_proof: - STATE-PFM-TNL-001 - STATE-PFM-TNL-004 provenance: documented source: >- rhythm-v2-docs:specs/platform/tenant-lifecycle/planning/capabilities/CAP-PFM-TNL-013-ask-for-a-workspace-to-be-deleted-after-a-waiting-period.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/design/state-models/STATE-PFM-TNL-001-workspace-lifecycle.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/design/state-models/STATE-PFM-TNL-004-deletion-request.md statement: >- Coverage for schedule deliberate workspace deletion still lacks a complete check of rule, edge, failure, invariant, interaction, transition. Existing examples do not establish every state-model guard, every authority boundary or every related-capability handoff; the structured inventory identifies the remaining proof obligations. - id: FND-PFM-TNL-079 capability: CAP-PFM-TNL-014 missing_categories: - rule - failure - concurrency - invariant - transition must_prove_without_scenario: - BR-CAP-PFM-TNL-014-07 related_without_combined_scenario: [] permissions_to_audit: - platform.tenants.deletion-hold - platform.tenants.deletion-cancel - platform.tenants.deletion-read state_models_requiring_complete_transition_proof: - STATE-PFM-TNL-001 - STATE-PFM-TNL-004 provenance: documented source: >- rhythm-v2-docs:specs/platform/tenant-lifecycle/planning/capabilities/CAP-PFM-TNL-014-hold-release-or-call-off-a-deletion-before-destruction.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/design/state-models/STATE-PFM-TNL-001-workspace-lifecycle.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/design/state-models/STATE-PFM-TNL-004-deletion-request.md statement: >- Coverage for pause or cancel deletion while preservation remains possible still lacks a complete check of rule, failure, concurrency, invariant, transition. Existing examples do not establish every state-model guard, every authority boundary or every related-capability handoff; the structured inventory identifies the remaining proof obligations. - id: FND-PFM-TNL-080 capability: CAP-PFM-TNL-015 missing_categories: - rule - validation - edge - concurrency - interaction - transition must_prove_without_scenario: - BR-CAP-PFM-TNL-015-07 related_without_combined_scenario: - CAP-PFM-TNL-017 permissions_to_audit: [] state_models_requiring_complete_transition_proof: - STATE-PFM-TNL-005 provenance: documented source: >- rhythm-v2-docs:specs/platform/tenant-lifecycle/planning/capabilities/CAP-PFM-TNL-015-tell-rhythm-staff-about-every-step-of-a-deletion.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/design/state-models/STATE-PFM-TNL-005-deletion-notice-delivery.md statement: >- Coverage for keep deletion decisions visible to staff still lacks a complete check of rule, validation, edge, concurrency, interaction, transition. Existing examples do not establish every state-model guard, every authority boundary or every related-capability handoff; the structured inventory identifies the remaining proof obligations. - id: FND-PFM-TNL-081 capability: CAP-PFM-TNL-016 missing_categories: - rule - invariant - transition must_prove_without_scenario: [] related_without_combined_scenario: [] permissions_to_audit: - platform.tenants.deletion-request state_models_requiring_complete_transition_proof: - STATE-PFM-TNL-001 - STATE-PFM-TNL-004 provenance: documented source: >- rhythm-v2-docs:specs/platform/tenant-lifecycle/planning/capabilities/CAP-PFM-TNL-016-begin-destruction-only-when-every-safeguard-still-holds.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/design/state-models/STATE-PFM-TNL-001-workspace-lifecycle.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/design/state-models/STATE-PFM-TNL-004-deletion-request.md statement: >- Coverage for revalidate the irreversible deletion decision still lacks a complete check of rule, invariant, transition. Existing examples do not establish every state-model guard, every authority boundary or every related-capability handoff; the structured inventory identifies the remaining proof obligations. - id: FND-PFM-TNL-082 capability: CAP-PFM-TNL-017 missing_categories: - transition - validation - concurrency - rule - interaction must_prove_without_scenario: - BR-CAP-PFM-TNL-017-07 - BR-CAP-PFM-TNL-017-13 - BR-CAP-PFM-TNL-017-14 related_without_combined_scenario: - CAP-PFM-TNL-015 permissions_to_audit: - platform.tenants.deletion-request state_models_requiring_complete_transition_proof: - STATE-PFM-TNL-001 - STATE-PFM-TNL-004 provenance: documented source: >- rhythm-v2-docs:specs/platform/tenant-lifecycle/planning/capabilities/CAP-PFM-TNL-017-remove-everything-a-workspace-owned-and-prove-it-is-gone.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/design/state-models/STATE-PFM-TNL-001-workspace-lifecycle.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/design/state-models/STATE-PFM-TNL-004-deletion-request.md statement: >- Coverage for remove declared workspace resources and verify the result still lacks a complete check of transition, validation, concurrency, rule, interaction. Existing examples do not establish every state-model guard, every authority boundary or every related-capability handoff; the structured inventory identifies the remaining proof obligations. - id: FND-PFM-TNL-083 capability: CAP-PFM-TNL-018 missing_categories: - transition - permission - failure - boundary - concurrency - rule must_prove_without_scenario: - BR-CAP-PFM-TNL-018-06 related_without_combined_scenario: [] permissions_to_audit: - platform.tenants.deletion-read - hq.tenants.update state_models_requiring_complete_transition_proof: - STATE-PFM-TNL-001 - STATE-PFM-TNL-004 provenance: documented source: >- rhythm-v2-docs:specs/platform/tenant-lifecycle/planning/capabilities/CAP-PFM-TNL-018-keep-a-lasting-record-of-a-deleted-workspace-and-stop-it.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/design/state-models/STATE-PFM-TNL-001-workspace-lifecycle.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/design/state-models/STATE-PFM-TNL-004-deletion-request.md statement: >- Coverage for retain deletion evidence and prevent identifier reuse still lacks a complete check of transition, permission, failure, boundary, concurrency, rule. Existing examples do not establish every state-model guard, every authority boundary or every related-capability handoff; the structured inventory identifies the remaining proof obligations. testing_unbound_files: - suite: TST-PFM-TNL-001 source: >- services-commerce:modules/tenant-lifecycle/tests/integration/db/declaration-completeness.integration.spec.js provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-002 source: 'services-commerce:modules/tenant-lifecycle/tests/integration/db/purge-order.integration.spec.js' provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-004 source: >- services-commerce:modules/tenant-lifecycle/tests/integration/services/participants/orders-participant.integration.spec.js provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-005 source: >- services-commerce:modules/tenant-lifecycle/tests/integration/services/participants/tenant-export.integration.spec.js provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-006 source: >- services-commerce:modules/tenant-lifecycle/tests/integration/services/persistence/tenant-exports.queries.integration.spec.js provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-007 source: >- services-commerce:modules/tenant-lifecycle/tests/integration/services/persistence/tenants.queries.integration.spec.js provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-008 source: 'services-commerce:modules/tenant-lifecycle/tests/unit/exports/export-round-trip.spec.js' provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-009 source: 'services-commerce:modules/tenant-lifecycle/tests/unit/lifecycle/tenant-availability.spec.js' provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-010 source: 'services-commerce:modules/tenant-lifecycle/tests/unit/lifecycle/tenant-lifecycle-operations.spec.js' provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-011 source: 'services-commerce:modules/tenant-lifecycle/tests/unit/participants/export-coverage.spec.js' provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-012 source: 'services-commerce:modules/tenant-lifecycle/tests/unit/participants/manifests.spec.js' provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-013 source: >- services-committees:modules/tenant-lifecycle/tests/integration/db/tenant-declaration-completeness.integration.spec.ts provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-014 source: >- services-committees:modules/tenant-lifecycle/tests/integration/services/lifecycle-wire-names.integration.spec.ts provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-015 source: >- services-committees:modules/tenant-lifecycle/tests/integration/services/starter-types.integration.spec.ts provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-016 source: 'services-committees:modules/tenant-lifecycle/tests/integration/services/tenant-purge.integration.spec.ts' provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-017 source: 'services-committees:modules/tenant-lifecycle/tests/unit/lifecycle-wire-names.spec.ts' provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-018 source: 'services-committees:modules/tenant-lifecycle/tests/unit/participants.spec.ts' provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-019 source: 'services-crm:modules/tenant-lifecycle/tests/e2e/tenant-availability.e2e.spec.js' provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-020 source: 'services-crm:modules/tenant-lifecycle/tests/integration/db/declaration-completeness.integration.spec.js' provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-021 source: 'services-crm:modules/tenant-lifecycle/tests/integration/db/purge-order.integration.spec.js' provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-024 source: >- services-crm:modules/tenant-lifecycle/tests/integration/services/lifecycle/tenant-lifecycle-operations.integration.spec.js provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-025 source: >- services-crm:modules/tenant-lifecycle/tests/integration/services/participants/activities-provisioning.integration.spec.js provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-028 source: 'services-crm:modules/tenant-lifecycle/tests/integration/services/participants/reset.integration.spec.js' provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-029 source: >- services-crm:modules/tenant-lifecycle/tests/integration/services/persistence/tenant-exports.queries.integration.spec.js provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-030 source: 'services-crm:modules/tenant-lifecycle/tests/unit/export/round-trip.spec.js' provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-032 source: 'services-crm:modules/tenant-lifecycle/tests/unit/lifecycle/tenant-availability.spec.js' provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-033 source: 'services-crm:modules/tenant-lifecycle/tests/unit/lifecycle/tenant-lifecycle-operations.spec.js' provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-034 source: 'services-crm:modules/tenant-lifecycle/tests/unit/participants/deletion-order.spec.js' provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-035 source: 'services-crm:modules/tenant-lifecycle/tests/unit/participants/export-coverage.spec.js' provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-036 source: 'services-crm:modules/tenant-lifecycle/tests/unit/participants/manifests.spec.js' provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-037 source: 'services-crm:modules/tenant-lifecycle/tests/unit/participants/reset-order.spec.js' provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-038 source: >- services-marketing:modules/tenant-lifecycle/tests/integration/db/tenant-declaration-completeness.integration.spec.ts provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-039 source: >- services-marketing:modules/tenant-lifecycle/tests/integration/services/lifecycle-wire-names.integration.spec.ts provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-040 source: 'services-marketing:modules/tenant-lifecycle/tests/integration/services/tenant-purge.integration.spec.ts' provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-041 source: 'services-marketing:modules/tenant-lifecycle/tests/unit/lifecycle-wire-names.spec.ts' provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-042 source: 'services-marketing:modules/tenant-lifecycle/tests/unit/participants.spec.ts' provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-043 source: >- services-membership:modules/tenant-lifecycle/tests/integration/services/lifecycle/export-coverage.integration.spec.ts provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-044 source: >- services-membership:modules/tenant-lifecycle/tests/integration/services/lifecycle/self-referencing-purge.integration.spec.ts provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-045 source: >- services-membership:modules/tenant-lifecycle/tests/integration/services/lifecycle/tenant-lifecycle.integration.spec.ts provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-046 source: 'services-membership:modules/tenant-lifecycle/tests/unit/export-coverage.spec.ts' provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-047 source: 'services-membership:modules/tenant-lifecycle/tests/unit/participants.spec.ts' provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-048 source: 'services-membership:modules/tenant-lifecycle/tests/unit/wire-names.spec.ts' provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-053 source: 'services-platform:modules/tenants/tests/e2e/tenant-email-sender.e2e.spec.js' provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-054 source: 'services-platform:modules/tenants/tests/e2e/tenant-hubspot-link.e2e.spec.js' provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-058 source: >- services-platform:modules/tenants/tests/integration/db/tenant-declaration-completeness.integration.spec.js provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-059 source: 'services-platform:modules/tenants/tests/integration/db/tenants.table.integration.spec.js' provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-060 source: 'services-platform:modules/tenants/tests/integration/lifecycle/reconciled-job-failure.integration.spec.js' provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-065 source: >- services-platform:modules/tenants/tests/integration/services/deletion/tenant-purge-functions.integration.spec.js provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-068 source: >- services-platform:modules/tenants/tests/integration/services/lifecycle/first-administrator.integration.spec.js provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-069 source: >- services-platform:modules/tenants/tests/integration/services/persistence/tenant-deletion-requests.integration.spec.js provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-070 source: >- services-platform:modules/tenants/tests/integration/services/persistence/tenant-deletion-requests.queries.integration.spec.js provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-071 source: >- services-platform:modules/tenants/tests/integration/services/persistence/tenant-deletion-schedule-jobs.queries.integration.spec.js provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-072 source: >- services-platform:modules/tenants/tests/integration/services/persistence/tenant-provisioning-jobs.queries.integration.spec.js provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-073 source: >- services-platform:modules/tenants/tests/integration/services/persistence/tenant-purge-jobs.queries.integration.spec.js provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-074 source: >- services-platform:modules/tenants/tests/integration/services/persistence/tenant-reset-jobs.queries.integration.spec.js provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-079 source: >- services-platform:modules/tenants/tests/integration/services/provisioning/initialize-tenant.integration.spec.js provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-081 source: >- services-platform:modules/tenants/tests/integration/services/provisioning/provision-tenant.development-licences.integration.spec.js provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-084 source: >- services-platform:modules/tenants/tests/integration/services/provisioning/repair-stranded-provisioning.integration.spec.js provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-088 source: 'services-platform:modules/tenants/tests/unit/aws/api/tenant-commercial-link.spec.ts' provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-089 source: 'services-platform:modules/tenants/tests/unit/aws/api/tenant-provisioning-mapper.spec.ts' provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-090 source: 'services-platform:modules/tenants/tests/unit/db/tenant-id.spec.ts' provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-092 source: 'services-platform:modules/tenants/tests/unit/services/deletion/deletion-ledger.spec.js' provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-093 source: 'services-platform:modules/tenants/tests/unit/services/deletion/schedule-wake-fields.spec.js' provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-094 source: 'services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js' provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-095 source: 'services-platform:modules/tenants/tests/unit/services/lifecycle/first-administrator.spec.ts' provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-099 source: 'services-platform:modules/tenants/tests/unit/services/lifecycle/reset-participants.spec.js' provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-100 source: 'services-platform:modules/tenants/tests/unit/services/provisioning/provision-existing-tenant.spec.js' provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-101 source: 'services-platform:modules/tenants/tests/unit/services/provisioning/provision-tenant-workflow.spec.js' provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-102 source: 'services-platform:modules/tenants/tests/unit/services/provisioning/provisioning-notice.spec.js' provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-103 source: >- services-submissions:modules/tenant-lifecycle/tests/integration/db/declaration-completeness.integration.spec.js provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-104 source: 'services-submissions:modules/tenant-lifecycle/tests/integration/db/export-coverage.integration.spec.js' provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-105 source: 'services-submissions:modules/tenant-lifecycle/tests/integration/db/purge-order.integration.spec.js' provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-106 source: >- services-submissions:modules/tenant-lifecycle/tests/integration/services/export/seed-everything.integration.spec.js provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-107 source: >- services-submissions:modules/tenant-lifecycle/tests/integration/services/persistence/tenants.queries.integration.spec.js provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-108 source: 'services-submissions:modules/tenant-lifecycle/tests/unit/export/export-coverage.spec.js' provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-109 source: 'services-submissions:modules/tenant-lifecycle/tests/unit/lifecycle/tenant-availability.spec.js' provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-110 source: 'services-submissions:modules/tenant-lifecycle/tests/unit/lifecycle/tenant-lifecycle-operations.spec.js' provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-111 source: 'services-submissions:modules/tenant-lifecycle/tests/unit/participants/manifests.spec.js' provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-112 source: >- services-websites:modules/tenant-lifecycle/tests/integration/db/declaration-completeness.integration.spec.js provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-113 source: >- services-websites:modules/tenant-lifecycle/tests/integration/services/participants/changes-export.integration.spec.js provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-115 source: >- services-websites:modules/tenant-lifecycle/tests/integration/services/participants/content-participant.integration.spec.js provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-116 source: >- services-websites:modules/tenant-lifecycle/tests/integration/services/persistence/tenants.queries.integration.spec.js provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-117 source: 'services-websites:modules/tenant-lifecycle/tests/unit/lifecycle/tenant-availability.spec.js' provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-118 source: 'services-websites:modules/tenant-lifecycle/tests/unit/lifecycle/tenant-lifecycle-operations.spec.js' provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-119 source: 'services-websites:modules/tenant-lifecycle/tests/unit/participants/export-coverage.spec.js' provenance: test finding: FND-PFM-TNL-084 - suite: TST-PFM-TNL-120 source: 'services-websites:modules/tenant-lifecycle/tests/unit/participants/manifests.spec.js' provenance: test finding: FND-PFM-TNL-084 testing_excluded_files: - source: 'services-platform:modules/tenants/tests/e2e/hq-tenant-shortcuts.e2e.spec.js' reason: >- Delegated workspace administration, shortcuts, default selection or general time-zone wiring; no lifecycle acceptance binding is established. provenance: test finding: FND-PFM-TNL-084 - source: 'services-platform:modules/tenants/tests/e2e/hq-tenants.e2e.spec.js' reason: >- Delegated workspace administration, shortcuts, default selection or general time-zone wiring; no lifecycle acceptance binding is established. provenance: test finding: FND-PFM-TNL-084 - source: >- services-platform:modules/tenants/tests/integration/services/default/get-default-tenant.integration.spec.js reason: >- Delegated workspace administration, shortcuts, default selection or general time-zone wiring; no lifecycle acceptance binding is established. provenance: test finding: FND-PFM-TNL-084 - source: >- services-platform:modules/tenants/tests/integration/services/persistence/staff-tenant-shortcuts.integration.spec.js reason: >- Delegated workspace administration, shortcuts, default selection or general time-zone wiring; no lifecycle acceptance binding is established. provenance: test finding: FND-PFM-TNL-084 - source: >- services-platform:modules/tenants/tests/integration/services/persistence/staff-tenant-shortcuts.queries.integration.spec.js reason: >- Delegated workspace administration, shortcuts, default selection or general time-zone wiring; no lifecycle acceptance binding is established. provenance: test finding: FND-PFM-TNL-084 - source: 'services-platform:modules/tenants/tests/unit/aws/api/hq-tenant-list-mapper.spec.ts' reason: >- Delegated workspace administration, shortcuts, default selection or general time-zone wiring; no lifecycle acceptance binding is established. provenance: test finding: FND-PFM-TNL-084 - source: 'services-platform:modules/tenants/tests/unit/db/normalize-tenant.spec.js' reason: >- Delegated workspace administration, shortcuts, default selection or general time-zone wiring; no lifecycle acceptance binding is established. provenance: test finding: FND-PFM-TNL-084 - source: 'services-platform:modules/tenants/tests/unit/services/default/get-default-tenant.spec.js' reason: >- Delegated workspace administration, shortcuts, default selection or general time-zone wiring; no lifecycle acceptance binding is established. provenance: test finding: FND-PFM-TNL-084 - source: 'services-platform:modules/tenants/tests/unit/tenant-time-zone-wiring.spec.js' reason: >- Delegated workspace administration, shortcuts, default selection or general time-zone wiring; no lifecycle acceptance binding is established. provenance: test finding: FND-PFM-TNL-084 authoring_conflicts: - finding: FND-PFM-TNL-085 provenance: documented source: >- rhythm-v2-docs:specs/CONVENTIONS.md#9.10; rhythm-v2-docs:specs/CONVENTIONS.md#6; rhythm-v2-docs:tools/check-corpus.mjs decision: Keep test evidence in frontmatter; omit the Evidence body heading rejected by conformance. testing_partial_scenarios: - scenario: ATS-PFM-TNL-001-04 sources: - >- services-platform:modules/tenants/tests/integration/services/provisioning/provision-tenant.integration.spec.js#refuses a different submission that names a tenant id somebody already has - >- services-platform:modules/tenants/tests/e2e/tenants.e2e.spec.js#refuses an id another tenant has as 409 tenant_id_taken finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-002-01 sources: - >- services-platform:modules/tenants/tests/unit/services/provisioning/provision-tenant-workflow.spec.js#runs the tenant row before anything that depends on it - >- services-platform:modules/tenants/tests/unit/services/provisioning/provision-tenant-workflow.spec.js#names every planned participant exactly once - >- services-platform:modules/tenants/tests/unit/services/provisioning/provision-tenant-workflow.spec.js#has one step per planned participant, then the readiness check and the activation - >- services-platform:modules/tenants/tests/integration/services/provisioning/provision-tenant.integration.spec.js#provisions all seven of CRM’s participants, the tasks, activities and duplicates participants after the entities they depend on finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-002-02 sources: - >- services-platform:modules/tenants/tests/unit/services/provisioning/provision-tenant-workflow.spec.js#refuses a run whose participants are not the ones it was planned for, naming both plans - >- services-platform:modules/tenants/tests/unit/services/lifecycle/remote-participants.spec.js#plans the live manifests, so normalised, in exactly the order the static copies plan (what the publish step compares) - >- services-platform:modules/tenants/tests/integration/services/deletion/tenant-purge.integration.spec.js#refuses the purge as planned for other participants rather than skipping one finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-003-06 sources: - >- services-platform:modules/tenants/tests/integration/services/provisioning/repair-stranded-provisioning.integration.spec.js#moves the stranded tenant to provisioning_failed, which makes it retryable and deletable again - >- services-platform:modules/tenants/tests/integration/services/provisioning/repair-stranded-provisioning.integration.spec.js#tells the staff member who asked for the tenant once, with the job’s own summary - >- services-platform:modules/tenants/tests/integration/services/provisioning/repair-stranded-provisioning.integration.spec.js#leaves a tenant whose provisioning is still running provisioning - >- services-platform:modules/tenants/tests/integration/services/provisioning/repair-stranded-provisioning.integration.spec.js#changes nothing about the repaired tenant on a second pass - >- services-platform:modules/tenants/tests/integration/lifecycle/reconciled-job-failure.integration.spec.js#moves the tenant to provisioning_failed, which is what makes it retryable and deletable again finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-003-09 sources: - >- services-platform:modules/tenants/tests/integration/services/provisioning/provision-tenant.integration.spec.js#does the missing work and not the finished work when it is provisioned again - >- services-platform:modules/tenants/tests/e2e/tenant-provisioning.e2e.spec.js#leaves the tenant usable after the retry finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-004-02 sources: - >- services-platform:modules/tenants/tests/integration/services/lifecycle/first-administrator.integration.spec.js#leaves an invited console user of the customer holding the address - >- services-platform:modules/tenants/tests/integration/services/lifecycle/first-administrator.integration.spec.js#grants that user the Administrator role at the customer, waiting on their acceptance - >- services-platform:modules/tenants/tests/integration/services/lifecycle/first-administrator.integration.spec.js#sends them one invitation - >- services-platform:modules/tenants/tests/unit/services/lifecycle/first-administrator.spec.ts#grants the built-in Administrator role, by the product key the catalog publishes it under finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-004-03 sources: - >- services-platform:modules/tenants/tests/integration/services/provisioning/provision-tenant.integration.spec.js#invites them once, and records the invitation in the ledger - >- services-platform:modules/tenants/tests/integration/services/provisioning/provision-tenant.integration.spec.js#does not invite them a second time when the provisioning is run again - >- services-platform:modules/tenants/tests/integration/services/lifecycle/first-administrator.integration.spec.js#sends no second invitation finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-004-04 sources: - >- services-platform:modules/tenants/tests/unit/services/lifecycle/first-administrator.spec.ts#refuses a SUSPENDED user, whatever they hold: an administrator nobody can use is none - >- services-platform:modules/tenants/tests/unit/services/lifecycle/first-administrator.spec.ts#refuses when the grant is of another role, which administers nothing - >- services-platform:modules/tenants/tests/unit/services/lifecycle/first-administrator.spec.ts#refuses when the Administrator grant is at tenant scope rather than the customer’s own - >- services-platform:modules/tenants/tests/unit/services/lifecycle/first-administrator.spec.ts#refuses a grant that has already ended - >- services-platform:modules/tenants/tests/integration/services/lifecycle/first-administrator.integration.spec.js#refuses the job rather than reporting an administrator the customer does not have finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-004-06 sources: - >- services-platform:modules/tenants/tests/integration/services/provisioning/tenant-email-strategy.integration.spec.js#proves the tenant’s id as the domain, the id being a hostname - >- services-platform:modules/tenants/tests/e2e/tenant-email-sender.e2e.spec.js#proves the tenant’s own domain, because the request left the strategy’s domain to it finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-004-07 sources: - >- services-platform:modules/tenants/tests/integration/services/provisioning/tenant-email-strategy.integration.spec.js#opens the tenant anyway, which is what option A promises - >- services-platform:modules/tenants/tests/integration/services/provisioning/tenant-email-strategy.integration.spec.js#leaves its sender identity pending, for the customer to finish in their own time - >- services-platform:modules/tenants/tests/e2e/tenant-email-sender.e2e.spec.js#answers the DNS records the customer must publish, so a support person can read them out finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-004-09 sources: - >- services-platform:modules/tenants/tests/integration/services/provisioning/provision-tenant.integration.spec.js#invites them once, and records the invitation in the ledger - >- services-platform:modules/tenants/tests/integration/services/provisioning/tenant-email-strategy.integration.spec.js#opens the tenant anyway, which is what option A promises finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-005-01 sources: - >- services-platform:modules/tenants/tests/e2e/tenant-availability-gate.e2e.spec.js#is served a tenant-scoped route in an active tenant (the premise every refusal below is read against) - >- services-platform:modules/tenants/tests/e2e/tenant-availability-gate.e2e.spec.js#is refused 403 in a tenant whose customer has been cut off - >- services-platform:modules/tenants/tests/e2e/tenant-availability-gate.e2e.spec.js#is refused 403 in a tenant that is still being provisioned - >- services-platform:modules/tenants/tests/e2e/tenant-availability-gate.e2e.spec.js#is refused 403 in a tenant whose destruction has begun - >- services-platform:modules/tenants/tests/e2e/tenant-availability-gate.e2e.spec.js#is told only that the tenant is not available - >- services-crm:modules/tenant-lifecycle/tests/e2e/tenant-availability.e2e.spec.js#is refused 403 TenantUnavailable in the disabled tenant - >- services-crm:modules/tenant-lifecycle/tests/e2e/tenant-availability.e2e.spec.js#is refused 403 TenantUnavailable in a tenant still being provisioned finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-005-03 sources: - >- services-platform:modules/tenants/tests/unit/services/access/tenant-availability.spec.js#is reads only for staff once destruction has begun, so support can still inspect it - >- services-platform:modules/tenants/tests/e2e/tenant-availability-gate.e2e.spec.js#may not write to a tenant being deleted, which the same caller being served above is the premise for finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-005-04 sources: - >- services-platform:modules/tenants/tests/e2e/tenant-availability-gate.e2e.spec.js#is refused 403 in a tenant whose initial data import is open - >- services-platform:modules/tenants/tests/e2e/tenant-availability-gate.e2e.spec.js#is past the gate in a tenant whose initial data import is open, which is what lets the import run at all - >- services-crm:modules/tenant-lifecycle/tests/e2e/tenant-availability.e2e.spec.js#is served the submission of a bulk contact job, which is what the import is made of - >- services-crm:modules/tenant-lifecycle/tests/e2e/tenant-availability.e2e.spec.js#is refused the contact list 403 TenantUnavailable, because nothing but the import may touch the tenant - >- services-platform:modules/tenants/tests/unit/services/access/tenant-availability.spec.js#serves the upload protocol, which is what the load is made of - >- services-platform:modules/tenants/tests/unit/services/access/tenant-availability.spec.js#serves staff, who reach every tenant on a system route finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-005-08 sources: - >- services-platform:modules/tenants/tests/e2e/tenant-availability-gate.e2e.spec.js#is refused 403 in a tenant that is still being provisioned - >- services-platform:modules/tenants/tests/e2e/tenant-provisioning.e2e.spec.js#leaves the tenant usable once the job has run finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-005-09 sources: - >- services-platform:modules/tenants/tests/e2e/tenant-availability-gate.e2e.spec.js#is refused 403 in a tenant whose initial data import is open - >- services-crm:modules/tenant-lifecycle/tests/e2e/tenant-availability.e2e.spec.js#is refused the contact list 403 TenantUnavailable, because nothing but the import may touch the tenant finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-006-01 sources: - >- services-platform:modules/tenants/tests/e2e/tenants.e2e.spec.js#answers 200 to a patch aimed at the lifecycle state, because the property is simply dropped - >- services-platform:modules/tenants/tests/e2e/tenants.e2e.spec.js#leaves the lifecycle state where the server put it after such a patch - >- services-platform:modules/tenants/tests/integration/services/persistence/tenants.integration.spec.js#ignores a lifecycle state a write input carries, rather than letting a client set the system axis finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-007-01 sources: - >- services-crm:modules/tenant-lifecycle/tests/unit/lifecycle/tenant-lifecycle-operations.spec.js#answers describe without reaching a tenant, so Platform can ask before a tenant exists - >- services-crm:modules/tenant-lifecycle/tests/unit/lifecycle/tenant-lifecycle-operations.spec.js#refuses an operation that names no tenant - >- services-committees:modules/tenant-lifecycle/tests/unit/participants.spec.ts#refuses a request that names no tenant - >- services-marketing:modules/tenant-lifecycle/tests/unit/participants.spec.ts#refuses a request that names no tenant - >- services-membership:modules/tenant-lifecycle/tests/unit/participants.spec.ts#refuses an operation that names no tenant finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-007-02 sources: - >- services-crm:modules/tenant-lifecycle/tests/unit/lifecycle/tenant-lifecycle-operations.spec.js#refuses an operation it does not have - >- services-crm:modules/tenant-lifecycle/tests/unit/lifecycle/tenant-lifecycle-operations.spec.js#refuses a participant CRM does not register - >- services-crm:modules/tenant-lifecycle/tests/unit/lifecycle/tenant-lifecycle-operations.spec.js#refuses a provision that belongs to no run - >- services-crm:modules/tenant-lifecycle/tests/unit/lifecycle/tenant-lifecycle-operations.spec.js#refuses a batch larger than the largest the batched delete accepts - >- services-committees:modules/tenant-lifecycle/tests/unit/participants.spec.ts#refuses an operation the contract does not name finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-007-03 sources: - >- services-crm:modules/tenant-lifecycle/tests/unit/participants/deletion-order.spec.js#provisions the tenant row, then regions, merges and data jobs, then entities, then tasks and duplicates, then activities - >- services-crm:modules/tenant-lifecycle/tests/unit/participants/deletion-order.spec.js#purges activities, then tasks and duplicates, then entities, then regions, merges and data jobs, then the tenant row - >- services-crm:modules/tenant-lifecycle/tests/unit/participants/deletion-order.spec.js#leaves the tenant row until last, in a stage of its own - >- services-membership:modules/tenant-lifecycle/tests/unit/participants.spec.ts#plans the structure before the memberships at provisioning and after them at deletion - >- services-submissions:modules/tenant-lifecycle/tests/unit/participants/manifests.spec.js#is provisioned by the planner in that order, and deleted in the reverse, one participant per wave finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-007-04 sources: - >- services-platform:modules/tenants/tests/integration/db/tenant-declaration-completeness.integration.spec.js#declares every tenant-keyed table the database holds - >- services-platform:modules/tenants/tests/integration/db/tenant-declaration-completeness.integration.spec.js#declares no table twice, so a plan can say which participant removes it - >- services-crm:modules/tenant-lifecycle/tests/integration/db/declaration-completeness.integration.spec.js#leaves no tenant-keyed table undeclared - >- services-crm:modules/tenant-lifecycle/tests/integration/db/declaration-completeness.integration.spec.js#lets no two participants claim the same table - >- services-submissions:modules/tenant-lifecycle/tests/integration/db/declaration-completeness.integration.spec.js#leaves no tenant-keyed table undeclared - >- services-committees:modules/tenant-lifecycle/tests/integration/db/tenant-declaration-completeness.integration.spec.ts#finds every tenant-keyed table declared once, and every declared table present - >- services-membership:modules/tenant-lifecycle/tests/integration/services/lifecycle/tenant-lifecycle.integration.spec.ts#declares every tenant-keyed table of the schema exactly once - >- services-marketing:modules/tenant-lifecycle/tests/integration/db/tenant-declaration-completeness.integration.spec.ts#finds every tenant-keyed table declared once, and every declared table present finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-007-06 sources: - >- services-crm:modules/tenant-lifecycle/tests/unit/lifecycle/tenant-lifecycle-operations.spec.js#names reset among the operations of every participant it describes, which is how Platform knows it may reset the tenant - >- services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#refuses the reset, naming the service and the contract it has to implement finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-008-01 sources: - >- services-platform:modules/tenants/tests/integration/services/persistence/tenant-seed-applications.integration.spec.js#applies every seed of the set and records each against the run that wrote it - >- services-crm:modules/tenant-lifecycle/tests/integration/services/participants/provisioning.integration.spec.js#records every seed in the ledger, against the run that applied them - >- services-committees:modules/tenant-lifecycle/tests/integration/services/starter-types.integration.spec.ts#keeps one ledger row for each of the fourteen finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-008-02 sources: - >- services-crm:modules/tenant-lifecycle/tests/integration/services/participants/provisioning.integration.spec.js#does not recreate a default the customer deleted - >- services-crm:modules/tenant-lifecycle/tests/integration/services/participants/provisioning.integration.spec.js#does not recreate an affiliation type the customer deleted - >- services-crm:modules/tenant-lifecycle/tests/integration/services/participants/provisioning.integration.spec.js#leaves a type the customer renamed after it was seeded exactly as they left it - >- services-committees:modules/tenant-lifecycle/tests/integration/services/starter-types.integration.spec.ts#does not put back a starter the customer deleted - >- services-committees:modules/tenant-lifecycle/tests/integration/services/starter-types.integration.spec.ts#does not overwrite a starter the customer edited - >- services-platform:modules/tenants/tests/integration/services/persistence/tenant-seed-applications.integration.spec.js#does not apply a seed the tenant has already received finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-008-03 sources: - >- services-crm:modules/tenant-lifecycle/tests/integration/services/participants/provisioning.integration.spec.js#adopts a role the customer made first with a seed’s id, rather than duplicating it - >- services-crm:modules/tenant-lifecycle/tests/integration/services/participants/provisioning.integration.spec.js#records an adopted role in the ledger too, so it is never written over later - >- services-crm:modules/tenant-lifecycle/tests/integration/services/participants/activities-provisioning.integration.spec.js#adopts a type the customer made first under a seed’s id, rather than overwriting it - >- services-committees:modules/tenant-lifecycle/tests/integration/services/starter-types.integration.spec.ts#adopts the position the customer made under a starter’s id instead of overwriting it finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-008-04 sources: - >- services-crm:modules/tenant-lifecycle/tests/integration/services/participants/provisioning.integration.spec.js#answers not ready, naming every seed, before it has provisioned - >- services-crm:modules/tenant-lifecycle/tests/integration/services/participants/provisioning.integration.spec.js#answers ready, with nothing missing, once it has provisioned - >- services-commerce:modules/tenant-lifecycle/tests/integration/services/participants/orders-participant.integration.spec.js#answers verifyProvisioned not ready for a fresh tenant, naming the two built-in audiences - >- services-committees:modules/tenant-lifecycle/tests/integration/services/starter-types.integration.spec.ts#is ready, with nothing missing, afterwards finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-009-01 sources: - >- services-platform:modules/tenants/tests/integration/services/provisioning/initialize-tenant.integration.spec.js#runs the participant for the tenant and says what it did - >- services-platform:modules/tenants/tests/integration/services/provisioning/initialize-tenant.integration.spec.js#reaches a participant of another macroservice through its lifecycle function - >- services-platform:modules/tenants/tests/e2e/tenant-provisioning.e2e.spec.js#says which participant ran for which tenant, and what it did - >- services-crm:modules/tenant-lifecycle/tests/integration/services/participants/provisioning.integration.spec.js#applies one type set alone when an initialization names it by key finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-009-02 sources: - >- services-platform:modules/tenants/tests/integration/services/provisioning/initialize-tenant.integration.spec.js#refuses a tenant whose deletion is pending - >- services-platform:modules/tenants/tests/integration/services/provisioning/initialize-tenant.integration.spec.js#refuses a tenant that is being deleted - >- services-platform:modules/tenants/tests/integration/services/provisioning/initialize-tenant.integration.spec.js#refuses a participant that is not in the registry, and names the ones that are - >- services-platform:modules/tenants/tests/integration/services/provisioning/initialize-tenant.integration.spec.js#does not touch the tenant it refused - >- services-platform:modules/tenants/tests/e2e/tenant-provisioning.e2e.spec.js#refuses a participant nobody has heard of as 400 - >- services-platform:modules/tenants/tests/e2e/tenant-provisioning.e2e.spec.js#may not initialize a participant of their own tenant finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-010-02 sources: - >- services-crm:modules/tenant-lifecycle/tests/integration/services/export/tenant-export.integration.spec.js#exports every row of the tenant’s exported tables exactly once, in its record or inline on its parent - >- services-crm:modules/tenant-lifecycle/tests/integration/services/export/tenant-export.integration.spec.js#withholds every declared table it does not export, each with its class and reason - >- services-submissions:modules/tenant-lifecycle/tests/unit/export/export-coverage.spec.js#finds no resource unclassified - >- services-websites:modules/tenant-lifecycle/tests/unit/participants/export-coverage.spec.js#classifies every resource, gathers every exported one in exactly one dataset, and has no dataset problem - >- services-membership:modules/tenant-lifecycle/tests/unit/export-coverage.spec.ts#classifies every resource, gathers each exported one in one dataset of its own participant and covers every object finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-010-03 sources: - >- services-crm:modules/tenant-lifecycle/tests/integration/services/export/tenant-export.integration.spec.js#stamps every record with the exported tenant - >- services-crm:modules/tenant-lifecycle/tests/integration/services/export/tenant-export.integration.spec.js#carries no value of the other tenant anywhere in the package - >- services-commerce:modules/tenant-lifecycle/tests/unit/exports/export-round-trip.spec.js#stamps every line with its tenant finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-011-02 sources: - >- services-platform:modules/tenants/tests/e2e/hq-tenant-loading.e2e.spec.js#refuses a live tenant, an initial import going only into an implementation tenant - >- services-platform:modules/tenants/tests/e2e/hq-tenant-loading.e2e.spec.js#names the status rule in that refusal, so an operator knows which half stopped it - >- services-platform:modules/tenants/tests/e2e/hq-tenant-loading.e2e.spec.js#left the live tenant exactly as it was, so the refusal did not half-happen - >- services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#refuses a live tenant by name: an initial import loads only an implementation tenant finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-011-03 sources: - >- services-platform:modules/tenants/tests/e2e/hq-tenant-loading.e2e.spec.js#is served to a staff member holding hq.data-runs.manage, answering the loading state - >- services-platform:modules/tenants/tests/e2e/hq-tenant-loading.e2e.spec.js#records who opened the load and why, which is what the row is evidence of - >- services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#puts the tenant into its loading state - >- services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#changes nothing when the tenant is already loading, so a repeated step is not an error finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-011-05 sources: - >- services-platform:modules/tenants/tests/e2e/hq-tenant-loading.e2e.spec.js#is served to a staff member holding hq.tenants.activate, returning the tenant to active - >- services-platform:modules/tenants/tests/e2e/hq-tenant-loading.e2e.spec.js#leaves the status where it was, going live being the separate decision - >- services-platform:modules/tenants/tests/e2e/hq-tenant-loading.e2e.spec.js#keeps the record of the load, which is the evidence of what was done to the tenant - >- services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#returns it to active, so its own people reach it again finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-012-02 sources: - >- services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#refuses a tenant that is not loading, naming that half of the rule - >- services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#refuses a live tenant, naming the other half - >- services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#records no reset job for any tenant it refused - >- services-platform:modules/tenants/tests/e2e/hq-tenant-loading.e2e.spec.js#refuses a tenant that is in implementation mode and not loading - >- services-crm:modules/tenant-lifecycle/tests/integration/services/participants/reset.integration.spec.js#refuses a live tenant, whatever its lifecycle state - >- services-crm:modules/tenant-lifecycle/tests/integration/services/participants/reset.integration.spec.js#refuses an implementation tenant that is no longer loading finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-012-03 sources: - >- services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#refuses a confirmation that is not the tenant’s id, and does not say what to type - >- services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#refuses a missing confirmation - >- services-platform:modules/tenants/tests/e2e/hq-tenant-loading.e2e.spec.js#refuses a confirmation that is not the tenant’s own id, without saying what to type finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-012-04 sources: - >- services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#refuses the second request as a conflict, naming the job that is running - >- services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#refuses before it asks any participant anything - >- services-platform:modules/tenants/tests/e2e/hq-tenant-loading.e2e.spec.js#refuses the second 409, naming the reset that is running finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-012-05 sources: - >- services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#refuses the reset, naming the service and the contract it has to implement - >- services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#removes nothing at all: a half-reset tenant is the outcome worth refusing for - >- services-platform:modules/tenants/tests/e2e/hq-tenant-loading.e2e.spec.js#refuses a tenant it may otherwise reset, the services holding its records not being in the live plan finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-012-06 sources: - >- services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#empties every table of every participant it empties, but the configuration a participant’s own reset keeps - >- services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#keeps every table of every participant it does not empty, row for row - >- services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#keeps the tenant row itself, which is the whole point of a reset - >- services-platform:modules/tenants/tests/unit/services/lifecycle/reset-participants.spec.js#accounts for every participant, emptied or kept - >- services-platform:modules/tenants/tests/unit/services/lifecycle/reset-participants.spec.js#keeps the security participant, so the tenant’s people and their grants survive it finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-012-07 sources: - >- services-crm:modules/tenant-lifecycle/tests/integration/services/participants/reset.integration.spec.js#leaves the tenant holding exactly what a freshly provisioned tenant holds, table for table - >- services-crm:modules/tenant-lifecycle/tests/integration/services/participants/reset.integration.spec.js#leaves the seeded records themselves equal to the freshly provisioned tenant’s - >- services-crm:modules/tenant-lifecycle/tests/integration/services/participants/reset.integration.spec.js#leaves the seed ledger equal to the freshly provisioned tenant’s, seed for seed - >- services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#let the other macroservice re-apply its seeds, which is what a reset has and a purge has not finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-012-08 sources: - >- services-platform:modules/tenants/tests/e2e/hq-tenant-loading.e2e.spec.js#is accepted for a staff member holding hq.data-runs.manage: 202, naming the tenant and the job that empties it - >- services-platform:modules/tenants/tests/e2e/hq-tenant-loading.e2e.spec.js#answers the totals by resource the reset removed, the other macroservice’s among them - >- services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#reports one progress event per participant, naming what that participant removed - >- services-platform:modules/tenants/tests/e2e/hq-tenant-loading.e2e.spec.js#leaves the tenant loading and in implementation, so the package can be loaded again at once finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-012-10 sources: - >- services-platform:modules/tenants/tests/e2e/hq-tenant-loading.e2e.spec.js#leaves the tenant loading and in implementation, so the package can be loaded again at once - >- services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#keeps every table of every participant it does not empty, row for row - >- services-crm:modules/tenant-lifecycle/tests/integration/services/participants/reset.integration.spec.js#leaves the tenant holding exactly what a freshly provisioned tenant holds, table for table finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-013-01 sources: - >- services-platform:modules/tenants/tests/e2e/tenant-deletion-requests.e2e.spec.js#may not ask for a tenant to be deleted - >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#refuses a caller who is not Rhythm staff - >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#writes no request for a caller who is not Rhythm staff finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-013-02 sources: - >- services-platform:modules/tenants/tests/e2e/tenant-deletion-requests.e2e.spec.js#refuses a confirmation that does not repeat the tenant's name as 400 - >- services-platform:modules/tenants/tests/e2e/tenant-deletion-requests.e2e.spec.js#names the confirmation in that refusal, so the person knows what to type - >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#refuses a confirmation that repeats the tenant id, which is no longer what the person types - >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#refuses a reason too short to tell anybody anything - >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#refuses a tenant that has changed since the screen was drawn - >- services-platform:modules/tenants/tests/e2e/tenant-deletion-requests.e2e.spec.js#refuses a body with no version as 400 finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-013-03 sources: - >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#refuses a tenant that is still live, because people must lose access first - >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#refuses a tenant that is still being implemented, for the same reason - >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#refuses a tenant that is being deleted - >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#refuses a tenant that is locked - >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#refuses a tenant that is somebody else parent - >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#refuses a well-known tenant the whole development environment is built on - >- services-platform:modules/tenants/tests/e2e/tenant-deletion-requests.e2e.spec.js#refuses a tenant that is still live as 409 finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-013-04 sources: - >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#refuses a second request, naming the one that is open - >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#leaves the tenant with exactly one request after the refusal - >- services-platform:modules/tenants/tests/integration/services/persistence/tenant-deletion-requests.integration.spec.js#refuses a second open request for the same tenant, by the index and not only by the service - >- services-platform:modules/tenants/tests/e2e/tenant-deletion-requests.e2e.spec.js#refuses a second request for the same tenant as 409 finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-013-06 sources: - >- services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#becomes eligible thirty days after the request - >- services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#refuses a configured period below fourteen days rather than quietly raising it - >- services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#accepts exactly fourteen days (the boundary, the negative control) - >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#records the thirty-day waiting period Andrew set - >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#fixes the date destruction may begin, thirty days on by the calendar of the tenant zone - >- services-platform:modules/tenants/tests/e2e/tenant-deletion-requests.e2e.spec.js#answers the thirty-day waiting period finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-013-07 sources: - >- services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#waits one day, because no association ever used it - >- services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#waits one day in Production too, where the fourteen-day floor does not apply to it - >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#makes a tenant that was never provisioned wait one day finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-013-08 sources: - >- services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#waits ten minutes outside Production, so an automated test can watch a whole deletion - >- services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#is refused a period longer than the configured one, so the field can only shorten - >- services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#is refused for a tenant that is not disposable, rather than ignored - >- services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#is refused in Production even for a disposable tenant - >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#refuses the disposable path in Production, where no tenant is disposable finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-013-09 sources: - >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#copies the tenant name and customer, so the record still reads after the tenant is gone - >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#records who asked and why - >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#moves the tenant to deletion_pending - >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#owes the notice destruction waits for - >- services-platform:modules/tenants/tests/integration/services/deletion/tenant-deletion-schedule.integration.spec.js#submits one schedule job with the request, before anything has waited - >- services-platform:modules/tenants/tests/e2e/tenant-deletion-requests.e2e.spec.js#moves the tenant to deletion_pending, read back through the tenants API finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-014-01 sources: - >- services-platform:modules/tenants/tests/e2e/tenant-deletion-requests.e2e.spec.js#may not hold a deletion request - >- services-platform:modules/tenants/tests/e2e/tenant-deletion-requests.e2e.spec.js#may not release a deletion request - >- services-platform:modules/tenants/tests/e2e/tenant-deletion-requests.e2e.spec.js#may not cancel a deletion request - >- services-platform:modules/tenants/tests/e2e/tenant-deletion-requests.e2e.spec.js#may not read a deletion request - >- services-platform:modules/tenants/tests/e2e/tenant-deletion-requests.e2e.spec.js#may not list deletion requests - >- services-platform:modules/tenants/tests/e2e/tenant-deletion-requests.e2e.spec.js#leaves the request exactly as it was after all of those refusals - >- services-platform:modules/tenants/tests/integration/services/deletion/deletion-holds.integration.spec.js#refuses a caller who is not Rhythm staff finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-014-02 sources: - >- services-platform:modules/tenants/tests/integration/services/deletion/deletion-holds.integration.spec.js#refuses a hold with no reason worth reading - >- services-platform:modules/tenants/tests/integration/services/deletion/deletion-holds.integration.spec.js#refuses a request that has changed since the screen was drawn - >- services-platform:modules/tenants/tests/integration/services/deletion/deletion-holds.integration.spec.js#leaves that request scheduled after the stale refusal - >- services-platform:modules/tenants/tests/e2e/tenant-deletion-requests.e2e.spec.js#refuses an action at a stale version as 409 finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-014-05 sources: - >- services-platform:modules/tenants/tests/integration/services/deletion/deletion-holds.integration.spec.js#answers a cancelled request - >- services-platform:modules/tenants/tests/integration/services/deletion/deletion-holds.integration.spec.js#returns the tenant to active - >- services-platform:modules/tenants/tests/integration/services/deletion/deletion-holds.integration.spec.js#leaves the tenant disabled: calling off a deletion restores nobody access - >- services-platform:modules/tenants/tests/integration/services/deletion/deletion-holds.integration.spec.js#cancels a held request too - >- services-platform:modules/tenants/tests/e2e/tenant-deletion-requests.e2e.spec.js#leaves the tenant disabled: calling off a deletion restores nobody access finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-014-06 sources: - >- services-platform:modules/tenants/tests/integration/services/deletion/deletion-holds.integration.spec.js#refuses to cancel a request whose destruction has begun - >- services-platform:modules/tenants/tests/integration/services/deletion/deletion-holds.integration.spec.js#leaves that executing request exactly as it was - >- services-platform:modules/tenants/tests/integration/services/deletion/begin-destruction.integration.spec.js#refuses a cancel that arrives after the point of no return - >- services-platform:modules/tenants/tests/integration/services/persistence/tenant-deletion-requests.integration.spec.js#matches nothing once the request is executing, which is the point of no return finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-015-01 sources: - >- services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#owes the notice at request, the seven-day reminder and the one-day reminder, in that order - >- services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#is owed at exactly eight days, the shortest period with room for it - >- services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#is skipped just below eight days, where it would fall before the request itself - >- services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#is due at once just below two days, so a short period still has the notice destruction waits for - >- services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#is due at once for a one-day period, the never-active tenant - >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#makes both of those notices due at once, or a tenant with a one-day period could never be deleted finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-015-02 sources: - >- services-platform:modules/tenants/tests/integration/services/deletion/deletion-holds.integration.spec.js#owes a notice, because a schedule that changes silently is a schedule nobody can trust - >- services-platform:modules/tenants/tests/integration/services/deletion/deletion-holds.integration.spec.js#owes a released notice - >- services-platform:modules/tenants/tests/integration/services/deletion/deletion-holds.integration.spec.js#owes a cancelled notice - >- services-platform:modules/tenants/tests/integration/services/deletion/begin-destruction.integration.spec.js#owes an executing notice, so somebody is told the point of no return was passed - >- services-platform:modules/tenants/tests/integration/services/deletion/tenant-purge.integration.spec.js#tells the people the plan owes a last notice to - >- services-platform:modules/tenants/tests/integration/services/deletion/tenant-purge-recovery.integration.spec.js#tells the people a deletion that failed was not completed finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-015-04 sources: - >- services-platform:modules/tenants/tests/integration/services/deletion/tenant-deletion-schedule.integration.spec.js#sends the requested notice on the day of the request - >- services-platform:modules/tenants/tests/integration/services/deletion/tenant-deletion-schedule.integration.spec.js#sends both reminders, each on its own day, as the waiting period passes - >- services-platform:modules/tenants/tests/integration/services/deletion/tenant-deletion-schedule.integration.spec.js#slept until each notice was due rather than polling, and never for a fixed duration - >- services-platform:modules/tenants/tests/integration/services/persistence/tenant-deletion-requests.integration.spec.js#ignores a notice whose schedule slot is already taken, so a re-run sends nothing twice finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-015-05 sources: - >- services-platform:modules/tenants/tests/integration/services/deletion/tenant-deletion-schedule.integration.spec.js#holds the deletion indefinitely when a notice could not be delivered, rather than destroying the tenant unannounced - >- services-platform:modules/tenants/tests/integration/services/deletion/begin-destruction.integration.spec.js#waits while a notice destruction waits for has not been sent - >- services-platform:modules/tenants/tests/integration/services/deletion/begin-destruction.integration.spec.js#names the notices it is waiting for - >- services-platform:modules/tenants/tests/integration/services/persistence/tenant-deletion-requests.integration.spec.js#counts a suppressed notice as sent, which is the development and test path - >- services-platform:modules/tenants/tests/integration/services/persistence/tenant-deletion-requests.integration.spec.js#still lists a failed notice, so a send that never worked never lets a tenant be deleted - >- services-platform:modules/tenants/tests/integration/services/persistence/tenant-deletion-requests.integration.spec.js#ignores a seven-day reminder that was never sent: only two kinds gate destruction finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-016-04 sources: - >- services-platform:modules/tenants/tests/integration/services/deletion/begin-destruction.integration.spec.js#ends when the request was cancelled while the job slept - >- services-platform:modules/tenants/tests/integration/services/deletion/begin-destruction.integration.spec.js#ends when another execution now owns the request, which is what a resume looks like - >- services-platform:modules/tenants/tests/integration/services/deletion/begin-destruction.integration.spec.js#touches nothing when it ends: the tenant is still awaiting deletion - >- services-platform:modules/tenants/tests/integration/services/deletion/begin-destruction.integration.spec.js#ends when the tenant is already gone - >- services-platform:modules/tenants/tests/integration/services/deletion/tenant-deletion-schedule.integration.spec.js#ends quietly, without destroying anything, when the request was cancelled while it slept - >- services-platform:modules/tenants/tests/integration/services/deletion/tenant-deletion-schedule.integration.spec.js#keeps waiting, and destroys nothing, while the request is held finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-017-02 sources: - >- services-platform:modules/tenants/tests/integration/services/deletion/tenant-purge.integration.spec.js#runs one step per participant, in the planned order, and completes every one of them - >- services-platform:modules/tenants/tests/integration/services/deletion/tenant-purge.integration.spec.js#asks a participant for another batch until it answers done, rather than looping inside one invocation - >- services-platform:modules/tenants/tests/integration/services/deletion/tenant-purge.integration.spec.js#purges accounting.transactions before accounting.configuration, which it depends on - >- services-platform:modules/tenants/tests/integration/services/deletion/tenant-purge.integration.spec.js#removes the tenant row itself - >- services-crm:modules/tenant-lifecycle/tests/integration/services/participants/purge.integration.spec.js#removes at most one row in a batch, because that is the batch it was given finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-017-03 sources: - >- services-crm:modules/tenant-lifecycle/tests/integration/services/participants/purge.integration.spec.js#refuses a tenant that is not being deleted - >- services-crm:modules/tenant-lifecycle/tests/integration/services/participants/purge.integration.spec.js#removes nothing from a tenant it refused - >- services-commerce:modules/tenant-lifecycle/tests/integration/services/participants/orders-participant.integration.spec.js#refuses a tenant that is not being deleted - >- services-commerce:modules/tenant-lifecycle/tests/integration/services/participants/orders-participant.integration.spec.js#refuses a tenant whose deletion was cancelled part way through - >- services-membership:modules/tenant-lifecycle/tests/integration/services/lifecycle/tenant-lifecycle.integration.spec.ts#refuses to purge a tenant Platform holds active, and removes nothing - >- services-platform:modules/tenants/tests/integration/services/deletion/tenant-purge-recovery.integration.spec.js#refuses a purge of a tenant that is neither being deleted nor being loaded - >- services-platform:modules/tenants/tests/integration/services/deletion/tenant-purge-recovery.integration.spec.js#refuses a purge of a tenant other than the one the session is in - >- services-platform:modules/tenants/tests/integration/services/deletion/tenant-purge-recovery.integration.spec.js#refuses a purge that names no tenant finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-017-04 sources: - >- services-crm:modules/tenant-lifecycle/tests/integration/services/participants/purge.integration.spec.js#empties the record history after the contacts, through the definer function - >- services-crm:modules/tenant-lifecycle/tests/integration/services/participants/purge.integration.spec.js#empties the merge tables, two of them through the definer function only they can be emptied by - >- services-platform:modules/tenants/tests/integration/services/deletion/tenant-purge-functions.integration.spec.js#leaves the tenant no communication row at all - >- services-platform:modules/tenants/tests/integration/services/deletion/tenant-purge-functions.integration.spec.js#leaves the tenant no security row at all - >- services-membership:modules/tenant-lifecycle/tests/integration/services/lifecycle/tenant-lifecycle.integration.spec.ts#allows membership.purge_tenant_versions once Platform is deleting the tenant finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-017-08 sources: - >- services-platform:modules/tenants/tests/integration/services/deletion/tenant-purge.integration.spec.js#checks that nothing is left before it finalizes, and asks every participant to count - >- services-platform:modules/tenants/tests/integration/services/deletion/tenant-purge-recovery.integration.spec.js#runs every participant again when a row appears after one of them finished, and finishes when it is gone - >- services-platform:modules/tenants/tests/integration/services/deletion/tenant-purge-recovery.integration.spec.js#refuses to finish, with the counts, when something keeps writing to the tenant - >- services-platform:modules/tenants/tests/integration/services/deletion/tenant-purge.integration.spec.js#leaves no row of the tenant in any table a participant declares finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-017-09 sources: - >- services-platform:modules/tenants/tests/integration/services/deletion/tenant-purge.integration.spec.js#leaves the other tenant of the same customer exactly as it was - >- services-crm:modules/tenant-lifecycle/tests/integration/services/participants/purge.integration.spec.js#leaves the other tenant’s rows exactly as they were, table for table - >- services-committees:modules/tenant-lifecycle/tests/integration/services/tenant-purge.integration.spec.ts#leaves the other tenant’s rows alone - >- services-marketing:modules/tenant-lifecycle/tests/integration/services/tenant-purge.integration.spec.ts#leaves another workspace’s rows exactly as they were finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-017-10 sources: - >- services-platform:modules/tenants/tests/integration/services/deletion/tenant-purge-recovery.integration.spec.js#deletes the customer with its last tenant when the request asked for it - >- services-platform:modules/tenants/tests/integration/services/deletion/tenant-purge.integration.spec.js#keeps the customer, because the deleted tenant was not its last - >- services-platform:modules/tenants/tests/integration/services/deletion/tenant-purge-recovery.integration.spec.js#never touches the catalog rows the product owns, whatever a customer purge removes - >- services-platform:modules/tenants/tests/integration/services/deletion/tenant-purge.integration.spec.js#keeps the deletion’s own job rows, which are the record of what was done finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-017-11 sources: - >- services-platform:modules/tenants/tests/integration/services/deletion/tenant-purge-recovery.integration.spec.js#completes the destruction when a purge that failed part way is retried - >- services-platform:modules/tenants/tests/integration/services/deletion/tenant-purge-recovery.integration.spec.js#does not run the steps a failed purge had already completed when it is retried - >- services-platform:modules/tenants/tests/integration/services/deletion/tenant-purge-recovery.integration.spec.js#leaves a retried request untouched when the purge it replaced records its failure afterwards - >- services-platform:modules/tenants/tests/e2e/tenant-deletion-recovery.e2e.spec.js#refuses as 409 a retry of a purge that did not fail - 'services-platform:modules/tenants/tests/e2e/tenant-deletion-recovery.e2e.spec.js#may not retry a purge' - >- services-platform:modules/tenants/tests/integration/lifecycle/reconciled-job-failure.integration.spec.js#fails the deletion request, which is what opens its retry route finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-017-12 sources: - >- services-platform:modules/tenants/tests/integration/services/deletion/tenant-purge.integration.spec.js#leaves no row of the tenant in any table a participant declares - >- services-crm:modules/tenant-lifecycle/tests/integration/services/participants/purge.integration.spec.js#empties every declared table of the tenant finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-018-02 sources: - >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#copies the tenant name and customer, so the record still reads after the tenant is gone - >- services-platform:modules/tenants/tests/integration/services/deletion/tenant-purge.integration.spec.js#keeps the deletion’s own job rows, which are the record of what was done finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-018-03 sources: - >- services-platform:modules/tenants/tests/integration/services/deletion/tenant-purge.integration.spec.js#writes the permanent deletion record outside the database, keyed by the tenant - >- services-platform:modules/tenants/tests/unit/services/deletion/deletion-ledger.spec.js#answers no entry for a tenant the ledger does not hold finding: FND-PFM-TNL-084 - scenario: ATS-PFM-TNL-018-06 sources: - >- services-platform:modules/tenants/tests/integration/services/deletion/tenant-purge.integration.spec.js#records on the request what was removed, and the counts it verified - >- services-platform:modules/tenants/tests/integration/services/deletion/tenant-purge-recovery.integration.spec.js#refuses to create a tenant again under the id of one that was deleted finding: FND-PFM-TNL-084 --- # Findings and Open Questions: Platform → Workspace Lifecycle The findings retain source disagreements and gaps in the available proof. Open questions identify choices that need Product’s decision before design. ## Findings | id | severity | statement | affects | evidence | kind | |---|---|---|---|---|---| | `FND-PFM-TNL-001` | medium | The registered milestone scope has no workspace-lifecycle milestone. Product authority instead comes from the approved lifecycle and HQ plans, baseline standard, reset contract and data-job plan; the module registry is corrected to those records. | `MOD-PFM-TNL` | services-platform:docs/milestones (no tenant lifecycle record); docs/tenants/tenant-lifecycle-plan.md (Status: approved 2026-10-09) | inconsistency | | `FND-PFM-TNL-002` | low | The approved plan keeps several standing-order defaults in force without individual review, including the shorter unopened-workspace wait, security-audit removal, backup expiry, internal-only notices and deliberate rather than automatic deletion. Andrew’s individual review remains open. | `BR-CAP-PFM-TNL-013-08`, `BR-CAP-PFM-TNL-013-12`, `BR-CAP-PFM-TNL-015-03`, `BR-CAP-PFM-TNL-017-07`, `BR-CAP-PFM-TNL-018-05` | services-platform:docs/tenants/tenant-lifecycle-plan.md#Acceptance checkpoints, Decisions (2026-10-10 row) | undocumented | | `FND-PFM-TNL-003` | low | Immediate deletion returns Method Not Allowed while the plan and console contract specify Gone. The retained debt record explains that response mismatch. | `BR-CAP-PFM-TNL-018-08` | services-platform:modules/tenants/aws/api/tenant-api-mapper.ts:tenantDeleteGoneRefusal; services-platform:docs/tenants/console-contract.md#Behaviour the console must respect; services-platform:docs/debt/tenant-delete-gone-status.md | inconsistency | | `FND-PFM-TNL-004` | medium | The access gate does not consult the external deletion ledger. A restored active workspace can therefore admit customer requests until staff reapply its recorded deletion; the approved restore safeguard has no passing implementation scenario. | `BR-CAP-PFM-TNL-018-07`, `CAP-PFM-TNL-005` | services-platform:docs/tenants/tenant-lifecycle-plan.md#§9 Restoring without resurrecting; services-platform:modules/tenants/services/access/tenant-availability.ts (no ledger read); plan Acceptance checkpoints, Remaining work | defect | | `FND-PFM-TNL-005` | low | Loading has an allowed transition to pending deletion, but deletion requests accept only active or provisioning-failed lifecycle and require disabled status. Loading requires implementation status, leaving that direct exit unavailable through the request service. | `BR-CAP-PFM-TNL-006-02`, `BR-CAP-PFM-TNL-013-04` | services-platform:modules/tenants/services/lifecycle/lifecycle-transitions.ts:SUCCESSORS; services/deletion/request-deletion.ts:REQUESTABLE_TENANT_LIFECYCLE_STATES; db/tenants.table.ts:tenants_loading_status_check | inconsistency | | `FND-PFM-TNL-006` | medium | Operational eligibility differs by purpose: Platform background enumeration requires active and non-disabled, CRM baseline selection includes active, loading and failed regardless of status, and staff initialization excludes loading. These definitions need an explicit product explanation. | `BR-CAP-PFM-TNL-005-07`, `BR-CAP-PFM-TNL-009-02`, `BR-CAP-PFM-TNL-009-03` | services-platform:modules/tenants/services/persistence/tenants.ts:listOperationalTenantIds; services-crm:db/platform/tenants.ts:OPERATIONAL_TENANT_STATES; services-platform:modules/tenants/services/provisioning/initialize-tenant.ts:INITIALIZABLE_STATES; services-platform:docs/standards/baseline-configuration.md#§3 | inconsistency | | `FND-PFM-TNL-007` | medium | The baseline standard requires deployment reconciliation across applications, but Platform’s local defaults still reach existing workspaces through staff initialization rather than a deployment pass. | `BR-CAP-PFM-TNL-009-06` | services-platform:docs/standards/baseline-configuration.md#§5 Where each macroservice stands | debt | | `FND-PFM-TNL-008` | medium | Platform’s remote descriptions have outdated seed or resource metadata for CRM, Committees, Membership and Marketing. The plan comparison checks participant order rather than the complete declarations, so matching order does not resolve that drift. | `BR-CAP-PFM-TNL-007-05`, `BR-CAP-PFM-TNL-002-02` | services-platform:modules/tenants/services/lifecycle/remote-participant-manifests.ts; services-crm:modules/tenant-lifecycle/services/participants/entities-participant.ts; services-committees:modules/tenant-lifecycle/participants.ts; services-membership:modules/tenant-lifecycle/services/lifecycle/participants.ts; services-marketing:modules/tenant-lifecycle/participants.ts | inconsistency | | `FND-PFM-TNL-009` | high | Websites registers content and changes participants while Platform retains only disabled content. Its change records and templates are absent from the orchestration plan and its inventory, limiting the deletion-completion claim. | `CAP-PFM-TNL-007`, `CAP-PFM-TNL-017` | services-platform:modules/tenants/services/lifecycle/remote-participant-manifests.ts (websites.content, enabled false); services-websites:modules/tenant-lifecycle/services/participants/registry.ts, changes-participant.ts | defect | | `FND-PFM-TNL-010` | medium | Committees reset removes its records without restoring starter configuration, whereas the reset contract describes restoring defaults. The contract also names fewer emptied applications than the current Platform reset classification. | `BR-CAP-PFM-TNL-012-07` | services-platform:docs/data-jobs/tenant-reset.md#§2, §3.4; services-committees:modules/tenant-lifecycle/participants.ts (header: a reset re-seeds nothing); services-platform:modules/tenants/services/lifecycle/reset-participants.ts | inconsistency | | `FND-PFM-TNL-011` | low | The lifecycle plan’s original two-role CRM baseline predates the later entities, tasks, activities and duplicate seed sets. The participant baseline now follows the later configuration standard. | `BR-CAP-PFM-TNL-008-07` | services-platform:docs/tenants/tenant-lifecycle-plan.md#§4.3, §10 Acceptance criteria 1; services-crm:modules/tenant-lifecycle/services/participants/entities-participant.ts | inconsistency | | `FND-PFM-TNL-012` | low | A partial unique index and refusal translation enforce one open provisioning job per workspace, but no cited test demonstrates that conflict path. | `BR-CAP-PFM-TNL-001-08` | services-platform:modules/tenants/db/tenant-provisioning-jobs.table.ts:tenant_provisioning_jobs_open_uidx; services/provisioning/submit-tenant-provisioning.ts:provisioningSubmissionRefusal | debt | | `FND-PFM-TNL-013` | low | Activation establishes application, staff-access and development-fixture records beyond the lifecycle plan’s description. The staff-access choice has HQ authority, while the differing activation failure handling needs explicit documentation. | `BR-CAP-PFM-TNL-002-08` | services-platform:modules/tenants/services/provisioning/provision-tenant-operations.ts:activateOperation; services-platform:docs/hq/rhythm-hq-plan.md#§K decision record K1a | undocumented | | `FND-PFM-TNL-014` | medium | An absent staff notice list blocks notice processing and therefore destruction, but the current bindings do not exercise that missing-configuration refusal end to end. | `BR-CAP-PFM-TNL-015-07` | services-platform:modules/tenants/services/deletion/notices/notice-recipients.ts (header) | debt | | `FND-PFM-TNL-015` | medium | Restore reapplication, long-disabled review and the orphan report lack cited automated tests. Restore recovery is particularly weak because the access gate still omits the ledger safeguard. | `BR-CAP-PFM-TNL-018-06`, `BR-CAP-PFM-TNL-018-09`, `BR-CAP-PFM-TNL-013-12` | services-platform:modules/tenants/services/deletion/reapply-deletions.ts; scripts/long-disabled.ts; services/deletion/orphan-report.ts; tests (none found) | debt | | `FND-PFM-TNL-016` | medium | The orphan report inspects request and job candidates using Platform participant inventories. It does not enumerate all application tables or file stores described by the plan’s wider orphan-report requirement. | `BR-CAP-PFM-TNL-018-09` | services-platform:docs/tenants/tenant-lifecycle-plan.md#§8.3; services-platform:modules/tenants/services/deletion/orphan-report.ts (header, What it cannot see) | debt | | `FND-PFM-TNL-017` | low | The plan describes parallel work for independent participants, while the implemented provisioning workflow runs sequentially. | `BR-CAP-PFM-TNL-002-07` | services-platform:docs/tenants/tenant-lifecycle-plan.md#§4.2, §6.2; services-platform:modules/tenants/services/provisioning/provision-tenant-workflow.ts (Sequential, not parallel) | inconsistency | | `FND-PFM-TNL-018` | low | The lifecycle plan’s old creation and deletion permission vocabulary differs from the current HQ provisioning and reading keys. The route declarations provide the current authority boundary. | `BR-CAP-PFM-TNL-001-01`, `BR-CAP-PFM-TNL-003-01`, `BR-CAP-PFM-TNL-009-01` | services-platform:docs/tenants/tenant-lifecycle-plan.md#§8.2; services-platform:aws/platform.service.ts (HQ_TENANTS_PERMISSIONS, retired keys comment) | inconsistency | | `FND-PFM-TNL-019` | medium | Reset does not inspect revision-source history to establish that only import-engine sessions wrote during loading. The approved safeguard remains absent and a reset can remove other selected writes. | `BR-CAP-PFM-TNL-012-10` | services-platform:docs/proposals/rhythm-data-job-engine-plan.md#§13.3; services-platform:modules/tenants/services/reset/reset-tenant.ts (no revision-source check) | defect | | `FND-PFM-TNL-020` | medium | The registry supplies no console source scope for this module. HQ records describe provisioning surfaces and defer deletion screens, but implementation of those screens is not verified from console code here; ownership remains an open module question. | `MOD-PFM-TNL`, `OQ-PFM-TNL-001`, `JNY-PFM-TNL-004` | services-platform:docs/tenants/console-contract.md#Screens; services-platform:docs/hq/rhythm-hq-plan.md#§D12, §D14, §G phase 4; specs/PRODUCT-AREAS.md (MOD-PFM-SEC, MOD-PFM-OPS rows) | undocumented | | `FND-PFM-TNL-021` | low | The route review establishes permission-key checks rather than the complete built-in-role distribution. Assigning hold, release, request and cancellation to named staff roles remains dependent on the security module’s records. | `BR-CAP-PFM-TNL-013-01`, `BR-CAP-PFM-TNL-014-01` | services-platform:docs/tenants/tenant-lifecycle-plan.md#§5.2; services-platform:modules/tenants/aws/api/tenant-deletion-requests.routes.ts | undocumented | | `FND-PFM-TNL-022` | low | Existing test bindings establish source-level evidence rather than a service-suite execution result. This examination runs corpus checks and tests, not the eight application suites. | `MOD-PFM-TNL` | rhythm-v2-docs: planning/acceptance (bound_to) | debt | | `FND-PFM-TNL-023` | low | The reset confirmation repeats the workspace identifier while deletion confirmation repeats its name. The records explain each choice separately, but the shared selection safeguard is inconsistent. | `BR-CAP-PFM-TNL-013-03`, `BR-CAP-PFM-TNL-012-03` | services-platform:modules/tenants/services/deletion/request-deletion.ts:assertConfirmation; services/reset/reset-tenant.ts (header) | inconsistency | | `FND-PFM-TNL-024` | medium | The draft restricts staff to import routes during loading, but Platform admits authorized staff system routes before applying the loading check. The access rules and loading assertion are corrected to preserve that exception. | `CAP-PFM-TNL-005`, `CAP-PFM-TNL-011`, `JNY-PFM-TNL-003` | services-platform:modules/tenants/services/access/tenant-availability.ts:tenantAvailabilityOf | inconsistency | | `FND-PFM-TNL-025` | medium | Input validation differs between applications. CRM validates run identities and batch bounds; Committees and Marketing default a missing run to an empty value and pass batch sizes through. Membership has a separate contract. A CRM test cannot establish a uniform refusal across all services. | `CAP-PFM-TNL-007` | services-crm:modules/tenant-lifecycle/services/lifecycle/tenant-lifecycle-operations.ts; services-committees:modules/tenant-lifecycle/services/lifecycle/tenant-lifecycle-operations.ts; services-marketing:modules/tenant-lifecycle/services/lifecycle/tenant-lifecycle-operations.ts | inconsistency | | `FND-PFM-TNL-026` | high | Websites declares CMS documents and media as resources without a purge, but its content participant returns an empty inventory and successful table purge. Enabling the participant alone would still leave CMS content outside deletion verification. | `CAP-PFM-TNL-017` | services-websites:modules/tenant-lifecycle/services/participants/content-participant.ts:WEBSITES_CONTENT_CMS_RESOURCES | defect | | `FND-PFM-TNL-027` | medium | Platform forwards remote initialization as provisioning and drops the selected seed sets. Local initialization can filter sets; a remote request applies the participant’s provisioning defaults. No binding proves remote selection. | `BR-CAP-PFM-TNL-009-08` | services-platform:modules/tenants/services/provisioning/initialize-tenant.ts:runInitialize | inconsistency | | `FND-PFM-TNL-028` | medium | Participant removal commits before Platform records the returned removal counts. A lost response or failed count write can leave removed records absent from the totals; the draft’s implied atomic accounting is unsupported. Zero inventory is separate evidence. | `BR-CAP-PFM-TNL-017-13` | services-platform:modules/tenants/services/deletion/tenant-purge-operations.ts:purgeParticipantOperation | defect | | `FND-PFM-TNL-029` | medium | Deletion notices are sent before their delivery state is persisted. A process failure after sending can repeat delivery on retry. Unique notice slots prevent duplicate records rather than exactly-once messages; no crash-window acceptance binding exists. | `BR-CAP-PFM-TNL-015-04` | services-platform:modules/tenants/services/deletion/notices/send-notices.ts:sendOneNotice | debt | | `FND-PFM-TNL-030` | medium | Several acceptance bindings prove a fixture outcome rather than the full cross-service claim. Scope is narrowed for CRM validation, baseline parity and change-event suppression; backend bindings do not prove the HQ screens or a deployed deletion across every application. | `MOD-PFM-TNL`, `BR-CAP-PFM-TNL-001-10` , `BR-CAP-PFM-TNL-007-08`, `BR-CAP-PFM-TNL-008-04`, `BR-CAP-PFM-TNL-009-07`, `BR-CAP-PFM-TNL-011-06`, `BR-CAP-PFM-TNL-013-11`, `BR-CAP-PFM-TNL-014-07` | specs/platform/tenant-lifecycle/planning/acceptance; services-platform:modules/tenants/tests/integration/services/deletion/tenant-purge.integration.spec.js | debt | | `FND-PFM-TNL-031` | low | The original actor ledger stops at six even though this module adds four actors after the existing thirty-four. The ledger now records the actual allocation through thirty-eight. | `MOD-PFM-TNL` | specs/platform/ACTORS.md:ACT-PFM-039 through ACT-PFM-042 | inconsistency | | `FND-PFM-TNL-032` | medium | Committees clears committee parents, meeting self-references and references to decisions before batched deletion. Those writes affect surviving records during a partial purge and need explicit proof of workspace isolation and retry behavior. | `BR-CAP-PFM-TNL-017-14` | services-committees:modules/tenant-lifecycle/services/persistence/tenant-purges.ts:unlinkDecisionReferences | debt | | `FND-PFM-TNL-033` | medium | Sixty-four of the one hundred twenty-nine in-scope test files have no acceptance binding. The examination report names each file; their existence does not establish acceptance coverage or execution results. | `MOD-PFM-TNL` | Pinned module test-file inventory; reports/EXAMINATION-2026-10-22.md | debt | | `FND-PFM-TNL-034` | medium | Availability gating applies to workspace-scoped routes. HQ workspace routes name a general record identifier and call persistence directly; ordinary field updates have no deleting-state refusal there. The draft’s universal prohibition on staff writes is narrowed to gated routes, leaving the broader policy unresolved. | `BR-CAP-PFM-TNL-005-03`, `JNY-PFM-TNL-004` | services-platform:modules/tenants/aws/api/tenants.routes.ts:patchHqTenant; services-platform:modules/tenants/services/persistence/tenants.ts:updateTenant; services-platform:modules/tenants/services/access/tenant-availability.ts:tenantAvailabilityOf | inconsistency | | `FND-PFM-TNL-035` | low | Ordinary workspace updates invalidate the time-zone cache but not the availability cache. A business-status change can retain the changing process’s previous availability until its thirty-second entry expires; immediate invalidation is established for lifecycle workflows only. | `BR-CAP-PFM-TNL-005-06` | services-platform:modules/tenants/services/persistence/tenants.ts:updateTenant; services-platform:modules/tenants/services/access/tenant-availability.ts:forgetTenantAvailability | defect | | `FND-PFM-TNL-036` | medium | Design: the Security module's landed design already specifies the workspace lifecycle state model, the provisioning, load and reset, retirement-watch and purge workflows, and all seventeen lifecycle operations in its workspace contract, and the product area's responsibilities list those operations under Security. Two homes now describe one set of rules; Security's next revision should supersede its lifecycle artifacts and its responsibilities row should drop the lifecycle operations in favour of this module's. | `SVC-PFM-TNL-tenants`, `STATE-PFM-TNL-001`, `RESP-PFM`, `ADR-PFM-TNL-001` | rhythm-v2-docs:specs/platform/security/design/contracts/SVC-PFM-SEC-tenants.md; state-models/STATE-PFM-SEC-001, STATE-PFM-SEC-003; workflows/WF-PFM-SEC-001 to WF-PFM-SEC-004; specs/platform/RESPONSIBILITIES.md (MOD-PFM-SEC exposes) | inconsistency | | `FND-PFM-TNL-037` | low | Design: retrying a failed build moves the workspace back to provisioning and then creates the retry attempt in a separate commit. A failure between the two leaves the workspace building with no open attempt until the stranded-workspace repair returns it to failed on the next reconciler pass; the approved behaviour expects the move inside the retry submission. | `WF-PFM-TNL-004`, `BR-CAP-PFM-TNL-003-03` | services-platform:modules/tenants/services/provisioning/submit-tenant-provisioning.ts:retryTenantProvisioning | defect | | `FND-PFM-TNL-038` | medium | Design: the three deletion screens describe deferred console requirements; no registered console source establishes their implementation; their routes are assumed and actual console implementation is unverified. The initial-load controls (open, reset, reset status, activate) have no screen specification here; their APIs exist, but console use is unverified. Whether the workspace unavailable page exists in the console was not established, because no console source is registered for this module. | `SCR-PFM-TNL-001`, `SCR-PFM-TNL-002`, `SCR-PFM-TNL-003`, `SCR-PFM-TNL-004`, `OQ-PFM-TNL-005`, `JNY-PFM-TNL-003` | services-platform:docs/tenants/console-contract.md#Screens; docs/hq/rhythm-hq-plan.md#§D14; rhythm-v2-docs:specs/platform/security/design/screens/SCR-PFM-SEC-027 | undocumented | | `FND-PFM-TNL-039` | low | Design: the resume-schedule and retry-purge routes take no body, so they record no reason and check no reviewed version, unlike hold, release and cancel; the console contract expects every detail action to send the version. | `WF-PFM-TNL-014`, `SCR-PFM-TNL-003`, `ADR-PFM-TNL-016` | services-platform:modules/tenants/aws/api/tenant-deletion-requests.routes.ts:resumeTenantDeletionSchedule, retryTenantPurge; docs/tenants/console-contract.md#Screens | inconsistency | | `FND-PFM-TNL-040` | medium | Design: the availability rule is copied into each application's request gate (Platform, CRM, Commerce, Submissions and Websites in the registered scope) rather than shared as one function, so the copies can drift; the gates of Committees, Membership and Marketing are outside this module's registered scope and unverified, and no copy reads the deletion ledger. | `ADR-PFM-TNL-003`, `DOM-PFM-TNL-001`, `CAP-PFM-TNL-005` | services-platform:modules/tenants/services/access/tenant-availability.ts; services-crm, services-commerce, services-submissions, services-websites:modules/tenant-lifecycle/services/lifecycle/tenant-availability.ts | debt | | `FND-PFM-TNL-041` | low | Design: a failed reset settles with no notice to anyone and no alert; staff learn of it only by reading the reset status, while builds and deletions notify the requester or the staff list. | `WF-PFM-TNL-008`, `CAP-PFM-TNL-012` | services-platform:modules/tenants/services/reset/tenant-reset-workflow.ts:ensureTenantResetJobTypeRegistered (no requester notice, no failure consequence) | debt | | `FND-PFM-TNL-042` | low | Design: no path of this module asks a model anything, so it has no Inference Operation and no inference directory; the conventions ask the module charter to say so in one sentence, which the planning charter does not yet do. | `MOD-PFM-TNL` | rhythm-v2-docs:specs/CONVENTIONS.md#9.8; services-platform:modules/tenants (no LLM task call); services-*:modules/tenant-lifecycle (none) | undocumented | | `FND-PFM-TNL-043` | medium | Design: finalization completes the request and then writes the ledger entry in the same retried task. If the ledger write keeps failing, the purge job fails, but the failure consequence leaves a completed request alone and the retry route accepts only failed requests, so the entry can never be written by the product and nothing alerts on its absence; a later restore would then bring the workspace back undetected. | `WF-PFM-TNL-013`, `WF-PFM-TNL-015`, `BR-CAP-PFM-TNL-018-03` | services-platform:modules/tenants/services/deletion/tenant-purge-operations.ts (finalize); tenant-purge-failure.ts:applyTenantPurgeFailure; operator-recovery.ts:retryTenantPurge | defect | | `FND-PFM-TNL-044` | medium | Design: Commerce applies its built-in pricing audiences and store placements by adoption and keeps no seed ledger, so a retried build, or a staff initialization that Platform forwards to Commerce as provisioning, recreates a default the customer removed, contrary to the rule that ledgered defaults are never reapplied. | `SVC-PFM-TNL-commerce-tenant-lifecycle`, `WF-PFM-TNL-005`, `BR-CAP-PFM-TNL-008-01`, `BR-CAP-PFM-TNL-008-02` | services-commerce:modules/tenant-lifecycle/services/participants/orders-participant.ts (seedBuiltInPricingAudiences, seedStorePlacements; no tenant_seed_applications in the repository) | defect | | `FND-PFM-TNL-045` | medium | Design: activation of a loaded workspace does not check for an open or failed reset. Activating while a reset runs stops the reset at its next batch, and activating after a failed reset opens the workspace partly emptied to its people; entering loading again on an activated implementation workspace also restamps the load record. | `STATE-PFM-TNL-003`, `WF-PFM-TNL-007`, `BR-CAP-PFM-TNL-011-05`, `BR-CAP-PFM-TNL-011-03` | services-platform:modules/tenants/services/persistence/tenants.ts:activateLoadedTenant, enterTenantLoading; services/reset/tenant-reset-operations.ts | defect | | `FND-PFM-TNL-057` | medium | Availability gates do not consult retained deletion evidence, so restoring an earlier database state can reopen a workspace until manual reapplication. | `TC-DAT-004`, `TC-PI-004`, `CAP-PFM-TNL-005` | Structured control evidence | control-gap | | `FND-PFM-TNL-058` | low | Failed initial-load reset produces no requester notice or failure alert; staff discover it only through status inspection. | `TC-MON-002`, `WF-PFM-TNL-008`, `CAP-PFM-TNL-012` | Structured control evidence | control-gap | | `FND-PFM-TNL-059` | medium | Purge can complete the request before writing its external evidence; a later failed write has no request-specific retry or missing-ledger alert. | `TC-LOG-001`, `TC-DAT-004`, `TC-PI-004`, `TC-AVL-004`, `WF-PFM-TNL-013`, `WF-PFM-TNL-015`, `BR-CAP-PFM-TNL-018-03` | Structured control evidence | control-gap | | `FND-PFM-TNL-060` | medium | Commerce adopts starter defaults without a seed ledger, so a repeated initialization can recreate defaults the customer removed. | `TC-PI-002`, `SVC-PFM-TNL-commerce-tenant-lifecycle`, `WF-PFM-TNL-005`, `BR-CAP-PFM-TNL-008-01`, `BR-CAP-PFM-TNL-008-02` | Structured control evidence | control-gap | | `FND-PFM-TNL-061` | medium | Workspace activation does not reject an open or failed reset, allowing partly emptied customer work to become available. | `TC-PI-005`, `WF-PFM-TNL-007`, `BR-CAP-PFM-TNL-011-05`, `BR-CAP-PFM-TNL-011-03` | Structured control evidence | control-gap | | `FND-PFM-TNL-062` | medium | Workspace resource-state writers accept any declared state without an enforced successor table. | `TC-PI-005`, `FND-PFM-TNL-046` | Structured control evidence | control-gap | | `FND-PFM-TNL-063` | high | Purge can remove the workspace before request completion without one transaction, leaving operator recovery unable to reach an unfinished removal. | `TC-AVL-004`, `TC-PI-004`, `TC-DAT-004`, `WF-PFM-TNL-013` | Structured control evidence | control-gap | | `FND-PFM-TNL-064` | medium | Recovery creates a job before repointing its request in a separate commit, leaving an unreferenced job if the later write fails. | `TC-AVL-004`, `TC-PI-004`, `WF-PFM-TNL-014` | Structured control evidence | control-gap | | `FND-PFM-TNL-065` | high | Cancellation records a notice that the watcher cannot send because its reader excludes cancelled requests. | `TC-MON-002`, `TC-PI-004`, `WF-PFM-TNL-010` | Structured control evidence | control-gap | | `FND-PFM-TNL-046` | medium | Resource state writes validate the stored vocabulary but enforce no successor table. Recording an existing resource can replace a deleted or deleting state, and the generic setter accepts every declared state. The state model now distinguishes participant sequencing from enforced refusals. | `STATE-PFM-TNL-006`, `DOM-PFM-TNL-003` | services-platform:modules/tenants/services/persistence/tenant-resources.ts:recordTenantResource, setTenantResourceState; modules/tenants/db/tenant-resources.table.ts | inconsistency | | `FND-PFM-TNL-047` | medium | The deletion-request list returns request records without notice delivery or a computed blocking reason. Detail adds notices but no job snapshots. The proposed screens need additional reads or an API change to display those results. | `SCR-PFM-TNL-002`, `SCR-PFM-TNL-003` | services-platform:modules/tenants/aws/api/tenant-deletion-request-api-mapper.ts:toApiTenantDeletionRequestPage, toApiTenantDeletionRequestDetail | inconsistency | | `FND-PFM-TNL-048` | medium | The supplied design brief is absent, and the planning charter and concept artifacts retain draft status. This examination cannot establish planning approval or verify the missing brief's instructions. Planning remains unchanged. | `MOD-PFM-TNL` | rhythm-v2-docs:briefs/design/platform-tenant-lifecycle.brief.md (absent); specs/platform/tenant-lifecycle/MODULE.md; specs/PRODUCT-AREAS.md | undocumented | | `FND-PFM-TNL-049` | low | The wake-time source names a real function. Its surrounding commentary also describes indefinite notice retries, although the declared execution timeout is one year; the retry claim must retain that limit. | `WF-PFM-TNL-011` | services-platform:modules/tenants/services/deletion/tenant-deletion-schedule-operations.ts:nextScheduleWakeInstant | inconsistency | | `FND-PFM-TNL-050` | medium | Generic application-contract text promises seed-ledger application and reset consistency even for services with no defaults or reset operation. Operation intent and consistency are narrowed to each declared interface; Commerce uses adoption, and Submissions, Websites and Marketing provision no defaults. | `SVC-PFM-TNL-commerce-tenant-lifecycle`, `SVC-PFM-TNL-submissions-tenant-lifecycle`, `SVC-PFM-TNL-websites-tenant-lifecycle`, `SVC-PFM-TNL-marketing-tenant-lifecycle` | services-commerce, services-submissions, services-websites, services-marketing:modules/tenant-lifecycle/services/lifecycle/tenant-lifecycle-operations.ts; participant declarations | inconsistency | | `FND-PFM-TNL-051` | high | Purge finalization removes the workspace before recording counts, optional customer removal and request completion, without a surrounding transaction. Failure in that interval leaves an executing or failed request with no workspace; authority and operator retry refuse recovery unless completion was already recorded. | `WF-PFM-TNL-013`, `DOM-PFM-TNL-005` | services-platform:modules/tenants/services/deletion/tenant-purge-operations.ts:finalizeOperation, requirePurgeAuthority; modules/tenants/services/deletion/operator-recovery.ts:retryTenantPurge | defect | | `FND-PFM-TNL-052` | medium | Recovery creates a replacement job before repointing the request, in separate commits. The open-job index limits concurrent creation, but a job created before a failed repoint can remain unreferenced; schedule resume also checks for open jobs before creation without a request lock spanning the sequence. | `WF-PFM-TNL-014` | services-platform:modules/tenants/services/deletion/operator-recovery.ts:resumeTenantDeletionSchedule, retryTenantPurge | debt | | `FND-PFM-TNL-053` | high | Cancellation records a notice, but the watcher's request reader excludes cancelled requests before the send step. No independent sender is established for that obligation, so the normal cancellation path can retain an unsent notice. | `WF-PFM-TNL-010`, `STATE-PFM-TNL-005` | services-platform:modules/tenants/services/deletion/deletion-holds.ts:cancelTenantDeletion; modules/tenants/services/deletion/tenant-deletion-schedule-operations.ts:requestOfJob | defect | | `FND-PFM-TNL-054` | medium | No lifecycle object registration descriptor is present in the registered module paths. The no-custom-fields design is consistent with the cited opt-in standard, but registration-level absence of capabilities.customFields remains unverified. | `DOM-PFM-TNL-001`, `DOM-PFM-TNL-002`, `DOM-PFM-TNL-003`, `DOM-PFM-TNL-004`, `DOM-PFM-TNL-005`, `ADR-PFM-TNL-014` | services-platform:docs/standards/custom-field-capability.md:R2-ARCH-001; modules/tenants; services-*:modules/tenant-lifecycle | undocumented | | `FND-PFM-TNL-055` | medium | Provisioning retry reads eligibility without a lock spanning retry creation. Two callers can pass the initial failed-state read, and the successor assertion accepts the second same-state write. The open-attempt index bounds created attempts, but it does not make the entire retry sequence atomic. | `WF-PFM-TNL-004`, `DOM-PFM-TNL-002` | services-platform:modules/tenants/services/provisioning/submit-tenant-provisioning.ts:retryTenantProvisioning; modules/tenants/services/persistence/tenants.ts:setTenantLifecycleState; modules/tenants/db/tenant-provisioning-jobs.table.ts | debt | | `FND-PFM-TNL-056` | medium | The notice outcome setter has no predecessor-state predicate. Due-notice selection excludes delivered and suppressed rows, but persistence does not enforce terminal transitions; overlapping send outcomes can replace earlier standing. | `STATE-PFM-TNL-005` | services-platform:modules/tenants/services/persistence/tenant-deletion-requests.ts:recordTenantDeletionNoticeOutcome | inconsistency | | `FND-PFM-TNL-066` | medium | Coverage for request a complete customer workspace still lacks a complete check of edge, boundary, concurrency, rule, interaction, transition. Existing examples do not establish every state-model guard, every authority boundary or every related-capability handoff; the structured inventory identifies the remaining proof obligations. | `CAP-PFM-TNL-001`, `BR-CAP-PFM-TNL-001-08` | rhythm-v2-docs:specs/platform/tenant-lifecycle/planning/capabilities/CAP-PFM-TNL-001-ask-for-a-new-workspace-and-have-every-application-build-it.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/design/state-models/STATE-PFM-TNL-001-workspace-lifecycle.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/design/state-models/STATE-PFM-TNL-002-provisioning-attempt.md | coverage-gap | | `FND-PFM-TNL-067` | medium | Coverage for open a workspace after its applications are ready still lacks a complete check of permission, edge, boundary, concurrency, rule, interaction, transition. Existing examples do not establish every state-model guard, every authority boundary or every related-capability handoff; the structured inventory identifies the remaining proof obligations. | `CAP-PFM-TNL-002`, `BR-CAP-PFM-TNL-002-08` | rhythm-v2-docs:specs/platform/tenant-lifecycle/planning/capabilities/CAP-PFM-TNL-002-open-a-new-workspace-only-when-every-application-reports-it.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/design/state-models/STATE-PFM-TNL-001-workspace-lifecycle.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/design/state-models/STATE-PFM-TNL-002-provisioning-attempt.md | coverage-gap | | `FND-PFM-TNL-068` | medium | Coverage for understand and recover a workspace build still lacks a complete check of validation, boundary, concurrency, transition. Existing examples do not establish every state-model guard, every authority boundary or every related-capability handoff; the structured inventory identifies the remaining proof obligations. | `CAP-PFM-TNL-003` | rhythm-v2-docs:specs/platform/tenant-lifecycle/planning/capabilities/CAP-PFM-TNL-003-follow-a-provisioning-retry-it-and-hear-how-it-ended.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/design/state-models/STATE-PFM-TNL-001-workspace-lifecycle.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/design/state-models/STATE-PFM-TNL-002-provisioning-attempt.md | coverage-gap | | `FND-PFM-TNL-069` | medium | Coverage for prepare the customer’s first access and sender still lacks a complete check of permission, edge, failure, concurrency, transition. Existing examples do not establish every state-model guard, every authority boundary or every related-capability handoff; the structured inventory identifies the remaining proof obligations. | `CAP-PFM-TNL-004` | rhythm-v2-docs:specs/platform/tenant-lifecycle/planning/capabilities/CAP-PFM-TNL-004-give-a-new-customer-its-first-administrator-and-its-own-e.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/design/state-models/STATE-PFM-TNL-001-workspace-lifecycle.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/design/state-models/STATE-PFM-TNL-002-provisioning-attempt.md | coverage-gap | | `FND-PFM-TNL-070` | medium | Coverage for apply workspace availability consistently still lacks a complete check of validation, failure, concurrency, invariant, interaction, transition. Existing examples do not establish every state-model guard, every authority boundary or every related-capability handoff; the structured inventory identifies the remaining proof obligations. | `CAP-PFM-TNL-005` | rhythm-v2-docs:specs/platform/tenant-lifecycle/planning/capabilities/CAP-PFM-TNL-005-keep-people-and-background-work-out-of-a-workspace-that-is.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/design/state-models/STATE-PFM-TNL-001-workspace-lifecycle.md | coverage-gap | | `FND-PFM-TNL-071` | medium | Coverage for preserve valid workspace lifecycle states still lacks a complete check of rule, validation, edge, failure, concurrency, interaction, transition. Existing examples do not establish every state-model guard, every authority boundary or every related-capability handoff; the structured inventory identifies the remaining proof obligations. | `CAP-PFM-TNL-006` | rhythm-v2-docs:specs/platform/tenant-lifecycle/planning/capabilities/CAP-PFM-TNL-006-keep-every-workspace-s-lifecycle-state-truthful.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/design/state-models/STATE-PFM-TNL-001-workspace-lifecycle.md | coverage-gap | | `FND-PFM-TNL-072` | medium | Coverage for account for each application’s lifecycle responsibilities still lacks a complete check of transition, edge, failure, concurrency, rule, interaction. Existing examples do not establish every state-model guard, every authority boundary or every related-capability handoff; the structured inventory identifies the remaining proof obligations. | `CAP-PFM-TNL-007`, `BR-CAP-PFM-TNL-007-08` | rhythm-v2-docs:specs/platform/tenant-lifecycle/planning/capabilities/CAP-PFM-TNL-007-register-each-application-s-part-in-a-workspace-s-life.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/design/state-models/STATE-PFM-TNL-006-registered-external-resource.md | coverage-gap | | `FND-PFM-TNL-073` | medium | Coverage for apply defaults without undoing customer choices still lacks a complete check of transition, failure, concurrency, rule. Existing examples do not establish every state-model guard, every authority boundary or every related-capability handoff; the structured inventory identifies the remaining proof obligations. | `CAP-PFM-TNL-008`, `BR-CAP-PFM-TNL-008-04` | rhythm-v2-docs:specs/platform/tenant-lifecycle/planning/capabilities/CAP-PFM-TNL-008-give-every-workspace-its-default-configuration-exactly-once.md | coverage-gap | | `FND-PFM-TNL-074` | medium | Coverage for maintain the baseline of existing workspaces still lacks a complete check of transition, permission, edge, boundary, concurrency, rule. Existing examples do not establish every state-model guard, every authority boundary or every related-capability handoff; the structured inventory identifies the remaining proof obligations. | `CAP-PFM-TNL-009`, `BR-CAP-PFM-TNL-009-06` | rhythm-v2-docs:specs/platform/tenant-lifecycle/planning/capabilities/CAP-PFM-TNL-009-bring-every-existing-workspace-up-to-the-current-baseline.md | coverage-gap | | `FND-PFM-TNL-075` | medium | Coverage for supply application data for workspace exports still lacks a complete check of edge, failure, concurrency. Existing examples do not establish every state-model guard, every authority boundary or every related-capability handoff; the structured inventory identifies the remaining proof obligations. | `CAP-PFM-TNL-010` | rhythm-v2-docs:specs/platform/tenant-lifecycle/planning/capabilities/CAP-PFM-TNL-010-contribute-each-application-s-records-to-a-whole-workspace.md | coverage-gap | | `FND-PFM-TNL-076` | medium | Coverage for control the initial import and subsequent opening still lacks a complete check of rule, edge, failure, boundary, concurrency, invariant, transition. Existing examples do not establish every state-model guard, every authority boundary or every related-capability handoff; the structured inventory identifies the remaining proof obligations. | `CAP-PFM-TNL-011`, `BR-CAP-PFM-TNL-011-06` | rhythm-v2-docs:specs/platform/tenant-lifecycle/planning/capabilities/CAP-PFM-TNL-011-open-a-workspace-for-its-initial-import-and-let-its-people.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/design/state-models/STATE-PFM-TNL-001-workspace-lifecycle.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/design/state-models/STATE-PFM-TNL-003-initial-load-and-its-resets.md | coverage-gap | | `FND-PFM-TNL-077` | medium | Coverage for recover an incorrect initial import still lacks a complete check of edge, boundary, rule, transition. Existing examples do not establish every state-model guard, every authority boundary or every related-capability handoff; the structured inventory identifies the remaining proof obligations. | `CAP-PFM-TNL-012`, `BR-CAP-PFM-TNL-012-10` | rhythm-v2-docs:specs/platform/tenant-lifecycle/planning/capabilities/CAP-PFM-TNL-012-empty-a-loading-workspace-so-it-can-be-loaded-again.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/design/state-models/STATE-PFM-TNL-001-workspace-lifecycle.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/design/state-models/STATE-PFM-TNL-003-initial-load-and-its-resets.md | coverage-gap | | `FND-PFM-TNL-078` | medium | Coverage for schedule deliberate workspace deletion still lacks a complete check of rule, edge, failure, invariant, interaction, transition. Existing examples do not establish every state-model guard, every authority boundary or every related-capability handoff; the structured inventory identifies the remaining proof obligations. | `CAP-PFM-TNL-013`, `BR-CAP-PFM-TNL-013-11` | rhythm-v2-docs:specs/platform/tenant-lifecycle/planning/capabilities/CAP-PFM-TNL-013-ask-for-a-workspace-to-be-deleted-after-a-waiting-period.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/design/state-models/STATE-PFM-TNL-001-workspace-lifecycle.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/design/state-models/STATE-PFM-TNL-004-deletion-request.md | coverage-gap | | `FND-PFM-TNL-079` | medium | Coverage for pause or cancel deletion while preservation remains possible still lacks a complete check of rule, failure, concurrency, invariant, transition. Existing examples do not establish every state-model guard, every authority boundary or every related-capability handoff; the structured inventory identifies the remaining proof obligations. | `CAP-PFM-TNL-014`, `BR-CAP-PFM-TNL-014-07` | rhythm-v2-docs:specs/platform/tenant-lifecycle/planning/capabilities/CAP-PFM-TNL-014-hold-release-or-call-off-a-deletion-before-destruction.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/design/state-models/STATE-PFM-TNL-001-workspace-lifecycle.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/design/state-models/STATE-PFM-TNL-004-deletion-request.md | coverage-gap | | `FND-PFM-TNL-080` | medium | Coverage for keep deletion decisions visible to staff still lacks a complete check of rule, validation, edge, concurrency, interaction, transition. Existing examples do not establish every state-model guard, every authority boundary or every related-capability handoff; the structured inventory identifies the remaining proof obligations. | `CAP-PFM-TNL-015`, `BR-CAP-PFM-TNL-015-07` | rhythm-v2-docs:specs/platform/tenant-lifecycle/planning/capabilities/CAP-PFM-TNL-015-tell-rhythm-staff-about-every-step-of-a-deletion.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/design/state-models/STATE-PFM-TNL-005-deletion-notice-delivery.md | coverage-gap | | `FND-PFM-TNL-081` | medium | Coverage for revalidate the irreversible deletion decision still lacks a complete check of rule, invariant, transition. Existing examples do not establish every state-model guard, every authority boundary or every related-capability handoff; the structured inventory identifies the remaining proof obligations. | `CAP-PFM-TNL-016` | rhythm-v2-docs:specs/platform/tenant-lifecycle/planning/capabilities/CAP-PFM-TNL-016-begin-destruction-only-when-every-safeguard-still-holds.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/design/state-models/STATE-PFM-TNL-001-workspace-lifecycle.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/design/state-models/STATE-PFM-TNL-004-deletion-request.md | coverage-gap | | `FND-PFM-TNL-082` | medium | Coverage for remove declared workspace resources and verify the result still lacks a complete check of transition, validation, concurrency, rule, interaction. Existing examples do not establish every state-model guard, every authority boundary or every related-capability handoff; the structured inventory identifies the remaining proof obligations. | `CAP-PFM-TNL-017`, `BR-CAP-PFM-TNL-017-07`, `BR-CAP-PFM-TNL-017-13`, `BR-CAP-PFM-TNL-017-14` | rhythm-v2-docs:specs/platform/tenant-lifecycle/planning/capabilities/CAP-PFM-TNL-017-remove-everything-a-workspace-owned-and-prove-it-is-gone.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/design/state-models/STATE-PFM-TNL-001-workspace-lifecycle.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/design/state-models/STATE-PFM-TNL-004-deletion-request.md | coverage-gap | | `FND-PFM-TNL-083` | medium | Coverage for retain deletion evidence and prevent identifier reuse still lacks a complete check of transition, permission, failure, boundary, concurrency, rule. Existing examples do not establish every state-model guard, every authority boundary or every related-capability handoff; the structured inventory identifies the remaining proof obligations. | `CAP-PFM-TNL-018`, `BR-CAP-PFM-TNL-018-06` | rhythm-v2-docs:specs/platform/tenant-lifecycle/planning/capabilities/CAP-PFM-TNL-018-keep-a-lasting-record-of-a-deleted-workspace-and-stop-it.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/design/state-models/STATE-PFM-TNL-001-workspace-lifecycle.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/design/state-models/STATE-PFM-TNL-004-deletion-request.md | coverage-gap | | `FND-PFM-TNL-084` | medium | The file inventory is classified and executable lifecycle suites are registered, but the structured unbound list still needs assertion-level acceptance mapping. Delegated administration files remain outside this module’s register; no file existence or suite registration is counted as scenario proof. | `MOD-PFM-TNL`, `FND-PFM-TNL-033` | rhythm-v2-docs:specs/platform/tenant-lifecycle/reports/TESTING-BACKFILL-2026-10-23.md#counts; FINDINGS.md#testing_unbound_files, testing_excluded_files | coverage-gap | | `FND-PFM-TNL-085` | low | The starting commit contains neither a previous testing report nor a Platform architecture record. The prior planning and design examination reports establish their own final-text passes; testing continuation therefore uses the actual artifact inventory and cited product records rather than inventing a previous testing result or area architecture decision. | `MOD-PFM-TNL` | rhythm-v2-docs:specs/PRODUCT-AREAS.md#Architecture Artifacts; specs/platform/tenant-lifecycle/reports/EXAMINATION-2026-10-22.md; specs/platform/tenant-lifecycle/reports/DESIGN-EXAMINATION-2026-10-23.md | coverage-gap | | `FND-PFM-TNL-086` | high | All six feature suites define proposed combined checks; no existing registered file is claimed to execute a complete feature scenario. Service-suite runs, deployed provider recovery, console qualification and a full cross-application lifecycle remain unqualified; corpus checks cannot resolve the known restore, notice and finalization defects. | `FAS-PFM-TNL-01`, `FAS-PFM-TNL-02`, `FAS-PFM-TNL-03`, `FAS-PFM-TNL-04`, `FAS-PFM-TNL-05`, `FAS-PFM-TNL-06` | rhythm-v2-docs:specs/platform/tenant-lifecycle/planning/acceptance; services-platform:modules/tenants/tests/local-provisioning.js; services-platform:modules/tenants/tests/local-deletion.js; FND-PFM-TNL-004, FND-PFM-TNL-051, FND-PFM-TNL-053 | coverage-gap | ## Open Questions | id | question | why_it_matters | options | recommendation | affects | |---|---|---|---|---|---| | `OQ-PFM-TNL-001` | Where should lifecycle administration screens have their specification home? | The hosted-screen convention follows record ownership, while current source registration places HQ surfaces elsewhere. | A: place lifecycle screen contracts here and register their console scope. B: retain them with workspace administration. C: place shared progress pages with jobs. | The product should choose A for lifecycle-specific screens and retain shared job pages with their owner. | `MOD-PFM-TNL` | | `OQ-PFM-TNL-002` | Which workspace eligibility definition should apply to each background or configuration task? | Different selectors include or exclude disabled and loading workspaces, changing whether background work or new defaults reach them. | A: define eligibility by purpose. B: require active, enabled standing for every task. C: preserve the existing selectors without a shared explanation. | The product should choose A and document configuration eligibility separately from ordinary processing. | `CAP-PFM-TNL-005`, `CAP-PFM-TNL-009` | | `OQ-PFM-TNL-003` | What is the deliberate removal path for an abandoned load? | The state policy offers a transition that the deletion request cannot admit, requiring activation before the current removal sequence. | A: permit removal directly from loading with explicit disabling. B: require activation first and retire the unused transition. C: leave the mismatch unresolved. | The product should choose B unless Product authorizes a dedicated abandoned-load removal path. | `CAP-PFM-TNL-006`, `CAP-PFM-TNL-013` | | `OQ-PFM-TNL-004` | Which module owns an application participant’s export contribution? | Participant dataset declarations sit beside lifecycle operations, while overall execution and delivery belong to the export coordinator. | A: keep participant contracts here and orchestration with exports. B: move the complete contribution specification to exports. | The product should choose A so participant ownership has one specification home. | `CAP-PFM-TNL-010` | | `OQ-PFM-TNL-005` | Should the deletion and initial-load administration screens be built in Rhythm HQ, and where? | Deletion and loading are only reachable through the API today; staff need a safe way to hold, cancel and follow a deletion and to reset and activate a load, and the screen contracts here assume their routes. | A: build the three deletion screens and an initial-load panel in Rhythm HQ under the HQ workspace pages. B: keep both API-only, operated by runbook and staff tools. C: build deletion screens only. | The product should choose A so every human action that the safeguards depend on has a reviewed screen, following the console change approval rule. | `SCR-PFM-TNL-001`, `SCR-PFM-TNL-002`, `SCR-PFM-TNL-003`, `CAP-PFM-TNL-011`, `CAP-PFM-TNL-012`, `CAP-PFM-TNL-014` |