memory/add always 500s on default memorize.mode = "agent" — DetectionResult missing should_wait (everalgo-boundary 0.3.0 vs agent/user-memory 0.4.0)

[jscales4000]

Summary

On a clean pip install everos==1.2.3, every POST /api/v2/memory/add returns
HTTP 500 INTERNAL_ERROR under the shipped default memorize.mode = "agent".

The cause is a version skew between separately-versioned everalgo sibling
distributions, so it reproduces deterministically for anyone installing today.

Root cause

everalgo-boundary 0.3.0 defines DetectionResult as a 3-field NamedTuple
with no defaults:

# everalgo/boundary/chat.py:37
class DetectionResult(NamedTuple):
    cells: list[MemCell]
    tail: list[ChatMessage]
    should_wait: bool | None      # <- required, no default

Five call sites in the 0.4.0 consumer packages still construct it with two
arguments:

File	Line	Package
everalgo/agent_memory/boundary.py	84	everalgo-agent-memory==0.4.0
everalgo/agent_memory/boundary.py	126	everalgo-agent-memory==0.4.0
everalgo/user_memory/boundary.py	121	everalgo-user-memory==0.4.0
everalgo/user_memory/boundary.py	140	everalgo-user-memory==0.4.0
everalgo/user_memory/boundary.py	143	everalgo-user-memory==0.4.0

Both 0.4.0 packages declare everalgo-boundary>=0.2.0,<2.0.0, so the resolver
picks 0.3.0 and the break lands inside the allowed range.

The two agent_memory sites carry # type: ignore[arg-type] on the exact line
that fails — the suppression hid the error that a type check would have caught.

Reproduce

from everalgo.boundary.chat import DetectionResult
DetectionResult(cells=[], tail=[])
# TypeError: DetectionResult.__new__() missing 1 required positional argument: 'should_wait'

Or end-to-end: everos init, everos server start, then any /api/v2/memory/add
with mode = "agent" →

TypeError: DetectionResult.__new__() missing 1 required positional argument: 'should_wait'
  everos/service/_boundary.py:250 in _detect
  everalgo/agent_memory/boundary.py:126 in adetect

Impact

• Default config is unusable — mode = "agent" is what everos init writes.
• mode = "chat" batch path (BoundaryDetector.adetect) is fine; its
  adetect_step path hits the same bug.
• Nothing in everos 1.2.3 reads should_wait (grep -rn should_wait everos/
  returns nothing), so the field is currently write-only from everos' side.

Suggested fix

Release everalgo-agent-memory / everalgo-user-memory 0.4.1 passing the field,
and tighten the pin to everalgo-boundary>=0.3.0,<0.4.0:

• user_memory/boundary.py:121,140,143 → should_wait=None
  (matches the docstring: "adetect_step (single-step) returns None")
• agent_memory/boundary.py:84 → should_wait=None (no LLM was consulted)
• agent_memory/boundary.py:126 → should_wait=chat_result.should_wait (propagate)

Dropping the two # type: ignore[arg-type] comments would let CI catch a repeat.

Workaround for users

pip install 'everalgo-boundary==0.2.1' — resolves cleanly and nothing in
everos 1.2.3 uses should_wait.

---

Second, smaller issue (separate report?)

[embedding] hard-requires ≥1024-dim vectors (_DEFAULT_DIM = 1024, enforced by
a pydantic min_length on the LanceDB column), but this is undocumented. A
768-dim provider (e.g. Ollama nomic-embed-text) passes /health with
embed: true, accepts writes, and then fails asynchronously in the cascade:

ValidationError: List should have at least 1024 items after validation, not 768

The rows land as retryable=FALSE and search silently returns zero results —
/health still says ok. Either validate the provider's dimension at startup,
or document the ≥1024 floor next to the [embedding] config block.