Split out of #60, which ships the design and plan for this but not the implementation.
Problem
CreateRecoveryDestination installs the canonical union of records while leaving indexed_files empty, and verifyRecoveryDestinationRows currently requires that emptiness:
// internal/storage/recovery_destination.go:243
if indexedFileCount != 0 {
return fmt.Errorf("indexed_files count = %d, want 0 for recovery destination source accounting", indexedFileCount)
}
Database.Validate requires every search_items.source_path to have an indexed_files row, so a database that recovery just declared healthy immediately fails the public validate --indexed-only orphan check. Recovery's remediation purpose is defeated: the user recovers, then sees the result reported as invalid.
Designed fix (already in the repo)
docs/superpowers/specs/2026-08-19-recovered-source-accounting-design.md and docs/superpowers/plans/2026-08-19-recovered-source-accounting.md specify it:
- One provisional
indexed_files row per distinct recovered source_path, hash backscroll:recovered, last_indexed NULL.
- The marker must never look like a 64-char hex SHA-256.
verifyRecoveryDestinationRows checks an exact marker set instead of zero rows.
- Consumers branch on it:
GetFileHashes and GetStats exclude markers; BackfillDerived includes them; SyncFiles' existing INSERT OR REPLACE replaces the marker with the real hash on the next real sync.
Not yet present
recoveredSourceHash, isRecoveredSourceHash, recoveryDestinationSourcePaths, insertRecoveryDestinationAccounting.
Acceptance
A database produced by recover passes validate --indexed-only with no orphan findings, and a later sync replaces every marker with a real hash.
Split out of #60, which ships the design and plan for this but not the implementation.
Problem
CreateRecoveryDestinationinstalls the canonical union of records while leavingindexed_filesempty, andverifyRecoveryDestinationRowscurrently requires that emptiness:Database.Validaterequires everysearch_items.source_pathto have anindexed_filesrow, so a database that recovery just declared healthy immediately fails the publicvalidate --indexed-onlyorphan check. Recovery's remediation purpose is defeated: the user recovers, then sees the result reported as invalid.Designed fix (already in the repo)
docs/superpowers/specs/2026-08-19-recovered-source-accounting-design.mdanddocs/superpowers/plans/2026-08-19-recovered-source-accounting.mdspecify it:indexed_filesrow per distinct recoveredsource_path, hashbackscroll:recovered,last_indexedNULL.verifyRecoveryDestinationRowschecks an exact marker set instead of zero rows.GetFileHashesandGetStatsexclude markers;BackfillDerivedincludes them;SyncFiles' existingINSERT OR REPLACEreplaces the marker with the real hash on the next real sync.Not yet present
recoveredSourceHash,isRecoveredSourceHash,recoveryDestinationSourcePaths,insertRecoveryDestinationAccounting.Acceptance
A database produced by
recoverpassesvalidate --indexed-onlywith no orphan findings, and a latersyncreplaces every marker with a real hash.