MS: neural-symbolic take-max router + W1 writer fixes

[wsuli615]

⚠️ Interim work — NOT a final result. MS accuracy numbers are deliberately omitted; they are mid-tuning and unstable run-to-run. A single consolidated MS result will be reported once tuning is complete.

Summary

Builds on the shelved neural-symbolic agent (#26) to make the count/sum lever complementary with the normal reader for LongMemEval MS, plus targeted writer (W1) fixes for writer-gap failures. All changes are gated behind --neural-symbolic (default OFF). W1 cues are under --extract-typed-attributes (already ON in the MS stack).

1. Neural-symbolic take-max complementary router (count/sum)

For count/sum questions the reader runs on the pure no-hint context and we keep the higher of (baseline count, NS count) — NS can only add, never subtract — so the agent complements rather than overrides the reader. --neural-symbolic-take-max (default ON when --neural-symbolic is set).

2. W1 writer cues for writer-gap operands

Some MS failures are writer-gaps where the operand was dropped at write time and lives in no node (retrieval/reader can't reach it). Targeted _TYPED_ATTR_PROMPT additions, validated on the failing raw turns with the real gpt-4o-mini writer:

• ACQUISITIONS / VIEWINGS → captures got/bought/viewed items.
• ENTITY-ANCHORED VALUES → a duration's context must name its place.
• PLANNED / FUTURE STATUS → tag-don't-drop: never drop a stated future value; only mark genuinely-undecided items so a count can exclude a phantom.
• quantity def now captures embedded category counts.

3. Cleanups

• _extract_bridge_phrases no longer mines sentence-initial interrogatives ("What"/"Which"/"Did") as bogus retrieval sub-queries.

Validation

• ruff + pyright clean; neural_symbolic_selftest.py (unit fixtures) PASS.
• Writer cues + take-max logic validated offline against the failing fixtures.
• End-to-end MS confirmation is still in progress; no MS scores are reported here.

🤖 Generated with Claude Code

[zsxh1990]

Curious — the recent MS work moves intent through a writer/reader split. When you serve via MCP + HTTP + CLI simultaneously, how does intent state stay consistent across surfaces? Do you treat the graph as a single source of truth with process-level locking, or does each surface hold its own intent buffer that reconciles async?

Working on a multi-agent collab layer and trying to figure out the right model here. Especially interested in what happens when an intent crystallizes while a query agent is mid-retrieval — does the reader see the new intent on the next call, or does it get surfaced through some other channel?

[duanyiqun]

Curious — the recent MS work moves intent through a writer/reader split. When you serve via MCP + HTTP + CLI simultaneously, how does intent state stay consistent across surfaces? Do you treat the graph as a single source of truth with process-level locking, or does each surface hold its own intent buffer that reconciles async?

Working on a multi-agent collab layer and trying to figure out the right model here. Especially interested in what happens when an intent crystallizes while a query agent is mid-retrieval — does the reader see the new intent on the next call, or does it get surfaced through some other channel?

@zsxh1990 Great question, happy to continue in discussions if useful.
This repo hasn't been well designed for multi-agent synchronisation/or compete status -- it's more like a proactive always on but massive amount of single agents. Also a serving topology is missing now for massive serve. But I do think multi-agent would be an important aspect.

My point of view (may be wrong) is the design is really depends on tasks. If we are discussing auto-research discovery etc, then we need a hard synchronise and consistent truth source. If we are discussing say social sim, we may need a bit more uncertainty.

If I were designing the multi-surface concurrent version, I'd keep the graph as the SoT and avoid per-surface mutable buffers (that turns a single-store problem into multi-master conflict resolution — the hardest thing in distributed systems, for no benefit when co-located). Concretely:

( below are my thinkings however, I speak so claude rephrase it a bit.

• Push consistency into the store as an append-only mutation log (CogniFold already has an auditable rewrite log), giving you a natural serialization point + snapshot reads instead of a coarse process lock.
• Snapshot-consistent reads: a retrieval reads the graph as of its start version. An intent that crystallizes mid-retrieval is not injected into the in-flight read — it becomes visible on the next query. That keeps the race deterministic.
• For the proactive side, emit a change-stream off the commit log (CQRS-ish): when a write batch mints/updates an INTENT, publish it; surfaces subscribe and decide whether to surface it or re-query. So the reader sees it via the next call (pull) or a notification channel (push) — your choice based on latency needs, but the graph stays the only authority.
• I'd only reach for per-surface buffers + async reconciliation (CRDTs / vector clocks) if offline/partitioned writes are a hard requirement — otherwise it's a large complexity tax.

This is a bit beyond the scope of this PR but still if you are interested, happy to have you commit multi-agent design and we go review with PR. cc @wsl2000 @matchyc happy to see how @DengMinghua feel.

[duanyiqun]

Just as a reference, update paper results to the main #29.
Please check that our different branches may have different performance from the benchmark performance, which may vary, and synchronize new scores to the main if it has whenever higher or lower. cc @wsl2000 check if you want add more comments.