Review code-only candidate surfaces

Review code-only candidate surfaces.

Status: source-reviewed Section: Reference

Search documentation

Type to search.

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.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

Contact GymCore