Create VuMarkTarget type for semantically correct VuMark fixture

[adamtheturtle]

Summary

Previously, _vumark_database used ImageTarget for VuMark targets, which was semantically incorrect since VuMark targets don't have image data. Now VuMarkTarget is a proper type that reflects these differences: no image_value, no processing_time_seconds, always SUCCESS status, and hardcoded tracking_rating.

Changes

• Add VuMarkTarget and VuMarkTargetDict to target.py
• Add vumark_targets: set[VuMarkTarget] field to CloudDatabase (separate from image targets)
• Update not_deleted_targets to include both target types for validator lookups
• Keep active_targets, inactive_targets, etc. as image-only for clarity
• Add POST /databases/{name}/vumark_targets Flask endpoint for creating VuMark targets
• Update _vumark_database fixture to use VuMarkTarget instead of dummy ImageTarget
• Update _enable_use_docker_in_memory to POST to new endpoint

🤖 Generated with Claude Code

---

Note

Medium Risk
Introduces a new VuMark database/target type and threads it through auth/validation and mock server routing, which could affect request matching and validator behavior for existing endpoints. Changes are localized but touch shared request-validation and target-manager logic.

Overview
Adds first-class VuMark support by introducing VuMarkTarget and VuMarkDatabase (with serialization) and exposing them in the docs.

Extends the target-manager Flask app and MockVWS/requests-mock backend to create/list/delete VuMark databases and to add VuMark targets (new /vumark_databases and /vumark_targets endpoints), and updates VuMark instance generation to validate/authenticate against both cloud and VuMark databases.

Refactors shared validators/matchers and TargetManager uniqueness checks to work with a unified AnyDatabase type, and updates tests/fixtures to use the new VuMark types and revised conflict messages.

^{Written by Cursor Bugbot for commit ac4bcb2. This will update automatically on new commits. Configure here.}

[adamtheturtle]

Re: Cursor Bugbot review — valid point about VuMark authentication. The VWS auth validators only search cloud_databases, so VuMark database credentials won't be found during authentication for the generate_vumark_instance endpoint. Fixing this requires widening the validator type signatures to accept both CloudDatabase and VuMarkDatabase — that'll be a follow-up change.

[cursor]

Duplicated uniqueness validation logic across add methods

Low Severity

The server key and database name uniqueness checking logic in add_vumark_database (building all_databases, iterating with the server_access_key / server_secret_key / database_name tuple, and raising ValueError) is a near-identical copy of the same block in add_cloud_database. If this validation logic ever needs updating (e.g., new key type, changed message format), both copies must stay in sync. Extracting a shared helper would reduce the maintenance surface.

Additional Locations (1)

• src/mock_vws/target_manager.py#L68-L97

 

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.}

[cursor]

Missing error handling in VuMark database deletion endpoint

Medium Severity

The delete_vumark_database endpoint lacks the try/except ValueError error handling that delete_cloud_database has. When no matching VuMark database exists for the given name, the set unpacking (matching_database,) = {...} raises an unhandled ValueError, resulting in a 500 error instead of the intended 404 response.