Commit the LongMemEval v4 driver byte-exact for the A17 rerun (D2h, C4) by seathatflowsinourveins · Pull Request #386 · native-agent-stack/native-agent-stack

seathatflowsinourveins · 2026-09-27T05:51:20Z

Scope

What this PR changes: adds the LongMemEval-S harness v4 driver (D2h, C4, the A16 arms) byte-exact under blueprints/memory-stack/longmemeval/v4/, extracted from the private agent-ecosystem repository for the workstation's amendment A17 rerun.
Host request: [mac-coordinator] memory E2E: clean agentmemory 0.9.29 beside ai-memory, C4/D2h arms and token-efficiency measurement #384
Base commit: 6454424a8821c833e272d28ce791da2b9146e043 (this branch's original fork point; kept current with main twice since, under the hot-file protocol: at 9a24f7a4, manifests/evidence.json was taken from main and this branch's files re-registered; at 7f48d7d3 this round, git merge origin/main resolved the same file cleanly with no conflict, confirmed after by validate.py and a count of all 28 v4 entries)
Lane: lane:foundation
Owned paths touched: blueprints/memory-stack/longmemeval/v4/**, docs/decisions/2026-09-25-longmemeval-frozen-npm-lock.md, manifests/evidence.json

SOTA sources

LongMemEval-S retrieval benchmark: xiaowu0162/LongMemEval at 9e0b455f4ef0e2ab8f2e582289761153549043fc (MIT). Imported by lme_harness.py at run time, not copied.
Transferred-file source: the private agent-ecosystem repository, branch claude/longmemeval-velanext-lane-20260925, commit 576689af6f5e5f4d85013c7c4bed3b8f7c92f57d, directory evals/longmemeval/. Per-file blob ids are in the directory's README.md Files table.
Pattern followed: Commit the Mac LongMemEval-S harness and preregistration byte-exact (#274) #380, which committed the v3 harness byte-exact under blueprints/memory-stack/longmemeval/ for host request [mac-coordinator] other: commit the memory-stack LongMemEval harness and preregistration for the NativeStack rerun #274. Commit the Mac LongMemEval-S harness and preregistration byte-exact (#274) #380 has since merged to main.
Lockfile-freeze rationale: docs/decisions/2026-09-25-longmemeval-frozen-npm-lock.md, extended by this PR's addendum (see Decision record below).

Evidence-class table

Claim	Evidence class	Command / receipt
The 25 copied files match `evals/longmemeval/<path>` at `agent-ecosystem@576689a`, byte-exact	`source_review`	`git rev-parse 576689a:evals/longmemeval/<path>` against each file's blob id in the README; sha256 against `SHA256SUMS`
`PREREGISTRATION.md` matches the required hash	`source_review`	sha256 `a9b1db335eee1ff99d1883e048bcd8e443ca2afee3505a34fd874dd1ef412d5b`, verified before the first commit was written
Which code implements D2h, C4, the X arms and the A16 arms	`source_review`	reading `lme_harness.py` and `rerank_stage.py` directly (the directory README's "Which arms" section corrects the task's premise that C4 runs through `rerank_stage.py`: C4 is implemented in `lme_harness.py` itself; `rerank_stage.py` implements the separate, never-decided X arms)
The shared-host warning's claims about `_ours`, `am_teardown`, `am_start`, `mp_mine_pids`/`_pid_alive`/`mp_kill_mines`, `stop_bg`/`same_process`, and `setup_velanext.sh`'s readiness loop — name/liveness checks, not ownership checks	`source_review`	reading each function directly at the line numbers the README cites
The three `lme_harness.py` teardown gaps above, reproduced rather than only read	independent observation	GPT-6 cross-family review at `97697b81` (PR comment): "An inert reproduction confirmed SIGKILL in all three cases"
No D2h, C4 or K1 run through this driver can pass `run_velanext.sh gates` from this directory without the three excluded Modelfiles	`source_review`	reading `require_gates`/`cmd_gates`/`cmd_cpu`/`cmd_arms`/`cmd_a16` and `llama_llm_up` directly (README "Which arms"/"Not transferred" sections)
The six `.frozen` locks' real dependency exposure under their plain names, and that the five `requirements/*.lock.txt.frozen` files keep out of the required `osv-scanner` inventory (`dependency-review` does not recognize any of the six plain names as a manifest either way)	`local_integration`	`osv-scanner scan source --config .github/osv-scanner.toml --no-resolve` (2.6.0) on plainly named scratch copies, with a discriminating control on `.frozen`-named copies ("No package sources found", exit 128); full counts in the decision record's 2026-09-27 addendum
`--help` for `lme_harness.py` and `lme_summarize.py`	`local_integration`	clean clone of the pushed branch, fake HOME holding only the pinned LongMemEval checkout, `env -i HOME=<fake> PATH=/usr/bin:/bin`; both exit 0 (below)
No private path, identity, credential or session id in the changed files	`local_integration`	`scripts/validate.py --scan-file`, `gitleaks-guarded-macos`, and the discriminating controls `tests.test_validate.ScanFileForPrivateContentTests.test_cli_scan_file_fails_on_a_planted_secret_without_echoing_it` and the gitleaks planted-key check in `docs/secret-storage.md` step 5b (both fail on a fabricated key, confirming the passing scans below are not vacuous)
Any benchmark result	none new	no arm ran for this commit

Local commands run

Original commit (97697b81):

$ python3 scripts/validate.py --scan-file <each of the 24 transferred files> [combined and individually]
{"scanned_files": 24, "status": "passed"}   (combined; each file individually also passed alone)
exit 0

$ adoption/tools/gitleaks-guarded-macos dir blueprints/memory-stack/longmemeval/v4 --config .gitleaks.toml --max-target-megabytes 2 --redact --no-banner
no leaks found
exit 0

$ env -i HOME=<fake> PATH=/usr/bin:/bin "$HOME/.local/share/agent-ecosystem/bench/longmemeval/.venv-official/bin/python" lme_harness.py --help
usage: lme_harness.py [-h] [--limit LIMIT] [--ids [IDS ...]] [--workers WORKERS] [--out OUT] [--pooled] arm
exit 0

$ env -i HOME=<fake> PATH=/usr/bin:/bin "$HOME/.local/share/agent-ecosystem/bench/longmemeval/.venv-official/bin/python" lme_summarize.py --help
usage: lme_summarize.py [-h] [--incumbent INCUMBENT] [--out OUT] [--final] [--results RESULTS] ...
exit 0

<fake> is a fresh temporary directory holding only a git clone of xiaowu0162/LongMemEval checked out to 9e0b455f4ef0e2ab8f2e582289761153549043fc; both scripts import nothing else at module load (numpy, stdlib, and the official checkout via a try/except that only raises if the arm actually runs), so no other install was needed.

GPT-6 review round (97697b81 → 9280f911 → ddf4b245; addressed 1 high / 2 medium / 1 low, all README-only, no frozen file touched): added ollama/qwen3.5-9b-64k.Modelfile, verified git hash-object against source blob de951c96 and line-identical to the extracted source; shasum -a 256 -c SHA256SUMS 27/27 OK; the four unittest modules below OK; git diff --check exit 0. Full per-finding notes are in the PR comments.

This review-fix round (current head), after merging origin/main (bringing #380 in) and applying this round's findings — a decision-record addendum, README.md corrections, and this file:

$ osv-scanner scan source --config .github/osv-scanner.toml --no-resolve --lockfile=requirements.txt:<plain-named copy> [x5] --lockfile=package-lock.json:<plain-named copy>
Per lock (unfiltered / with this repository's `osv-scanner.toml`): official 64 packages, 9/9 vulnerable, 115/114 unique advisories; embed 91, 3/2, 3/2; mempalace 80, 1/1, 4/4; hindsight 223, 0, 0; build 3, 0, 0; agentmemory-repo 376, 2/2, 2/2. The repository's two ignores are global by advisory ID (OSV-Scanner 2.6.0 `ShouldIgnore`), so they filter GHSA-8mgp-746c-j5xp (nltk 3.9.1, official) and GHSA-h35f-9h28-mq5c (setuptools 81.0.0, embed) here too.
exit 1 (vulnerabilities found; full counts in the decision record addendum)

$ osv-scanner scan source -r <same six files under their committed .frozen names>
No package sources found
exit 128

$ shasum -a 256 -c SHA256SUMS      (in blueprints/memory-stack/longmemeval/v4/)
27 files: OK
exit 0

$ python3 scripts/validate.py --scan-file blueprints/memory-stack/longmemeval/v4/README.md --scan-file blueprints/memory-stack/longmemeval/v4/SHA256SUMS --scan-file docs/decisions/2026-09-25-longmemeval-frozen-npm-lock.md
{"scanned_files": 3, "status": "passed"}
exit 0

$ adoption/tools/gitleaks-guarded-macos dir blueprints/memory-stack/longmemeval/v4 --config .gitleaks.toml --max-target-megabytes 2 --redact --no-banner
$ adoption/tools/gitleaks-guarded-macos dir docs/decisions --config .gitleaks.toml --max-target-megabytes 2 --redact --no-banner
no leaks found (both)
exit 0

$ python3 -m unittest tests.test_validate.ScanFileForPrivateContentTests
Ran 9 tests ... OK

$ python3 scripts/validate.py
{"components": 69, "hashed_files": 7278, "profiles": 4, "receipts": 159, "status": "passed"}
exit 0

$ python3 scripts/host_receipts.py validate
{"receipts": 167, "status": "passed"}
exit 0

$ python3 scripts/component_matrix.py --write
{"flip_rule_violations": 0, "rows": 32, "status": "written"}
exit 0

$ python3 scripts/new_host_grand_list.py --write
{"status": "written", "layers": 32, "winners": 66}
exit 0

$ git diff --check
exit 0

$ python3 -m unittest tests.test_osv_lockfile_coverage tests.test_adoption_docs_consistency tests.test_verdict_review_gate tests.test_workflow_security_coverage
Ran 221 tests ... OK (skipped=1)
exit 0

CI at the previous head (ddf4b245): every required check passed except validate, which failed on tests.test_adaptive_paper_metrics.FileSdRegistrationTests.test_a_clean_stop_of_an_unfinished_trial_stays_registered ("exporter never registered its target") — a trading-lane test (docs/lanes.md's test_adaptive_*.py) this PR's diff does not touch (git diff --name-status origin/main...HEAD at that point showed only blueprints/memory-stack/longmemeval/v4/** and manifests/evidence.json). validate.yml's last 5 runs on main are all green, so this looks like a runner-timing flake rather than something this PR caused; this push reruns CI fresh.

Decision record

docs/decisions/2026-09-25-longmemeval-frozen-npm-lock.md is now on main (#380 merged). This PR adds a dated 2026-09-27 addendum to it, extending its scope from the two agentmemory/*.frozen files to this driver's six additional *.frozen files (the five requirements/*.lock.txt.frozen and vendor/agentmemory-repo-package-lock.json.frozen), with the same kind of evidence the original record used: an osv-scanner run on plainly named scratch copies, the advisory list, and a discriminating control against the .frozen names. Highlights (counts read unfiltered / with this repository's osv-scanner.toml, whose two ignores are global by advisory ID): official.lock.txt alone carries 115/114 unique advisories across 9 of its 64 packages (nltk 43/42, transformers 26, torch 20, pillow 15, jinja2 4, and others); mempalace.lock.txt's chromadb 1.5.9 carries 4, including a pre-authentication code-injection advisory; embed.lock.txt carries 3/2 (the difference is GHSA-h35f-9h28-mq5c on setuptools 81.0.0; nltk's is GHSA-8mgp-746c-j5xp); the npm lock repeats the exact pair the original record already found in the smaller install-prefix lock; hindsight.lock.txt and build.lock.txt show none at scan time. The addendum's "What the rename does not do" section is explicit that none of this makes the pinned packages safe to run — only unscanned by the required checks, as records of a fixed, historical (or to-be-measured) environment.

Not transferred

Nothing was excluded for failing the private-content scan; all transferred files, plus this directory's README.md and SHA256SUMS, passed it individually and combined. Out of this task's requested scope, and listed with sha256 and reasons in the README's "Not transferred, and why": LANE.md, the source directory's own README.md, eligible-manifest.json, agentmemory/package.json + package-lock.json, and run_official_oracle.py (byte-identical to files #380 already carries, now on main; not duplicated here); embed_cache_proxy.py (a v4 revision, not byte-identical to #380's frozen v3 copy, not requested — an arm needing the byte-exact cache cannot run from this directory alone without it); embed_gates.json; ruff.toml; reference/v3-check-ids.txt; reference/mac-rows/*.jsonl (result rows); and three of the original four ollama/*.Modelfile (lfm2.5-2.6b-64k, nemotron-3.5-lightning-30b-a3b-64k, qwen3.6-35b-a3b-64k — each an H-arm reranker LLM, and qwen3.6-35b-a3b-64k doubles as K1's LLM). qwen3.5-9b-64k.Modelfile (blob de951c96) is transferred (Files table in the README): the GPT-6 review found it is a C4 prerequisite, not outside D2h/C4 as an earlier revision of the README said. The README's new "Before anything runs" section spells out that the three still-excluded Modelfiles, eligible-manifest.json, the agentmemory install files, embed_gates.json and reference/v3-check-ids.txt are all read by run_velanext.sh gates, so no D2h, C4 or K1 run passes gates from this directory alone without them.

Host evidence

Not applicable, no component ran and no evidence/hosts/ file changed.

python3 scripts/host_receipts.py validate — n/a to this PR's own paths, but run above at the current head (167 receipts, passed) as part of the hot-file protocol.
Independent review recorded via scripts/host_receipts.py review — n/a; see Review below instead.
No platform_status change is made.

Checklist

No new/changed GitHub Actions in this PR.
No new/changed workflows in this PR.
No secrets are printed, logged or committed; no new required secret was added (gitleaks: no leaks; discriminating controls above).
No new paid hosting, subscription or billing surface was introduced.
Peer-owned untracked files and worktrees were preserved (only blueprints/memory-stack/longmemeval/v4/**, docs/decisions/2026-09-25-longmemeval-frozen-npm-lock.md and manifests/evidence.json were touched).

Review

An Opus same-host review will follow. The GPT-6 cross-family review runs from the workstation when capacity returns; this PR waits for that verdict before merge.

Related: #384, #380, #274

🤖 Generated with Claude Code

blueprints/memory-stack/longmemeval/v4/: the harness v4 driver (lme_harness.py, lane_tools.py, lme_summarize.py, pins.json), the v3 equivalence reference (reference/lme_harness_v3.py), the X-arm and embedding-server tools (rerank_stage.py, embed_server_st.py, gguf_embed_front.py, mteb_lmeb.py), the VelaNext drivers (run_velanext.sh, setup_velanext.sh), PREREGISTRATION.md (hash-verified against a9b1db33...), the k1-subset.json question-id subset, the five requirements/*.in + *.lock.txt(.frozen) pairs, and vendor/agentmemory-repo-package-lock.json.frozen. Extracted byte-exact from the private agent-ecosystem repository, branch claude/longmemeval-velanext-lane-20260925, commit 576689a, per host request #274 and #384, following the pattern of #380 (not yet merged). The five requirements/*.lock.txt files match this repository's TRACKED lockfile pattern and are stored as .frozen for the same reason #380 freezes its npm lock (docs/decisions/2026-09-25-longmemeval-frozen-npm-lock.md, still on #380's branch); official.lock.txt additionally pins nltk==3.9.1, which would also trip the repo-wide ignore-scope test if scanned live. vendor/agentmemory-repo-package-lock.json.frozen does not itself match that pattern but is frozen under the same rationale per this task's directive. README.md corrects the task's premise that C4 runs through rerank_stage.py: C4 (aimem-qwen3-rerank) is implemented in lme_harness.py itself via its LLM reranker path (LLM_URL, A12); rerank_stage.py implements the separate, non-decided X arms. It also documents each teardown function's actual ownership checks (am_teardown, mp_kill_mines, run_velanext.sh's stop_bg/same_process) against the code, not its docstrings, and lists what was left out of transfer scope and why (eligible-manifest.json, the agentmemory install lock and run_official_oracle.py are byte-identical to #380's copies and are not duplicated; embed_cache_proxy.py at 576689a is a changed v4 revision not in this task's requested file list). Checks: private-content scan (24/24 new source files plus README.md and SHA256SUMS, individually and combined), gitleaks-guarded-macos (no leaks), SHA256SUMS self-check, component_matrix.py --check, new_host_grand_list.py --check, validate_catalogs.py, git diff --check, scripts/validate.py (7173 hashed files), and the targeted unittest modules (221 tests, 1 skipped, all passing). Co-Authored-By: Claude Sonnet 5 <[email protected]>

seathatflowsinourveins · 2026-09-27T06:05:57Z

GPT-6 cross-family review at 97697b81: VERDICT: needs_changes (1 high, 2 medium, 1 low)

Setup: gpt-6-astra, effort max, read-only, run from the workstation. It reproduced behaviour with inert probes rather than only reading.

The high and medium findings are in the frozen, byte-exact v4 code. As with #380, the fix for this PR is accurate README warnings. The safe execution belongs in the workstation rerun's own code (A17). Don't edit the frozen files.

[high] lme_harness.py:749: teardown does not establish ownership.

_ours() at :701 accepts any command containing agentmemory or a matching iii executable name.
An empty or failed ps result also passes.
am_start() calls the cleanup with proc=None at :800, so it can SIGKILL another workload before starting its own process.
An inert reproduction confirmed SIGKILL in all three cases.
README.md:46-51 wrongly says the empty-command-line case is the only gap. Please correct it.

[medium] setup_velanext.sh:220: readiness accepts any Ollama server on port 11438. If its own server fails to bind, curl can succeed against an existing server, and :224 then sends that server model pulls. There is no child-liveness or port-ownership check.

[medium] lme_harness.py:1149: MemPalace cleanup trusts numeric PID files without checking process identity. mp_mine_pids() checks only kill(pid, 0) before mp_kill_mines() calls killpg, so a reused PID can receive SIGKILL.

[low] README.md:234: the excluded Modelfiles are described as outside D2h and C4. But pins.json:146 assigns qwen3.5-9b-64k.Modelfile to C4, and run_velanext.sh:654 starts that alias, so the README understates C4's prerequisites.

Verified:

sha256sum -c SHA256SUMS: 26 of 26 pass. All 24 transferred files match the README's source-blob prefixes, and the provenance names the repository, branch, full commit, exclusions and reasons.
Gitleaks: no leaks. No private hostname, email, credential or personal path.
D2h reproduces agentmemory v0.9.29's hook sequence (plugin/hooks/hooks.json at 2d38dafe): SessionStart, user observations, Stop, SessionEnd. It does this by HTTP emulation, which is documented.
C4 uses ai-memory's native LlmReranker (serve.rs at 19b6429b). rerank_stage.py belongs to the separate X arms.
Setup downloads use pinned commits, hashes or locks.
validate.py and git diff --check: exit 0.

A17 (the workstation rerun) must add, recorded here for the rerun:

Isolated runner: owned ports, stores and process identities; it fails closed on unreadable process information, and applies identity checks to PID-file and process-group cleanup too.
Inputs to carry into the rerun:
- the adjacent eligible-manifest.json;
- the pinned dataset and official checkout;
- the agentmemory install-prefix package files;
- runtime copies of the .frozen locks under their expected filenames.
Embed cache proxy: the v4 embed_cache_proxy.py (sha256 e08e11f8…), or a preregistered decision to omit it. Commit the Mac LongMemEval-S harness and preregistration byte-exact (#274) #380's different proxy is not a substitute.
D2h pins:
- agentmemory 0.9.29@2d38dafe;
- iii 0.11.2;
- the Node and dependency locks;
- Xenova MiniLM q8 at 751bff37, keeping install_minilm cache staging.
C4 pins:
- ai-memory 19b6429b;
- the Qwen3-Embedding-4B and Qwen3.5-9B Q4_K_M digests (pins.json:129-146);
- the missing qwen3.5-9b-64k Modelfile;
- reasoning low;
- Ollama 0.34.4@b2da9e46;
- llama.cpp b11146@7fe450e1.
Statistics: confirmatory analysis for n=470 and n=419, at α=0.0333 per C3/C4 family and 0.0167 for A16 (D2h included), per A15.2.

Verified each finding against the frozen code before editing; only README.md, SHA256SUMS and one new file change, nothing frozen is touched. [high] lme_harness.py's teardown does not establish ownership. _ours() (:698-701) accepts any command merely containing the substring "agentmemory", or the configured iii path/basename; am_teardown() (:749) also treats an empty `ps` result as "ours"; am_start() (:797-800) calls that same teardown with proc=None before it has started anything, so it can SIGKILL a foreign process before owning anything. The README wrongly called the empty-command case "the one gap" and said the functions check ownership; it now describes the actual name/liveness matching and ends with a plain warning: do not run lme_harness.py, run_velanext.sh or setup_velanext.sh on a shared host. A17's runner is where isolated ports/stores and identity-checked cleanup belong. [medium] Two warnings added, both verified by reading the code directly: - setup_velanext.sh:220's readiness loop accepts any Ollama server that answers on port 11438, with no check that it is the oll_pid process just started; :222-224 then pulls models, and :228-229 creates aliases, against whichever server answered. - lme_harness.py's mp_kill_mines() (:1149) trusts mp_mine_pids() (:1045), which only checks _pid_alive() (:1035, kill(pid, 0)) with no identity check, then killpg()s the whole process group; a reused PID's group can be hit. [low] pins.json:146 and run_velanext.sh:654 confirm qwen3.5-9b-64k.Modelfile is a C4 prerequisite (also used by the A15.2 F arms and the pooled aimem-qwen3-rerank stage), not outside D2h/C4 as the README said. Transferred it byte-exact from the private agent-ecosystem repository at 576689a (evals/longmemeval/ollama/qwen3.5-9b-64k.Modelfile, blob de951c9, git hash-object verified against the source blob id), added to SHA256SUMS and the Files table. The other three Modelfiles stay excluded and are now named individually with size/sha256/blob: lfm2.5-2.6b-64k.Modelfile (H3), nemotron-3.5-lightning-30b-a3b-64k.Modelfile (H2), qwen3.6-35b-a3b-64k.Modelfile (H1, and K1's LLM via H1_BUILD at run_velanext.sh:68) -- verified against lme_harness.py's H_RERANK_MODELS and run_velanext.sh's matching loop, not asserted from memory. Checks: shasum -a 256 -c SHA256SUMS (27/27 OK), python3 scripts/validate.py --scan-file on README.md/SHA256SUMS/the new Modelfile, and adoption/tools/gitleaks-guarded-macos over the whole directory (no leaks). Co-Authored-By: Claude Sonnet 5 <[email protected]>

manifests/evidence.json: took main's copy and re-registered this branch's 28 blueprints/memory-stack/longmemeval/v4/** files (the 27 previously registered plus the new ollama/qwen3.5-9b-64k.Modelfile), then reran component_matrix.py --write and new_host_grand_list.py --write (no content change; both were already current). Co-Authored-By: Claude Sonnet 5 <[email protected]>

socket-security · 2026-09-27T07:11:07Z

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	pypi/nltk@3.9.1
	pypi/pillow@10.2.0
	pypi/torch@2.3.1
	pypi/transformers@4.43.3
	pypi/setuptools@84.0.0
	pypi/numpy@1.26.3
	pypi/tqdm@4.66.4
	pypi/torch@2.11.0
	pypi/mempalace@3.10.0
	pypi/transformers@5.7.0
	pypi/protobuf@5.27.1
	pypi/sentencepiece@0.2.0
	pypi/pyarrow@16.1.0
	pypi/huggingface-hub@0.23.4
	pypi/torchvision@0.18.1
	pypi/hindsight-api@0.10.1
	pypi/joblib@1.4.2
	pypi/sentence-transformers@2.2.2
	pypi/scikit-learn@1.5.1
	pypi/sentence-transformers@5.7.0
	pypi/multiprocess@0.70.16
	pypi/jinja2@3.1.3
	pypi/openai@1.35.1
	pypi/mteb@2.21.8
	pypi/requests@2.32.3
	pypi/wheel@0.48.0
	pypi/safetensors@0.4.3
	pypi/tiktoken@0.7.0
	pypi/tokenizers@0.19.1
	pypi/regex@2024.5.15
	pypi/backoff@2.2.1
	pypi/httpx@0.27.2

View full report

socket-security · 2026-09-27T07:11:09Z

Warning

Review the following alerts detected in dependencies.

According to your organization's Security Policy, it is recommended to resolve "Warn" alerts. Learn more about Socket for GitHub.

Action	Severity	Alert (click "▶" to expand/collapse)
Warn		Critical CVE: NLTK: Unsafe Pickle Deserialization in TransitionParser Allows Remote Code Execution CVE: GHSA-rhp5-r9x4-f5g2 NLTK: Unsafe Pickle Deserialization in TransitionParser Allows Remote Code Execution (CRITICAL) Affected versions: < 3.10.0 Patched version: 3.10.0 From: blueprints/memory-stack/longmemeval/v4/requirements/official.in → `pypi/[email protected]` ℹ Read more on: This package \| This alert \| What is a critical CVE? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at `[email protected]`. Suggestion: Remove or replace dependencies that include known critical CVEs. Consumers can use dependency overrides or npm audit fix --force to remove vulnerable dependencies. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment `@SocketSecurity ignore pypi/[email protected]`. You can also ignore all packages with `@SocketSecurity ignore-all`. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.
Warn		Critical CVE: NLTK: Allowlisted pickle loaders still permit code execution in current source CVE: GHSA-x99w-6fgc-pmfw NLTK: Allowlisted pickle loaders still permit code execution in current source (CRITICAL) Affected versions: < 3.10.3 Patched version: 3.10.3 From: blueprints/memory-stack/longmemeval/v4/requirements/official.in → `pypi/[email protected]` ℹ Read more on: This package \| This alert \| What is a critical CVE? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at `[email protected]`. Suggestion: Remove or replace dependencies that include known critical CVEs. Consumers can use dependency overrides or npm audit fix --force to remove vulnerable dependencies. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment `@SocketSecurity ignore pypi/[email protected]`. You can also ignore all packages with `@SocketSecurity ignore-all`. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.
Warn		Critical CVE: NLTK has a Zip Slip Vulnerability CVE: GHSA-7p94-766c-hgjp NLTK has a Zip Slip Vulnerability (CRITICAL) Affected versions: < 3.9.3 Patched version: 3.9.3 From: blueprints/memory-stack/longmemeval/v4/requirements/official.in → `pypi/[email protected]` ℹ Read more on: This package \| This alert \| What is a critical CVE? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at `[email protected]`. Suggestion: Remove or replace dependencies that include known critical CVEs. Consumers can use dependency overrides or npm audit fix --force to remove vulnerable dependencies. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment `@SocketSecurity ignore pypi/[email protected]`. You can also ignore all packages with `@SocketSecurity ignore-all`. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.
Warn		Critical CVE: NLTK: JVM argument injection bypass via per-call options in the NLTK Stanford wrappers (incomplete fix of CVE-2026-12841) CVE: GHSA-m4rf-3fr8-xwx3 NLTK: JVM argument injection bypass via per-call options in the NLTK Stanford wrappers (incomplete fix of CVE-2026-12841) (CRITICAL) Affected versions: < 3.10.3 Patched version: 3.10.3 From: blueprints/memory-stack/longmemeval/v4/requirements/official.in → `pypi/[email protected]` ℹ Read more on: This package \| This alert \| What is a critical CVE? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at `[email protected]`. Suggestion: Remove or replace dependencies that include known critical CVEs. Consumers can use dependency overrides or npm audit fix --force to remove vulnerable dependencies. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment `@SocketSecurity ignore pypi/[email protected]`. You can also ignore all packages with `@SocketSecurity ignore-all`. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.
Warn		Critical CVE: PyTorch: `pypi` torch`.load` with `weights_only=True` leads to remote code execution CVE: GHSA-53q9-r3pm-6pq6 PyTorch: `torch.load` with `weights_only=True` leads to remote code execution (CRITICAL) Affected versions: < 2.6.0 Patched version: 2.6.0 From: blueprints/memory-stack/longmemeval/v4/requirements/official.in → `pypi/[email protected]` ℹ Read more on: This package \| This alert \| What is a critical CVE? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at `[email protected]`. Suggestion: Remove or replace dependencies that include known critical CVEs. Consumers can use dependency overrides or npm audit fix --force to remove vulnerable dependencies. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment `@SocketSecurity ignore pypi/[email protected]`. You can also ignore all packages with `@SocketSecurity ignore-all`. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.

View full report

seathatflowsinourveins · 2026-09-27T07:11:18Z

Addressed the GPT-6 review (VERDICT: needs_changes, 1 high / 2 medium / 1 low). README-only fixes, every transferred file stays byte-exact; new head 9a24f7a4.

Verified each finding against the frozen code directly before editing (not from the review's summary alone):

[high] Shared-host warning rewritten. Confirmed _ours() (lme_harness.py:698-701) is a substring match on agentmemory/the iii path/basename, am_teardown() (:749) treats an empty ps result as "ours," and am_start() (:797-800) runs that same teardown with proc=None before starting anything. The README no longer calls the empty-command case "the one gap" or says these functions "check ownership" — it names the three mechanisms and ends with a plain warning: don't run lme_harness.py, run_velanext.sh or setup_velanext.sh on a shared host; A17's runner supplies the ownership-checked path.
[medium] Two warnings added, both confirmed by reading the code: setup_velanext.sh:220's readiness loop accepts any server answering on port 11438 with no check that it's the oll_pid process just started (so :222-224's pulls and :228-229's ollama create can land on a foreign server); and lme_harness.py's mp_kill_mines() (:1149) relies on mp_mine_pids()/_pid_alive() (:1035-1056, plain kill(pid, 0)) with no identity check before killpg().
[low] qwen3.5-9b-64k.Modelfile transferred. Confirmed it's a C4 prerequisite via pins.json:146 and run_velanext.sh:654 (also used by the A15.2 F arms and the pooled aimem-qwen3-rerank stage) — byte-exact from agent-ecosystem@576689a's evals/longmemeval/ollama/ (blob de951c96, git hash-object verified against the source blob id), added to SHA256SUMS and the Files table. The other three Modelfiles stay excluded; the README now names each individually with its role verified against lme_harness.py's H_RERANK_MODELS and run_velanext.sh (H1/H2/H3, and qwen3.6-35b-a3b-64k doubling as K1's LLM via H1_BUILD), not asserted from memory.

Local commands (post-merge, at the new head): shasum -a 256 -c SHA256SUMS (27/27 OK), python3 scripts/validate.py --scan-file on the three changed/added files, adoption/tools/gitleaks-guarded-macos over the directory (no leaks), python3 scripts/host_receipts.py validate, python3 scripts/validate.py, python3 scripts/component_matrix.py --check, python3 scripts/new_host_grand_list.py --check, python3 scripts/validate_catalogs.py, git diff --check — all exit 0 — and the same four unittest modules the PR body ran (221 tests, 1 skipped, OK).

Also merged origin/main (which had moved, including #380) under the hot-file protocol: took main's manifests/evidence.json and re-registered this branch's 28 files.

Aside, out of this fix's scope: the merge means #380 is no longer "not yet merged" as the README's intro and the .frozen-lock section still say, and that section's "no addendum because the decision record lives only on #380's branch" is now stale too — leaving that for a follow-up rather than expanding this fix.

Ready for the GPT-6 re-check at 9a24f7a4.

🤖 Generated with Claude Code

Line ~289's "teardown behavior described above" row still named only the pre-fix set of functions (am_teardown, stop, mp_kill_mines, stop_bg/ same_process). Updated it to list every function and file the rewritten shared-host warning now cites (_ours, am_teardown, am_start, mp_mine_pids/_pid_alive/mp_kill_mines, stop_bg/same_process, setup_velanext.sh's readiness loop), so the table matches the prose above it. Co-Authored-By: Claude Sonnet 5 <[email protected]>

seathatflowsinourveins · 2026-09-27T07:16:55Z

Small follow-up on top of the previous comment: the README's own evidence-class table had a row ("The teardown behavior described above") that still named only the pre-fix function list. Updated it to match the rewritten shared-host warning (_ours, am_teardown, am_start, mp_mine_pids/_pid_alive/mp_kill_mines, stop_bg/same_process, and setup_velanext.sh's readiness loop), re-registered README.md/SHA256SUMS in manifests/evidence.json, and re-ran shasum -a 256 -c SHA256SUMS (27/27 OK), scripts/validate.py, scripts/host_receipts.py validate, scripts/component_matrix.py --check, scripts/new_host_grand_list.py --check and git diff --check — all exit 0.

Final head for the GPT-6 re-check: ddf4b245.

…ongmemeval-v4-driver-20260927

Verified each finding against the frozen code and the merged #380 state before editing; only README.md, the decision record and evidence.json change, no frozen file touched. [should_fix] The "outside D2h/C4" line for the three still-excluded Modelfiles was misleading: run_velanext.sh's `gates` command is mandatory before any arm (require_gates, called by cmd_cpu/cmd_arms/cmd_a16) and smoke-tests all four reranker-LLM tags plus K1 before writing logs/gates/passed.json, so no D2h, C4 or K1 run passes gates from this directory without all three files. README title now matches the PR body's scope (D2h, C4, the A16 arms). [should_fix] #380 has merged to `main` since this PR opened; removed the two "not yet merged"/"lives only on #380's branch" statements. [should_fix] Added a dated 2026-09-27 addendum to docs/decisions/2026-09-25-longmemeval-frozen-npm-lock.md, extending its scope from the two agentmemory/*.frozen files to this driver's six additional .frozen files. Evidence gathered directly: osv-scanner 2.6.0 against plainly named scratch copies (official.lock.txt: 114 unique advisories across 9 of 64 packages, dominated by nltk/transformers/torch/pillow; mempalace.lock.txt's chromadb: 4, including a pre-auth code-injection advisory; embed.lock.txt: 2; the npm lock repeats the original record's 2 OpenTelemetry advisories; hindsight.lock.txt and build.lock.txt: none), plus the same discriminating control the original record used (.frozen names: "No package sources found", exit 128). Also corrected README.md's claim that the .in files are "unpinned" (official.in alone pins 25 of 28 lines) and that TRACKED "does not match" them by design (it is a basename/directory-name technicality, not a deliberate exemption). [should_fix] Added a "Before anything runs" section: eligible-manifest.json, the agentmemory install files, embed_gates.json, reference/v3-check-ids.txt and the six renamed locks are all read by setup_velanext.sh/run_velanext.sh, but are not available from this directory alone. The table gives each file:line that reads it and where to get it (two are byte-identical to files #380 now carries on main; two are not present anywhere in this repository and need the private source; the locks need isolated-prefix restore commands). [nit] Split the evidence-class row that credited "reproducing... with inert probes" to source_review; that reproduction is the GPT-6 review's own independent observation, now cited by its actual PR-comment URL (confirmed via `gh api .../issues/386/comments`, which also confirmed the review's 1 high / 2 medium / 1 low was carried through in full, nothing dropped or narrowed). [nit] Qualified two over-broad safety claims: stop_bg's group-mode signals (the CPU stream) are unconditional, not same_process-guarded; setup_velanext.sh's `kill "$oll_pid"` can hit a reused PID in the failed-bind case, the same gap attributed to mp_kill_mines. [nit] Corrected the LME_HOME/Path.home() claim: LME_HOME itself defaults to this directory (lme_harness.py:87), not Path.home(); only the AE-derived paths do. [nit] Added .gitignore to the SHA256SUMS provenance exception, and noted the plain-name/`.frozen`-name distinction for git-show provenance commands. [nit] Added README notes for the three shared-host/portability gaps that are frozen-code findings, not README claims: two vendor harnesses launch without env -i (run_velanext.sh:563,596-597); lane_tools.py's v3-shim/fetch-hf --pin-main mutate shared state outside their lane-owned wrapper paths; the X arm's kalm-small reranker loads with trust_remote_code=True (mitigated by a pinned revision, local_files_only and HF_HUB_OFFLINE). [hygiene] Deleted the blob:none clone of the private agent-ecosystem repository left in the review session's scratchpad; nothing referenced it. Re-merged origin/main (three more commits landed) under the hot-file protocol before this commit: took main's manifests/evidence.json and re-registered this branch's 28 v4 files plus the two edited entries above. Checks after this round: shasum -a 256 -c SHA256SUMS (27/27 OK); python3 scripts/validate.py ({"hashed_files": 7278, "status": "passed"}); python3 scripts/validate.py --scan-file on the three changed files (passed); gitleaks over blueprints/memory-stack/longmemeval/v4 and docs/decisions (no leaks); python3 scripts/host_receipts.py validate (passed); python3 scripts/component_matrix.py --write and new_host_grand_list.py --write (no unexpected diff); git diff --check; the four unittest modules the PR body cites plus tests.test_validate.ScanFileForPrivateContentTests (all OK, 221+9 tests) -- all exit 0. Co-Authored-By: Claude Sonnet 5 <[email protected]>

Self-review of the previous commit found two accuracy issues before they reached a second reviewer: - The 2026-09-25 decision record's new addendum claimed that under plain names, the required `dependency-review` check would fail this pull request on specific advisories. That does not follow: `dependency-review` reads GitHub's native dependency graph, which recognizes manifests by fixed per-ecosystem names (`requirements.txt`, `package-lock.json`, ...), not by this repository's `TRACKED` pattern. None of the six files' plain names (`official.lock.txt`, `mempalace.lock.txt`, `agentmemory-repo-package-lock.json`, and so on) is one of those recognized names, so `dependency-review` would not see any of them regardless of the `.frozen` suffix -- unlike the original record's own file, which was named exactly `package-lock.json`. The gate these five Python locks actually escape by staying `.frozen` is `osv-scanner`, via the `TRACKED`-forced inventory entry. Reworded the addendum's "Under their plain names" paragraph and the PR body's matching evidence row accordingly. - README.md's new "Before anything runs" table cited "`:130` area's sibling installs" for where `setup_velanext.sh` reads the five lock files under their plain names; `:130` is the unrelated `eligible-manifest.json` hash check. The actual citation is `venv()` and its five calls at `:94-109`. Also fixed the pr-body.md line describing this round's `origin/main` merge: it was a clean `git merge` with no conflict (git's 3-way merge resolved `manifests/evidence.json` on its own), not a manual `checkout --theirs` + re-registration as the first merge round used; reworded to say so, and pointed the decision-record link at a resolvable full GitHub URL instead of a relative path that would not resolve in a PR body. Rechecked after these edits: shasum -a 256 -c SHA256SUMS (27/27 OK); python3 scripts/validate.py ({"hashed_files": 7278, "status": "passed"}, unchanged file count); python3 scripts/validate.py --scan-file on the three changed files (passed); gitleaks over both changed directories (no leaks); python3 scripts/host_receipts.py validate, component_matrix.py --write and new_host_grand_list.py --write (no further diff beyond the two hash/byte updates); git diff --check -- all exit 0. Co-Authored-By: Claude Sonnet 5 <[email protected]>

seathatflowsinourveins · 2026-09-27T12:12:38Z

Ready for the GPT-6 re-check at 07a81a4e.

The branch merged origin/main under the hot-file protocol.
It addresses GPT-6's four findings: the plain shared-host warning for _ours()/am_start(), warnings for setup_velanext.sh:220/224 and lme_harness.py:1149, and the qwen3.5-9b-64k Modelfile, marked as a C4 prerequisite and transferred byte-exact.
It also addresses 19 findings from two same-host Opus reviews, including decision-record coverage for the new .frozen locks.
Frozen files are unchanged.

seathatflowsinourveins · 2026-09-27T12:24:15Z

GPT-6 cross-family re-check at 07a81a4e (gpt-6-astra, effort max, read-only; run from the workstation session against the earlier review of 97697b81). The review text follows verbatim.

VERDICT: needs_changes

All four earlier findings are resolved as documentation fixes for this frozen-source transfer. One new medium finding remains in the lock decision record.

Paths below are relative to blueprints/memory-stack/longmemeval/v4/, except where stated.

Earlier high — resolved: README.md:43–56 accurately describes _ours() accepting foreign matching processes, unreadable command lines passing teardown, and am_start() killing listeners before starting anything. Lines 89–93 prohibit shared-host execution and assign isolation and identity-checked cleanup to A17.
Earlier medium, Ollama — resolved: README.md:72–85 explains the failed-bind/readiness confusion, pulls and creates reaching a foreign store, and cleanup’s PID-reuse risk. A17 must establish server identity before readiness or mutation.
Earlier medium, MemPalace — resolved: README.md:57–62 correctly distinguishes PID liveness from identity and identifies whole-process-group SIGKILL after PID reuse. The A17 cleanup requirement covers this.
Earlier low — resolved: README.md:315–340 identifies the added Modelfile as a C4 prerequisite and explains why the other three excluded Modelfiles remain necessary for the driver’s gates.

The 24 previously transferred source files remain byte-identical to 97697b81.

New finding:

[medium] docs/decisions/2026-09-25-longmemeval-frozen-npm-lock.md:154–158 — the claimed lock-scoped OSV ignores are actually global. The evidence path is only text in reason; it does not scope filtering. OSV-Scanner v2.6.0’s ShouldIgnore checks advisory ID and expiry, without a lockfile argument. The repository’s existing affected_pins() guard identifies two affected v4 pins: nltk==3.9.1 in official.lock.txt.frozen:333 and setuptools==81.0.0 in embed.lock.txt.frozen:1728. Receiving other advisories for those packages does not prove their findings were unfiltered. Correct this safety claim and identify the filtered advisory IDs when reporting scan totals. Preserve the frozen locks unchanged.

The decision’s file coverage is complete: its addendum names all five Python locks and the npm lock, and all six have checksum/evidence entries. Its accuracy fails on the finding above. Line 144 explicitly says the raw scan JSON is uncommitted; I could not independently validate the reported advisory totals from the retained checkout.

The added Modelfile:

Its SHA-256 is 60dbf344e5c374eabda289e7b379c1642bd523a2b4f4f387eb00ce021afcc318, matching SHA256SUMS:9.
Its 476 bytes and Git blob de951c96fee8df48346e2bf243eca6b94079adf4 match the provenance table. The recorded origin is evals/longmemeval/ollama/qwen3.5-9b-64k.Modelfile at private source commit 576689af6f5e5f4d85013c7c4bed3b8f7c92f57d. I did not independently fetch that private commit.
It specifies context 65536, temperature 1, top-k 20, top-p 0.95, min-p 0, presence penalty 1.5, and repeat penalty 1.
It is insufficient alone. FROM qwen3.5:9b is mutable and contains no explicit template. Ollama inherits the base layers (pinned implementation); pins.json:141–147 supplies the Q4_K_M base’s immutable manifest and GGUF digests. Together these specify the intended model, provided A17 obtains and verifies that exact base and records the effective template and parameters.

No additional secret, email, private hostname or personal home-path value was found. Private repository/branch identifiers are the already-authorized provenance. The repair introduces no executable changes. Existing home/cache mutations are documented at README.md:94–103; mutable Ollama pulls remain subject to manifest checks. A17 should additionally hash actual model blobs: verify_ollama() currently checks the GGUF’s recorded digest and file size, rather than hashing its bytes.

A17 must still add or pin:

Owned ports, stores, homes/caches, server readiness and process/group identity; fail closed on occupied ports or unreadable identity.
The missing manifest/install files, plain-name runtime lock copies, embedding gates, equivalence-check IDs and three remaining Modelfiles listed at README.md:351–358.
The v4 embedding-cache proxy, SHA-256 e08e11f871be151ade7d59b4dff5b7835746b1166fac31fe6681b9bfc58df5e3, or a preregistered omission.
D2h’s pinned agentmemory/iii and Xenova MiniLM revision; C4’s pinned ai-memory, embedding model, reranker base, serving binaries, effective template and parameters.
Workstation confirmatory evidence for n=470 and n=419, retaining the protocol’s C3/C4-family α=0.0333 and A16 α=0.0167.

Verified:

sha256sum -c SHA256SUMS: 27/27 passed.
All 25 transferred files match the README’s hashes, sizes and recorded blob prefixes.
python3 scripts/validate.py: passed, 7,278 hashed files.
git diff --check 97697b81 07a81a4e: exit 0.
Gitleaks: no leaks found.
Separated merged-main changes from the PR’s changes; checkout remains clean at 07a81a4e. No models ran, files were edited, commits created or comments posted.

🤖 Generated with Claude Code

https://claude.ai/code/session_012qwXNtFyUhY5x2dtrm7tG5

OSV-Scanner 2.6.0 matches an [[IgnoredVulns]] entry by advisory ID and expiry only (internal/config/config.go:104-112, ShouldIgnore), so the two entries written for the Lumibot lock also filter the v4 locks: GHSA-8mgp-746c-j5xp on nltk 3.9.1 (official.lock.txt) and GHSA-h35f-9h28-mq5c on setuptools 81.0.0 (embed.lock.txt). Re-scanned with an empty config: official 115 unique advisories (114 with the config) and embed 3 (2). The addendum table and README now give both counts and name the filtered IDs. No frozen file changed. Co-Authored-By: Claude Opus 5.5 <[email protected]>

Take main's manifests/evidence.json and re-register this branch's 29 files; the generated reports were rewritten with no change and validate.py passed. Co-Authored-By: Claude Opus 5.5 <[email protected]>

seathatflowsinourveins · 2026-09-27T12:29:16Z

Fix for the GPT-6 re-check at 07a81a4e; new head 0ae533e4.

[medium] OSV ignores are global. Confirmed at google/[email protected] internal/config/config.go:104-112 (ShouldIgnore matches the ID and ignoreUntil only). The OSV API confirms both v4 pins are affected: GHSA-8mgp-746c-j5xp covers nltk ≤3.10.3, and GHSA-h35f-9h28-mq5c covers setuptools <83.0.0.
Re-scan. I re-ran the frozen locks under plain scratch names with the repo config and with an empty config. The repo config filters exactly those two advisories, which is what the scanner's 'Filtered 4' line counts once aliases are included. Totals, unfiltered / with the repo config: official 115/114, embed 3/2; every other lock is unchanged.
Changes. The addendum's false 'lock-scoped' sentence is replaced with the correct statement. The totals table now gives both counts, and the filtered IDs are named in the addendum, the README and the PR body. The PR body's per-lock summary line, which had mixed lock orders, is rewritten.
Unchanged. No frozen file changed. v4 SHA256SUMS passes 27/27.
Checks. Main was merged under the hot-file protocol (29 files re-registered, generated reports unchanged). validate.py passes, and test_osv_lockfile_coverage and test_adoption_docs_consistency are OK.

seathatflowsinourveins · 2026-09-27T12:36:17Z

GPT-6 scoped check of the OSV repair at 0ae533e4 (gpt-6-astra, effort max, read-only). The earlier medium is resolved. The remaining low concerns only the PR body's highlight counts, so after that text edit no further review round is needed. The review text follows verbatim.

VERDICT: needs_changes

The medium is resolved. The repaired documentation correctly describes ID/expiry matching, consistent with OSV-Scanner v2.6.0 ShouldIgnore. Both advisory IDs match the repository configuration and affected frozen pins.

Low — PR #386 body:112: The “Decision record” highlights still present filtered counts as unqualified totals: official 114, nltk 42, embed 2. The corrected documentation distinguishes 115/114, 43/42, and 3/2 respectively. Label this paragraph’s counts as repository-config results or repeat the paired counts.

No other new findings.

Verified

Isolated repair 756b35d7; all 14 other changed paths match the merged main parent.
sha256sum -c SHA256SUMS: 27/27 passed.
All frozen locks and drivers remain byte-identical; only README’s checksum changed.
python3 scripts/validate.py: passed, 7,282 hashed files.
git diff --check 07a81a4e 0ae533e4: exit 0.
Checkout remains clean at 0ae533e4. Reported scan totals were cross-checked; OSV scans were not rerun.

🤖 Generated with Claude Code

https://claude.ai/code/session_012qwXNtFyUhY5x2dtrm7tG5

manifests/evidence.json taken from main, then this branch's 29 files re-registered through host_receipts.register_file; component_matrix.py and new_host_grand_list.py regenerated (reports unchanged); validate.py passes. v4 SHA256SUMS still verifies 27/27. Co-Authored-By: Claude Opus 5.5 <[email protected]>

seathatflowsinourveins · 2026-09-27T13:19:04Z

main free. #386 is merged as 8bb52541c8f6b937ff71535a2ae6dfdad00e4e3a, a squash of head fdfa25b4acc3b7fc06c66e971e0bd143f04cfb63, and every required check passed.

The merge applied the hot-file protocol on top of ec27a300.
validate.py passed, and the v4 SHA256SUMS verifies 27/27.

The next merge belongs to the token-efficiency lane (token-efficiency-evidence-cards), per the workstation's window. The mac-coordinator session will not merge to main again until that lane posts "main free".

….4.0 reranker feasibility; v4-based runner rules S3 draft r4 (not frozen): - Reference feasibility from source. Official ai-memory v2.4.0 ships the LLM reranker: AI_MEMORY_RERANKER=llm in crates/ai-memory-cli/src/config.rs:413-420,1744-1759, crates/ai-memory-llm/src/reranker.rs and docs/llm-providers.md:185-192. The docs name no reranker model, so the preregistered qwen3.5-9b-64k stays. Its base is pinned by v4 pins.json:141-147, and the runner verifies the base, the effective template and parameters, and the served blob hashes. - C3' and C4' are defined from the v4 driver's C3/C4. agentmemory's primary arm is its shipped hook path, the A-protocol's D2h shape, with its v4 pins. - Late-candidate rule: later sweep survivors enter only through a dated amendment arm, like reserves admitted after confirmatory execution. The 32-layer sweep is held for the user's Gates A and B. - D-mac-prod: the Mac's production 19b6429 in a C4-shaped configuration, a labelled diagnostic outside the decision family, at the Mac session's request. The 19b6429 / v2.4.0 / v2.4.1 lineage is recorded. - Harness: v4 (#386) is the frozen adapter source, and the S3 runner is new code with the isolation rules from the #386 GPT-6 reviews. The cache proxy's omission is preregistered from A16.3. Only the public reranker Modelfile and its base pin are needed. - A workstation GPU window, a scheduled production stop the user approves; per-host qualification, including reranker timeout latency; Mac Hindsight pending the user's Apple Container decision. - S3's statistics govern, and the A-protocol's do not transfer. Section 12 covers the relationship to A1-A16.3. New blueprints/memory-stack/longmemeval/A17-SUPERSESSION.md (PROPOSED): R1 is not run under A1-A16.3, and S3 supersedes it on both hosts. No confirmatory arm has run on any host, so no look is spent. It takes effect only when the user confirms it at the S3 freeze. No session held an A17 draft (checked with the sessions that had owned it). Every path:line citation in the new text was checked against the files (19 of 19 resolve). Main (#386) is merged in so the v4 citations resolve. validate.py passed. Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]> Claude-Session: https://claude.ai/code/session_012qwXNtFyUhY5x2dtrm7tG5

seathatflowsinourveins added the lane:foundation Foundation lane: Claude/Codex setup, hosts, memory, RAG, research, workers label Sep 27, 2026

seathatflowsinourveins and others added 2 commits September 27, 2026 03:06

seathatflowsinourveins and others added 3 commits September 27, 2026 03:54

Merge remote-tracking branch 'origin/main' into claude/memory-stack-l…

7f48d7d

…ongmemeval-v4-driver-20260927

seathatflowsinourveins and others added 2 commits September 27, 2026 08:28

Merge main into #386 under the hot-file protocol

0ae533e

Take main's manifests/evidence.json and re-register this branch's 29 files; the generated reports were rewritten with no change and validate.py passed. Co-Authored-By: Claude Opus 5.5 <[email protected]>

seathatflowsinourveins enabled auto-merge (squash) September 27, 2026 13:00

seathatflowsinourveins merged commit 8bb5254 into main Sep 27, 2026
24 checks passed

seathatflowsinourveins deleted the claude/memory-stack-longmemeval-v4-driver-20260927 branch September 27, 2026 13:17

seathatflowsinourveins mentioned this pull request Sep 27, 2026

Memory layer S3: head-to-head preregistration draft r6 (both hosts; upstream AMB harness in retrieval mode; not frozen) #390

Closed

Navigation Menu

Repository navigation

Commit the LongMemEval v4 driver byte-exact for the A17 rerun (D2h, C4) - #386

Commit the LongMemEval v4 driver byte-exact for the A17 rerun (D2h, C4)#386
seathatflowsinourveins merged 10 commits into
mainfrom
claude/memory-stack-longmemeval-v4-driver-20260927

seathatflowsinourveins commented Sep 27, 2026 •

edited

Loading

Uh oh!

seathatflowsinourveins commented Sep 27, 2026

Uh oh!

socket-security Bot commented Sep 27, 2026 •

edited

Loading

Uh oh!

socket-security Bot commented Sep 27, 2026 •

edited

Loading

Uh oh!

seathatflowsinourveins commented Sep 27, 2026

Uh oh!

seathatflowsinourveins commented Sep 27, 2026

Uh oh!

seathatflowsinourveins commented Sep 27, 2026

Uh oh!

seathatflowsinourveins commented Sep 27, 2026

Uh oh!

seathatflowsinourveins commented Sep 27, 2026

Uh oh!

seathatflowsinourveins commented Sep 27, 2026

Uh oh!

Uh oh!

seathatflowsinourveins commented Sep 27, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

seathatflowsinourveins commented Sep 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Scope

SOTA sources

Evidence-class table

Local commands run

Decision record

Not transferred

Host evidence

Checklist

Review

Uh oh!

seathatflowsinourveins commented Sep 27, 2026

Uh oh!

socket-security Bot commented Sep 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

socket-security Bot commented Sep 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

seathatflowsinourveins commented Sep 27, 2026

Uh oh!

seathatflowsinourveins commented Sep 27, 2026

Uh oh!

seathatflowsinourveins commented Sep 27, 2026

Uh oh!

seathatflowsinourveins commented Sep 27, 2026

Uh oh!

seathatflowsinourveins commented Sep 27, 2026

Uh oh!

seathatflowsinourveins commented Sep 27, 2026

Uh oh!

Uh oh!

seathatflowsinourveins commented Sep 27, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

seathatflowsinourveins commented Sep 27, 2026 •

edited

Loading

socket-security Bot commented Sep 27, 2026 •

edited

Loading

socket-security Bot commented Sep 27, 2026 •

edited

Loading