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 |
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 |