Skip to content

fix(memory): honor status in add_finding; open friction-log spec#1208

Merged
silversurfer562 merged 3 commits into
mainfrom
claude/relaxed-taussig-90da42
Jul 1, 2026
Merged

fix(memory): honor status in add_finding; open friction-log spec#1208
silversurfer562 merged 3 commits into
mainfrom
claude/relaxed-taussig-90da42

Conversation

@silversurfer562

Copy link
Copy Markdown
Member

Summary

  • add_finding() never read finding["status"], so every node created through the real public API silently got status="open" regardless of what was passed. Found via /code-review of PR feat(memory): add curated cross-session memory NodeTypes #1207 (curated-memory NodeTypes), whose whole premise is that these nodes get active/superseded/stale status — falsified for every node actually written via add_finding. Predates feat(memory): add curated cross-session memory NodeTypes #1207.
  • Fixed: add_finding now passes status=finding.get("status", "open").
  • Strengthened the regression test (test_loads_curated_memory_node_via_real_add_finding) to assert status == "active" on reload — it previously only asserted .type, so it couldn't catch this.
  • Opened docs/specs/memory-nodetype-friction-log/ to track real dogfood usage of the 4 curated NodeType members and log taxonomy/field friction going forward, separate from implementation bugs like this one (logged there as a "fix note").

Test plan

  • pytest tests/unit/memory/test_graph.py tests/unit/memory/test_nodes_coverage_boost.py tests/unit/memory/test_graph_extended.py tests/memory/test_graph.py — 212 passed
  • pytest tests/agent_factory/test_agent_factory_memory.py — 15 passed, 4 skipped
  • pre-commit hooks passed on commit

🤖 Generated with Claude Code

add_finding() never read finding["status"], so every node created
through the real public API silently got status="open" regardless of
what the caller passed - found reviewing PR #1207's curated-memory
NodeTypes (whose whole premise is that these nodes get
active/superseded/stale status). Predates #1207 but falsified its
design for every node written via the real API; the new regression
test asserted .type but not .status, so it didn't catch it.

Also opens docs/specs/memory-nodetype-friction-log/ to track real
dogfood usage of the 4 new NodeTypes and log taxonomy/field friction
separately from implementation bugs like this one.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@vercel

vercel Bot commented Jul 1, 2026

Copy link
Copy Markdown
Contributor

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
attune-ai.dev Ready Ready Preview, Comment Jul 1, 2026 10:18pm
website Ready Ready Preview, Comment Jul 1, 2026 10:18pm

@codecov

codecov Bot commented Jul 1, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

query() did `for hit in pipeline.run(...)`, but the installed
attune_rag's RagPipeline.run() returns a RagResult dataclass (not
iterable), so every call raised TypeError, silently swallowed by a
broad except and returned []. This means personal_memory_recall - the
MCP tool surface - has returned zero results unconditionally since
attune_rag's return type changed. Existing mocked tests couldn't catch
this: their fake RagPipeline.run() returned a plain list, the same
wrong shape the code assumed, so mock and code agreed with each other
while both diverged from the real dependency.

Fixed: query() now reads rag_result.citation.hits (CitedSource objects
with .template_path/.category/.score/.excerpt), matching the pattern
already used correctly in workflows/rag_code_gen.py. Updated the 3
affected mocked tests to return the real RagResult/CitedSource shape
instead of a plain list, and added a new regression test that exercises
the real (unmocked) attune_rag dependency end to end - verified it
fails without the fix (TypeError swallowed -> empty result) and passes
with it.

Found via docs/specs/memory-recall-eval/ - a measure-before-build
benchmark (scripts/memory_recall_eval.py) built to answer "does
attune.memory's recall actually work" before investing further in the
subsystem. Post-fix: hit@1/hit@3 both 100% on an 18-query ground-truth
corpus (was 0%/0%). Full writeup + score-distribution caveats in the
spec's decisions.md.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Comment thread scripts/memory_recall_eval.py Fixed
CodeQL review comment on PR #1208 flagged the dead local.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

core documentation Improvements or additions to documentation tests

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant