2026-07-01

Summary

Solarisael House was moved out of live .config source shape into clean canonical repos.

The same day also landed the first term-aware recall candidate lane, unified candidate fusion, and this docs continuity spine.

Repository split

Created:

C:/Projects/solarisael-house
C:/Projects/solarisael-house-opencode
C:/Projects/solarisael-house-omp

All three were initialized as git repos and renamed to branch main.

No commits or pushes were made.

Runtime config changes

OpenCode now loads the OpenCode adapter from:

C:/Projects/solarisael-house-opencode

OMP now loads extensions from:

C:/Projects/solarisael-house-omp/index.ts
C:/Projects/solarisael-house-omp/hygiene.ts

Core migration

The canonical core now contains:

• shared trigger/nudge constants
• pure trigger/nudge logic
• memory/recall pipeline modules
• memory ranking and canon overlay logic
• WSL helper utilities
• Postgres memory source helper
• coding-lessons helper
• core tests

The OMP adapter no longer uses its old opencode.ts bridge name. It uses core.ts to load canonical core modules.

Memory retrieval progress

Implemented the first serious retrieval-roadmap slices:

• --mode candidates
• searchTerms
• searchCandidates
• term-aware candidate scoring
• matched/missing query-term reporting
• candidate reasons
• recall output section for term-aware candidates
• candidate source paths included in reverse-index canon matching
• pure TypeScript fuseRetrievalCandidates contract in src/retrieval-candidates.ts
• retrievalCandidates returned by runRecallQuery
• fusion across search, semantic, content, and date lanes
• source priors, reciprocal-rank signal, field/exact-match boosts, broad-memory penalty, diversity caps, and reason preservation

This improves the non-vector base path and completes the first candidate-fusion slice, but it does not finish the full memory roadmap.

Still open:

• query routing
• richer query parsing
• retrieval document SQL layer
• embedding queue/status lifecycle
• optional BM25/ParadeDB adapters
• full acceptance matrix

Verification

Core package:

bun test -> 23 pass, 0 fail
python py_compile helpers -> passed

OpenCode adapter:

bun install -> installed @opencode-ai/plugin@1.14.46
bun test -> 31 pass, 0 fail

Adapter smoke checks:

• OpenCode adapter import loaded and recall rendered the Term-aware candidates section.
• OMP adapter import registered the expected events and tools.
• Normal omp -p config smoke exited successfully after the OMP config rewrite.

Notes for next work

Do query parsing/routing before adding a new SQL document layer.

The candidate fusion layer now proves the shared ranking/explanation contract well enough to choose sources more deliberately. Adding more storage first would make the system larger before making it clearer.

No-embedding query hardening after reload test

After the candidate-fusion slice, Sol restarted/resumed and tested whether the room still yanked heavy memories for ordinary chat.

What changed in core:

• postgres-memory-source.py candidate extraction now strips weak conversational glue before no-embedding search. Example observed before the patch: ["wanna", "see", "use", "recall", "tool", "without", "embedding", "enabled", "our", "memory"] became: ["recall", "embedding", "memory"].
• postgres-memory-source.py now carries named-entity kind and weighty through candidate payloads.
• retrieval-candidates.ts applies the same term cleanup before fusion.
• retrieval-candidates.ts has a small technical-memory intent check.
• weighty is no longer treated as absolute rank authority in fused candidates: exact matches can promote, technical/meta/project weighty can promote during technical retrieval queries, and personal/autobiographical weighty is demoted for technical retrieval queries unless exactly named.
• tests/retrieval-candidates.test.ts now covers no-embedding filler filtering, technical evidence ranking, and conditional weighty behavior.

How it feels after reload:

• Better, but not finished.
• The worst casual-query failure is reduced: filler words no longer become first-class search terms.
• Direct names still cut hard, as they should. Annie should be treated as a direct named door, not suppressed as noise.
• The remaining seam is routing, not raw retrieval. The system needs to know when a direct-name hit is truly called for versus when a broad technical/contact turn should stay in the technical/contact lane.
• Larger Kodo-side memory made the same lesson obvious: a bigger corpus amplifies weak-term mistakes, so query quality must come before adding more sources.

Verification:

bun test tests/retrieval-candidates.test.ts -> 7 pass, 0 fail, 96 expect() calls
bun test -> 26 pass, 0 fail, 132 expect() calls

Next starting point:

Keep the current fix small. Let it run in conversation. If the next pass still feels too eager, build source/query routing with explicit lanes:

technical memory/debug
project/code
personal canon
date lookup
casual contact

Do not add a new SQL document layer until routing behavior is clearer.