MEMBERS-DIRECTORY-001O — Preserve visibility-toggle focus after authoritative settlement

IMPLEMENTATION_PLAN.md

@@ -191,6 +191,8 @@ Exit gate:
 
 **MEMBERS-DIRECTORY-001N current source boundary:** [#645](https://github.com/Run-MPRC/Run-MPRC.github.io/issues/645) changes only confirmed upload and removal keyboard focus in the preserved connected Account branch. A pending confirmed-photo intent is created only after request-ID creation and `startMutation('upload'|'remove')` admit the exact current operation into `pending`, and only while the exact **Save profile photo** or **Remove current saved photo** initiating action owns focus. It contains only the mounted application-and-account lifetime, exact operation symbol, and upload-or-remove action. A successful mutation plus current successful authoritative readback transfers only the matching lifetime, operation, and action to the result ref for one ready render. Upload keeps the persistent Add/Replace file input as its destination; removal keeps the existing surviving Remove, exact current ready Save, then persistent file-input priority. The already-focused destination is left alone; body, document-root, absent, or disconnected focus returns to that destination; and any other connected focus deliberately chosen during mutation or readback keeps focus. Programmatic or outside-focused invocation, request-ID failure, failed mutation admission, definitive rejection, unknown outcome, failed readback, application or account change, unmount, and stale completion create no intent or clear or fail the guards. #643 rejected-removal behavior, #637 Reload recovery, confirmations, exact calls, bytes, revisions, draft behavior, and existing fences remain unchanged. Focus creates no request ID, callable, retry, mutation, draft, data URL, confirmation, audit, provider action, or data action. Availability stays `false`, so the default branch and live #623 preview remain inert. #645 changes no data movement, page structure, Account wiring, People finder, visibility setting, service contract, Function, Rule, index, schema, package, workflow, backend, provider, account, sign-in, production data, deployment, biometric processing, or connected/live behavior. #507 still owns privacy approval, scoped authorization, isolated staging, backend-first deployment/readback, the reviewed availability flip, connected publication, and live proof.
 
+**MEMBERS-DIRECTORY-001O current source boundary:** [#647](https://github.com/Run-MPRC/Run-MPRC.github.io/issues/647) changes only visibility-mutation keyboard focus in the preserved connected Account branch. After request-ID creation and admitted `startMutation('visibility')`, the component records one pending intent only when the exact officer-finder checkbox owns focus, and the intent contains only the mounted application-and-account lifetime and exact operation symbol. Confirmed success plus a current successful authoritative profile read, or definitive rejection plus a current successful confirming read, transfers only the matching intent, and one matching ready render consumes it. Body, document-root, absent, or disconnected focus returns only to the same connected and enabled checkbox; an already-focused checkbox is left alone; any other connected focus deliberately chosen during mutation or readback keeps focus; and an ineligible returned off checkbox consumes the result without focus because it is disabled. Programmatic or outside-focused invocation, request-ID failure, failed mutation admission, unknown outcome, failed readback, application or account change, unmount, and stale mutation or readback completion create no result or clear or fail the guards. #637 Reload recovery, #643 rejected-removal focus, #645 confirmed-photo focus, native pending disablement, errors, confirmations, exact calls and revisions, and existing fences remain unchanged. Focus creates no request ID, read, mutation, retry, audit, result, draft, photo byte, data URL, provider action, or data action beyond the already admitted operation. Availability stays `false`, so the default branch and live #623 preview remain inert. #647 changes no data movement, element structure, page topology, Account wiring, People finder, service contract, Function, Rule, index, schema, package, workflow, backend, provider, account, sign-in, production data, deployment, publication, biometric processing, or connected/live behavior. #507 still owns privacy approval, scoped authorization, isolated staging, backend-first deployment/readback, the reviewed availability flip, connected publication, and live proof.
+
 ### Phase 5 — End-to-end qualification
 
 **Issue:** TEST-001 plus final closure evidence from all prior phases

SECURITY.md

@@ -110,6 +110,7 @@ These entries are implementation evidence, not a production risk-acceptance deci
 | Source-only search-focus containment for RISK-042 | MEMBERS-DIRECTORY-001L [#641](https://github.com/Run-MPRC/Run-MPRC.github.io/issues/641) gives the preserved connected People finder one exact-operation focus intent after a valid query and request ID admit `pending`, and only when the persistent name input or Search button owns focus. Current result-card, empty-result, and fixed-failure settlement consumes the intent after render. The already-focused origin is left alone; body, root, absent, or disconnected focus returns to the same now-enabled origin; and another connected element focused during the request retains focus. Programmatic or outside-focused submit creates no intent. Editing, Clear, local validation failure, request-ID failure, application or administrator change, unmount, and stale resolution or rejection clear or fail the guards. Generated-only tests cover both origins and all three outcomes, deliberate outside focus, retained-origin focus, local failures, Clear, context changes, unmount, one exact request, and the unavailable default. | Programmatic focus is accessibility state, not authorization, search correctness, provider acknowledgement, audit proof, membership evidence, or live behavior. It stores no query, name, result, photo, account ID, request ID, or service value and creates no request ID, search, retry, Clear action, result, audit, service call, or data URL. Existing response/privacy bounds and name-only search plus human comparison of voluntary thumbnails remain unchanged; never add a photo query, face recognition, matching, embedding, similarity, biometric processing, totals, export, or roster authority. The source-controlled availability value stays `false`, and live #623 remains inert. No data movement, page structure, service/server contract, Function, Rule, index, Firebase or provider configuration, account, sign-in, production data, deployment, or connected/live behavior changes. #507 still owns notice/retention approval, scoped authorization, protected authority, isolated staging, backend-first deployment/readback, the availability flip, connected publication, and live proof. Use no real name or photo. |
 | Source-only rejected-removal focus containment for RISK-042 | MEMBERS-DIRECTORY-001M [#643](https://github.com/Run-MPRC/Run-MPRC.github.io/issues/643) gives the preserved connected Account branch one exact-operation pending focus intent only after request-ID creation and admitted `pending` removal, and only when **Remove current saved photo** owns focus. A definitive rejection plus current successful authoritative readback transfers the matching pending intent to the result ref for one ready render. The destination is a surviving Remove action, otherwise the enabled Save action for the exact current ready draft, otherwise the persistent file input for no, reading, or not-yet-ready draft. Body, document-root, absent, or disconnected focus returns to that current destination; an already-focused destination is left alone; any other connected focus selected during pending is preserved. A surviving Remove alone describes the fixed rejection. If Remove disappears, the fixed alert stays standalone and is not attached to Save or the input. Generated-only tests cover all destinations, native focus eviction, retained and deliberate outside focus, request-ID failure, both readback-failure classes, application/account changes, unmount, zero extra calls, and the unavailable default. | Programmatic focus is current-interface accessibility state, not provider acknowledgement, deletion proof, reconciliation, authorization, audit evidence, or proof that the rejected removal succeeded. The focus intent contains only the mounted application-and-account lifetime and exact mutation-operation symbol, with no photo bytes, profile, request ID, revision, provider value, or error, and creates no request ID, callable, retry, mutation, draft, data URL, confirmation, audit, provider action, or data action. Existing confirmed-success and #637 Reload focus behavior remains. The source-controlled availability value stays `false`, and live #623 remains inert. No data movement, page structure, service/server contract, Function, Rule, index, Firebase or provider configuration, account, sign-in, production data, deployment, or connected/live behavior changes. #507 still owns notice/retention approval, scoped authorization, protected authority, isolated staging, backend-first deployment/readback, the availability flip, connected publication, and live proof. Use no real name or photo. |
 | Source-only confirmed-photo focus containment for RISK-042 | MEMBERS-DIRECTORY-001N [#645](https://github.com/Run-MPRC/Run-MPRC.github.io/issues/645) gives the preserved connected Account branch separate pending and result confirmed-photo focus refs. Only a successful request-ID creation followed by admitted `pending` upload or removal may record an intent, and only while the exact **Save profile photo** or **Remove current saved photo** initiating control owns focus. The intent contains only the mounted application-and-account lifetime, exact operation symbol, and upload-or-remove action. A successful mutation and current successful authoritative readback transfer only a matching lifetime, operation, and action for one ready render. Confirmed upload targets the persistent file input. Confirmed removal retains the existing surviving Remove, exact current render-ready Save, then persistent file-input priority. Body, document-root, absent, or disconnected focus returns to the current destination; an already-focused destination is left alone; every other connected focus selected during mutation or readback is preserved. Generated-only tests cover both actions, all removal destinations, native focus eviction, redundant-focus avoidance, deliberate outside and in-profile focus, programmatic invocation, request-ID failure, definitive rejection, unknown and readback failure, application/account changes, unmount, one-shot consumption, exact call/byte/revision behavior, and the unavailable default. | Programmatic focus is current-interface accessibility state, not provider acknowledgement, upload or deletion proof, reconciliation, authorization, audit evidence, or connected-live proof. The focus intent stores no name, profile, revision, request ID, photo bytes, data URL, provider value, response, or error and creates no request ID, callable, retry, mutation, draft, data URL, confirmation, audit, provider action, or data action. #643 rejected-removal focus/error ownership and #637 Reload recovery remain separate. The source-controlled availability value stays `false`, and live #623 remains inert. No data movement, page structure, People finder, visibility behavior, service/server contract, Function, Rule, index, schema, Firebase or provider configuration, account, sign-in, production data, deployment, biometric processing, or connected/live behavior changes. #507 still owns notice/retention approval, scoped authorization, protected authority, isolated staging, backend-first deployment/readback, the availability flip, connected publication, and live proof. Use only generated non-face test images; never add a photo query, facial recognition, matching, embedding, similarity, biometric processing, roster authority, or membership proof. |
+| Source-only visibility-focus containment for RISK-042 | MEMBERS-DIRECTORY-001O [#647](https://github.com/Run-MPRC/Run-MPRC.github.io/issues/647) gives the preserved connected Account branch separate pending and result visibility focus refs plus the exact persistent officer-finder checkbox ref. Only successful request-ID creation followed by admitted `pending` visibility may record an intent, and only while that checkbox owns focus. The intent contains only the mounted application-and-account lifetime and exact operation symbol. Confirmed success plus a current successful authoritative profile read, or definitive rejection plus a current successful confirming read, transfers only a matching intent, and one ready render consumes it before checking the destination. Body, document-root, absent, or disconnected focus returns only to the same connected and enabled checkbox; retained checkbox focus is left alone; another connected outside or in-profile focus is preserved; and an ineligible returned off checkbox consumes the result without focus because it is disabled. Generated-only tests cover requested on, requested off, changed-again state, definitive rejection and error association, native focus eviction, redundant-focus avoidance, deliberate connected focus, programmatic invocation, request-ID failure, unknown and both readback-failure paths, name-ineligible disablement, application/account changes, unmount, stale mutation/readback completion, one-shot consumption, exact call counts, and the unavailable default. | Programmatic focus is current-interface accessibility state, not provider acknowledgement, saved-setting proof, mutation correctness, reconciliation, authorization, audit evidence, membership proof, or connected-live proof. The focus intent stores no query, name, profile, revision, request ID, result, error, provider value, photo byte, or data URL and creates no request ID, read, mutation, retry, audit, result, draft, photo byte, data URL, provider action, or data action beyond the already admitted operation. #637 Reload recovery, #643 rejected-removal focus, and #645 confirmed-photo focus remain separate. The source-controlled availability value stays `false`, and live #623 remains inert. No data movement, element structure, page topology, People finder, service/server contract, Function, Rule, index, schema, Firebase or provider configuration, account, sign-in, production data, deployment, publication, biometric processing, or connected/live behavior changes. #507 still owns notice/retention approval, scoped authorization, protected authority, isolated staging, backend-first deployment/readback, the availability flip, connected publication, and live proof. Use no real name or photo; never add a photo query, facial recognition, matching, embedding, similarity, biometric processing, total, export, roster authority, or membership proof. |
 | Immediate Product-binding containment part of RISK-031 | PAY-PRODUCT-001A is tracked in live [#353](https://github.com/Run-MPRC/Run-MPRC.github.io/issues/353). One dependency-free projection is used by the paid race and Shop checkout paths. A present stored Product link must be an own primitive non-empty string from 1 through 255 JavaScript code units and is copied without trimming, conversion, character restrictions, or `prod_` inference. Only a genuinely missing own field retains the compatibility Product-create path. Before any mapping write, a resolved Product must provide a bounded custom ID, exact Product kind, expected declared mode, and an installed-SDK 2xx response marker. Malformed stored links stop before token, registration/order identifier, Product-link or business-record write, or Stripe work; earlier access and request-count checks and their safety-counter writes may already have run. Malformed created results stop after at most one Product attempt but before mapping, Checkout Session, or business-record writes. | This structural containment does not prove provider origin, Stripe account ownership, intended catalog identity, metadata binding, Product status, price, dispatch, delivery, or reconciliation. A rejected create result may leave an orphaned Product; do not retry automatically. Anonymous clean-missing creation remains concurrency-prone and reachable from public traffic. Complete #113 inventory/disposition, authenticated idempotent catalog synchronization, Product-specific plan/pre-send/result/lost-acknowledgement/reconciliation controls, isolated staging, protected Firebase deployment, and provider proof before live commerce. |
 | Immediate current-handler containment part of RISK-003 | PAY-SESSION-001A is tracked in live [#357](https://github.com/Run-MPRC/Run-MPRC.github.io/issues/357). The current paid race and Shop handlers build one immutable expectation before the Session call, catch rejection without opening it, and immediately project only a closed installed-SDK result. A result must match declared test/live mode, payment/open/unpaid state, exact cents, USD, buyer email, exact closed metadata, exact callbacks, a mode-compatible bounded Session ID, one canonical HTTPS capability at the hard-coded default `checkout.stripe.com` origin, and an installed-SDK 200 marker. Only copied ID/URL values continue; records store the ID but never the URL. Invalid results create no registration/order record and return one fixed unknown-result message. The website makes rejection or a missing paid URL terminal for that page visit, retains the form, and blocks a second direct handler call. | This is a narrow legacy compatibility stop, not trusted provider/account origin, deterministic business idempotency, dispatch/delivery proof, durable result evidence, payment proof, or adoption of the unused C4 chain. The Session call occurs first, so a rejected result may leave a payable orphan; earlier rate-counter, token/identifier, and lazy Product-mapping effects may remain. Reload, another tab/device, or a scripted caller bypasses the page lock. A configured Stripe custom checkout domain is blocked until #113 and a protected configuration boundary approve it. Complete PAY-002C/D persistence-first sagas, trusted C4 controller/result persistence, reconciliation, protected staging/deployment, provider readback, and exact website/Firebase/live proof. |
 | Immediate pre-render browser containment part of RISK-003 | PAY-SESSION-001B is tracked in live [#503](https://github.com/Run-MPRC/Run-MPRC.github.io/issues/503). Each current public race and Shop page now keeps one component-local in-memory marker. After existing local checks admit a request, the handler sets that marker synchronously before analytics or its first Checkout promise can settle. A same-action or later submission on that mounted page is inert, including the gap before React renders the existing pending disabled button. Focused actual-route tests prove one service/analytics attempt across same-action and post-render repeats; preserve free-participant, volunteer-without-price-tier, and both paid-link navigation branches; and prove local waiver/native-disabled paths do not consume an attempt. | This browser marker is not a server boundary, durable idempotency key, provider dispatch/result record, business-state lock, payment proof, or reconciliation. It never releases during the mounted page visit because the admitted result must navigate or enter #357's terminal unknown-result state. Existing form controls other than the submit button remain editable. Reload, a remount, another tab/device, a script, or a direct service caller can bypass it. A same-mounted route change instead stays locked, and this slice does not fence an older pending result from that changed route. Complete PAY-002C/D persistence-first deterministic commands, durable replay/reconciliation, protected deployment, and exact website/Firebase/Stripe/live proof. |