Deprecate `object-detection-yolo`

[aidanbruneel]

Objective

Retire the YOLO-based object detection preprocessor from the maintained IMAGE server now that object-detection-llm is the supported replacement.

Context and rationale

IMAGE currently retains both the legacy YOLO object detector and the newer LLM/VLM-based object detector.

The previous practice of moving unmaintained microservices into deprecated/ directories is not desirable here. Those components remain part of the repository's dependency-maintenance surface, which can continue to generate Dependabot alerts and other maintenance work even though the code is no longer supported.

The YOLO implementation is no longer intended to be maintained and has also introduced compatibility and GPU-resource concerns on the current production infrastructure. Its source does not need to remain in the active tree solely for historical purposes, since previous implementations can be recovered through Git history.

This Task should therefore retire YOLO cleanly while ensuring that existing object-detection-dependent functionality continues to operate with object-detection-llm.

In scope

• Remove the YOLO object detection implementation from the maintained source tree.
• Remove it from active build, CI, deployment, and server configuration.
• Remove or update remaining active references to the legacy object-detection service where required for the server to operate without YOLO.
• Confirm that object-detection-dependent experiences continue to function using object-detection-llm.
• Ensure the retired implementation remains reasonably discoverable through repository history or project documentation.

Completion criteria

• object-detection-yolo is no longer part of the maintained source tree.
• The YOLO service is no longer built, deployed, or started by current IMAGE server configurations.
• No active component requires the YOLO object detector for normal operation.
• Object-detection-dependent experiences continue to receive usable object detection data from object-detection-llm.
• Obsolete YOLO-specific CI, build, configuration, and documentation references have been removed or updated.
• The retired implementation can still be located through repository history or appropriate project documentation.

Constraints and non-goals

• Do not move the YOLO implementation into preprocessors/deprecated/; retired code should not remain in the maintained dependency surface solely for archival purposes.
• Do not delete shared schemas or interfaces that remain applicable to object-detection-llm.
• Do not expand this Task into model selection, prompt tuning, or broader object-detection quality improvements.
• Do not attempt to solve the broader architecture of service-name versus schema/data-type dependencies as part of this Task, except where changes are necessary to remove YOLO safely.
• Existing previously published artifacts do not need to be removed solely because the implementation is being retired.

Validation and operational impact

• Confirm supported Docker Compose profiles start without the YOLO service.
• Test representative image requests and verify object detection is provided by object-detection-llm.
• Test object-detection-dependent renderings for regressions.
• Check server logs for missing-service, dependency-resolution, or related errors following removal.
• No data migration is expected.
• Retiring YOLO should remove its active GPU and dependency requirements from the server.

Dependencies and related work

• Select and validate the production vision-language model #1167
  The replacement object detector should be considered suitable for supported use before YOLO is retired.
• preprocessors and handlers directly reference preprocessors rather than schemas #1165
  Tracks the broader architectural problem exposed when replacing one object-detection implementation with another.
• Repair production environment preprocessors #1194
  YOLO is one of the legacy GPU-dependent preprocessors implicated in the current production compatibility work.

[aidanbruneel]

@jeffbl You mentioned in-person that the preprocessors/deprecated/ and handlers/deprecated/ directories are improper and cause dependabot issues.

To me, that implies we should rethink how we deprecate before moving forward with deprecating object-detection-yolo. Thoughts?

[jeffbl]

Our standard was to move unmaintained microservices to a deprecated folder. This means issues with them keep showing up in dependabot. If we don't have any expectation that these will ever be maintained, the alternative would be to just delete them. If we do that, there is likely some value in tagging those versions in git, and maintaining a list of deprecated items since someone may want to explore previous approaches.

[jeffbl]

@aidanbruneel to consider:

• When you make a final decision on this preprocessor, we need to clean up the test-docker-compose.yml and docker-compose.yml files to either remove yolo entirely, or if not deprecating, make sure that only one of [object-detection,object-detection-llm] is ever running for a given profile. Right now, that would mean removing "default" from the main docker-compose and the test-docker-compose.
• the reason to not deprecate yolo would be because it is going to be much faster than any LLM solution. But IIRC there was some work to do to get it actually working on latest GPUs, and maybe that is not worth the effort.
• If we do keep it, suggest renaming to object-detection-yolo to make it clearer.

[aidanbruneel]

@jeffbl I think we should just remove YOLO at this point. The LLM detector seems to be working well enough now and keeping YOLO around is adding some maintenance/config commitments for something we aren't actually using in production.

I also don't think we should introduce objectdetectionLLM just to distinguish the two. If YOLO is going away, the LLM detector can stay as the normal objectDetection output and the SAM work in #1152 can build on that.

If we eventually need a much faster detector for some use case, we can revisit that then rather than maintaining YOLO indefinitely.

@Miliya-Ai I think we should proceed with removing YOLO.

[jeffbl]

@aidanbruneel That's fine. I'd suggest tagging it somehow so if someone wants it, it is easy to find. I'm not sure what "I also don't think we should introduce objectdetectionLLM just to distinguish the two." means. They both use the same schema, so there shouldn't be any necessary downstream changes.

[aidanbruneel]

I meant the output identifier. My intent is for object-detection-llm to continue providing the existing objectDetection output once YOLO is removed, rather than introduce a separate objectDetectionLLM output. Agreed that downstream, we should not need to change just to distinguish them.

For discoverability, I think we are on the same page that tagging the last YOLO state before removal would probably be useful. @Miliya-Ai, please keep the shared output contract unchanged as part of the removal.