Code Navigation

Use this page when you have a receiver symptom, public type, or failing test but do not yet know the owning runtime family.

Start From A Public Type

flowchart LR
    symbol["public type or function"]
    api["curated receiver API"]
    owner["private owning subsystem"]
    local["module-level proof"]
    integration["public behavior proof"]

    symbol --> api --> owner
    owner --> local
    owner --> integration

1. Find the export in the curated receiver API.
2. Follow the re-export to its private owner.
3. Confirm whether the name is always available or gated by nav.
4. Read the nearest module tests before selecting an integration target.
5. Check downstream callers before changing public shape or semantics.

Do not add a second public route to avoid this trace. One curated API keeps feature availability and ownership reviewable.

Start From A Runtime Symptom

symptom or question	implementation route	first focused proof
configuration is accepted, rejected, or defaulted unexpectedly	Receiver configuration	configuration module tests, then basic runtime integration
a signal is missed, ambiguously selected, or poorly refined	Acquisition stage	acquisition module tests, then acquisition smoke proof or the matching accuracy/refusal target
carrier, code, lock, or reacquisition behavior drifts	Tracking stage	the narrow matching tracking target, such as C/N0 tracking proof
observations have wrong timing, smoothing, covariance, or status	Observation stage	observation module tests, then measurement-quality proof
optional navigation handoff or report meaning changes	Navigation adapter and validation reports	navigation accuracy budget plus the closest report or refusal target
samples, clocks, or sinks do not behave as expected	Sample adapters and runtime ports	source, streaming, clock, or sink integration proof
a deterministic scenario no longer matches truth	Synthetic runtime	synthetic integration proof plus the affected stage target
supported-signal reporting disagrees across surfaces	Engine support reporting	support inventory proof

Start From A Failing Test

Test names identify the observed contract, not necessarily the root cause:

• Acquisition failures often require checking signal assumptions, front-end rejection, threshold resolution, candidate selection, and uncertainty before changing the assertion.
• Tracking failures may originate in acquisition handoff, signal metadata, channel lifecycle, loop initialization, or fade/reacquisition policy.
• Observation failures can originate in tracking timing or lock evidence before observation construction.
• Navigation and RTK failures may belong to navigation science rather than the receiver adapter.
• Synthetic failures can expose either scenario truth drift or a real runtime regression.

Use the receiver test directory to find the exact target, then trace backward through the stage handoff instead of editing the first matching assertion.

Stop At The Right Boundary

Leave receiver when the root cause becomes reusable signal math, navigation science, repository persistence, command policy, or shared record meaning. Use the Module Map and Integration Seams to identify that handoff before widening receiver internals.