Personalization, Diagnostics, And Cross-Device Reliability Update

The last update introduced a major expansion in how Apex Infinity can present live information. Core had gained a direct glasses display path, Wrist standby behavior was becoming measurable, and replay continued to give the platform a shared way to validate device behavior.

Since then, the focus has shifted from adding individual capabilities to making those capabilities work together as a dependable system.

Companion can now express more of the user's intent. Core can preserve and act on that intent. Wrist can show more of what Core and connected equipment are actually doing. Diagnostics can retrieve complete evidence instead of only showing a short snapshot. Replay transfers are more defensive about interruptions. And storage cleanup is becoming a deliberate recovery workflow instead of an all-or-nothing action.

This is the less visible work that turns a collection of features into a product. The devices need to share state, preserve ownership, recover cleanly, and explain what happened when something goes wrong.

Personalization now reaches all the way to Core

One of the clearest changes is that Companion can now configure the color Core uses for its normal status light.

That preference is not only a temporary app setting. Companion encodes it with the rest of the synchronized device preferences, Core validates and stores it, and the status-light policy applies it during normal operation. The result is a small but meaningful step toward making each Apex Infinity setup feel personally identifiable without changing the colors reserved for warnings and other important device states.

The same end-to-end approach now supports active camera profiles.

Companion can hold the user's camera selections and associated behavior, then send the active profile information to Core through the existing preference path. Core preserves those settings across restart and uses them as the source of truth when camera coordination is enabled. The current implementation concentrates validation on one active camera connection, while keeping the preference shape ready for a broader device mix later.

Companion's existing callout editor also received a smaller reliability improvement. Closing and reopening the editor no longer leaves its temporary state in an inconsistent lifecycle. That is not a headline feature, but it is part of the same product standard: preferences should be predictable whether they control a light, a spoken prompt, or connected equipment.

Camera behavior became visible instead of assumed

Earlier camera work proved that Core could send recording commands while preserving its normal telemetry responsibilities. The latest work closes a more important confidence gap: knowing whether the camera is actually recording.

Core now uses the selected camera profile to discover and connect to the configured camera during the appropriate operating window. It can observe the camera's reported recording state, including recording started manually on the camera, and carry that confirmed state through the existing Core-to-Wrist telemetry path.

Wrist now turns that shared state into a compact status indicator on both display families. A configured camera can appear as waiting, connected, recording, or needing attention. Recording uses a blinking red indicator so it is visually distinct from a camera that is merely connected and ready. The indicators are designed to remain visible across the standard layouts without taking over the primary display.

That distinction matters. A command being sent is not the same as the intended action occurring. By showing confirmed state, Apex Infinity can help the user see whether the camera is ready and whether recording is active without treating a successful command write as proof.

The engineering path to that result also became more disciplined. A dedicated camera probe was used to characterize the relevant BLE behavior before the production firmware depended on it. Core's camera component now separates device-specific recording behavior from the higher-level coordination policy, which gives future camera integrations a clearer place to live.

Camera activity is also bounded more carefully. Automatic coordination is gated by the configured location and activity state, and a post-completion delay can keep recording active for the desired window before Core requests a stop. The purpose is not to create a permanent camera connection. It is to coordinate the camera around the period when it is useful, then release that connection cleanly.

Diagnostics grew from snapshots into complete evidence

The previous diagnostics work made Core's reset reason, event tail, system-log tail, and recent runtime breadcrumbs visible over BLE. That was a major improvement over trying to reconstruct a reboot with no monitor attached, but a short tail can only answer so much.

Core can now offer a controlled list of diagnostic files and transfer them in acknowledged pages. Each page is tied to an expected position, and the receiver confirms it before Core advances. Retries and duplicate acknowledgments are handled explicitly, which makes a dropped or repeated BLE delivery recoverable instead of silently producing a malformed file.

The Apex Diagnostics app now completes the user side of that workflow. The user can choose a destination, start a complete diagnostic download, watch byte-level progress, and receive files reconstructed at their original size. The app creates a dedicated diagnostic folder for the session and reports transfer failures clearly instead of leaving the user to wonder whether a partial file is complete.

Crash evidence is included when Core has retained it. That gives a spontaneous reboot a better chance of producing useful postmortem information even when the computer was not monitoring Core at the moment of failure.

Core also records more BLE connection lifecycle evidence in its event history. Connects, disconnects, ownership changes, and related reasons are now easier to line up with replay transfers, Companion sessions, and external-device activity. Together, the retained files and connection breadcrumbs create a much stronger path from "Core restarted" to a specific investigation.

This does not mean every random reboot has been explained. It means the next reboot should leave more evidence, and that evidence can now be downloaded without attaching a development monitor at exactly the right time.

Replay transfers became more defensive

Replay remains one of the most valuable tools in the Apex Infinity development loop because it exercises Companion, Core, Wrist, displays, alerts, and connected-device behavior through the same timeline.

That makes the transfer itself an important reliability surface.

Companion now reports more detail about replay progress, throughput, unexpected Core disconnects, and the point at which a transfer stopped. Completion detection has also been hardened so the app does not confuse an interrupted final step with a successfully committed replay.

Core now binds an in-progress replay transfer to the BLE connection that started it. If that connection disappears, a later connection cannot accidentally continue, commit, or cancel the previous owner's partial transfer. The abandoned transfer can be cleaned up, while the new connection begins from a known state.

Another change reduces processor pressure during large replay uploads. Core temporarily quiets nonessential sensor-producer work while the upload owns the transfer window, then restores normal behavior when the transfer ends. This addresses a specific watchdog-pressure path observed during testing without changing the recorded data format or normal live behavior.

The result is not only a better success case. It is a clearer failure case. Companion can say where the transfer stopped, Core protects the transfer from a replacement connection, and retained diagnostics can show what the device was doing near the interruption.

Shared BLE time is being managed more intentionally

Core may need to serve Companion, send live updates to Wrist, maintain a glasses display, and briefly coordinate a camera. Those responsibilities share one wireless system and cannot all begin discovery work independently at the same moment.

The latest camera work exposed a concrete version of that conflict. The glasses path could already own an active discovery operation when the camera needed its short connection window. Core now explicitly gives the camera operation priority, asks the glasses path to yield, and lets the glasses reconnect after the camera window finishes.

The glasses path also received faster update handling and stronger reconnect behavior after the first direct-display milestone. The purpose is to make yielding inexpensive. A display can step aside for a higher-priority action and then recover without requiring Core to restart.

Core is becoming quieter during known idle periods as well. When the system is safely inactive, it can stop unnecessary high-rate telemetry while continuing the background reference maintenance and connection-control work needed for a clean return to activity. That reduces needless radio and processor work without giving up the state needed for the next active period.

This is an architectural step more than a single feature. Connected equipment should cooperate around Core's timeline rather than forcing Core into isolated modes for each accessory.

Storage clearing now protects the useful data first

Companion's Core storage display exposed an uncomfortable edge case during testing: storage could appear completely full, one record could fail to synchronize, and the normal cleanup action could refuse to reclaim anything because not every record had been offloaded.

The safer workflow now separates recovery from reclamation.

When the user chooses to clear Core storage, Companion first attempts to synchronize what it can. It presents an explicit confirmation before destructive work begins, tracks command results, and asks Core to reclaim records that are actually eligible. One problematic record no longer needs to prevent unrelated, already-recovered records from releasing their space.

Core enforces the other half of that contract. Reclamation is a confirmed operation, not an incidental side effect of listing or downloading records. The log-offload service tracks which BLE connection owns the operation and applies the storage policy before changing anything.

Companion then refreshes the reported usage after cleanup, including a short retry window for Core's storage accounting to settle. That corrects the confusing behavior where a successful cleanup could still appear completely full until the user initiated another synchronization.

The workflow is deliberately conservative. It does not reset preferences, identity, or unrelated Core state. Its purpose is specifically to manage the on-Core logbook while preserving everything recoverable before space is reclaimed.

Wrist power behavior reached a cleaner baseline

Wrist's touch-only deep-sleep policy also moved into the merged product baseline after extended validation.

Normal sleep and deep sleep remain different promises. Normal sleep is intended for quick return and reconnection between active periods. Deep sleep is intended for longer non-use, with touch as the deliberate wake action. The latest work keeps that distinction explicit, records the preparation and wake outcome, and restores the required device state after touch wake.

This builds on the power work described in the previous update rather than replacing it. The important change is that the safer touch-only policy moved from a promising test branch into the supported Wrist behavior, with diagnostics retained around the parts most likely to need future tuning.

Validation is finding system problems now

The most encouraging pattern in this round is the class of problems the validation loop is finding.

Replay testing verified that camera recording state could travel from a real camera, through Core, to the red recording indicator on Wrist. Large transfers exposed connection-ownership and watchdog-pressure problems that were difficult to see in smaller tests. Complete diagnostic downloads exposed offset and descriptor edge cases, which were then corrected and retested. Storage testing found that a successful clear could still leave stale capacity visible in Companion, leading to the post-clear refresh work.

These are not isolated screen or packet tests. They are product-loop tests. Companion sends intent, Core coordinates the work, Wrist displays the resulting state, and diagnostics preserve evidence when the loop breaks.

The current random-reboot investigation remains open. One replay-upload pressure path has been addressed, but Apex Infinity is not treating that as a universal explanation for every restart. The new crash export, event history, connection breadcrumbs, and transfer diagnostics are there so future incidents can be diagnosed from evidence rather than resemblance.

What this means for Apex Infinity

This update is about coordination and recoverability.

Preferences now have an end-to-end path from Companion into persistent Core behavior. Camera state can be observed and shown on Wrist. Glasses and camera discovery can yield to each other. Replay transfers have clearer ownership and failure evidence. Complete diagnostic files can be downloaded with visible progress. Storage cleanup preserves recoverable history before reclaiming space. Wrist power behavior has a more deliberate long-rest baseline.

There is still meaningful work ahead.

Logbook synchronization needs to become much faster. The camera path needs broader device support and more field validation. Future Core hardware should make larger storage practical. Reboot investigations need to continue until retained evidence identifies the remaining causes. And every new connected device will add pressure to the scheduling and ownership rules Core now uses.

But the platform is asking better questions.

Not only "did the command run?" but "did the device confirm the result?"

Not only "did the transfer start?" but "who owns it, how does it fail, and can it resume safely?"

Not only "can storage be cleared?" but "what can be preserved first, and does the user immediately see the true result?"

That is the direction Apex Infinity needs. Companion expresses intent, Core owns the operational truth, Wrist makes that truth visible, and diagnostics preserve enough evidence to keep improving the whole system.