venice-video-harness 2.14.0 → 2.15.0

package/CHANGELOG.md

@@ -1,5 +1,59 @@
 # Changelog
 
+## 2.15.0 — 2026-08-06
+
+### Added
+
+- **Capability manifest: the probe-verified registry is now a machine-readable
+  export downstream clients can sync against.** New
+  `src/venice/capabilities-manifest.ts` builds a versioned JSON manifest
+  (`schemaVersion: 1`) carrying the full `VIDEO_MODELS` registry, the eight
+  exact-id capability sets (elements, referenceImages, sceneImages, endImage,
+  imageTags, audioInput, perReferenceAudio, referenceAudio), the budgets
+  (per-model reference-image caps, image-model prompt caps, the 2500-char
+  video prompt limit), and the routing defaults (action / atmosphere /
+  character-consistency / multi-shot / lip-sync / image models). Three ways
+  to consume it:
+  - `venice-video capabilities` — emits the manifest on stdout.
+  - `capabilities.json` at the repo root — a committed snapshot regenerated
+    by `npm run manifest` (wired into `prepack`, shipped in the npm tarball),
+    so clients can fetch the raw file from GitHub `main` or read it from an
+    npm install. `generatedAt` is pinned while data is unchanged, so the
+    snapshot only diffs when the registry actually moves.
+  - Library exports: `buildCapabilitiesManifest()`,
+    `renderCapabilitiesManifest()`, `CAPABILITIES_SCHEMA_VERSION`.
+
+  The manifest is data only — prompt builders and planners still ship with
+  each client. First consumer: the Venice Video Creator macOS app, which
+  fetches it at launch (behind a user toggle) to keep its
+  `VideoModelCapabilities` allowlists current between app releases.
+  `tests/capabilities-manifest.test.mjs` guards registry coverage, set
+  consistency, known-id routing defaults, deterministic rendering, and the
+  CLI command's JSON shape.
+
+### Fixed
+
+- **`MODELS_SUPPORTING_END_IMAGE` no longer lists the Wan 2.7 i2v family.**
+  The live queue rejects `end_image_url` on Wan 2.7 i2v (Uncensored/Spicy):
+  "This model does not support end_image_url" — probed 2026-07-06 during the
+  Venice Video Creator app sync. The `VideoModelSpec` entries already said
+  `supportsEndImage: false`; the set had silently drifted from the registry.
+  Caught by the app's bundled-manifest test the day the manifest went live.
+
+## 2.14.1 — 2026-08-05
+
+### Changed
+
+- **README: added a human-facing "Installing the CLI" section.** Installation
+  was documented only inside the agent-runner quick start; a person at a
+  terminal had no plain install path. The new section covers prerequisites
+  (Node 20+, ffmpeg/ffprobe), the global npm install with `setup` (interactive
+  or `--api-key`/`--workspace`/`--skip-validation`) and `doctor`, the three
+  bins on PATH (`venice-video`, `video-harness`, `storyboard`), the
+  from-source path (clone, `npm install`, `npm run build`, `npm run dev --` /
+  `node dist/mini-drama/cli.js`, `.env` for the API key), and pointers to
+  `pipeline` and `shell`. Docs only.
+
 ## 2.14.0 — 2026-08-05
 
 ### Changed

package/README.md

@@ -27,6 +27,52 @@ Most Venice integrations are thin wrappers around API calls. This package is the
 - **Comprehensive model registry** covering Venice video, image, audio, and music models
 - **Optional agent orchestration** in `AGENTS.md` and `.agents/` for users who want natural-language operation
 
+## Installing the CLI
+
+For a human at a terminal. (Driving it from an agent instead? See the next section.)
+
+**Prerequisites:** Node 20+, and `ffmpeg` + `ffprobe` on PATH (used for video/audio processing; `venice-video doctor` checks all three).
+
+### Global install (recommended)
+
+```bash
+npm install -g venice-video-harness
+
+venice-video setup     # prompts for your Venice API key + default project workspace
+venice-video doctor    # verifies API key, ffmpeg, ffprobe
+```
+
+`setup` prompts interactively (the API key prompt is hidden); for non-interactive use pass `--api-key <key>` and `--workspace <dir>`, or set `VENICE_API_KEY` in the environment. `--skip-validation` stores the key without contacting Venice.
+
+The install puts three commands on PATH:
+
+- `venice-video` — the primary CLI
+- `video-harness` — alias for the same CLI
+- `storyboard` — the legacy screenplay-ingestion CLI
+
+From there:
+
+```bash
+venice-video pipeline   # the ordered stages, their gates, and the command that advances each
+venice-video shell      # persistent interactive session: select a project once, background renders, /jobs
+venice-video --help     # everything else
+```
+
+### From source (development)
+
+```bash
+git clone https://github.com/jordanurbs/venice-video-harness.git
+cd venice-video-harness
+npm install
+npm run build
+
+# Run via tsx during development, or the compiled CLI:
+npm run dev -- pipeline
+node dist/mini-drama/cli.js pipeline
+```
+
+Put the API key in `.env` at the repo root (`VENICE_API_KEY=...`) — many scripts source it from there — or run `setup` as above.
+
 ## Driving this from an agent
 
 Instructions for a coding agent operating the harness — Claude Code, Cursor,
@@ -140,6 +186,19 @@ same core rules are installable as a skill for runners that pull skills from
 GitHub: `hermes skills install jordanurbs/venice-video-harness/venice-agent-guide`
 (and any of the other `.agents/skills/` by name).
 
+From **2.15.0** the probe-verified model registry is also machine-readable:
+
+```bash
+venice-video capabilities   # full capability manifest as JSON: model specs, capability sets, budgets, routing defaults
+```
+
+The same manifest is committed as `capabilities.json` at the repo root
+(regenerated on every release), so downstream clients — the Venice Video
+Creator macOS app is the first — can fetch
+`https://raw.githubusercontent.com/jordanurbs/venice-video-harness/main/capabilities.json`
+and stay capability-synced between their own releases without shelling out to
+the CLI.
+
 ### Running the harness in a separate runtime (containers, remote backends)
 
 Running long renders off the main machine is a real and useful capability. In