Rejects & Sync

Two workflows that close the loop after grading: getting rejected files out of your stacking software's way — reversibly — and moving grades and captures between machines.

Managing rejected files

Stacking tools like PixInsight happily load everything under your lights directory — including frames you've rejected. move-rejects archives rejected frames (and their sidecars: .xisf, .json, .txt) into a REJECT/ subtree so they're out of the scan path but never lost:

# Move rejects to <image_dir>/<Project>/REJECT/... with their sidecars.
# Idempotent; every move is recorded for restore.
psf-guard move-rejects --db my-db [--dry-run]

# Changed your mind? Un-reject frames in the UI, then:
psf-guard restore-rejects --db my-db          # restores only un-rejected files
psf-guard restore-rejects --db my-db --all    # restores everything

Recorded — every move lands in an archive table in the database (plus a redundant manifest in each archive root for disaster recovery), so restores are exact.
Reversible — restore-rejects by default restores only files whose grade is no longer Rejected (you un-rejected them in the UI); --all restores everything. It never overwrites: if the original path is occupied, the file is restored beside it with a .restored suffix.
Still visible — archived frames remain findable in the grader UI; the file index covers the REJECT/ subtree.
Configurable — --reject-segment, --reject-depth, and --sidecar-exts flags, or a per-database reject_archive block in the registry.

Requires Target Scheduler plugin schema v22+ (the stable image GUID). Older databases are refused with a pointer at the legacy filter-rejected command, which still works but leaves files in the same tree.

Syncing between machines

Grade on one machine while the telescope keeps capturing on another. sync moves state between two scheduler databases — registry slugs or .sqlite paths — matching images by their stable GUID:

# Mirror projects, targets and captured images FROM the telescope INTO your DB.
# Your local grading is preserved; new images arrive with the telescope's grade.
psf-guard sync pull --from telescope.sqlite --to my-db --dry-run

# Push your grading decisions back TO the telescope (one-way, source wins).
psf-guard sync grades --from my-db --to telescope.sqlite --dry-run

Use them as a loop — pull to refresh, grade locally, push grades back:

sync pull mirrors structure (projects, targets, exposure plans, templates) and captured images into your local database. Telescope wins for structure; your local grading is preserved — an existing image keeps its grade unless it's still Pending, in which case it adopts the telescope's.
sync grades pushes grading status and reject reasons one-way (source wins), with --status/--project/--target filters to scope what moves.
Both open the source read-only, refuse same-path source/dest, run in a single transaction, and report exactly what changed (matched, changed, unchanged, unmatched).

Don't reverse the directions — pulling grades from the telescope over your local decisions, or pushing structure to it, would overwrite work. The two commands are deliberately one-way and complementary.

The full loop, end to end

# 1. Bring the night's captures over from the telescope
psf-guard sync pull --from telescope.sqlite --to my-db

# 2. Screen the night automatically, write rejections
psf-guard screen-fits /images/2026-06-30/LIGHT --regrade-db my-db

# 3. Review borderline frames in the grader UI
psf-guard server

# 4. Archive rejects out of the stacking tree
psf-guard move-rejects --db my-db

# 5. Push final grades back so the scheduler re-captures
psf-guard sync grades --from my-db --to telescope.sqlite