, no

, no meta description). It is deliberately cause-agnostic: it would have caught the unterminated sidecar, the absent marker, the orphaned lock and the superseded rebuild equally, on day one. Exit 0 pass / 1 blank / 2 unavailable — never reported as a pass. Verified against production both ways: passes on hour-timebank.ie and timebank.global, and correctly fails on app.project-nexus.ie, which has no snapshots and genuinely does serve crawlers a blank shell. Runs non-blocking after a deploy when NEXUS_DELIVERY_ORIGINS is set in the per-installation env file (hostnames deliberately are not hardcoded in the repo, so a new installation configures its own). ### Fixed - A member who had not opted into federation was told a federated member did not exist. GET /v2/federation/members/{id} gates the CALLER before it looks anything up, refusing a viewer who has not opted in with 403 FEDERATION_NOT_ENABLED. FederationMemberProfilePage mapped every unsuccessful response to member_profile.not_found_error, so that refusal rendered as "Member not found" — sending the member to look for a person who exists, is reachable, and is one switch in their own settings away. The page now keeps the error code and, for that one code, says federation is not switched on for their account, repeats the sentence the disabled buttons already use, and replaces Try Again (which cannot help) with a button to Federation settings. A genuine 404 is unchanged. Adds member_profile.optin_required_heading and member_profile.optin_required_action in all eleven locales. - The federated member profile offered Connect, Message and Send Credits to members whose community safeguarding policy refuses contact, so the member only found out after composing a transfer. The profile payload carried only messaging_enabled and transactions_enabled, both read from federation_user_settings, and the page enabled every action from those two fields alone. A recipient can have both settings switched on and still be unreachable, because the recipient tenant's safeguarding policy is evaluated separately at send time — the live case is a Timebanking UK member with two safeguarding options carrying restricts_messaging, correctly refused with 403 SAFEGUARDING_CONTACT_RESTRICTED. All three buttons are now disabled up front, with the server's explanation shown as visible text beneath them. That text is deliberately not phone-only: walking the page in a browser showed a disabled HeroUI Button computes pointer-events: none, so it never receives hover or focus and its tooltip cannot open at all — the two older reasons on the same row (transactions_disabled_tooltip and optin_required_tooltip) had the same flaw and are fixed alongside it, so every reason an action is unavailable is now readable on any screen. Fixing that also exposed a duplicate: the transfer-reason line fell back to whichever broader reason applied, printing the opt-in sentence twice whenever the viewer had not opted into federation. It now states only the recipient's own transfer setting. Connect is included because FederatedConnectionService::sendRequest() applies the same gate and failed the same way. The server-side checks are unchanged and stay authoritative; this only tells the member sooner. - A refused federated credit transfer said only "Unknown error", hiding the one sentence that explained it. FederationMemberProfilePage discarded the API's error body and always rendered member_profile.tx_unknown_error, so every distinct refusal looked identical: a safeguarding contact restriction on the recipient, a partnership with transfers switched off, a recipient who has disabled federated transactions, and a sender who has not opted in all produced the same dead-end toast. Observed on production sending from TimeBank Ireland to a Timebanking UK member who has two safeguarding options carrying restricts_messaging, where the API correctly returned 403 SAFEGUARDING_CONTACT_RESTRICTED with a member-readable message. The toast now shows the server's message and falls back to the generic string only when the response carries none. The refusal itself is correct and unchanged — this restores the explanation, it does not weaken the safeguarding boundary. - The app failed to boot after every deploy for anyone whose browser had the site installed: the service worker was serving a previous build's index.html, whose asset filenames the deploy had already deleted. Workbox only stores a navigation response as the reusable HTML shell when it carries X-Nexus-Spa-Shell: 1 (cacheableResponse.headers on the NetworkFirst navigation route). nginx.bluegreen.conf declared that marker in location = / and location /, but both blocks end in an unconditional return 421 and the response is generated by the @spa_shell named location — and nginx does not inherit add_header into a block that declares any of its own. The marker was therefore discarded on every request and never reached a browser. Verified on production before the fix: X-Nexus-Spa-Shell absent from https://timebank.global/, the response header set matching @spa_shell's exactly, and the nexus-public-html-shell-v3 cache not present in a real browser after loading the site — only workbox-precache-v2 and nexus-immutable-assets-v1. With the runtime cache permanently empty, precacheFallback handed back the precached index.html of whichever build installed the worker whenever a navigation exceeded the 3-second network timeout, which is exactly what a blue/green switch produces. Old hashed assets hard-404 after a deploy (confirmed against production), so the app could not start and rendered the root error boundary in main.tsx. The marker now lives on @spa_shell, along with the Vary: User-Agent that block also lacked despite serving bots and users different bodies at one URL; the dead declarations are replaced by comments explaining why they were dead. Verified by running the real nginx: nginx -t clean, and X-Nexus-Spa-Shell: 1 present on / and on deep SPA routes, absent from every snapshot and maintenance block. Guarded by npm run check:spa-shell. - Stale-chunk recovery gave up after one attempt, so the deploy crash was shown to the user rather than repaired. requestStaleChunkRecovery allowed a single reload per route per 30 seconds and returned false for anything inside that window. A deploy reliably produces two failures in a row — the reload re-requests the same URL and the service worker hands back the same previous-build shell — so the second failure always fell through to the error boundary. Recovery now allows three attempts, and every attempt after the first deletes the caches that can hold HTML (workbox-precache* and any html-shell) before reloading, forcing the navigation to the network. A hung or rejecting Cache API cannot block the reload: a 2-second timeout guard reloads regardless. The service-worker registration is deliberately left alone — it owns the push subscription. The attempt budget resets after 60 quiet seconds, and the legacy bare-timestamp sessionStorage record is upgraded rather than crashed on, so sessions open across this deploy still behave. Covered by nine tests in src/routes/lazyWithRetry.test.ts. - The platform master tenant was excluded from prerendering entirely, so app.project-nexus.ie — the public front page that lists every community — had never had a single snapshot. PrerenderPlanRoutes carried ->where('id', '<>', 1), skipping master in every route plan ever produced. That hostname takes roughly 156 crawler visits a day and served every one of them the empty SPA shell. Master is now planned like any other tenant, with one deliberate difference: it renders at the app host (FRONTEND_URL), never at its own tenants.domain. Master's domain is project-nexus.ie, which Apache routes to the separate sales-site container — snapshots written under that hostname are read by nothing, and 48 such orphans had quietly accumulated. The reserved-slug guard is skipped for master because it is served at the host root with no slug prefix; without that, renaming master's slug to a reserved word would have aborted route planning for every tenant. Regression test in PrerenderPlanRoutesTest, verified to fail with the exclusion restored. - ROOT CAUSE: the authoritative prerender publish could never complete, so crawler-facing prerendering was off platform-wide from 2026-07-11 to 2026-09-13. The publisher validates each staged page against its checksum sidecar with read -r recorded_hash recorded_bytes < "$checksum". POSIX read returns non-zero at EOF when the final line has no trailing newline — even though it assigned both variables correctly — and prerender-worker.mjs wrote those sidecars without one. Under set -eu the publish therefore aborted on the first page it validated, with no message, no partial state and exit code 1. Because .tenant-identity-v1 is written only at the end of a successful authoritative publish, and nginx fails closed without it, every crawler received the 1,950-byte empty SPA shell: across the whole retained bot-access log, 0 snapshots were served to any bot out of ~4,400 visits. Google indexed hour-timebank.ie with the app's own "Unable to connect" error as its description. The reader now tolerates the EOF status (the malformed/mismatch checks immediately after still reject empty or wrong values) and the worker now terminates the sidecar, matching sha256sum output. - The regression test for that publish existed, passed, and proved nothing — and CI never ran it. scripts/test/test-prerender-authoritative-publish.sh wrote its checksum fixtures with a trailing newline while the real worker wrote them without, so the one byte that mattered was never exercised; and the script was not referenced by any workflow. The fixture now covers both shapes (verified: the test exits 1 with the reader fix reverted, 0 with it), and the test runs as a BLOCKING step in the existing Migration Safety Gate job — no new required job, so the deploy verifier's job list is unchanged. - The prerender health report could not see that prerendering was switched off. nginx fails closed on .tenant-identity-v1: while that marker is absent it serves the empty SPA shell to every crawler regardless of how fresh or complete the snapshots are. Every existing check in PrerenderService::health() measures snapshot production — cache readable/writable, route planning, circuit breaker, queue age, recent failures, stuck jobs, coverage, scheduler liveness — and none measured delivery. The marker was absent in production from 2026-07-11 (commit f62b85fa4, which introduced the gate) to 2026-09-13, and across the whole retained bot-access log zero snapshots were served to any crawler while this endpoint reported green. A new serving_enabled check now reports red, with the exact remedy, whenever the marker is missing — and states that only a full authoritative rebuild writes it, so the condition cannot self-heal, and that the file must never be created by hand because its presence also activates strict missing-sidecar enforcement. Regression tests in tests/Laravel/Feature/PrerenderServiceTest.php, both verified to fail without the check. - /terms, /privacy and /cookies had no meta description, canonical link or Open Graph tags on any tenant that uploaded its own legal document. All three pages branch three ways — loading, tenant custom document, default content — but only the default branch rendered . A tenant with a custom policy took the middle branch, which returned bare, so the page reached crawlers with a title from usePageTitle() and nothing else. AcceptableUsePage has always rendered PageMeta on both branches and was used as the reference. Confirmed against a freshly rendered production snapshot of hour-timebank.ie/terms: Terms of Service, zero description tags, zero canonical tags. Regression tests added to TermsPage.test.tsx, PrivacyPage.test.tsx and CookiesPage.test.tsx, each verified to fail without the fix. - Every tenant domain advertised an empty sitemap to search engines. location = /robots.txt rewrites the platform hostname to the requesting host via sub_filter, but ran with sub_filter_once on. robots.txt opens with the comment # robots.txt for app.project-nexus.ie (React frontend), so the single permitted substitution was spent on line 1 and the Sitemap: directive on line 151 was never rewritten. Every community — hour-timebank.ie, pairc-goodman.com, uk.timebank.global and the rest — therefore told crawlers its sitemap was https://app.project-nexus.ie/sitemap.xml, which contains zero entries, while its own correct sitemap (99 URLs for hour-timebank.ie) went unadvertised. Now sub_filter_once off, so the Sitemap: line and the llms.txt comment lines are rewritten to the serving host as intended. Both nginx.bluegreen.conf and nginx.conf carry a comment pinning the value. Verified by byte count against production: the served file was exactly 4 bytes shorter than the file on disk — one app.project-nexus.ie → hour-timebank.ie substitution, in the wrong place. - Buying an item in the XP shop works again from the app already on members' phones. The purchase endpoint had begun requiring an operation key that only newer clients send, which would have refused every purchase made from a handset until a new store release. The key is now checked when it is sent and never demanded, so purchases that do send one keep their protection against a double tap buying the same item twice. - Android release builds no longer fail on Windows when Node crashes while shutting down after the update-manifest step: the Gradle build now runs Node through a wrapper that exits that one script cleanly the moment its work is done and retries it, bounded, if Node still crashes at teardown (plugins/with-android-node-clean-exit, scripts/node-retrying.cjs). Seen in two of three builds of the first Expo SDK 55 bundle. - A web sign-in page that is out of date no longer answers "Sign-in failed" when the server sends an answer it cannot read: the update reload is applied at once on sign-in, registration, password and two-factor pages instead of waiting for the cursor to leave a field, an unrecognised sign-in answer on a stale bundle says the page was out of date and refreshes it immediately, and a live session ended because the account now requires two-factor authentication is explained as such rather than as an expired session. Seen on the first web sign-in after mandatory administrator two-factor went live. - The Play upload-key signing configuration and the -PplayVersionCode override are now generated into the Android project by a config plugin (plugins/with-android-play-signing) instead of living only in one machine's git-ignored Gradle file, so a bundle built from a clean checkout is signed with the upload key rather than the debug key. - XP-shop purchases from the web app and the accessible site would have failed once the current code shipped. The purchase endpoint started requiring an 8–191 character operation key (c03aeefe6, so a retried request replays the original purchase instead of spending XP twice), but only the native app sent one; the React achievements page and the accessible shop form sent just item_id and would have received 422 on every purchase. Both now send a per-purchase key (the accessible form carries a per-render key per item, and the route mints one if a cached form omits it). Tests: AchievementsPage.test.tsx, web-uk api.test.js and shared-accessible-shell.test.js. Found in the 2026-09-12 review before deployment; production was unaffected. (E-005, O-019; commit 63b5f1134) - Voting on a poll with an option from a different poll, or on a poll whose end date has passed, answered 500 instead of a proper status. PollService::vote() threw InvalidArgumentException('Invalid poll option') and RuntimeException('This poll has closed'); neither PollsController::vote() nor SocialController::votePollV2() caught them, so both cases surfaced as a server error (with the exception class and file path in the body under debug). Both controllers now answer 422 VALIDATION_INVALID_VALUE for a foreign option and 409 RESOURCE_CONFLICT for a closed poll. The closed case is a new typed App\Exceptions\PollClosedException (extends RuntimeException, so nothing that caught the old type breaks); a broad catch (\RuntimeException) was deliberately not used because QueryException is one too. No new translation key — both messages reuse api.invalid_input. Regression tests: four new cases in tests/Laravel/Feature/Controllers/PollsControllerTest.php. Found by the same-community access sweep. (E-003, F-001; commit a49671ea9) - Native ideation submissions, votes, comments, edits and deletions now use synchronous pending guards, preventing rapid taps from dispatching conflicting or duplicate requests before React renders its loading state. Submitted idea, edit and comment fields lock for the duration of their write so a successful response cannot discard changes made after dispatch. - Federation hub, partner-detail, member-card and marketplace-order actions in the native app now use enforced responsive columns instead of compressing controls into unreadable rows. Labels keep a readable size and may wrap to two lines, large-text and narrow-screen layouts become full-width, partner and order chips use the medium size, and federation directory filters no longer cap partner names and translations to one 136dp line. - Android release builds no longer fail when Node crashes while shutting down after the JavaScript bundle step. The same Windows shutdown crash that the build already retried for the update-manifest step was seen in the Metro bundle step, after the bundle and source map had both been written in full. That step is now retried on the same bounded terms; an ordinary bundling failure is still reported on the first attempt rather than repeated, and other commands of the same tool are not retried. - Native goal completion now uses the canonical atomic lifecycle transition, preserving completion history, milestones and XP while making retries side-effect safe. Goal forms and actions prevent rapid conflicting edits. Poll votes now commit with XP, return the committed choice after response loss, reject a changed second choice, and serialize rapid native taps; poll creation locks its submitted draft. - Native paid-course, marketplace, daily-reward, challenge-reward and XP-shop actions now suppress rapid duplicate dispatches. Challenge awards commit with their claim marker, daily and challenge retries return committed results, and XP-shop retries use a durable content-bound identity so response loss cannot spend XP twice. Marketplace shipping no longer offers an ignored method override, and delivery copy now states the actual 14-day dispute period before escrow release. - Native volunteering now preserves expense, donation-pledge and hour drafts across tab changes, warns before leaving with unsaved or pending input, serializes rapid submissions, and retries certificate, expense, pledge and hour writes with the same content-bound operation identity. Laravel durably returns the original record after response loss, preventing duplicate records and duplicate hour credits. - Administrator shift-swap approve/reject decisions now have one atomic winner. Retrying the committed decision succeeds without repeating notifications or assignments, while the opposite decision returns a conflict. - Native organisation settings preserve dirty edits across refresh and tab changes, guard navigation while dirty or saving, and retain rejected clears for retry. Optional description, contact email and website fields can now be cleared through the Laravel update contract. - Native organisation dashboards now keep successful panel data visible when a later applications, hours, volunteers or wallet refresh fails, with a panel-specific Retry warning instead of a false empty state. Hour decisions, wallet inputs and settings fields also lock synchronously while their writes are pending, and the dashboard resets when the account, community or organisation changes. - Volunteer-hours decisions now have one atomic winner across concurrent approve/decline requests. Retrying the winning decision after response loss succeeds without paying twice, while the conflicting decision returns HTTP 409 instead of reporting contradictory success. - Native organisation directory/detail screens now reset on account/community changes and warn when a refresh fails instead of silently presenting stale records. Organisation details map the Laravel volunteer_count and opportunity_count contract, replacing misleading zero member/listing tiles and restoring the missing volunteer total. - Native organisation registration now locks every field and its authority confirmation while saving, serializes rapid submissions, resets on account/community changes, and retries an unknown result with the same content-bound operation key. Laravel stores hashed operation identity so response loss and simultaneous retries return one pending organisation and one owner membership instead of a duplicate-name dead end or duplicate records. - Native job analytics now distinguish a failed prediction request from “not enough data,” offer a direct retry, refresh figures and predictions together, and reset on account/community changes. Prediction totals and comparisons use real tenant-scoped application rows instead of stale stored counters, and leftover English analytics labels are translated in German, Spanish, French, Italian and Portuguese. - Native candidate interview and offer decisions now serialize rapid taps, remain retryable after a failed request, and ignore completions after an account/community change or unmount. Laravel resolves conflicting decisions atomically, permits a response-loss retry of the decision that already won, and rejects the opposite decision. - Job-alert emails now render role type, commitment and closing dates in the recipient's language and regional date format instead of leaking English enum labels and month names. - Job-alert notifications now honour saved category filters and do not match location-specific alerts to vacancies with no location. - Native job-alert creation now locks the draft while saving, resets on account/community replacement, ignores completions from the prior identity, and retries the same intended alert with a content-bound idempotency key; Laravel stores hashed operation identity so lost responses and simultaneous retries return one subscription instead of creating duplicates. - Native job applications now read saved CV and cover-letter details from the Laravel response envelope, show an honest loading state, and expose failed lookups with Retry instead of claiming no saved CV exists. - Job creation retries carry a content-bound idempotency key, and Laravel stores it with the vacancy, so lost responses and simultaneous retries return the original job instead of publishing duplicates. - Job forms reset when the signed-in account or community changes, and completions from the previous identity cannot navigate or show success in the replacement session. - Job forms lock every field, choice and generation action while a save is pending, preventing accepted submissions from clearing edits that were never included in the request. - Job creation and editing prevent repeated save dispatches while a submission is pending. - Delayed AI job descriptions no longer overwrite employer edits or apply after their generation inputs change. - Switching job edit targets loads the correct vacancy and resets the form baseline instead of retaining the previous job's draft. - Job forms track unsaved changes across all fields and treat an unchanged loaded vacancy as clean, including when edits are reverted. - Hiring pipeline stage summaries use full-width rows so enlarged system text has room without relying on live font-scale notifications. - Hiring pipeline stage summaries use explicit container widths to prevent narrow, stretched controls in the native layout. - Job lists calculate application totals in a tenant-scoped batch query so stale stored counters no longer contradict job details and hiring pipelines. - Job detail application counts now reflect actual tenant-scoped applications rather than a potentially stale stored counter. - Mobile hiring pipeline actions prevent rapid conflicting moves for the same candidate while a request is pending. - Mobile hiring pipelines keep withdrawn candidates in their own stage and suppress forbidden actions for accepted, rejected and withdrawn applications, using the server's authoritative stage. - Mobile job candidate cards hide decision actions after acceptance, rejection or withdrawal, matching the server's terminal-status rules. - Mobile job candidate decisions prevent rapid conflicting updates while a status change is pending. - Mobile job applications respect server-derived vacancy availability, including expired deadlines and moderation restrictions, using the same end-of-day rule as submission. - Mobile job application drafts are scoped to the job, account and community, preventing a previous job's covering message or attachment from appearing in another application. - Mobile job application drafts retain their covering message when the sheet is closed and reopened after a failed submission; successful completion clears both message and attachment. - Mobile job owners no longer see an application action for their own vacancy; owner management tools remain available. - Mobile job applications wait for CV selection to finish before submission and recover when the document picker fails. - Mobile job applications lock the submitted message and CV controls while sending and preserve the message after rejection; pending submissions cannot be dismissed or dispatched twice from the form. - Mobile opportunity owners and organisation managers can include a decision note when reviewing volunteering applications. Tenant-required decline notes are explained and enforced before submission; failed decisions preserve the note for retry. - Mobile volunteering prevents conflicting approve/decline requests while an organiser's application decision is pending. - Mobile volunteering isolates application and form state by opportunity so navigating to another opportunity does not carry over a previous submitted status. - Mobile volunteering prevents overlapping shift sign-ups and cancellations while a shift change is being submitted. - Mobile volunteering pauses shift changes when existing registrations are loading or failed, offering retry instead of bypassing the confirmation required to move from another shift. - Mobile volunteering now permits a new application after a previous application was declined or withdrawn, matching the server's eligibility rules. - Mobile volunteering applications now show success only after server acceptance and lock the submitted note while sending, preserving it after failure for retry. - Opening another volunteer QR token resets the check-in confirmation and prevents the previous volunteer's status or delayed response from appearing for the new token. - Volunteer checkout retries return success for the original completed checkout without changing its timestamp or dispatching a duplicate shift-completed webhook. - Native volunteer check-in and checkout offer a same-token retry after temporary network or server failures, retaining the volunteer name and retrying the correct action. - Confirmation actions ignore duplicate events while an action is pending, preventing rapid presses from starting the same operation twice before the button disables. - Android confirmation dialogs disable portal animations that could crash the app when a confirmed action navigated away, including discarding an unsaved course. - Course completion checks the locked enrolment record before running completion integrations, preventing stale repeat requests from counting the same completion twice. - Instructor grading preserves fractional percentage scores instead of truncating them to whole numbers; invalid or out-of-range scores are rejected without replacing an existing grade. - Native course grading pauses score, pass/fail and feedback edits while saving, preserving the submitted draft when a grade is rejected. - Refreshing the native course grading queue preserves unsent feedback and keeps accepted grades hidden; refresh failures appear beside the retained forms instead of discarding them. - Native cross-community credit transfers save their retry key before sending, retain it after request failure, and prevent overlapping submissions or edits during a pending transfer. - Internal cross-community transfers with an explicit retry key retain their committed receipt in the database, preventing cache loss from causing a second debit and rejecting reuse of a key with changed transfer details. The wallet recovery endpoint can confirm these receipts for the original sender and transfer details. - Accepting a connection request no longer hides the member from the Connected tab if the user switches tabs before the request finishes. - Closing or unmounting an open native bottom sheet dismisses its keyboard, preventing it from covering the screen beneath the closed form. - Shared native top-bar labels remeasure after text-size changes, preventing the Back label and screen title from retaining clipped layout bounds. - Bottom-sheet titles and the group discussion helper text remeasure when text size changes, preserving the discussion draft while preventing stale clipped text. - Group discussion actions use full-width rows at larger text sizes to give translated and enlarged labels room to wrap. - The group discussion composer opens at its expanded height so Android keyboard users can reach the message and publishing actions without first expanding the sheet. - An accepted group answer is no longer reported as a failed post when its subsequent detail refresh fails; the question list refreshes and the UI reports the read failure separately. - Group questions and answers pause text editing while submitting, preventing successful saves from clearing newer unsent edits. - Group announcement title, body and pin controls pause during publishing so edits made during a pending save cannot be silently cleared; rejected saves retain the draft for retry. - Group discussion fields pause editing while publishing and unlock after a failed request, preventing successful submission from clearing text entered during the save. - Late native API authentication failures no longer refresh, retry under, or sign out a replacement session. - Native API requests awaiting credential reads are cancelled before dispatch if the session is replaced or cleared, preventing queued actions from using another account's bearer or stale sign-out credentials. - Native wallet reservations stop when the account or community changes during asynchronous recovery, preserving the original account's retry record. - Native wallet retries older than the legacy cache window can now check for a matching durable server record and replay the original key when confirmed. Unknown or unavailable results retain the existing safety block and never create a replacement debit. - Donation retry identities are persisted with the donation ledger, preventing a lost replay-cache result from debiting members twice. Member and community-fund paths retain atomic balance updates. Requires the credit donation retry-identity migration before rollout. - Explicit wallet transfer retries now use a durable receipt committed with the debit and credit, preventing duplicate transfers after replay-cache failure or eviction. Requires the wallet transfer receipt migration before rollout; legacy unresolved transfers and other credit-changing paths retain their existing recovery limits. - Organisation deposit retries now commit a durable receipt with both balances and ledger entries, preventing a replay-cache outage from charging the member twice. Requires the organisation deposit receipt migration before rollout. - Late duplicate wallet success responses no longer erase the saved retry identity of a newer intentional transfer, donation or organisation deposit. - Native text buttons grow to fit wrapped labels at larger accessibility text sizes. Android handles font-size changes without recreating the active screen and discarding its unsaved form state. - Cold native deep links retain the main navigation behind the destination, so Back and Cancel can leave the screen and invoke unsaved-draft confirmation. - Native image placeholders no longer persist when a failed image is replaced with a different URL. Saved event/group image recovery also uses the shared failure placeholder. - Native podcast playback failures now show a retry action and retain the last playback position instead of leaving the player showing Pause after a decoder error. Playback also supplies episode and show titles to native media controls. - Biometric unlock preserves its security boundary on failures. Native sessions stay locked when device authentication or the saved lock preference is unavailable; secure-storage failures no longer report successful enable/disable changes. Locked content is hidden from accessibility services, and hardware/enrolment errors use the existing translated messages. - Native biometric settings explain that the lock protects a saved session, permits biometrics enrolled on the device and may accept the device PIN. Enrolment guidance correctly requires fingerprint or face unlock; all seven native locales include the clarification. - Passkey cancellation and revocation remain under member control. Cancelling platform registration no longer opens a second prompt. Existing credentials remain manageable when tenant passkey sign-in is disabled. - ASP.NET passkeys require local user verification. Registration and sign-in enforce verification before issuing verified-passkey claims, including ceremonies started under the older policy. New credentials must be discoverable. - ASP.NET passkey removal preserves recovery and revokes sessions. Removing credentials cannot consume a passwordless member's final passkey, missing IDs cannot remove every key, and unknown IDs return a truthful failure. Successful removal invalidates access, refresh and security-confirmation tokens. Credential mutations, passkey sign-in and refresh rotation serialize against removal, and compatibility endpoints require security confirmation for enrolment and management. - Updated the ASP.NET WebAuthn verifier to the stable Fido2.AspNet 4.0.1 patch. - ASP.NET enforces the tenant biometric-login switch on registration and authentication, including assertions started before the switch was disabled, while retaining credential management. - Voice-message retries retain their duration. Retrying a failed native voice upload now sends the original recording length instead of zero seconds. - Marketplace media failures keep a recovery path. Saved listings retain failed photo/video operations for retry against the existing listing. Photos are tracked individually so a rejected file is not hidden by a successful batch response. Successful media steps are not repeated, and sellers can explicitly continue to the saved listing. - Saved events and groups retain failed cover images. A failed upload now opens recovery with retry, replacement-image selection and an explicit continue action, without repeating the saved event/group creation. Recovery controls use all seven native language catalogues. - Image recovery respects navigation and large-text attribution. Pending retries keep the recovery screen in place, completed retries do not redirect after unmount, and the native source-repository link wraps within the screen at large text sizes. - Lost photo-upload responses no longer duplicate marketplace photos on retry. Native retries retain an operation key, and the API commits a durable upload receipt with the image rows. Matching replays return the original result, conflicting content is refused, and ownership remains enforced. Requires the marketplace image-upload receipt migration before rollout. - Generated listing descriptions preserve newer edits. Delayed AI descriptions no longer overwrite text entered while generation is pending in native service and marketplace listing forms. - Stale sign-in responses cannot replace the current account. Delayed native password, MFA profile and session-restore responses are ignored after logout or a newer session is installed, including old credential refusals. - Delayed sign-out preserves a newer session. Native logout now stops obsolete cleanup after push unregister, server logout and local storage waits, avoiding deletion of credentials belonging to a subsequently signed-in account. - Late authentication replies preserve the active API identity. Login/logout responses cannot replace a newer bearer token, and mutation requests correctly recognize an isolated refresh-suppression option. - Credential cleanup follows pending writes. Native storage operations now preserve order per key, preventing a delayed write or cached read from restoring a token after logout removes it. - Confirmed wallet payments survive local cleanup failures. A failed secure-storage deletion no longer reports an accepted transfer or donation as failed. Completion is retained so intentional repeats can receive a new durable operation ID while uncertain requests keep duplicate protection. ### Added - Two-factor recovery codes can now be saved. The enrolment screen warns that the codes are shown once, and offers a copy button and a plain-text download built entirely in the page, so the codes are never requested, never logged and never left behind in an address that could be fetched again. The date inside the file follows the member's community region, and the file uses Windows line endings so it stays readable in Notepad. Translated into all eleven languages. - Over-the-air mobile updates are now refused when the native surface (dependencies, Expo plugins, permissions, update channel) differs from the store build members have installed, recorded in mobile/live-store-build.json; verify:release also refuses an Android version code below the live one. Added after the two-factor lockout fix was nearly published as an update that the SDK 54 store build could not have run. - docs/SECURITY-ASSURANCE.md — how security assessment works here, and the register behind it. Project NEXUS hosts communities for public-sector bodies with supplier-assurance obligations, so security work is now a maintained record rather than a series of one-off exercises: a private Security Assurance Register holds every engagement, every finding with a permanent identifier and a status vocabulary that distinguishes "a fix exists" from "the fix works in production", the cross-document reconciliation, and the evidence-freezing rules. The public document describes the process and deliberately carries no findings. The rule that security work must read and update that register is binding in AGENTS.md (MANDATORY RULES) and CLAUDE.md, and SECURITY.md now points a discloser or a buyer at the process. (E-003; commit aa19256b7) - tests/Laravel/Feature/Security/SameCommunityAccessSweepTest.php — can member A reach member B's records inside the SAME community? Every earlier sweep kept actor and record in different communities, where TenantScope does the work; this one asks the question the per-endpoint ownership checks have to answer. Reads: every v2 GET with one path parameter, B's record vs A's own as control; a 200 carrying data must be registered as public by design (exact route, with a reason) or it fails, and B's e-mail address in any body always fails. Writes: every v2 non-GET with one path parameter, body grown from the API's own validation messages, B's row compared column by column after every request regardless of status; a changed or deleted row fails unless only counter columns moved, and a 2xx that leaves B's row alone must be a registered interaction. Consumed fixtures are re-seeded before the next endpoint (a control request is a real request). A third method covers multi-parameter routes (person routes with a third member seeded into both members' records; child routes with B's parent and child): first run 46 combinations probed, 25 refused with a working control, 7 refused at the permission gate, 0 served/accepted/changed. Shared machinery (fixture maps, seeding, id-type resolution, request helpers, multi-parameter enumerators) moved verbatim from CrossCommunityAccessSweepTest into tests/Laravel/Feature/Security/Support/AccessSweepTestCase.php; the cross-community sweep's behaviour and figures are unchanged. (E-003; commits 068dc7551, 95cfeaab0) - Published docs/SECURITY-ASSURANCE.md, a public description of how security assessment works on the platform: what gets tested, how findings are recorded and tracked in the private register, how evidence is handled, and what a customer with a supplier-assurance obligation can ask for. It states process only and deliberately contains no findings. Linked from the documentation index and the published site navigation, with contributor and agent guidance pointing at it so security assessment is maintained as an ongoing record rather than a one-off audit. - Repeatable real-backend MFA journeys for React, the accessible website (with JavaScript disabled), and the Android debug emulator, using dedicated synthetic accounts in the isolated end-to-end database. Browser tests cover enrollment, recovery acknowledgment, recovery sign-in and rejected code reuse; Android additionally checks session restoration after process restart. - MFA recovery and operational tooling. Members can replace recovery codes with a fresh authenticator code and revoke remembered devices from React and accessible security settings. OAuth/SSO sign-in can continue into local MFA without prematurely linking identities or issuing credentials. Read-only security:mfa-readiness inventory and explicitly confirmed security:recover-admin-mfa host recovery commands support rollout and emergency recovery; security changes send recipient-localized notifications. - Native Android/iOS MFA sign-in and required enrollment. Password challenges now open native authenticator or recovery-code verification. Mandatory setup presents the setup key and recovery codes, preserves issued credentials while profile loading is retried, and handles expired challenges without silently refreshing an unrelated session. - Tenant member MFA enforcement with a mandatory platform administrator baseline. The authentication configuration panel now lets tenant administrators require MFA for every member, while the administrator requirement cannot be disabled. Restricted enrollment on React and the accessible website includes QR/manual setup, retries and recovery-code acknowledgment. Server checks cover existing sessions, role promotion and refresh; remembered devices cannot bypass required MFA, and required users cannot disable their factor. Existing passkey configuration permissions remain restricted to super administrators. Deployment activates the administrator baseline and requires the accompanying TOTP migration first. - tests/Laravel/Feature/Security/ExternalSurfaceKillSwitchSweepTest.php — the inbound partner surfaces, enumerated from the route table instead of a list. External partner federation and the partner v1 API are switched OFF in production and have been since 2026-07-27 with no partner connected. Both already have dedicated kill-switch tests and both pass. This adds a sweep because those tests drive hand-written lists, and these are the one authentication path that never runs Authenticate — so they never see the cross-community checks proved in CrossCommunityTokenReplayTest. 69 inbound partner route-and-method combinations: all 69 gated, all 69 refuse with 503 while the switch is off, 0 reached. Surfaces covered: Credit Commons 17, Komunitin 17, Nexus ingest 7, legacy v1 15, partner v1 10, plus external webhooks, aggregates and hour-transfer inbound. Control-verified. "Everything refused" proves nothing if the routes are broken, so the sweep runs again with the switch ON and requires the answer to change; a route that refuses identically either way is reported INCONCLUSIVE, not as a pass. All 69 changed: 62 → 401, 4 → 400, 1 → 404, and 2 → 200. Those two are GET /v1/federation (a list of endpoint names) and /v1/federation/health (status and timestamp) — no member data, and both still behind the switch. 🔴 The population is defined by PATH, not by which middleware is attached — deliberately. Selecting "routes carrying the kill-switch middleware" is circular: a new external route added without the gate would simply not be in the population, and the sweep would report a clean pass over the routes that were already safe. The sweep therefore asserts separately that every route on an inbound partner path carries a gate, against a shrink-only KNOWN_UNGATED list that is currently empty. A new ungated external surface now fails this test on the day it lands. Honest scope note: the existing hand-written lists were not materially incomplete — they cover comparable ground today. What this adds is that the coverage is now derived from the live route table and cannot drift, that an ungated route is detected rather than merely absent, that the refusal is proved to come from the switch, and that federation and partner v1 are checked in one pass. The member-facing /v2/federation/* routes (connections, messages, opt-in, settings) are deliberately excluded: that is internal cross-community federation, live and ungated by design, and it runs Authenticate, so it is covered by the token-replay sweep. - CrossCommunityAccessSweepTest::test_write_endpoints_refuse_a_foreign_id_even_with_a_valid_body — the write sweep's largest blind spot, closed by letting the API write its own request bodies. The write sweep sends an EMPTY body, so 108 of its 366 endpoints were rejected by validation before any community check could run — recorded as unproven, never as passes, and the single biggest gap in the assessment. Rather than hand-writing 108 bodies, the sweep now reads the API's own validation errors, which name the field that failed and often list the values it will accept ("Invalid reaction_type. Valid types: love, like, …"), supplies a plausible value, and asks again — up to eight rounds, stopping the moment validation objects twice to the same field, because that means the value was rejected rather than missing and guessing further would be dishonest. 366 endpoints, 0 MUTATED. Refusals rose 245 → 271, and the unproven bucket fell 108 → 77: 31 endpoints that had never been exercised now are. The 77 that remain need structured bodies (patch, permissions, tiers, a file upload) and are still recorded as unproven. 🔴 The first run of this test scored a flawless 366 of 366 refusals in under six seconds, and it was completely worthless. $e['uri'] already begins with api/, so prefixing another /api requested /api/api/v2/…, which matches no route; every response was a router 404, and a router 404 scored as REFUSED. A dedicated assertion now fails the test outright if any response carries NotFoundHttpException, so this cannot recur silently. Six seconds for what should have been thousands of requests was the only outward sign. - tests/Laravel/Feature/Security/CrossCommunityTokenReplayTest.php — a valid account from one community, used against another, across the whole authenticated API. Every sweep before this one kept the actor and the community aligned (a tenant-2 member asking for a tenant-999 record). None asked the opposite and more dangerous question: what if the CALLER is from somewhere else? That matters more than it first looks, because every community-owned query is restricted by tenant_id = TenantContext::getId() and the community is resolved from the REQUEST, not from the account — so a member of community A whose request resolved as community B would be handed community B's data by queries all working exactly as designed. The protection cannot come from the queries; it has to come from refusing the request. 2,316 authenticated v2 routes swept, 2,303 refused, 0 reached, 13 inconclusive. Every single refusal carried the same code: tenant_mismatch (2,303 of 2,303). The 13 are router-level 404s where the placeholder fails a pattern constraint ({kind}.csv, {providerKey}, {provider}, {action}, {type}) — the same class as the 21 in RoleBoundarySweepTest. Authenticate carries two independent checks — the user's tenant_id, and the token's own tenant_id (which still binds a platform super-admin whose account may legitimately cross communities). Both were already unit-tested in AuthenticateTest; what had never been established is that they cover the whole API, since they live in one middleware and 129 of the 2,503 v2 routes do not run it. 🔴 This sweep proves check (1) only, and says so in the test. The actor is authenticated with Sanctum::actingAs(), so no bearer token is present and the token-tenant check cannot fire. A real issued token was tried first and returns 401 for its own community inside the test harness — an artefact of middleware ordering under the test kernel, not production behaviour. Testing what can be tested honestly beat chasing it. 🔴 The control caught the first version of this test proving nothing. Routes sort alphabetically, so the first 40 are all under /admin/, where an ordinary member is refused regardless of community — every control "failed" and the sweep would have been meaningless. The control now draws only member-facing, parameterless GET routes. - CrossCommunityAccessSweepTest::test_no_endpoint_accepts_a_child_record_from_another_community — the rest of the multi-parameter routes, and eighteen new child fixtures to make them answerable. The companion to the foreign-person sweep: the 116 combinations whose deepest identifier is another RECORD (a lesson in a course, a version of a legal document, an answer to a question). Every identifier except the last is one of OUR OWN records owned by the acting user; only the deepest is another community's. 36 probed, 0 leaked, 0 mutated; 27 refused with a succeeding control (23 member, 4 community admin), 4 rejected by validation first, 5 inconclusive, 80 skipped. 🔴 This could not be bolted onto the existing resolution, and measuring first is what showed it. 84 of the 86 candidate routes resolved BOTH identifiers to the same fixture type, because the child parameter fell back to matching its parent's path prefix — the sweep would have requested courses/5/lessons/5, one row as both course and lesson, and the control would have rejected every one. It would have looked like coverage and proved nothing. CHILD_FIXTURES_BY_PREFIX resolves on the path segment before the parameter and is deliberately SEPARATE from the shared PREFIX_FIXTURES, whose figures are published; {questionId} shows why a shared map could not work anyway — under courses/…/quizzes/{quizId}/questions it is a quiz question, under groups/{id}/questions a group Q&A question. Eighteen child fixtures, each linked by a new needs clause to the parent seeded for the SAME community, so a control uses a child that genuinely belongs to the parent in the URL: course lessons/sections/cohorts/quizzes/questions, group discussions/chatrooms/chatroom-messages/announcements/questions/answers/files/media/invites/challenges/scheduled-posts, podcast episodes, legal documents and their versions. insertRow() gained needs, an optional owner column, a conditional tenant_id (legal_document_versions has none — it is scoped through its parent document by join, which is what LegalDocumentService does), a {today} placeholder, and a unique clause that reuses an existing row (legal_documents is unique on (tenant_id, document_type) and every seeded tenant already holds a terms row). 🔴 A CONTROL REQUEST IS A REAL REQUEST, and one destroyed the preconditions of the endpoints after it. Endpoints run in sorted order, so the control for DELETE .../versions/{versionId} genuinely deleted our own version and the controls for PUT, notify and pending-count on the same record then answered "Version not found" — three endpoints falsely INCONCLUSIVE. The identical trap hit the person sweep via group membership. Both sweeps now re-establish state per endpoint: this one re-seeds when recordsStillExist() says a needed row was consumed, which also makes it order-independent. Member refusals went 15 → 23 and the admin pass 1 → 4 from that fix alone. 🔴 A disabled feature module is not a pass. The courses module is off for the test community, so twelve course endpoints answered 403 FEATURE_DISABLED to probe AND control. A gate firing first says nothing about community scoping, so the sweep enables courses and podcasts for both communities via tenants.features. What it still does not reach: 80 combinations, 32 of them under events. Those are the registration-product, offline check-in and guardian-consent families, whose tables require twenty-odd NOT NULL columns of tokens, hashes and ciphertext each; a hand-built row would not represent real state. Recorded as untested rather than fixtured badly. - CrossCommunityAccessSweepTest::test_no_endpoint_accepts_a_person_from_another_community — the multi-parameter routes, which no sweep reached before. The two sweeps above take routes with exactly one path parameter. 141 route-and-method combinations take two or more, and none of them had been exercised — including admin/groups/{groupId}/members/{userId}/promote, conversations/{id}/participants/{userId} and events/{id}/people/{userId}/history. That is where a scoping bug survives review, because the handler checks the FIRST id against the caller's community and forgets the second. The outer record is deliberately OURS and legitimate; only the person is foreign. 25 combinations name a person ({userId}, {childId}, {attendeeId}, {guestId}, {delivererId}, {partnerId}, …); every other parameter is filled with a tenant-2 record owned by the acting user. 17 probed, 0 leaked, 0 mutated; 6 refused with a succeeding control (3 as member, 3 as community admin), 7 rejected by validation first (not a pass), 4 inconclusive, 8 skipped. The detector is stronger than the single-parameter write sweep's, by design. That sweep compares the target row and states plainly that rows CREATED ELSEWHERE are invisible to it — which is precisely this sweep's subject, since "add this person to my group" writes a join row rather than altering the group. So this one counts, before and after every request, every row in the live schema referencing the foreign person across 302 person-shaped foreign keys. A count that moves in either direction is a confirmed cross-community write. The community-admin pass is fully conclusive: 3 probed, 3 refused, control-verified, 0 inconclusive — group member removal, promote and demote. GroupService::updateMemberRole() scopes its group_members lookup by tenant_id, so a person outside the community has no row and the operation refuses. 🔴 A test-ordering bug in the first version made seven results falsely inconclusive. Endpoints run in sorted order, so the control request for DELETE .../members/{userId} genuinely removed the control person from the group, and every later control then failed with NOT_MEMBER. The relationships are now re-established idempotently before every endpoint, not once per pass. Nothing about the platform was wrong; the sweep was. 🔴 group_members carries is_federated and source_tenant_id, so a member row pointing at a user in another tenant is a DESIGNED federation state. Do not extend this sweep by planting a foreign user in group_members and calling a successful promote a finding without reading the federation rules first. What is tested is narrower and sound: a person with no relationship to our record and no presence in our community must be refused. Verb-shaped parameters ({action}, {state}) are recognised as operations rather than records, locally to this sweep so the other two sweeps' published figures are unaffected. - tests/Laravel/Feature/Security/PrivilegeFieldInjectionTest.php — a member sends role: admin, both super-admin flags, tenant_id: 999, a wallet balance, is_verified and id alongside a legitimate field on PUT /v2/users/me; every privileged column is read back with the query builder and must be unchanged. Passed first time: UserService::update() whitelists thirteen profile fields. The first thing a tester tries on a profile form, now pinned. - CrossCommunityAccessSweepTest::test_no_write_endpoint_mutates_another_communitys_record — every non-GET single-parameter v2 route (796 route×methods, 691 routes) with a tenant-999 record id and an empty body, as a tenant-2 member and a tenant-2 community admin. 366 probed, 0 mutated the foreign record (snapshotted before/after so "accepted" and "changed" are not confused), 245 refused, 108 rejected by validation first (recorded as VALIDATION_FIRST — not a pass), 10 accepted no-ops pinned in KNOWN_ACCEPTED_NO_CHANGE. The first run listed 18 accepted writes; eight were fixed the same day (see Security). 🔴 {day} is a day of the week, not a record id. PUT users/me/availability/{day} resolved by path prefix to a member_availability row id, accepted it as a day number and answered 2xx — an eleventh accepted-no-change write. It failed only on a CI shard: the local run had failed to seed that fixture and skipped the endpoint, so the sweep was green locally and red in CI. day is now named in NOT_AN_ID, which is what moves the probed count from 367 to 366. - Two route-table security sweeps, written for the Coventry City Council assurance request and kept as permanent regression tests. TenantIsolationTest covers three resources by hand; the v2 API registers 2,507 routes, 1,308 of which take a record id, so hand-written coverage was never going to keep pace. Both tests enumerate Route::getRoutes() at runtime so a new endpoint is covered the day it lands. Per-request evidence (statuses, control statuses, response-body excerpts) is written to .local-docs-archive/security-evidence/ (gitignored). tests/Laravel/Feature/Security/RoleBoundarySweepTest.php — every route reserved for a higher tier, requested by each of five actors with every declared method. anonymous 2,375 → 0 reached; member 1,121 → 0; broker 959 → 0; community admin 62 → 0; network admin 37 → 0. 4,554 requests, 0 reached a controller; 21 inconclusive (router-level 404s where the placeholder 1 fails a {provider} / {kind}.csv / {action} constraint — the gate was never exercised, so they are listed, not counted). 🔴 A 422 is a REACHED, not a refusal. Form validation runs after route middleware, so a member sending an empty body to an admin write endpoint and getting a validation error proves the gate did not fire. 🔴 Gates are read from Router::gatherRouteMiddleware(), not Route::gatherMiddleware(). The declared stack still lists a gate that ->withoutMiddleware(...) removed. The first version read the declared stack and reported the broker reaching /admin/listings (declared admin, effectively broker-or-admin — the broker's own panel) and the anonymous caller reaching /blog (declared auth, effectively public) as 48 breaches. None were. The first run did not disable rate limiting and the platform answered 429 to 2,097 of 2,397 anonymous requests after roughly 300 — recorded in the assessment as an observation that throttling engages; the test now removes ThrottleRequests because rate limiting has its own tests. tests/Laravel/Feature/Security/CrossCommunityAccessSweepTest.php — every single-id GET endpoint whose record type can be resolved, requested with a tenant-999 record, in two passes: as a tenant-2 member for member routes and as a tenant-2 community ADMIN for /admin/ routes. 371 endpoints in population, 220 probed, 124 refused, 0 returned another community's member data; 30 answered 200 with an empty body (correct); 62 inconclusive; 151 skipped (44 because the parameter is a slug/token/type, 102 because no fixture, 5 platform-tier routes covered by the role sweep). 🔴 Every refusal is control-verified. Each probe is paired with the same request for a same-type record in tenant 2 owned by the actor; a refusal counts only if the control returned 200/201. Without this, volunteering/shifts/{id} mapped to a VolOpportunity id "passes" with a 404 that means nothing. The control caught a wrong mapping during development — ideation-challenges is served by IdeationChallengesController, not the gamification Challenge model — which is exactly why it exists. 🔴 A 200 is classified by reading the body. The status-only first version flagged 19 endpoints; 16 were correctly scoped empty lists. Id type is resolved from the parameter name first ({userId}, {childId}, {caredForId} → user; {groupId}, {eventId}, {courseId}, {message}), then the longest matching path prefix (volunteering/organisations → VolOrganization, admin/newsletters/segments → NewsletterSegment). Slugs, tokens and type names are SKIPPED as "not an id", never probed with a number. Modules with no factory (courses, marketplace_listings, stories, podcast_shows) get a direct row insert filling only NOT NULL columns. KNOWN_SOFT_200 holds four reviewed endpoints that answer 200 for a foreign record while disclosing nothing — connections/status/{userId}, jobs/{id}/match, users/{id}/activity/dashboard, and (admin actor) admin/users/{id}/verification-badges. Each records the body read and the date. They should 404. Shrink-only in both directions. Found in passing, not fixed here: VolShiftFactory writes updated_at and vol_shifts has no such column; ResourceItemFactory likewise against resources. Both factories cannot create a row. - Members are now asked whether they want notifications. registerForPushNotifications() took its prompting argument as opt-in and only the Settings switch passed it, so on iOS and Android 13+ the system permission dialog was never raised in the ordinary flow: a new member signed up, was never asked anything, and silently received no message, exchange-request or event notifications unless they found the switch. A card on the feed offers it once. Either answer is stored, because the OS cannot tell "tapped Not now" from "never asked" — both read as undetermined — so a permission-only rule would re-offer on every launch. - A Vibration switch in Settings, and the app stops buzzing on everything. The shared button fired a haptic on every press of every variant, and toasts and confirmations added their own, so plain navigation buzzed as hard as sending credits. The button impact is now limited to the primary and destructive variants, and the new switch silences all three kinds of feedback for members who do not want them. - Picked photos are shrunk before upload. Every picker passed quality only, which re-encodes without resizing, so a 12-to-48-megapixel camera photo left the device at full size — several megabytes against an 8 MB server limit and a 60-second timeout. On mobile data the member waited out the minute and was told the upload had failed. Capped at 1600px on the longest edge (2048 for marketplace listings). Adds expo-image-manipulator, so this needs a new store build. A PNG stays a PNG, so a transparent organisation logo does not gain a black background. - Loading lists show the shape of what is coming. Notifications, marketplace, volunteering, jobs and the wallet transaction list showed a centred spinner on a blank screen while five other tabs already had card skeletons, so the same wait looked slower on half the app. - mobile/docs/PLAY_RELEASE_PROCEDURE.md — how a build actually reaches Google Play, written from an end-to-end release rather than from memory. PLAY_SUBMISSION.md covered signing, listing copy and assets but not the act of shipping, so the order of operations lived only in the owner's head and an agent shipped straight to production without it. Every timing and fingerprint in the document is measured. The order is internal testing → phone → promote. Not production first. Play's live version code is the only source of truth. Measured 2026-09-09: Play was on 7 while EAS's remote counter said 4, so an EAS build with autoIncrement would have produced 5 and been rejected outright. The counter is stale because releases are built locally, which never touches it. Review took 33 minutes (submitted 7:32 PM, published 8:05 PM), against a dialog that warns of up to 7 days. With managed publishing off, submitting for review is the decision to go live. Internal testing and a production review can run at once — verified, not assumed: version 8 was submitted to production at 7:32 PM, published to internal testing at 7:47 PM, and the production submission published normally at 8:05 PM. Also records the two non-interchangeable certificates, the silent debug-signing fallback, the emulator-address landmine, the single-architecture trap, and the fact that navigating during a 90 MB upload aborts it with no error. Three documents still listed "correct the false no-money claim in the Play description" as the top release blocker. Reading the live listing shows it was fixed some time ago — neither description contains that wording. Corrected in all three, with a note to read the live fields before re-raising it. - mobile/scripts/build-aab-play.sh — the signed Play bundle now has a checked-in recipe. There was none: build-apk-local.sh builds a deliberately debug-signed APK for sideloading, and the artefact actually uploaded to Google was assembled by hand each time. Three ways that goes wrong silently, all of which produce a file that looks completely normal, are now refusals rather than warnings. A debug-signed bundle. android/app/build.gradle:133 reads release { signingConfig playStoreFile ? playRelease : signingConfigs.debug } — with the signing values absent Gradle does not fail, it signs with the debug key and still writes app-release.aab. The script reads the key and its passwords from mobile/credentials.json (never echoing them) and verifies the finished bundle's certificate against the Play upload key before reporting success. 🔴 The wrong server baked in. .env.production.local was found holding EXPO_PUBLIC_API_URL=http://10.0.2.2:8090 — the address an Android emulator uses to reach the build machine, left behind by a test build on 2026-09-03. That value is compiled into the bundle permanently. A release built from it works flawlessly on an emulator and is dead in every real user's hand. The script regenerates the file and refuses any loopback, private-network or plain-http host. One CPU architecture. expo run:android writes reactNativeArchitectures= into android/gradle.properties; a later release build inherits it. On 2026-08-20 that shipped an x86_64-only artefact — perfect on the emulator, "App not installed" on a real phone. All four are passed explicitly. It also requires --version-code rather than defaulting, because Play refuses a version code it has already seen. ### Changed - Android version code 11: the store release carrying the minified, resource-shrunk build. The version name stays 1.5.0 because no native dependency changed between the two builds — only how the release binary is compiled — so the over-the-air runtime version stays compatible with the build already on phones. This is the release that answers Google Play's "DEX code optimization is below our threshold" warning against version code 10. - Native app version 1.5.0, Android version code 10: the store release carrying the two-factor sign-in and the Expo SDK 55 upgrade. The bump also gives the build a new over-the-air runtime version, so an update built for SDK 55 can never be served to the SDK 54 build 9 still installed on phones. - The member directory's explanation of why it lists fewer people than have joined the community is now a single collapsible line. It shows the count on one row with a "Why?" control, and only opens the visibility rules, the closing note and the privacy-settings link when a member asks for them. As an always-open alert it pushed the first row of member cards below the fold on desktop and took several lines on phones. - The member directory now states its size once. The hero's member-count chip and the "Showing 24 of 25 members" line have gone: with the collapsible coverage note above them, the page carried three counts of almost the same thing, two of which used "of" to mean different things. The count while searching stays, because a match count is real information, and the Load more button already says how many members remain unloaded. - Android release builds are now minified and resource-shrunk (R8). Google Play reported "DEX code optimization is below our threshold — Obfuscation (2%)" against version code 10, with a February 2027 deadline. Minification had never been switched on: the Expo build-properties block set only legacy packaging, so the generated Gradle properties carried no minify setting and the release build compiled unobfuscated — which is also why every upload reported "no deobfuscation file associated with this App Bundle", because R8 never ran and there was no mapping file to include. The keep rules the app actually needs are checked in at mobile/android-proguard-rules.pro and carried into the generated Android project by a config plugin, since that project is regenerated on every build. Each rule cites the dependency and call site that requires it, and the file records which dependencies already ship their own so nothing is duplicated; notably expo-notifications ships a rules file that its own Gradle configuration never applies, and react-native-gesture-handler ships none at all while two packages look its classes up by name. The build script now refuses a bundle that carries no R8 mapping file, and the release-config check refuses an app configuration that has lost either flag or the rules plugin. - ASP.NET edition paused (owner decision, 11 September 2026) — not abandoned; it resumes when the rest of the platform is more mature. The four ASP.NET jobs in the platform-contracts workflow are pinned off so no runner minutes are spent on them, the ASP.NET markdown-link pass is removed from the shared inventory job, and AGENTS.md, react-frontend/CLAUDE.md, docs/REACT-DUAL-BACKEND.md and the ASP.NET README state the pause at the top. Code, ledger and earlier decision records are untouched; ADR-0005 records what was switched off and how to resume. - Updated the native app to Expo SDK 55 and React Native 0.83, including the system-appearance API adjustment and explicit background audio configuration. - Native voice messages, podcasts and lesson/marketplace video now use Expo's separate audio and video modules. Audio loading has a bounded timeout and cancellation on leaving the screen; podcasts seek to their saved position before playing and activate lock-screen controls. Voice recording prevents overlapping starts while permission is pending and late starts after leaving the screen. - Updated the web passkey client to @simplewebauthn/browser 14.0.0, retaining the platform's existing Node 22 minimum and Laravel credential algorithms. - 🔴 The mutation detector had three blind spots, all now closed and all now proved closed by a test that tries to fool it. An external review of the assessment identified them, and it was right on every one. Every sweep in this file reports "0 mutated", and that number is worth exactly as much as the detector behind it. A mutation was classified only when the response was 2xx, so a write that changed another community's record and then returned an error escaped the detector entirely. Now classified from the record comparison alone, with the status reported alongside rather than gating it. An exception skipped the after-snapshot altogether, so a request that changed something and then threw was filed as merely inconclusive. The record is now read again on the exception path too, in both the write and person sweeps. The person sweep compared row COUNTS, so changing somebody's role in a group — same row, same count — was invisible. It now fingerprints row contents (count plus a hash), and columns that cannot be read are counted and reported as blind spots rather than silently dropped (currently 0 of 302). The leak detector scanned the 300-character excerpt kept for the report rather than the full response body. It now scans the whole body. New: test_the_mutation_detector_sees_changes_it_is_supposed_to_see. The inverse of every other test here — it deliberately causes a field change, a deletion, a side row created elsewhere referencing the person, and a content change that leaves the row count identical, and fails if the detector misses any of them. A detector nobody has tried to fool is an assumption, not a control. After hardening, every sweep still reports 0 mutated. The stricter detector did not reveal anything the weaker one had missed — which is the reassuring outcome, and now it rests on something demonstrated rather than assumed. - The pre-commit hook gained a third gate: the native push producer inventory. When app/**.php is staged it runs audit-native-push-producers.php --check in the app container — about a second — and blocks with the exact --write command if the inventory has gone stale. Added because that inventory pins NotificationDispatcher call sites by file and line, so any edit adding or removing lines above one makes it stale even when no producer changed, and that reds PHP Tests (shard 1), PHP Checks and Release Gate together. It happened twice on 2026-09-10, the second time to someone who had already written the trap down in a handoff. Skips with a notice when Docker or the container is unavailable, as gate B does for phpunit; CI remains the backstop. Verified by deliberately shifting a call site and confirming the commit was blocked. - The mobile Create Course, Create Job, Create Opportunity and Podcast Studio forms are laid out like Create Listing. The owner named Create Listing as the form that looks right and the others as "really badly formatted": a single undivided column of up to twenty fields, a save button buried in the middle of a card, and no summary of what has been chosen. Each now opens with a hero card (module icon, eyebrow, title, one-line purpose, and summary tiles that echo the choices as they are made), groups its fields into titled sections with an icon (components/ui/FormSection), and keeps its primary action in the sticky footer that Create Listing and Create Event already had. Course titles that are missing are now also flagged under the field, not only in a toast that fades. ### Fixed - Native wallet and message recovery. Transfers, donations and organisation deposits persist unresolved retry identities in encrypted storage across screen closure and app restart, scoped to account and community. Failed messages preserve the next draft and its attachments separately, with an unsent-draft switcher and navigation protection. - Native message editing preserves unsent work. Opening an older message for editing retains the current draft and photos in the unsent-draft area. Edit switching and cancellation are unavailable while a send or edit save is pending. - Native interaction and startup polish. Shared HeroUI buttons, tabs and interactive chips use 48dp targets; Messages has a compact header. Public configuration and preferences migrate from SecureStore to files, credential-write failures prevent false sign-in success, and browser-only Sentry replay is excluded from native bundles. iOS camera descriptions cover both QR journeys, and API/parity checks include MFA routes. - Native audit follow-through. Authentication screens suppress internal server exceptions and display source attribution, achievement navigation wraps into readable rows, and decorative status badges disable their press responders. API and parity check mode no longer rewrites generated evidence files. - Preserve pending two-factor enrollment when retrying setup, support the intended authenticator clock tolerance, and retain trusted-device choices through the accessible website. React now returns to sign-in after two-factor removal revokes the current session. - 🔴 The mobile API-consumer ledger was stale, and a flaky test had been hiding it. mobile/ pins a fingerprint of routes/api.php and verifies that every endpoint the app calls still exists. Adding the partner-analytics rate limit changed that file, so npm run drift:check failed with "nothing was verified. This is NOT a pass." — the correct answer, and a good gate. It surfaced only after the jest flake below was fixed, because jest runs first in the same job and its failure stopped the job before drift:check ran. One red check can conceal another in the same job. Refreshed with npm run api:routes: 2,240 API paths, 514 of 514 consumed endpoints verified, and the only diff is two fingerprints and two review dates — no endpoint was added or removed, because the change added middleware rather than a route. - A flaky mobile test that turned main red without any mobile code changing. PushPermissionCard.test.tsx — "does not send the member to system settings when registration merely failed" — failed once on a CI Android job (1 of 3,854 tests) on a commit that touched only routes/api.php, the changelog and a PHP test. It passes repeatedly on the developer machine. handleEnable() awaits two promises — the registration call, and the storage write recording that the member has now been asked — before it hides the card, so the default waitFor window is tight on a loaded runner. The component is deterministic (a failed result always hides the card), so the wait was widened to 5s rather than the behaviour changed, with the reasoning recorded at the assertion. - The native push producer inventory is current again (239 calls, unchanged in content) — twice. It went stale a second time when the poll-vote fixes added lines to PollsController and SocialController, and was caught by CI rather than before the push, even though this exact trap is recorded in the working handoff. 🔴 Any edit above a NotificationDispatcher call in a tracked file reds PHP Tests (shard 1), and through it PHP Checks and Release Gate. Worth a pre-commit gate: the check is php mobile/scripts/audit-native-push-producers.php --check and takes about a second. - First occurrence, same cause. The security fixes above added lines to ConnectionsController, StoryController and StoryService, which moved four NotificationDispatcher call sites down by a few lines. The committed inventory pins file-and-line ids, so NativePushProducerInventoryTest failed on CI shard 1 — no producer was added or removed, only the line references were stale. Regenerated with mobile/scripts/audit-native-push-producers.php --write. Worth knowing: any edit above a NotificationDispatcher call in a tracked file reds this gate. - 🔴 The Android build on Google Play could never have received an over-the-air update. Found while trying to send one: the version code 8 bundle carried no update channel (Expo's cloud builds get it written in; our locally built Play bundle gets it only from app.json, which set none) and a runtime version of 1.2.0 inside an app labelled 1.4.0 (the build script only regenerated the native project when the folder was missing, so an August value was reused). Either fault alone means the update service serves that build nothing. app.json now bakes the production channel into every build, the build script regenerates the native project every time, and it opens the finished bundle and refuses it if the channel or the runtime version is wrong. Version code 9 is the first build that can take an update; the fix cannot reach phones still on 8 or earlier. Confirmed on a real phone the same day: build 9, installed from Play, showed the app's "Update ready" prompt for the first update ever published, which is the first over-the-air update this app has received. - 🔴 Option pickers on eleven mobile screens were about 20dp tall and did not visibly show the chosen option. Create Job, Create Course, Podcast Studio, Create Event, Create Group, Create Marketplace Listing, Edit Listing, the support contact form and three marketplace filter bars all built their category / level / type / sort pickers on HeroUI Native's TagGroup size="sm", whose selected state is a pale tint — over which every one of them painted the label contrastText(primary), white on most communities, so the chosen option was white text on a pale wash. Measured on a device: below the WCAG 2.2 minimum target and less than half Android's guidance. Create Listing never had the fault because it used HeroUI Native Buttons. That idiom is now the shared components/ui/ChoiceChips (44dp minimum, full accent fill when chosen, label colour picked by the library for the community's accent, wraps to new rows, announces selected to screen readers), used everywhere, and components/choiceChipsMigration.test.ts keeps TagGroup out of the app so the small picker cannot come back one screen at a time. - 🔴 The Goals "Add goal" drawer could not be scrolled and had no buttons. Reproduced on the emulator after the owner reported it: the drawer opened with the keyboard on the title field, the description and target fields sat underneath the keyboard, and Cancel / Create goal were not on screen at all — HeroCard.Footer has no row layout, so two flex-1 buttons in a column collapsed to zero height. There was no scroll container either. Three Podcast Studio drawers, the job application drawer and five marketplace drawers had a plain React Native ScrollView instead, which HeroUI Native's own documentation says the drawer intercepts, so dragging moved the drawer and never the content. The shared BottomSheet now takes scrollable (renders the gorhom scroll view the drawer does not swallow) and footer (actions pinned above the keyboard and home indicator; on Android the wrapper measures the keyboard itself, because neither the window nor the drawer moves for it under this app's root). Twenty-two drawers migrated. components/ui/sheetContentRules.test.ts fails on any React Native scroll view inside a drawer and on any drawer holding a text field that is not scrollable. - 🔴 Form fields were hidden behind the keyboard on iPhone, on fifteen screens — including the wallet transfer amount and the marketplace offer amount, where the member could not see the figure they were entering before sending credits or money. Android is protected by the manifest's adjustResize; iOS has no equivalent and each scroll view must make room itself, which is why the gap survived every Android device test. app/keyboardAvoidance.test.ts now scans every screen with a text field. - 🔴 Paged lists could show a row twice or lose one, and the warning that would have revealed it was switched off. usePaginatedApi appended pages without de-duplicating, so cursor pagination over a list the server re-orders handed React two children with the same key. Both of React's duplicate-key warnings were in LogBox.ignoreLogs, which is why it went unnoticed. The hook de-duplicates; the suppressions are gone, along with the nested-list one, which was checked rather than assumed to be needed. - 🔴 Large system text clipped the tab bar and could squeeze a screen title's own Back button off the row. The app had no font-scale handling anywhere. Caps are applied only where the container cannot grow — 1.6 for single-line chrome, 1.3 for tab labels, whose bar height now grows with the same capped scale. Body text is deliberately left uncapped. - 🔴 The iOS permission explanations described a narrower app than the one we ship, which Apple's guideline 5.1.1 checks against the running app: the camera text named only marketplace codes though it also scans event check-in codes; the photo-library text said "profile or post" though photos are picked for listings, events, groups and marketplace items, and videos are picked too; the location text named only the marketplace though the Listings tab uses it as well. - A cold start showed three screens instead of one. expo-splash-screen was not installed, so the native splash hid as soon as React rendered — and the first thing React renders is a bare spinner. The splash is now held until the redirect has landed, with a five-second backstop and a release from the crash boundary so nothing can strand a member on it. The splash also gains a dark-mode background and stops letterboxing on other aspect ratios. - "You're offline" now appears on every screen. The banner was mounted by hand on fourteen screens out of a hundred and seventy; on the rest a lost connection was indistinguishable from a server fault. It is mounted once in the shell and adds its own measured height to the safe-area inset, so it never covers a screen's own content. - Every external link now opens through one checked helper. Linking.openURL was called from twenty-two files; six had no error handling at all, so a device with nothing able to open the link produced an unhandled rejection and, to the member, a button that did nothing. One opened an empty string when a parcel had no tracking link, and two opened a member-typed website with no scheme check. - A picture that fails to load no longer leaves a blank hole. No image in the app had an onError, so a photo that 404s rendered as a blank rectangle the size of the picture. Seventeen server-image sites now use the component written for this. - Harmless questions were being asked in red. The confirmation dialog defaulted to the danger variant, so enrolling on a course, confirming a purchase or a delivery, completing a group exchange, sending credits and even unblocking somebody all asked with a red button. - Numbers now read the way the member's language writes them. Ratings and file sizes were built with toFixed, which always produces a full stop, so a French or German member saw "4.5" among numbers that otherwise read "4,5". - A screen reader can jump by heading. The app had twenty heading roles in total and the screen title was not one of them anywhere; one line in the shared top bar covers 134 screens. - The same screen no longer looks different depending on how you reached it. Groups and members are reachable at two routes that present them differently, and links were split between the two. - A half-filled seller profile now asks before it is lost — four steps of business details with nothing between a stray Back gesture and losing all of it. - 🔴 Android App Links have never verified, because assetlinks.json published the wrong certificate. The file listed F5:0D:87:55…, which is the upload key — the one used to sign what we send to Google. Play App Signing is enabled, so Google re-signs the app with its own key (79:38:E8:06…), and that is the fingerprint a phone checks. Every https://app.project-nexus.ie/… link therefore opened a browser or a chooser for everyone who installed from Play, while app.json's autoVerify: true half looked correct. Both fingerprints are now published — Google's app signing key first, the upload key retained so a locally signed release build verifies too. Confirmed against the Play Console's own ready-made snippet, which names the app signing key. verify-release-config.mjs already anticipated this in a comment and accepts multiple fingerprints; it passes. - 🔴 Sign-up reported one mistake at a time and would not say which box it meant. RegistrationService::register ended its validation at $validator->errors()->first() — a single string with no field — and RegistrationController::register passed null as the field, so a member who got their email, phone and password wrong was told about one of the three, in a banner, across an eight-input form. Every failure is now returned, each naming the input it belongs to, through respondWithErrors(). The native app already places a message on whichever field the API names and simply had nothing to place. Backwards compatible by construction. The first entry keeps the code and message the single-error response carried, because both first-party frontends branch on errors[0].code to tell TERMS_REQUIRED and LOCATION_NOT_VERIFIED from a generic failure. Those two special cases no longer hide the other bad inputs, though — they lead, then the rest follow. The single-error refusals that belong to a visible input now name it too: duplicate account and the two email-domain checks → email, breached and mismatched passwords → password / password_confirmation, invite-code failures → invite_code. Raw latitude/longitude rows are deliberately dropped, being fields no member can see or correct. Prevention: two tests in RegistrationControllerTest assert every failed input is present and attributed, and that the special-cased code still leads. A control run confirms both fail against the old code — one because only a single error came back, the other because the terms branch hid the email failure. No new translation keys: the fallback reuses the existing api.validation_failed. - Two volunteering lists could only ever serve their first page, so the app has no "Load more" on either. Certificates: VolunteerCertificateService::getUserCertificates() has always paginated and always returned a cursor, but VolunteerCertificateController::myCertificates() called it with no filters and so threw the caller's page request away. It now reads cursor and limit, accepting per_page as an alias because that is what the app already sends. The { items, cursor, has_more } shape is unchanged — both the app and CertificatesTab.tsx read data.items. Shift swaps: ShiftSwapService::getSwapRequests() returned everything it found behind a hard limit(50) with no cursor at all. It now takes limit (default 20, max 50) and a cursor. Ordering moved from created_at to id, both descending: a cursor on created_at cannot be stable, because two requests made in the same second tie and a tie makes rows repeat or vanish between pages. The endpoint answers through respondWithCollection(), so data stays a flat array — what VolunteerShiftSwapsResponse already expects — and the cursor rides in meta. 🔴 Found while doing it: filtering swaps by direction has never worked from the app. It sends direction=sent / received; the service only tested for incoming / outgoing, so both fell through to the catch-all branch and returned every swap in both directions. The service now accepts the app's vocabulary alongside the original, which fixes it without needing a new store build. - 🔴 scripts/release.mjs corrupted react-frontend/package-lock.json when cutting v1.8.0, and turned main red. It bumped the version with a blind 1.7.0 → 1.8.0 string replace across every file carrying the version, and the lockfile carried that string in twenty-one places that had nothing to do with the platform version: esquery's own version (there is no esquery@1.8.0), the ^1.7.0 ranges for @emnapi/runtime and es-module-lexer, and seventeen Node engine ranges, where ^21.7.0 silently became ^21.8.0. Every job that runs npm ci then died with ETARGET No matching version found for esquery@1.8.0 — all eight React shards, React Build & Tests, Translation Drift Detection, the Release Gate, Security Scan, Lighthouse CI and the Platform-contracts React job. Four red workflows, one cause. Root cause: a blind string replace applied to dependency manifests. It had only ever worked by luck — no earlier platform version happened to collide with a dependency's, and 1.7.0 is a very common third-party version. The lockfile is repaired to the two root version keys only, so npm ci resolves again. Prevention: manifest versions are now set by key, never by text — scripts/lib/set-json-version.mjs writes .version and .packages[""].version and leaves every other byte alone, re-serialising with the file's own indentation (npm writes 2 spaces, composer 4) so a release diff stays reviewable. scripts/test/test-release-manifest-rewrite.mjs pins it in both directions, with decoys for each of the four collision shapes; it fails 4/4 against the old string replace. It is BLOCKING in CI (npm run test:release-manifest) and runs in local preflight. - scripts/release.mjs could not finish a release, because it ran the semver gate one step too early. It wrote all thirty-six version files, then ran check-semver-policy.mjs before committing and tagging — and that gate asserts every release at or above its 1.7.0 enforcement floor has a vX.Y.Z tag. The tag cannot exist yet at that point, so the check failed by construction, the script exited without committing, and the release had to be completed by hand. It was latent until now: 1.7.0 was tagged before it became the floor, so 1.8.0 was the first cut to hit it. Root cause: a tag-dependent check placed in a pre-commit self-check block. check-version-consistency.mjs (tag-independent) still runs there and still blocks the commit; check-semver-policy.mjs now runs after the tag, and on failure prints the git tag -d / git reset --soft undo pair rather than leaving the state unexplained. Prevention: --no-tag and --no-commit now say in words that the semver gate did not run and what to run once the tag exists, instead of reporting checks as passed when one was skipped. ### Changed - 🔴 CrossCommunityTokenReplayTest now exercises the REAL login credential path, because its previous claim about how authentication works was wrong. An external review of the assessment caught it and was right. Authenticate reads foreach ($request->bearerToken() === null ? $guards : [] as $guard), so the two tenant checks inside that loop run only when a request carries no bearer token — on the production login path, which always carries one, that branch never executes and the token-tenant check inside it is unreachable. The isolation on the real path is enforced by TenantContext::resolve(), which validates the JWT's signature and compares the community inside it with the community requested, exempting platform administrators. The test now mints a token exactly as login does (TokenService::generateToken($userId, $tenantId)), proves it works against its own community first, then replays it. 2,316 authenticated v2 routes, 2,316 refused, 0 reached, 0 inconclusive — every refusal attributed, not assumed: the mismatch handler is the only thing that sets the resolved community to 0, and the 13 routes whose URL pattern makes them raise rather than return carry the TENANT_MISMATCH code in the thrown body. Control: 6 of 25 sampled member endpoints served the token in its own community, reported as measured rather than rounded into an impression of universal success. 🔴 A second invented explanation is also corrected. The previous version said a genuinely issued token failed "because of middleware ordering under the test kernel". That was a guess written up as fact. The real reasons: user-login personal access tokens were deliberately retired (the middleware docblock says so, and refuses them so an old seven-day token cannot bypass JWT lifetime and revocation), and TenantContext::resolve() reads $_SERVER directly while the test harness clears it. Both verified in code. Platform-tier prefixes are excluded from the population and the document now says so: the total is of selected routes, not of every route. ### Security - Two volunteering endpoints could echo raw database error text to the caller. Recording an offline donation (POST /v2/volunteering/donations) and submitting an expense (POST /v2/volunteering/expenses) mapped every RuntimeException to a 400 that repeated the exception message. Laravel's QueryException is a RuntimeException, and both services rethrow it when the request carries no idempotency key, so a database failure (reachable in practice only through a same-key race) would have answered with the full SQL statement, its bindings and the connection name. Both controllers now answer a generic 500 SERVER_ERROR and log the detail server-side. Regression test: tests/Laravel/Feature/Security/VolunteeringDatabaseErrorDisclosureTest.php. (E-005, F-016; commit a304ef718) - A member could rebuild and download their personal-data export without limit by replaying an idempotency key. The 5-per-24-hours cap counted only new audit rows, and a replayed Idempotency-Key writes none, so every replay rebuilt the archive with no bound and the admin GDPR notice fired once. Every build now also counts against a per-member daily limit, replays included. Regression test in tests/Laravel/Feature/MemberDataExportTest.php. (E-005, F-017; commit 453aeaa27) - The SVG logo sanitiser closes two bypass classes. A CSS escape (\75rl( reads as url( to the browser) slipped past the forbidden-token check in