resmon

Configuration

Guide Configuration types, the JSON shape they are stored in, and the export and import workflow.

resmon persists reusable search parameters as named rows in the configurations table and treats them as the primary unit of reproducibility for Deep Dive, Deep Sweep, and Routine runs. A configuration is a saved bundle of parameters — repository (or repository set), keywords, per-repository result cap, AI toggle and AI settings, email toggles, storage settings, and (for routines) schedule and execution-location fields. Date ranges are deliberately not persisted; they are chosen fresh per run or per routine fire so a saved configuration always produces a time-current window.

Configuration Types

Every row carries a config_type constrained by a CHECK constraint to one of three values:

config_typeProduced byConsumed byPurpose
manual_diveDeep Dive page’s Save Configuration actionDeep Dive page’s ConfigLoaderReusable single-repository query preset.
manual_sweepDeep Sweep page’s Save Configuration actionDeep Sweep page’s ConfigLoaderReusable multi-repository query preset.
routineRoutines page’s create/edit modalRoutines page (restores everything except the date range) and the Calendar popoverScheduled Automated Deep Sweep bound to a cron expression.

Rows are keyed by an auto-increment integer id; names are not uniquely constrained, so multiple configurations with the same name are permitted. The Configurations page at #/configurations opens on the Routine Configs tab by default and exposes a Manual Configs tab that shows manual_dive and manual_sweep entries together.

JSON Shape

The parameters column stores a JSON document whose shape matches the search page that produced it. Representative (non-exhaustive) field sets:

  • manual_dive — repository (single slug), keywords, max_results, ai_enabled, optional ai_overrides (length, tone, model).
  • manual_sweep — repositories (array of slugs), keywords, max_results_per_repo, ai_enabled, optional ai_overrides.
  • routine — every manual_sweep field plus cron_expression, email_enabled, results_in_email, notify_on_completion, and a linked_routine_id pointing at the row in the routines table that APScheduler registers a job under.

Deleting a configuration whose config_type is routine cascades to the linked routine row when the stored parameters contain a valid linked_routine_id pointing at an existing routine; the delete-confirmation dialog surfaces the cascade count before the user confirms.

Export and Import Workflow

The Configurations page moves presets between machines as a single archive:

  1. Select one or more rows via the per-row checkboxes or the select-all header checkbox.
  2. Click Export Selected — the frontend sends POST /api/configurations/export with { ids: [...] }; the backend writes a ZIP archive of individual JSON files through config_manager.export_configs and returns { "path": "<absolute path>" }.
  3. The success banner shows the archive path for 10 seconds; on desktop a Reveal in Finder (macOS) / Reveal in File Explorer button is rendered when the Electron preload has exposed window.resmonAPI.revealPath.
  4. On the receiving machine, click Import and pick the exported .zip through the native file picker — or the .json files from inside one, if you unpacked it. Several files can be chosen at once, and the picker accepts both shapes. A file whose name ends in neither extension is refused before anything is sent, with a message naming what Import does take. The chosen files are POSTed as multipart/form-data to /api/configurations/import, and config_manager.import_configs decides what each one is from its content rather than its name: a ZIP is read for its .json members, and anything else is parsed as a single configuration. Each configuration is validated and inserted as a new row. The response carries { "imported": <n>, "routines_created": <n>, "errors": [...] }, where errors names any file or archive member that could not be used — a bad entry reports itself and the rest of the batch still imports.
  5. Click Delete Selected to open the confirmation dialog (which counts how many of the selected rows are routines so the cascade impact is visible). Confirming issues one DELETE /api/configurations/{id} per selected row; per-row failures are swallowed so the batch proceeds.

Imports are always additive: a new row is inserted with a fresh integer id. Nothing is overwritten, so round-tripping is safe to repeat — but a configuration whose name is already in use lands as a second row under that name, rather than being renamed or replacing the first.