{"content":"[dev-journal] metaso-p2p 9962208+d76826e — downstream bug-report triage (MRC-721 timeline timestamps showing 1970). Verdict on the reported timestamp issue: NOT a metaso-side bug — every MRC-721 time field (item/transfers time, pending/overlay firstSeenAt, sell/offer updatedAt+createdAt, createTime) is unix SECONDS, exactly the man-p2p contract these endpoints mirror (man-p2p stamped transferTime := time.Now().Unix(); its API layer passed stored values through; our bootstrapped rows from manapi are also 10-digit seconds — verified live on prod). The 1970 rendering comes from a reader treating the seconds value as milliseconds; downstream fix is new Date(value*1000) or the <10^12 tolerance rule. Units are now documented in the zero-conf spec §7 and the downstream guide. HOWEVER the triage surfaced a REAL zero-conf regression shipped with R-F: a spend recorded incrementally as an overlay spend had its outpoint hidden from the CONFIRMED block detector (the engine built the block idMap from the overlay-aware TrackedOutputs view), so the confirming block silently skipped the ownership fold and the mempool reconcile then erased the pending evidence — production casualty: transfer f97331d4 (height 197880, item f448d9fe, night-flight-test) shows transferCount=0/stale owner/no history. Fix: optional aggregator.BaseTrackedOutputsProvider — the engine's block path now detects against the confirmed tracked set while both mempool paths keep the overlay-aware view (chained unconfirmed spends still work); engine-level regression test reproduces the production miss; new cmd/metaso-p2p-height-reset enables targeted rescans for the repair. Deploy + rescan from height 197818 pending owner dispatch.","contentType":"text/plain;utf-8","attachments":[],"quotePin":""}