Observed behavior: PostgreSQL passive promotion uses the remote owner UUID as a provenance filter, while normal public /promote writes the local path hash. A tier-3 passive event with a matching normal promotion therefore fails the existing-memory probe and is marked skipped unless repeated evidence independently qualifies it. Tier-1/2 passive deduplication also searches only the UUID provenance subset.
Expected behavior: Matching promoted knowledge already owned by the bound PostgreSQL project should be visible to passive reinforcement/deduplication regardless of the local-hash or remote-UUID self-provenance representation. Preserve owner isolation and SQLite compatibility.
Root cause: In src/daemon/routes/promote-events.ts, the tier-3 existence query passes project.projectId as searchPromoted source filter (lines 911-916 at candidate below), and the dedup call passes the same value (line 946). Normal /promote writes sourceProjectId: paths.id (src/daemon/routes/promote.ts:407). PostgreSQL search always scopes ownership separately by project_id, then applies the additional source filter; local-hash normal rows do not match the UUID.
How to reproduce: In the isolated PostgreSQL18 operational harness, use normal public /promote to create known content, verify stored source_project_id equals the bound local path hash and differs from the owner UUID, then submit one matching priority-3 passive event with insufficient repeated evidence. Observe the UUID-filtered search returning no normal-promotion row and the event being counted skipped. Add a corresponding priority-1/2 exact-content dedup regression when repairing the shared passive seam.
Evidence limits: Source/control-flow confirmed independently during PR #1143 review; the new #618 integration already proves the normal /promote local-hash representation on real PostgreSQL18. A complete passive-route end-to-end reproduction has not yet been run for this separate issue. The mismatch exists unchanged at parent bcd215163f1a4077bf93400c3ed7fff83596f8a6 and candidate bdb9c2ea1926ff00cb37b785ebb67304af52806a.
Environment:
Discovered while reviewing #618 / #1143. This is a pre-existing passive-capture route defect outside the fixed Epic #224 inventory and the #618 CLI/portable correction. Track separately without native parenting into the campaign. It is not an uncompleted fix or budget reset for PR #1143. #1153 fixes exact-rank acceptance once a candidate is visible; it does not correct this distinct source-filter mismatch.
Observed behavior: PostgreSQL passive promotion uses the remote owner UUID as a provenance filter, while normal public
/promotewrites the local path hash. A tier-3 passive event with a matching normal promotion therefore fails the existing-memory probe and is marked skipped unless repeated evidence independently qualifies it. Tier-1/2 passive deduplication also searches only the UUID provenance subset.Expected behavior: Matching promoted knowledge already owned by the bound PostgreSQL project should be visible to passive reinforcement/deduplication regardless of the local-hash or remote-UUID self-provenance representation. Preserve owner isolation and SQLite compatibility.
Root cause: In
src/daemon/routes/promote-events.ts, the tier-3 existence query passesproject.projectIdassearchPromotedsource filter (lines 911-916 at candidate below), and the dedup call passes the same value (line 946). Normal/promotewritessourceProjectId: paths.id(src/daemon/routes/promote.ts:407). PostgreSQL search always scopes ownership separately byproject_id, then applies the additional source filter; local-hash normal rows do not match the UUID.How to reproduce: In the isolated PostgreSQL18 operational harness, use normal public
/promoteto create known content, verify stored source_project_id equals the bound local path hash and differs from the owner UUID, then submit one matching priority-3 passive event with insufficient repeated evidence. Observe the UUID-filtered search returning no normal-promotion row and the event being counted skipped. Add a corresponding priority-1/2 exact-content dedup regression when repairing the shared passive seam.Evidence limits: Source/control-flow confirmed independently during PR #1143 review; the new #618 integration already proves the normal
/promotelocal-hash representation on real PostgreSQL18. A complete passive-route end-to-end reproduction has not yet been run for this separate issue. The mismatch exists unchanged at parentbcd215163f1a4077bf93400c3ed7fff83596f8a6and candidatebdb9c2ea1926ff00cb37b785ebb67304af52806a.Environment:
Discovered while reviewing #618 / #1143. This is a pre-existing passive-capture route defect outside the fixed Epic #224 inventory and the #618 CLI/portable correction. Track separately without native parenting into the campaign. It is not an uncompleted fix or budget reset for PR #1143. #1153 fixes exact-rank acceptance once a candidate is visible; it does not correct this distinct source-filter mismatch.