01ace26d08db395fa6a7ebf5dbeb1f58e7d59f75
7
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  alvinfeiandClaude Opus 5.5
|
9459a1107b |
chore(release): MemHub 1.0.6, build 37
Sets every MemHub package, the Core project and its lock entry to 1.0.6 with set-release-version.mjs, and the build number to 37. The release facts in memhub/README.md and docs/INSTALLATION.md now name v1.0.6 (build 37). Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
 alvinfeiandCursor
|
f5a38c38b3 |
release(memhub): pin hy-memory 2.0.5
Co-authored-by: Cursor <cursoragent@cursor.com> |
||
 
|
a3f09f4cac |
release: merge MemHub 1.0.4 development fixes (#50)
* feat(memhub): add model usage audit and cost controls Co-authored-by: Cursor <cursoragent@cursor.com> * fix(memhub): typed source authorization state and managed-key registry ownership Closes #29 Issue #29 surfaced as "WorkBuddy plugin cannot be uninstalled / source sync cannot be turned on", but it is two independent failure domains that were both being reported as a single opaque `desktop_action_failed`: 1. Source sync domain: the UI could not tell whether a source failed to sync because the grant was missing, revoked, or because the source identity or root path changed. Every failure collapsed into one error, so the UI could only say "failed". 2. Host plugin install domain: WorkBuddy shares three registry files (`known_marketplaces.json`, `installed_plugins.json`, `settings.json`) with the host. MemHub recorded a whole-file hash at install time and then refused to uninstall whenever the host (or a reformat) changed any byte anywhere in the file, even in entries MemHub does not own. What changes Domain errors (new `packages/host-bridge/src/domain-error.ts`) - Closed allowlist `DOMAIN_CODES`: grant_required, source_identity_changed, host_uninstall_modified_managed_value, host_uninstall_unknown_owned_file, host_uninstall_needs_review, host_install_journal_invalid, host_install_recovery_required, host_permission_storage_unsafe. - `DomainError` + `domainCodeOf()` so callers stop string-matching on `Error.message`. `diagnosticDomainError()` emits only the code and a repo-relative safe stack, never message text, so diagnostics cannot leak paths or payloads. - Re-exported from `runtime-control` (host-bridge owns the type to avoid a dependency cycle); desktop `observeDesktopAction` now uses `domainCodeOf(error) ?? fallbackCode`. Source authorization state - `SourceAuthorizationState` enum: ok / missing_grant / revoked_grant / source_identity_changed / source_root_unavailable / candidate_changed, plus `SourceGrantStore.authorization_state()` which is read-only and fails closed. - `/api/v1/sources` now returns `authorization_state` per source; contracts and the web app render a concrete next action next to the sync switch instead of a generic failure. - `_change_source_sync` distinguishes sync_prepare_failed, sync_config_write_failed, sync_resume_failed, sync_watcher_failed (409 with the code as detail) while keeping the existing rollback behaviour. - Capture refuses silently but now records a fail-open rejection marker (`sync_disabled` / grant_missing / grant_revoked) that counts occurrences in a time window and carries no payload, path, or session content. WorkBuddy registry ownership (journal v1 -> v2) - Ownership is now the value at MemHub's own key, not the whole file. Added `canonicalJson`, `registryManagedDigest`, `registryWithoutOurs`, `registryHoldsOnlyOurs`. - Install: the plan records `keyPath` + managed digest; apply compares the managed value (CAS) instead of the whole file; the journal writes both the v1 `installed_hash` and the v2 `installed_managed`. - Uninstall: `resolveRegistryOwnership()` compares the v2 digest, falls back to the v1 hash and `isManagedRegistryEntry`, and otherwise produces a review finding instead of throwing. `managedRegistryRemoval()` deletes a file MemHub created when it still holds only our entry; removes just our key when the host has added its own content; and restores recorded bytes only when the rest of the document is unchanged, otherwise patches the current document. - v1 journals migrate: a whole-file hash mismatch no longer blocks uninstall. Tests - `packages/host-bridge/src/domain-error.test.ts` (5): code is carried, message never reaches diagnostics, no guessing on unclassified errors, refuses to parse codes out of free text, allowlist is closed. - `workbuddy-plugin-installer.test.ts` (34 total): uninstall survives a host reformat, removes only our key when the host changed something else, asks for review when a managed entry was changed, migrates a v1 journal, keeps a registry the host now uses, installs over a post-plan change. - `apps/core/tests/test_source_authorization_state.py` (12): every state, fail-closed ordering, capture rejection names, marker contains no secret or path, recording never raises. - `apps/web`: authorization note rendered for revoked grant and hidden when ok. Verification - host-bridge WorkBuddy suite 34/34; domain-error 5/5. - apps/web 1906 tests across 105 files pass. - pnpm -r typecheck clean; biome check clean on touched files. - core-fast: 232 failed / 4131 passed, identical failure count to the clean baseline (232 failed / 4119 passed) with +12 from the new tests; the failures are pre-existing and unrelated (confirmed by stashing and re-running). * feat(memhub): add a start/stop switch for model sedimentation Shipped builds gave the user no way to stop model calls: the model content permission switch is gone (removed with its endpoint in #20) and there is no pause or remove entry either, so a configured model keeps turning conversations into memories and keeps costing money. Adds a user switch in settings: stopping keeps the model configuration and the already imported conversations, leaves queued work pending instead of failing it, and stops new work, enqueueing and backfill so nothing further reaches the model. Starting again resumes the same work without re-entering a key. The flag lives in Core's own user config (config.json), so no schema migration is needed, and the supervisor takes it as an optional callback so every existing caller and test keeps its current behaviour. * test(desktop): keep host-bridge mocks whole and assert the review contract The memhub CI job failed four desktop tests after the issue #29 change. Both were test-side contracts that the new ownership model intentionally moves, not regressions in the fix itself. 1. `host-control-ownership.test.ts` mocked `@one-memory/host-bridge` with a whitelist that carried only `RecallBroker`. Main now imports `domainCodeOf`, which runtime-control re-exports from host-bridge, so the mock handed back undefined and every error path that called it threw a TypeError instead of the error the test was asserting on. The mock now spreads the real module and overrides only `RecallBroker`, which is the part it was written for. 2. `host-permissions.test.ts` asserted the pre-#29 contract, where a change anywhere in a shared registry made uninstall throw `host_uninstall_modified_files`. Ownership is now the value at our own key, so a change to that value is reported instead of guessed at: the plan schedules no removal, names the file in a review finding, and applying it refuses with `host_uninstall_needs_review`. The test keeps the guarantee it existed for, that those bytes are never overwritten, and now also asserts that apply refuses, so the safety is checked at both steps. Verification: full desktop suite 38 files / 436 tests pass, `pnpm -r typecheck` clean, biome reports only two pre-existing warnings on lines this change does not touch. * fix(logging): keep info diagnostics actionable Co-authored-by: Cursor <cursoragent@cursor.com> * test(memhub): register the sedimentation switch test in the core test inventory New core test files must appear in TEST_INDEX.md and in the classification inventory's expected count and digest, and the backfill case needs a settled turn because an unanswered user tail is not backfill material. * feat(diagnostics): expose build info and fullscreen logs Co-authored-by: Cursor <cursoragent@cursor.com> * fix(settings): align help controls and tighten spacing Co-authored-by: Cursor <cursoragent@cursor.com> * release: prepare MemHub 1.0.4 build 8 Co-authored-by: Cursor <cursoragent@cursor.com> * fix(memhub): clear pre-existing dev lint errors and flaky SDK dedup tests Three things blocking CI that came in with dev and are unrelated to the sedimentation switch itself: - biome errors in DebugLogPanel.tsx (import order) and ModelUsageView.tsx (refreshToken is an intentional refresh trigger, annotated like the existing modelVersion trigger in R6Settings). - test_extractor_prompt_override.py's fake LLM now accepts keyword args the real pipeline passes since the usage audit landed (audit_stage). - the fake embeddings in the intention dedup tests used the process-random hash(), so two different texts collided roughly one run in 32 and were misread as duplicates; switched to a deterministic md5 index. * fix(cli): count recall characters as code points A recall whose hits contain an emoji outside the BMP was reported as response_invalid even though the data and the search were fine: the CLI cross-checked the response by summing String.prototype.length, which counts UTF-16 code units, against Core's used_characters, which Python's len() counts in code points. One emoji is two units here and one character there, so any hit set with an emoji failed the check. The sibling validator in host-bridge (context-protocol.ts) already counted code points, so the CLI was the odd one out rather than a deliberate choice. - validateContextResponse now sums through characterCount(), which counts code points, matching Core. - Two regression tests: an emoji hit whose used_characters follows code points must stay grounded, and the same response counted as UTF-16 units must still be refused, so the cross-check is not simply loosened. - The contract now states used_characters counts Unicode code points and is not an encoding length, so a client in another language does not repeat the comparison. Verified by reverting the source change: the first test fails on the old implementation and passes with it. Closes #30 * fix(web): keep the model recovery entry reachable while a probe is pending Closes #40 A pending model probe fenced the configuration editor, and the only recovery entry ("核对测试结果") lived inside the area the fence kept shut. Reaching it required opening the form; opening the form required having recovered. People with a stuck probe could not change or repair their model at all. The fence itself was doing its job and still is. What was wrong is that refusal also hid the way out. R6Settings - openConfiguration() now opens the model area whether or not the editor accepts, so the recovery entry inside it is reachable. editProfile() and add() still return false while the fence is up; nothing about the protection changed. - The refusal notice is reworded to match: the configuration cannot be changed yet, and the next step is down in the area that just opened. Saying "cannot be opened" was both untrue now and unhelpful before. ModelSettings - A refused open is remembered instead of dropped. Once the fence clears, the intent is replayed, so the person lands in the form they asked for. Without this they would get a blank new-configuration form the moment the probe reconciled, which invites a duplicate entry. - Replaying only fills fields in. It never sends a request, so no test is re-sent implicitly; "核对测试结果" remains the only thing that does. Tests - R6Settings: with a current model and without one, the recovery entry is reachable while the editor is fenced, and the refusal is still reported. - ModelSettings: after reconciling, the form reopens on the profile that was asked for, and the probe is sent exactly once. - Both new R6Settings cases and the ModelSettings case fail on the previous code. * perf(runtime-control): decide runtime reuse before staging the payload Every App launch copied the whole 373MB bundle into a temp directory and hashed it twice before asking whether the selected runtime could be reused. On a machine that already runs this build the answer is yes and all of that work is thrown away: measured on a release Mac bundle, 6.9s to copy and about 3.8s of hashing (fileDigests, then verifyInstalledDistribution over the same tree). installPackagedRuntime now describes the payload in place first. The staged tree is a byte for byte copy of resources/{core,host-bridge,runtime,web} plus two generated launchers, so the same relative paths and digests can be read without copying anything. reuseSelectedSameBuild takes that description instead of a staged directory, and only a payload that is going to be installed is ever staged. The decision itself is unchanged: it still compares every file digest except bin/node, still repairs the packaged launcher when the App moved, and still raises installed_version_conflict or distribution_hash_mismatch exactly as before. Nothing was replaced by a cheaper fingerprint, because a wrong reuse is what those errors exist to prevent. Hashing also runs through a small worker pool now; the digests are identical and the manifest keeps its sorted key order. New test: describeBundlePayload must equal the manifest the staged copy produces, so moving the decision ahead of the copy cannot decide something different. Verified read-only against the installed release bundle: 1534 files, identical file sets, zero digest mismatches. * perf(desktop): raise a startup window before the runtime and Core come up Opening the App currently shows nothing at all until initialize finishes. On this machine that is 55.6s from desktop.initializing to desktop.ready (about 19s installing and starting the managed runtime, then about 36s for Core to become ready), and window.requested is logged after desktop.ready. A launch that slow with no window reads as a launch that failed, and people click the icon again. startDesktopLifecycle now takes two optional hooks. showStartupWindow runs before initialize and loads a placeholder; revealStartupWindow runs after initialize and swaps that same window onto the real app. Because the window is reused rather than replaced, there is no second window and no flash. The placeholder is served from the app protocol as /__startup, in memory, not as a file in the web bundle. It performs no IPC: it renders before initialize has registered a single handler, so anything it asked for would fail and leave the page in an error state for the whole wait. That route is also reserved, so a file of the same name inside the bundle can never be reached through it. Raising the placeholder is best effort. It only fills a wait that would otherwise be blank; failing to draw it must not stop the services or the real window. Tests: five lifecycle cases cover the ordering (placeholder before initialize, reveal after, reuse of the same window, nothing for a background launch, and a real window when the placeholder was closed or could not be raised). The four suites that mock ./app-protocol now spread the real module instead of whitelisting it, which is what broke when the protocol gained exports. host-control-ownership gains the BrowserWindow methods the placeholder path uses, and its "no window" assertion now names the placeholder, since a placeholder window is expected there by design. * fix(core): stop the sedimentation switch failing its own request Turning the switch off answered "停止未能确认，模型可能仍在整理记忆，请重试" every time. The value was saved and the error was a lie the endpoint told afterwards: `put_sedimentation` logged `memory_sedimentation.toggled` with `details={"enabled": ...}`, `enabled` is not in the diagnostic allow-list, and `_details` raises. That ValueError escaped the endpoint, so the request is recorded in this machine's log three times as `api.request.failed` / `core.request.unhandled` with `diagnostic_detail_key_invalid`, and the UI took the 500 as an unconfirmed stop. Because the raise sits between the save and the resume, starting again was broken the same way: `resume_allowed()` never ran, so work parked by a stop stayed parked. Three changes, in the order they matter: 1. `enabled` is now a legal detail key. It is a bounded boolean, the same shape as `spawned` and `index_complete`. 2. `diagnostic_event` no longer lets a rejected payload reach the caller. It already swallowed `OSError` with the comment "Diagnostics must not become a new product outage"; an unlisted key is the same failure seen from the caller, and it is exactly what turned every external recall into a 500 and then killed the process last time. The payload is still wrong and still caught in CI — now by every module rather than five. 3. `test_diagnostic_payload_keys.py` walks every module instead of a hand-picked list. The two payloads that caused real outages were in files nobody thought to add to that list; the only shape of the check that holds the line is "every module, always". This file was already failing on dev with `api.py:3673: unlisted details key 'enabled'` — the bug was known to the suite and shipped anyway. `DiagnosticLog.write` still raises, so the rejection itself is unchanged and still tested; only the callers are protected. * fix(core): let the drain claim a manual note's job A memory added by hand stayed on "原话已保存，等待整理" indefinitely, with `task_id: null`: the note's durable job was never claimed, so no task was ever created for it. On this machine the job is still `pending` with `attempts=0` more than eight hours after it was saved, while the write gate admits its source without complaint. The drain had two different answers to one question. `source_writes_permitted` is `_source_writes_on`, which admits `one-memory-manual` by its grant. The claim gate was `_config_store(app).sync_enabled`, the per-app toggle, and `one-memory-manual` is not a connected app: it never appears in the configuration document, so that predicate answers False for it. The job survived the `enabled_sources` prefilter and was then dropped row by row, on every tick, forever. Nothing ever failed and nothing ever ran. The claim gate now asks the same question the write gate asks. Admission is one decision; giving it two predicates is what parked the work. Two tests pin it. One builds the drain as the composition root does and shows the job is claimed, and shows the shipped wiring stranding the same job, so the regression is visible if the toggle comes back. The other records the asymmetry itself: `_source_writes_on` is True for the manual source while `sync_enabled` is False, which is why the pair could disagree at all. No migration and no reinstall: existing pending jobs are picked up on the next drain tick. * fix(memhub): make sedimentation pause stop model dispatch Co-authored-by: Cursor <cursoragent@cursor.com> * feat(memhub): schedule memory writes by event time Co-authored-by: Cursor <cursoragent@cursor.com> * fix(core): answer the sedimentation switch before the backlog walk Turning "用模型沉淀记忆" back on wrote the choice to the store and then awaited `resume_allowed()` inside the PUT handler. That call is not a nudge: it runs maintenance over every unfinished task and then a whole-queue scan, and the bounded scan waited -- holding the scan lock -- for the queue to drop under its cohort ceiling. With a real backlog the queue never drops, so the request never returned: one toggle in the field is still open 20+ minutes later with no `api.request.completed`, while the renderer gave up at its 30s timeout and showed "启用未能确认，仍显示上次确认的状态；请重试。" for a switch that had in fact been saved. The choice is the durable fact; the walk is follow-up work: - The handler now stores the choice and returns it, and starts the resume as a watched background task (same idiom as the other Core background walks). Repeated toggles reuse the running walk instead of stacking. - A bounded scan now stops at its ceiling instead of sleeping under the scan lock waiting for capacity, which also un-starves the periodic scan that was queued behind it. It reports `queue_saturated` rather than `no_tasks`, so the status stops claiming there is nothing to do while hundreds wait. Verified on the field log first: the failing toggle is the only request in the window with `api.request.started` and no `api.request.completed`, and its trace shows `memory_sedimentation.toggled` succeeded 6ms in at `pending_count` ~500. New tests fail on the old code (timeout) and pass now. * fix(core): stop a blank author from erasing a whole conversation A user turn whose host did not say who wrote it carries `written_by=unknown`. The write binding's allow-list had every other role/author pair but not that one, so verifying the context raised `hy_memory_write_verification_context_scope` and the task ended as `model_content_outcome_unknown` after two attempts: a memory the model may well have written, that can never be confirmed, and a conversation that is never sedimented again. This is not a rare shape. On this machine 1078 user records across 1002 WorkBuddy conversations are `unknown`, and the failures were 42 per 15 minutes in the field log — every one of them a task reporting `result_count=0` while 402 sat pending. The author is missing, not the turn: the record is still inside the same conversation, workspace and source, which is what the binding actually checks, and the turn assembly already sent it. Accepting it here puts the verification back in agreement with what was sent, the same reasoning that added ("user", AGENT) for sub agent questions. New test fails on the old code at hy_source_context.py:76 — the same frame as the field stack — and passes now. * fix(core): stop an abandoned read reporting a failure nobody owns `in_read_pool` shields the wrapped worker, so a lane that runs out of budget gives up on the answer without yanking a query out from under SQLite. The caller cancels; the read runs on. When such an abandoned read then failed, nothing awaited its future any more: `shield` drops its inner callback as soon as the outer future is cancelled, so the inner future finished with an exception that nobody retrieved. asyncio reports that at GC, and the loop handler files it as `core.loop.task_exception` -- a red error sitting next to a lane that had already degraded on its own budget and already said so. On this machine that is the `raw_context_timeout` pair in the field log: a Future, not a Task, carrying TimeoutError('raw_context_timeout'), reported three times in half an hour. The lane result itself was right; only the diagnostics were arguing with themselves. Retrieving the outcome on completion keeps the diagnostics honest without hiding anything: awaiting the read still raises for a caller who waited, which the second case pins down. The new case fails on the previous code (it reports the TimeoutError) and passes now. * fix(core): one task with no inputs no longer strands every unknown task `MemoryTaskRunner._request` falls back to `chunk[0]` when no record is a person-written user turn. A task whose inputs are gone yields an empty chunk, so that fallback raised IndexError -- an error no caller can read. A reconcile pass catches domain errors per task and moves on, so IndexError did not skip the task: it ended the pass, and every unknown task behind it stayed unknown while the retry backed off 1, 2, 4 ... 128 and gave up. On this machine 68 of 303 unknown tasks had no inputs, which is exactly the `reconcile_unknown / error_type=IndexError` backing off in the field log. Those 68 cannot be reconciled either way -- there is nothing to ask HY about -- but the 235 that can must not be held hostage to them, and this is what stands between a task whose model write may already have landed and its confirmation. An empty chunk is now a domain error, so the pass skips the task and continues. Also folds in one formatting hunk left over in this file from the previous change, so the formatter is clean again. The new case fails on the previous code at memory_processing.py:1036 with the same IndexError the log shows, and passes now. * chore(memhub): bump release build number to 10 The installer refuses a package whose bytes differ while its build number stays the same, so the four Core fixes on dev need their own number to be installable over the 1.0.4 / build 9 package already on the machine. * fix(core): retire a window whose remaining rows FIFO refuses The event-time window asked only whether its ten-minute range still held *some* pending row before deciding the anchor was still active. A pending row that FIFO holds back is not claimable: it may be blocked by an earlier sibling of the same Harness whose own event time sits outside the range, and that sibling can never be claimed from inside this window. The anchor then stayed pinned forever and the whole queue starved. Live shape on one machine: the anchor sat on 2026-10-07T03:24Z while the four pending rows inside it were blocked by 929/930/1243/2347 earlier workbuddy jobs, the earliest of them dated 2026-03-12. Completions stopped at 09:59 and 3.8k queued turns sat at zero output; restarting does not help because the anchor is persisted. The contract (docs/contracts/memory-event-time-scheduling-v1.md) retires a window once every *eligible* pending/running row in the range has settled or parked, and re-anchors on the next oldest eligible job. Reuse the claim's own predicate — free lease, no busy Harness, no earlier unsent sibling — so "the window is busy" and "the window can still be worked" finally agree. Anchor selection and in-window selection already used it; only the liveness check did not. * fix(core): a refused source context is a failure, not an unknown write Issue #44: an OpenCode import carried `role=user, written_by=unknown`. The role/author set now admits it, but the row still never moved: `HyWriteBindings` is built inside `ingest`, and the invocation marker is recorded *before* that call, so the refusal arrived with the marker already set. The classifier checked `hy_invoked` first and parked the task as `unknown` — a state that means "HY may hold a write we cannot confirm" about a request that provably never reached HY. The reason stayed off the row, the task could not be re-driven, and the queue behind it stopped. `hy_memory_write_verification_context_scope` is raised from that construction alone, and `_check_source_context` (which does run after the call) raises `hy_memory_evidence_changed` instead, so the code is unambiguous: nothing was sent. It joins `PRE_SEND_REFUSAL_CODES`, and both classifiers now test that set before the marker: the durable path settles `failed` with the marker cleared so reclaim does not treat a row HY never saw as possibly-sent, and the task path fails with the code instead of marking unknown. Regression covers both directions: a pre-call refusal must end `failed` with `hy_invoked=0`, and a post-call refusal (`authority_invalid`) must still be `unknown` — the fix narrows the unknown set, it does not widen the failure set. * chore(memhub): bump release build number to 11 Carries the window starvation fix ( |
||
|
|
20b92d8a89 |
release: prepare MemHub 1.0.3 (#33)
Co-authored-by: alvinfei <alvinfei@tencent.com> Co-authored-by: Cursor <cursoragent@cursor.com> |
||
|
|
f79770cdb0 |
release: prepare MemHub 1.0.2 (#19)
Co-authored-by: alvinfei <alvinfei@tencent.com> Co-authored-by: Cursor <cursoragent@cursor.com> |
||
|
|
268ad16d26 |
release: prepare Hy Memory 2.0.2 and MemHub 1.0.1 (#15)
* release: prepare Hy Memory 2.0.2 and MemHub 1.0.1 Co-authored-by: Cursor <cursoragent@cursor.com> * fix(memhub): retry grant reads across atomic replacement Co-authored-by: Cursor <cursoragent@cursor.com> --------- Co-authored-by: alvinfei <alvinfei@tencent.com> Co-authored-by: Cursor <cursoragent@cursor.com> |
||
|
alvinfei
|
fba347ad8d | Initial open source release |