[hannahwestra25]

Description

• Adds ScenarioSuiteRegistry, modeled on ScenarioPresetRegistry, so code-registered read-only suites coexist with editable stored suites while preserving stored precedence and actionable registered-name conflicts.
• Exposes suite and preset origin plus nullable versions; registered definitions use None, while stored definitions retain opaque optimistic-concurrency versions.
• Routes suite CRUD, resolution, source configuration, and startup scanning through the registry while retaining ScenarioSuiteStorage as persistence.
• Adds a process-local ScenarioSuiteExecutionService that preflights the complete reviewed suite/preset snapshot before accepting work, then submits ordinary scenario runs in suite order through ScenarioRunService.
• Persists versioned scenario_suite_execution_v1 metadata atomically on each successful child ScenarioResult, without adding parent run records or database migrations.
• Adds launch, grouped progress, and best-effort cancellation APIs plus runtime admission/shutdown integration.
• Makes cancellation admission-safe, keeps temporary child-status read errors nonterminal, and retains active executions at the 256-entry boundary; capacity exhaustion returns 429 instead of evicting active grouped control state.
• Adds a launch dialog, registered/stored launch actions, ordered progress page, child-run links/backlinks, transient polling recovery, and cancellation UI.
• Keeps suite execution failures user-safe: full exception details stay in server logs while API responses and the progress page expose stable actionable messages.
• Preserves stored-suite editing, optimistic concurrency, advisory status projection, authorization, existing scenario-run behavior, and current suite routes.

Tests and Documentation

Added backend coverage for registry resolution, optimistic snapshots, ordered submission, admission-safe cancellation, transient status recovery, terminal-aware retention, lifecycle behavior, and safe failure responses. Added frontend coverage for launch gating, polling, cancellation, routing, backlinks, and error redaction. Updated suite configuration documentation.

Focused validation passed: 115 backend and 5 frontend tests, Ruff, formatting, and whitespace. Earlier branch validation passed 590 backend/import and 200 frontend tests plus TypeScript, ESLint, and production build. Cached ty==0.0.86 reported no code errors; pinned ty==0.0.89 could not download due PyPI TLS, so CI reruns it. JupyText was not run because no notebooks changed.

[Richard Lundeen (richlundeen)]

The latest lifecycle changes address three of the earlier findings. These comments cover the remaining lifecycle and polling issues, the shared-model boundary, the metadata key, and the proposed UI flow.

[Richard Lundeen (richlundeen)]

Can we reset the code-registered suites during live reinitialization? reset_setup_registries() does not include ScenarioSuiteRegistry, so an initializer that registers a suite succeeds at startup but fails with "already registered" when the same configuration is applied again. Removing the initializer also leaves its suites in the registry. The registered instances should follow the setup lifecycle; the stored suite documents should remain unchanged.

[Richard Lundeen (richlundeen)]

Can we keep polling with a delay after a refresh failure, or add a Retry button to the stale-data view? After two consecutive failures, this branch preserves the last execution but does not schedule another poll. ScenarioSuiteExecutionPage only exposes Retry when there is no execution, so a temporary outage leaves an active suite's progress frozen until the user reloads the page.

[Richard Lundeen (richlundeen)]

Let's use a stable metadata key, scenario_suite_execution, without _v1 in the name. The payload already has a version field, which is where the schema version belongs. Encoding it in both places makes readers track multiple keys for the same concept when the schema changes. Please keep the version inside the payload and update the readers and writers together.

[Richard Lundeen (richlundeen)]

Can we keep the shared suite launch/execution contracts in pyrit.models, following RunScenarioRequest and ScenarioRunSummary, and keep only the HTTP-specific envelopes here? I would also separate reusable suite/preset resolution from the backend task lifecycle. The backend should own admission, scheduling, and cancellation, but resolving a suite into child requests should not require importing a backend service. Reusing the existing run states and launch-field validation would also avoid a second contract drifting from the ordinary scenario path. This matches the model and backend responsibilities in framework.md.

[Richard Lundeen (richlundeen)]

I'd like to keep the registry for defining configurations and use the Scanner for launching them. That would better match the existing UI. Can we organize the flow like this?

1. Combine presets and suites under one Scenario presets registry page. Put Scenario Preset Groups (or Scenario Suites) at the top, with individual presets below.
2. Add an Add to scanner yes/no switch to each preset. The tip should explain that this controls whether the preset appears as an individual scanner entry; presets used only within a suite can stay hidden from that list.
3. Remove Launch actions from the registry pages and move launching to the Scanner.
4. In the Scanner, show suites/groups first in alphabetical order, with an expandable list of their member scenarios, then the normal individual scanners. Separate Single and Groups tabs could also work if that layout is clearer.
5. Keep the existing launch flow: select an item, review its configuration, and click Launch. We can allow configuration edits before launch for individual scenarios; suite-level edits do not need to be part of this change.

Small, non-blocking note: Refresh is in the opposite position from other pages. I would rather remove manual refresh across the UI eventually, so I would not spend time on that here.