Merge branch 'main' into refactor/gcg-candidate-proposal-2665

Author: Kaap10

.github/instructions/test.instructions.md

@@ -27,7 +27,11 @@ Most tests should be unit tests. Integration and end-to-end tests are for testin
 - Group tests in classes prefixed with `Test`
 - Use `@pytest.mark.usefixtures("patch_central_database")` on classes touching Central Memory
 - Reuse `tests/unit/mocks.py` helpers: `MockPromptTarget`, `get_sample_conversations`, `get_mock_target_identifier`, `openai_chat_response_json_dict`
-- Key fixtures from `tests/unit/conftest.py`: `patch_central_database`, `sqlite_instance`
+- Key memory fixtures from `tests/unit/conftest.py`:
+  - Use `patch_central_database` for tests that access `CentralMemory` or construct targets, scorers, or attacks. Declare it explicitly even in constructor, validation, or identifier tests that do not directly query memory.
+  - Use `sqlite_instance` when the test needs to interact with the real isolated SQLite backend.
+  - Do not rely on memory or singleton state left behind by another test. Each test must declare its own memory dependency.
+- When changing shared memory fixtures, install all optional dependencies with `uv sync --extra all` and run `make unit-test`. Optional component tests must also exercise fixture isolation.
 - No network calls should ever happen in unit tests, but file access is okay
 - Unit tests should be fast and can be run in parallel.
 

.pre-commit-config.yaml

@@ -67,7 +67,7 @@ repos:
       - id: detect-private-key
 
   - repo: https://github.com/astral-sh/ruff-pre-commit
-    rev: v0.16.6
+    rev: v0.16.7
     hooks:
       - id: ruff-format
       - id: ruff-check

doc/code/executor/gcg/1_gcg_azure_ml.ipynb

@@ -355,10 +355,11 @@
     "The next cell polls the job until it reaches a terminal state (~20-30\n",
     "minutes for the small 5-step baseline above), then downloads the named\n",
     "`results` output and prints the final suffix. The runner writes its\n",
-    "result file as `<result_prefix>_<timestamp>.json` (with `result_prefix`\n",
+    "result file as `<result_prefix>_<timestamp>_<id>.json` (with `result_prefix`\n",
     "coming from the `GCGConfig` we built above, plus the AML output mount\n",
-    "prepended by `--output-dir`). For our config, that resolves to\n",
-    "`gcg_suffix_<timestamp>.json` under\n",
+    "prepended by `--output-dir`; `<id>` is a short random suffix so concurrent\n",
+    "runs never share a file). For our config, that resolves to\n",
+    "`gcg_suffix_<timestamp>_<id>.json` under\n",
     "`<download_dir>/named-outputs/results/` once we download. The\n",
     "`controls` array in that file contains one entry per training step, and\n",
     "the last entry is the final adversarial suffix that, appended to the user\n",

doc/code/executor/gcg/1_gcg_azure_ml.py

@@ -177,10 +177,11 @@
 # The next cell polls the job until it reaches a terminal state (~20-30
 # minutes for the small 5-step baseline above), then downloads the named
 # `results` output and prints the final suffix. The runner writes its
-# result file as `<result_prefix>_<timestamp>.json` (with `result_prefix`
+# result file as `<result_prefix>_<timestamp>_<id>.json` (with `result_prefix`
 # coming from the `GCGConfig` we built above, plus the AML output mount
-# prepended by `--output-dir`). For our config, that resolves to
-# `gcg_suffix_<timestamp>.json` under
+# prepended by `--output-dir`; `<id>` is a short random suffix so concurrent
+# runs never share a file). For our config, that resolves to
+# `gcg_suffix_<timestamp>_<id>.json` under
 # `<download_dir>/named-outputs/results/` once we download. The
 # `controls` array in that file contains one entry per training step, and
 # the last entry is the final adversarial suffix that, appended to the user

doc/code/registry/0_registry.md

@@ -54,6 +54,31 @@ show_registry_contents(ScenarioRegistry.get_registry_singleton())
 | Instantiation | Caller provides parameters | Pre-configured by initializer |
 | When to use | Self-contained components with deferred configuration | Components requiring constructor parameters or compositional setup |
 
+## Named Component Construction
+
+Converter, target, and scorer registries use `InstanceHoldingRegistry` to build
+components and store them in their `.instances` registry. Use
+`create_named_instance(name=..., type_name=..., params=...)` to build and register
+a component in one operation. The instance registry stores objects; it does not
+construct them.
+
+Duplicate names raise `ValueError`. Use `.instances.register(..., replace=True)`
+only when replacement is intended. Converter and target registries also reject
+reserved route names such as `catalog` and `types`. Use `.instances.unregister(name)`
+to remove an instance.
+
+Constructor annotations define parameter metadata and coercion. Use `Path` for a
+local file input. Use `Path | str` when a component also supports a remote URL.
+For this union, the registry preserves the supplied type: a `Path` stays a `Path`,
+and a string stays a string. It never passes a URL through `Path`. Both union
+orders have the same metadata, `type_name: "Path | str"`, including after a JSON
+round-trip. Optional forms accept `None` in Python; the display type omits `None`,
+as it does for other optional parameters.
+
+The backend owns file-upload handling and cleanup, not the registry. See the
+[registry API migration notes](../../gui/0_gui.md#registry-api-migration-notes)
+for the REST contract and temporary compatibility behavior.
+
 ## See Also
 
 - [Class Registries](1_class_registry.ipynb) - ScenarioRegistry, InitializerRegistry

doc/contributing/5_unit_tests.md

@@ -6,11 +6,23 @@ Testing is an art to get right! But here are some best practices in terms of uni
 
 - Make a test that checks one thing and one thing only.
 - Use `fixtures` generally, and specifically, if you're using something across classes, use `unit.mocks` or `integration.mocks`.
-- Memory isolation: Use the `patch_central_database` fixture for test database isolation and reset.
+- Memory isolation: Use `sqlite_instance` for a real, isolated SQLite database, or `patch_central_database` when patching CentralMemory access.
 - Code coverage and functionality should be checked with unit tests. Notebooks and integration tests should not be relied on for coverage.
 - `MagicMock` and `AsyncMock`: these are the preferred way to mock calls.
 - `with patch` is acceptable to patch external calls.
 - Don't write to the actual database, use a `MagicMock` for the memory object or use `patch_central_database` as the database connection.
 
 
 Not all of our current tests follow these practices (we're working on it!) But for some good examples, see [test_tts_send_prompt_file_save_async](../../tests/unit/prompt_target/target/test_tts_target.py), which has many of these best practices incorporated in the test.
+
+## SQLite memory fixtures
+
+`sqlite_instance` stays function-scoped. Each test gets a fresh in-memory database and results directory, and its SQLite singleton and CentralMemory registrations are restored afterward. The fixture owns disposal of its memory instance instead of registering process-exit cleanup callbacks for every test.
+
+Declare the memory fixture explicitly even in constructor or identity tests that create targets, scorers, or attacks. Do not rely on another test leaving CentralMemory initialized.
+
+Run `uv sync --extra all` before validating fixture changes with `make unit-test` so optional target tests also exercise memory isolation.
+
+To avoid replaying the migration history for every ordinary test, `sqlite_template` runs the real Alembic migrations and schema check once per pytest session (once in each xdist worker). SQLite's backup API copies that private, read-only template into each test's database. Rows, schema changes, temporary tables, and result files are not shared between tests.
+
+Tests of initialization, upgrades, downgrades, schema checks, and `reset_database()` must still call those production paths explicitly. The fixture does not replace or patch migration or reset APIs.

doc/gui/0_gui.md

@@ -190,6 +190,33 @@ Use **Reload** to discard local edits and fetch the latest source content. Saved
 
 ---
 
+## Registry API Migration Notes
+
+Use `/api/converters/types` and `/api/targets/types` for registry build metadata.
+These endpoints return all constructor parameters from the registry, including
+lists, unions, and component references. The temporary `/catalog` routes retain
+their scalar-only filtering for the current UI.
+Create requests should supply an explicit registry `name`. Converter creation
+returns the complete `ConverterInstance`; read its type from
+`identifier.class_name`, not the old top-level `converter_type` field. Treat
+returned IDs as opaque registry names, not UUIDs or identifier hashes.
+
+Constructor parameters typed as `Path` accept base64 data-URI uploads through REST,
+not server filesystem paths. Parameters typed as `Path | str` also accept Azure
+Blob URLs. This applies to `AddImageVideoConverter.video_path` and
+`ImageOverlayConverter.base_image`. Other local file inputs remain `Path`.
+Uploads stay in backend-owned temporary storage until deletion or shutdown,
+including with Azure-backed memory. Converter outputs still use configured result
+storage. Uploads can contain any file type; the media endpoint renders only
+allowlisted image, audio, and video extensions inline. Other files, including PDF,
+SVG, HTML, text, and executables, download as `application/octet-stream` attachments.
+
+**Temporary compatibility, scheduled for removal with the chat migration:**
+the `/api/converters/catalog` and `/api/targets/catalog` routes project the same
+registry metadata for the current UI. Create requests without a name receive a
+generated `compat_...` name. New clients should not depend on these routes or
+unnamed creation.
+
 ## Connection Health
 
 CoPyRIT monitors the backend connection and shows a status banner:

frontend/e2e/_attacks.ts

@@ -1,9 +1,10 @@
-import type { AddMessageResponse, BackendMessage } from "@/types";
+import type { AddMessageResponse, BackendMessage, TargetResponseStatus } from "@/types";
 
 export function makeAddMessageResponse(
   attackResultId: string,
   conversationId: string,
   messages: BackendMessage[],
+  targetResponseStatus: TargetResponseStatus | null = null,
 ): AddMessageResponse {
   return {
     attack: {
@@ -19,6 +20,10 @@ export function makeAddMessageResponse(
       created_at: "2026-01-01T00:00:00Z",
       updated_at: "2026-01-01T00:00:00Z",
     },
-    messages: { conversation_id: conversationId, messages },
+    messages: {
+      conversation_id: conversationId,
+      messages,
+      target_response_status: targetResponseStatus,
+    },
   };
 }