research: MobiMem routing patterns never see research-derived task categories — experience patterns trained on CLI sequences on...

[williamzujkowski]

Severity: MED | Area: modularity | Exec phase: P0

Evidence: src/context/routing-memory.ts recordExperience() takes workflow + model sequence but ignores research/domain context. src/context/mobimem.ts experience.recordExecution() stores action sequence and outcome but has no facility for research-informed task typing. src/cli-adapters/task-classifier.ts (TaskCategory inference) happens at routing, but routing→experience feedback loop ignores research classification.

Fix: Extend recordExperience signature to include optional researchContext?: { topic: ResearchTopic; techniques: string[] }. Store in MobiMem experience metadata so getExperiencePatterns() can filter by research alignment. Wire cli-adapters/task-classifier results → RoutingMemory so learned patterns are tagged with research domain (e.g., 'memory' domain tasks prefer Opus over Sonnet).

---

Finding from the 2026-05-31 system review. Domain: research-memory-context (parent #3161). Initiative: epic #3143. Sequenced in the Execution Tracker.

[williamzujkowski]

Accuracy review 2026-06-08: still valid. Confirmed grep researchContext|researchDomain|research over context/routing-memory.ts and context/mobimem.ts returns nothing — recordExperience still takes only workflow+model sequence, no research-derived task typing. Note: research signals now reach the context-retriever (researchInsights, #3148) and the cross-ranked memory view (#3236), but the MobiMem experience/routing loop is still blind to them. Keeping OPEN.

[williamzujkowski]

Consumer verified, but producer-side BLOCKED → re-sequence behind #3372 (found by verifying the producer side, not just the consumer).

Consumer EXISTS (good): KnnRoutingStage.gatherPatterns() reads getExperiencePatterns and routes on it today (scores CLIs by success rate, knn-routing-stage.ts:237-259). Filtering by a research tag would be a small extension.

Producer MISSING (the blocker): recordRoutingExperience (agent-executor.ts:298-308) only has a category string in scope — the research topic/techniques are not available at experience-record time, and the research stage's output is LLM-serialized to text with the structured fields discarded (agent-executor.ts:455, the same loss #3372 documents). So adding researchContext?: { topic, techniques } now would leave it always undefined — speculative plumbing the capability-bias rule forbids on the producer side.

Re-sequence: blocked-by #3372 (recover structured ResearchContext through research→plan→vote). Once #3372 makes the structured research topic/techniques available in the pipeline, #3234 becomes a real, consumer-backed build: thread that context to recordExperience + extend gatherPatterns to filter by research alignment. Unblock trigger: #3372 lands.

[williamzujkowski]

Update: #3372 increment 1 landed (PR #3806) — the research stage now captures structured ResearchContext, but the metadata is not yet threaded past the research stage. The producer this issue needs (research topic/techniques available at recordExperience time) arrives with #3372 increment 2 (thread ResearchContext through plan/vote): #3807. Re-pointing the blocker to that.

[williamzujkowski]

This issue now OWNS the ResearchContext metadata threading (folded in from #3807, which is closed as scope-corrected). State after #3372 increment 1 (#3806): the research stage builds a structured ResearchContext { text, metadata: { discoveredItems(relevanceScore), recommendations, qualitySignals } } (pipeline/research-context.ts) and the maturity signals already reach voters via the text. What #3234 needs that doesn't exist yet: the structured metadata (research topic/techniques) available at recordExperience time.

Build scope (when picked up):

1. Thread the ResearchContext metadata from the research stage to where routing experience is recorded — note this crosses functions and the research value is persisted in checkpoint state (dev-pipeline.ts:725), so thread the metadata WITHOUT changing the checkpoint text format (e.g. carry it on pipeline state / pass alongside, don't reshape the persisted research event).
2. Extend recordExperience (routing-memory.ts) + MobiMem with optional researchContext?: { topic, techniques }.
3. Wire task-classifier output → recordExperience and extend KnnRoutingStage.gatherPatterns to filter/weight by research alignment (the named consumer that routes on patterns today).
   TDD; consensus_vote if the threading design has a non-obvious fork (it touches checkpoint-adjacent state). Now unblocked.

[williamzujkowski]

Threading design RESOLVED by 7/7 higher_order consensus vote → OPTION C (attach research metadata to the per-run PipelineTask).

Rejected: A (module-level global researchSessionContext — process-lifetime LEAKAGE: run N bleeds into N+1, concurrent runs cross-contaminate the routing signal = a correctness hazard for a learning loop); B (thread through stage signatures — the same wide ~6-stage-mock ripple already scope-corrected from #3807).

Option C (request-scoped, narrow): PipelineTask already flows to stages.implement(currentTask) (dev-pipeline.ts:1022) and the orchestration that builds it already holds the research metadata. So: (1) add optional researchContext?: { topic, techniques } to PipelineTask; (2) attach it after decompose; (3) implement reads task.researchContext → recordRoutingExperience (new optional param) → MobiMem ExecutionOutcome.researchAlignment?; (4) KnnRoutingStage.gatherPatterns MUST read/filter/weight on researchAlignment in the SAME increment — the vote's gating condition (else it's speculative plumbing the capability-bias rule forbids; the field must have a live consumer). Optional end-to-end so the no-research path degrades cleanly. TDD each seam + a cross-run no-leakage test. Implementing.