/goal Implement and verify the changes needed to resolve the ELA end-to-end review. Address all functional findings, mobile and operations UI/UX recommendations, incomplete integration paths, and verification gaps.

This is an implementation task. Make the changes and test the resulting behavior. Do not stop after a plan, a code review, or the first few fixes.

Use short, direct sentences in progress reports and documentation. Follow an ASD-STE100-inspired style. Explain technical terms when needed.

1. Establish the baseline

Work from the ELA repository at /Users/stevanl/dev/ela.

Read AGENTS.md, CLAUDE.md, spec/README.md, prd.md, the current canonical backlog, relevant flow diagrams and runbooks, docs/admin/operators-field-guide.md, and current mobile and admin design guidance.

Read these source artifacts under docs/qa/2026-09-05-end-to-end-review/:
- REPORT.md
- FINDINGS.md
- UX.md
- REMEDIATION.md
- COVERAGE.md and coverage.json
- COMMANDS.md and EVIDENCE.md

Use visual-report.html as the reading aid. Use the source reports and current code for implementation decisions.

Record the checkout, branch, commit, local changes, and available environments. Preserve all existing user work. Do not reset, discard, overwrite, or commit unrelated changes. Do not alter the original review evidence.

Revalidate each finding against the current checkout. The review is a baseline, not proof that the code is unchanged.

2. Create a complete work register

Track all of the following:
- Functional findings F1–F12.
- Mobile recommendations M1–M8.
- Operations recommendations O1–O8.
- All 16 remediation backlog items.
- All 138 original coverage records, plus any journeys added or changed.

Link overlapping items to one implementation where appropriate. Keep every original ID traceable.

For each item, record:
- Current behavior and expected behavior.
- Dependencies and decisions needed.
- Implementation status.
- Acceptance criteria.
- Changed files.
- Test and runtime evidence.
- Remaining limitations.

Use explicit statuses: not started, in progress, implemented but unverified, verified, blocked, or superseded with evidence. A blocked or superseded item is not a successful test.

3. Resolve requirements before changing consequential behavior

Reconcile older requirements with current approved decisions. Check dates and supersession notices.

Find the approved policy for:
- Active legacy membership renewal and migration to IAP.
- General Help delivery: call/email or a member inbox.
- SLA treatment of cases with no pickup, cancellation, or stand-down.
- Firm assignment, acceptance, reassignment, and displaced-firm access.
- Retired or deferred portal capabilities.
- Any change to eligibility disclosures or insurance/refund rules.

Use existing decisions where they are clear. Ask a concise question only when a missing decision materially affects implementation. State the options, your recommendation, and the consequence.

Continue independent work while a decision is pending. Do not invent policy or silently remove a capability to close an item.

4. Implement the functional repairs

Use REMEDIATION.md for dependency order. Prioritize emergency reliability, truthful status, and blocked operator actions.

F1: Complete production dispatch and pre-arm composition.
Use durable repositories, workers, provider adapters, and restart recovery.
Preserve the intentional production guard until the complete supported path is proven.
Do not remove the guard merely to make requests or tests pass.

F2: Repair shared confirmation dialogs.
Keep dialog controls usable with mouse, keyboard, and assistive technology.
Maintain background isolation and correct focus restoration.

F3: Make force assignment a real, atomic ownership transition.
Reconcile the requested firm, displaced firm, access, notifications, audit events, and mobile state.
Assignment must not imply firm acceptance.

F4 and F10: Remove invented coverage, takeover, and SLA results.
Derive each displayed fact from the applicable authoritative record.
Closure alone must never create a takeover event.

F5: Repair Help completion, repeated actions, and failure recovery.
Complete the approved response-delivery path.
Distinguish a saved reply from a failed subsequent refresh.

F6: Repair microphone permission recovery.
Test first denial, repeated denial, Settings changes, return to the app, and cancellation.

F7: Correct supported host/origin handling.
Retain the intended origin protections.
Do not generalize a local configuration failure into a production defect without evidence.

F8: Give restricted roles deliberate access outcomes.
Do not return an accidental server error or expose unauthorized data.

F9: Replace the placeholder firm-pause impact result with accurate data or an explicit unknown state.

F11: Reconcile identity, entitlement, policy, verification-window, guarantee, and refund facts across all affected panels.

F12: Make each renewal action match the approved policy.
Preserve duplicate-purchase prevention.

Address shared causes across callers. Avoid screen-specific patches that leave the same defect elsewhere.

5. Implement the UI/UX improvements

Implement M1–M8 and O1–O8 against their recorded acceptance criteria.

For mobile:
- Make emergency status and timelines agree.
- Provide reliable permission recovery.
- Clarify returning-member sign-in and OTP recovery.
- Require the appropriate intentional disclosure action.
- Make renewal guidance accurate.
- Make support channels clear and reachable.
- Simplify phone-number entry and pasted-number handling.
- Measure and correct readability problems where needed.

For operations:
- Separate verified, paid, insured, assigned, accepted, and refundable facts.
- Make consequential dialogs accessible and identify the affected case/member.
- Show stale data and recover from conflicting updates.
- Put urgency, ownership, evidence, and the next action first.
- Distinguish resolved, forbidden, offline, missing, and server-error states.
- Provide usable MFA renewal without losing context.
- Reconcile navigation, available capabilities, and configuration scope.
- Support consecutive Help actions without reloading.

Use the current approved design system. Preserve useful existing structure.
Do not introduce a new visual identity or replace working screens without a task-based reason.

Inspect actual rendered screens. Source changes and fixture screenshots alone do not establish usability.

6. Prove complete journeys

Trace and test:
- Onboarding → KYC → review/resubmission → approval → mobile readiness.
- Purchase → provider confirmation → entitlement → matching mobile and portal status.
- Emergency activation → durable case → dispatch/escalation → operator handling → member updates → closure.
- Member message/support request → operator response → member receipt.

Test production composition in an isolated environment with durable storage and workers.

Exercise:
- Concurrent requests and simultaneous operators.
- Duplicate, delayed, and out-of-order events.
- Provider timeout, retry, and partial failure.
- Late database commits and process crashes.
- Restart and state recovery.
- Websocket loss and polling fallback.
- Backgrounding, app termination, reopening, and reconnecting.
- Session expiry, stale MFA, role restrictions, and changed case ownership.
- Cancellation, deadman, duress, and watch interactions.

Queued, sent, delivered, accepted, protected, and resolved must describe different facts where the underlying states differ.

Do not claim exactly-once provider delivery unless the provider contract supports it. Make retry and deduplication behavior explicit.

7. Validate each change properly

For each implementation slice:
- Reproduce the original defect or document its concrete failure scenario.
- Make the smallest complete repair.
- Add meaningful regression coverage for the failure and important adjacent cases.
- Run the relevant checks.
- Exercise the affected rendered flow.
- Review correctness, permissions, concurrency, persistence, and recovery.
- Record the evidence before marking the item verified.

Inspect check requirements and side effects before running them.

Update stale smoke tests to current approved workflows. Do not weaken assertions, disable gates, or replace integration checks with mocks to obtain a pass.

Run the applicable builds, type checks, tests, browser smoke checks, realtime checks, and readiness gates. Investigate failures. Separate pre-existing failures, environment failures, and regressions.

Test iOS and Android where available. Use physical devices or appropriate native environments for camera, microphone, biometrics, notifications, background behavior, and watch checks.

Use sandbox purchases and controlled test recipients for provider acceptance.
Label evidence as code traced, automated test, fixture-only, local runtime, durable integration, sandbox provider, or physical device.

8. Respect execution boundaries

You may edit implementation code, tests, migrations, configuration templates, and relevant documentation. You may create isolated local services and synthetic test data.

Do not:
- Deploy, merge, push, or commit without separate instruction.
- Trigger real emergency dispatch.
- Contact real members or responders.
- Charge real payments.
- Modify production data or execute production migrations.
- Expose credentials in logs or artifacts.
- Stop unrelated services or delete unrelated data.

Prepare migration verification and rollback instructions where changes require them.

If a service, device, credential, or decision is unavailable, record the exact blocker and continue independent work. Do not substitute fake evidence or mark the blocked check as passed.

9. Deliver the completed work and evidence

Save new remediation records under:
docs/qa/<date>-end-to-end-remediation/

Maintain a concise progress record so work can continue across sessions.

Deliver:
- A status for every original finding, recommendation, backlog item, and coverage record.
- A summary of changes and why they were needed.
- Before/after runtime evidence for important functional and UI changes.
- Commands run, outcomes, and unresolved failures.
- Migration, configuration, and operator-guide changes.
- Remaining decisions and blockers, with the exact next action.
- A new visual HTML report with clear status, priorities, evidence links, and remaining limits.

Validate the new report’s links, filters, counts, and desktop/mobile layout.

Completion requires verified acceptance criteria for all applicable items. Already-fixed or superseded items require current evidence and a clear explanation.

If external blockers prevent full completion, finish all independent work and report the remaining items precisely. Do not declare the app launch-ready while required production, provider, or device evidence is missing.

Finish with the most important remaining risk, the verified improvements for each surface, and an explicit readiness verdict.