Repository navigation
Memory Layer Only - #17
Merged
Merged
Conversation
- Changed the return type of `recall_skill_context` to `Option<serde_json::Value>` for better flexibility. - Updated logging to provide clearer insights during memory recall operations. - Simplified context handling in `chat_send_inner` and `recall_memory` functions to improve readability.
…arify memory context usage - Reduced the number of available tools for Notion from 25 to 12. - Added architecture note regarding memory layer handling for read/query operations. - Updated descriptions to specify that data retrieval is managed by the memory context instead of tools.
- Introduced a utility function to identify read-only tools in both TypeScript and Rust implementations. - Updated tool discovery logic to filter out read-only tools, ensuring only actionable tools are included in the skill definitions. - Improved comments for clarity regarding the handling of tool data from the memory layer.
sanil-23
referenced
this pull request
in sanil-23/openhuman
Apr 28, 2026
…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. #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. #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/. #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. #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 #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 <noreply@anthropic.com>
AusAgentSmith
pushed a commit
to AusAgentSmith/openhuman
that referenced
this pull request
May 23, 2026
chore: merge develop into main (v0.5.0)
AusAgentSmith
pushed a commit
to AusAgentSmith/openhuman
that referenced
this pull request
May 23, 2026
Memory Layer Only
5 tasks done
aashir-athar
added a commit
to aashir-athar/openhuman
that referenced
this pull request
May 30, 2026
…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 <noreply@anthropic.com>
aashir-athar
added a commit
to aashir-athar/openhuman
that referenced
this pull request
May 30, 2026
…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 <noreply@anthropic.com>
aashir-athar
added a commit
to aashir-athar/openhuman
that referenced
this pull request
May 30, 2026
…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 <noreply@anthropic.com>
aashir-athar
added a commit
to aashir-athar/openhuman
that referenced
this pull request
May 31, 2026
…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 <noreply@anthropic.com>
aashir-athar
added a commit
to aashir-athar/openhuman
that referenced
this pull request
May 31, 2026
…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 <noreply@anthropic.com>
aashir-athar
added a commit
to aashir-athar/openhuman
that referenced
this pull request
May 31, 2026
…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 <noreply@anthropic.com>
oxoxDev
added a commit
to oxoxDev/openhuman
that referenced
this pull request
Jun 5, 2026
oxoxDev
added a commit
to oxoxDev/openhuman
that referenced
this pull request
Jun 5, 2026
…(TAURI-RUST-F)
Merged
12 tasks done
senamakel
added a commit
to nocstah/openhuman
that referenced
this pull request
Sep 11, 2026
…e: merge develop into main (v0.5.0)\n
senamakel
pushed a commit
to nocstah/openhuman
that referenced
this pull request
Sep 11, 2026
11 of 12 tasks
12 tasks done
sanil-23
added a commit
that referenced
this pull request
Oct 16, 2026
Review #15/#17/#18: - the coverage matrix row cites the current tests instead of the deleted ChatFilesPanel test and describes cards and the save dialog; - AGENTS.md's submodule table gains `tiny-artifacts`; - comments in `artifact_commands.rs`, `lib.rs` and `artifactDownloadService.ts` describe the save dialog that exists again, and the permissions README drops the missing `allow-artifact-save` set; - `save_artifact_as` takes its chooser through `save_to_chosen_path`, so its refusals (empty, unknown, path-like filename) and the cancel and copy paths are tested without a dialog. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
29 tasks done
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.