Client code names supported cost-bearing route or function patterns
ShipReady found supported static client-code references whose names match its bounded cost-class vocabulary.
Why it matters
The result is an informational review list for operations that may deserve access and spend-control review.
How ShipReady detects it
What it inspects
ShipReady combines fetched client script text with page evidence and looks for literal Supabase invokes, Firebase callable names, Supabase function paths, and quoted first-party API or v1 paths matching supported cost-class terms.
What triggers a finding
It triggers when at least one discovered name or path is classified as SMS, email, audio, image, or LLM-related; evidence is deduplicated and capped at 20 surfaces.
What the evidence shows
The evidence proves the listed supported static client-code patterns were present and classified into the reported cost classes.
Limits of this check
Dynamic names, unmatched terms, non-literal calls, and routes without a supported cost-class signal are excluded. ShipReady does not call any discovered function or endpoint.
The check does not prove a route exists, costs money, is public, authenticated, rate limited, reachable, vulnerable, or subject to abuse. It is an informational inventory, not a security verdict.
How to fix it
Review the observed evidence
Use the listed names as a review list for server-side access, rate, spend, and alert controls where they apply.
How to verify the change
Verify the intended behavior
Review the actual handlers and deployment configuration.
Expected: Relevant operations have the intended access and spend controls.