feat: add guided monitor creation with scope and alert review #1269

Result

Unit administrators and operators can create a monitor through Targets → Coverage → Schedule and alerts → Review, with the full editor available at every appropriate step.

Parent: #1266. Depends on #1267, #1268.

User flow and integration

1. Add src/pages/MonitorSetup.tsx; make /jobs/new the guided route and expose advanced new-job creation at /jobs/new/advanced. Keep saved-job editing unchanged. Connect Dashboard/Jobs empty-state and create actions with existing permission gates.
2. Targets: name and authorized IP/CIDR/DNS targets, inline errors, duplicate/canonical target feedback, and clear expansion limits. Keep exclusions authoritative on the server.
3. Coverage: full TCP surface with the built-in Naabu→Nmap profile, or selected TCP ports using Nmap; optional explicitly chosen UDP ports use Nmap. Show scanner availability and coverage limitations. Profile/tuning customization uses the advanced editor. Do not pretend a Naabu enrichment port field restricts its full-range discovery.
4. Schedule and alerts: reuse cadence presets, timezone defaults, schedule suggestions, enabled/paused scheduling semantics, and explicit destination selection. Operators select destinations through notification_options.read; only notifications.manage can create/test.
5. Factor the destination-create controls needed from the unit Notifications page around src/components/NotificationDestinationConfig.tsx. Reuse existing create/test APIs and password confirmation; after creation, refresh the destination list and select the returned ID. Explain test delivery still needs checking by the recipient. Do not add an independent credential compiler, platform-destination flow, or credential persistence.
6. Review: show actual targets/coverage/engine, selected profile revision, cadence/timezone, alert destination names or 'no alerts', baseline samples/confirmation threshold, probe estimate, budget outcome, and uncertainty. Advanced-only fields remain represented accurately. Fetch preview for the exact current draft; cancel superseded requests and reject stale results. Any relevant draft change invalidates approval of an earlier preview.
7. Explicit final actions: Create and start first scan and Create without starting. Use createJob; after success clear the draft, seed/invalidate job queries, and open /jobs/{id}. First-run dispatch belongs to the dependent lifecycle task; until that lands, route to the created job without claiming the scan started.

Failure and resource ownership

• Invalid input, stale profile, missing/paused destination, unavailable scanner/policy, and unavailable preview produce actionable states without erasing the draft or using a stale 'ready' indicator.
• An over-budget draft can be reviewed and saved compatibly, but 'create and start' is unavailable until budget fit is established; explain administrator approval versus narrower scope without widening anyone's permissions. Runtime checks remain final.
• A saved destination is independent of job creation. If later job creation fails or the journey is canceled, preserve the destination and explain that it remains in Notifications. Retry targets the failed operation only.
• Disable duplicate submissions. On an unknown create outcome, explain how to check the Jobs list; do not transparently retry or invent frontend-only exactly-once guarantees.
• Destination credentials/account password are transient, cleared after save/cancel/unmount, and never placed in URLs, shared job draft, query cache/keys, browser storage, or logs. Backend responses remain write-only.

Acceptance and tests

• First and repeat job creation are usable with keyboard and mobile layouts; step names, focus changes, errors, and review updates are accessible.
• Mode switches preserve the entire draft and advanced values; cancel/Back handling is consistent.
• Full-range TCP, limited TCP, optional UDP, DNS/CIDR, timezone/cadence, no alerts, selected alerts, paused destinations, and missing profiles have meaningful unit tests.
• Out-of-order/canceled previews, changed drafts, conflicts, preview outages, and create failures cannot show stale readiness or lose draft input.
• Administrator destination creation/test and operator selection work; viewer/platform-admin never get the unit creation or management controls.
• Network payloads and transferred/cache state contain no destination credentials except the intended existing create request.
• Existing editor and URL-based API clients stay compatible.

Likely files: new src/pages/MonitorSetup.tsx, shared job draft/helpers, src/main.tsx, src/pages/Dashboard.tsx, src/pages/Notifications.tsx and a narrowly extracted destination-create component, src/styles.css, API types/client and nearby tests. Backend normalization remains in the preview/create implementation.

Update docs/src/content/docs/getting-started/first-scan.md, relevant scanning/jobs/notifications guides, and the README quick-start path alongside the change; build docs and verify deployed guidance. Checks: frontend lint/build/coverage, applicable browser tests, docs build/deployment, normal CI/security/diff coverage. Estimated effort: 8–14 hours.