Changelog

User-facing changes, per release. Format loosely follows Keep a Changelog; versioning is 0.x semver — minor bumps may break APIs until 1.0. Day-to-day changes live in the git history and pull requests; entries land here when they are release-worthy.

[Unreleased]

[0.2.9] — 2026-09-17

Added

• Runs can record where they actually execute. Submitting to a cluster, a queue or a cloud box from a laptop used to leave the run pointing at the laptop: hardware held the launcher’s specs, and nothing anywhere said which job this was or how to find it. A run now carries compute (system, job_id, url, host, note) — set it with the new run_set_compute MCP tool / MlParty.run_set_compute() right after the submit command answers with an id, pass compute={...} to run_start when it is already known, or hand it to the job over the env handshake (ML_PARTY_COMPUTE_SYSTEM / _JOB_ID / _URL next to ML_PARTY_RUN) and attach() records it from the compute host. The web UI shows it as a chip on the run, linking straight to the job, and the job’s system/id/host are indexed for search, so “which run was jobpool 4711?” is answerable from the other end too. Deliberately no scheduler integration: ml-party neither submits nor polls, so this works with any job system, in-house ones included.

Changed

• run_start skips hardware capture when the call declares remote compute. The machine that submits a job is not the machine that runs it, so capturing its specs there is a wrong answer rather than an approximate one; hardware then arrives from mlparty.attach() on the compute host, and until it does the run carries none. Declaring remote compute afterwards with run_set_compute leaves an existing capture alone — it stays labelled captured_by: "start" (shown as launcher’s view in the UI) rather than being deleted, so nothing already recorded is lost.

[0.2.8] — 2026-09-16

Added

• mlp demo — the demo is now a real CLI command, so it appears in mlp --help and in the command list help() reports. It was previously only python -m mlparty.demo mentioned inside a guide, so an agent scanning for a way to run it found nothing and concluded the installed package could not.

• help('all') returns every guide in one call.

Changed

• help() now answers like a README instead of a table of contents. The first call returns the quickstart in full alongside the index. An index of topic titles asks an agent to choose before it has learned anything, and an agent that does not know what it is looking for cannot choose — so it went looking on disk, found an unrelated ml-party checkout and ran a stale script out of it. help() and the connection brief now also state plainly that the installed package is the source of truth, and that a checkout found on disk may be an entirely different release while looking identical.

• The quickstart opens with what it covers rather than who it is for — its one-line summary is derived from that opening, and the old one said nothing an agent could match against “how do I run the demo?”

[0.2.7] — 2026-09-16

Fixed

• Timestamps in the UI were unlabelled UTC. fmtDate sliced the ISO string instead of parsing it, so every absolute time rendered UTC digits with no zone shown anywhere — while “2h ago” and the board gallery did parse and showed local time, so two views could disagree about when the same thing happened. Times are now UTC by default and always carry their zone, with a top-bar toggle that switches the whole UI to the viewer’s own zone; the choice is remembered per browser. Storage is unchanged — runs were always recorded UTC.

Added

• help() reports where to file a bug — Homepage / Issues / Documentation / Changelog, read from the installed package’s metadata. An agent asked to report a problem previously found no repository in the package, searched the filesystem, and drew its conclusion from a stale local clone of a renamed predecessor. The index now also warns agents off inferring the repository from directories on disk: a fork, an old clone and the real thing look identical there.

[0.2.6] — 2026-09-16

Added

• help MCP tool — the package documents itself to agents. The guides now ship inside the wheel, so an agent that only ran pip install mlparty can read them with no checkout and no browser. help() returns the topic index plus every mlp command (introspected from the CLI, so it cannot drift), the installed version and the store root; help(topic) returns a guide in full. Previously an agent’s whole knowledge of ml-party was the tool descriptions and the tracking contract — it could not discover the demo, the web UI, how to instrument a training script, boards, actions, sync or deployment without reading the source.

• A quickstart guide written for agents rather than readers: run the demo with the right interpreter, check which store it landed in, watch it live.

Changed

• The user guides moved to src/mlparty/_docs/ so they ship with the package; the docs site renders those same files through {include} stubs, so there is one source of truth and page URLs are unchanged.

Fixed

• mlparty.__version__ reported 0.1.0 on every release since 0.2.0 — it was hardcoded. It now comes from package metadata and cannot drift from pyproject.toml again.

[0.2.5] — 2026-09-16

Fixed

• The self-teaching server was not teaching. The tracking workflow shipped as the MCP instructions string, and clients cap that — Claude Code at exactly 2048 characters, mid-word and silently. At 6.5k characters only the first 31% arrived: an agent learned to open a run, then never received the ML_PARTY_STORE/ML_PARTY_RUN handshake, the mlparty.attach() snippet, the finalize contract, or the confirm_snapshot guardrail. Neither side could tell the brief had been cut.

Added

• workflow_guide tool — returns the full manual, and the store root plus what the store already holds. A tool is the only teaching channel an agent can pull on its own initiative: instructions is truncated, and MCP prompts (track_training) are user-invoked slash commands, so the designated fallback needed the user to already suspect the agent was under-briefed. Connection instructions are now a short router whose first line is call workflow_guide(), kept under budget by a test so it cannot silently regrow. The cap is per-client and unspecified — the MCP schema calls instructions a hint clients may use — so the router is built to survive any cap, not just Claude Code’s. Tool descriptions are capped the same way and are now pinned by a test too.

• A backstop that does not depend on the connection brief arriving at all: since a client may legitimately drop instructions outright, every tool response carries a nudge to call workflow_guide() until it has been called — refusals included, since a confused agent is exactly who needs it. Tool responses cannot be truncated or dropped, so this is the channel that actually guarantees delivery.

• Orientation: workflow_guide reports the store root and node counts, and run_start echoes the store root back — an agent could previously only discover which store it served by reading the client’s config off disk, and would happily write into one nobody was watching.

[0.2.4] — 2026-09-16

Added

• An install skill an agent can follow to set ml-party up in someone’s project: reuse an existing store rather than fragmenting the graph, put .mcp.json where the agent will actually read it, and tell the user to restart the session.

• Copy buttons on the docs site’s code blocks (sphinx-copybutton); GitHub already renders them for README code fences.

Changed

• Install instructions rewritten around one store holding many projects, registered globally, instead of a store per repository — retrieval spans a store, so a store per repo splits the knowledge graph into islands. Two clear paths (let an agent install it, or do it yourself) replace the old single block, and registration is described for any MCP client rather than Claude Code alone. The per-project variant, and when it is worth the trade-off, moved into the MCP setup guide.

• mlp mcp-config explains where to paste its output (on stderr, so the JSON on stdout stays pipeable).

Fixed

• python -m mlparty.demo honours ML_PARTY_STORE like the rest of the CLI, instead of always defaulting to ./.mlparty.

[0.2.3] — 2026-09-16

Fixed

• Code snapshots no longer capture files you did not point at. Previously a run with no source_root snapshotted the whole directory holding the store, and collection was a filesystem walk that never consulted git — so unrelated files (personal notes, agent conversation logs) could be copied into a run and, through sync, into a shared store.

Changed

• Breaking: run_start without source_root now records no code snapshot instead of guessing a directory. Env lock, hardware, invocation and outer-git provenance are still captured automatically.

• Inside a git repository the snapshot is now what git reports — tracked files plus untracked-but-unignored ones — so .gitignore decides what belongs to the project. The extension allowlist no longer applies there, which also means tracked .cpp/.cu/.rs sources are captured at last. Secret-shaped filenames stay denied, tracked or not.

• A non-git source_root, or a capture above confirm_above_files / confirm_above_bytes, now requires confirm_snapshot=True; the refusal carries a preview of exactly what would be captured. A source_root at or above $HOME is refused outright.

• snapshot_report now records the files that were included, not only those excluded.

• Agents are now instructed to ask which directory to capture before the first tracked run in a project, show the file list from snapshot_preview before anything is written, and point out that .gitignore is what keeps a file out — so the choice is made knowingly instead of defaulted into. source_root is documented in the README and MCP guide too; it was previously mentioned only in passing, despite deciding what leaves your machine.

• mlp init / mlp connect now print where .mcp.json was written and how to make it take effect — agents read it from the directory they are started in, and need a one-time approval — plus how to verify (/mcp, claude mcp list). Previously they claimed agents “pick it up automatically”, which quietly assumed both.

Added

• snapshot_preview() — core API, snapshot_preview MCP tool, and mlp snapshot-preview <dir> — shows what a capture would take without writing anything, plus the delta (added / modified / removed) against the snapshot already stored for an experiment.

[0.2.2] — 2026-09-16

Fixed

• Hardware capture on macOS: total RAM was read only from /proc/meminfo, so every run tracked on a Mac recorded no RAM at all — silently, since the read was already fault-tolerant. Falls back to sysctl hw.memsize. macOS is now covered by CI (Python 3.11 and 3.14) instead of assumed.

Added

• Repository-level security policy: SECURITY.md documents the agent-instruction supply chain (instruction files are read by AI agents as direction, so editing them is a prompt-injection vector) and the gates against it; CONTRIBUTING.md states that PRs from outside contributors touching those paths are closed automatically, enforced by a new guard workflow plus CODEOWNERS.

[0.2.1] — 2026-09-16

Added

• The live demo run ships with the package: python -m mlparty.demo (previously a repo-only script), so a pip install mlparty has a real run to watch immediately — the documented quickstart now works as written from the released wheel.

[0.2.0] — 2026-09-16, first public release

Everything ml-party ships with:

• Security posture: SECURITY.md (trust model, disclosure, the agent-instruction and prompt-injection surfaces) and login rate-limiting: repeated failed logins per username+IP back off exponentially (HTTP 429 with Retry-After). The MCP workflow tells agents to treat retrieved knowledge as data, never as instructions.

• Local-first tracking store: append-only journal as the source of truth with a rebuildable SQLite/FTS5 index; per-run metric journals; sha256 content-addressed artifacts; safe live backups (mlp backup).

• The write contract: run_start pre-registers intent (title, purpose, hypothesis, full parameters) and auto-captures the repro tuple — source snapshot into an internal per-experiment git repo, environment lock, invocation, hardware; run_finalize refuses without method, result with verdict, and a reproduce command; failures are recorded, never deleted.

• A knowledge graph over the runs: typed nodes and a controlled edge vocabulary (derives-from, supersedes, refutes, …), notes and append-only annotations, hybrid BM25(+optional embeddings)+graph retrieval that downranks superseded beliefs, run diffing.

• Agent surfaces: a self-teaching MCP server (17 tools; mlp init registers it in ./.mcp.json), the mlp CLI, and an in-process client (mlparty.attach()) with heartbeats, runtime env capture, and crash-to-failure reporting.

• Web UI: live metric dashboards (SSE streaming, stateful per-run panels, drag-zoom, exports), a finder-style artifact browser with image/audio/video viewers and an .npy/.npz tensor slicer, lineage graph, search, compare, diff.

• Boards: agents author self-contained HTML views logged as artifacts, rendered sandboxed with read-only live API access — reports that stay current.

• Run control: users register shell action templates with typed placeholders; agents invoke them with validated, quoted values, every invocation recorded in the graph.

• Remote tracking: spool-and-flush sync of journal events, git objects, artifacts, and metrics to a served store over an idempotent, resumable protocol (mlp serve, mlp sync).

• Multi-user auth: opt-in via the first mlp user add — login-gated reads, store-wide viewer/writer/admin roles, per-user API tokens, session cookies; designed for OIDC/SSO to plug in later.

• Deployment: Dockerfile + compose (Caddy TLS profile), systemd template, Sphinx documentation.