Replay Validation, Wrist Alerts, And Core Storage Update

The last update focused on Core reliability, spoken audio installs, replay validation, and the work to keep Core's firmware structure from becoming harder to maintain.

Since then, the work has stayed close to that same theme.

The difference is that replay moved from being mostly a developer convenience into something closer to a platform workflow.

That matters because Apex Infinity is increasingly a system of connected devices and surfaces. Core, Wrist, and Companion all need to agree about what happened during a session, what alert thresholds were active, what the display should do, and whether the user can trust what they see and hear.

Replay is becoming one of the ways to prove that.

Companion can now send a session back to Core as replay

One of the most useful changes in this round was adding a replay action directly from the Companion logbook.

The workflow is simple in concept: choose an activity record, send it to Core, let Core reboot into replay, and use that replay to validate device behavior.

That is a small interaction with a large impact.

Before this, replay was powerful but still too dependent on development setup. Files could be copied around, storage could be mounted, and specific replay assets could be staged, but that was not the same as having a normal product surface that could push a real session back to the device for inspection.

Putting the replay action in the logbook changes that.

It makes replay feel like a natural part of the platform instead of a hidden tool. If an activity record behaved oddly, or if a user says they did not hear a callout, or if a display seemed wrong, the system now has the beginning of a path for asking Core to replay that activity record.

That has obvious development value, but it also points toward future support value.

Apex Infinity should eventually be able to turn a user's recorded session into a repeatable validation case.

Wrist alert behavior was validated from the full loop

That new replay path immediately paid off in the Wrist work.

The current Wrist issue was about descent alert flashing behavior. The expected behavior is intentionally narrow: Classic analog faces should not suddenly change behavior unless they are in a digital mode, while Classic digital and Edge-style presentations should behave consistently for the descent alert states.

That kind of behavior is hard to validate well with static inspection alone.

The useful test is the full loop:

• build and flash the Wrist firmware
• send a real replay from Companion to Core
• let Core stream replay telemetry
• watch the Wrist display move through the session phases
• confirm the alert visual state when the replay crosses the configured thresholds

That is what happened in this round.

The first pass exposed another useful detail: the replay's breakoff, pull, and hard-deck windows need to line up with the current Core alert settings if the visual behavior is going to be obvious. Once those settings were aligned, the Wrist reached active use, showed the expected green state, and confirmed the descent alert flash behavior.

That is the kind of validation loop the project needs more of.

It does not only prove that one display effect worked. It proves that Companion, Core replay, BLE telemetry, Wrist ingestion, and the face logic can all be exercised together.

Companion release flow is part of the device workflow now

This round also made one operational truth more obvious: when Companion gains a device workflow, the release path matters immediately.

The replay button existed in the code before it existed in the installed app. That meant the device validation path depended on cutting a fresh Companion build and getting it through the macOS TestFlight release workflow.

That is not just administrative overhead.

It is part of the platform now.

Core and Wrist work increasingly depends on Companion features being available in the real installed app, not only in a local debug build. That makes the release lane for Companion part of the hardware validation story. If Companion is the user-facing control surface, then device workflows are only as usable as the build that can actually reach the user or tester.

The latest release path carried the replay action forward and made it available for the Wrist validation work. That is another sign that Apex Infinity is becoming a coordinated product system rather than separate repos moving in isolation.

New Core hardware opened the next storage chapter

The hardware side also moved forward with the next Core prototype board.

The new board changes the storage conversation. Earlier Core layouts were built around a smaller internal storage envelope, while the newer hardware gives Core more room to separate firmware growth, runtime content, and import workflows.

The first step was bring-up discipline: flash the existing firmware, monitor the boot, identify what worked, and separate real wiring problems from software assumptions.

That caught two important things.

First, the module itself was alive and flashable.

Second, one of the storage paths initially looked dead in a way that pointed to hardware wiring, not a storage-format problem. After physical inspection and correction, that path came back and the existing stored activity data was still visible.

That matters because it kept the investigation honest.

The right answer was not to erase more aggressively or keep changing software until the symptom disappeared. The right answer was to prove the physical link first.

Core is moving toward separate runtime and import storage

With the new board alive, the Core storage layout could be reconsidered.

The current direction is to use the larger internal flash more deliberately:

• more room for future firmware growth
• app-owned runtime storage for device content
• a separate USB-facing import area
• and an import step that copies staged files into runtime storage after USB file transfer is done

That split is important.

The earlier USB storage model put too much pressure on the same storage surface. The host and the firmware both cared about content on the same volume, and the handoff between "a computer is writing files" and "Core is using files" was fragile.

The staged model is cleaner. USB gets an inbox. Core owns the runtime copy. After the host is done, Core can validate, copy, rename, and reboot into the correct runtime behavior.

That is the right shape for voice packs and replay files.

It is not finished yet.

The current storage branch has already exposed and fixed a serious formatting bug where a recovery path could target the wrong storage area. That was exactly the kind of bug the staging design is meant to make easier to reason about.

But the import workflow still has a remaining blocker. On the current test branch, a computer can see and write to the USB-facing volume, but Core is not yet reliably reclaiming the device after eject and importing the copied audio pack back into runtime storage. Until that path is proven, audio on the new setup should be treated as not installed rather than as a playback failure.

That distinction matters.

Audio is not "broken" because the speaker path forgot how to play. The current blocker is that the new storage/import workflow has not yet completed the handoff from the host-visible USB inbox to Core's runtime storage.

Why this matters

This phase is about turning validation and content handling into real system behavior.

The replay work shows the positive side of that: Companion can send a session back to Core, Core can replay it, Wrist can react to it, and the whole system can be tested as a chain instead of as isolated parts.

The Core storage work shows the hard side: once Core is expected to carry voice packs, replay files, logs, runtime state, and host-visible import behavior, the storage layout and USB handoff have to be deliberate. A storage workflow that mostly works is not good enough if it can leave the device without audio or stuck after eject.

That is the right problem to be solving now.

Apex Infinity is becoming a platform where a session can be recorded, replayed, inspected, displayed, and used to validate the behavior of multiple devices.

To make that feel finished, the boring parts have to be trustworthy too:

• files need to land in the right place
• storage needs to recover cleanly
• host handoff needs to be predictable
• replay settings need to represent the session being replayed
• and device workflows need to confirm themselves without requiring developer tools

That is where the current work is aimed.

The visible result is better replay validation and more capable hardware.

The more important result is that Apex Infinity is continuing to turn isolated device capabilities into repeatable platform workflows.