shenas
shenas is a personal-data application: it ingests a user’s data from the services they use into a DuckDB store on their own device, and reads its dashboards from that store. It is the application the reference implementation is developed alongside, and the first one to consume it. This page is about shenas as an SSP/1 implementation and nothing else.
Modules claimed
Section titled “Modules claimed”None. The conformance clause requires an implementation to state its module set. shenas has no running replication layer, so any module it named would be a claim nothing yet enforces.
Floor partition
Section titled “Floor partition”SSP/1 section 15.1 requires every conforming mesh to fix a floor, and registry section 55.1 item 3 requires it to be documented. The shenas floor partition is that document: every schema the application declares, in exactly one of the three categories, with the reason it is there, and the section 17 declaration of which categories may have their history evicted.
It is normative for shenas’s own code, which tests itself against that page in both directions, and it is published ahead of the replication layer on purpose: a floor stated before there is anything to replicate cannot be shaped after the fact to fit whatever the first release happened to send.
Corpus result
Section titled “Corpus result”Not run. shenas does not execute the published vectors, because every case in the corpus exercises a module it does not claim. The reference implementation’s result is on its own page.
Not implemented
Section titled “Not implemented”Replication itself. There is no registered replication layer, so the floor gates nothing at runtime today, and the send-side policy of section 15.2 is not filled in the node that is being built: the floor partition page says what that leaves exposed once the node runs, and why. There is no eviction, no peer, and no object plane. The status page says what exists of the protocol.