chore(deps): roll up env Dependabot updates

[burtenshaw]

Rolls up the remaining Dependabot updates under envs/ so maintainers can merge them as one PR.

Includes closed single Dependabot PRs:

• chore(deps): bump starlette from 1.0.0 to 1.0.1 in /envs/textarena_env #771
• chore(deps): bump starlette from 1.0.0 to 1.0.1 in /envs/julia_env #772
• chore(deps): bump starlette from 1.0.0 to 1.0.1 in /envs/finqa_env #773
• chore(deps): bump starlette from 1.0.0 to 1.0.1 in /envs/calendar_env #774
• chore(deps): bump starlette from 1.0.0 to 1.0.1 in /envs/chess_env #775
• chore(deps): bump authlib from 1.7.0 to 1.7.1 in /envs/opencode_env #780
• chore(deps): bump authlib from 1.7.0 to 1.7.1 in /envs/terminus_env #786
• chore(deps): bump tornado from 6.5.5 to 6.5.6 in /envs/wildfire_env #791
• chore(deps): bump tornado from 6.5.5 to 6.5.6 in /envs/coding_env #792

Scope:

• envs/calendar_env/uv.lock
• envs/chess_env/uv.lock
• envs/coding_env/uv.lock
• envs/finqa_env/uv.lock
• envs/julia_env/uv.lock
• envs/opencode_env/uv.lock
• envs/terminus_env/uv.lock
• envs/textarena_env/uv.lock
• envs/wildfire_env/uv.lock

No src/ changes. Tests were not run locally because this only updates third-party environment lockfiles. Prior CI passed validate-env-locks and lint; check-env-docs was failing due pre-existing docs drift also present on hf/main (maze, reasoning_gym, textarena, and websearch).

[bot-ci-comment]

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

[Darktex]

Note: This is an automated review by Claude Code, not a human review.

---

Review: env Dependabot lockfile rollup

Verdict: Approve ✅

Reviewed all 7 changed files. Scope matches the description exactly — changes are confined to envs/*/uv.lock, with no src/, pyproject.toml, or config changes.

Tier 1 — Bugs / correctness

• Scope is clean. Only the 7 uv.lock files listed in the body are touched. No code, manifest, or CI changes leaked in.
• Version bumps look like legitimate Dependabot/uv output — pinned versions with sha256 hashes, all sourced from files.pythonhosted.org / pypi.org. No suspicious URLs or unexpected package additions:
  • starlette 1.0.0 → 1.0.1 (all envs)
  • authlib 1.7.0 → 1.7.1 (opencode_env, terminus_env)
  • gradio bump (textarena_env)
  • greenlet 3.5.0: pruning of s390x / riscv64 manylinux wheels, and a macholib/altgraph env-marker normalization — both benign uv resolver recomputations.
• openenv-core → openenv 0.3.1 consolidation is consistent. Several lockfiles replace the standalone openenv-core package (0.2.3 / 0.3.0) with openenv 0.3.1, including in the embedded requires-dist metadata. I verified this against the pyproject.toml manifests at the PR head (finqa, chess, julia, opencode, calendar, terminus) — they already declare openenv[core] / openenv, so these lockfiles are simply catching up to the already-migrated manifests. The resolved openenv 0.3.1 satisfies every manifest's version specifier.

Tier 2 — Alignment

No concerns. Lockfile-only change; no client/server boundary or invariant implications.

Note (non-blocking)

The body describes this as a pure "Dependabot rollup," but it also carries the openenv-core → openenv package consolidation. That change is correct and consistent with the manifests — just worth a line in the description so reviewers aren't surprised by the non-version-bump diff. Recommend confirming CI's uv lock --check (or equivalent) is green before merge, since lockfile resolution wasn't run as part of this automated review.

---

Automated review by Claude Code | Learn more

[Darktex]

Note: This is an automated review by Claude Code, not a human review.

---

Verdict: Approve ✅

Reviewed as a Dependabot lockfile roll-up touching only 7 uv.lock files (no src/, no pyproject.toml, no code).

What it does

• Replaces locked openenv-core (0.2.3 / 0.3.0) with openenv 0.3.1 and rewrites each env's lock requires-dist/dependencies from openenv-core[core] → openenv[core].
• Patch bumps: starlette 1.0.0 → 1.0.1, authlib 1.7.0 → 1.7.1.
• Prunes some greenlet 3.5.0 wheels (s390x, riscv64) in calendar_env; refines a macholib→altgraph platform marker in chess_env.

Tier 1 — bugs/lint: None. Lockfiles only (not subject to Python lint). I verified the lock requires-dist entries are consistent with the base pyproject.toml specifiers on main (HEAD 7f17b2a2) for all 7 envs — the openenv-core → openenv rename already landed in source, so these locks mirror it correctly. Locked openenv==0.3.1 satisfies every floor, including opencode's >=0.3.0.

Env	pyproject on main	lock after PR	OK
calendar	openenv>=0.2.0	openenv>=0.2.0	✅
chess	openenv[core]>=0.2.2	openenv[core]>=0.2.2	✅
finqa	openenv[core]>=0.2.2	openenv[core]>=0.2.2	✅
julia	openenv[core]>=0.2.2	openenv[core]>=0.2.2	✅
opencode	openenv[core]>=0.3.0	openenv[core]>=0.3.0	✅
terminus	openenv[core]>=0.2.2	authlib bump only	✅
textarena	openenv[core]>=0.2.2	openenv[core]>=0.2.2	✅

Tier 2 — alignment: No OpenEnv invariants touched — third-party env dependency bookkeeping with no interface, architecture, or behavioral change.

Non-blocking notes

• The pruned greenlet wheels are s390x / riscv64 only — irrelevant for the supported x86-64 / arm64 Docker targets.
• calendar_env's bare openenv>=0.2.0 now pulls the full framework transitively (vs. the old 2020 placeholder openenv 0.1.13); this matches the intent already encoded on main.

---

Automated review by Claude Code | Learn more

[Darktex]

Note: This is an automated review by Claude Code, not a human review.

---

Dependency Rollup Review

Thanks for rolling this up. The version bumps themselves look correct — openenv v0.3.1 hashes are consistent across all lock files, starlette 1.0.0→1.0.1 and authlib 1.7.0→1.7.1 are routine patch bumps. However there are three issues that need to be addressed before this can land.

[blocking] pyproject.toml manifests not updated to match lock files

The central change here — renaming openenv-core → openenv as the installed package — is only reflected in the uv.lock files. The pyproject.toml manifests are not touched. uv sync derives what to install from pyproject.toml, so environments will fail to install because openenv-core no longer exists on PyPI under that name.

All of the following need updating from openenv-core[core]>=0.2.2 → openenv[core]>=0.2.2 (or >=0.3.0 where appropriate):

• envs/chess_env/pyproject.toml:11
• envs/finqa_env/pyproject.toml:12
• envs/julia_env/pyproject.toml:17
• envs/textarena_env/pyproject.toml:18
• envs/terminus_env/pyproject.toml:17
• envs/coding_agent_env/pyproject.toml (currently openenv-core[core]>=0.3.0)

Also, envs/calendar_env/pyproject.toml still specifies openenv>=0.1.13 — this should be bumped to >=0.3.1 to match the resolved version in the lock file.

[blocking] envs/opencode_env/uv.lock references a non-existent directory

The diff includes a change to envs/opencode_env/uv.lock, but opencode_env was renamed to coding_agent_env in commit 81e37a2a. That directory does not exist in the repository. One of:

• The Dependabot config (.github/dependabot.yml) still targets the old path and should be updated to envs/coding_agent_env/.
• The envs/coding_agent_env/uv.lock needs the equivalent update instead.

[minor] greenlet s390x and riscv64 wheel removal (calendar_env lock)

The calendar_env/uv.lock diff removes several greenlet wheel entries for s390x and riscv64 platforms across all Python versions (cp310–cp314). This is more than a version bump — it drops platform support from the resolved lockfile. If CI or deployment targets any s390x/riscv64 machine, those builds will no longer find a cached wheel and will need to build from source (or fail). Please confirm this is intentional and that no CI runners use these architectures.

---

Automated review by Claude Code | Learn more

[Darktex]

Note: This is an automated review by Claude Code, not a human review.

---

Alignment Review — Dependency Rollup

Automated Checks

• Lint: PASS (no .py files changed; pre-existing formatting issues on this branch are not introduced by this PR)
• Debug code: CLEAN (no .py files in scope)

Tier 1: Fixes Required

pyproject.toml / lockfile mismatch — openenv-core -> openenv rename

The lockfiles for five environments have their [package.metadata] requires-dist section updated to reference openenv instead of openenv-core, but the corresponding pyproject.toml files (the source of truth uv reads to generate lockfiles) still declare openenv-core:

Env	pyproject.toml declares	lockfile requires-dist after PR
envs/chess_env/pyproject.toml	openenv-core[core]>=0.2.2	openenv[core]>=0.2.2
envs/finqa_env/pyproject.toml	openenv-core[core]>=0.2.2	openenv[core]>=0.2.2
envs/julia_env/pyproject.toml	openenv-core[core]>=0.2.2	openenv[core]>=0.2.2
envs/terminus_env/pyproject.toml	openenv-core[core]>=0.2.2	openenv[core]>=0.2.2
envs/textarena_env/pyproject.toml	openenv-core[core]>=0.2.2	openenv[core]>=0.2.2

A lockfile whose requires-dist diverges from pyproject.toml will fail uv lock --check (uv considers the lockfile stale/inconsistent). These lockfiles as written would not be regeneratable from their own pyproject.toml.

Resolution options:

• Either update all five pyproject.toml files to declare openenv[core]>=0.2.2 (if the intent is to complete the openenv-core -> openenv rename), or
• Regenerate the lockfiles without the requires-dist rename so they are consistent with the existing pyproject.toml declarations.

Tier 2: Alignment Discussion

ALIGNMENT FLAG: openenv-core package being absorbed into openenv

• Principle at stake: Per PRINCIPLES.md, architectural decisions should be documented. The openenv-core -> openenv consolidation (merging a separate PyPI distribution into the main package) is visible only through lockfile changes here — no RFC or pyproject.toml-level change accompanies it.
• The concern: If openenv-core is intentionally being deprecated in favour of openenv>=0.3.x, that migration should be tracked explicitly (updated pyproject.toml files, a note in the PR body, or a companion PR). As written, the lockfile rename is ahead of the declared dependencies, which creates a confusing split between what the lockfiles resolve and what the source manifests declare.
• Suggested reviewer: @Darktex

Summary

The routine version bumps (starlette 1.0.0 -> 1.0.1, authlib 1.7.0 -> 1.7.1, greenlet platform-wheel pruning, macholib marker refinement) are consistent across all affected lockfiles and look clean.

The blocking issue is the pyproject.toml/lockfile mismatch on the openenv-core -> openenv rename for five environments. Those lockfiles cannot be verified by uv lock --check in their current state. The PR needs either the pyproject.toml files updated to match, or the lockfile requires-dist sections reverted to reflect the actual pyproject.toml declarations.

---

Automated review by Claude Code | Learn more

[burtenshaw]

CI note: check-env-docs is currently failing for pre-existing docs drift on hf/main as well: maze, reasoning_gym, textarena, and websearch stubs are stale. This rollup only changes env dependency files.

[Darktex]

Note: This is an automated review by Claude Code, not a human review.

---

Alignment Review Report

Automated Checks

• Lint: PASS (lockfiles are not Python source; ruff/usort do not apply)
• Debug code: CLEAN

Tier 1: Fixes Required

This PR is described as a routine Dependabot lockfile rollup, but the lockfiles contain a structural change that is not reflected in the corresponding pyproject.toml files, creating a genuine desync that would cause uv lock to produce different results if re-run from scratch.

• pyproject.toml / uv.lock desync (all 8 affected envs). Every changed lockfile replaces openenv-core (the old split package) with openenv>=0.3.1 (the new unified package) in both the resolved dependency graph and the [package.metadata] requires-dist block. However, the corresponding pyproject.toml files still declare openenv-core[core]>=0.2.x (not openenv). A lockfile must be derivable from its pyproject.toml; this one is not. Either update the pyproject.toml files to match (openenv[core]>=0.3.0) and regenerate, or revert the package rename out of this PR. Affected:

  • envs/calendar_env/pyproject.toml (declares both openenv-core>=0.2.0 and openenv>=0.1.13)
  • envs/chess_env/pyproject.toml (openenv-core[core]>=0.2.2)
  • envs/coding_env/pyproject.toml (openenv-core[core]>=0.2.2)
  • envs/finqa_env/pyproject.toml (openenv-core[core]>=0.2.2)
  • envs/julia_env/pyproject.toml (openenv-core[core]>=0.2.2)
  • envs/terminus_env/pyproject.toml (openenv-core[core]>=0.2.2)
  • envs/textarena_env/pyproject.toml (openenv-core[core]>=0.2.2)
  • envs/wildfire_env/pyproject.toml (openenv-core[core]>=0.2.0)

• envs/opencode_env/ does not exist in the repo. The PR updates envs/opencode_env/uv.lock, but there is no envs/opencode_env/ directory or pyproject.toml in the repository. Please clarify and remove the orphaned lockfile if the env has been deleted.

Tier 2: Alignment Discussion

ALIGNMENT FLAG: the openenv-core → openenv package rename is bundled into a routine rollup.

• Principle at stake: design-for-stability; architectural changes should be explicitly reviewed.
• The concern: absorbing all functionality into the top-level openenv package (0.3.1) is a meaningful change to how every environment declares its framework dependency. The PR body lists only Dependabot issues (#771–#786) and says "No src/ changes," making this easy to miss in review. If the unification was deliberately planned/tracked in an RFC or issue, this flag can be dismissed; otherwise it deserves its own PR with an explicit description.
• Suggested reviewer: a human maintainer.

Summary

• 2 mechanical issues to fix before merge (pyproject.toml ↔ lockfile desync across 8 envs; orphaned opencode_env lockfile).
• 1 alignment point for human review (framework package rename bundled into a routine rollup).

---

Automated review by Claude Code | Learn more

[Darktex]

Note: This is an automated review by Claude Code, not a human review.

---

Alignment Review Report

Summary

This PR rolls up Dependabot lockfile updates across 9 envs. All 9 changed files are uv.lock files — no source, config, or Dockerfile changes are included; the diff is genuinely lockfile-only. However, there is a substantive semantic change buried inside the lockfile churn that goes beyond routine version bumps: most envs migrate their core dependency from the openenv-core package to the openenv package. This migration and two other items need human attention before merge.

---

Automated Checks

• Lint: PASS — no lint issues introduced (lockfiles only, not Python source).
• Debug code: CLEAN.

---

Tier 1: Fixes / Items to Resolve

• envs/terminus_env/uv.lock — incomplete migration. terminus_env is the only env in this PR where openenv-core is not migrated to openenv. Its lockfile still pins openenv-core==0.2.3 and its requires-dist still references openenv-core, while every sibling env in this PR completed the migration. Either migrate terminus_env too, or explicitly note why it's excluded. As-is, terminus_env will diverge from all sibling envs on a dependency that is being actively consolidated.

---

Tier 2: Alignment Discussion

ALIGNMENT FLAG: openenv-core → openenv package rename is a substantive change, not a routine dep bump.

• Principle at stake: "Minimize lifecycle deltas" (PRINCIPLES.md) and the breaking-change policy (INVARIANTS.md).
• Concern: The lockfiles record that most envs are switching their declared dependency from openenv-core to openenv (the main package now absorbing core functionality). In calendar_env this is a jump to openenv==0.3.1; the openenv 0.3.1 wheel size matches the old openenv-core 0.3.0 wheel, confirming a package rename/merge rather than just a version bump. This is a deliberate dependency-graph change (not something Dependabot would generate) and is not described in the PR body at all — the body frames this as a pure lockfile-only Dependabot rollup. Reviewers approving on the stated scope would be unaware of the dependency restructuring. Please call this out explicitly and confirm the corresponding pyproject.toml changes landed elsewhere.

ALIGNMENT FLAG: PR body scope vs. actual diff.

• The PR body says "only updates third-party environment uv.lock lockfiles." The actual diff touches 9 envs (calendar, chess, coding, finqa, julia, opencode, terminus, textarena, wildfire), consistent with the file list — but the more important gap is that the openenv-core → openenv migration is undocumented.

---

Additional Notes (Non-blocking)

• Version consistency: All migrated envs resolve openenv==0.3.1 with a matching sdist hash; hashes are consistent across lockfiles — no mismatches detected.
• Routine third-party bumps: starlette 1.0.0→1.0.1, tornado 6.5.5→6.5.6, authlib 1.7.0→1.7.1, greenlet wheel-arch removals — all routine, no major-version jumps, no yanked packages.
• No src/ changes: Confirmed.

Verdict: comment — lockfile mechanics look clean, but the undocumented package migration and the incomplete terminus_env case should be resolved/clarified before merge.

---

Automated review by Claude Code | Learn more

[burtenshaw]

Reopening this env Dependabot rollup so maintainers still have a single PR for the remaining env dependency updates. There are no currently open single Dependabot PRs.

[Darktex]

Note: This is an automated review by Claude Code, not a human review.

---

Alignment Review Report

Automated Checks

• Lint: PASS - All changed files are uv.lock files (generated, not linted by ruff/usort).
• Debug code: CLEAN - No source code changes; lockfiles only.

Open RFCs Context

No open RFCs in rfcs/ are directly relevant to dependency management or the openenv-core -> openenv package consolidation. RFCs 001-005 cover abstractions, env spec, MCP support, rubrics, and agentic harnesses — none address PyPI packaging topology.

Tier 1: Fixes Required

• envs/calendar_env/pyproject.toml — pyproject.toml still lists both openenv-core>=0.2.0 AND openenv>=0.1.13 as separate dependencies. The lockfile resolves this to openenv 0.3.1 only (dropping openenv-core), but the source of truth (pyproject.toml) is not updated. This creates drift: a fresh uv lock may behave differently, or a developer reading pyproject.toml will see a stale requirement for a now-defunct package. The pyproject.toml should be updated to remove openenv-core>=0.2.0 and pin openenv>=0.3.1.

• envs/chess_env/pyproject.toml and all other envs included in this PR — The lockfiles for chess, coding, finqa, julia, opencode, terminus, textarena, and wildfire envs now resolve openenv-core -> openenv 0.3.1, but their pyproject.toml files still declare openenv-core[core]>=0.2.2. These are the source-of-truth manifests. If the PyPI rename is real and openenv-core is deprecated/removed, any environment that runs uv sync from a cold cache against these pyproject.toml files may fail or pull a wrong version. The pyproject.toml files for all 9 affected envs need to be updated in lock-step with the lockfiles.

Tier 2: Alignment Discussion

ALIGNMENT FLAG: Implicit package consolidation (openenv-core absorbed into openenv) without RFC or documented decision

• Principle at stake: "Key Decisions Made — documented in RFCs and should not be changed without a new RFC" (PRINCIPLES.md). The packaging topology (what the published openenv PyPI package exposes and depends on) is core infrastructure.
• The concern: The openenv package jumped from v0.1.13 (a 2020 stub with only numpy as a dependency) to v0.3.1 (published 2026-06-02), and now carries all the dependencies previously in openenv-core (fastapi, fastmcp, gradio, uvicorn, websockets, etc.). This is a major change in what the openenv PyPI package means to downstream consumers. There is no RFC, no CHANGELOG reference, and no mention in the PR body of whether this rename was intentional and who approved it. The PR body says "rolls up Dependabot updates" — but this is not a routine version bump; it is a package identity change.
• Suggested reviewer: @Darktex

ALIGNMENT FLAG: check-env-docs CI failure acknowledged but not resolved

• Principle at stake: "Be hands-on — provide ready-to-use implementations" (PRINCIPLES.md); correctness of the repo as a whole.
• The concern: The PR description acknowledges check-env-docs was failing due to "pre-existing docs drift (maze, reasoning_gym, textarena, websearch)". Merging with a known failing CI check — even if pre-existing — normalizes CI failures and makes it harder to distinguish new regressions.
• Suggested reviewer: @Darktex

Summary

• 2 mechanical issues to fix (pyproject.toml files not updated to match lockfile package rename across all 9 affected envs)
• 2 alignment points for human review (package identity change without RFC; acknowledged CI failure being merged past gate)

---

Automated review by Claude Code | Learn more

[Darktex]

Note: This is an automated review by Claude Code, not a human review.

---

Alignment Review Report

Automated Checks

• Lint: N/A — PR modifies only lockfiles; no Python source changed
• Debug code: CLEAN — no debug code introduced by this PR

---

Tier 1: Fixes Required

Critical: lockfile/pyproject.toml mismatch across all updated envs

This PR updates lockfiles to resolve openenv-core as openenv 0.3.1, but the pyproject.toml manifests for those same envs were not updated. This creates an inconsistency where the resolved graph no longer matches the declared requirements:

Env	pyproject.toml declares	Lockfile resolves
chess_env	openenv-core[core]>=0.2.2	openenv 0.3.1
coding_env	openenv-core[core]>=0.2.2	openenv 0.3.1
finqa_env	openenv-core[core]>=0.2.2	openenv 0.3.1
julia_env	openenv-core[core]>=0.2.2	openenv 0.3.1
textarena_env	openenv-core[core]>=0.2.2	openenv 0.3.1
wildfire_env	openenv-core[core]>=0.2.0	openenv 0.3.1
opencode_env	openenv-core[core]>=0.3.0	openenv 0.3.1
calendar_env	openenv-core>=0.2.0 + openenv>=0.1.13	openenv 0.3.1

The lockfile represents the PyPI package openenv 0.3.1 having absorbed what was previously in openenv-core. This is a package rename/consolidation, not a routine Dependabot version bump. The pyproject.toml files should be updated atomically with the lockfiles, otherwise:

• A fresh uv sync on a clean clone may fail to find openenv-core on PyPI (if yanked/unmaintained), or install both openenv-core and openenv, introducing duplicate code.
• CI environments that uv sync from scratch will be in an inconsistent state.

Action required: Either update all affected pyproject.toml files to replace openenv-core[core]>=... with openenv[core]>=0.3.1, or explain how openenv-core is still satisfied (e.g., a compatibility shim).

Also note: many envs are not touched by this PR and still reference openenv-core in both pyproject.toml and lockfiles (e.g., atari_env, browsergym_env, echo_env, agent_world_model_env). This leaves a split state across the repo that will confuse contributors. The migration should be either complete or clearly deferred.

---

Tier 2: Alignment Discussion

ALIGNMENT FLAG: openenv package consolidation may warrant RFC coverage

• Principle at stake: PRINCIPLES.md — architectural decisions (collapsing openenv-core as a separate PyPI package into openenv) warrant discussion / an RFC per the contribution workflow.
• The concern: openenv 0.3.1 now carries the full server/core dependency set (fastapi, fastmcp, gradio, httpx, huggingface-hub, openai, pydantic, pyyaml, requests, rich, tomli, tomli-w, typer, uvicorn, websockets). This is a substantial shift in the published-artifact model that affects all downstream users and CI/CD pipelines. There is no RFC in rfcs/ visible to this review covering this consolidation. If the rename is intentional and approved, a short note/RFC reference in the PR description would help reviewers.
• Suggested reviewer: @Darktex

---

Summary

• 1 mechanical issue to fix (lockfile/pyproject.toml mismatch — the migration appears half-done)
• 1 alignment point for human review (package consolidation scope and RFC coverage)

The third-party version bumps themselves (starlette 1.0.0→1.0.1, tornado 6.5.5→6.5.6, authlib 1.7.0→1.7.1) are all clean patch-level updates with no concerns. The greenlet wheel pruning (dropping s390x and riscv64 variants) is benign. The macholib marker refinement in chess_env is mechanical and correct.

---

Automated review by Claude Code | Learn more