[devsimze]

Closes #1232
Closes #1233
Closes #1234
Closes #1235

#1232 — Cumulative Stellar network fee tracking

• Bill payments save the fee Horizon actually charged (Transaction.networkFeeStroops). x402 and MPP settlements don't, because the agent doesn't submit those itself.
• shared/stellar-fee.ts adds up fees for 7d / 30d / all time, with a daily trend. A day counts as a spike when its average fee is at least 2× the median fee for the range (e.g. network congestion).
• getSpendingSummary() returns the totals as networkFees.
• New Stellar Network Fees card on the wallet tab, separate from medication and bill spend, using the same range filter as the other spending views.
• Network fees get their own line in the transaction PDF report, and a Network Fee (XLM) column in the CSV export.

#1233 — Owner approval for sensitive profile changes

• These changes now create a pending request instead of applying: raising any spending limit or budget (including the approval threshold), removing a caregiver, and any wallet auto-topup change. Lowering a limit, and other changes, still apply immediately.
• If a policy update both raises limits and changes other fields, the other fields apply now and the increases wait for approval.
• Only the owner role can approve or reject:
  • /recipients/:id/profile-changes/:id/approve|reject requires the owner-only manage permission (per-caregiver tokens).
  • /agent/profile-changes/:id/approve|reject resolves caregiver_id against the linked caregivers. This follows the same identity approach as approval delegation (Allow a caregiver to delegate approval authority temporarily to a co-caregiver #1195). A recipient with no linked caregivers treats the API key holder as owner.
• DELETE /recipients/:id/caregivers/:id now returns 202 with a pending request. Removing the last owner still returns 409 straight away.
• The auto-topup rule is now stored on the server (GET/PUT /agent/wallet/auto-topup) and only changes once an owner approves.
• Requests, approvals and rejections are written to the audit log (profile_change.requested|approved|rejected).
• New "Profile changes awaiting approval" section in the Approvals tab, and a notice in the policy tab when a change is waiting.

#1234 — Insurance in-network flag

• Caregivers maintain in-network pharmacy and provider lists per recipient: stored in services/care-recipients/db.ts, edited through GET/PUT /agent/insurance-network and a new Settings editor. With no list set, network status is unknown and nothing is flagged.
• compare_pharmacy_prices gives each pharmacy a networkStatus plus networkNote, and adds a network summary. The summary calls out when the cheapest option is out-of-network and names the cheapest in-network one.
• audit_medical_bill / fetch_and_audit_bill add an out_of_network_provider finding: its own finding type, not counted in errorCount, with a full explanation (balance billing, No Surprises Act).
• Explanations are shown as callouts in the medications and bills tabs, not just as badges.
• Fixed: the strict audit_medical_bill input schema rejected provider_id / provider_name, which the tool definition already advertised.

#1235 — "Why did this happen?" reasoning

• At the end of each run, shared/action-reasoning.ts writes a plain-language summary for each significant action: payments (paid, held for approval, blocked, failed), flagged interactions and flagged bill audits. It lists the tools that ran first and the key numbers behind the decision. No raw tool JSON.
• All text is redacted with shared/redact.ts.
• The last 500 summaries are saved through shared/agent-state.ts (the issue mentions agent/agent-state.ts, which doesn't exist) and served at GET /agent/reasoning?transaction_id=&tool_call_id=&limit=.
• Expandable "Why did this happen?" sections in activity-tab.tsx (per transaction) and bills-tab.tsx (per audit and per bill payment).

Fixes to broken main

Earlier merges deleted code that other files still reference, so these modules failed to load:

• services/care-recipients/db.ts: restored the delegation methods, the task methods, CareRecipientEntity and the legacy caregiver-column migration (from 8a3bc6f).
• services/care-recipients/routes.ts: removed a stray half-finished copy of createCareRecipientsRouter and a duplicate import.
• shared/types.ts: restored SpendingPolicySchema and the allergy, bill, pharmacy-price and presence schemas (from d2d4bc8).

Not fixed here: agent/tools.ts on main doesn't parse. payForMedication has an unclosed try (esbuild: Expected "finally"), left by merge 59c4b1f, which also reverted other code; 369e668 is the last commit where the file parses. Any test that imports tools.ts can't load until that's fixed. My changes in tools.ts are type-checked and add no new tsc errors.

Testing

• New tests:

  • shared/__tests__/network-fee-tracking.test.ts
  • shared/__tests__/insurance-network.test.ts
  • shared/__tests__/action-reasoning.test.ts
  • services/care-recipients/__tests__/profile-changes.test.ts
  • services/care-recipients/__tests__/insurance-network.test.ts
  • dashboard/src/__tests__/{network-fees-card,why-did-this-happen,profile-change-approvals}.test.tsx

• Updated caregiver-access.integration.test.ts for the 202 approval flow on caregiver removal.

• Full vitest run:

  	Passed	Failed	Files that fail to load
  main	904	72	69
  this branch	1082	82	54

  The only failures not on main come from persistence.test.ts and timezone-policy.test.ts. Both failed to load on main; they now load and fail on the existing tools.ts parse error above.

[vercel]

@Abidoyesimze is attempting to deploy a commit to the Harrison Eze's projects Team on Vercel.

A member of the Team first needs to authorize it.

[drips-wave]

@devsimze Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

[Abidoyesimze]

@harystyleseze kindly merge!!!!