69 lines
5.1 KiB
Markdown
69 lines
5.1 KiB
Markdown
# subjektiv
|
|
|
|
Shared Host domain implementation for per-Subject Memory, change history, candidate dispositions, derived surfaces, and Session activity Journals.
|
|
`feature-storage` manages physical SQLite storage; the calling Host handles authentication and execution authority.
|
|
Journal storage does not generate prose, launch Jobs, or fetch Session history.
|
|
Hosts retain body ownership across inactivity, reserve actual execution quiescence, and reconcile final committed history before releasing a Journal writer lifetime. [`journal::binding`] fences new mutations inside storage transactions; historical attribution and exact receipt recovery cannot renew a released lifetime. [`journal::startup`] selects bounded reference context independently of source retention and long-term Memory.
|
|
|
|
## Main entry points
|
|
|
|
- [`SubjektivStore`]: scope-bound records and transactions
|
|
- [`MemoryRecord`], [`SurfaceSnapshot`]: change history and derived context
|
|
- [`api`]: shared Host operations and bounded responses
|
|
- [`job`]: consolidation selection rules and result validation
|
|
- [`journal`]: individually committed activity operations, source coverage, retry receipts, and bounded reading
|
|
|
|
## Explicit Subject deletion
|
|
|
|
`begin_subject_deletion(subject_id, operation_id)` commits a permanent content-free
|
|
fence in this store **before** the Host stops execution or erases external content.
|
|
The operation ID is unique within this storage scope. Exact retries return current
|
|
saved state; a different key for that Subject or reuse for another Subject conflicts.
|
|
Pending fences survive restart and a failed purge. Normal reads, writes, saved-receipt
|
|
replay, cached Host/Journal contexts and authority lookup cannot use a fenced Subject.
|
|
Subject discovery hides fenced records before pagination. SQL INSERT/UPDATE guards
|
|
cover direct and indirect owners, checking both OLD and NEW ownership on UPDATE.
|
|
Deleting a grant never restores non-Subject fallback: content-free Worker identity
|
|
fences remain, and the Host must consult them before fallback authorization.
|
|
|
|
The Host uses `subject_deletion` / `pending_subject_deletions` for recovery and
|
|
`deletion_subject_workers` / `deletion_subject_sessions` / `deletion_subject_jobs`
|
|
only as cleanup inventories, not authority or model-visible content. It must fence
|
|
creation reservations, quiesce Workers and in-flight delivery, purge Job inputs/results
|
|
and live Job execution copies, and clear resident/derived caches. Source Worker/Session
|
|
originals and pre-existing archives have independent retention lifecycles: the Workspace
|
|
Host archives source originals rather than erasing them. Those archives may contain
|
|
previously injected Memory; Workdirs, Tickets, exports and external provider copies are
|
|
also outside Subject content erasure. These boundaries must be explained to the user.
|
|
An unfinished, previously authorized Worker retention operation is snapshotted separately
|
|
from prior successful removals. Its exact original request is reconciled under the permanent
|
|
fence; its disposition, fingerprint and canonical result are never rewritten. Body originals
|
|
follow that earlier independent request. For a Subject Job, any archive/diagnostic copies
|
|
produced by the unfinished operation require a distinct Runtime physical-erasure acknowledgement
|
|
before deletion can complete. Lost responses or failed receipt commits retain the same request
|
|
and incomplete state across restart. Successes that already existed at deletion start remain
|
|
under their independent archive lifecycle; a later success is not inserted into that snapshot.
|
|
The domain rechecks after out-of-DB capture callbacks and before returning Job read
|
|
responses; already returned DTOs cannot be revoked by SQLite. Host lifecycle locking
|
|
must cover delivery/reinjection of previously fetched content as well as finish.
|
|
|
|
Only after external cleanup succeeds may the Host call
|
|
`finish_subject_deletion(subject_id, operation_id)`. One transaction deletes Subject,
|
|
Memory/history, staging/evidence, Surface snapshots/runs, permission sources/receipts,
|
|
child grants, writer/session bindings, Journal content/generations/deliveries/receipts,
|
|
links, and the Subject's `legacy_record_archive` rows. A purge error rolls back all
|
|
those deletions without undoing the separately committed fence. Ordinary history
|
|
retention and explicit Journal Session-erasure rules are unchanged for other Subjects.
|
|
Retained records contain only deletion operation/time/completion and execution/session
|
|
identities needed to prevent reuse; existing content-free Session-erasure markers and
|
|
workspace-only migration metadata remain. Other Subjects and storage scopes are untouched.
|
|
|
|
The deletion migration adds fences without erasing or reactivating existing data. Old `retired`
|
|
JSON/SQL records deserialize as `SubjectState::LegacyRetired` and remain readable
|
|
until explicitly deleted. There is no current retirement API. Normal Worker deletion
|
|
still does not implicitly delete Subject memory.
|
|
|
|
Completion means logical erasure from domain and Host-managed storage, **not** secure
|
|
physical overwriting: SQLite free pages, WAL files, filesystem snapshots, backups and
|
|
external copies can retain bytes under their own retention/erasure policies.
|