Skip to main content

Module integrity

Module integrity 

Source
Expand description

Integrity linter — read-time conformance findings.

The engine’s schema validation runs at write time as refusals on memstead_create / memstead_update / memstead_relate. This module runs the same checks in a read context over the entities already on disk, so memstead_health can report the conformance axis: which entities of a mem would a write refuse under a given schema, and why.

One validation truth, two contexts: every finding carries the same typed code (and the same recovery payload, via EngineError::code / EngineError::details) the corresponding write would refuse with. An entity that lints clean against schema S is accepted by a write under S, and vice versa — the linter never invents a parallel conformance vocabulary.

Determinism: same store state and schema produce the same findings in the same order, byte for byte. Entities are visited in lexical id order; within one entity, checks run in a fixed sequence (type, section keys, required sections, metadata, required fields, relationships) and map/list iteration follows the entity’s own deterministic on-disk order (IndexMap / Vec).

Structs§

BodyObservation
One per-entity BODY OBSERVATION — what an entity’s stored body carries that its type does not declare (consistency-sweep 04/01).
IntegrityFinding
One per-entity integrity finding — the stable wire shape { id, axis, code, detail }.

Enums§

IntegrityAxis
Which integrity axis a finding belongs to. Consistency findings (graph coherence: orphans, stubs, dangling links) come from the pre-existing health categories; conformance findings (entity vs schema) come from this linter.
ObservationFate
What happens to the observed content on the next write.

Constants§

UNRESOLVED_STUB_CODE
Run the consistency axis over mem, projecting the pre-existing graph-coherence checks into the integrity-finding shape: dangling wiki-links (the DANGLING_LINK_* / DANGLING_RELATION_* family, on the linking entity), stubs with their referrers (UNRESOLVED_STUB, on the stub), and cross-mem edges the workspace no longer permits (CROSS_MEM_EDGE_UNGRANTED, on the referrer). The category collectors are the same ones the dedicated health includes use — integrity is a projection, not a second implementation.

Functions§

body_observations
Every body observation for mem, in a stable order.
conformance_findings
Run the conformance axis over every non-stub entity of mem, validating against schema (the mem’s current pin, or an arbitrary target schema — the caller chooses the effective schema).
consistency_findings
target_mounted answers whether a mem is mounted right now. A cross-mem edge whose target mem is not mounted is one condition, not two: the edge dangles (DANGLING_RELATION_TARGET_MISSING, the same row the dangling-link collector emits for an absent target, emitted here when the target survives only as a load-time stub of the vanished mem) and the grant question is never asked, because “no grant declared” and “target not mounted” are different facts and only the first carries the re-grant repair. The grant table may still name the pair; that is not the condition, and re-granting what is granted repairs nothing.
entity_conformance_findings
Conformance findings for a single entity — the per-entity slice of conformance_findings, exposed for callers that gate on one entity’s current conformance (the memstead_update repair-power gate). Empty result == the entity is conformant: a write of this entity under schema would be accepted.