SpecService

The door host's spec binding: it brings the spec database up for one (sentient, device), registers the `spec.*` tasks against it, and backs it up (trove-parts §TPS-3, §TPS-4).

In the namespace octomy::trove::specdb. Declared in src/libs/libtrove/trove/specdb/SpecService.hpp.

Detailed description

Identity switches swap the database, and the tasks with it

There is one database per **(sentient, device)** pair (§DM-2), so activating a different identity is not a reconfiguration — it is a different corpus. activate() therefore closes the previous store and re-registers the task family against the new one.

Re-registration is not optional bookkeeping: the tasks hold a shared pointer to the store they were built with. Leaving them registered across an identity switch would leave a live, working `spec.*` surface answering from the PREVIOUS sentient's database — which is precisely the isolation §DM-2.2 promises, broken in the least visible way possible.

The door is not here

Until trove-parts phase 2 this class also opened the spec front door and wrote `spec-door.json`. The door is one per user and host now, and the door host opens it (trove-parts §TPD-1). This class keeps the two jobs that are the database's.

Backups run

SpecStore::backup() keeps seven snapshots, and until phase 2 nothing outside the tests called it. The door host calls backupIfDue() at each call, so the first call after midnight takes the day's backup. The store itself backs up a database of an older schema before it migrates it.

The database is an octomy::trove::specdb::SpecStore.

See also octomy::trove::door::DoorHost.