The category map records specified proof. A covered category can contain proposed scenarios; it does not mean the checks have run. The bindings identify individual executable contributions, while findings retain missing rules, permissions, transitions and assertions.
The interaction scenarios connect this capability to the related actions and workflow handoffs named in their proof references. Each case observes the outcome after the connected action changes records or available authority. A collection of separately bound checks does not establish an ordered feature journey.
Source revisions and assertion references are recorded in frontmatter. Steps and expected observations carry separate evidence annotations. Proposed checks remain distinct from executable test statements, and static review supplies no run result.
Coverage
Rulegap: FND-PFM-SEC-069
Transitioncovered
Validationcovered
Permissioncovered
Edgecovered
Failuregap: FND-PFM-SEC-069
Boundarycovered
Concurrencycovered
Invariantcovered
Interactioncovered
Test Scenarios
18 scenarios proving CAP-PFM-SEC-012; 13 bound to an existing test.
01Separate read and management permissionspermissionapinegativetest
Prepare a run-owned custom and built-in access definition in active state with the authority and inputs required by the cited transition.
Steps
[
{
"do": "Archive an unreferenced custom definition with management permission and its current version.",
"expect": "After the stated action, observe the custom and built-in access definition in archived state. This case does not require an additional history event unless the transition explicitly defines one.",
"provenance": "proposed",
"source": [
"services-platform:modules/security/services/definitions/manage-roles.ts:archiveCustomRole",
"services-platform at ad3f6a65: modules/security/db/security-roles.table.ts, security-policies.table.ts; services/definitions/manage-roles.ts, manage-policies.ts, impact.ts; services/catalog/*."
]
}
]
Expected
After the stated action, observe the custom and built-in access definition in archived state. This case does not require an additional history event unless the transition explicitly defines one.
Data
A disposable customer, workspace and named actor; a controllable clock where the transition depends on time.
Source
services-platform:modules/security/services/definitions/manage-roles.ts:archiveCustomRole,services-platform at ad3f6a65: modules/security/db/security-roles.table.ts, security-policies.table.ts; services/definitions/manage-roles.ts, manage-policies.ts, impact.ts; services/catalog/*.
15Custom and built-in access definition: active to activetransitionapiproposed
Prepare a run-owned custom and built-in access definition in active state with the authority and inputs required by the cited transition.
Steps
[
{
"do": "Change the active custom definition, then independently change a built-in through release reconciliation.",
"expect": "After the stated action, observe the custom and built-in access definition in active state. This case does not require an additional history event unless the transition explicitly defines one.",
"provenance": "proposed",
"source": [
"services-platform:modules/security/services/definitions/manage-roles.ts:updateCustomRole",
"services-platform at ad3f6a65: modules/security/db/security-roles.table.ts, security-policies.table.ts; services/definitions/manage-roles.ts, manage-policies.ts, impact.ts; services/catalog/*."
]
}
]
Expected
After the stated action, observe the custom and built-in access definition in active state. This case does not require an additional history event unless the transition explicitly defines one.
Data
A disposable customer, workspace and named actor; a controllable clock where the transition depends on time.
Source
services-platform:modules/security/services/definitions/manage-roles.ts:updateCustomRole,services-platform at ad3f6a65: modules/security/db/security-roles.table.ts, security-policies.table.ts; services/definitions/manage-roles.ts, manage-policies.ts, impact.ts; services/catalog/*.
16Model customer responsibilities with roles and policies with assign roles within a controlled scopeinteractionapinegativeproposed
A role editor lacks authority for a requested widening change.
Steps
Attempt the edit and inspect the definition and refusal history.
Expected
The definition is unchanged and the classified refusal survives rollback.
Data
An isolated customer with two workspaces, ordinary and staff identities, and records owned by this run.
Source
services-platform:modules/security/services/audit/refused-attempts.ts:auditedAttempt,services-platform:modules/security/tests/integration/services/definitions/manage-roles.integration.spec.js#refuses an edit that would widen a role the editor holds themselves, whoever else holds it
18Model customer responsibilities with roles and policies with derive member access from appointments and eligibilityinteractionapinegativeproposed
A customer role uses an eligibility condition binding in its own workspace.
Steps
Evaluate the condition, then try replacing it with another customer’s binding.
Expected
The owned condition participates in evaluation; the foreign replacement is refused without changing the definition.
Data
An isolated customer with two workspaces, ordinary and staff identities, and records owned by this run.
Source
services-platform:modules/security/services/persistence/rules.ts:parseConditions,services-platform:modules/security/tests/integration/services/definitions/eligibility-conditions.integration.spec.js#refuses a binding of another customer’s tenant, naming it, and stores no policy