Problem
migrate-feedback-memories captures each routed memory as an event through capture-event, which auto-fills cwd and repo from the invocation's working directory. The migration runs from one place while the memories originate in many repos, so every migrated event is stamped with the migration run's repo and cwd, never the origin's. The origin survives only in the body's Origin: line.
This corrupts recall. kb-retrieve-events derives its recurrence count (occurrences) by grouping events that share a repo. A migration batch stamps many origin-diverse lessons with one shared repo, producing a spurious recurrence cluster, and it severs each lesson from its true origin, so a later in-situ capture of the same lesson never groups with its migrated ancestor.
Context
capture-event reads the working directory for exactly two fields: cwd (from process.cwd()) and repo (the git remote at that directory). Store resolution, schema loading, and the write path are keyed on the store's absolute path from ~/.agents/kb.yaml, independent of the working directory. Running the capture from the origin repo therefore redirects cwd and repo to the origin and affects nothing else.
The origin directory is already in hand: The enumerator emits each memory's repoPath. session and captured-at are the same class of migration-run provenance but stay out of scope; they remain in the body's Origin: line.
Proposed solution
Run each capture from the origin repo's working directory (repoPath), rather than teaching capture-event a working-directory override. The fix is confined to migrate-feedback-memories' capture step, which wraps the existing capture-event invocation in a subshell that changes to repoPath first; the auto-filled cwd/repo then resolve to the origin. When repoPath is null, the capture runs from the migration run's directory as today, and the origin survives in the body's Origin: line.
Acceptance criteria
Must have
Problem
migrate-feedback-memoriescaptures each routed memory as an event throughcapture-event, which auto-fillscwdandrepofrom the invocation's working directory. The migration runs from one place while the memories originate in many repos, so every migrated event is stamped with the migration run'srepoandcwd, never the origin's. The origin survives only in the body'sOrigin:line.This corrupts recall.
kb-retrieve-eventsderives its recurrence count (occurrences) by grouping events that share arepo. A migration batch stamps many origin-diverse lessons with one sharedrepo, producing a spurious recurrence cluster, and it severs each lesson from its true origin, so a later in-situ capture of the same lesson never groups with its migrated ancestor.Context
capture-eventreads the working directory for exactly two fields:cwd(fromprocess.cwd()) andrepo(the git remote at that directory). Store resolution, schema loading, and the write path are keyed on the store's absolute path from~/.agents/kb.yaml, independent of the working directory. Running the capture from the origin repo therefore redirectscwdandrepoto the origin and affects nothing else.The origin directory is already in hand: The enumerator emits each memory's
repoPath.sessionandcaptured-atare the same class of migration-run provenance but stay out of scope; they remain in the body'sOrigin:line.Proposed solution
Run each capture from the origin repo's working directory (
repoPath), rather than teachingcapture-eventa working-directory override. The fix is confined tomigrate-feedback-memories' capture step, which wraps the existingcapture-eventinvocation in a subshell that changes torepoPathfirst; the auto-filledcwd/repothen resolve to the origin. WhenrepoPathis null, the capture runs from the migration run's directory as today, and the origin survives in the body'sOrigin:line.Acceptance criteria
Must have
cwdandrepoin its structured fields, resolved by runningcapture-eventfrom the origin repo's working directory (repoPath).repoPathis null, the capture runs from the migration run's directory as today, and the origin survives in the body'sOrigin:line.