Files
computer-playbook/utils
kevinveenbirkenbachandClaude Opus 5 ee9cbc8d5b feat(tools): pin the lane's judge model in its own inventory
The oracle asks a chat model whether a translation states its source. llama3.2:1b cannot answer that: on the suite's own fixture it scored an unrelated text at the middle level instead of the bottom one, and asked as a yes-or-no question it called two identical texts different. With it the suite reached no verdict at all, reporting that the judge read none of the 47 languages the catalogs hold machine translations for. Qwen2.5-3B answers both correctly, and the same run then judged 248 samples.

The pin lives in the lane inventory rather than in AI_LOCAL_MODELS, because a judge that can separate a faithful rendering from an unrelated text is a demand no deployment makes, and the default should not grow a gigabyte to satisfy a check. The litellm config builds its routes from the merged application config, so a lane override reaches the model list and its window without touching the repository default.

LANE_MODEL_ALIAS repeats the one name in utils/inventory/tools.py, because ensure() asks whether the lane already serves before the deploy that writes the rendered inventory, so the probe cannot read it from there. A lane serving one model while the probe expects another never reports ready and redeploys on every call, so a test renders the template and holds the two names equal.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-10-18 10:30:22 +02:00
..
…
…
…
…
…

Shared Utilities (utils/)

This directory contains shared Python helpers used by custom modules and plugins.

Purpose

Use utils/ for reusable code that should not be duplicated across:

  • library/ modules,
  • plugins/action/,
  • plugins/filter/,
  • plugins/lookup/.

Typical shared utilities:

  • API clients,
  • validation/conversion helpers,
  • path and configuration helpers,
  • cross-plugin/module domain logic.
  • Shared HTTP(S) connection handler for multiple modules.
  • Common validation or transformation functions for user input.
  • Utility functions for interacting with Docker, LDAP, etc.
  • Grouped helper packages such as utils/domains/ for related domain logic.

Design Guidelines

  • Keep helpers focused and composable.
  • Avoid side effects during import.
  • Prefer explicit function/class APIs over implicit globals.
  • Keep dependencies minimal so modules/plugins stay lightweight.

Example Import

from utils.domains.primary_domain import get_primary_domain

What Does Not Belong Here

  • Standalone executable modules (put in library/).
  • Ansible plugin entrypoints (put in plugins/*).

References