Examination Findings and Product Questions
Findings
| id | severity | statement | affects | evidence | kind |
|---|---|---|---|---|---|
FND-PFM-MTD-001 | medium | The original registry scope included the eligibility milestone while omitting milestones for loads, events, console delivery and field capability. Several console paths were unavailable and implementation paths were missing. The draft’s registry update repairs that scope description. | MOD-PFM-MTD | Structured evidence | inconsistency |
FND-PFM-MTD-002 | low | The extensibility inventory primarily describes integration registry and invocation work. Only three business-event delivery entries belong to this module; the remaining inventory stays with the integrations module. | MOD-PFM-MTD, CAP-PFM-MTD-015 | Structured evidence | inconsistency |
FND-PFM-MTD-003 | medium | The relationship milestone remains in progress and lacks an Engineering Verified run. Its recorded layers passed, but verification is held for an owner-picker scenario associated with the earlier console milestone. Approved plans and decisions establish relationship intent; acceptance completion does not. | CAP-PFM-MTD-017, CAP-PFM-MTD-018, CAP-PFM-MTD-019, JNY-PFM-MTD-002, JNY-PFM-MTD-004, JNY-PFM-MTD-005 | Structured evidence | debt |
FND-PFM-MTD-004 | medium | The loads and events milestone remains proposed without an approved plan. Its record describes unlanded work even though the pinned tree contains load handlers, event storage, dispatch and sweeping. The affected capabilities retain proposed intent. | CAP-PFM-MTD-015, CAP-PFM-MTD-016 | Structured evidence | inconsistency |
FND-PFM-MTD-005 | medium | The attachment milestone has no Engineering Verified run. Upload issuance is implemented, while uploader checking and web-address copying during save depend on shared assets and record owners beyond this module’s proof. Issuance does not apply a field-specific smaller size limit. | CAP-PFM-MTD-007, BR-CAP-PFM-MTD-007-08 | Structured evidence | debt |
FND-PFM-MTD-006 | medium | The contact page designer stores draft and published documents in browser storage. Platform’s shared layout storage is therefore not the publication destination, and other browsers do not receive that publication. The standard expects shared configured layouts and leaves the engine choice open. | BR-CAP-PFM-MTD-008-13, CAP-PFM-MTD-008 | Structured evidence | inconsistency |
FND-PFM-MTD-007 | low | The permission catalogue includes metadata, label and layout keys without corresponding route requirements. Publishing a permission resource does not establish an operation. Bulk custom-field access is consumed by dependent data-job routes. | CAP-PFM-MTD-002, CAP-PFM-MTD-004, CAP-PFM-MTD-008 | Structured evidence | debt |
FND-PFM-MTD-008 | medium | Four approved additional-field categories lack layout purposes: committee nominations, memberships, organizational units and membership applications. Their form and layout requests fail despite the standard’s associated presentation obligation. No in-scope deferral decision establishes an exception. | CAP-PFM-MTD-003, CAP-PFM-MTD-008 | Structured evidence | debt |
FND-PFM-MTD-009 | medium | Object settings accept and retain per-owner record and per-record link limits without enforcing them. An owner can receive records beyond the stored cap, contrary to the documented enforcement claim. | BR-CAP-PFM-MTD-009-11 | Structured evidence | defect |
FND-PFM-MTD-010 | medium | Reset retains custom-object definitions, including active ones, while removing their properties and rules. Until package restoration, the retained definition lacks its naming property and cannot be replaced unchanged. The recorded reset decision does not settle property retention. | BR-CAP-PFM-MTD-009-10, OQ-PFM-MTD-001 | Structured evidence | inconsistency |
FND-PFM-MTD-011 | medium | A link-load correction replaces link attributes as a complete set. Supplying only primary clears omitted dates, position and notes; omitting an existing end date reopens the connection. Partial correction files can therefore change history without warning. | BR-CAP-PFM-MTD-016-06, CAP-PFM-MTD-016 | Structured evidence | defect |
FND-PFM-MTD-012 | medium | The metadata contract assigns HTML sanitization to value storage, but custom-record writes convert and retain HTML without a sanitizing step. No scoped test proves sanitization, leaving a gap before markup reaches member or public consumers. | CAP-PFM-MTD-012, SC-CAP-PFM-MTD-012-03 | Structured evidence | defect |
FND-PFM-MTD-013 | medium | Endpoint requirement flags are stored on relationship types but are not checked by custom-record or link writes. The documented owner responsibility therefore does not prevent a record from existing without its required connection. | BR-CAP-PFM-MTD-017-07 | Structured evidence | defect |
FND-PFM-MTD-014 | low | A deletion-check registration seam exists without a registered consumer. Cross-service cascades do not consult that seam, so future submission protections would need explicit integration to cover cascaded removal. | BR-CAP-PFM-MTD-013-10, CAP-PFM-MTD-019 | Structured evidence | debt |
FND-PFM-MTD-015 | low | Ownership predicates and exposure projections have tests, while member and public record routes remain absent under the recorded portal pause. Stored portal operation settings do not establish a delivered member workflow. | BR-CAP-PFM-MTD-011-07, BR-CAP-PFM-MTD-011-06, CAP-PFM-MTD-011 | Structured evidence | debt |
FND-PFM-MTD-016 | low | The caller-organization default is accepted but resolves no value because the signed context supplies no organization. The available option consequently has no filling effect. | BR-CAP-PFM-MTD-006-04, BR-CAP-PFM-MTD-012-05 | Structured evidence | undocumented |
FND-PFM-MTD-017 | low | Only custom-object records register the checker needed to enable uniqueness. Registered record categories therefore reject unique rules despite sharing the rule vocabulary. | BR-CAP-PFM-MTD-006-03 | Structured evidence | undocumented |
FND-PFM-MTD-018 | low | The builder-deletion browser test retains a title suggesting partial deletion. Its assertions instead prove refusal and complete rollback, matching the corrected all-or-nothing decision. Evidence strength follows those assertions. | BR-CAP-PFM-MTD-013-05, JNY-PFM-MTD-005 | Structured evidence | inconsistency |
FND-PFM-MTD-019 | medium | Platform retains relationship revisions for native endpoints, but CRM’s drawer reads CRM history alone. Staff do not see those linked-record changes in the contact or organization timeline; the service records this integration gap. | BR-CAP-PFM-MTD-014-05, OQ-PFM-MTD-003 | Structured evidence | debt |
FND-PFM-MTD-020 | low | The legacy custom-object inventory and README describe an earlier branch with no console screens and a pending console decision. The pinned tree contains screens and browser specifications under the later milestone approach. Legacy capabilities are superseded; the earlier rule inventory is a seed rather than a completed row-by-row reconciliation. | MOD-PFM-MTD | Structured evidence | inconsistency |
FND-PFM-MTD-021 | low | The shared metadata contract enforces the obligation to declare forms and layouts with additional fields. Platform’s scoped tests do not demonstrate that contract refusal, so the rule retains documentary evidence pending an appropriate integration proof. | BR-CAP-PFM-MTD-003-03 | Structured evidence | debt |
FND-PFM-MTD-022 | low | The recorded decision limits relationship-type counts per workspace and endpoint category. Persistence does not enforce either limit; query description instead bounds its type read and logs overflow. | BR-CAP-PFM-MTD-017-08 | Structured evidence | defect |
FND-PFM-MTD-023 | low | The custom-navigation operation exists in routes but is absent from the contract’s route tables. Its availability is therefore implementation evidence with a documentation gap. | CAP-PFM-MTD-010 | Structured evidence | undocumented |
FND-PFM-MTD-024 | low | The scoped modules contain eighty-six literal operation identities and three factory-generated health routes. Dependent custom-record data-job declarations belong to the data-job engine and are excluded from that literal count. | MOD-PFM-MTD | Structured evidence | inconsistency |
FND-PFM-MTD-025 | low | The definition retains a legacy navigation hint alongside validated app placement. Writes do not reconcile the two settings, and the contract leaves removal of the older hint undecided. | CAP-PFM-MTD-010 | Structured evidence | debt |
FND-PFM-MTD-026 | medium | A bound test establishes its asserted behavior, not a passing execution at the pinned commits. Recorded live runs contain an owner-picker failure and earlier API failures, so current acceptance needs execution evidence. | JNY-PFM-MTD-002, ATS-PFM-MTD-012, ATS-PFM-MTD-018 | Structured evidence | debt |
FND-PFM-MTD-027 | low | Transition compatibility supplies all capabilities to approved categories that omit declarations and warns on certain query registrations without refusing them. Owning-service declarations and removals from unapproved categories remain outside this module’s completed work. | CAP-PFM-MTD-003, BR-CAP-PFM-MTD-003-04 | Structured evidence | debt |
FND-PFM-MTD-028 | low | Role-restricted reach depends on Security’s object-scoped assignments. This module stores and applies the access mode; creating the scoped role assignment belongs to Security. | CAP-PFM-MTD-011, JNY-PFM-MTD-003 | Structured evidence | undocumented |
FND-PFM-MTD-029 | low | Link-attribute updates and merge-driven link movements or endings emit no business announcements. Service debt records retain both omissions. | BR-CAP-PFM-MTD-015-08 | Structured evidence | debt |
FND-PFM-MTD-030 | low | The custom-record export key has no requiring route. Exports use the query layer, and custom-object dataset end-to-end confirmation remains recorded debt. | BR-CAP-PFM-MTD-011-05, CAP-PFM-MTD-016 | Structured evidence | debt |
| FND-PFM-MTD-31 | medium | The planning brief named by the examination job is absent from the starting checkout and the fetched default branch. Examination uses the supplied job instructions and pinned product records; draft compliance with that missing brief remains unknown. | MOD-PFM-MTD | Structured evidence | undocumented | | FND-PFM-MTD-32 | medium | Indexed-field archival commits a degradation record and rebuild request; the search documents change later. The draft incorrectly promised immediate document rewriting. The corrected rule is observed in the archive coordinator, while its existing test binding demonstrates the completed rebuild. | BR-CAP-PFM-MTD-005-08 | Structured evidence | inconsistency | | FND-PFM-MTD-33 | low | The field-count limit is checked only for custom objects. The draft extends it to registered record types; the corrected rule limits that claim to custom-object properties. | BR-CAP-PFM-MTD-005-09, ATS-PFM-MTD-005-09 | Structured evidence | inconsistency | | FND-PFM-MTD-34 | medium | Visibility validation checks submitted changes rather than every retained value. Changing a controlling property can leave an untouched hidden value stored. The added acceptance scenario is proposed because no existing binding proves this transition. | BR-CAP-PFM-MTD-012-04, ATS-PFM-MTD-012-15 | Structured evidence | undocumented | | FND-PFM-MTD-35 | medium | Direct deletion does not reject a record merely because it is archived, provided its object is active and deletion checks pass. The draft says archived records accept only restoration. The correction and proposed deletion scenario distinguish record archival from object archival. | BR-CAP-PFM-MTD-012-11, BR-CAP-PFM-MTD-013-02, ATS-PFM-MTD-012-16 | Structured evidence | inconsistency | | FND-PFM-MTD-36 | medium | Activation writes shared Explorer query recipes, rather than personal saved views. The object archive operation contains no recipe retirement call. The draft conflates those records and promises retirement; the corrected rule and a proposed scenario expose the actual boundary. | BR-CAP-PFM-MTD-009-12, ATS-PFM-MTD-009-12 | Structured evidence | inconsistency | | FND-PFM-MTD-37 | medium | Additional must-prove obligations lack a bound acceptance scenario: post-registration search degradation, custom-app lifecycle cleanup, history filtering and purge protection, queued-event retention, and relationship cleanup on workspace reset or deletion. Existing documentation and service code describe these behaviours; approval requires explicit proof at the relevant boundary. | BR-CAP-PFM-MTD-001-10, BR-CAP-PFM-MTD-010-09, BR-CAP-PFM-MTD-014-07, BR-CAP-PFM-MTD-015-06, BR-CAP-PFM-MTD-019-10 | Structured evidence | debt | | FND-PFM-MTD-38 | medium | Upload issuance signs an expiring address and records an issue but does not consume a one-use token. The draft calls that address single-use without evidence. Issuance also validates the declaration rather than checking whether the named field exists or accepts the requested kind. Save-side enforcement remains a separate obligation. | CAP-PFM-MTD-007 | Structured evidence | undocumented | | FND-PFM-MTD-39 | medium | Some composite proof claims exceed the assertions in their bindings: collection retirement in registration, portal absence as a route inventory claim, and the contact-field journey rendering a newly created field in a browser. Database integration scenarios are corrected to the API tier; the contact journey is narrowed to description evidence and remains partially observed. Each listed test exists, but an execution pass and complete end-to-end proof are separate questions. | BR-CAP-PFM-MTD-001-02, BR-CAP-PFM-MTD-011-07, JNY-PFM-MTD-006 | Structured evidence | debt | | FND-PFM-MTD-40 | medium | Link maintenance rejects applicable record locks even after the relationship type is deactivated. The added rule and proposed acceptance scenario cover those service refusals; no existing bound test proves their combined lifecycle case. | BR-CAP-PFM-MTD-018-13, ATS-PFM-MTD-018-12 | Structured evidence | debt |
| FND-PFM-MTD-041 | medium | Current descriptions and audience exposure filter revision presentation, leaving archived property values retained but undisplayed. A focused archive-then-history acceptance binding is absent. The history record also identifies concurrent opposite-direction link capture as a deadlock case that depends on caller retry; no scoped proof establishes that retry boundary. | BR-CAP-PFM-MTD-014-08, CAP-PFM-MTD-014 | Structured evidence | debt | | FND-PFM-MTD-042 | high | The custom record store's file cleanup is not deployed. Files of deleted records, replaced files and copies of refused saves are marked for retirement or discard, but nothing retires them, so they stay at their permanent addresses and remain fetchable by anyone holding the address. Deletion therefore does not remove a person's picture or document as the asset decision expects. | BR-CAP-PFM-MTD-013-03, WF-PFM-MTD-005, WF-PFM-MTD-007, STATE-PFM-MTD-007, ADR-PFM-MTD-013 | Structured evidence | debt | | FND-PFM-MTD-043 | medium | Archiving a custom field starts its search rebuild after the commit with a plain start. If the start fails, the request answers an error although the field is archived, a retry is refused as already archived, and the rebuild waits for the reconciler to settle it as never started. The jobs standard asks API-facing submitters to leave a failed start to the reconciler and answer success. | WF-PFM-MTD-002, BR-CAP-PFM-MTD-005-08, SVC-PFM-MTD-metadata | Structured evidence | defect | | FND-PFM-MTD-044 | medium | After a registration retires fields, the search fan-out walks workspaces one at a time, logs and skips any workspace it cannot degrade, and stops after one hundred rebuilds. Skipped and remaining workspaces keep the retired field's values in search until someone rebuilds, and the deploy is told nothing; no reconciliation picks them up. | WF-PFM-MTD-001, BR-CAP-PFM-MTD-001-10, STATE-PFM-MTD-001 | Structured evidence | debt | | FND-PFM-MTD-045 | medium | Planning says a workspace reset empties both relationship types and links. The code and the reset decision keep the types, which kept custom objects name as owners, and empty only the links; the module's own contract document repeats the planning wording. The planning rule needs correcting to match the decided behaviour. | BR-CAP-PFM-MTD-019-10, WF-PFM-MTD-015 | Structured evidence | inconsistency | | FND-PFM-MTD-046 | medium | The owner chosen while a custom object is a draft is kept only in the browser that made it. Activating the object from another browser, by another administrator, or after the browser's storage is cleared activates it with no owner and no warning. | WF-PFM-MTD-004, SCR-PFM-MTD-011, OQ-PFM-MTD-005 | Structured evidence | defect | | FND-PFM-MTD-047 | medium | A custom record and its owner are saved by separate calls: the record, then removal of the old owner link, then the new link. A failure after the removal leaves the record with no owner; the person is told for ten seconds and nothing restores the previous owner. Required-owner flags do not prevent it. | WF-PFM-MTD-006, SCR-PFM-MTD-015, SCR-PFM-MTD-017, OQ-PFM-MTD-004 | Structured evidence | debt | | FND-PFM-MTD-048 | low | A field's definition and its rules are saved by separate calls, and arranging properties is one replacement per property. A refused rule set leaves the field saved with its previous rules, and a refusal part way through an arrangement leaves the properties partly moved. | WF-PFM-MTD-003, SCR-PFM-MTD-003, OQ-PFM-MTD-004 | Structured evidence | debt | | FND-PFM-MTD-049 | medium | The Record Layouts screen lists sample rows built into the console rather than the workspace's stored page layouts, offers record types without the page layout capability, and saves nothing to Platform. Its contract is left open until the publication destination is decided. | SCR-PFM-MTD-008, BR-CAP-PFM-MTD-003-06, OQ-PFM-MTD-002 | Structured evidence | inconsistency | | FND-PFM-MTD-050 | low | The Fields chooser filters the record type list itself to contacts, organizations and custom objects instead of asking the registry for record types holding custom fields. Approved record types such as committees are not offered once their owners declare them. | SCR-PFM-MTD-001, BR-CAP-PFM-MTD-003-07 | Structured evidence | inconsistency | | FND-PFM-MTD-051 | low | This module asks no model a question, but the custom record list's Ask box sends the question to the Queries module's query generation when that is switched on. The module charter carries no sentence saying the module performs no inference, and the Queries module owes the inference operation for its generation. | SCR-PFM-MTD-014, MOD-PFM-MTD | Structured evidence | undocumented | | FND-PFM-MTD-052 | low | While no native subscriber and no integration router exist, every business event is removed from the outbox without any message and survives only in the ledger for ninety days. A destination added later never hears about earlier changes. | WF-PFM-MTD-010, STATE-PFM-MTD-008, OQ-PFM-MTD-006 | Structured evidence | undocumented | | FND-PFM-MTD-053 | low | Every upload issue is recorded and the records are never pruned; the ledger grows with every picked file whether or not it is saved. | WF-PFM-MTD-013, SVC-PFM-MTD-files | Structured evidence | debt | | FND-PFM-MTD-054 | medium | Owners write layout assignments through a dedicated database role whose membership depends on a database bootstrap change recorded as an open follow-up. Until it lands, an owner's assignment writes in a deployed environment would be refused; this module cannot confirm whether it has landed. | DOM-PFM-MTD-003, SVC-PFM-MTD-layouts, INV-DOM-PFM-MTD-003-04 | Structured evidence | debt | | FND-PFM-MTD-055 | low | The module charter names the jobs, audit and licensing module as the owner of data job orchestration, while the registry of modules gives data jobs to the Data Job Engine module. The design delegates loads to the Data Job Engine. | MOD-PFM-MTD, WF-PFM-MTD-012 | Structured evidence | inconsistency | | FND-PFM-MTD-056 | medium | Individual registration upserts lock rows, but complete manifests have no application-wide lock; concurrent releases have no proved last-release-wins guarantee. | WF-PFM-MTD-001, STATE-PFM-MTD-001 | services-platform:modules/metadata/services/registration/register-application.ts:registerApplication; services-platform:modules/metadata/services/persistence/registered-objects.ts | debt | | FND-PFM-MTD-057 | medium | The draft omitted accepted publication and past-dated link transitions and overstated version guards; the design examination corrects these descriptions without changing planning. | STATE-PFM-MTD-002, STATE-PFM-MTD-006, STATE-PFM-MTD-009, STATE-PFM-MTD-010 | services-platform:modules/custom-objects/services/persistence/custom-object-records.ts:publishRecord; services-platform:modules/associations/services/persistence/associations.ts; services-platform:modules/metadata/services/persistence/custom-fields.ts:restoreCustomField | inconsistency | | FND-PFM-MTD-058 | medium | The custom-record list consumes query generation when enabled, but its draft inference list was empty; the examination adds the consumed operation contract while Queries retains execution ownership. | SCR-PFM-MTD-014, IOP-PFM-MTD-001 | react-console:components/record-explorer/use-recipe-explorer.ts; services-platform:modules/queries/services/generate/generation-runner.ts:GENERATE_QUERY_OPERATION_KEY | inconsistency | | FND-PFM-MTD-059 | low | The draft calls existing screens approved and requires new visual designs for behavior changes without a cited decision; those claims are removed because implementation does not establish approval. | SCR-PFM-MTD-001, SCR-PFM-MTD-008, SCR-PFM-MTD-009 | rhythm-v2-docs:specs/CONVENTIONS.md#6. Document Form; rhythm-v2-docs:specs/CONVENTIONS.md#10. Deferred Kinds | undocumented | | FND-PFM-MTD-060 | medium | The requested design brief is absent and planning artifacts retain draft status; their confirmed product origins are available, but this checkout does not establish approval of the planning layer itself. | SVC-PFM-MTD-metadata, ADR-PFM-MTD-014 | rhythm-v2-docs:briefs/design/platform-metadata.brief.md (absent at the starting commit); rhythm-v2-docs:specs/platform/metadata/planning/capabilities/ (draft status) | undocumented | | FND-PFM-MTD-061 | low | One archival hop claimed test provenance from service code, and CRM cascades pointed to the adapter that only returns cascade targets; the examination corrects provenance and points to the database implementation. | WF-PFM-MTD-002, WF-PFM-MTD-008 | services-platform:modules/metadata/services/field-lifecycle/archive-field.ts; services-platform:db/migrations/20261020023906_apply_endpoint_deletion.sql; services-platform:db/migrations/20261021162402_associations_in_force_until_end_date.sql; services-platform:modules/associations/services/persistence/associations.ts:applyEndpointDeletion | inconsistency | | FND-PFM-MTD-062 | medium | A minute schedule does not bound delivery during errors or throttling, and the pinned tree does not establish whether an external router parameter exists in a deployed environment. | WF-PFM-MTD-010, STATE-PFM-MTD-008, SVC-PFM-MTD-custom-objects | services-platform:modules/custom-objects/services/dispatch/business-events.ts; services-platform:modules/custom-objects/aws/logic/business-events.lambda.ts | undocumented |
Open Questions
| id | question | why_it_matters | options | recommendation | affects |
|---|---|---|---|---|---|
OQ-PFM-MTD-001 | Which parts of an object definition survive workspace reset? | Reset currently preserves active objects while removing the properties needed to use them. The recorded decision retains record categories without resolving that mismatch. | A: retain properties and rules while clearing record data. B: require a property-restoring package after every reset. C: archive active definitions until configuration is restored. | The product should retain properties and rules with their objects so reset leaves a usable definition while replacing its data. | CAP-PFM-MTD-009, BR-CAP-PFM-MTD-009-10, FND-PFM-MTD-010 |
OQ-PFM-MTD-002 | What is the shared publication destination for record page designs? | Contact layouts currently publish only within one browser despite available shared storage and assignment protection. The consumer engine remains an open choice. | A: save and publish through shared layout storage and owner assignments. B: retain browser drafts until the engine decision. C: remove the designer and use description-generated pages. | The product should publish page designs through Platform storage and assignments so every user receives the same configuration while rendering can evolve. | CAP-PFM-MTD-008, BR-CAP-PFM-MTD-008-13, FND-PFM-MTD-006 |
OQ-PFM-MTD-003 | How should native-record timelines present Platform relationship changes? | Platform records the revisions, but CRM’s timeline does not read them. A person inspecting a contact therefore misses linked-record changes. | A: combine CRM and Platform revisions in one timeline. B: present a separate relationship-history panel. C: retain these revisions only on the custom-record surface. | The product should combine the timelines so staff can inspect the person’s changes in one place, using revisions already retained for that endpoint. | CAP-PFM-MTD-014, BR-CAP-PFM-MTD-014-05, FND-PFM-MTD-019 |
OQ-PFM-MTD-004 | Should the console's multi-call saves become single service operations? | A record and its owner, a field and its rules, and an object and its owner type are each saved by several calls with no compensation, so partial states reach staff and depend on a short message. | A: add composite service operations (a record write that names its owner; a field write that carries its rules; activation that creates the owner type). B: keep the calls and add console compensation. C: keep the current behaviour and state it. | A: one transaction per action removes the partial states; compensation from a browser can itself fail. | WF-PFM-MTD-003, WF-PFM-MTD-004, WF-PFM-MTD-006, ADR-PFM-MTD-012, FND-PFM-MTD-047, FND-PFM-MTD-048 |
OQ-PFM-MTD-005 | Where is a draft custom object's intended owner kept? | Relationship types refuse draft objects, so the owner chosen during design is held in one browser and lost elsewhere. | A: store the intended owner on the object definition and create the owner type in the activation transaction. B: let relationship types name draft objects so the owner type is made at once. C: keep the browser storage. | A: the definition is the shared record of the design, and activation already checks the owner. | WF-PFM-MTD-004, DOM-PFM-MTD-004, FND-PFM-MTD-046 |
OQ-PFM-MTD-006 | Should events published before a destination existed be replayed to it? | Today events with no destination are never sent and are swept after ninety days, so an integration or automation switched on later starts from nothing. | A: replay the ledger window to a newly registered destination. B: deliver only events after registration. C: let each destination ask for a bounded replay. | B for now with the behaviour stated, and C when the integration router lands, because unbounded replay can surprise a new subscriber. | WF-PFM-MTD-010, STATE-PFM-MTD-008, FND-PFM-MTD-052 |
Testing Coverage Findings
| Id | Severity | Statement | Affects | Evidence | Kind |
|---|---|---|---|---|---|
FND-PFM-MTD-063 | medium | Keep the Record Catalogue Current has remaining proof obligations across detailed lifecycle, permission, invariant or workflow cases; category and executable gaps are itemized in the evidence. | CAP-PFM-MTD-001, ATS-PFM-MTD-001 | structured testing coverage audit | coverage-gap |
FND-PFM-MTD-064 | medium | Describe Records for Shared Clients has remaining proof obligations across detailed lifecycle, permission, invariant or workflow cases; category and executable gaps are itemized in the evidence. | CAP-PFM-MTD-002, ATS-PFM-MTD-002 | structured testing coverage audit | coverage-gap |
FND-PFM-MTD-065 | medium | Keep Configurability Within Product Scope has remaining proof obligations across detailed lifecycle, permission, invariant or workflow cases; category and executable gaps are itemized in the evidence. | CAP-PFM-MTD-003, ATS-PFM-MTD-003 | structured testing coverage audit | coverage-gap |
FND-PFM-MTD-066 | medium | Use Workspace Labels for Standard Fields has remaining proof obligations across detailed lifecycle, permission, invariant or workflow cases; category and executable gaps are itemized in the evidence. | CAP-PFM-MTD-004, ATS-PFM-MTD-004 | structured testing coverage audit | coverage-gap |
FND-PFM-MTD-067 | medium | Extend Records With Durable Custom Fields has remaining proof obligations across detailed lifecycle, permission, invariant or workflow cases; category and executable gaps are itemized in the evidence. | CAP-PFM-MTD-005, ATS-PFM-MTD-005 | structured testing coverage audit | coverage-gap |
FND-PFM-MTD-068 | medium | Configure Field Requirements and Exposure has remaining proof obligations across detailed lifecycle, permission, invariant or workflow cases; category and executable gaps are itemized in the evidence. | CAP-PFM-MTD-006, ATS-PFM-MTD-006 | structured testing coverage audit | coverage-gap |
FND-PFM-MTD-069 | medium | Prepare Image and File Uploads has remaining proof obligations across detailed lifecycle, permission, invariant or workflow cases; category and executable gaps are itemized in the evidence. | CAP-PFM-MTD-007, ATS-PFM-MTD-007 | structured testing coverage audit | coverage-gap |
FND-PFM-MTD-070 | medium | Manage Shared Forms and Record Layouts has remaining proof obligations across detailed lifecycle, permission, invariant or workflow cases; category and executable gaps are itemized in the evidence. | CAP-PFM-MTD-008, ATS-PFM-MTD-008 | structured testing coverage audit | coverage-gap |
FND-PFM-MTD-071 | medium | Bring a Custom Record Type Into Use has remaining proof obligations across detailed lifecycle, permission, invariant or workflow cases; category and executable gaps are itemized in the evidence. | CAP-PFM-MTD-009, ATS-PFM-MTD-009 | structured testing coverage audit | coverage-gap |
FND-PFM-MTD-072 | medium | Make Custom Records Discoverable has remaining proof obligations across detailed lifecycle, permission, invariant or workflow cases; category and executable gaps are itemized in the evidence. | CAP-PFM-MTD-010, ATS-PFM-MTD-010 | structured testing coverage audit | coverage-gap |
FND-PFM-MTD-073 | medium | Control Custom Record Audiences has remaining proof obligations across detailed lifecycle, permission, invariant or workflow cases; category and executable gaps are itemized in the evidence. | CAP-PFM-MTD-011, ATS-PFM-MTD-011 | structured testing coverage audit | coverage-gap |
FND-PFM-MTD-074 | medium | Maintain Valid Custom Records has remaining proof obligations across detailed lifecycle, permission, invariant or workflow cases; category and executable gaps are itemized in the evidence. | CAP-PFM-MTD-012, ATS-PFM-MTD-012 | structured testing coverage audit | coverage-gap |
FND-PFM-MTD-075 | medium | Retire or Publish Custom Records has remaining proof obligations across detailed lifecycle, permission, invariant or workflow cases; category and executable gaps are itemized in the evidence. | CAP-PFM-MTD-013, ATS-PFM-MTD-013 | structured testing coverage audit | coverage-gap |
FND-PFM-MTD-076 | medium | Explain Custom Record Changes has remaining proof obligations across detailed lifecycle, permission, invariant or workflow cases; category and executable gaps are itemized in the evidence. | CAP-PFM-MTD-014, ATS-PFM-MTD-014 | structured testing coverage audit | coverage-gap |
FND-PFM-MTD-077 | medium | Deliver Committed Record and Link Events has remaining proof obligations across detailed lifecycle, permission, invariant or workflow cases; category and executable gaps are itemized in the evidence. | CAP-PFM-MTD-015, ATS-PFM-MTD-015 | structured testing coverage audit | coverage-gap |
FND-PFM-MTD-078 | medium | Load and Reconcile Record Files has remaining proof obligations across detailed lifecycle, permission, invariant or workflow cases; category and executable gaps are itemized in the evidence. | CAP-PFM-MTD-016, ATS-PFM-MTD-016 | structured testing coverage audit | coverage-gap |
FND-PFM-MTD-079 | medium | Define Meaningful Record Relationships has remaining proof obligations across detailed lifecycle, permission, invariant or workflow cases; category and executable gaps are itemized in the evidence. | CAP-PFM-MTD-017, ATS-PFM-MTD-017 | structured testing coverage audit | coverage-gap |
FND-PFM-MTD-080 | medium | Maintain Dated Links Between Records has remaining proof obligations across detailed lifecycle, permission, invariant or workflow cases; category and executable gaps are itemized in the evidence. | CAP-PFM-MTD-018, ATS-PFM-MTD-018 | structured testing coverage audit | coverage-gap |
FND-PFM-MTD-081 | medium | Preserve Relationships Through Deletion and Merge has remaining proof obligations across detailed lifecycle, permission, invariant or workflow cases; category and executable gaps are itemized in the evidence. | CAP-PFM-MTD-019, ATS-PFM-MTD-019 | structured testing coverage audit | coverage-gap |
FND-PFM-MTD-082 | medium | The cited deployed owner-deletion test exercises a cascade, not a restricting deletion through CRM; the detailed scenario now describes only its existing proof. | ATS-PFM-MTD-019-03, BR-CAP-PFM-MTD-019-03 | deployed owner-deletion assertions | inconsistency |
FND-PFM-MTD-083 | medium | Some existing executable suites, including shared contact-editor measurements, lack a matching detailed or feature scenario; their register entries keep an empty implementation map. | TST-PFM-MTD-011, TST-PFM-MTD-012, TST-PFM-MTD-015, TST-PFM-MTD-021, TST-PFM-MTD-028, TST-PFM-MTD-029, TST-PFM-MTD-030, TST-PFM-MTD-031, TST-PFM-MTD-032, TST-PFM-MTD-033, TST-PFM-MTD-034, TST-PFM-MTD-035, TST-PFM-MTD-038, TST-PFM-MTD-040, TST-PFM-MTD-042, TST-PFM-MTD-046, TST-PFM-MTD-047, TST-PFM-MTD-050, TST-PFM-MTD-054, TST-PFM-MTD-055, TST-PFM-MTD-059, TST-PFM-MTD-061, TST-PFM-MTD-062, TST-PFM-MTD-063, TST-PFM-MTD-066, TST-PFM-MTD-068, TST-PFM-MTD-071, TST-PFM-MTD-079, TST-PFM-MTD-080, TST-PFM-MTD-081, TST-PFM-MTD-086, TST-PFM-MTD-089, TST-PFM-MTD-090, TST-PFM-MTD-091, TST-PFM-MTD-092, TST-PFM-MTD-094, TST-PFM-MTD-095, TST-PFM-MTD-096, TST-PFM-MTD-097, TST-PFM-MTD-099, TST-PFM-MTD-100, TST-PFM-MTD-101, TST-PFM-MTD-102, TST-PFM-MTD-103, TST-PFM-MTD-106, TST-PFM-MTD-111, TST-PFM-MTD-114, TST-PFM-MTD-119, TST-PFM-MTD-121, TST-PFM-MTD-122, TST-PFM-MTD-125 | structured executable mapping audit | coverage-gap |
FND-PFM-MTD-084 | medium | Proposed feature acceptance cases lack executable proof of their complete joint outcome. | FAS-PFM-MTD-01, FAS-PFM-MTD-02, FAS-PFM-MTD-03, FAS-PFM-MTD-04, FAS-PFM-MTD-05, FAS-PFM-MTD-06 | structured feature coverage audit | coverage-gap |
Continuation Findings
| Id | Severity | Statement | Affects | Evidence | Kind |
|---|---|---|---|---|---|
FND-PFM-MTD-085 | medium | Four finding identifiers carry conflicting control-gap and testing-gap descriptions. Their existing records remain intact pending an explicit identity decision; the allocation summary now reserves all existing identifiers. | FND-PFM-MTD-063, FND-PFM-MTD-064, FND-PFM-MTD-065, FND-PFM-MTD-066 | structured continuation evidence | inconsistency |