PR #TBD — Native Sessions Can Prove Cross-Harness Review Provenance
PR #TBD — Native Sessions Can Prove Cross-Harness Review Provenance
The goalpost we inherited
The previous provenance recovery work kept synlynk pr check fail-closed when
a dispatched implementation lost its cost row. The remaining gap was a
legitimate implementation authored directly from an interactive home session,
where no dispatch job exists to identify the implementer.
The problem this PR addresses
The cross-harness review gate only knew how to resolve implementation identity through dispatch jobs: capability ratings, linked issues, or a dispatch branch. Native sessions therefore failed the gate even when the PR had a recorded cost entry and a valid cross-harness review.
What shipped
cost_entriesnow records an optionalpr_number, with additive migration support for existing databases.synlynk cost log --pr <pr-number> --harness <harness>records native implementation provenance without reusing the categoricaldispatch_contextfield.synlynk pr checkuses the newest matching native cost entry only after all existing job-based paths fail, while preserving the same identity and incomplete-provenance checks.- The missing-provenance hint and
CLAUDE.mdnow distinguish native--prlogging from dispatched--job-idlogging.
Verification
The focused database, CLI, and cost-ledger suites pass: 310 tests passed and 1 was skipped before the final persistence assertion was added. Coverage includes matching native provenance, mismatched PR numbers failing closed, and all three existing job-based recovery paths remaining green.
New goalpost
Interactive home sessions can now participate in the same measured, cross-harness review gate as dispatched work, without weakening fail-closed behavior for unrecorded or incomplete provenance.