v3.1.2

Fixed

• AgenticHub's LLM intent-classification fallback (free-form questions with no matching keyword)
  could route to lineage/dictionary/quality/builder even when that agent isn't configured in
  the hub, and _dispatch treated it as a hard "Agent '<x>' non configure dans ce hub." error
  instead of falling back to GenBI — on a hub exposing only GenBI, a free-form metrics question like
  "l'évolution mensuelle du CA des commandes" could be misrouted and fail outright. Fixed by
  restricting _llm_classify_intent's candidate intents (and its system prompt's per-intent
  descriptions) to the agents actually configured on the hub, and by falling back to GenBI in
  _dispatch only when the intent came from that LLM fallback — an explicit keyword-detected
  request for an unconfigured agent still returns the "non configure" error as before.
• A failed Spark/Spark Connect query (e.g. an AnalysisException) leaked its full message —
  including the JVM stacktrace: marker and thousands of characters of at org.apache.spark.../
  at com.databricks... frames — into AgentResponse.error/QualityResponse.error, and from there
  into the Markdown rendered for Playground/the supervisor. Fixed by sanitizing the message at the
  point each agent builds its error response (new agentic/_errors.py::sanitize_exception_message),
  keeping only the readable prefix (error code, short message) up to the JVM stacktrace: marker (or
  the first stack-frame line when that marker is absent) and capping the result's length; the full
  original message is still available via exc_info=True logging. The Provenance block is unaffected
  — it reads only from evidence, never from error.

v3.1.1

Fixed

• SparkBackend._append_certification (contract/run/check certification rows) relied on Spark's
  single-row schema inference, which fails with CANNOT_DETERMINE_TYPE as soon as one column is
  entirely None in that row — the case for every STARTED RunEvent (target_fqn/staging_fqn/
  quarantine_fqn all unset) on both Spark Connect and classic Spark. Certified publication could
  never write its first STARTED event, blocking the whole data_product pipeline before any Gold
  write. Fixed by giving each of the three certification tables (contract_definitions,
  materialization_runs, check_results) an explicit schema, the same pattern already used by
  upsert_incident and append_semantic_usage_event.

v3.1.0

Changed

• SkiferResponsesAgent (Plan 41) répond en Markdown (serving/_markdown_renderer.py) : le Playground et le
  superviseur rendent le texte en Markdown, si bien que la réponse en texte brut y perdait son saut de ligne et
  affichait les flottants bruts (total_revenue: 16200985.329999981). Un KPI affiche désormais le label de la
  métrique (sinon sa description si elle est courte) et une valeur au format français (16 200 985,33), une
  ventilation devient un tableau Markdown de 30 lignes au plus — triée, puisque la requête n'a pas d'ORDER BY :
  un axe temporel dans l'ordre chronologique, toute autre ventilation par sa première mesure décroissante —, et la provenance est un bloc séparé qui explique
  le statut de certification (NOT_EVALUATED → « non évaluée (gate de certification désactivé) »). Les règles de
  divulgation ne changent pas : aucune valeur de filtre, le maillon le plus faible l'emporte. La CLI et l'API
  locale gardent le texte brut de hub_response_to_text.

Fixed

• Gate de certification sémantique (Plan 29) : sur Databricks, un modèle dont la table est en deux parties
  (gold.kpi_orders) était toujours refusé MISSING en warn/enforce, même publié en mode certifié. Le
  resolver lit cette table dans le catalogue du moteur et la publication enregistre le run sous ce nom à trois
  parties (sts_demo_catalog.gold.kpi_orders), alors que le gate cherchait le nom nu. SemanticEngine cherche
  désormais d'abord sous le nom qualifié par le catalogue, puis sous le nom nu, et la certification garde le nom
  du modèle dans la preuve.
• ContractExtractor ne dérive plus de FilterInvariantCheck pour un filtre de source portant sur une colonne que
  la sortie ne publie pas (absente de select_final ou de aggregate). Le check s'évalue sur la table publiée :
  un filtre status:in:completed,shipped suivi d'un select_final sans status échouait en erreur SQL à chaque
  publication certifiée, avec une trace Spark complète dans les logs. Avec keep_all_columns, la sortie n'est
  pas connue et le check est conservé.

v3.0.3

Added

• Workflow Release (.github/workflows/release.yml) et scripts/release.py réparé : la montée de version se
  lance à la demande (gh workflow run release.yml -f bump=patch|minor|major, avec dry_run possible). Il exige
  une CI verte sur main, met à jour pyproject.toml, uv.lock, docs/install_databricks.md et le
  CHANGELOG.md, pousse le commit chore(release) et le tag vX.Y.Z, puis déclenche la publication PyPI.
  release.py refusait de tourner depuis le passage à la publication de confiance (il cherchait des secrets
  PYPI_API_TOKEN qui n'existent plus). CLAUDE.md décrit la procédure.

Fixed

• SkiferResponsesAgent.predict() (Plan 41.4) ne mettait pas de id au niveau racine de
  ResponsesAgentResponse. MLflow accepte ce champ comme optionnel (None, et le serialiseur
  l'omet alors de la réponse), mais le schéma strict de l'API Responses d'OpenAI l'exige : un
  client qui valide contre ce schéma rejette la réponse. Trouvé en validant la réponse en direct
  de l'endpoint skifer-agent sur le workspace (Plan 41.9) contre plusieurs schémas connus.
  id=str(uuid4()) au niveau racine, en plus de celui déjà posé sur l'item de sortie.