tao-run-dinov3-ssl-deft

DINOv3 SSL DEFT

The DS-packaged Python controller owns the loop and durable state. This skill prepares and approves its inputs; it does not implement orchestration.

Instructions

1. Resolve the DINOv3 model using the model resolver. Choose grit-score for unlabeled target ranking; its scorer is built in. Offer multi-task-round-robin only when the user already has a score adapter that meets the task scoring contract: DS ships no multi-task scorer, and validate rejects the recipe's placeholder. Read architecture.md for the scientific meaning, task weighting, and stopping policy.
2. Read tao-container-integration.md. Check release readiness before offering a launch: the resolved images.tao_toolkit.data_services image must be a release build whose installed packages contain the reviewed DEFT modules and pass packaged validation. An older DS build is not sufficient. The placeholder rejection (step 1), the cohort checks and the canceled-run exit code 143 need a DS build that contains tao-data-services#59: the first DS 7.3.0 RC after rc-90. DS rc-90 and older accept the placeholder at validate, fail in round 1 with Missing configured inputs: [... 'score_implementation_0'], and exit 0 after a cancel. The release/7.3.0 cherry-pick of this skill must bump images.tao_toolkit.data_services in versions.yaml to that RC. The executable profile is one allocated DS container; no external runner ships with this application. For release QA, the repository script scripts/deft_container_handoff.py runs each repository's regression tests (--suite source) and the shipped package checks (--suite packaged) inside the approved images; the packaged suite also rejects a DS image that predates #59. Run it from clean checkouts of the release SHAs; the default --base-ref origin/main diffs each release from its merge base. It is a QA tool, not a launcher.
3. Follow the selected platform's launch gate. For Docker, use the concrete allocation, preflight, and docker exec lifecycle in the integration reference. Inside that runtime, follow the preparation sequence in adapter-contracts.md: produce source/target embeddings with the same fixed encoder, register the source store with its payload contract, and write the target contract. No additional host/model package installation is needed. Generate a packaged recipe with init, fill paths/resources, then run validate <config>, preflight <config> --gpu in the launch runtime, and plan <config>. Read adapter-contracts.md when declaring a held-out benchmark (isolation), or configuring custom scoring/evaluation, indexed retrieval, or resource policies.
4. Inspect the plan and present the approval contract below. Read references/skill_info.yaml:path_contract as the input-mount checklist: every applicable path must be visible in the allocated container, and output.run_dir must match the platform's durable results directory. Skill Bank resolves image keys on the host; DS accepts explicit image references only and never reads this repository at runtime.
5. After approval, execute run <config> inside the allocated container. Monitor to a terminal result using the commands below. Do not modify controller state or locks manually.