v1.3.0

What's changed

appmap-gold-traces: name the framework, record in batches

• The manifest can now name the test framework instead of spelling out a full command. commands.framework takes pytest, unittest, rspec, minitest, rails-test, jest, vitest, mocha, maven, or gradle. The engine knows how each one names a test on its command line and how it names several, and records the whole gold set in as few runs as the framework allows: one pytest run, one jest run with a name filter, one mvn run with a -Dtest= list, one run per file for minitest. Each agent still writes one recording per test, so entries keep their own appmap_path.
• Optional commands.runner replaces the launcher and commands.args appends flags. commands.record remains as the full-template path for a runner the engine does not know; the two are exclusive.
• With runner unset, the engine detects it per project. A Python .venv or venv that has appmap-python installed is run with both tools named by path, because appmap-python finds its command through PATH and does not add the venv to it, so the plain form ran a foreign pytest and recorded nothing. uv, Poetry, and Pipenv projects run through their own run. Maven and Gradle prefer the project's wrapper script.
• Batches are bounded by the machine's shell limit, measured at run time: getconf ARG_MAX minus the environment on POSIX, capped by Linux's 128 KB single-argument limit, and the 8 KB line on Windows. A run that would exceed it is halved until every piece fits. Optional commands.batch_size caps the count per run on top of that, for isolating a flaky test.
• New plan command prints the record commands the engine would run, and which entries each covers, without running anything. --help lists the frameworks with their default launcher, what is detected, and what test_name means for each.
• The registry lives in assets/frameworks.mjs with its own tests; manage.test.mjs gains end-to-end batch tests against a stub runner.
• Maintain step: when a release materially changes a subsystem an entry already guards, extend that entry's expect with the new release-critical code objects, using the project code objects that check --record prints as the candidate list. The baseline's contract grows with the code.

appmap-review: review before committing

The pipeline only read gold traces from git, but the gold-traces workflow reviews before blessing, when the recordings are not committed. A new "Head from the working tree" section and a step 1b in the script extract the head side from disk: (a) the fresh, sanitized recordings under appmap_dir for the manifest's entries, the exact set update would bless; or (b) gold_traces/ after a bless and before the commit. The gold-traces maintain step now names source (a).

appmap-record and appmap-config: one file per language

Both skills were mostly four language sections, so an agent working on one language read three it did not need. Each language now lives in languages/<lang>.md, and SKILL.md keeps the general material and ends with a table mapping language to file. Names, descriptions, and cross-references are unchanged. appmap-record also gains proper frontmatter and indexes with ~/.appmap/bin/appmap, matching where the other skills expect the tools.

appmap-setup and appmap-setup-review

docs/appmap.md now records the framework name and launcher, so the pair pastes into commands.framework and commands.runner unchanged; the full-command form with placeholders is kept for unknown runners. appmap-setup-review's gold-traces phase points at plan to confirm the commands before recording.

Full changelog: v1.2.1...v1.3.0