Review code-only candidate surfaces.
This page is for owners handing a suspected “hidden feature” to engineering. A class file can exist without being connected to a menu, URL, scheduled event, or service provider. In that state customers cannot rely on it as product behavior.
A “runtime consumer” is simply live code that calls or registers another piece of code. The candidates below had no such connection in the audited source search.
Current candidates
| Candidate | What the file suggests | Registration evidence in the audited source | Customer guidance |
|---|---|---|---|
| `IntegrationController` | Integration request handling | Only the class’s own file references it | Do not document an integration endpoint or button from this class alone |
| `CrmContactSync` | CRM contact synchronization | Only the class’s own file references it | Use the documented Form-to-CRM path; do not promise this synchronizer runs |
| `ReferralController` | Referral request handling | Only the class’s own file references it | Use the registered referral admin and shortcode workflows |
| `BeltPresetLoader` and `KarateBeltPreset` | Preset belt-system loading | No provider, menu action, or other caller was found | Do not promise a preset import; use Belt Systems’ visible JSON import |
`AttendanceDashboard` is not a candidate: it is wired by `AdminServiceProvider` in the current source. Likewise, the current AI SMS log table is managed by active table/store code; an older migration file is not evidence that the active log is unavailable.
Exact steps
Safe stop: Source inspection and read-only environment verification require no commit button. Stop if no registered entry point reaches the candidate; do not expose or document one by guesswork.
-
Search the current source for construction, dependency-container registration, hook registration, route registration, menu registration, and direct calls to the candidate.
Expected: A usable surface has a caller or registration outside its own class file.
-
Trace that registration to a visible menu, HTTP route, scheduled hook, shortcode, block, or background action.
Expected: The entry point names an effective permission and a callback that reaches the candidate.
-
Verify the entry point in an environment where the same plugin versions and optional dependencies are active.
Expected: The visible entry point exists and reaches the documented result. Do not invent a browser or command-line test when the source exposes no entry point.
-
Record the registration file and source-system result in the support handoff.
Expected: Engineering can reproduce the connection without treating class existence as proof.
Do not expose candidates by guesswork
Do not add a menu, route, hook, or direct database call merely to make one of these classes reachable during support. That is a product change requiring design, authorization, security review, and tests.
Verified against: current cross-reference searches and provider registrations in the checked-out GymCore and GymCore AI source.
Need help?
Describe one problem and the installed versions. Never send passwords, license keys, API keys, payment details, or member records.