Fullfører spikens siste måling etter at docker-tillatelsen kom på plass.
7.1 — `docker build --platform linux/amd64` grønn på python:3.12-slim-bookworm.
`uv sync --frozen` resolverte inne i containeren, inkludert begge git-pinnene,
og siste lag ga `import OK`. Det lukker gapet uv-resolusjonen ikke kunne lukke:
at avhengighetene LØSER for linux beviser ikke at koden KJØRER der.
7.2 — Andre måling bygde wheelen, SLETTET kilden, og installerte kun wheelen.
Den feilet: `llm-ingestion-guard was not found in the package registry`.
Wheelens metadata bærer de to avhengighetene som BARE NAVN — [tool.uv.sources]
er uv-konfig og reiser ikke med wheelen, og navnene finnes ikke på PyPI. En
nedlaster som får et wheel (f.eks. fra release-objektet fase 3 skal lage)
treffer denne veggen. Med direct references ved siden av: 65 pakker, exit 0.
Dette er den skarpeste friksjonskanten spiken fant, og ingen hadde spurt om den.
7.3 — Samme bygg beviste fase 4a i container: shared_root() peker på
site-packages/portfolio_optimiser/_shared, 80 filer, persona-skillen lesbar —
uten arbeidstre, siden /build var slettet før installasjonen. Invarianten er
dermed målt i situasjonen den ble bygget for, ikke bare i enhetstest.
Byggekonteksten er `git archive HEAD` (311 sporede filer) — det en fremmed
faktisk laster ned, ikke arbeidstreet.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jk8tauXXAojNKC7Tzq7ziF
Research-spiken som åpner fase 4. Fire spørsmål, besvart med kjørte kommandoer
og siterte Learn-kilder via et agent-team på fire spor.
Tre premisser i planen viste seg gale:
1. «azd-utvidelsen heter enten microsoft.foundry eller azure.ai.agents — én er
utdatert». Begge er gjeldende. Målt mot azds offisielle register: den ene er
en meta-pakke uten egne kommandoer, den andre eier `azd ai agent`. Det som
faktisk henger etter i doc-en er azd-minsteversjonen (1.25.2 vs >=1.27.1).
2. «Foundry injiserer FOUNDRY_PROJECT_ENDPOINT, AZURE_AI_MODEL_DEPLOYMENT_NAME
og APPLICATIONINSIGHTS_CONNECTION_STRING». To av tre. Modelldeployment-navnet
deklarerer vi selv. Kilden til antakelsen var MAF-hostingsiden, som motsier
både plattformdoksettet og Microsofts eget kjørende sample.
3. «docker build og azd ai agent run mot localhost:8088 er testbare UTEN Azure».
Halvveis: azd ai agent run krever azd auth login og provisjonerte ressurser,
og modellkallene går fortsatt til Foundry. --local sparer deploy, ikke Azure.
Kostnadsrelevant.
Q4 avgjorde 4c-omfanget: Workflow.as_agent() KJØRER på vårt objekt (målt), men
eksponerer bare debatten — validator, forankring, provenance og ledger ligger
utenfor grafen. En hosted agent bygget på as_agent() alene ville servert ugatede
forslag. Fase 4c er et signaturproblem rundt run_project, ikke et grafproblem.
Q2/Q3: direct references resolverer i BÅDE uv og pip, anonymt, uten publisering.
Base-image python:3.12-slim-bookworm; 3.14 faller fordi numpy 2.2.6 mangler
cp314-hjul — den ferske resolusjonen skjuler det bak en sdist.
Verktøykjeden reparert underveis: azd og docker manglet (Docker Desktop-casken
var en foreldet 0 B-oppføring). colima valgt framfor Desktop — kjører fra
terminalen, og VM-en er linux/amd64 nativt på Intel.
IKKE gjort: containeren er ikke bygget. docker build ble avvist av
tillatelsesklassifisereren. Uv-resolusjon viser at avhengighetene løser for
linux, ikke at koden kjører der — og det er forskjellen fase 4d trenger.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jk8tauXXAojNKC7Tzq7ziF
