Detect SQLite journal sidecars during workspace and handoff inspection

[jacksenpierce]

Status

Confirmed inspection gap; the reported external artifact has not yet been independently examined here.

Observed behavior

Workspace adoption rejects source databases with adjacent -wal, -shm, or -journal files. inspect_workspace() currently inventories .sqlite files but does not report journal sidecars next to the declared authority or handed-off databases.

Desired outcome

Report adjacent SQLite journal sidecars as an explicit unsafe-handoff/workspace condition and cold-open the standalone authoritative .sqlite at its declared head. Do not infer corruption merely from an empty sidecar; distinguish presence, size, and verification result.

Acceptance evidence

Tests cover empty and nonempty WAL/SHM/journal companions, a valid checkpointed database, and a handoff whose standalone database cannot verify its declared head.

Related to #23 and #22.

[jacksenpierce]

Post-PM4 triage: still open and independently actionable. This is the smallest confirmed safety repair in the backlog: surface adjacent -wal, -shm, and -journal files during workspace/handoff inspection, report size and verification status, and cover checkpointed plus unsafe handoffs without inferring corruption from presence alone.

[jacksenpierce]

Additional unverified PM4 field evidence from the first reported YHX3.2.2 native-fork workflow: the packaged child allegedly contained authoritative/corpus.sqlite, a zero-byte corpus.sqlite-wal, and a 32 KiB corpus.sqlite-shm. Integrity and the expected head reportedly remained valid. The reporter could not determine whether fork, later inspection/opening, or packaging created the sidecars.

Preserved source report: https://github.com/jacksenpierce/parmesan/blob/main/maintenance/incidents/2026-08-22-yhx3-2-2-pm4-fork-resource-rehydration.md

This does not independently prove corruption or a fork defect. It strengthens the existing acceptance requirement to distinguish empty/nonempty WAL state, checkpoint before portable packaging, exclude unnecessary SHM/empty WAL files, and cold-open the delivered standalone database at its declared head. Related resource-canonicalization investigation: #39.

[jacksenpierce]

YHX4 supplied a new unverified field report with the exact failure mode this issue is meant to make visible: a handrolled resource-thin ZIP omitted WAL/SHM without checkpointing. The live directory reportedly showed sequence 1012 while its delivered main database cold-opened at 887; a later live sequence 1042 reportedly exported as 979. The agent repaired the process by checkpoint/truncate, repackage, clean extraction, and cold-open verification.

Report: https://github.com/jacksenpierce/parmesan/blob/main/maintenance/incidents/2026-08-23-yhx4-stale-snapshot-export-sqlite-wal.md

The incident artifacts are unavailable, so those numbers are evidence to investigate rather than established fact. Current source does confirm the inspection/publication affordance gap. Keep this issue focused on detecting and explaining sidecars/unsafe SQLite state; #47 now covers the safe PM4 publication path that checkpoints and validates the deliverable.

[jacksenpierce]

Parmesan 4.1.0 addresses the publication side of this issue for native PM4 capsules: pm4 share uses SQLite online backup, cold-validates a standalone database, and refuses a candidate retaining -wal, -shm, or -journal sidecars. The broader workspace/handoff inspection diagnostics requested here remain open. See PR #53.