# Move an existing project to Hypit 0.3

Use this guide when a project written for 0.2.x or an earlier development checkout needs to run on
0.3. The concrete target used here is `@hypit/hypit@0.3.1`.
New projects should use the current authoring references, not recreate the old forms below.

| Starting point | What to inspect |
| --- | --- |
| 0.2.x or an older checkout | Headers, authoring relationships, project components, Runtime selection and reusable Outputs in this guide; then the 0.3.1 SDK changes |
| Published 0.3.0 | The [0.3.1 import and dependency changes](0.3.1.md); do not assume the whole work needs rewriting |
| Version or origin unknown | Identify the active executable and inspect the actual file or import named in the error |

This is a guide to the main migration boundaries, not an automatic converter for every historical
package. Some changes are exact identifier replacements; others require preserving the meaning of
the particular work. Migrate only the features that production uses.

## 1. Identify and preserve the production

Before changing a working installation, keep its Sources, Recipes, Runs, project packages,
`package.json`, lockfile, Runtime Profile, assets and Results. Preserve a recoverable copy of the
files being edited. Do not overwrite credentials or replace accepted media merely to upgrade.

From the project directory, identify the executable actually used:

```sh
hypit version
hypit paths
```

For an existing project-local npm installation, use `npm exec --no -- hypit version`.
For the npx installation in this guide, use `npx @hypit/hypit@0.3.1 version`. These are alternative
launchers, not three installation steps. Inspect explicit project dependencies as well: choosing a
new executable does not update a project's older component packages or its lockfile.

The [installation reference](../skills/hypit/references/environment/distribution.md) explains the
separate executable, Skill and project lifecycles. If the Agent learned obsolete syntax from an old
Skill, update that Skill through its own installation channel and read its current instructions.

## 2. Check the document's syntax entry before installing a missing package

The first line selects the language reader. The suffix remains `.svml`, `.svs` or `.svrun`.

| Document | Earlier header | Header in 0.3.0 and 0.3.1 |
| --- | --- | --- |
| SVML Author | `<?svml using="@hypit/markup@1"?>` | Unchanged |
| SVRun | `<?svml using="@hypit/run-markup@1"?>` | `<?svml using="@hypit/markup/run@1"?>` |
| Ordinary SVS Recipe sheet | `<?svml using="@hypit/svs@1"?>` | `<?svml using="@hypit/recipe@1"?>` |
| Text-template SVS | `<?svml using="@hypit/text/svs@1"?>` | Unchanged; keep Text's reader for TextTemplate sheets |

These are logical reader identities, not npm package/version specifications. The official
Distribution includes these readers. Do not try to install the old reader name to make it resolve.
Changing a sheet's header selects its reader; the receiving component's Recipe properties still
need checking against its current interface.

### `cannot locate installed package @hypit/run-markup`

For this error, first change only the Run header. For example, a Run targeting `take.video` becomes:

```xml
<?svml using="@hypit/markup/run@1"?>
<svrun version="1">
  <author source="./swap8.svml"/>
  <target output="take.video"/>
</svrun>
```

Preserve the real Author path, Targets and any existing Candidate/reuse declarations. Then check it:

```sh
npx @hypit/hypit@0.3.1 check swap8.svrun
```

Here `npx` selects an executable, `@0.3.1` fixes its npm release, and `check` checks the Source and
graph without submitting generation. Successful Run-header parsing does not establish that its
Author, selected packages or Targets are valid; address the next specific diagnostic if one appears.

This reader change predates the published 0.3.0 release. It is not a 0.3.1-only package omission.
API credentials do not affect reader resolution. `hypit cli use` selects installed command
contributions, not document readers; `hypit packages install` is not a current command.
For a genuinely missing external capability package, use the project's ordinary package manager.
Ranking and other optional components, plus partner Providers, are not included in the default
installation. Install the selected package in the project, for example `npm install @hypit/ranking@^0.1.0`
or `npm install @hypit/provider-hiapi`;
for repository examples with a lockfile, use `npm ci` as their README directs.

## 3. Migrate the work's relationships, not just tag names

A larger 0.2 production may parse after the header repair and then expose obsolete Surfaces or
inputs. Use the following table to locate the owning part of the work. These rows are not global
search-and-replace rules.

| Earlier form in the project | What to express now | Current usage |
| --- | --- | --- |
| Program Space declarations or imports | Declare the Clock, Timeline and Canvas explicitly; construct Frames within the chosen spatial bounds | [Timeline](../skills/hypit/references/production/timeline.md), [space](../skills/hypit/references/production/spatial.md) |
| Timeline assembled from semantic `Take` entries | Construct a Timeline with a resolvable `end`; normalized media Extents can determine named Windows | [Timeline construction](../skills/hypit/references/production/timeline.md) |
| Components consuming Script Selection/Moment directly | Choose a Projection, publish a named absolute Window/Instant, and pass that value to the component | [Timing](../skills/hypit/references/production/timing.md) |
| Performance/Sound Tracks implicitly presenting Timeline material | Place normalized media explicitly in Visual Clips and Audio Clips, preserving the original picture and sound choices | [Visual Clips](../skills/hypit/references/production/visual-clips.md), [Audio Clips](../skills/hypit/references/production/audio-clips.md) |
| Media Track `Item`, presentation or playback presets | Re-express the occurrence using Visual Track's Clip, Frame and source-time sampling; inspect the intended fit, crop, trim, repeat or hold behavior | [Visual Clips](../skills/hypit/references/production/visual-clips.md) |
| Media Pipeline imports | Use Media Operations for normalization and processing; check each Surface's inputs and exported values | [Media](../skills/hypit/references/production/media.md) |
| Caption supplied only with Script content and Timeline | Produce absolute CaptionTiming through an explicit binding and Projection, then supply document and timing to the Caption component | [Caption presentation](../skills/hypit/references/production/caption-presentation.md) |
| Typography Track and its former recipes | Use Fine Text or the project's own text component; retain the intended text, Frame, style and named time inputs | [Fonts and text](../skills/hypit/references/production/fonts-and-text.md) |
| Fonts Open's bundled family names | Select the actual npm font dependency or local font files, preserving face, weight, style and required glyph coverage | [Fonts](../skills/hypit/references/production/fonts-and-text.md) |
| Render Hyperframes | Assemble the Film as an HtmlProgram/video through `@hypit/html-video@1`, with the local HTML Provider selected for execution | [Rendering](../skills/hypit/references/production/rendering.md) |

For example, a semantic passage is no longer a component's implicit time input:

```xml
<semantic:Window id="proof-window" projection={story-time}
  during={story.selection.proof}/>
```

The consumer then uses `during={proof-window}`. Here `semantic` imports
`@hypit/narrative-temporal@1`, `story-time` is an explicit Projection, and `story` is the Script
owning the Selection. Projection Maps connect aligned local domains to equal-length Timeline
Windows; those Maps do not place the picture or sound. Visual and Audio Clips do that separately.
Keep directly authored times as direct named time values when they express the original intention.

For Script-derived captions, the timing adapter uses data already produced from the Script:

```xml
<narrative-caption:Timing id="story-captions"
  document={story.caption}
  binding={story.caption-binding}
  projection={story-time}/>
```

Here `narrative-caption` imports `@hypit/narrative-caption@1`. Pass `{story.caption}` and
`{story-captions}` as the current Caption component's `document` and `timing`. Do not retype the
Script as a second subtitle document. Preserve authored `||` Cue boundaries and display/speech
relationships; the required Unit timings must be available through the selected Projection.

The [small production example](../skills/hypit/references/production/examples/production.svml)
shows current materials, Clock/Canvas, normalization, Timeline, Projection, Visual/Audio, Film and
video output together. Use it to understand wiring, not to replace the existing work's creative
structure or regenerate its accepted material. Inspect `hypit vocabulary <package>` and the owning
package's README for the exact installed Surface and output names.

## 4. Update project components and their imports

Some 0.2 SDKs changed responsibility as well as name. A component importing `author-kit`,
`component-kit`, `endpoint-kit`, `runtime-kit`, `visual-ir`, `program-space` or `studio-adapter`
cannot be assumed to migrate through a prefix replacement alone.

- Author components use the narrow Author, Producer, Admission and Markup APIs described in
  [component authoring](../skills/hypit/references/production/track-authoring.md).
- Visual and audio values use Composition and the relevant domain packages. HTML components use
  the current HtmlVisual/HtmlProgram interfaces, not the former Hyperframes API.
- Providers use the [Endpoint SDK](../packages/endpoint/README.md) and their real domain dependencies.
- Editor behavior belongs to the component's Companion, using
  [Studio Companion](../packages/studio-companion/README.md). Separate historical `*-studio`
  imports need checking against the current owner's exports, not installation by guessed names.

For the 0.3.1 target, apply the exact [domain SDK import mapping](0.3.1.md#move-only-the-domain-imports)
and dependency guidance. Fix the component's owning source and manifest, then rebuild its declared
JavaScript entry. Keep the package manager and review its lockfile update. For third-party components,
select an available migrated release or agree on a source repair; do not silently patch an installed
copy and call the project migrated.

## 5. Keep project selection, installed code and execution configuration separate

The project is selected explicitly or through an ancestor `package.json` with `hypit.project: true`.
The Run's location does not choose another project. `hypit paths` reports the active locations.

Use an existing intended Profile through `hypit runtime use <profile>` or a command's
`--runtime <profile>`. If the project has no Profile, `hypit runtime init` creates a starter;
do not replace a production's working configuration with a starter merely to upgrade.
The [Profile reference](../skills/hypit/references/environment/profile.md) owns current configuration.

Review old Profile package names and adapter-specific options. Local execution uses Runtime Local;
HTML rendering uses `@hypit/provider-html-local`; local media execution uses `@hypit/media-local`;
credential selection uses the local or environment Credential Store. Preserve the chosen service,
account and storage location where applicable. Historical split storage/transport configurations
are not interchangeable with the current local Profile schema.

Environment variables supply credentials only when the selected Store/Provider reads them. A
`.env` file or a particular API key variable does not resolve an obsolete Source import. Resolve
syntax/package errors first; diagnose service access against the selected Provider's actual setup.

## 6. Preserve usable results and verify the real production

Do not rewrite old Result documents to pretend they have new types. Existing media files can often
be reused, while old structured media, alignment, caption or composition values may require
recomputation from retained inputs. Inspect their actual types and data before deciding.

Use current [Run Candidates](../skills/hypit/references/production/runs.md) to select compatible
completed Outputs. If only a raw video/audio/image can be carried forward, admit that actual file
through the current media path and perform the normalization or alignment the new consumers need.
Preserve the original Result and its resource files; do not discard them after copying a manifest.
Do not assume every old Blob type or structured `@1` value is compatible merely because its label
looks similar. Paid regeneration is a separate decision, not a migration default.

Verify in increasing scope using the production's selected launcher:

1. Build changed project components with their own build command.
2. Run `hypit check` on the actual Source and Run; resolve exact package, Surface, reference and type errors.
3. Run `hypit plan <run> --runtime <profile>` and inspect the remaining requests and explicit reuse choices.
4. Open the actual Run in Studio; check duration, picture, sound, captions and a representative passage.
5. Build/export only the work covered by the user's instructions and inspect the resulting video.

After dependency or Profile changes, account for
[process lifetimes](../skills/hypit/references/environment/profile.md#know-when-a-change-takes-effect).
Do not interrupt active production just to restart every helper. If migration is blocked, retain the
known-working executable, dependencies, lockfile and original work; report the specific missing
capability rather than promising that a successful header check completes the migration.