[binaryaaron]

Start UserSim 0.3 development at 0.3.0.dev0, move supported Python versions to >=3.11,<3.15, and require released data-designer>=0.10,<0.11. Python 3.10 users remain on the 0.2 release line. Python 3.12 remains the development default; the CI matrix, compatibility imports/dependencies, documentation, and packaging checks follow the new supported range.

This PR retains main's uv>=0.13.4 minimum and existing setup commands. Exact uv pinning, bootstrap/tool-check targets, and expanded stacked-branch CI triggers have been removed. UV_FROZEN remains removed.

The lock now uses all three Data Designer packages at 0.10.0 from PyPI. Temporary Git overrides and no-sources have been removed. The release follow-up also updates json-repair to satisfy DD engine's new minimum; other locked package versions are unchanged from the preceding PR revision.

Validation:

• 247 focused tests passed on Python 3.11.13 across packaging, CI workflows, network isolation, CLI, model catalog, and model facades. Locked installation confirms all three DD packages at registry version 0.10.0.
• Lock consistency, documentation links, and whitespace checks passed. The preceding narrowing also passed changed-file Ruff lint/format; the release follow-up changes no Python source.
• Full make check-dist passed on Python 3.12, including archive/Twine checks, a clean registry wheel installation outside the checkout, installed smoke, and simulation dry-run.

The preceding revision passed GitHub CI across Python 3.11–3.14 and wheel/extension checks. These local results apply to the new DD release revision; the full suite/matrix, container, and live-provider checks were not rerun locally. Dependent PRs remain unchanged and need separate stack reconciliation.

[github-actions]

All contributors have signed the DCO ✍️ ✅
_{Posted by the DCO Assistant Lite bot.}

[binaryaaron]

I have read the DCO document and I hereby sign the DCO.

[3mei]

@binaryaaron Thanks for putting this together, and for dropping working-memory/ and signing the DCO. Leaving a comment on each PR, but this one has choices that the rest of the stack depend on:

• Python 3.10 stays supported for the whole 0.2 line (build: support Python 3.10 to 3.14 #32). The main reason is the empty 0.0.0a0 placeholder PyPI holds for usersim. It declares no Requires-Python, so on any Python our releases exclude, pip skips our releases and installs the placeholder instead: the install looks fine, but there's no code and no usersim command. uv errors there once a final release exists, and a uv project that allows that Python can't lock until it narrows its range. If 0.2.0 dropped 3.10, that's what every 3.10 user would get. Keeping 3.10 through 0.2.x means 3.10 always resolves to a working release, and when 0.3.0 drops it, 3.10 users stay on the last 0.2.x, which still works. The placeholder stays on PyPI, so this applies to every release.

  Two smaller reasons: Data Designer, which User Sim runs on, supports 3.10 to 3.14, and 0.2.0rc1 already shipped declaring >=3.10. 3.10 reaches end of life this month, so 0.3.0 is the natural point to drop it.

• No upper bound on requires-python. With <3.15, a project whose own range reaches past it can't lock User Sim without narrowing its range, and lifting the cap would take a release.

• uv: a minimum, not an exact pin. required-version = "==0.13.1" stops anyone with a different uv from running anything here. Data Designer uses a minimum (>=0.7.10) and the latest uv in CI; a minimum is fine here too.

• UV_FROZEN is there so no step in CI or the release re-resolves the lock. Please keep it unless every uv call is covered by --locked.

• Branch names and commit subjects describe the session (codex/usersim-draft-prNN, "prepare PR05 with reviewed workflow simplifications"). Both end up in main's history (merge commits keep the branch name). It would be great to rename resubmitted branches and commits after the change.

[binaryaaron]

Closing this PR and renaming its branch to build/usersim-0.3-python311-dd010 so the name describes the change rather than the development session. The implementation is preserved on that branch.

We plan to use squash merges here, consistent with our other repositories, so the final commit title and description will describe the complete change rather than retain the intermediate development commits.

[binaryaaron]

Replacement PR: #119, using the descriptive branch name and the same reviewed implementation.