A read-only diagnostic pass collects evidence without altering the setup. It is useful when the cause is unclear or several people have already suggested different fixes. Establishing the current state first makes later changes easier to assess and reverse.
The goal is not to inspect every available screen. Choose observations that distinguish the likely layers: device platform, player version, active source, affected content type and exact result. Keep private credentials out of routine notes and screenshots.
Start with one reproducible action
Choose a specific task such as opening one known entry or viewing a dated guide window. Record what should happen and what actually happens. “The app is slow” is a broad impression; a named action with an observable delay or error gives the investigation a clearer boundary.
Also establish scope. Does the result affect one entry, one source, one profile or every part of the interface? Working comparison examples are useful evidence, but they do not prove unrelated features are correct. Keep each observation limited to what was actually checked.
Collect without modifying
Do not open private URLs in unrelated tools merely to make the diagnostic feel more complete. Every extra recipient or context should answer a relevant question. A local status screen may be sufficient for the initial finding.
- Record the genuine app identity, installed version and device platform.
- Identify the active source, profile and relevant view.
- Repeat the chosen action once and preserve the exact non-secret result.
- Inspect documented status information without changing account fields.
- Summarize what the evidence narrows and what remains unknown.
Separate observation from proposed fixes
A guide with no events after Friday establishes a coverage observation if that range was inspected. It does not establish that reinstalling the app will help. State the finding first, then choose a change that addresses the identified layer.
If another person later takes over, this baseline explains which state they inherited. It can prevent two helpers from changing different settings simultaneously and attributing the result to the wrong action. A short clear record is more useful than a long unstructured dump.
For support, provide the baseline, exact symptom and any safe comparison evidence. Label untested possibilities honestly. The useful outcome is a narrower question and a justified next action, with the original configuration still available for a controlled comparison.
Useful answers
Does a read-only pass mean opening every private endpoint in every tool?
No. Collect only evidence relevant to the defined question.
Why record the starting state?
It makes later changes and handover easier to assess.
Does one working comparison prove the entire setup is correct?
No. Keep each observation within its actual scope.