11. Package and install the application

A discoverable contract is not yet an installable application. Studio's release includes its Python child, browser files, declared manifest, schemas and exact dependency artifacts. The installed code and advertised descriptors must agree.

Understand the three deliverables

Deliverable	Contents	Consumer
Authoring SDK	Public Python contracts and helpers	Application developers.
Studio source/package	Application implementation, assets, schemas and manifest	Contributors and the managed host.
Host/publisher tooling	Build/sign/install/launch machinery	Operators and release tooling.

The Studio source is intended to be public teaching material. That does not make private SDK implementation or separately managed publisher tooling part of its download. Consult Get the SDK for delivered artifacts and tooling availability; do not assume an internal command is already a public package.

Define the package entry point

Studio's capability.toml points at:

Studio package specification excerpt

package = "foxlight_video_studio"
package_root = "src"
entry = "foxlight_video_studio.child"
validator = "foxlight_video_studio.packaging:validate_manifest"

The child entry starts managed IPC and application resources. The validator compares the supplied manifest with the manifest the code constructs for the same artifact identity, including the configuration schema. A release cannot advertise one set of permissions or contracts and package another.

Do not treat a specification excerpt as the complete package file. Studio also declares packaged data files; these are essential for the browser interface.

Generate and pack in order

The repository's pipeline:

1. Export Python/SDK schemas.
2. Generate web-client types from those schemas.
3. Validate and build the browser application.
4. Pack browser output into the Python package.
5. Update the specification's exact data-file inventory.
6. Build and validate the capability artifact against its manifest.
7. Sign/publish with the release toolchain and immutable artifact identity.

tools/pack_web.py builds web/, copies its output into packaged static files and updates the data-file inventory. Missing this step can produce a working Python child with a broken or outdated interface.

With the pinned repository dependencies installed

uv run python tools/export_schemas.py
npm --prefix web run gen:api
npm --prefix web run check
uv run python tools/pack_web.py

Studio's publisher uses capability-build with a spec, manifest and wheelhouse. That tool is separate from the public seven-module authoring SDK at this revision. Signing and distribution require the appropriate delivered toolchain; copying these repository files is not a substitute for it.

Pin dependencies and artifact identity

Studio's reviewed source revision is 5cf917fed8387943bec7b27eea882b598a73c3fe. Its Python dependency specification pins the SDK and host source dependency to 4d1a33331bef8a2313f75da98b4ceab1bed162d6. The documented public SDK interface is revision 31bb090b8f64689f87514e48385e22b6ad94a6c2, version 0.4.0.

These identify different things: a repository dependency pin and the qualified public-module revision. Preserve the reviewed dependency relationship rather than silently replacing everything with whatever is newest.

Once issued, a release sequence is immutable. Changes to code, schemas, packed web output or dependency wheels need a new release identity and qualification. Keep signer material outside application source and static browser output.

Install, then prove the runtime

After a signed catalog/artifact is available, the operator reviews permissions, configures the application and installs through the managed host. Verify:

• The expected child starts and announces the expected descriptors.
• Health responds while work is active.
• The Studio surface URL opens from the operator's browser.
• Readiness accurately describes mounted model capacity.
• Plan, render, status, content download and explicit cancellation work.
• Restart retains accepted-job references and saved application files.

Installation and rendering are separate acceptance steps. An installed healthy package with no mounted video model should explain that missing capacity. It must not advertise a successful render qualification based only on startup.

Where to go next

Return to the architecture map and identify which parts your application actually needs. A small transform may only require one descriptor and a handler. A long-running application can reuse Studio's operation, storage and surface patterns without copying every feature.

Use the SDK reference, durable-jobs guide and qualification guide as you build. Product installation and inference APIs remain in Foxlight Docs.