open/portfolio-optimiser
1
0
Fork 0
Code Issues Releases 3 Activity

build(maf): lift the pin to core 1.18.0, and lift foundry/openai WITH it -- measured, not assumed

Browse source 
core 1.16.0 -> 1.18.0 turns the red guard green. The other three floors are
set to what `uv sync` actually installs, measured after the sync:

  core          1.16.0 -> 1.18.0   (latest, 2026-09-10)
  foundry        1.8.2 -> 1.13.0   (latest, 2026-09-10)
  openai         1.8.2 -> 1.14.3   (latest, 2026-09-10)
  orchestrations  1.1.1 -> 1.1.1   UNCHANGED -- 1.1.1 is still the latest release

TWO of the order's premises were felled by measurement, and the measurement
wins:

(1) `orchestrations` cannot be lifted -- there is nothing to lift it to
    (1.1.1, 2026-08-21, is still the head on PyPI). F15's comment "the two
    floors are lifted TOGETHER -- there is no partial bump" was true of F15's
    bump; after F16 it is measurably weaker, and the comment now says so.

(2) foundry/openai were NOT forced up. The order read their coupling off the
    LATEST releases (both require core>=1.17.0), but the PINNED 1.8.2 requires
    only core<2,>=1.9.0 -- so the resolver kept 1.8.2 against core 1.18.0 and
    resolved cleanly. They are lifted anyway, for a different and measured
    reason: two of the 1.17/1.18 BREAKING items name core AND foundry in the
    SAME bullet (#7918 sequence-only middleware inputs, #8127 SecretString), so
    a 1.9.0-era foundry against a 1.18.0 core is half of a coordinated change
    -- exactly the "still imports, semantics moved silently" class F15 measured.
    Config A (core 1.18.0 + foundry/openai 1.8.2) was measured green on the
    guard, the 19 async-plan-review tests and the golden transcript, and that
    is stated as the measured alternative rather than hidden.

Full suite 1577 passed / 5 skipped -- identical to the pre-bump baseline
measured on this HEAD, 0 tests lost or added. Both goldens BYTE-UNCHANGED
(stdout ea8c534773acdbe41ae68f2c55724d69aaf8be4f, stderr
ede3e2f685ce6a14ad9888e9de421d1a66f6c611); #8219's lazy Foundry/OpenAI loading
did NOT move stderr, which stays two lines through the UNCHANGED normaliser.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Kjell Tore Guttormsen 2026-09-12 17:06:47 +02:00
commit a629902660
2 changed files with 27 additions and 16 deletions
Download patch file Download diff file Expand all files Collapse all files

18
pyproject.toml
View file

@ -9,12 +9,22 @@ dependencies = [
# og `[all]` trekker inn de fortsatt-beta integrasjonene (azure-ai-search/cosmos/ollama/…) som
# tvinger pre-releases og drar med en ALPHA pydantic. Offisiell guide: installer kun det du trenger.
# Beta-integrasjoner legges til per-fase (med snevert pre-release-scope) når de faktisk trengs.
"agent-framework-core>=1.16.0,<2", # kjerne (GA) — to-sidig pin (S2.5): major-bump krever re-verifisering av privat-API-premissene (test_maf_version_guard). F15 (02.09): løftet fra 1.9.0; de 19 private formene re-verifisert mot 1.16.0, se docs/2026-09-02-f15-maf-pinnen.md
"agent-framework-foundry>=1.8.2", # Azure/Foundry-profil: FoundryChatClient (GA)
"agent-framework-core>=1.18.0,<2", # kjerne (GA) — to-sidig pin (S2.5): major-bump krever re-verifisering av privat-API-premissene (test_maf_version_guard). F16 (12.09): løftet fra 1.16.0; 17 private/ugaranterte former, 16 sjekket mekanisk av proben, se docs/2026-09-12-f16-maf-1180.md. F15 (02.09) løftet 1.9.0→1.16.0.
# F16 (12.09): løftet 1.8.2 → 1.13.0 SAMMEN med `-openai` og `core`, og koblingen er MÅLT, ikke antatt.
# foundry 1.13.0 krever selv `core<2,>=1.17.0` OG `openai<2,>=1.14.2`, så de tre kan ikke løftes hver for
# seg. Resolveren ville BEHOLDT 1.8.2 (den krever bare `core<2,>=1.9.0`, målt) — men to av 1.17/1.18s
# BREAKING-endringer navngir core OG foundry i SAMME punkt (#7918 sequence-only middleware-inputer,
# #8127 `SecretString`), så et 1.9.0-æra foundry mot en 1.18.0 core er halvparten av en koordinert
# endring — nøyaktig «importerer fortsatt, semantikken har flyttet i stillhet»-klassen F15 § 4 målte.
"agent-framework-foundry>=1.13.0", # Azure/Foundry-profil: FoundryChatClient (GA)
"azure-identity>=1.25", # S4.1: AzureFoundryBackend passes an explicit AzureCliCredential (Foundry requires it); already transitive via foundry — promoted to a declared direct dep (zero new install weight)
"agent-framework-openai>=1.8.2", # OpenAI + OpenAI-kompatible lokale endpoints (GA) → lokal profil
"agent-framework-openai>=1.14.3", # OpenAI + OpenAI-kompatible lokale endpoints (GA) → lokal profil; F16: løftet 1.8.2 → 1.14.3 (foundry 1.13.0 krever `openai>=1.14.2`; se raden over)
# Promotert dev→core i Fase 2 (MVP-runtime, ikke lenger spike-only):
"agent-framework-orchestrations>=1.1.1", # GA orchestration builders (GroupChat/Concurrent/Magentic); krever selv core>=1.15.0, så de to gulvene løftes SAMMEN (F15) — det finnes ingen delvis bump
# F16 (12.09): dette gulvet STÅR på 1.1.1, og det er en MÅLING, ikke en utelatelse: 1.1.1 (2026-08-21) er
# fortsatt siste utgivelse på PyPI, så det finnes ingenting å løfte det til. Kravet `core<2,>=1.15.0` er
# tilfredsstilt av core 1.18.0. F15s formulering «de to gulvene løftes SAMMEN — det finnes ingen delvis
# bump» var sann for F15s bump; etter F16 er den MÅLT SVAKERE: core kan løftes uten at orchestrations kan.
"agent-framework-orchestrations>=1.1.1", # GA orchestration builders (GroupChat/Concurrent/Magentic)
"pulp>=2.8", # deterministisk validator-solver; PuLP bundler CBC i wheelen (R2). Installert 3.3.2.
# PuLP 4.0 vil kreve `pip install pulp[cbc]` + COIN_CMD (Fase-migrasjonsnotat).
"mcp>=1.28.0", # tynn lokal-mappe MCP-server (Step 7) — GA (resolverte 1.28.0) per Step 1-beslutning