[Sync drift] tools/llm_registry.py forked in consumers but absent from Workflows + sync-manifest (langchain_client/llm_provider clobber risk)

[stranske]

Why

tools/langchain_client.py and tools/llm_provider.py are sync-managed from this repo to consumers (.github/sync-manifest.yml:670 and :667). Two consumers have forked these synced files to route model selection through a local tools/llm_registry.py that does not exist in Workflows and is not in the sync-manifest — so the next maint-68 sync will overwrite the consumer forks and orphan their llm_registry.py, silently reverting registry-driven model selection and blocked-model guards fleet-wide.

Verified 2026-06-28 (against local clones + this repo's main):

• Workflows canonical tools/langchain_client.py: 0 references to llm_registry; slot logic is inlined (SlotDefinition(... model="gpt-5.4") at langchain_client.py:98, build_chat_client at :204). tools/llm_provider.py hardcodes gpt-5.1-codex (:594,629) and claude-sonnet-4-5-20250929 (:660,705).
• Consumer forks Manager-Database and Trend_Model_Project: langchain_client.py has 6 llm_registry references each; both ship tools/llm_registry.py that is byte-identical (md5 10527ff44035e70636dbfa9738433895) — a shared, registry-driven slot/model-selection module with blocked-model guards. (Travel-Plan-Permission carries only an empty llm_registry.py placeholder; not forked.)
• tools/llm_registry.py is absent from this repo (find → none) and has 0 entries in .github/sync-manifest.yml.

So the canonical synced files and the consumer copies have diverged, with the consumer version being the more capable one (registry + blocked-model guards) and the dependency it needs (llm_registry.py) living only in consumers and outside the sync system.

Scope

Reconcile the LLM-client sync boundary so a sync cannot clobber registry-driven model routing. This is a canonical-behavior decision (owner): the evidence favors upstreaming the consumer fork, but confirm before executing.

Recommended direction (Option A — upstream the fork)

The consumer fork is strictly more capable (external llm_registry config + is_model_blocked guards) and is already duplicated identically across 2 consumers — the signature of something that should be source-owned.

Non-Goals

• Do NOT "fix" this only inside a consumer repo — that violates the consumer-repo rule and will be re-clobbered on next sync. The durable fix is in this repo.
• Do NOT silently drop the blocked-model guard behavior when reconciling.

Tasks (Option A — recommended)

• Add tools/llm_registry.py to this repo (adopt the consumer version, md5 10527ff…), and refactor tools/langchain_client.py + tools/llm_provider.py here to import it (registry-driven slot/model selection + is_model_blocked), replacing the inlined SlotDefinition/hardcoded models.
• Add tools/llm_registry.py as a synced entry in .github/sync-manifest.yml (alongside langchain_client.py/llm_provider.py, same sync mode).
• Re-sync consumers (maint-68) so Manager-Database / Trend_Model_Project converge on the upstreamed version instead of carrying a fork.

Alternative (Option B — if the inlined version is canonical)

• Then the consumer forks are the drift: remove tools/llm_registry.py + revert langchain_client.py/llm_provider.py in the affected consumers, and document why registry-driven routing was rejected.

Acceptance Criteria

• After the change, a state_fingerprint / sync-drift check shows tools/langchain_client.py, tools/llm_provider.py, and tools/llm_registry.py CLEAN (identical) between this repo and Manager-Database + Trend_Model_Project — i.e. no consumer fork remains.
• tools/llm_registry.py is listed in .github/sync-manifest.yml (Option A) OR is absent from all consumers (Option B).
• A test asserts model routing honors the registry/blocked-model guards (Option A) and that build_chat_client selects the configured slot model rather than a hardcoded default.
• Deliberate-break demonstration: removing the llm_registry manifest entry (Option A) makes the sync-drift check flag langchain_client.py as DRIFT against the two consumers; restoring it returns CLEAN.

Implementation Notes

Audit baseline: Workflows main, 2026-06-28; consumer clones at their origin/main. Manifest evidence: .github/sync-manifest.yml:667 (llm_provider.py), :670 (langchain_client.py), :673 (embedding_provider.py). Cross-fleet footprint: forked in stranske/Manager-Database and stranske/Trend_Model_Project (identical llm_registry.py). Surfaced by the Manager-Database full audit (Code/Audits/Manager-Database/2026-06-28-03-sync-drift.md). Related smaller drift in the same audit: tools/requirements-llm.txt (template_sync: exact, consumer pins ahead) and opposite-direction drift in scripts/langchain/followup_issue_generator.py vs progress_reviewer.py (build_chat_client vs _llm_client.build_client) — worth folding into the same reconciliation.

[stranske-automation-bot]

Branch codex/issue-2708 created from main.

Option 1 (Invite) is enforced on issue events.
PR creation is disabled by design so you are the PR author.
Codex only engages on human-authored PRs.

Please open the PR as the author so Codex can work on it:

• Compare link: https://github.com/stranske/Workflows/compare/main...codex/issue-2708?expand=1
• Suggested title: Codex bootstrap for #2708
• Suggested body (copy/paste):

<!-- meta:issue:2708 -->

@codex Your objective is to satisfy the **Acceptance Criteria** by completing each **Task** within the defined **Scope**.

## Keepalive Next Task

**This round you MUST:**
1. Implement actual code or test changes that advance at least one incomplete task toward acceptance.
2. Commit meaningful source code (.py, .yml, .js, etc.)—not just status/docs updates.
3. Mark a task checkbox complete ONLY after verifying the implementation works.
4. Focus on the FIRST unchecked task unless blocked, then move to the next.

**Guidelines:**
- Keep edits scoped to the current task rather than reshaping the entire PR.
- Use repository instructions, conventions, and tests to validate work.
- Prefer small, reviewable commits; leave clear notes when follow-up is required.
- Do NOT work on unrelated improvements until all PR tasks are complete.

## Pre-Commit Formatting Gate (Black)

Before you commit or push any Python (`.py`) changes, you MUST:
1. Run Black to format the relevant files (line length 100).
2. Verify formatting passes CI by running:
   `black --check --line-length 100 --exclude '(\.workflows-lib|node_modules)' .`
3. If the check fails, do NOT commit/push; format again until it passes.

**COVERAGE TASKS - SPECIAL RULES:**
If a task mentions "coverage" or a percentage target (e.g., "≥95%", "to 95%"), you MUST:
1. After adding tests, run TARGETED coverage verification to avoid timeouts:
   - For a specific script like `scripts/foo.py`, run:
     `pytest tests/scripts/test_foo.py --cov=scripts/foo --cov-report=term-missing -m "not slow"`
   - If no matching test file exists, run:
     `pytest tests/ --cov=scripts/foo --cov-report=term-missing -m "not slow" -x`
2. Find the specific script in the coverage output table
3. Verify the `Cover` column shows the target percentage or higher
4. Only mark the task complete if the actual coverage meets the target
5. If coverage is below target, add more tests until it meets the target

IMPORTANT: Always use `-m "not slow"` to skip slow integration tests that may timeout.
IMPORTANT: Use targeted `--cov=scripts/specific_module` instead of `--cov=scripts` for faster feedback.

A coverage task is NOT complete just because you added tests. It is complete ONLY when the coverage command output confirms the target is met.

**The Tasks and Acceptance Criteria are provided in the appendix below.** Work through them in order.

<!-- 
  DO NOT ADD TASK CONTENT BELOW THIS LINE
  
  Task content is dynamically injected from the PR body via the `appendix` input.
  This template file should only contain instructions, not PR-specific tasks.
  
  If you see task content in this file, it was incorrectly committed and should
  be removed. The guard script will flag this as an error.
-->

[stranske]

Resolved on main (verified at a39db6e on a fresh clone): tools/llm_registry.py is present and byte-identical to the consumer copies (md5 10527ff…), the canonical tools/langchain_client.py imports it (== consumer, md5 c6cd8cbd…), and it is in .github/sync-manifest.yml — so a maint-68 sync converges rather than clobbers. This issue was filed off a stale Dropbox checkout of Workflows during the Manager-Database audit; the live tip already carries the fix. The forward-looking model-ossification concern is now tracked by PR #2709 (freshness gate / maint-77) and the model-update design issue.