…ems)

#4  gmail unknown bucket — orphan:{id} fallback instead of collapsing
    all no-address messages into one "unknown" source tree; messages with
    neither address nor id are dropped with a warn (skip sentinel).

#5  PII in gmail/ingest.rs — participants, source_id, and owner wrapped
    with redact() before logging; no email addresses in log output.

#7  PII in chunker.rs — source_id in debug logs replaced with
    redact(source_id) hash.

#8  Parent dir fsync after rename in atomic.rs — on Unix, open the parent
    directory and call sync_all() after a successful rename so the dirent
    is durable across a crash; best-effort warn on failure, non-fatal.

#9  Body verify on re-stage in atomic.rs — when the path already exists,
    read and hash the on-disk body; if sha differs from the new body,
    remove the stale file and re-write atomically so SQLite content_sha256
    always matches the on-disk bytes. New unit test covers the re-write path.

#10 PII in paths.rs — malformed source_id fallback log now emits
    redact(source_id) instead of the raw string.

#11 PII in read.rs — sha256 mismatch warn logs now emit
    redact(abs_path) instead of abs_path.display().

#13 Same-tx enqueue in handle_extract — append_buffer and topic_route
    jobs are built before the transaction opens and enqueued via
    enqueue_tx() inside the same tx that commits the lifecycle update,
    eliminating the crash window where lifecycle commits but jobs are lost.

tinyhumansai#16 PII in score/extract/mod.rs — LLM extractor info! log demoted to
    debug! and endpoint wrapped with redact_endpoint() to strip
    path/query/credentials from the URL.

tinyhumansai#17 Non-email scope slug in bucket_seal.rs — only the gmail: prefix is
    stripped before slugify; all other source kinds (slack:, discord:,
    document:, …) slugify the full scope string so slack:#eng and
    discord:#eng no longer produce the same "eng" slug and collide in
    summaries/source/.

tinyhumansai#18 Don't commit summary on stage_summary failure — bucket_seal.rs,
    global_tree/digest.rs, and global_tree/seal.rs now propagate
    stage_summary errors via .context()?  instead of falling back to a
    NULL content_path row; the seal is retried via the normal job-retry
    path. insert_summary_tx callers in those three paths now always pass
    Some(&staged) instead of Option.

tinyhumansai#20 PII in topic_tree/backfill.rs — all entity_id occurrences in log
    lines (info/debug/warn) replaced with redact(entity_id).

New shared helper: src/openhuman/memory/tree/util/redact.rs
  - redact(s)          → stable 8-hex-char SHA-256 prefix for PII fields
  - redact_endpoint(u) → host:port only (strips scheme, creds, path, query)
  - Full unit-test coverage for both helpers

Items #14 (lease tokens) and tinyhumansai#19 (preview-vs-disk reader audit)
intentionally deferred to follow-up commits — both have larger blast
radius and need separate review.

Items #1, #12, #15 pushed back on PR thread (verified false positive or
covered by upstream contract).

Items #2, #3 deferred (pre-existing in slack_backfill.rs, not introduced
by this PR).

Co-Authored-By: Claude Sonnet 4.6 <[email protected]>

chore: merge develop into main (v0.20.0)

refactor: streamline message handling in Conversations component

…rmation)

A new read-only "Specialisation" tab. The vocabulary lens (tinyhumansai#17 Predicate
Diversity) tells you how varied the global predicate set is. The thickness
lens (tinyhumansai#18 Predicate Bundles) tells you which entity pairs share many
predicates. The frequency lens (tinyhumansai#7 Relationship Types) tells you which
predicates dominate overall. None of them answers the question this lens
does: how much does knowing the SUBJECT predict which predicate it will
use? And which entities speak in a specialised vocabulary versus a
generalist one?

Engine (pure, deterministic — no React/RPC/clock/RNG):
- Global: I(S; P) in bits with canonical-order summation; H(S) and H(P);
  normalisedMI = I / min(H(S), H(P)).
- Per-subject: specialisation = 1 - H(P|S=s)/log2(D_s) in [0,1] (1 when
  D_s <= 1 — single-predicate subject is maximally specialised by
  convention), plus dominantPredicate (tie-broken by predicate ASC) and
  dominantPredicateShare.
- All p·log2(p) and joint·log2 ratio sums walk pairs in canonical
  (sortedSubjects, sortedPredicates) order so the result is byte-identical
  regardless of relation insertion order (lesson from tinyhumansai#2978 Cohesion's
  float-order bug).

Selected from the prior loop-19 design workflow's runner-up (8.35/10 — a
genuinely new lens not covered by any of the 19 shipped features).

Adds ZERO new core surface: composes the already-shipped memoryGraphQuery
/ memoryListNamespaces wrappers. Container/presentational split with a
monotonic request-token race guard for load-on-mount; i18n across all 13
locales.

Co-Authored-By: Claude Opus 4.7 <[email protected]>

…rmation)

A new read-only "Specialisation" tab. The vocabulary lens (tinyhumansai#17 Predicate
Diversity) tells you how varied the global predicate set is. The thickness
lens (tinyhumansai#18 Predicate Bundles) tells you which entity pairs share many
predicates. The frequency lens (tinyhumansai#7 Relationship Types) tells you which
predicates dominate overall. None of them answers the question this lens
does: how much does knowing the SUBJECT predict which predicate it will
use? And which entities speak in a specialised vocabulary versus a
generalist one?

Engine (pure, deterministic — no React/RPC/clock/RNG):
- Global: I(S; P) in bits with canonical-order summation; H(S) and H(P);
  normalisedMI = I / min(H(S), H(P)).
- Per-subject: specialisation = 1 - H(P|S=s)/log2(D_s) in [0,1] (1 when
  D_s <= 1 — single-predicate subject is maximally specialised by
  convention), plus dominantPredicate (tie-broken by predicate ASC) and
  dominantPredicateShare.
- All p·log2(p) and joint·log2 ratio sums walk pairs in canonical
  (sortedSubjects, sortedPredicates) order so the result is byte-identical
  regardless of relation insertion order (lesson from tinyhumansai#2978 Cohesion's
  float-order bug).

Selected from the prior loop-19 design workflow's runner-up (8.35/10 — a
genuinely new lens not covered by any of the 19 shipped features).

Adds ZERO new core surface: composes the already-shipped memoryGraphQuery
/ memoryListNamespaces wrappers. Container/presentational split with a
monotonic request-token race guard for load-on-mount; i18n across all 13
locales.

Co-Authored-By: Claude Opus 4.7 <[email protected]>

…rmation)

A new read-only "Specialisation" tab. The vocabulary lens (tinyhumansai#17 Predicate
Diversity) tells you how varied the global predicate set is. The thickness
lens (tinyhumansai#18 Predicate Bundles) tells you which entity pairs share many
predicates. The frequency lens (tinyhumansai#7 Relationship Types) tells you which
predicates dominate overall. None of them answers the question this lens
does: how much does knowing the SUBJECT predict which predicate it will
use? And which entities speak in a specialised vocabulary versus a
generalist one?

Engine (pure, deterministic — no React/RPC/clock/RNG):
- Global: I(S; P) in bits with canonical-order summation; H(S) and H(P);
  normalisedMI = I / min(H(S), H(P)).
- Per-subject: specialisation = 1 - H(P|S=s)/log2(D_s) in [0,1] (1 when
  D_s <= 1 — single-predicate subject is maximally specialised by
  convention), plus dominantPredicate (tie-broken by predicate ASC) and
  dominantPredicateShare.
- All p·log2(p) and joint·log2 ratio sums walk pairs in canonical
  (sortedSubjects, sortedPredicates) order so the result is byte-identical
  regardless of relation insertion order (lesson from tinyhumansai#2978 Cohesion's
  float-order bug).

Selected from the prior loop-19 design workflow's runner-up (8.35/10 — a
genuinely new lens not covered by any of the 19 shipped features).

Adds ZERO new core surface: composes the already-shipped memoryGraphQuery
/ memoryListNamespaces wrappers. Container/presentational split with a
monotonic request-token race guard for load-on-mount; i18n across all 13
locales.

Co-Authored-By: Claude Opus 4.7 <[email protected]>

…rmation)

A new read-only "Specialisation" tab. The vocabulary lens (tinyhumansai#17 Predicate
Diversity) tells you how varied the global predicate set is. The thickness
lens (tinyhumansai#18 Predicate Bundles) tells you which entity pairs share many
predicates. The frequency lens (tinyhumansai#7 Relationship Types) tells you which
predicates dominate overall. None of them answers the question this lens
does: how much does knowing the SUBJECT predict which predicate it will
use? And which entities speak in a specialised vocabulary versus a
generalist one?

Engine (pure, deterministic — no React/RPC/clock/RNG):
- Global: I(S; P) in bits with canonical-order summation; H(S) and H(P);
  normalisedMI = I / min(H(S), H(P)).
- Per-subject: specialisation = 1 - H(P|S=s)/log2(D_s) in [0,1] (1 when
  D_s <= 1 — single-predicate subject is maximally specialised by
  convention), plus dominantPredicate (tie-broken by predicate ASC) and
  dominantPredicateShare.
- All p·log2(p) and joint·log2 ratio sums walk pairs in canonical
  (sortedSubjects, sortedPredicates) order so the result is byte-identical
  regardless of relation insertion order (lesson from tinyhumansai#2978 Cohesion's
  float-order bug).

Selected from the prior loop-19 design workflow's runner-up (8.35/10 — a
genuinely new lens not covered by any of the 19 shipped features).

Adds ZERO new core surface: composes the already-shipped memoryGraphQuery
/ memoryListNamespaces wrappers. Container/presentational split with a
monotonic request-token race guard for load-on-mount; i18n across all 13
locales.

Co-Authored-By: Claude Opus 4.7 <[email protected]>

…rmation)

A new read-only "Specialisation" tab. The vocabulary lens (tinyhumansai#17 Predicate
Diversity) tells you how varied the global predicate set is. The thickness
lens (tinyhumansai#18 Predicate Bundles) tells you which entity pairs share many
predicates. The frequency lens (tinyhumansai#7 Relationship Types) tells you which
predicates dominate overall. None of them answers the question this lens
does: how much does knowing the SUBJECT predict which predicate it will
use? And which entities speak in a specialised vocabulary versus a
generalist one?

Engine (pure, deterministic — no React/RPC/clock/RNG):
- Global: I(S; P) in bits with canonical-order summation; H(S) and H(P);
  normalisedMI = I / min(H(S), H(P)).
- Per-subject: specialisation = 1 - H(P|S=s)/log2(D_s) in [0,1] (1 when
  D_s <= 1 — single-predicate subject is maximally specialised by
  convention), plus dominantPredicate (tie-broken by predicate ASC) and
  dominantPredicateShare.
- All p·log2(p) and joint·log2 ratio sums walk pairs in canonical
  (sortedSubjects, sortedPredicates) order so the result is byte-identical
  regardless of relation insertion order (lesson from tinyhumansai#2978 Cohesion's
  float-order bug).

Selected from the prior loop-19 design workflow's runner-up (8.35/10 — a
genuinely new lens not covered by any of the 19 shipped features).

Adds ZERO new core surface: composes the already-shipped memoryGraphQuery
/ memoryListNamespaces wrappers. Container/presentational split with a
monotonic request-token race guard for load-on-mount; i18n across all 13
locales.

Co-Authored-By: Claude Opus 4.7 <[email protected]>

…rmation)

A new read-only "Specialisation" tab. The vocabulary lens (tinyhumansai#17 Predicate
Diversity) tells you how varied the global predicate set is. The thickness
lens (tinyhumansai#18 Predicate Bundles) tells you which entity pairs share many
predicates. The frequency lens (tinyhumansai#7 Relationship Types) tells you which
predicates dominate overall. None of them answers the question this lens
does: how much does knowing the SUBJECT predict which predicate it will
use? And which entities speak in a specialised vocabulary versus a
generalist one?

Engine (pure, deterministic — no React/RPC/clock/RNG):
- Global: I(S; P) in bits with canonical-order summation; H(S) and H(P);
  normalisedMI = I / min(H(S), H(P)).
- Per-subject: specialisation = 1 - H(P|S=s)/log2(D_s) in [0,1] (1 when
  D_s <= 1 — single-predicate subject is maximally specialised by
  convention), plus dominantPredicate (tie-broken by predicate ASC) and
  dominantPredicateShare.
- All p·log2(p) and joint·log2 ratio sums walk pairs in canonical
  (sortedSubjects, sortedPredicates) order so the result is byte-identical
  regardless of relation insertion order (lesson from tinyhumansai#2978 Cohesion's
  float-order bug).

Selected from the prior loop-19 design workflow's runner-up (8.35/10 — a
genuinely new lens not covered by any of the 19 shipped features).

Adds ZERO new core surface: composes the already-shipped memoryGraphQuery
/ memoryListNamespaces wrappers. Container/presentational split with a
monotonic request-token race guard for load-on-mount; i18n across all 13
locales.

Co-Authored-By: Claude Opus 4.7 <[email protected]>

…tk prelude + macOS NSAlert unsafe (TAURI-RUST-F)