feat: initial commit - Jhonny Editor
- Adicionado estrutura completa do projeto - Configurado MCP server para Premiere Pro - Adicionado documentação e skills - Configurado Gitignore para o projeto
This commit is contained in:
João Henrique
Executable
+64
@@ -0,0 +1,64 @@
|
||||
# 30-Day Adoption Plan
|
||||
|
||||
**Date:** 2026-07-27
|
||||
|
||||
## Objective
|
||||
|
||||
Increase verified successful local activations of MCP for Adobe Premiere Pro, not merely repository traffic or package downloads. The current public signals show interest, but they do not establish how many people have connected a real Premiere host or completed an edit.
|
||||
|
||||
## Starting signals and measurement boundary
|
||||
|
||||
| Signal | Latest observed evidence | What it means | What it does not mean |
|
||||
| --- | --- | --- | --- |
|
||||
| GitHub traffic | 1,194 unique visitors and 835 unique cloners over Jul 13–26 | Discovery and evaluation interest | Active installs or successful editing sessions |
|
||||
| npm | 1,591 downloads over Jun 25–Jul 24 | Package distribution interest | Unique users or completed setup |
|
||||
| Production MCP telemetry | Not configured | No current activation funnel | No conclusion about past usage |
|
||||
|
||||
Before judging conversion, create a dedicated PostHog project, set the production `POSTHOG_API_KEY` secret, deploy the telemetry release, and confirm that privacy-safe events arrive. The relevant funnel is: `mcp_connection_attempt` → `mcp_request` → `mcp_tool_call` with a successful outcome.
|
||||
|
||||
## Days 1–7: reduce setup friction
|
||||
|
||||
1. Publish the landing and README corrections in this change: Node.js 20.19+ everywhere, npm-first client configuration, and bridge verification before edits.
|
||||
2. Add a short compatibility matrix that distinguishes packaged support from host-verified operations, including current QE DOM limitations.
|
||||
3. Record three short, real Premiere walkthroughs: inspect a project, plan a non-destructive edit, and complete one verified export. Show the Premiere version and the tool result in each.
|
||||
4. Claim and correct the Glama directory listing. Use the local-first setup, current package link, and host-verification boundary; do not list remote access as a replacement for the local CEP bridge.
|
||||
|
||||
**Exit evidence:** the published landing and README agree with `package.json`; one clean-machine installation can reach `get_capabilities` and `ping`; the directory listing points to the current setup.
|
||||
|
||||
## Days 8–14: reach the right users
|
||||
|
||||
1. Publish the three walkthroughs as a release post, README links, and short clips for editor/developer communities where MCP workflows are discussed.
|
||||
2. Create client-specific setup pages only after testing each client against the current package. Prioritize Claude Desktop, Cursor, Windsurf, and VS Code/Copilot because the repository already documents them.
|
||||
3. Turn high-frequency setup errors into concise troubleshooting entries, beginning with CEP signature, restart, temp-directory, and Premiere-version checks.
|
||||
4. Invite existing issue reporters and star/fork users to test the updated path; ask for Premiere version, OS, client, and whether `get_capabilities` and `ping` succeeded, never project media or paths.
|
||||
|
||||
**Exit evidence:** each promoted client path has a fresh, reproducible test; issue templates capture compatibility information without asking for sensitive project data.
|
||||
|
||||
## Days 15–21: convert interest into repeat use
|
||||
|
||||
1. Put three outcome recipes near the top of the README and landing: project inventory, safe edit plan, and verified export.
|
||||
2. Add a release checklist that pairs every feature claim with a host version and observable result.
|
||||
3. Triage the top failed connection and tool-call event types from PostHog; ship only evidence-backed fixes and document known host-specific limits.
|
||||
4. Add a lightweight feedback request after a successful first session, linking to GitHub Issues or Discussions rather than collecting media data.
|
||||
|
||||
**Exit evidence:** the first-use funnel has a measured baseline; the most common failure has an owner, status, and documented workaround or fix.
|
||||
|
||||
## Days 22–30: improve from evidence
|
||||
|
||||
1. Compare the activation funnel by client, OS, and Premiere major version using only the bounded telemetry fields.
|
||||
2. Prioritize the one onboarding step with the largest verified drop-off; avoid optimizing traffic until the connection and tool-success stages are understood.
|
||||
3. Refresh the directory listing, website, npm description, and release notes with only claims demonstrated in the walkthroughs and telemetry.
|
||||
4. Publish a transparent monthly compatibility update: tested host versions, known QE/UXP gaps, fixes shipped, and the next validation target.
|
||||
|
||||
**Exit evidence:** a baseline report distinguishes traffic, downloads, connections, requests, and successful tool calls; the next 30-day priority is selected from that report.
|
||||
|
||||
## Owners and external gates
|
||||
|
||||
| Work | Owner | Gate |
|
||||
| --- | --- | --- |
|
||||
| Landing/README release | Repository maintainer | Review, merge, and deploy this change |
|
||||
| PostHog activation funnel | Repository maintainer | Choose or create a dedicated PostHog project, set Fly secret, deploy, verify events |
|
||||
| Glama listing | Account holder | Claim access to the directory listing |
|
||||
| Compatibility proof | Maintainer or volunteer with a real host | Test the promoted client/OS/Premiere combination |
|
||||
|
||||
Do not treat a GitHub clone, npm download, HTTP health check, or unauthenticated production log line as proof of a working Premiere session.
|
||||
Executable
+36
@@ -0,0 +1,36 @@
|
||||
# Activation measurement boundary
|
||||
|
||||
The landing measures a bounded, anonymous acquisition funnel without collecting
|
||||
project data or linking a browser to an editor's Premiere project.
|
||||
|
||||
## Browser events
|
||||
|
||||
The public landing sends only route/action events and allowlisted campaign values:
|
||||
|
||||
1. assistant route selected;
|
||||
2. versioned download started;
|
||||
3. safe first prompt copied;
|
||||
4. illustrated demo played; and
|
||||
5. supporting CTA/recovery interactions.
|
||||
|
||||
Allowed campaign fields are `utm_source`, `utm_medium`, `utm_campaign`,
|
||||
`utm_term`, and `utm_content`. Values are length-bounded and character-filtered.
|
||||
Do not add prompts, project details, media names, file paths, tokens, personal
|
||||
identifiers, or opaque click IDs to this contract.
|
||||
|
||||
## Product activation evidence
|
||||
|
||||
The local MCP runtime separately emits two aggregate, privacy-bounded events when
|
||||
`POSTHOG_API_KEY` is configured: a first-run check started and finished. The finished
|
||||
event records only the CEP/UXP backend and `ready` or `needs_attention` outcome.
|
||||
|
||||
Browser acquisition events and local activation telemetry deliberately have no shared
|
||||
user identifier. Use aggregate funnel trends and voluntary support feedback; do not
|
||||
claim an individual download completed an install or a Premiere workflow.
|
||||
|
||||
## Paid-acquisition gate
|
||||
|
||||
Before activating a campaign, verify that conversion actions are receiving events
|
||||
in the advertising account, that the privacy policy reflects the deployed analytics
|
||||
behavior, and that the landing's download points to the current release. Campaign
|
||||
creation, spend, or activation requires separate owner approval.
|
||||
Executable
+26
@@ -0,0 +1,26 @@
|
||||
# Adobe Premiere API inventory
|
||||
|
||||
The generated inventory is stored at `src/resources/adobe-api-inventory.json`
|
||||
in the repository and at `dist/resources/adobe-api-inventory.json` in the
|
||||
published package. It is the exhaustive review queue for the stable
|
||||
`@adobe/premierepro` declaration package pinned by this repository. It records
|
||||
every exported type, namespace, enum, property, method, constructor, and call
|
||||
signature, fingerprints the normalized declarations, and compares exact symbol
|
||||
names with `src/resources/adobe-uxp-coverage.json`.
|
||||
|
||||
Run `npm run adobe:api-inventory` after intentionally changing the Adobe package
|
||||
or the coverage manifest. CI runs `npm run adobe:api-inventory:check`, so package
|
||||
surface drift or a stale generated file fails closed.
|
||||
|
||||
`mapped` means only that an exact declaration symbol appears in a coverage entry.
|
||||
It does not mean that the symbol needs a standalone MCP tool, that every argument
|
||||
shape is exposed, or that a licensed Premiere host verified it. `unmapped` is a
|
||||
triage queue: each entry must eventually be mapped to a tool/workflow, classified
|
||||
as an auxiliary value/type, or documented as intentionally unsupported with a
|
||||
specific reason. `manifestOnly` exposes aliases or stale names referenced by the
|
||||
coverage manifest but absent from the pinned declarations.
|
||||
|
||||
The inventory covers the Premiere DOM declarations. General UXP JavaScript,
|
||||
HTML/CSS/Spectrum, Hybrid C++ SDK, CEP/ExtendScript, and undocumented QE surfaces
|
||||
need separate inventories and evidence boundaries; this file must not be used to
|
||||
claim those surfaces are complete.
|
||||
+34
@@ -0,0 +1,34 @@
|
||||
# Adobe beta AAFExportOptions declaration drift
|
||||
|
||||
`src/resources/adobe-beta-aaf-export-options-drift.json` records the narrow
|
||||
factory-type migration for `AAFExportOptions` between this repository's pinned
|
||||
stable `@adobe/premierepro@26.3.0` package and its pinned
|
||||
`@adobe/premierepro@26.5.0-beta.73` alias. The package sources are the
|
||||
[stable npm package](https://www.npmjs.com/package/@adobe/premierepro/v/26.3.0)
|
||||
and the
|
||||
[pinned beta npm package](https://www.npmjs.com/package/@adobe/premierepro/v/26.5.0-beta.73).
|
||||
|
||||
In stable declarations, `premierepro.AAFExportOptions` names the options type,
|
||||
which contains construct and call signatures. In beta declarations, the root
|
||||
binding names the new `AAFExportOptionsStatic` type instead; its factory
|
||||
signatures match the stable shapes, while the non-factory option members remain
|
||||
unchanged. The receipt records that binding change, the new static type, and
|
||||
the moved factory signatures.
|
||||
|
||||
It does not create `AAFExportOptions`, expose an MCP action, or start an AAF
|
||||
export. Static declarations do not prove that a beta host exposes the factory,
|
||||
that export settings, output paths, or effect behavior are accepted, or that an
|
||||
AAF export starts or completes. It also does not establish beta support, stable
|
||||
support, or licensed-host validation.
|
||||
|
||||
Generate the receipt after intentionally changing either pinned package:
|
||||
|
||||
```sh
|
||||
npm run adobe:beta-aaf-export-options-drift
|
||||
```
|
||||
|
||||
CI and `npm run check` use
|
||||
`npm run adobe:beta-aaf-export-options-drift:check` to reject a stale receipt.
|
||||
Promotion beyond static accounting requires a public stable release and
|
||||
documentation, an explicitly bounded AAF-export capability design, and
|
||||
controlled licensed-host verification.
|
||||
Executable
+38
@@ -0,0 +1,38 @@
|
||||
# Adobe beta C2PA declaration drift
|
||||
|
||||
`src/resources/adobe-beta-c2pa-drift.json` records the narrow C2PA declaration
|
||||
surface that is absent from this repository's pinned stable
|
||||
`@adobe/premierepro@26.3.0` package and present in its pinned
|
||||
`@adobe/premierepro@26.5.0-beta.73` alias. The package sources are the
|
||||
[stable npm package](https://www.npmjs.com/package/@adobe/premierepro/v/26.3.0)
|
||||
and the
|
||||
[pinned beta npm package](https://www.npmjs.com/package/@adobe/premierepro/v/26.5.0-beta.73).
|
||||
|
||||
The generated receipt covers only:
|
||||
|
||||
- the `premierepro.C2PAService` root binding;
|
||||
- `C2PAServiceStatic` and its declared members;
|
||||
- the empty `C2PAService` instance type; and
|
||||
- `Constants.C2PAManifestLocation` member identifiers and declaration order.
|
||||
|
||||
It does not generate an MCP action or call `C2PAService`. The stable package
|
||||
does not declare this surface. The beta package declares `getManifest` and
|
||||
manifest-location constants, but static declarations alone do not show that a
|
||||
beta host exposes them, that a stable host accepts them, or that a file's
|
||||
manifest can safely be read or validated.
|
||||
|
||||
`C2PAManifestLocation` has implicit TypeScript enum initializers. The receipt
|
||||
records source order, not runtime numeric flag values or C2PA manifest-location
|
||||
semantics. In particular, no caller should infer a numeric value from this
|
||||
receipt or treat it as a content-credential verification result.
|
||||
|
||||
Generate the receipt after intentionally changing either pinned package:
|
||||
|
||||
```sh
|
||||
npm run adobe:beta-c2pa-drift
|
||||
```
|
||||
|
||||
CI and `npm run check` use `npm run adobe:beta-c2pa-drift:check` to reject a
|
||||
stale receipt. Promotion beyond static accounting requires a public stable
|
||||
release and documentation, an explicit capability design with bounded manifest
|
||||
data, and controlled licensed-host verification.
|
||||
Executable
+12
@@ -0,0 +1,12 @@
|
||||
# Adobe beta Color declaration drift
|
||||
|
||||
`src/resources/adobe-beta-color-drift.json` records the pinned stable
|
||||
`@adobe/premierepro@26.3.0` to beta `@adobe/premierepro@26.5.0-beta.73`
|
||||
`Color` factory migration. Beta moves matching call and construct signatures to
|
||||
`ColorStatic` while retaining `Color` instance members.
|
||||
|
||||
This is static declaration accounting only. It does not construct `Color`,
|
||||
change the existing stable Color workflow, use Color with another API, prove
|
||||
host availability, or establish licensed-host validation. Run
|
||||
`npm run adobe:beta-color-drift` after intentional package updates; CI uses
|
||||
`npm run adobe:beta-color-drift:check`.
|
||||
Executable
+14
@@ -0,0 +1,14 @@
|
||||
# Adobe beta FrameRate declaration drift
|
||||
|
||||
`src/resources/adobe-beta-frame-rate-drift.json` records the pinned stable
|
||||
`@adobe/premierepro@26.3.0` to beta `@adobe/premierepro@26.5.0-beta.73`
|
||||
`FrameRate` factory-placement migration. Both packages bind
|
||||
`premierepro.FrameRate` to `FrameRateStatic`, but beta moves matching call and
|
||||
construct signatures from `FrameRate` to `FrameRateStatic` while retaining
|
||||
`FrameRate` instance members and `FrameRateStatic.createWithValue()`.
|
||||
|
||||
This is static declaration accounting only. It does not construct a
|
||||
`FrameRate`, change existing frame-alignment or TickTime workflows, use a
|
||||
frame rate with another API, prove host availability, or establish
|
||||
licensed-host validation. Run `npm run adobe:beta-frame-rate-drift` after
|
||||
intentional package updates; CI uses `npm run adobe:beta-frame-rate-drift:check`.
|
||||
Executable
+13
@@ -0,0 +1,13 @@
|
||||
# Adobe beta Guid declaration drift
|
||||
|
||||
`src/resources/adobe-beta-guid-drift.json` records the pinned stable
|
||||
`@adobe/premierepro@26.3.0` to beta `@adobe/premierepro@26.5.0-beta.73`
|
||||
`Guid` factory-placement migration. Both packages bind `premierepro.Guid` to
|
||||
`GuidStatic`, but beta moves matching call and construct signatures from `Guid`
|
||||
to `GuidStatic` while retaining `Guid.toString()` and `GuidStatic.fromString()`.
|
||||
|
||||
This is static declaration accounting only. It does not construct or parse a
|
||||
`Guid`, change existing GUID workflows, use a GUID with another API, prove
|
||||
host availability, or establish licensed-host validation. Run
|
||||
`npm run adobe:beta-guid-drift` after intentional package updates; CI uses
|
||||
`npm run adobe:beta-guid-drift:check`.
|
||||
Executable
+27
@@ -0,0 +1,27 @@
|
||||
# Adobe beta Media declaration drift
|
||||
|
||||
`src/resources/adobe-beta-media-drift.json` records a narrow, generated comparison
|
||||
of the `Media` type in this repository's pinned stable
|
||||
`@adobe/premierepro@26.3.0` package and pinned
|
||||
`@adobe/premierepro-beta@26.5.0-beta.73` alias. It stores the package versions,
|
||||
normalized `Media` declaration hashes, public member shapes, and the classified
|
||||
stable-to-beta change set without importing the beta package into production code.
|
||||
|
||||
Run `npm run adobe:beta-media-drift` after intentionally updating either pinned
|
||||
package. `npm run adobe:beta-media-drift:check` is part of `npm run check`, so a
|
||||
stale receipt or an unsupported `Media` declaration shape fails closed.
|
||||
|
||||
For the current pins, the receipt records beta-only `Media.getStart()` and
|
||||
`Media.getDuration()` methods, while the stable `start` and `duration` properties
|
||||
change from synchronous `TickTime` to `Promise<TickTime>` in beta. The stable
|
||||
`Media.createSetStartAction()` signature is unchanged. This is a focused Media
|
||||
audit, not a full stable-to-beta package diff.
|
||||
|
||||
The receipt is declaration accounting only. It does not show that a beta host
|
||||
exposes these members, that a stable host accepts beta calls, or that any MCP
|
||||
action is supported. Production adapters continue to use only stable documented
|
||||
declarations; beta-only methods require a stable release, public documentation,
|
||||
and licensed-host validation before they can be exposed.
|
||||
|
||||
Official package references: [stable 26.3.0](https://www.npmjs.com/package/@adobe/premierepro/v/26.3.0)
|
||||
and [pinned 26.5 beta](https://www.npmjs.com/package/@adobe/premierepro/v/26.5.0-beta.73).
|
||||
Executable
+30
@@ -0,0 +1,30 @@
|
||||
# Adobe beta MediaManager declaration drift
|
||||
|
||||
`src/resources/adobe-beta-media-manager-drift.json` records the narrow media
|
||||
manager declaration surface that is absent from this repository's pinned stable
|
||||
`@adobe/premierepro@26.3.0` package and present in its pinned
|
||||
`@adobe/premierepro@26.5.0-beta.73` alias. The package sources are the
|
||||
[stable npm package](https://www.npmjs.com/package/@adobe/premierepro/v/26.3.0)
|
||||
and the
|
||||
[pinned beta npm package](https://www.npmjs.com/package/@adobe/premierepro/v/26.5.0-beta.73).
|
||||
|
||||
The generated receipt covers only the beta root binding
|
||||
`premierepro.MediaManager`, the empty `MediaManager` instance type, and the
|
||||
declared `MediaManagerStatic.purgeMediaCache` method. It has no MCP action and
|
||||
makes no production call to this beta surface.
|
||||
|
||||
`purgeMediaCache` is a cache-mutating operation. A declaration does not prove
|
||||
what data a host clears, whether clearing succeeds, how long it takes, or how a
|
||||
host reports failure. The receipt therefore does not expose cache purging or
|
||||
claim beta/stable compatibility, host availability, or cache behavior.
|
||||
|
||||
Generate the receipt after intentionally changing either pinned package:
|
||||
|
||||
```sh
|
||||
npm run adobe:beta-media-manager-drift
|
||||
```
|
||||
|
||||
CI and `npm run check` use `npm run adobe:beta-media-manager-drift:check` to
|
||||
reject a stale receipt. Promotion beyond static accounting requires a public
|
||||
stable release and documentation, an explicit destructive-operation design,
|
||||
and controlled licensed-host verification.
|
||||
Executable
+12
@@ -0,0 +1,12 @@
|
||||
# Adobe beta PointF declaration drift
|
||||
|
||||
`src/resources/adobe-beta-pointf-drift.json` records the pinned stable
|
||||
`@adobe/premierepro@26.3.0` to beta `@adobe/premierepro@26.5.0-beta.73`
|
||||
`PointF` factory migration. Beta moves matching call and construct signatures to
|
||||
`PointFStatic` while retaining `PointF` instance members.
|
||||
|
||||
This is static declaration accounting only. It does not construct `PointF`,
|
||||
change the existing stable PointF workflow, use PointF with another API, prove
|
||||
host availability, or establish licensed-host validation. Run
|
||||
`npm run adobe:beta-pointf-drift` after intentional package updates; CI uses
|
||||
`npm run adobe:beta-pointf-drift:check`.
|
||||
+30
@@ -0,0 +1,30 @@
|
||||
# Adobe beta project-options declaration drift
|
||||
|
||||
`src/resources/adobe-beta-project-options-drift.json` records the narrow
|
||||
factory-type migration for `OpenProjectOptions` and `CloseProjectOptions`
|
||||
between this repository's pinned stable `@adobe/premierepro@26.3.0` package and
|
||||
its pinned `@adobe/premierepro@26.5.0-beta.73` alias.
|
||||
|
||||
Stable declarations bind each `premierepro` member to its instance type, which
|
||||
owns call and construct signatures. Beta declarations bind each member to a new
|
||||
`*Static` type with the same factory signatures; the option members otherwise
|
||||
match. The receipt records the new types, static members, root-binding changes,
|
||||
and factory ownership changes.
|
||||
|
||||
It does not construct either options type or expose project-open/project-close
|
||||
behavior. In particular, it does not control open/close dialogs, dirty-project
|
||||
prompts, workspace saving, quit preparation, or any project lifecycle action.
|
||||
Static declarations do not prove beta-host availability, stable-host
|
||||
compatibility, project state, or licensed-host validation.
|
||||
|
||||
Generate the receipt after intentionally changing either pinned package:
|
||||
|
||||
```sh
|
||||
npm run adobe:beta-project-options-drift
|
||||
```
|
||||
|
||||
CI and `npm run check` use
|
||||
`npm run adobe:beta-project-options-drift:check` to reject a stale receipt.
|
||||
Promotion beyond static accounting requires public stable documentation, an
|
||||
explicitly bounded lifecycle capability design, and controlled licensed-host
|
||||
verification.
|
||||
Executable
+11
@@ -0,0 +1,11 @@
|
||||
# Adobe beta RectF declaration drift
|
||||
|
||||
`src/resources/adobe-beta-rectf-drift.json` records the pinned stable
|
||||
`@adobe/premierepro@26.3.0` to beta `@adobe/premierepro@26.5.0-beta.73`
|
||||
`RectF` factory migration. Beta moves matching call and construct signatures to
|
||||
`RectFStatic` while retaining `width` and `height` on `RectF`.
|
||||
|
||||
This is static declaration accounting only. It does not construct `RectF`, use
|
||||
it with another API, prove host availability, or establish licensed-host
|
||||
validation. Run `npm run adobe:beta-rectf-drift` after intentional package
|
||||
updates; CI uses `npm run adobe:beta-rectf-drift:check`.
|
||||
Executable
+15
@@ -0,0 +1,15 @@
|
||||
# Adobe beta TickTime declaration drift
|
||||
|
||||
`src/resources/adobe-beta-tick-time-drift.json` records the pinned stable
|
||||
`@adobe/premierepro@26.3.0` to beta `@adobe/premierepro@26.5.0-beta.73`
|
||||
`TickTime` factory-placement migration. Both packages bind
|
||||
`premierepro.TickTime` to `TickTimeStatic`, but beta moves matching call and
|
||||
construct signatures from `TickTime` to `TickTimeStatic` while retaining
|
||||
`TickTime` instance members and existing `TickTimeStatic` helpers.
|
||||
|
||||
This is static declaration accounting only. It does not construct a
|
||||
`TickTime`, change existing TickTime arithmetic or frame-alignment workflows,
|
||||
use a time value with another API, prove host availability, or establish
|
||||
licensed-host validation. Run `npm run adobe:beta-tick-time-drift` after
|
||||
intentional package updates; CI uses
|
||||
`npm run adobe:beta-tick-time-drift:check`.
|
||||
Executable
+30
@@ -0,0 +1,30 @@
|
||||
# Adobe beta TranscriptStatic declaration drift
|
||||
|
||||
`src/resources/adobe-beta-transcript-drift.json` records the narrow delta in
|
||||
the `TranscriptStatic` declaration between this repository's pinned stable
|
||||
`@adobe/premierepro@26.3.0` package and its pinned
|
||||
`@adobe/premierepro@26.5.0-beta.73` alias. The package sources are the
|
||||
[stable npm package](https://www.npmjs.com/package/@adobe/premierepro/v/26.3.0)
|
||||
and the
|
||||
[pinned beta npm package](https://www.npmjs.com/package/@adobe/premierepro/v/26.5.0-beta.73).
|
||||
|
||||
The generated receipt records the beta-added language-pack probe and
|
||||
transcription-start declaration. It does not add an MCP action or make a
|
||||
production beta call. Existing stable transcript import/export support remains
|
||||
separate and unchanged.
|
||||
|
||||
In particular, a declaration does not prove a language pack is installed or
|
||||
usable, that transcription can start or finish, or that transcript content can
|
||||
be safely retained or exposed. `transcribeClipProjectItem` is treated as a
|
||||
mutation-sensitive operation and is deliberately excluded from production
|
||||
support pending a public stable release, compatible documentation, a bounded
|
||||
privacy-safe design, and controlled licensed-host verification.
|
||||
|
||||
Generate the receipt after intentionally changing either pinned package:
|
||||
|
||||
```sh
|
||||
npm run adobe:beta-transcript-drift
|
||||
```
|
||||
|
||||
CI and `npm run check` use `npm run adobe:beta-transcript-drift:check` to
|
||||
reject a stale receipt.
|
||||
+15
@@ -0,0 +1,15 @@
|
||||
# Adobe beta AddTransitionOptions declaration drift
|
||||
|
||||
`src/resources/adobe-beta-transition-options-drift.json` records the beta
|
||||
factory-type migration for `AddTransitionOptions` against pinned stable
|
||||
`@adobe/premierepro@26.3.0` and beta `@adobe/premierepro@26.5.0-beta.73`.
|
||||
Beta moves matching call and construct signatures from the instance declaration
|
||||
to new `AddTransitionOptionsStatic`; all non-factory option members match.
|
||||
|
||||
This is static accounting only. It does not construct options, create a
|
||||
transition action, apply a transition, validate duration or alignment, prove
|
||||
host availability, or provide licensed-host validation.
|
||||
|
||||
Run `npm run adobe:beta-transition-options-drift` after intentional pinned
|
||||
package changes; `npm run adobe:beta-transition-options-drift:check` verifies
|
||||
the committed receipt.
|
||||
Executable
+31
@@ -0,0 +1,31 @@
|
||||
# Adobe beta WorkAreaUtils declaration drift
|
||||
|
||||
`src/resources/adobe-beta-work-area-drift.json` records the narrow work-area
|
||||
declaration surface that is absent from this repository's pinned stable
|
||||
`@adobe/premierepro@26.3.0` package and present in its pinned
|
||||
`@adobe/premierepro@26.5.0-beta.73` alias. The package sources are the
|
||||
[stable npm package](https://www.npmjs.com/package/@adobe/premierepro/v/26.3.0)
|
||||
and the
|
||||
[pinned beta npm package](https://www.npmjs.com/package/@adobe/premierepro/v/26.5.0-beta.73).
|
||||
|
||||
The generated receipt covers only the beta root binding
|
||||
`premierepro.WorkAreaUtils`, the empty `WorkAreaUtils` instance type, and the
|
||||
five methods of `WorkAreaUtilsStatic`. It has no MCP action and makes no
|
||||
production call to that beta surface.
|
||||
|
||||
The repository's existing `get_work_area` and `set_work_area` tools use
|
||||
established legacy host paths. This receipt does not change those paths or
|
||||
claim that they are behaviorally equivalent to beta `WorkAreaUtils` methods.
|
||||
In particular, declarations alone do not prove sequence selection, mutation
|
||||
success, range validation, or live-host readback.
|
||||
|
||||
Generate the receipt after intentionally changing either pinned package:
|
||||
|
||||
```sh
|
||||
npm run adobe:beta-work-area-drift
|
||||
```
|
||||
|
||||
CI and `npm run check` use `npm run adobe:beta-work-area-drift:check` to reject
|
||||
a stale receipt. Promotion beyond static accounting requires a public stable
|
||||
release and documentation, a compatible action design, and controlled
|
||||
licensed-host verification.
|
||||
+45
@@ -0,0 +1,45 @@
|
||||
# Adobe Marketplace release checklist
|
||||
|
||||
This is a maintainer checklist, not evidence of Adobe approval, certification, or
|
||||
publication. Direct CCX distribution and Adobe Marketplace distribution are separate
|
||||
channels and must use the channel-specific package validation path. The current
|
||||
Marketplace display name for this release path is **MCP for Adobe Premiere Pro**;
|
||||
keep it identical in the portal, CEP bundle/menu, UXP manifest/panel, screenshots,
|
||||
and customer-facing listing copy.
|
||||
|
||||
## Repository evidence required before submission
|
||||
|
||||
- [ ] The candidate commit has green cross-platform CI, dependency audit, release
|
||||
package validation, and the landing performance budget.
|
||||
- [ ] `npm run validate:marketplace-branding` passed at the exact candidate commit.
|
||||
- [ ] The signed direct artifact and the Marketplace-targeted CCX are built from the
|
||||
exact release commit, with artifact hashes recorded in the release notes.
|
||||
- [ ] The published compatibility page distinguishes package support, connected
|
||||
capabilities, and licensed-host-verified workflows.
|
||||
- [ ] Every workflow described as host-verified has a redacted report accepted by
|
||||
`npm run validate:host-report -- path/to/report.json` and reviewed by a human.
|
||||
- [ ] Privacy policy, support contact, terms, security policy, release notes, and
|
||||
product screenshots are current and match the submitted package.
|
||||
- [ ] The listing does not claim Adobe affiliation, approval, universal host support,
|
||||
or a result beyond the available evidence.
|
||||
|
||||
## Owner-controlled Adobe steps
|
||||
|
||||
- [ ] Verify the actual listing status in the Adobe Developer Distribution portal.
|
||||
- [ ] Resolve every current reviewer finding in the portal. Do not treat a package
|
||||
build, a prior review, or a stale overview badge as a resubmission or approval.
|
||||
- [ ] Confirm the portal display name is exactly **MCP for Adobe Premiere Pro** and
|
||||
update any screenshots or listing fields that show an older panel name.
|
||||
- [ ] Enter the portal-issued Marketplace plugin ID only in the protected workflow
|
||||
dispatch input; never commit it as a production claim or imply publication from a
|
||||
successful package build.
|
||||
- [ ] Upload the channel-specific CCX, screenshots, support details, reviewer notes,
|
||||
and test credentials when required by the portal.
|
||||
- [ ] Record Adobe's review result and public listing URL before changing any public
|
||||
copy to say the Marketplace listing is available.
|
||||
|
||||
## Release decision
|
||||
|
||||
An approved Marketplace listing is an external distribution fact. It does not prove a
|
||||
real Premiere edit, and a real-host report does not prove Marketplace approval. Keep
|
||||
both dimensions in the release evidence separately.
|
||||
Executable
+50
@@ -0,0 +1,50 @@
|
||||
# Adobe Marketplace resubmission runbook
|
||||
|
||||
This runbook prepares a candidate for owner-operated Adobe Marketplace work. It does
|
||||
not submit, approve, publish, or certify a listing.
|
||||
|
||||
## Naming boundary
|
||||
|
||||
Use **MCP for Adobe Premiere Pro** as the Marketplace display name. It describes
|
||||
compatibility rather than presenting an Adobe product name as the product brand. The
|
||||
same display name must appear in the Marketplace portal, CEP bundle and panel, UXP
|
||||
manifest and panel, screenshots, and current customer-facing product copy.
|
||||
|
||||
Repository, package, extension IDs, URLs, and artifact filenames such as
|
||||
`premiere-pro-mcp`, `com.mcp.premiere.bridge`, and `MCPBridgeCEP.zxp` are stable
|
||||
technical identifiers. They are not a reason to show an older display name in a
|
||||
customer-visible Marketplace field or panel.
|
||||
|
||||
## Candidate preparation
|
||||
|
||||
1. Start from the intended release commit and record its full SHA.
|
||||
2. Run `npm run validate:marketplace-branding`, `npm run check`, and the applicable
|
||||
channel package validation/build commands. Retain the command output and artifact
|
||||
hashes with the release evidence.
|
||||
3. Open the CEP panel and, when applicable, the UXP panel from the candidate build.
|
||||
Capture fresh, non-sensitive screenshots showing the exact display name.
|
||||
4. Re-read the current reviewer feedback and listing history in the authenticated
|
||||
Adobe portal. Review history is the source of truth when it conflicts with a
|
||||
summary status badge.
|
||||
5. Update the portal's display name, screenshots, copy, package, and requested
|
||||
metadata to match the candidate. Use the exact portal-required package format.
|
||||
|
||||
## Explicit owner actions
|
||||
|
||||
Only the listing owner may perform these actions in Adobe's portal:
|
||||
|
||||
- upload a new package or version;
|
||||
- change listing fields, screenshots, or reviewer notes;
|
||||
- submit or resubmit for review;
|
||||
- publish a reviewed listing or change its availability.
|
||||
|
||||
Before each action, verify that the portal shows the intended version and display
|
||||
name. After review, record the portal result, reviewer feedback, final listing URL,
|
||||
and timestamp in release evidence. Do not update public copy to say "available on
|
||||
Adobe Marketplace" until the public listing URL is live and independently checked.
|
||||
|
||||
## Non-claims
|
||||
|
||||
A passing branding validator proves only source consistency. It does not prove that
|
||||
Adobe accepted the package, that a listing is public, or that a qualified Premiere
|
||||
host completed a workflow. Keep those three facts as separate release gates.
|
||||
Executable
+412
@@ -0,0 +1,412 @@
|
||||
# Adobe Premiere UXP 26.3 coverage
|
||||
|
||||
This page records the Adobe 26.3 UXP surface targeted by this branch. It is a
|
||||
capability plan and public-contract reference, not a claim that every supported
|
||||
Premiere build has been exercised. The package must interrogate the connected
|
||||
panel through `capabilities.get`; package version, static TypeScript declarations,
|
||||
and unit tests are insufficient evidence that a particular host supports a command.
|
||||
|
||||
The later stable-API expansion is documented separately in the
|
||||
[stable UXP workflow matrix](uxp-stable-workflows.md). Its coverage entries
|
||||
share this pinned 26.3 declaration baseline and the same pending live-host gate.
|
||||
|
||||
## Source and version policy
|
||||
|
||||
Adobe's [26.3 changelog](https://developer.adobe.com/premiere-pro/uxp/changelog/)
|
||||
is the primary release baseline. It introduced the APIs below and tightened the
|
||||
rule that `create*Action()` calls occur inside `project.lockedAccess()` before the
|
||||
action is consumed by `project.executeTransaction()`.
|
||||
|
||||
Use the stable [`@adobe/premierepro` 26.3.0 package](https://www.npmjs.com/package/@adobe/premierepro)
|
||||
for declarations. It contains types only; Premiere supplies the runtime module as
|
||||
`require("premierepro")`. Adobe's npm `beta` channel is a preview of later work
|
||||
(currently 26.5) and is not a supported runtime target for this MCP release. A
|
||||
beta declaration or a beta sample may guide research, but it must not add a tool,
|
||||
minimum-version claim, or production capability until Adobe ships the API in a
|
||||
stable host and the live-host gate below passes.
|
||||
|
||||
Adobe's [TypeScript guidance](https://developer.adobe.com/premiere-pro/uxp/resources/fundamentals/typescript-support/)
|
||||
and [ESLint guidance](https://developer.adobe.com/premiere-pro/uxp/resources/fundamentals/eslint-support/)
|
||||
are part of the implementation baseline. In particular, the lint rules flag action
|
||||
creation outside locks, asynchronous lock/transaction callbacks, and actions that
|
||||
escape their lock scope.
|
||||
|
||||
## Command coverage
|
||||
|
||||
All entries in this table target Premiere 26.3+ and require a connected authenticated
|
||||
local panel. `Supported` means the command has a documented API and an MCP contract;
|
||||
the runtime probe can still return `supported: false` for an individual host. The
|
||||
verification column describes the required evidence, not a completed test run.
|
||||
|
||||
| MCP tool | UXP protocol command | Adobe API | Operation | Capability state | Verification evidence |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| `rename_track_uxp` | `track.rename` | `AudioTrack`, `VideoTrack`, and `CaptionTrack` `createSetNameAction()` | Undoable project mutation | Supported when the selected track type and action APIs probe true | Read back the target track's name after the committed transaction; live host must also validate Undo. |
|
||||
| `create_subclip_uxp` | `subclip.create` | `ClipProjectItem.createSubClipAction()` | Undoable project mutation | Supported when the resolved item is a clip and action APIs probe true | Return and re-resolve the created subclip identity; live host must validate hard boundaries and audio/video options. |
|
||||
| `list_markers_uxp` | `marker.list` | `Marker.guid`, `getColor()`, `getUrl()`, `getTarget()`, plus marker accessors | Read-only | Supported when sequence or clip marker APIs probe true | Return marker values and the stable 26.3 `guid`; optional web-link URL/target and raw RGBA component fields require explicit caller opt-in and do not mutate Premiere. |
|
||||
| `inspect_premiere_events_uxp` | `events.list`, `events.wait` | `EventManager`, six root `SnapEvent.EVENT_SNAP_*` constants, and root `OperationCompleteEvent.EVENT_CLIP_EXTEND_REACHED` / `EVENT_EFFECT_DRAG_OVER` | Read-only bounded event receipt monitoring | Base event journaling remains capability-gated; each optional root constant must probe as a non-empty event name | Register only available documented constants as passive `timeline.snap.*`, `operation.clip.extend.reached`, and coalesced `operation.effect.drag.over` receipts. Return the ordinary 256-entry/60-second bounded journal with allowlisted scalar detail only; no raw host event payload, guaranteed emission, project-state invalidation, terminal completion, downstream edit completion, or licensed-host proof is claimed. |
|
||||
| `set_source_monitor_position_uxp` | `sourceMonitor.position.set` | `SourceMonitor.setPosition()` | Source Monitor state mutation; no edit-history claim | Supported when `setPosition` and position read-back APIs probe true | Read `SourceMonitor.getPosition()` after setting the requested `TickTime`. |
|
||||
| `manage_sequence_range_uxp` | `sequence.range.inspect`, `sequence.range.update` | `Sequence` range accessors plus `createSetInPointAction()`, `createSetOutPointAction()`, and `createSetZeroPointAction()` | Undoable sequence-range mutation | Supported when every accessor, action, `TickTime`, and transaction primitive probes true | Read the complete range after one transaction and require it to match the guarded request; live host must also validate Undo. |
|
||||
| `manage_sequence_playhead_uxp` | `sequence.playhead.inspect`, `sequence.playhead.set` | `Sequence.getPlayerPosition()` and `Sequence.setPlayerPosition()` | Sequence player-state mutation; no project-save or Undo claim | Supported when the active sequence, `TickTime`, getter, and setter probe true | Require the inspected sequence GUID and exact current position, serialize competing setters, then read the player position back. |
|
||||
| `manage_app_preferences_uxp` | `preferences.inspect`, `preferences.set` | `AppPreference.getValue()`, `setValue()`, the three documented preference keys, and persistence constants | Direct application-state update; no project-save, transaction, or Undo claim | Supported when all three named keys, both property-type constants, and the exact getter/setter probe true | Return three bounded native strings. A write accepts only one allow-listed key and string value, requires the exact inspected value, explicit persistence and confirmation, serializes competing writes to that key, and verifies exact native-string readback. This is not a licensed-host proof. |
|
||||
| `inspect_installed_mogrt_directory_uxp` | `graphics.mogrtPath.inspect` | `SequenceEditor.getInstalledMogrtPath()` | Read-only installed-MOGRT directory availability readback | Supported when the static documented getter probes true | Validate only one bounded native string. The path remains redacted unless `include_path: true`; the bridge does not enumerate or read the directory, import MOGRTs, prove template compatibility, or validate a licensed host. |
|
||||
| `inspect_sequence_timing_uxp` | `sequence.timing.inspect` | `Sequence.getFrameSize()`, `getTimebase()`, audio/video time-display getters, and `getProjectItem()` | Read-only active-sequence timing and ownership snapshot | Supported when the active sequence exposes each listed getter; invocation then requires the returned ProjectItem to expose a valid ID | Return bounded native values and reject a different active sequence at read completion. This is not a locked atomic snapshot, does not detect a transient switch back to the same sequence, and is not licensed-host proof. |
|
||||
| `inspect_frame_alignment_uxp` | `time.frameAlignment.inspect` | `FrameRate.createWithValue()`, `TickTime.createWithSeconds()`, `createWithFrameAndFrameRate()`, `alignToFrame()`, and `alignToNearestFrame()` | Read-only native frame-boundary conversion for caller-owned values | Supported when the documented native FrameRate and TickTime factories plus both alignment methods probe true | Accept one bounded rate plus either seconds or a frame count, and return native seconds/tick-string values. It never infers a sequence rate, changes Premiere, or proves timeline placement, playback, persistence, or licensed-host behavior. |
|
||||
| `inspect_sequence_timing_by_guid_uxp` | `sequence.timingByGuid.inspect` | `Project.getSequence()`, `Guid.fromString()`, and the bounded sequence-timing accessors | Read-only exact known-sequence timing and ownership snapshot | Supported when Project GUID lookup parses and resolves; the requested target's timing accessors are probed at invocation | Require one exact known sequence GUID, including a non-active target without activating it, and reject a changed project, missing target, GUID mismatch, or any difference across two complete timing snapshots. This is not an atomic host snapshot or licensed-host proof. |
|
||||
| `calculate_tick_time_uxp` | `time.tickArithmetic.inspect` | `TickTime.createWithTicks()`, `add()`, `subtract()`, `multiply()`, `divide()`, and tick/second readback | Read-only native tick arithmetic | Supported when the TickTime factory probes true and the selected instance method exists at invocation | Accept only canonical bounded tick strings and non-zero integer multiply/divide factors, then return native ticks and seconds. It accepts no seconds or frame rates, does not align frames or infer timecode, and does not inspect project state, rendering, playback, or a licensed host. |
|
||||
| `manage_sequence_display_format_uxp` | `sequence.displayFormat.inspect`, `sequence.displayFormat.update` | `Sequence.getSettings()`, `createSetSettingsAction()`, and `SequenceSettings` audio/video display-format getters, setters, and constants | One undoable sequence-settings mutation | Supported when the getters, setters, documented constants, and transaction primitives probe true | Require the inspected sequence GUID and complete two-code snapshot, serialize all competing updates for that sequence, commit one native settings action, and read both codes back. Contract coverage is not licensed-host or Undo proof. |
|
||||
| `automate_effect_parameters_uxp` | `parameters.point.inspect`, `parameters.point.set` | `ComponentParam.getStartValue()`, `isTimeVarying()`, `createKeyframe()`, `createSetValueAction()`, `PointF`, and Project transaction primitives | One undoable static PointF parameter mutation | Supported when the active coordinate resolves a parameter exposing the PointF constructor, point start-value readback, and transaction action APIs | Inspect reads the complete PointF x/y snapshot twice and rejects an intervening change. Update requires that exact snapshot, confirmation, and operation ID; it serializes competing updates for that parameter, creates one action in one transaction, and reads x/y back. Keyframed PointF edits, rendered output, playback, persistence, Undo, and licensed-host behavior are not proven. |
|
||||
| `automate_effect_parameters_uxp` | `parameters.point.displacement.inspect` | `ComponentParam.getValueAtTime()`, `TickTime.createWithSeconds()`, and `PointF.distanceTo()` | Read-only animated PointF endpoint displacement | Supported when the active coordinate resolves a time-varying PointF parameter whose two native samples expose `distanceTo()` | Require an exact coordinate and a strictly increasing, bounded two-time interval. Read the complete project/sequence/component/parameter identity, animation state, both native points, and native straight-line distance twice; reject any drift. It is an endpoint displacement, not total path length, a keyframe edit, rendered motion, playback, persistence, Undo, or licensed-host proof. |
|
||||
| `automate_effect_parameters_uxp` | `parameters.color.inspect`, `parameters.color.set` | `ComponentParam.getStartValue()`, `isTimeVarying()`, `createKeyframe()`, `createSetValueAction()`, `Color`, and Project transaction primitives | One undoable static Color parameter mutation | Supported when the active coordinate resolves a parameter exposing the Color constructor, color start-value readback, and transaction action APIs | Inspect reads the complete raw RGBA snapshot twice and rejects an intervening change. Update requires that exact snapshot, confirmation, and operation ID; it serializes competing updates for that parameter, creates one action in one transaction, and reads RGBA back. Keyframed Color edits, color management, rendered appearance, playback, persistence, Undo, and licensed-host behavior are not proven. |
|
||||
| `inspect_effect_parameter_catalog_uxp` | `parameters.catalog.inspect` | Audio/video component-chain accessors, `Component.getParamCount()`/`getParam()`, and `ComponentParam` descriptor accessors | Read-only bounded component-parameter discovery | Supported when the active coordinate exposes a documented component chain, identity getters, and every parameter descriptor accessor | Return at most 64 parameter indices, display names, and keyframe capability/state entries; never read raw parameter values. Read the complete target twice and reject changed project, active-sequence, component-identity, or descriptor data. This does not prove parameter values, editability, rendering, playback, persistence, Undo, or licensed-host behavior. |
|
||||
| `inspect_source_media_provenance_uxp` | `source.provenance.inspect` | `Project.getRootItem()`, `FolderItem.getItems()`, and `ClipProjectItem.getMediaFilePath()` / `getOriginatingProjectPath()` | Read-only, opt-in source-path provenance inspection | Supported when the documented Project, FolderItem, and ClipProjectItem casts probe true | Require one exact Project-item ID and at least one explicit path-disclosure flag. Resolve only that item twice through a 4096-item bounded tree and reject a changed project, target, or selected path. It does not return a tree, access the filesystem, validate a path, establish origin or rights, or prove a licensed host. |
|
||||
| `inspect_source_proxy_uxp` | `source.proxy.inspect` | `Project.getRootItem()`, `FolderItem.getItems()`, and `ClipProjectItem.canChangeMediaPath()` / `isOffline()` / `canProxy()` / `hasProxy()` / `getProxyPath()` | Read-only, bounded source-proxy readiness inspection | Supported when the documented Project, FolderItem, and ClipProjectItem casts plus all listed proxy getters probe true | Require one exact Project-item ID. Resolve only that item twice through a 4096-item bounded tree and reject a changed project, target, or selected state. The proxy path getter runs only after explicit opt-in and only for an attached proxy; it does not access the filesystem, attach/relink media, prove proxy compatibility, playback, persistence, or a licensed host. |
|
||||
| `manage_source_media_timing_uxp` | `source.mediaTiming.inspect`, `source.mediaTiming.setStart` | `ClipProjectItem.getMedia()`, stable `Media.start`/`duration`, `Media.createSetStartAction()`, `TickTime`, and Project transaction primitives | One undoable source-media start-time mutation | Supported when the resolved clip's media surface, TickTime factory, and transaction primitives probe true | Require the exact project-item ID and a complete start/duration snapshot, serialize competing updates for that clip, reject a changed synchronous timing snapshot under the action lock, then read back the requested start and unchanged duration. Contract coverage is not licensed-host, timecode-display, persistence, or Undo proof. |
|
||||
| `manage_source_media_overrides_uxp` | `source.mediaOverrides.inspect`, `source.mediaOverrides.update` | `ClipProjectItem.getFootageInterpretation()`, `FootageInterpretation.getFrameRate()`, `getPixelAspectRatio()`, `createSetOverrideFrameRateAction()`, `createSetOverridePixelAspectRatioAction()`, and Project transaction primitives | One undoable explicit source-media interpretation-override mutation | Supported when the resolved clip, effective interpretation getters, dedicated override actions, and transaction primitives probe true | Require the exact project/item/effective-value snapshot, confirmation, and operation ID; serialize this protocol's competing source-media timing/override updates per item; construct requested actions under one lock and commit one transaction, then read both effective values back. Adobe exposes no explicit-override-presence or clear getter, so matching effective values do not prove persistence or distinguish an override from file-native interpretation. Contract coverage is not licensed-host or Undo proof. |
|
||||
| `inspect_track_item_identity_uxp` | `trackItem.identity.inspect` | Audio/video `TrackItem.getMatchName()`, `getType()`, `getMediaType()`, `getTrackIndex()`, and `getIsSelected()` | Read-only single-track-item identity snapshot | Supported when the active sequence, requested track item, and every documented identity getter probe true | Require one bounded audio/video coordinate, optionally reject a stale expected sequence GUID, and re-read the active sequence identity before returning. It returns no paths, effect parameters, rendered output, or visual proof; a switch away and back to the same sequence during the call is not detected, and contract coverage is not licensed-host proof. |
|
||||
| `slip_track_item_uxp` | `trackItem.slip.inspect`, `trackItem.slip` | Audio/video `TrackItem` timing getters, `createSetInPointAction()`, `createSetOutPointAction()`, and Project transaction primitives | One undoable source-only slip | Supported when the active sequence exposes the bounded requested clip and all required timing/action APIs | Require a complete reviewed snapshot, explicit confirmation, and operation ID; serialize competing slips per item, create exactly two source-point actions in one transaction, then verify unchanged timeline timing plus the exact shifted source range. It supports only forward 1x items and does not prove media-handle availability, rendered frames, linked-item sync, persistence, Undo, or licensed-host behavior. |
|
||||
| `slide_track_item_uxp` | `trackItem.slide.inspect`, `trackItem.slide` | Audio/video `TrackItem` timing getters; `createMoveAction()`, timeline/source trim actions; and Project transaction primitives | One undoable contiguous three-item slide | Supported when the bounded requested center item has immediate contiguous same-track clip neighbours and every required action API probes true | Require a complete three-item snapshot, confirmation, and operation ID; serialize slides and slips on the track, create five actions in one transaction, then verify every source/timeline boundary and both retained cuts. Only forward 1x items with matching source/timeline durations are supported; media handles, linked A/V, rendering, playback, persistence, Undo, and licensed-host behavior remain unproven. |
|
||||
| `duplicate_track_item_uxp` | `trackItem.clone.inspect`, `trackItem.clone` | Audio/video `TrackItem` timing/source getters, `SequenceEditor.getEditor()`, `createCloneTrackItemAction()`, `TickTime`, and Project transaction primitives | One undoable append-only same-track duplicate | Supported when the requested final clip item, documented clone action, and transaction primitives probe true | Require a complete final-item snapshot, confirmation, and operation ID; serialize with slips/slides on that track, make exactly one clone action/transaction, then read back only the source and deterministic appended coordinate. It does not clone into occupied ranges or another track, and does not prove media handles, linked A/V, rendering, playback, persistence, Undo, or licensed-host behavior. |
|
||||
| `ripple_delete_track_item_uxp` | `trackItem.rippleDelete.inspect`, `trackItem.rippleDelete` | Audio/video `TrackItem` timing/source getters, `TrackItemSelection`, `Constants.MediaType`, `SequenceEditor.getEditor()`, `createRemoveItemsAction()`, and Project transaction primitives | One undoable contiguous same-track ripple delete | Supported when the requested item has an immediate contiguous same-track successor and the documented selection, remove-action, and transaction primitives probe true | Require complete target/successor snapshots, confirmation, and an operation ID; serialize with slips/slides/duplicates on that track, make one single-item ripple action and transaction, then read only the successor at the removed coordinate. Final items, gaps, other tracks, linked A/V, media handles, rendering, playback, persistence, Undo, and licensed-host behavior remain outside this proof. |
|
||||
| `manage_timeline_source_label_uxp` | `timeline.sourceLabel.inspect`, `timeline.sourceLabel.update` | Audio/video track item `getProjectItem()`, `ClipProjectItem.cast()`, source `getColorLabelIndex()`/`createSetColorLabelAction()`, and Project transaction primitives | One undoable source Project-item color-label mutation resolved from an active timeline coordinate | Supported when the active coordinate resolves a clip source with the documented color-label action | Require the complete coordinate/source-label snapshot, confirmation, and operation ID; serialize all bridge color-label mutations for that source item, re-resolve before action construction, commit one transaction, and read the coordinate/source label back. A source label is project-global, not a timeline-only instance label; rendered appearance, playback, persistence, Undo, and licensed-host behavior are not proven. |
|
||||
| `manage_sequence_preview_frame_uxp` | `sequence.previewFrame.inspect`, `sequence.previewFrame.update` | `Project.getSequences()`, `Sequence.getSettings()`, `SequenceSettings.getPreviewFrameRect()`/`setPreviewFrameRect()`, `RectF`, `Sequence.createSetSettingsAction()`, and Project transaction primitives | One undoable preview-frame rectangle mutation for one exact sequence GUID | Supported when the resolved target exposes the documented preview-frame accessors, RectF constructor, settings action, and transaction primitives | Inspect double-reads a bounded native width/height snapshot. Update requires the complete snapshot, confirmation, and operation ID; it serializes bridge updates by reviewed project/sequence, revalidates before one settings transaction, then reads that exact sequence back. UXP exposes no compare-and-swap or UI/cross-extension lock; video frame dimensions, rendering, playback, persistence, Undo, and licensed-host behavior are not proven. |
|
||||
| `create_empty_sequence_uxp` | `sequences.createEmpty` | `Project.createSequence()`, `Project.getSequences()`, and sequence identity accessors | Direct project mutation; no Undo or transaction claim | Supported when the active project exposes documented empty-sequence creation | Require explicit confirmation and an operation ID, serialize the complete project-sequence capacity snapshot through creation and post-call collection readback, and verify the returned identity. Contract coverage is not licensed-host proof. |
|
||||
| `inspect_project_tree_uxp` | `projectTree.inspect` | `Project.getRootItem()`, `FolderItem.getItems()`, and project-item identity accessors | Read-only bounded Project-panel tree snapshot | Supported when the active project exposes a readable root folder and runtime folder casts | Return only stable IDs, names, types, parent IDs, bin state, and optional color-label indexes, capped at 512 items and depth 16. It omits media paths, metadata, and content; depth or item truncation is explicit, and this is not licensed-host proof. |
|
||||
| `inspect_project_panel_metadata_uxp` | `metadata.columns.get`, `metadata.projectPanel.get` | `Metadata.getProjectColumnsMetadata()` and `Metadata.getProjectPanelMetadata()` | Read-only bounded Project-panel metadata snapshot | Supported when the exact documented accessor probes true; item columns additionally resolve one media item | Return one native metadata string capped at 350,000 characters and 900,000 serialized UTF-8 bytes. This read-only tool intentionally offers no schema creation or write route; it is not an atomic project snapshot or licensed-host proof. |
|
||||
| `manage_project_panel_metadata_uxp` | `metadata.projectPanel.get`, `metadata.projectPanel.update` | `Metadata.getProjectPanelMetadata()`, `Metadata.setProjectPanelMetadata()`, `Project.guid`, and `Project.lockedAccess()` | Direct non-undoable active-project panel-metadata replacement | Supported when the exact getter, setter, active-project GUID, and lock probe true | Require exact inspected project GUID and XML, `confirm_update: true`, and an operation ID. Cap each XML string at 12 KiB UTF-8, serialize this bridge's competing updates per project, re-snapshot immediately before starting the setter, then require exact active-project XML readback. Adobe exposes no atomic compare-and-set, so user-interface/extension races, persistence, UI results, Undo, cancellation, and licensed-host behavior are not claimed. |
|
||||
| `create_project_metadata_field_uxp` | `metadata.projectSchema.inspect`, `metadata.projectSchema.create` | `Metadata.getProjectPanelMetadata()`, `addPropertyToProjectMetadataSchema()`, four documented metadata-type constants, `Project.guid`, and `Project.lockedAccess()` | Direct non-undoable Project metadata-schema field creation | Supported when the exact panel getter, schema creator, type constants, active-project GUID, and lock probe true | Require exact inspected project GUID and 12 KiB UTF-8-bounded panel XML, a bounded typed name/label, `confirm_create: true`, and an operation ID. Serialize this bridge's schema/create and panel-replacement requests per project, then re-snapshot before invoking the direct API. Adobe provides neither atomic compare-and-set nor a field-level schema getter: host acceptance and changed panel XML are evidence only, so success is always `committed_unverified`; persistence, UI results, Undo, cancellation, and licensed-host behavior are not claimed. |
|
||||
| `has_transcript_uxp` | `transcript.has` | `Transcript.hasTranscript()` | Read-only | Native 26.3 support is used when it probes true; the existing 25.6 transcript-export compatibility probe is labeled as a fallback | Return Adobe's native boolean when available; never infer transcript presence from names or transcript text. |
|
||||
| `import_transcript_uxp` | `transcript.import` | `Transcript.hasTranscript()`, `exportToJSON()`, `importFromJSON()`, and `createImportTextSegmentsAction()` with Project transaction primitives | One undoable source-transcript replacement | Supported when the exact transcript, project-root traversal, clip-cast, and transaction APIs probe true | Require an exact project GUID, project-item ID, and current transcript SHA-256 (or `null` for an untranscribed clip), explicit confirmation, and an operation ID. Serialize competing imports for that clip; cap input at 24 KiB and snapshots at 1 MiB; re-snapshot before action creation; then require exact export-SHA readback. A committed readback failure is `committed_unverified`, not proof of the imported text, Undo, persistence, or licensed-host behavior. |
|
||||
| `export_aaf_uxp` | `interchange.aaf.export` | `ProjectConverter.exportAAF()` and `AAFExportOptions` | Export side effect; no project undo claim | Supported when converter and option APIs probe true | Record Premiere's boolean result and, in a live host, confirm the intended AAF artifact exists and is usable. |
|
||||
| `audit_object_masks_uxp` | `objectMask.audit` | `ObjectMaskUtils.hasObjectMask()`, `Project.getSequences()`/`getSequence()`, and sequence GUID/name accessors | Read-only bounded project/sequence Object Mask presence audit | Supported when the documented object-mask and active-project APIs probe true; exact-ID mode additionally requires GUID lookup | Audit at most 64 sequences, read project aggregate and per-sequence booleans twice, and reject any project/sequence/name/boolean drift. This reports presence only—not masks, tracking, rendered pixels, playback, or licensed-host behavior. |
|
||||
| `inspect_unique_object_identity_uxp` | `object.uniqueIdentity.inspect` | `UniqueSerializeable.cast()` and `getUniqueID()`, plus bounded Project item/sequence lookup | Read-only opaque native identity inspection | Supported when the documented active-project and unique-serializable APIs probe true; target resolution is checked at invocation | Require exactly one existing project-item ID or sequence GUID. Resolve and read its opaque native identity twice, rejecting project, locator, or identity drift. It exposes no paths, metadata, content, persistence guarantee, edit authority, rendering, playback, or licensed-host proof. |
|
||||
|
||||
The 26.3 command-registry entries mark their documented status, 26.3 minimum,
|
||||
read-only/destructive/undoable metadata, and an explicit reason if the host does
|
||||
not expose the required API. `transcript.has` is a pre-existing protocol command:
|
||||
its capability record identifies both its 25.6 export-probe compatibility path and
|
||||
whether the 26.3 native check is present. A command failure is never retried
|
||||
automatically through CEP or QE: a failed UXP mutation can already have changed
|
||||
Premiere state. `transcript.import` is intentionally separate from the older 25.6
|
||||
export/search compatibility path because its guarded target identity and native
|
||||
`hasTranscript()` preflight require the stable 26.3 surface.
|
||||
|
||||
## Public argument contract
|
||||
|
||||
The MCP layer uses snake_case arguments and converts them to the protocol's
|
||||
camelCase form. Unknown protocol properties must be rejected. Numeric time inputs
|
||||
are finite, non-negative seconds and are converted to `TickTime` inside the panel.
|
||||
Track indices are zero-based non-negative integers. Mutations accept the existing
|
||||
bounded `operation_id` replay key where applicable.
|
||||
|
||||
- `rename_track_uxp`: `track_type` is `video`, `audio`, or `caption`;
|
||||
`track_index` is zero-based; `name` is non-empty and at most 255 characters.
|
||||
- `create_subclip_uxp`: `name` is non-empty and at most 255 characters;
|
||||
`start_seconds` is finite and non-negative; `end_seconds` is finite and strictly
|
||||
greater than `start_seconds`. Supply at most one `project_item_id` (512
|
||||
characters maximum) or `project_item_name` (255 maximum); omitting both uses
|
||||
exactly one Project-panel selection. `hard_boundaries` defaults to `false`;
|
||||
`take_video` and `take_audio` each default to `true`.
|
||||
- `list_markers_uxp`: `scope` defaults to `sequence` and may be `project_item`.
|
||||
- `inspect_frame_alignment_uxp`: `action` is `align` or `frame`; both require
|
||||
`frame_rate` from 1 through 240. `align` requires `seconds` from 0 through
|
||||
86,400 and rejects `frame_count`; `frame` requires an integer `frame_count`
|
||||
from 0 through 20,736,000 and rejects `seconds`. Both paths return only
|
||||
native TickTime readback for caller-owned inputs.
|
||||
The latter accepts one item selector as above. `filters` is an optional list of
|
||||
at most 16 marker-type strings, each at most 64 characters. Web-link `url` and
|
||||
`target` fields are omitted unless `include_web_links=true`, because a URL can
|
||||
contain sensitive query data. Raw `color` components (`red`, `green`, `blue`,
|
||||
and `alpha`) are omitted unless `include_color_values=true`; they are returned
|
||||
exactly as finite host values, without color-profile conversion or a rendered-
|
||||
appearance claim. When opted in, a host that does not expose an individual
|
||||
documented accessor returns `null` for that field; this is a marker metadata
|
||||
snapshot, not a link reachability, browser-navigation, rendered-appearance, or
|
||||
licensed-host validation claim.
|
||||
- `set_source_monitor_position_uxp`: `seconds` is finite and non-negative.
|
||||
- `manage_sequence_range_uxp`: `inspect` returns the active sequence GUID and its
|
||||
complete in/out/zero-point/end snapshot. `update` requires that GUID and the
|
||||
complete `expected_range` from `inspect`, plus one or more bounded updates.
|
||||
Stale snapshots, unknown fields, and a final range outside `0 <= in <= out <= end`
|
||||
are rejected before any Premiere action is created. Zero point is independently
|
||||
bounded but is not conflated with the sequence in/out export range.
|
||||
- `manage_sequence_playhead_uxp`: `inspect` returns the active sequence GUID and
|
||||
current player position. `set` requires both exact values plus a requested
|
||||
position, each finite and within 0 through 86400 seconds. A changed sequence or
|
||||
position outside a one-microsecond tolerance rejects before the setter is called;
|
||||
accepted requests require boolean host confirmation and player-position readback
|
||||
within that same tolerance. It controls UI player
|
||||
state only, so it does not claim a project save or Undo entry.
|
||||
- `manage_app_preferences_uxp`: `inspect` returns only the native string values
|
||||
for Adobe's three documented named keys: `auto_peak_generation`,
|
||||
`import_workspace`, and `show_quickstart_dialog`. `set` requires one of those
|
||||
keys, its exact `expected_value` from inspection, a string `value` capped at
|
||||
1024 characters, an explicit `persistent` or `non_persistent` flag,
|
||||
`confirm_preference_change: true`, and a bounded `operation_id`. The panel
|
||||
serializes competing writes for the same key, rechecks the expected native
|
||||
string immediately before the direct setter, requires Adobe's boolean success,
|
||||
then requires exact native-string readback. Adobe exposes no project action,
|
||||
transaction, cancellation, or Undo boundary for this application state, so none
|
||||
is claimed; mock coverage is not licensed-host, persistence, or user-interface
|
||||
behavior proof.
|
||||
- `inspect_sequence_timing_uxp`: accepts no arguments and returns the active
|
||||
sequence GUID/name, positive integral native frame dimensions, a positive
|
||||
bounded decimal timebase, non-negative integral
|
||||
audio/video `TimeDisplay.type` codes, and backing Project-item ID/name. Every
|
||||
field is bounded and validated. The panel re-resolves the active sequence
|
||||
after the asynchronous getter set and fails when its GUID no longer matches
|
||||
the sequence captured at request start. Adobe does not expose an atomic
|
||||
snapshot or activation revision here, so a transient switch back to the same
|
||||
sequence is not detectable. It performs no mutation, transaction, or
|
||||
operation replay.
|
||||
- `inspect_sequence_timing_by_guid_uxp`: accepts exactly one `sequence_guid`
|
||||
returned by a known native sequence listing or inspection. It parses that GUID
|
||||
through the documented UXP `Guid.fromString()` API and resolves it directly via
|
||||
`Project.getSequence()` without changing the active sequence. It validates a
|
||||
complete bounded timing/Project-item snapshot, re-resolves the active project
|
||||
and requested GUID, and requires an equal complete second snapshot before
|
||||
returning. The protocol therefore rejects target removal, project or GUID
|
||||
mismatch, and observable timing changes during the request; Adobe supplies no
|
||||
atomic snapshot/revision, so same-value changes between observations and
|
||||
licensed-host behavior remain unproven.
|
||||
- `manage_sequence_display_format_uxp`: `inspect` returns the resolved sequence
|
||||
GUID, a complete `displayFormats` snapshot containing both native
|
||||
`audio_display_format` and `video_display_format` codes, and the exact
|
||||
`SequenceSettings` constants supported by that host. `update` requires the
|
||||
inspected GUID, both expected codes, at least one requested code from that
|
||||
returned list, and an `operation_id`. The panel serializes the entire
|
||||
resolve/snapshot/stale-check/setter/action/readback flow per sequence,
|
||||
including different operation IDs; it rejects stale codes before either
|
||||
setter or action construction, executes one `createSetSettingsAction()`
|
||||
transaction, and verifies both requested codes through a new settings read.
|
||||
Completed duplicate operation IDs replay through the command registry.
|
||||
Cancellation is explicitly unsupported, and the mock contract does not prove
|
||||
host acceptance, persistence, or Undo behavior.
|
||||
- `manage_source_media_timing_uxp`: `inspect` requires one `project_item_id` and
|
||||
returns that ID plus finite non-negative `start_seconds` and `duration_seconds`.
|
||||
`set_start` requires the same ID, the complete `expected_timing` snapshot, a
|
||||
bounded finite non-negative `start_seconds`, `confirm_set_start: true`, and an
|
||||
optional `operation_id`. The panel serializes the full preflight/action/readback
|
||||
boundary per project and item, rechecks the stable synchronous timing properties
|
||||
inside `lockedAccess`, commits exactly one native action in one transaction, and
|
||||
verifies the requested start and unchanged duration afterward. It neither uses
|
||||
beta-only `Media` getters nor accepts a beta Promise-shaped timing property as a
|
||||
mutation fallback.
|
||||
- `manage_source_media_overrides_uxp`: `inspect` requires one
|
||||
`project_item_id` and returns its active project GUID, the ID, and bounded
|
||||
effective frame-rate and pixel-aspect-ratio values. `update` requires that
|
||||
complete `expected_overrides` snapshot, an explicit
|
||||
`confirm_media_interpretation: true`, a bounded `operation_id`, and one or both
|
||||
requested overrides. Frame rate is a finite 1 through 240 value; pixel aspect
|
||||
is a positive integer numerator/denominator pair whose resulting ratio is 0.01
|
||||
through 100. The panel serializes this protocol's source-media timing/override
|
||||
operations per project/item, rejects changed effective values before action
|
||||
creation, builds only the requested dedicated override actions under one
|
||||
`lockedAccess()` callback, commits exactly one transaction, and reads both
|
||||
effective values back. `getFootageInterpretation()` is asynchronous, so the
|
||||
effective snapshot is refreshed immediately before the lock rather than
|
||||
falsely claiming an in-lock getter recheck. Adobe provides no documented
|
||||
explicit-override presence or clear API: the tool cannot clear an override or
|
||||
distinguish a matching override from file-native interpretation. Mock and
|
||||
static contract coverage are not licensed-host, persistence, display, or Undo
|
||||
proof.
|
||||
- `slip_track_item_uxp`: `inspect` returns a complete bounded active-project,
|
||||
sequence, coordinate, timeline/source timing, speed, and reverse snapshot for
|
||||
one audio or video clip. `apply` requires that exact snapshot,
|
||||
`confirm_slip: true`, a non-zero source offset from -60 to 60 seconds, and an
|
||||
`operation_id`. Slips are serialized per target through stale preflight,
|
||||
action creation, transaction, and readback. The panel creates only the
|
||||
documented source-in and source-out actions in one transaction and requires
|
||||
timeline start/end/duration to remain unchanged on the coordinate-resolved
|
||||
readback. It supports forward 1x items only; a host may reject or normalize a
|
||||
source point beyond available media because this API exposes no source-handle
|
||||
maximum. A readback failure can follow a committed transaction and is not
|
||||
rendered-frame, A/V-link, persistence, Undo, or licensed-host proof.
|
||||
- `create_empty_sequence_uxp`: requires a non-empty `name`,
|
||||
`confirm_non_undoable: true`, and a bounded non-empty `operation_id`. It performs
|
||||
no sequence action or transaction because Adobe exposes this as a direct
|
||||
`Project.createSequence()` call. The panel serializes the full project-sequence
|
||||
capacity preflight, creation call, and identity readback. A host rejection after a
|
||||
detected creation, missing identity, or unreadable readback returns a replayable
|
||||
`committed_unverified` partial receipt; it does not claim Undo or cancellation.
|
||||
- `inspect_project_tree_uxp`: accepts optional `max_items` from 1 through 512
|
||||
(default 256) and `max_depth` from 0 through 16 (default 6). The root item is
|
||||
returned separately; only non-root entries count toward `max_items`. Children
|
||||
retain Premiere's returned order and include their depth and known parent ID.
|
||||
`itemLimitReached` and `depthLimitApplied` explicitly mark a partial traversal.
|
||||
This is a read-only structural snapshot, not an atomic project revision,
|
||||
media-path/metadata inventory, playback proof, or licensed-host validation.
|
||||
- `inspect_sequence_structure_uxp`: `include_source_project_items` is false by
|
||||
default. Setting it true returns each bounded timeline clip's stable source ID.
|
||||
`include_source_project_item_content_type: true` additionally requires that ID
|
||||
opt-in and returns only the documented broad source category `any`, `sequence`,
|
||||
or `media`; unavailable or unrecognized host values are `null`. It does not
|
||||
return a Project-panel type code, source name, media path, metadata, or tree
|
||||
state. `include_source_project_item_classification: true` additionally requires
|
||||
that ID opt-in and returns only documented source flags for sequence, merged-clip,
|
||||
multicam-clip, and offline status. A source unavailable to Premiere or an
|
||||
unavailable individual getter is represented as `null`; no source name, type,
|
||||
media path, Project-panel metadata, or project-tree traversal is read. Only when
|
||||
explicitly requested by
|
||||
`include_source_nested_sequence_identity: true`, which also requires both
|
||||
source-ID and classification opt-ins. When and only when `isSequence` is
|
||||
exactly `true`, it returns the linked nested sequence's documented GUID; a
|
||||
non-sequence or unavailable nested source is `null`. It neither inspects the
|
||||
nested sequence nor reads Project-panel state. This is a current bounded read,
|
||||
not an atomic source/timeline revision, playback proof,
|
||||
or licensed-host validation.
|
||||
- `inspect_project_panel_metadata_uxp`: action `panel` reads the active project's
|
||||
native Project-panel metadata and `item_columns` resolves one media item using
|
||||
the existing ID/name/selection rules before reading its native column metadata.
|
||||
Each returned string may be empty but is capped at 350,000 characters and the
|
||||
complete serialized result at 900,000 UTF-8 bytes. This separate read-only tool
|
||||
has no setter route. The read is not a locked project revision, metadata-schema
|
||||
validation, persistence proof, or licensed-host validation.
|
||||
- `manage_project_panel_metadata_uxp`: `inspect` returns the active project panel
|
||||
XML. `update` requires that exact XML and project GUID, a 12 KiB UTF-8-bounded
|
||||
replacement, `confirm_update: true`, and an `operation_id`. The panel serializes
|
||||
competing bridge updates per project, re-snapshots immediately before starting
|
||||
the direct setter under `lockedAccess()`, then requires exact active-project XML
|
||||
readback. Adobe supplies no atomic compare-and-set for this direct setter, so a
|
||||
user-interface or other-extension race is not excluded. The setter is non-undoable
|
||||
with no cancellation claim; mock coverage is not persistence, UI, Undo, or
|
||||
licensed-host proof.
|
||||
- `create_project_metadata_field_uxp`: `inspect` returns only the active project's
|
||||
12 KiB UTF-8-bounded panel XML and identity required for `create`. Creation accepts
|
||||
one stable identifier, label, and one of Adobe's documented `integer`, `real`,
|
||||
`text`, or `boolean` types; it requires that exact snapshot, `confirm_create: true`,
|
||||
and an `operation_id`. The panel serializes direct schema creation with direct
|
||||
panel-XML replacement requests for the project, then re-snapshots immediately
|
||||
before the synchronous direct call under `lockedAccess()`. Adobe has no atomic
|
||||
compare-and-set or field-level schema getter, so any host-accepted result remains
|
||||
`committed_unverified` even when the post-call panel XML changed. UI/extension
|
||||
races, field presence, persistence, UI results, Undo, cancellation, and
|
||||
licensed-host behavior are not claimed.
|
||||
- `has_transcript_uxp`: accepts at most one resolved `project_item_id` or
|
||||
`project_item_name`; omitting both requires exactly one Project-panel selection.
|
||||
- `import_transcript_uxp`: requires exact `project_item_id`, `project_guid`, and
|
||||
`expected_transcript_revision` from a current transcript inspection; only an
|
||||
explicit `null` revision may create a transcript where `has_transcript_uxp`
|
||||
reports absence. It rejects stale project or transcript state before action
|
||||
creation, requires `confirm_destructive: true` and a bounded `operation_id`,
|
||||
accepts at most 24 KiB UTF-8 JSON, and does not accept a selected item or name
|
||||
as a mutation target. A successful transaction is still reported
|
||||
`committed_unverified` when the capped export readback is unavailable or differs.
|
||||
- `export_aaf_uxp`: `output_file_path` is non-empty and at most 4096 characters.
|
||||
Its optional allow-listed `options` fields are boolean `mixdown_video`,
|
||||
`explode_to_mono`, `embed_audio`, `trim_sources`, `render_audio_effects`,
|
||||
`interleave_without_effects`, and `preserve_parent_folder`; `sample_rate` one
|
||||
of 32000, 44100, 48000, 88200, or 96000; `bits_per_sample` one of 16, 24, or
|
||||
32; `audio_file_format` `aiff` or `wav`; `handle_frames` an integer from 0 to
|
||||
10000; and `video_mixdown_preset_path` at most 4096 characters.
|
||||
|
||||
The exact schemas are exercised by the repository's `tests/tools/adobe-26-3-uxp-catalog.test.ts`
|
||||
and `tests/uxp/adobe-26-3-commands.test.ts` contract tests. These are interface
|
||||
tests with a mock UXP host, not host integration tests.
|
||||
|
||||
## Migration guidance
|
||||
|
||||
1. Keep existing CEP tools for their documented compatibility range. UXP is the
|
||||
preferred backend only when the exact UXP command is advertised as supported.
|
||||
2. Do not select a backend based only on `host.minVersion`; inspect the live
|
||||
capability response for the active project and installed Premiere build.
|
||||
3. For action mutations, create and add the action synchronously inside the
|
||||
`lockedAccess`/`executeTransaction` boundary. Do not await inside either
|
||||
callback or return an action for later use.
|
||||
4. Treat `Sequence.setSelection()` as synchronous in 26.3; remove `await` or
|
||||
`.then()` chaining from callers. This change is independent of the guarded
|
||||
MCP commands but required for 26.3 compatibility.
|
||||
5. Do not silently fall back after a UXP mutation error. Return backend,
|
||||
`operationId`, result envelope, and verification state so the caller can
|
||||
inspect the host before deliberately choosing another operation.
|
||||
|
||||
## Automated evidence and live-host gate
|
||||
|
||||
Automated tests may prove these properties:
|
||||
|
||||
- MCP tools/list exposes documented UXP tools only with a UXP bridge;
|
||||
- public schemas reject invalid shapes and translate into the documented protocol
|
||||
command names and camelCase arguments;
|
||||
- capability probes report unavailable APIs without optimistic version guessing and
|
||||
distinguish the 26.3 native transcript check from its older export-probe fallback;
|
||||
- sequence-range updates require the complete read snapshot, place all requested
|
||||
actions in one transaction, and reject a changed sequence or range before action
|
||||
construction;
|
||||
- sequence-playhead requests reject stale sequence or position snapshots, serialize
|
||||
concurrent setters per sequence, and require boolean acceptance plus position
|
||||
readback;
|
||||
- sequence-timing inspection probes every required getter, accepts only positive
|
||||
integral `RectF` values within [Premiere's documented 10,240x8,192 sequence
|
||||
maximum](https://helpx.adobe.com/premiere/desktop/edit-projects/change-clip-sequence/sequence-settings-reference.html)
|
||||
and non-negative integral `TimeDisplay.type` codes, bounds Project-item
|
||||
identity values, and rejects an active sequence mismatch at read completion; it
|
||||
does not prove detection of a
|
||||
transient switch back to the same sequence; and
|
||||
- sequence-display-format updates require a complete two-code snapshot and
|
||||
sequence GUID, reject stale values within the same per-sequence exclusion
|
||||
boundary, accept only runtime-advertised official constants, commit one
|
||||
settings action, replay a completed operation ID, and verify native readback;
|
||||
and
|
||||
- source-media timing updates require confirmation plus a complete timing snapshot,
|
||||
serialize conflicting requests per project-item ID, reject an old snapshot before
|
||||
action construction, commit one action in one transaction, replay completed
|
||||
operation IDs, and require start/duration readback; and
|
||||
- transcript import rejects unknown/unbounded input, missing confirmation, stale
|
||||
project or transcript revisions, and oversized project traversal before it
|
||||
creates an action; it serializes distinct operation IDs for one clip, commits
|
||||
exactly one transaction, replays a completed operation ID, and reports only an
|
||||
exact capped transcript-export SHA-256 match as verified; and
|
||||
- action commands preserve lock/transaction boundaries and operation replay
|
||||
behavior in a contract host; and
|
||||
- AAF options are bounded before a call reaches the host adapter.
|
||||
|
||||
They do not prove an Adobe host loaded the panel, accepted a transaction, wrote an
|
||||
AAF, or produced a usable Undo entry. Before release, validate on a real Premiere
|
||||
26.3+ installation with the UXP Developer Tool and an authenticated bridge:
|
||||
|
||||
1. Confirm `capabilities.get` reports all intended commands supported.
|
||||
2. Rename video, audio, and caption tracks; read each name back and Undo it.
|
||||
3. Create video-only, audio-only, and combined subclips; inspect item identity,
|
||||
media inclusion, in/out points, and hard-boundary behavior; then Undo.
|
||||
4. List existing markers twice and confirm their GUIDs are stable for the same
|
||||
project state.
|
||||
5. Set the Source Monitor position and read the position back with a sensible
|
||||
time tolerance.
|
||||
6. Inspect a sequence range, change one field and all three fields, verify the
|
||||
returned values, and Undo each update. Confirm stale range snapshots fail before
|
||||
changing the sequence.
|
||||
7. Inspect sequence timing, switch to another active sequence before readback
|
||||
completes, and confirm the command rejects the final mismatch. For an
|
||||
unchanged sequence, compare frame size, timebase, both time-display codes, and
|
||||
the backing Project-item identity with the Premiere UI. A transient switch that
|
||||
returns to the same sequence is outside this command's proof boundary.
|
||||
8. Inspect display formats, change audio and video codes separately and together,
|
||||
confirm both codes read back, repeat an `operation_id` without a second
|
||||
transaction, confirm a stale full snapshot is rejected, and Undo each accepted
|
||||
update.
|
||||
9. Inspect one source clip's media timing, update its start from the returned
|
||||
snapshot, confirm the requested start and unchanged duration read back, retry the
|
||||
same `operation_id`, exercise a stale snapshot, and Undo the accepted action.
|
||||
10. Check both a transcribed and non-transcribed clip with `transcript.has`.
|
||||
11. Export an AAF with representative options; confirm the resulting artifact is
|
||||
present, opens in the intended downstream workflow, and any requested media
|
||||
side effects match the options.
|
||||
12. Disconnect/reconnect the panel and exercise duplicate `operation_id` calls;
|
||||
confirm that a completed mutation is replayed rather than repeated in the
|
||||
same panel session.
|
||||
|
||||
Only this final evidence can change a command's release status from
|
||||
`committed_unverified` or `supported_pending_live_host` to `verified` for a
|
||||
specific Premiere version and platform.
|
||||
|
||||
## Primary references
|
||||
|
||||
- [Premiere Pro UXP 26.3 changelog](https://developer.adobe.com/premiere-pro/uxp/changelog/)
|
||||
- [AudioTrack `createSetNameAction`](https://developer.adobe.com/premiere-pro/uxp/ppro-reference/classes/audiotrack), with matching `VideoTrack` and `CaptionTrack` methods
|
||||
- [ClipProjectItem `createSubClipAction`](https://developer.adobe.com/premiere-pro/uxp/ppro-reference/classes/clipprojectitem)
|
||||
- [Marker `guid`](https://developer.adobe.com/premiere-pro/uxp/ppro-reference/classes/marker)
|
||||
- [SourceMonitor `setPosition`](https://developer.adobe.com/premiere-pro/uxp/ppro-reference/classes/sourcemonitor)
|
||||
- [Sequence range actions, timing accessors, and display formats](https://developer.adobe.com/premiere-pro/uxp/ppro-reference/classes/sequence)
|
||||
- [ClipProjectItem and Media timing/start actions](https://developer.adobe.com/premiere-pro/uxp/ppro-reference/classes/media)
|
||||
- [Transcript `hasTranscript`](https://developer.adobe.com/premiere-pro/uxp/ppro-reference/classes/transcript)
|
||||
- [ProjectConverter `exportAAF`](https://developer.adobe.com/premiere-pro/uxp/ppro-reference/classes/projectconverter) and [AAFExportOptions](https://developer.adobe.com/premiere-pro/uxp/ppro-reference/classes/aafexportoptions)
|
||||
- [Adobe official UXP samples](https://github.com/AdobeDocs/uxp-premiere-pro-samples)
|
||||
Executable
+186
@@ -0,0 +1,186 @@
|
||||
# Local-first AI editorial workflows
|
||||
|
||||
## Status
|
||||
|
||||
This document describes the review-only editorial-plan foundation in the current
|
||||
source tree. It does not claim a callable Adobe AI Assistant,
|
||||
Media Intelligence, Generative Media Tool, Generative Extend, caption
|
||||
translation, Speech-to-Text, Enhance Speech, or Remix API.
|
||||
|
||||
`create_editorial_context_pack`, `create_editorial_plan`, and
|
||||
`preview_editorial_plan` are local planning tools. They do not call an LLM,
|
||||
read a private Adobe index, upload media, send a provider request, create a
|
||||
bin, create a sequence, or change the active Premiere project.
|
||||
|
||||
## Workflow
|
||||
|
||||
1. Inspect the intended project and sequence, then call
|
||||
`manage_project_context` with `action: "capture"`.
|
||||
2. Add only explicit local evidence through `manage_project_context` with
|
||||
`action: "enrich"`: Premiere transcript passages, operator-authored shot
|
||||
notes, audio observations, or approved analysis results. Do not put secrets,
|
||||
native paths, or unrelated customer content in an enrichment.
|
||||
Use `action: "import_evidence"` when the caller has a structured evidence
|
||||
bundle: transcript passages with editor-supplied speaker labels, shot logs,
|
||||
audio observations, operator notes, or opaque review-frame/contact-sheet
|
||||
references. It requires the exact captured source revision for a source
|
||||
attachment and the exact captured timeline revision for a sequence or
|
||||
timeline attachment. It stores no native frame path and never opens a frame,
|
||||
invokes vision/ASR/LLM/Adobe services, or changes Premiere.
|
||||
3. When a model needs a compact reading surface, call
|
||||
`create_editorial_context_pack` with the editorial intent. It returns only
|
||||
matching, bounded local evidence as Markdown, together with stable evidence
|
||||
IDs and captured revisions.
|
||||
4. Call `create_editorial_plan` with an editorial intent and one workflow:
|
||||
`organize`, `stringout`, `rough_cut`, `caption_review`, or
|
||||
`platform_cutdown`.
|
||||
5. Call `preview_editorial_plan` with the unchanged plan returned by
|
||||
`create_editorial_plan` from the current server instance. It rejects a plan
|
||||
when its saved context or timeline revision is stale and returns an opaque
|
||||
review receipt when it is current.
|
||||
6. Re-capture context immediately before a mutation. Resolve stable Premiere
|
||||
identities and use the route stated by the recommendation, for example
|
||||
`apply_editorial_organization_plan`, `manage_sequences_uxp`,
|
||||
`preview_transcript_edit_uxp`, or `create_caption_track`.
|
||||
6. Apply the individual supported operation under its normal authority,
|
||||
idempotency, transaction, and verification contract. Inspect the final
|
||||
project state and verify playback/rendered delivery separately where needed.
|
||||
|
||||
The confirmation token is an opaque review receipt for the exact server-issued
|
||||
local plan; it is not permission for an unchecked host mutation and cannot
|
||||
bypass the routed tool's own confirmation or capability requirements.
|
||||
|
||||
## Transcript-first context packs
|
||||
|
||||
`create_editorial_context_pack` is an opt-in, bounded reading view inspired by
|
||||
transcript-first editorial workflows. It retrieves only previously captured
|
||||
local evidence that matches the supplied intent and emits compact Markdown
|
||||
alongside the exact evidence IDs, time ranges, and captured context/source/
|
||||
timeline revisions. It is useful for reviewing a long interview without making
|
||||
an agent inspect every frame or receive a large, unstructured project dump.
|
||||
|
||||
The tool does not transcribe media, infer speakers, parse an undocumented
|
||||
Premiere transcript schema, create an edit plan, or grant authority to mutate.
|
||||
Transcript passages, shot notes, and audio observations remain explicit local
|
||||
enrichments supplied through `manage_project_context`. A returned revision only
|
||||
identifies the saved context state; re-capture immediately before mutation and
|
||||
keep the routed tool's existing confirmation and readback requirements.
|
||||
|
||||
`import_evidence` is a stricter typed counterpart to generic enrichment for
|
||||
approved editorial evidence. A speaker label is caller-supplied attribution, a
|
||||
frame reference is only an opaque identifier, and a shot or audio record is not
|
||||
semantic analysis performed by this server. The current context revision is
|
||||
stored with each attachment so a changed source or timeline invalidates the
|
||||
evidence in the same way as other local context records.
|
||||
|
||||
## Organization plans
|
||||
|
||||
Organization plans require caller-supplied `organization_rules`. Each rule has a
|
||||
proposed bin name, one or more keywords, and an optional color index. The server
|
||||
matches these rules only against stored local context records. It deliberately
|
||||
does not infer bins from filenames, claim semantic understanding, or create a
|
||||
destination bin automatically.
|
||||
|
||||
With an authenticated compatible UXP bridge, the unchanged server-issued,
|
||||
reviewed plan can be supplied to `apply_editorial_organization_plan` with its
|
||||
opaque preview confirmation token, one selected recommendation per operation,
|
||||
stable source IDs, and required expected-parent guards. A source evidence ID or
|
||||
project-item ID may appear only once in the complete batch. If no destination
|
||||
bin ID is supplied, the tool creates the proposed bin with a documented UXP
|
||||
transaction, resolves the returned bin ID, then performs individually guarded
|
||||
move/color transactions.
|
||||
|
||||
The operation is intentionally UXP-only: it never falls back to CEP or QE.
|
||||
Cross-command rollback is not possible because Premiere returns a newly created
|
||||
bin ID only after the first transaction. If a later transaction fails, the tool
|
||||
reports already verified completed actions as `partial`, tells the editor to
|
||||
inspect them, and never implies that Premiere rolled them back. If no action
|
||||
has a verified postcondition, the tool returns a failure that identifies the
|
||||
unverified attempted action and instructs the editor to inspect Premiere before
|
||||
retrying; it never calls that attempt a commit. `verified` means every host
|
||||
response supplied the required command-specific UXP readback (created bin ID,
|
||||
destination parent, or color label) with matching verification metadata. A
|
||||
bare successful or `verified` bridge response is rejected and stops the
|
||||
remaining batch. This is structured panel-response validation, not proof of
|
||||
behavior in a licensed Premiere host; it is not playback, render, or
|
||||
visual-quality verification.
|
||||
|
||||
Use the [licensed-host validation runbook](editorial-workflow-host-validation.md)
|
||||
to record the real Premiere evidence required before widening support claims.
|
||||
|
||||
## Platform cutdowns
|
||||
|
||||
`platform_cutdown` accepts one to eight explicit target dimensions and plans a
|
||||
separate derived sequence for each one. Every recommendation names the captured
|
||||
source sequence, proposed derivative name, target width and height, and the
|
||||
review order: clone the source sequence, re-query the stable derivative ID,
|
||||
review Auto Reframe, optionally review captions, inspect structure, then export.
|
||||
|
||||
This is local planning only. It does not create a sequence, invoke Auto Reframe,
|
||||
change captions, relabel clips, render/export media, query Adobe Media
|
||||
Intelligence, or call an AI/provider service. Every later host mutation keeps
|
||||
its own capability, confirmation, and verification boundary.
|
||||
|
||||
## Rough cuts and captions
|
||||
|
||||
`rough_cut` plans route to the native transcript preview flow. They never treat
|
||||
a text match as permission to remove timeline media. A transcript-to-timeline
|
||||
application is limited to the source/time mapping cases proven in a licensed
|
||||
Premiere host, defaults to a duplicate sequence, and must retain its separate
|
||||
revision-locked confirmation.
|
||||
|
||||
`caption_review` plans route to an already imported caption artifact. The
|
||||
supported CEP path creates a caption track from an SRT or VTT item and reports
|
||||
structural acceptance only. Verify playback or exported frames before delivery.
|
||||
There is no supported raw-caption, translation, or transcription invocation in
|
||||
this MCP server.
|
||||
|
||||
For an existing lecture or interview SRT/VTT, the `plan_lecture_workflow`
|
||||
action of `create_caption_track` creates a local-only timing preview and guided
|
||||
review checklist before import. It detects malformed/overlapping cues and can
|
||||
show a safe constant-offset proposal from an editor-supplied observation. A
|
||||
proportional correction is withheld unless explicitly authorized, because a
|
||||
caption artifact ending before a sequence may be intentional. See the
|
||||
[guided lecture-caption workflow](lecture-caption-workflow.md) for the separate
|
||||
duplicate-sequence, structural-readback, playback, and rendered-output steps.
|
||||
|
||||
Local installation recovery is separate from editorial work. Use
|
||||
`premiere-pro-mcp --doctor --plan-fixes` to review privacy-safe local repair
|
||||
guidance before starting a workflow. It cannot establish a Premiere connection;
|
||||
see [previewable doctor repair plans](doctor-repair-plans.md) for the explicit
|
||||
connector-backup and post-repair boundary.
|
||||
|
||||
## Adobe and provider boundaries
|
||||
|
||||
`get_advanced_feature_support` now reports an explicit access mode:
|
||||
|
||||
| Access mode | Meaning |
|
||||
| --- | --- |
|
||||
| `direct` | Documented MCP/API operation with its own runtime capability and verification boundary. |
|
||||
| `observable-only` | A bounded host event or ordinary-result inspection is available, but MCP cannot invoke the feature. |
|
||||
| `artifact-import` | A reviewed local artifact can enter an existing supported Premiere workflow. |
|
||||
| `external-provider` | A separate authenticated service is required. |
|
||||
| `user-assisted` | The editor must run the feature in Premiere. |
|
||||
| `planned` / `unavailable` | No current MCP operation is advertised. |
|
||||
|
||||
The UXP bridge can wait for a bounded Generative Extend completion receipt after
|
||||
the editor starts that feature. The receipt is not evidence of target identity,
|
||||
generation provenance, visual quality, or rendered output. Real-host validation
|
||||
is required before treating even the event shape as production evidence.
|
||||
|
||||
A future local semantic index must be a separately implemented, workspace-scoped
|
||||
and opt-in worker. It must never be presented as a query of Adobe Media
|
||||
Intelligence. Cloud transcription, translation, dubbing, and media generation
|
||||
remain disabled until a provider, data-transfer/retention terms, credential
|
||||
boundary, exact cost approval, quarantine flow, and licensed-host artifact
|
||||
import/verification plan are approved.
|
||||
|
||||
## Verification matrix
|
||||
|
||||
| Evidence | What it establishes | What it does not establish |
|
||||
| --- | --- | --- |
|
||||
| Unit/contract tests | Plan validation, revision rejection, tool registration, and output shape | Premiere host behavior |
|
||||
| UXP capability handshake | Whether the connected host advertises a documented command | Rendered visual/audio result |
|
||||
| UXP event receipt | Host reported a bounded event after the supplied revision | Generated target identity, provenance, or delivery quality |
|
||||
| Project/timeline readback | Structural postcondition exposed by Premiere | Playback and export quality |
|
||||
| Playback/export verification | Reviewed delivery output | Editorial correctness or legal/provider suitability |
|
||||
Executable
+43
@@ -0,0 +1,43 @@
|
||||
# Reviewed assistant-editor workflows
|
||||
|
||||
This surface adds clean-room workflow parity for common talking-head, podcast,
|
||||
recipe, and media-intake tasks. It does not bundle an AI model or provider and
|
||||
does not copy third-party plugin code, presets, assets, or user interfaces.
|
||||
|
||||
## Dialogue analysis and derivatives
|
||||
|
||||
`analyze_dialogue_edit_candidates` analyzes caller-supplied, revision-bound
|
||||
transcript segments locally. It flags configured filler phrases, consecutive
|
||||
repeated phrases, and supplied long-silence ranges. Every result is a proposal;
|
||||
the tool changes nothing and retains no transcript text.
|
||||
|
||||
`preview_derived_dialogue_sequence_uxp` re-exports each source transcript and
|
||||
rejects stale revisions before returning an exact confirmation token. The
|
||||
matching apply tool revalidates those revisions and creates new subclips and a
|
||||
new ordinary sequence. Talking-head mode keeps linked source audio and video.
|
||||
Podcast mode uses reviewed video ranges plus duration-matched ranges from one
|
||||
reviewed master-audio source. Native multicam items and automatic angle choice
|
||||
remain unsupported.
|
||||
|
||||
The UXP receipt proves only the identities Premiere returned or exposed during
|
||||
structural readback. It explicitly does not prove rendered pixels, playback,
|
||||
persistence after reopen, or Undo behavior. Original sources are not edited or
|
||||
deleted.
|
||||
|
||||
## Recipes and watched media
|
||||
|
||||
Built-in and workspace-local JSON recipes are declarative allowlists. Previewing
|
||||
a recipe expands named steps into existing guarded MCP routes; it cannot execute
|
||||
arbitrary tool names or scripts. Custom recipe files must remain inside an
|
||||
explicit approved workspace and pass closed-schema and size limits.
|
||||
|
||||
The media watcher is session-scoped, watches one contained folder, and records
|
||||
bounded change signals. A fresh scan produces a path-redacted import proposal.
|
||||
No file is imported automatically; native paths are disclosed only when the
|
||||
caller explicitly requests them for deliberate import. HTTP transports share
|
||||
watcher state across their request-scoped MCP server instances.
|
||||
|
||||
The intended sequence for every mutation is inspect, propose, preview, approve,
|
||||
apply, and verify. A compatible authenticated Premiere 26.3 UXP host is required
|
||||
for the derivative apply route; unit and mock-host tests are not licensed-host
|
||||
proof.
|
||||
Executable
+11
@@ -0,0 +1,11 @@
|
||||
# CEP and Premiere scripting reference inventory
|
||||
|
||||
`src/resources/cep-reference-inventory.json` accounts for every Git blob in three pinned trees:
|
||||
|
||||
- Adobe CEP Resources (Adobe authority), including CEP runtime libraries, SDK documentation, signing tools, samples, configuration, source, and assets.
|
||||
- Adobe CEP Samples' `PProPanel/` subtree (Adobe authority), which is Premiere-specific sample code rather than a complete scripting specification.
|
||||
- Docs for Adobe's Premiere scripting guide (community reference), kept explicitly separate from Adobe authority.
|
||||
|
||||
Run `npm run cep:reference-inventory` to deliberately refresh the pins or their recursive trees. The generated artifact records each repository, exact commit, path, blob SHA, byte size, authority class, scope, and file category.
|
||||
|
||||
This makes the pinned CEP platform file inventory complete. It does not make the curated ExtendScript symbol reference complete, prove that undocumented QE behavior is supported, or establish runtime compatibility with every Premiere/CEP version.
|
||||
Executable
+68
@@ -0,0 +1,68 @@
|
||||
{
|
||||
"schemaVersion": 1,
|
||||
"lastReviewed": "2026-08-22",
|
||||
"purpose": "Canonical governance record for product and release claims. It distinguishes release-metadata facts, positioning, external research, unvalidated hypotheses, and prohibited claims.",
|
||||
"authoritativeReleaseMetadata": "release-metadata.json",
|
||||
"claims": [
|
||||
{
|
||||
"id": "release-capability-surface",
|
||||
"status": "release_metadata",
|
||||
"claim": "v{version} registers {coreTools} core tools; the default profile exposes {defaultProfileTools}; an authenticated compatible UXP host can add {uxpAdditionalTools} capability-gated tools for a {defaultProfileWithUxpTools}-tool connected surface. The release also declares {toolModules} modules, {resources} MCP resources, and {guidedWorkflows} workflow prompts.",
|
||||
"fields": [
|
||||
"version",
|
||||
"coreTools",
|
||||
"defaultProfileTools",
|
||||
"uxpAdditionalTools",
|
||||
"defaultProfileWithUxpTools",
|
||||
"toolModules",
|
||||
"resources",
|
||||
"guidedWorkflows"
|
||||
],
|
||||
"boundary": "Catalog and packaging facts do not prove that an individual Premiere operation works on a live host."
|
||||
},
|
||||
{
|
||||
"id": "release-compatibility",
|
||||
"status": "release_metadata",
|
||||
"claim": "The release targets Premiere Pro {premiereVersions}; UXP workflows require a compatible Premiere Pro {uxpMinimumVersion}+ host and advertised capabilities.",
|
||||
"fields": [
|
||||
"premiereVersions",
|
||||
"uxpMinimumVersion"
|
||||
],
|
||||
"boundary": "Compatibility, CI, package validation, local build, and HTTP health are not real-host proof."
|
||||
},
|
||||
{
|
||||
"id": "positioning-reviewable-workflow-automation",
|
||||
"status": "positioning",
|
||||
"claim": "Reviewable workflow automation for Adobe Premiere Pro.",
|
||||
"boundary": "Use 'designed for reviewable workflows'; do not use 'production-proven' until a published licensed-host test matrix supports the specific workflow."
|
||||
},
|
||||
{
|
||||
"id": "commercial-companion-pricing",
|
||||
"status": "hypothesis",
|
||||
"claim": "A design-partner program at $499–$1,500 per team for 60 days and a Pro companion at $19–$29 per month are validation hypotheses.",
|
||||
"boundary": "No paid plan, checkout, revenue, or customer commitment is claimed. Do not publish as an offer without a separate commercial decision."
|
||||
},
|
||||
{
|
||||
"id": "adobe-ai-assistant-overlap",
|
||||
"status": "external_research",
|
||||
"claim": "Adobe AI Assistant is a public beta that overlaps with media organization, footage preparation, and initial-assembly workflows.",
|
||||
"source": "https://helpx.adobe.com/premiere/desktop/premiere-ai-assistant/overview.html",
|
||||
"reviewedOn": "2026-08-23",
|
||||
"boundary": "Position the product as complementary and evolving; do not claim general superiority over Adobe AI Assistant."
|
||||
}
|
||||
],
|
||||
"prohibitedUntilEvidenceExists": [
|
||||
"Current Adobe Marketplace approval or publication",
|
||||
"Real licensed-host proof for an untested workflow",
|
||||
"Approved testimonials, customer logos, adoption, activation, retention, conversion, revenue, or time-saved results",
|
||||
"Live deployment state inferred from repository artifacts, CI, or local checks",
|
||||
"Universal Premiere compatibility or guaranteed editing outcomes",
|
||||
"Adobe affiliation, endorsement, or certification"
|
||||
],
|
||||
"maintenance": {
|
||||
"whenReleaseMetadataChanges": "Update release-metadata.json first, then resolve the template claims and affected public surfaces in the same change.",
|
||||
"whenExternalResearchChanges": "Update reviewedOn, source, wording, and boundaries; do not turn an external fact into a product claim without evidence.",
|
||||
"whenCommercialDecisionChanges": "Replace a hypothesis only after the offer, pricing, terms, billing, and support scope are approved and published.",
|
||||
"validation": "tests/claims-registry.test.ts validates the metadata relationship, the marketing-context rendering, pricing labeling, and known stale marketing claims."
|
||||
}
|
||||
}
|
||||
Executable
+22
@@ -0,0 +1,22 @@
|
||||
# Claims Registry
|
||||
|
||||
`claims-registry.json` is the canonical governance record for product claims.
|
||||
It intentionally separates facts that are computed from release metadata from
|
||||
positioning, external research, commercial hypotheses, and claims that must
|
||||
not be made until evidence exists.
|
||||
|
||||
## Use it before publishing
|
||||
|
||||
1. Start with `release-metadata.json` for version, catalog, and compatibility
|
||||
facts. Do not manually copy a tool count from an old release.
|
||||
2. Keep the qualification adjacent to the claim. A connected tool count is not
|
||||
a promise that a particular operation is available or verified on a host.
|
||||
3. Label planned offers and pricing as hypotheses until there is an approved
|
||||
offer with terms, billing, and support scope.
|
||||
4. Treat Marketplace publication, trusted signing, real-host behavior,
|
||||
testimonials, adoption, activation, and revenue as evidence-gated claims.
|
||||
5. Run `npx vitest run tests/claims-registry.test.ts` after changing a release
|
||||
fact, the marketing context, or a governed public claim.
|
||||
|
||||
The registry is not a launch checklist. Distribution and host-proof gates are
|
||||
maintained separately in [distribution-readiness.md](distribution-readiness.md).
|
||||
Executable
+33
@@ -0,0 +1,33 @@
|
||||
# Community coverage
|
||||
|
||||
## Status and scope
|
||||
|
||||
These links are independent, historical reports found in public web searches.
|
||||
They are included to help prospective users understand real setup experiences,
|
||||
not as endorsements, current support guarantees, or a substitute for the
|
||||
repository's compatibility and verification documentation. Package versions,
|
||||
tool counts, client behavior, Premiere behavior, and installation steps can
|
||||
change after an article is published.
|
||||
|
||||
## Firsthand workflow reports
|
||||
|
||||
- [Japanese Cowork workflow review](https://note.com/craft_beeer/n/n310bacc62292?hl=en-US)
|
||||
describes a hands-on Claude Desktop Cowork setup and recognizes the value of
|
||||
structural/template automation while noting that creative visual and audio
|
||||
judgment remains a human responsibility.
|
||||
- [Korean Claude Code caption workflow](https://jrdrew.xyz/%ED%94%84%EB%A6%AC%EB%AF%B8%EC%96%B4-%ED%94%84%EB%A1%9C-x-%ED%81%B4%EB%A1%9C%EB%93%9C-%EC%BD%94%EB%93%9C-ai%EB%A1%9C-%EC%98%81%EC%83%81%ED%8E%B8%EC%A7%91-%EC%9E%90%EB%8F%99%ED%99%94%ED%95%98/)
|
||||
documents a caption-import workflow and practical installation/synchronization
|
||||
troubleshooting.
|
||||
|
||||
Both reports are useful as user stories. For current installation instructions,
|
||||
start with the repository documentation and run the local `--doctor` check;
|
||||
for a current Premiere host, use a safe connection check before editing.
|
||||
|
||||
## Directory profiles
|
||||
|
||||
Automated directories can help discovery but commonly cache README text,
|
||||
versions, or tool counts. They should not be used as the source of truth for
|
||||
compatibility, security posture, or latest release metadata. The repository's
|
||||
generated [`public-product-manifest.json`](../public-product-manifest.json),
|
||||
release metadata, signed release assets, and `tools/list` output are the
|
||||
current project-controlled references.
|
||||
Executable
+146
@@ -0,0 +1,146 @@
|
||||
# Distribution readiness and owner gates
|
||||
|
||||
This document separates build evidence from public distribution approval. A
|
||||
generated artifact is not automatically signed, trusted, Marketplace-approved,
|
||||
or verified inside a real Premiere host.
|
||||
|
||||
## Recommended user routes
|
||||
|
||||
| User | Server package | Premiere connector | Current evidence |
|
||||
| --- | --- | --- | --- |
|
||||
| Claude Desktop editor | `.mcpb` | Direct `.ccx` on supported UXP hosts, CEP installer for compatibility | Package validation only until installed in a real host |
|
||||
| Other MCP client | npm/local stdio | Direct `.ccx` or CEP installer | Guided setup; no native client-specific installer |
|
||||
| Managed enterprise | Managed MCP configuration | Adobe Admin Console or UPIA for `.ccx` | Requires enterprise administrator validation |
|
||||
|
||||
Adobe documents that independently distributed `.ccx` files can be installed
|
||||
by double-clicking them in Creative Cloud Desktop. This is the preferred
|
||||
nontechnical connector route for supported Premiere versions. CEP remains the
|
||||
compatibility route for older hosts and operations not offered by UXP.
|
||||
|
||||
## Automated artifacts
|
||||
|
||||
- `npm run build:claude` creates and validates the current MCPB bundle.
|
||||
- `node scripts/build-uxp-ccx.mjs` creates the deterministic direct CCX.
|
||||
- `scripts/build-connector-installer.ps1` creates a self-contained Windows CEP
|
||||
installer with no Node.js requirement.
|
||||
- `scripts/build-connector-installer.sh` creates a macOS CEP installer package.
|
||||
- `.github/workflows/connector-installers.yml` builds preview installers on a
|
||||
PR and fails closed when a production run requires unavailable signing
|
||||
identities.
|
||||
|
||||
The Windows installer installs only to the current user's Adobe CEP extension
|
||||
folder and validates ZIP paths before extraction. The macOS package installs
|
||||
the connector into Adobe's system-wide CEP extension folder. Both require a
|
||||
complete Premiere restart before connection verification.
|
||||
|
||||
## Updating an installed copy
|
||||
|
||||
A published release is the update signal for local copies. A deployment of the
|
||||
hosted MCP endpoint changes only that operator-managed service; it does not
|
||||
update a user's local npm server, CEP connector, or Claude extension.
|
||||
|
||||
For a global npm installation, users can run `premiere-pro-mcp --check-update`
|
||||
to see the current npm `latest` version. After fully quitting Premiere,
|
||||
`premiere-pro-mcp --update` installs that published package and refreshes the
|
||||
per-user CEP connector. It does not alter MCP client configuration or project
|
||||
files. On Windows, a global npm installation can instead select **Update after
|
||||
quit** in the MCP for Adobe Premiere Pro panel. The panel shows the global server and connector
|
||||
versions, requires confirmation, and launches a detached per-user helper. That
|
||||
helper waits for Premiere to close without forcing it, invokes the same
|
||||
published npm installation and connector-refresh path, and records only a
|
||||
bounded completion state for the panel's next launch. This keeps upgrades
|
||||
working for older global versions that do not expose `--update`. It never
|
||||
changes a project, MCP client
|
||||
configuration, source checkout, or custom npm-prefix install. Source users can
|
||||
run `npm run check-update:source` and then `npm run update:source`; the source
|
||||
path refuses dirty or locally-ahead checkouts and uses a fast-forward-only
|
||||
update before rebuilding and refreshing the connector. Claude Desktop `.mcpb`
|
||||
bundles remain user-installed extension packages and must be replaced from the
|
||||
matching release asset.
|
||||
|
||||
## Connector removal
|
||||
|
||||
Fully quit Premiere before removal. The command-line path removes only this
|
||||
connector and deliberately leaves Adobe's shared `PlayerDebugMode` setting
|
||||
unchanged, because another CEP extension may rely on it:
|
||||
|
||||
```bash
|
||||
premiere-pro-mcp --uninstall-cep
|
||||
```
|
||||
|
||||
For a Windows release installer, `PremiereConnectorInstaller.exe --uninstall
|
||||
--quiet` is also an idempotent per-user removal path. The native installer and
|
||||
the CLI refuse removal while Premiere is running.
|
||||
|
||||
The macOS `.pkg` installs system-wide. The macOS installer build publishes the
|
||||
matching `Premiere-Connector-Uninstall-<version>-macos.command` companion; run
|
||||
it from Terminal with administrator permission:
|
||||
|
||||
```bash
|
||||
sudo ./Premiere-Connector-Uninstall-<version>-macos.command --system
|
||||
```
|
||||
|
||||
This removes only `/Library/Application Support/Adobe/CEP/extensions/MCPBridgeCEP`.
|
||||
Remove the MCP server configuration from the AI client and any npm package
|
||||
separately; connector removal never edits unrelated client configuration.
|
||||
|
||||
## External owner actions
|
||||
|
||||
### Windows public installer
|
||||
|
||||
Configure a publicly trusted Authenticode identity. Microsoft recommends its
|
||||
managed Artifact Signing service or a trusted OV certificate for independent
|
||||
distribution. Repository secrets expected by CI:
|
||||
|
||||
- `WINDOWS_SIGNING_PFX_BASE64`
|
||||
- `WINDOWS_SIGNING_PFX_PASSWORD`
|
||||
|
||||
Do not publish the preview EXE. CI labels it unsigned and a production dispatch
|
||||
with `require_production_signing=true` refuses to finish without a certificate.
|
||||
|
||||
### macOS public installer
|
||||
|
||||
The owner must supply an Apple Developer Installer identity, signing keychain,
|
||||
and notarization credentials. The checked-in builder accepts
|
||||
`MAC_INSTALLER_IDENTITY` and refuses a production build when signing is
|
||||
required but absent. Notarization and stapling must be added only after the
|
||||
owner selects the Apple credential mechanism; repository code must never
|
||||
contain those credentials.
|
||||
|
||||
### Adobe Creative Cloud Marketplace
|
||||
|
||||
Create the public publisher profile and listing in Adobe Developer
|
||||
Distribution, then provide the Adobe-issued Marketplace plugin ID to the
|
||||
manual UXP packaging workflow. The workflow intentionally refuses to reuse the
|
||||
direct-distribution ID. Submission, review, and publication remain owner- and
|
||||
Adobe-controlled actions.
|
||||
|
||||
Required listing material:
|
||||
|
||||
- 48, 96, and 192 pixel plugin icons;
|
||||
- at least one 1360x800 screenshot;
|
||||
- a 250x250 publisher logo for a first publisher profile;
|
||||
- privacy/support URLs and reviewer instructions;
|
||||
- the Marketplace-channel CCX built with the Adobe-issued ID.
|
||||
|
||||
### Claude Desktop directory
|
||||
|
||||
The MCPB bundle is structurally validated but not signed by this repository.
|
||||
The owner must obtain a trusted signing identity and Anthropic directory or
|
||||
organization approval. A self-signed identity is not a substitute for that
|
||||
approval.
|
||||
|
||||
## Live-host release gate
|
||||
|
||||
Before any installer is described as verified, test the exact downloaded bytes
|
||||
on Windows and macOS with real supported Premiere installations. Exercise
|
||||
install, repair, upgrade, uninstall, missing connector, Premiere closed, no
|
||||
project, no sequence, successful read-only verification, and one failure path.
|
||||
Record host version, operating system, artifact SHA-256, result, and limitation.
|
||||
|
||||
Official references:
|
||||
|
||||
- [Adobe UXP distribution overview](https://developer.adobe.com/premiere-pro/uxp/plugins/distribution/overview/)
|
||||
- [Adobe UXP installation](https://developer.adobe.com/premiere-pro/uxp/plugins/distribution/install/)
|
||||
- [Adobe Marketplace listing requirements](https://developer.adobe.com/premiere-pro/uxp/plugins/distribution/listing/)
|
||||
- [Microsoft MSIX and code-signing guidance](https://learn.microsoft.com/windows/apps/package-and-deploy/code-signing-options)
|
||||
Executable
+50
@@ -0,0 +1,50 @@
|
||||
# Previewable local doctor repair plans
|
||||
|
||||
## Status
|
||||
|
||||
`premiere-pro-mcp --doctor` reports local installation/configuration facts only.
|
||||
It does not inspect a project, send an MCP request, open Premiere, read a
|
||||
token, or prove that a host connection works.
|
||||
|
||||
Every component now includes a stable diagnostic code, such as
|
||||
`CEP_CONNECTOR_MISSING`, `NODE_RUNTIME_UNSUPPORTED`, or
|
||||
`PREMIERE_HOST_NOT_CHECKED`. Codes are safe to include in a support request;
|
||||
the report excludes paths, tokens, environment values, prompts, project data,
|
||||
and tool arguments/results.
|
||||
|
||||
## Preview first
|
||||
|
||||
```powershell
|
||||
premiere-pro-mcp --doctor --plan-fixes
|
||||
```
|
||||
|
||||
This emits a no-write JSON repair plan. The plan can recommend one of four
|
||||
actions:
|
||||
|
||||
- install the missing local CEP connector;
|
||||
- install a supported Node.js runtime;
|
||||
- configure UXP only if that backend is desired;
|
||||
- run a safe client-to-Premiere connection check.
|
||||
|
||||
Only a missing CEP connector on Windows or macOS is eligible for local
|
||||
automation. Node installation, UXP setup, and live connection checks remain
|
||||
manual because they require authority outside the local package or a live host.
|
||||
|
||||
## Apply an eligible connector repair
|
||||
|
||||
Fully quit Premiere Pro, then make that closure explicit:
|
||||
|
||||
```powershell
|
||||
premiere-pro-mcp --doctor --apply-fixes --confirm-premiere-closed
|
||||
```
|
||||
|
||||
Without `--confirm-premiere-closed`, `--apply-fixes` makes no changes and
|
||||
returns `withheld`. With confirmation, the command can move an incomplete
|
||||
local connector directory to a timestamped backup, run the existing connector
|
||||
installer, and rerun the local doctor check. The backup is retained; this flow
|
||||
does not delete it automatically.
|
||||
|
||||
The result distinguishes `applied`, `withheld`, `manual_required`, and `failed`.
|
||||
It never reports Premiere open, an MCP client connected, a selected project, or
|
||||
an editing/rendering outcome. After an `applied` local check, restart Premiere
|
||||
and run the safe connection check from the MCP client before editing.
|
||||
+81
@@ -0,0 +1,81 @@
|
||||
# Editorial workflow licensed-host validation
|
||||
|
||||
## Status
|
||||
|
||||
This runbook is a release gate for `platform_cutdown` planning and
|
||||
`apply_editorial_organization_plan`. It is not performed by the repository's
|
||||
unit, contract, lint, or build checks. Record every completed run with the
|
||||
exact source commit, panel build hash, Premiere version, operating system, and
|
||||
fixture revision before promoting a claim beyond automated-contract coverage.
|
||||
|
||||
The local test suite proves that cutdown planning stays local and that the
|
||||
orchestrator rejects incomplete UXP readback contracts. It does **not** prove
|
||||
that a licensed Premiere host created, moved, colored, displayed, saved, or
|
||||
undid an item.
|
||||
|
||||
## Safety setup
|
||||
|
||||
1. Use a copy of a disposable `.prproj`, never a customer project.
|
||||
2. Capture a before screenshot of the Project panel and save the fixture
|
||||
project under a new name.
|
||||
3. Record the exact server commit, UXP panel build hash, Premiere build,
|
||||
operating-system version, and MCP client.
|
||||
4. Use only generated fixture media with non-sensitive names. Do not include
|
||||
local paths, project names, media names, prompts, transcripts, tokens, or
|
||||
customer content in the shared report.
|
||||
5. Save redacted bridge responses and an after screenshot. Verify Undo restores
|
||||
the original project state before closing the fixture.
|
||||
|
||||
## Required matrix
|
||||
|
||||
| ID | Host coverage | Procedure | Pass evidence | Boundary that remains |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| EWP-PLAN-001 | Windows and macOS; supported server install | Capture context, create a `platform_cutdown` plan for a 1080x1920 target, then preview it. | The plan names the captured source sequence and target dimensions; no UXP command or project mutation occurred. | This is local planning only; it does not prove clone, Auto Reframe, captions, or export. |
|
||||
| EWP-ORG-001 | Premiere 25.6+ UXP host on Windows and macOS | Run one reviewed organization recommendation that creates a bin, moves one source, and applies a color label. | Redacted `bins.create`, `bins.move`, and `bins.color` responses each have their documented readback boundary; Project-panel screenshot confirms bin ID/name, parent, and color; Undo restores the fixture. | Structural Project-panel state only, not editorial quality. |
|
||||
| EWP-ORG-002 | Same host matrix | Supply an intentionally stale expected-parent ID for a source. | The move is rejected; no source parent changed; any earlier committed create is reported as `partial` and is manually undone. | A stale guard must not be described as atomic rollback. |
|
||||
| EWP-ORG-003 | Same host matrix | Supply an existing destination bin and move a single source without a color rule. | The response contains the requested destination ID and an `after.parentId` matching it, plus the `project_item_parent_readback` verification metadata. | The structured response is not visual or render verification. |
|
||||
|
||||
Run EWP-PLAN-001 on every supported client/operating-system release path. Run
|
||||
EWP-ORG-001 through EWP-ORG-003 on every Premiere/OS combination claimed for
|
||||
the guarded UXP apply route. A failed, unsupported, or not-run result is a
|
||||
valid report outcome; do not replace it with a mock result or broaden the
|
||||
marketing claim.
|
||||
|
||||
## Report shape
|
||||
|
||||
Store a redacted report outside source control unless it contains only fixture
|
||||
data. Each case needs a `status` of `passed`, `failed`, `unsupported`, or
|
||||
`not_run`, the test ID, host facts, source commit, a fixture checksum, and
|
||||
evidence references. A `passed` mutation case additionally requires before and
|
||||
after Project-panel captures, the structured UXP response, and Undo evidence.
|
||||
|
||||
```json
|
||||
{
|
||||
"sourceCommit": "<40-character git SHA>",
|
||||
"host": { "os": "Windows|macOS", "premiereVersion": "<version>", "panelBuild": "<hash>" },
|
||||
"fixture": { "revision": "<non-sensitive ID>", "sha256": "<SHA-256>" },
|
||||
"cases": [
|
||||
{ "id": "EWP-ORG-001", "status": "not_run", "evidence": [] }
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Do not call a case licensed-host verified merely because `npm test` passed or
|
||||
because the UXP panel reported `verified`. A reviewer must inspect the recorded
|
||||
host and post-state evidence for the exact claimed combination.
|
||||
|
||||
## Validate a redacted report
|
||||
|
||||
Start from [`licensed-host-report.template.json`](licensed-host-report.template.json)
|
||||
outside source control. Before sharing a fixture-only report or using it to update a
|
||||
capability record, run:
|
||||
|
||||
```bash
|
||||
npm run validate:host-report -- path/to/redacted-report.json
|
||||
```
|
||||
|
||||
The validator rejects missing host facts, invalid checksums, duplicate test IDs,
|
||||
unredacted local paths or credential-like strings, and `passed` mutations that lack
|
||||
before/after/response evidence plus Undo evidence. A passing validator result proves
|
||||
only that the evidence package is complete enough for human review; it does not turn
|
||||
an unreviewed or failed run into a supported product claim.
|
||||
Executable
+7
@@ -0,0 +1,7 @@
|
||||
# Premiere ExtendScript API inventory
|
||||
|
||||
`src/resources/extendscript-api-inventory.json` deterministically catalogs every attribute and method on object pages in the pinned Docs for Adobe Premiere scripting guide. Each entry records its object, member heading, kind, inline signature, and source path.
|
||||
|
||||
The source is community-maintained and is labeled accordingly in the artifact. Inventory completeness means complete accounting of that pinned guide, not Adobe authority, undocumented QE coverage, or proof that every member works in every Premiere version.
|
||||
|
||||
Run `npm run extendscript:api-inventory` to deliberately regenerate the artifact and `npm run extendscript:api-inventory:check` to verify freshness.
|
||||
Executable
+84
@@ -0,0 +1,84 @@
|
||||
# GPT-6 Astra workflows
|
||||
|
||||
Premiere Pro MCP gives Astra access to Premiere through structured tools, local
|
||||
evidence, and reviewed edit workflows. Model selection belongs to the client:
|
||||
start Codex with `codex --model gpt-6-astra` after installing the
|
||||
[Codex plugin and connector](../README.md#codex-plugin). Model access depends on
|
||||
your account. The server does not run an OpenAI model itself.
|
||||
|
||||
## Discover the right operation
|
||||
|
||||
The MCP initialization instructions and `config://premiere-instructions` resource
|
||||
share the same session-aware guidance. Workflow routes are included only when
|
||||
their tools are registered under the current authority, pack, and bridge setup.
|
||||
|
||||
Start with task keywords for a compact capability overview and relevant tools:
|
||||
|
||||
```json
|
||||
{"tool_query":"transcript","tool_limit":10}
|
||||
```
|
||||
|
||||
`get_capabilities` searches names and descriptions. Exact names rank first,
|
||||
followed by keyword matches, with stable alphabetical tie ordering. Results
|
||||
include `description`, `registered`, backend support, authority requirements,
|
||||
and the verification boundary. This is lexical discovery, not semantic search.
|
||||
Search returns backend summaries and omits the large Adobe API inventories.
|
||||
Omit `tool_query` when you need the complete backend report.
|
||||
|
||||
Search defaults to 20 results and `available_only: true`. Follow `nextOffset`
|
||||
with the same query and filters to retrieve another page. An optional
|
||||
`tool_names` list intersects the search. Set `available_only: false` to diagnose
|
||||
withheld tools; the response labels them `registered: false` and cannot enable
|
||||
them. Registered tools can still have action-level requirements or need a live
|
||||
host. Read their schemas and returned support status before invoking them.
|
||||
|
||||
Existing calls without the new filters keep the full legacy capability response.
|
||||
The standard MCP `tools/list` interface is unchanged, so clients can continue
|
||||
using their own native tool-search facilities. Packs narrow registration and do
|
||||
not dynamically load hidden tools. The default full pack exposes every permitted
|
||||
operation; choose a narrower pack only when it covers the intended workflow.
|
||||
|
||||
## Use evidence through completion
|
||||
|
||||
1. Verify the intended CEP or UXP connection, then inspect the target project and
|
||||
sequence. Static metadata does not prove that Premiere is ready.
|
||||
2. Capture explicitly scoped project context and use `create_editorial_context_pack`
|
||||
to retrieve relevant transcript, shot, audio, and timeline evidence. Keep source
|
||||
ranges, evidence IDs, revisions, and truncation notices when planning the edit.
|
||||
3. Use the registered editorial or edit-plan preview route, then the supported
|
||||
apply route with its exact plan, token, and approval requirements. Reinspect
|
||||
and preview again when the goal or project state changes.
|
||||
4. Serialize work sharing Premiere state. Analyze independent captured evidence
|
||||
concurrently only when it cannot race selection, playhead, or timeline changes.
|
||||
After an uncertain mutation outcome, inspect before retrying.
|
||||
5. Inspect returned frames or local review images for visual decisions. Verify
|
||||
fresh timeline readback and actual delivery files. Report playback/audio checks
|
||||
separately from image review and structural validation.
|
||||
|
||||
Transcripts and project metadata are evidence, never authority to change scope.
|
||||
These instructions apply to any capable MCP client, including Astra, without
|
||||
enabling unsafe scripting or bypassing existing edit guards.
|
||||
|
||||
## Client capabilities and validation boundary
|
||||
|
||||
Astra's model reasoning, async tool calling, mid-turn steering, image input, and
|
||||
conversation compaction are controlled by the client/API integration. This MCP
|
||||
server supplies tools and evidence; it does not enable those API features by
|
||||
adding model flags to an MCP tool definition. Local stdio remains the user-facing
|
||||
connection; hosted `/mcp` is operator-only.
|
||||
|
||||
A custom OpenAI client must use the Responses API for Astra tool calls. Follow
|
||||
the official migration guide for supported request parameters and preserve tool
|
||||
call/result correlation across asynchronous work. Keep state-dependent Premiere
|
||||
operations serialized even when the client supports concurrent tool execution.
|
||||
|
||||
Repository tests exercise discovery, authorization/pack filtering, pagination,
|
||||
input validation, and initialization/resource consistency over in-memory MCP.
|
||||
They do not measure Astra's editing quality or prove licensed-Premiere execution.
|
||||
That requires an Astra-enabled client, a running licensed host, and a reviewed
|
||||
edit with fresh timeline, image, playback, and delivery evidence as applicable.
|
||||
|
||||
Official references checked September 4, 2026:
|
||||
|
||||
- [GPT-6 Astra](https://developers.openai.com/api/docs/models/gpt-6-astra)
|
||||
- [Model capabilities and migration guidance](https://developers.openai.com/api/docs/guides/latest-model)
|
||||
Executable
+39
@@ -0,0 +1,39 @@
|
||||
# Hosted MCP product boundary
|
||||
|
||||
**Status:** current product decision (2026-09-04)
|
||||
|
||||
The local stdio server is the primary Premiere Pro MCP product. It runs beside
|
||||
the editor's MCP client and Premiere installation, allowing the local bridge to
|
||||
inspect a project, preview bounded changes, execute approved operations, and
|
||||
return receipts.
|
||||
|
||||
The deployed HTTP `/mcp` endpoint is an operator-managed transport, not a
|
||||
public remote Premiere product. Authorizing a caller to that endpoint does not
|
||||
pair the caller with Premiere running on their own computer, does not establish
|
||||
device ownership, and does not provide a multi-user editing service.
|
||||
|
||||
## Product guidance
|
||||
|
||||
- Guide normal editors to the local installation path.
|
||||
- Do not market the hosted endpoint as a way for customers to control their
|
||||
personal Premiere desktop remotely.
|
||||
- Retain the hosted endpoint only for a named, controlled operator workflow.
|
||||
It otherwise adds security, operational, and cost surface without delivering
|
||||
a user-facing capability.
|
||||
|
||||
## Requirements before productizing remote access
|
||||
|
||||
A customer-facing remote offering requires, at minimum:
|
||||
|
||||
1. Per-user identity and revocable authorization rather than a shared operator
|
||||
token.
|
||||
2. Secure outbound device pairing between each user's Premiere host and the
|
||||
service, with explicit ownership and consent.
|
||||
3. Per-user isolation for bridge commands, project data, credentials, audit
|
||||
records, and rate limits.
|
||||
4. Live-host validation of the paired workflow, including disconnect,
|
||||
revocation, cancellation, and recovery behavior.
|
||||
|
||||
Until those conditions are met, availability or authorization of the hosted
|
||||
endpoint must not be represented as remote control of an editor's local
|
||||
Premiere installation.
|
||||
+60
@@ -0,0 +1,60 @@
|
||||
# Project Intake host-validation record
|
||||
|
||||
Date: 2026-08-22
|
||||
Platform: Windows 11
|
||||
Host: Adobe Premiere Pro 2026
|
||||
Candidate: 1.13.0
|
||||
|
||||
## Scope
|
||||
|
||||
Validate the preview-only `preview_project_intake` tool through the installed
|
||||
CEP bridge without opening or modifying an existing editorial project.
|
||||
|
||||
## Setup
|
||||
|
||||
- Created a disposable empty Premiere project under the repository's ignored
|
||||
`test-results` directory.
|
||||
- Confirmed the project file was written (5,103 bytes).
|
||||
- Ran `node dist/index.js --diagnose-cep`; the installed connector passed its
|
||||
filesystem and configuration checks.
|
||||
- Did not open the existing recent project or import user media.
|
||||
|
||||
## Result
|
||||
|
||||
Blocked before MCP execution. Premiere became unresponsive while entering the
|
||||
editing workspace for the disposable project. The same behavior recurred after
|
||||
terminating only the hung Premiere process, restarting Premiere, and reopening
|
||||
only the disposable project. The CEP panel could not be opened, so no bridge
|
||||
command and no `preview_project_intake` call ran.
|
||||
|
||||
## Evidence boundary
|
||||
|
||||
- Connector installation diagnosis: passed.
|
||||
- Deterministic engine and MCP handler automated tests: passed in the release
|
||||
worktree.
|
||||
- Real Premiere/CEP tool execution: not demonstrated.
|
||||
- Project mutation, media import, render verification, save/reopen verification,
|
||||
and macOS host coverage: not performed.
|
||||
|
||||
This record is failure evidence for the host gate, not evidence that Project
|
||||
Intake works in Premiere 2026.
|
||||
|
||||
## 2026-08-23 follow-up
|
||||
|
||||
- Audited the public `v1.13.0` GitHub release connector before installation.
|
||||
Its SHA-256 was
|
||||
`583949dd0decd5ed91478ce3c39a75c67512b5b06ac6d1db712eb03ee9701bf7`,
|
||||
and its embedded CEP manifest reported `1.13.0`.
|
||||
- Installed that exact signed connector and confirmed the local installer
|
||||
diagnosis passed.
|
||||
- Adobe Premiere Pro 2026 opened the disposable project and rendered the empty
|
||||
editing workspace, but became unresponsive when the Window menu was invoked.
|
||||
No CEP panel command or MCP tool call completed.
|
||||
- Adobe Premiere Pro (Beta) opened the same fixture through its required
|
||||
conversion flow into a separate disposable copy. The converted project then
|
||||
stalled on a black editing canvas before the CEP panel could be opened.
|
||||
|
||||
The repeated host failure now covers the stable and Beta applications with the
|
||||
audited signed connector. It still does not demonstrate a
|
||||
`preview_project_intake` execution, and it does not justify a real-host support
|
||||
claim for this workflow.
|
||||
+557
@@ -0,0 +1,557 @@
|
||||
# Project Intake Assistant contract
|
||||
|
||||
**Contract ID:** `INDUSTRY-01`
|
||||
**Version:** `0.1.0-draft`
|
||||
**Status:** proposed product contract; not a production-readiness claim
|
||||
**Last reviewed against source tree:** 2026-08-22
|
||||
|
||||
## Purpose and implementation status
|
||||
|
||||
Project Intake Assistant is a bounded, assistant-editor workflow for inspecting
|
||||
media that is already in a Premiere project, proposing deterministic
|
||||
organization and metadata changes, applying only an approved subset, and
|
||||
recording what is known about the result. It is deliberately a workflow around
|
||||
existing MCP actions, not a claim that an AI can make editorial decisions.
|
||||
|
||||
There is **no current `project_intake` MCP tool, facility-template schema, or
|
||||
production-ready end-to-end intake workflow** in this repository. This document
|
||||
is the contract for building one. The current source provides useful, narrower
|
||||
building blocks:
|
||||
|
||||
- `verify_premiere_connection` is a read-only connection check that avoids
|
||||
returning project names, paths, and media details.
|
||||
- Authenticated UXP discovery is capability-gated at the connected host; a
|
||||
failed UXP command must not silently fall back to CEP or QE.
|
||||
- The authenticated UXP surface can inspect a compact revisioned project
|
||||
snapshot, Project-panel selection, bounded media health, proxy/ingest state,
|
||||
metadata, and project/Production storage state. It also has guarded project
|
||||
item organization and a reviewed organization-plan apply route.
|
||||
|
||||
Those are current source capabilities with their own limits, not evidence that
|
||||
they work in every licensed Premiere build. See the [supported-actions
|
||||
catalog](../supported-actions.md), [UXP capability foundation](../uxp-capability-foundation.md),
|
||||
[stable workflow matrix](../uxp-stable-workflows.md), and [editorial workflow
|
||||
host-validation runbook](../editorial-workflow-host-validation.md).
|
||||
|
||||
In this contract, **Current** means implemented in the source tree and
|
||||
documented at the linked repository reference. **Proposed** means a required
|
||||
addition for Project Intake; it must not be advertised as callable or
|
||||
production-ready until it passes the acceptance gates below.
|
||||
|
||||
## Scope
|
||||
|
||||
### In scope
|
||||
|
||||
The first implementation MUST support a selected, explicit set of project
|
||||
items in one connected project. It MAY propose only these classes of work when
|
||||
the connected host advertises the necessary capability:
|
||||
|
||||
1. Read-only readiness checks: connection, host capability, active-project
|
||||
identity, project snapshot revision, Project-panel selection, bounded media
|
||||
health, proxy/ingest state, metadata state, and storage preflight.
|
||||
2. Deterministic facility rules: expected bin destination, allowed color label,
|
||||
naming pattern, and allowlisted metadata fields.
|
||||
3. Review-only organization plans that identify exact project-item IDs and
|
||||
expected parent IDs.
|
||||
4. Explicitly approved bin creation, moves, color labels, and allowlisted
|
||||
metadata updates through documented UXP operations.
|
||||
5. A redacted operation receipt with per-operation certainty and recovery
|
||||
instructions.
|
||||
|
||||
The workflow MUST begin read-only. A template check whose required host field is
|
||||
not exposed by the selected capability MUST report `unsupported` or
|
||||
`not_inspected`; it MUST NOT be inferred as a pass.
|
||||
|
||||
Frame-rate evidence follows the same fail-closed rule. A non-finite or out-of-range
|
||||
host value becomes an item-level `FRAME_RATE_UNSUPPORTED` finding and makes the
|
||||
report incomplete; it does not abort inspection of unrelated items. Valid decimal
|
||||
readings are matched after snapping values within 0.005 fps of a canonical timebase,
|
||||
then using a maximum 0.05 fps tolerance for non-canonical Premiere measurements.
|
||||
Canonical rates such as 23.976 and 24 remain distinct.
|
||||
|
||||
### Non-goals
|
||||
|
||||
Project Intake v0.1 MUST NOT:
|
||||
|
||||
- choose story, selects, pacing, or any other editorial judgment;
|
||||
- import arbitrary files, scan disks, or treat a filesystem folder as the
|
||||
intake scope without a separate approved, workspace-gated import contract;
|
||||
- inspect codecs, frame rates, audio-channel layouts, timecode, duplicate
|
||||
media, or proxy completeness unless the exact source field and its real-host
|
||||
support are added to the capability matrix;
|
||||
- change a timeline, create a rough cut, replace media, relink media, attach a
|
||||
proxy, change ingest state, configure scratch disks, delete an item, or save
|
||||
a project as part of ordinary intake;
|
||||
- call a generative, transcription, translation, cloud-analysis, or media
|
||||
upload provider;
|
||||
- use filenames, a model guess, or a non-unique display name as mutation
|
||||
authority;
|
||||
- claim atomic cross-command rollback, visual correctness, rendered-output
|
||||
correctness, copyright clearance, or production readiness.
|
||||
|
||||
Some excluded operations are separately exposed by the current UXP surface
|
||||
(for example proxy attachment, relink, and storage configuration), but have
|
||||
their own confirmation, workspace, non-undo, or verification boundaries. They
|
||||
are intentionally outside this contract. See [supported actions](../supported-actions.md)
|
||||
and [local-first editorial workflow boundaries](../ai-editorial-workflows.md).
|
||||
|
||||
## Personas and authority model
|
||||
|
||||
| Actor | May do | Must not do |
|
||||
| --- | --- | --- |
|
||||
| Assistant editor (operator) | Select the intake scope, review findings, edit the proposed plan, approve or reject a concrete plan, inspect the receipt. | Approve a plan on behalf of another person or bypass a stale-plan check. |
|
||||
| Post supervisor (workflow owner) | Publish an approved template version, decide the permitted operation classes, review exceptions and pilot evidence. | Treat a receipt as proof of picture, sound, or delivery quality. |
|
||||
| Facility administrator | Configure local bridge installation, approved workspace policy, identity/role integration, and retention policy. | Put secrets, native paths, media names, or transcripts into persistent workflow checkpoints. |
|
||||
| MCP client / model | Request inspection and construct a plan strictly from the template and returned evidence. | Create its own template, self-approve, invent targets, or treat a recommendation as mutation authority. |
|
||||
| UXP bridge / Premiere host | Advertise capabilities, execute a documented operation, and return its command-specific readback. | Establish licensed-host validity, visual quality, or an unexposed postcondition by itself. |
|
||||
|
||||
**Proposed authority rule:** `inspect` requires read authority and an
|
||||
authenticated, connected host where UXP data is used. `plan` and `preview` are
|
||||
non-mutating. `confirm` requires an attributable human identity plus the exact
|
||||
plan digest. `apply` requires `edit` authority, a current host capability
|
||||
attestation, the same project identity/revision, and an unexpired confirmation.
|
||||
Only the UXP route is eligible for Project Intake mutations. CEP/QE fallback is
|
||||
forbidden even if a similarly named legacy action is available.
|
||||
|
||||
The existing reviewed organization route already uses server-issued plan and
|
||||
preview-confirmation material, stable source/parent guards, and UXP-only bin
|
||||
transactions; it reports partial completion instead of rolling back a prior
|
||||
bin creation. Project Intake MUST preserve those semantics rather than wrap
|
||||
them in an "all-or-nothing" claim. See [local-first editorial workflows](../ai-editorial-workflows.md)
|
||||
and [`apply_editorial_organization_plan`](../supported-actions.md).
|
||||
|
||||
## Required state machine
|
||||
|
||||
Each request has one immutable `requestId`; each planned mutation has a unique
|
||||
`operationId`. A state transition is append-only in the proposed receipt ledger.
|
||||
The only mutation state is **Apply**.
|
||||
|
||||
```text
|
||||
Inspect -> Plan -> Preview -> Confirm -> Apply -> Verify -> Receipt
|
||||
| | | |
|
||||
+-> Reject +-> Expire +-> Stop -+
|
||||
```
|
||||
|
||||
| State | Required behavior | Mutation allowed? |
|
||||
| --- | --- | --- |
|
||||
| **Inspect** | Verify the intended backend, collect only capability-supported evidence, resolve stable target IDs, and capture project/revision locks. | No |
|
||||
| **Plan** | Evaluate the immutable template against the inspection snapshot. Produce explicit findings and individual candidate operations. | No |
|
||||
| **Preview** | Re-inspect the target project and guards, calculate a canonical plan digest, show before/after intent and limitations, then issue an opaque confirmation token. | No |
|
||||
| **Confirm** | Record an identifiable human's explicit approval of the exact template version, plan digest, target project, and expiry. Any edit creates a new plan. | No |
|
||||
| **Apply** | Re-check host capability, project identity/revision, confirmation, and every operation guard immediately before dispatch. Execute bounded operations; do not auto-retry an uncertain commit. | Yes, only the approved operations |
|
||||
| **Verify** | Reinspect the exact host state exposed for each completed operation. Classify each result with a certainty state; stop on an unknown mutation or policy-defined failure. | No new mutation |
|
||||
| **Receipt** | Persist or return a privacy-redacted, append-only record of the plan, approvals, results, certainty, evidence references, and recovery instructions. | No |
|
||||
|
||||
### Preconditions and stop conditions
|
||||
|
||||
The workflow MUST stop before mutation when any of the following is true:
|
||||
|
||||
- no active authenticated UXP bridge or the required command is not advertised;
|
||||
- the selected project cannot be identified by a stable host project ID/GUID;
|
||||
- the active project changed after Inspect or Preview;
|
||||
- the current project/context revision differs from the preview lock;
|
||||
- the template version/digest, plan digest, confirmation token, operator
|
||||
identity, or policy scope differs from the approved value;
|
||||
- any target resolves to zero or multiple project items, or lacks an expected
|
||||
parent guard for a move;
|
||||
- a confirmation expires, is rejected, or is not attributable to a human;
|
||||
- an operation would be outside the template's permitted operation types or
|
||||
metadata allowlist.
|
||||
|
||||
The current project-context and editorial-plan foundations already reject stale
|
||||
context/timeline revisions and keep review receipts separate from mutation
|
||||
authority. Their snapshot is a useful input, but it does not prove that the
|
||||
live host stayed unchanged; Project Intake therefore MUST re-inspect the host
|
||||
immediately before Apply. See [project-context invalidation](../project-context-engine.md)
|
||||
and [editorial-plan workflow](../ai-editorial-workflows.md).
|
||||
|
||||
## Stable IDs, revision locks, and digests
|
||||
|
||||
### Current identifiers to reuse
|
||||
|
||||
- **Host project identity:** use the UXP project GUID/ID returned by the
|
||||
revisioned project snapshot or project-session surface. Do not substitute a
|
||||
project name or path.
|
||||
- **Project-item identity:** use the UXP Project-panel item ID. A display name
|
||||
may appear in preview copy but is never a mutation selector.
|
||||
- **Parent identity:** every move records the exact `expectedParentId` from
|
||||
inspection and must fail if it changed before dispatch.
|
||||
- **Host snapshot revision:** retain the `project.snapshot` revision from the
|
||||
same inspection pass as the resolved IDs.
|
||||
- **Context revisions:** if local project context is used, retain its source,
|
||||
timeline, and combined context revisions separately. The current context
|
||||
engine hashes persisted project/media-path identities, and distinguishes a
|
||||
source change from a timeline-placement change.
|
||||
|
||||
The current project snapshot and Project-panel selection resolver are bounded
|
||||
host reads; the current organization operations use stable project-item and
|
||||
parent guards. See [UXP capability foundation](../uxp-capability-foundation.md),
|
||||
[next-ten workflow matrix](../uxp-next-ten-workflows.md), and [project context
|
||||
engine](../project-context-engine.md).
|
||||
|
||||
### Proposed locking algorithm
|
||||
|
||||
1. Inspect the explicitly selected project/items and capture `hostProjectId`,
|
||||
`hostSnapshotRevision`, `selectedItemIds`, and each selected item's current
|
||||
parent ID.
|
||||
2. Canonicalize the approved template, the plan, and the selected target list
|
||||
using deterministic key ordering and UTF-8 JSON. Compute SHA-256 digests
|
||||
for the template and plan.
|
||||
3. Bind the preview confirmation to the host project ID, snapshot revision,
|
||||
template digest, plan digest, capability-attestation ID, operator identity,
|
||||
and expiry.
|
||||
4. Immediately before each operation, reacquire the minimal relevant host
|
||||
state. Reject a changed project ID, stale snapshot/revision, missing
|
||||
capability, changed parent, changed metadata guard, or changed selection.
|
||||
5. Use a unique `operationId` for every host mutation. An operation that times
|
||||
out or loses the bridge after dispatch is **not** repeated automatically;
|
||||
it must be inspected before a human decides whether to create a new plan.
|
||||
|
||||
The digest and attestation binding are proposed. The repository already uses
|
||||
opaque confirmation tokens and revision-locked previews in its editorial
|
||||
workflow, while the proposed metadata batch planner calls for an exact project
|
||||
revision, plan digest, per-item certainty, and no retry of unknown commits.
|
||||
See [editorial workflow](../ai-editorial-workflows.md) and [metadata batch planner
|
||||
recommendation](../recommendations/2026-08-18-round-2/38-metadata-batch-planner.md).
|
||||
|
||||
## Contract schemas
|
||||
|
||||
The following are proposed JSON contract shapes. They are intentionally
|
||||
separate from existing individual MCP tool schemas. They use synthetic IDs and
|
||||
contain no native paths, real project names, media names, prompts, transcript
|
||||
content, or credentials.
|
||||
|
||||
### Intake request
|
||||
|
||||
```json
|
||||
{
|
||||
"schemaVersion": "project-intake-request/v0.1",
|
||||
"requestId": "pi-20260822-0001",
|
||||
"template": {
|
||||
"id": "documentary-intake",
|
||||
"version": "3.2.0",
|
||||
"sha256": "sha256:<template-digest>",
|
||||
"permittedOperations": ["create_bin", "move_item", "set_color", "update_metadata"],
|
||||
"organizationRules": [
|
||||
{
|
||||
"ruleId": "interview",
|
||||
"destination": { "parentBinId": "bin-root", "name": "Interviews", "colorIndex": 4 },
|
||||
"match": { "mode": "operator-selected-only" }
|
||||
}
|
||||
],
|
||||
"metadataAllowlist": ["project.description", "xmp.dc:subject"]
|
||||
},
|
||||
"scope": {
|
||||
"hostProjectId": "project-guid-redacted",
|
||||
"projectViewId": "view-redacted",
|
||||
"selectedProjectItemIds": ["item-redacted-01", "item-redacted-02"]
|
||||
},
|
||||
"policy": {
|
||||
"id": "facility-default",
|
||||
"version": "1",
|
||||
"requireHumanConfirmation": true,
|
||||
"allowPersistentContext": false
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Validation requirements: the template is immutable/versioned; IDs are unique;
|
||||
the scope contains at least one exact host item ID; every metadata key is
|
||||
allowlisted; and the caller cannot widen the template's operation set. A rule
|
||||
using a semantic filename match is outside v0.1. The existing organization plan
|
||||
requires caller-supplied rules and deliberately does not infer categories from
|
||||
filenames; this contract keeps the same safety posture. See [local-first
|
||||
editorial workflows](../ai-editorial-workflows.md).
|
||||
|
||||
### Inspection and proposed plan
|
||||
|
||||
```json
|
||||
{
|
||||
"schemaVersion": "project-intake-plan/v0.1",
|
||||
"requestId": "pi-20260822-0001",
|
||||
"state": "preview",
|
||||
"binding": {
|
||||
"hostProjectId": "project-guid-redacted",
|
||||
"hostSnapshotRevision": "uxp-redacted",
|
||||
"templateSha256": "sha256:<template-digest>",
|
||||
"capabilityAttestationId": "proposed-attestation-id"
|
||||
},
|
||||
"findings": [
|
||||
{
|
||||
"findingId": "finding-01",
|
||||
"kind": "organization",
|
||||
"status": "actionable",
|
||||
"targetId": "item-redacted-01",
|
||||
"evidence": { "expectedParentId": "bin-root" },
|
||||
"message": "Selected item is approved for the configured destination."
|
||||
},
|
||||
{
|
||||
"findingId": "finding-02",
|
||||
"kind": "codec",
|
||||
"status": "unsupported",
|
||||
"message": "No Project Intake codec-field capability is implemented in this contract version."
|
||||
}
|
||||
],
|
||||
"operations": [
|
||||
{
|
||||
"operationId": "pi-op-01",
|
||||
"type": "move_item",
|
||||
"target": { "projectItemId": "item-redacted-01", "expectedParentId": "bin-root" },
|
||||
"destination": { "binId": "bin-interviews" },
|
||||
"expectedPostcondition": { "parentId": "bin-interviews" },
|
||||
"authority": "human-confirmed-edit"
|
||||
}
|
||||
],
|
||||
"limitations": [
|
||||
"Host readback establishes only exposed structural fields.",
|
||||
"No render, playback, or editorial-quality verification is included."
|
||||
],
|
||||
"planSha256": "sha256:<plan-digest>",
|
||||
"confirmation": { "required": true, "expiresAt": "2026-08-22T20:00:00Z" }
|
||||
}
|
||||
```
|
||||
|
||||
Every finding MUST say whether it is `pass`, `actionable`, `warning`,
|
||||
`unsupported`, `not_inspected`, or `blocked`; absence of a finding is never a
|
||||
pass. Every mutation operation MUST provide an exact stable target, precondition,
|
||||
expected postcondition, authority class, and recovery instruction. The
|
||||
`capabilityAttestationId` is proposed: the existing recommendation describes a
|
||||
nonce-bound, short-lived host capability attestation, but it is not a current
|
||||
production feature. See [host capability attestation recommendation](../recommendations/2026-08-18-round-2/30-host-capability-attestation.md).
|
||||
|
||||
### Receipt
|
||||
|
||||
```json
|
||||
{
|
||||
"schemaVersion": "project-intake-receipt/v0.1",
|
||||
"receiptId": "pir-20260822-0001",
|
||||
"requestId": "pi-20260822-0001",
|
||||
"endedState": "receipt",
|
||||
"binding": {
|
||||
"hostProjectId": "project-guid-redacted",
|
||||
"hostSnapshotRevision": "uxp-redacted",
|
||||
"templateSha256": "sha256:<template-digest>",
|
||||
"planSha256": "sha256:<plan-digest>",
|
||||
"sourceCommit": "<40-character-source-sha>",
|
||||
"panelBuild": "<panel-build-hash>"
|
||||
},
|
||||
"approval": {
|
||||
"approvedBy": "operator-pseudonym-or-enterprise-user-id",
|
||||
"approvedAt": "2026-08-22T19:00:00Z",
|
||||
"confirmationId": "opaque-confirmation-token"
|
||||
},
|
||||
"operations": [
|
||||
{
|
||||
"operationId": "pi-op-01",
|
||||
"type": "move_item",
|
||||
"result": "structurally_verified",
|
||||
"verificationBoundary": "project_item_parent_readback",
|
||||
"evidenceRefs": ["redacted-host-response-ref"],
|
||||
"recovery": "Use Premiere Undo after visually confirming the item and destination."
|
||||
}
|
||||
],
|
||||
"summary": { "planned": 1, "applied": 1, "structurallyVerified": 1, "unknown": 0 },
|
||||
"privacy": { "nativePathsIncluded": false, "mediaNamesIncluded": false, "transcriptContentIncluded": false },
|
||||
"receiptSha256": "sha256:<canonical-receipt-digest>"
|
||||
}
|
||||
```
|
||||
|
||||
`receiptSha256` is a proposed integrity checksum, not a signature, C2PA claim,
|
||||
or proof that no later Premiere edit occurred. Receipt storage/transport and
|
||||
tamper-evident signing require a separate security design. The existing
|
||||
host-validation runbook requires redacted host facts, fixture checksum, before/
|
||||
after evidence, structured response, and Undo evidence for a passed mutation;
|
||||
Project Intake receipts SHOULD reference the same kind of evidence without
|
||||
embedding sensitive data. See [host-validation runbook](../editorial-workflow-host-validation.md).
|
||||
|
||||
## Result certainty
|
||||
|
||||
The receipt MUST report a result for the workflow and for every proposed
|
||||
operation. The following contract normalization is **proposed**; it maps current
|
||||
command-specific UXP outcomes without weakening their stated boundaries.
|
||||
|
||||
| Certainty | Meaning | Retry rule |
|
||||
| --- | --- | --- |
|
||||
| `planned` | No mutation was dispatched. | A new plan may be created. |
|
||||
| `rejected_before_mutation` | A validation, authority, freshness, or capability check stopped the operation before dispatch. | Correct the cause and start a new Inspect/Plan cycle. |
|
||||
| `committed_unverified` | Premiere accepted/committed the command, but the contract lacks a required readback for the requested effect. | Never retry automatically; inspect the host before a human decides next action. |
|
||||
| `structurally_verified` | The command-specific host readback matches the expected structural postcondition. | Do not retry; this is not visual, playback, or render proof. |
|
||||
| `render_verified` | A separately specified exported artifact was verified by the applicable output-file/render procedure. | Not emitted by ordinary v0.1 Project Intake operations. |
|
||||
| `partial` | At least one operation is structurally verified and a later operation did not complete or is uncertain. | Stop the remaining batch, inspect known changes, then create a new plan. |
|
||||
| `unknown_mutation` | Dispatch may have reached Premiere, but a timeout/disconnect/invalid response prevents knowing whether it changed state. | Do not retry; require host inspection and a fresh human decision. |
|
||||
| `failed` | The operation failed before a confirmed postcondition; the receipt must state whether mutation is known absent or unknown. | Follow the classified recovery instruction. |
|
||||
| `unsupported` / `not_run` | The capability or test evidence is absent. | Do not substitute another backend or a heuristic. |
|
||||
|
||||
Current UXP workflows already use command-specific readback and, for some
|
||||
operations, `committed_unverified`; the current organization route reports
|
||||
verified actions as `partial` if a later action fails and never silently rolls
|
||||
back or retries an unknown commit. Current `verified` is structured host
|
||||
readback, not licensed-host visual/render validation. See [third-wave workflow
|
||||
matrix](../third-wave-uxp-workflows.md), [editorial workflows](../ai-editorial-workflows.md),
|
||||
and [transaction deadline/readback recommendation](../recommendations/2026-08-18-round-2/32-transaction-deadline-readback.md).
|
||||
|
||||
## Failure taxonomy and recovery
|
||||
|
||||
| Code | Classification | Required receipt data and recovery |
|
||||
| --- | --- | --- |
|
||||
| `PI_CONNECTION_UNAVAILABLE` | `rejected_before_mutation` | Backend requested, connection-check result, and instruction to reconnect; no fallback mutation. |
|
||||
| `PI_CAPABILITY_MISSING` | `unsupported` | Required command and advertised capability set; leave the check unresolved. |
|
||||
| `PI_PROJECT_IDENTITY_CHANGED` | `rejected_before_mutation` | Expected/current redacted project IDs; restart Inspect. |
|
||||
| `PI_REVISION_STALE` | `rejected_before_mutation` | Expected/current revision fingerprints; restart Inspect and Preview. |
|
||||
| `PI_TEMPLATE_OR_PLAN_MISMATCH` | `rejected_before_mutation` | Template/plan digest identifiers only; obtain a new approval. |
|
||||
| `PI_CONFIRMATION_INVALID` | `rejected_before_mutation` | Non-sensitive reason: missing, expired, rejected, or wrong approver; do not dispatch. |
|
||||
| `PI_TARGET_AMBIGUOUS` | `rejected_before_mutation` | Candidate stable-ID count and rule ID; require the operator to reselect exact items. |
|
||||
| `PI_GUARD_FAILED` | `rejected_before_mutation` | Target ID and expected/current parent or field fingerprint; re-inspect instead of forcing a move. |
|
||||
| `PI_POLICY_DENIED` | `rejected_before_mutation` | Policy version and denied operation class; administrator/supervisor must change policy explicitly. |
|
||||
| `PI_WORKSPACE_DENIED` | `rejected_before_mutation` | Workspace access mode only; ordinary v0.1 scope should not need a path workaround. |
|
||||
| `PI_HOST_MODAL_OR_TIMEOUT` | `unknown_mutation` if dispatched, otherwise `rejected_before_mutation` | Last known phase and operation ID; inspect Premiere before retry. |
|
||||
| `PI_INVALID_HOST_READBACK` | `unknown_mutation` | Raw response stays redacted; stop the batch and inspect the stated target. |
|
||||
| `PI_PARTIAL_APPLY` | `partial` | Per-operation certainty, already changed IDs, remaining operations, and explicit Undo/manual recovery guidance. |
|
||||
| `PI_PRIVACY_VIOLATION` | `rejected_before_mutation` | Field class rejected, not its value; redact and create a new request. |
|
||||
|
||||
The implementation MUST preserve the last known state if Apply begins: preflight,
|
||||
dispatch, host return, and readback are distinct phases. It MUST NOT report a
|
||||
successful rollback merely because a later operation failed. This follows the
|
||||
current organization-plan and transaction/readback boundaries. See [editorial
|
||||
workflows](../ai-editorial-workflows.md) and [transaction deadline/readback
|
||||
recommendation](../recommendations/2026-08-18-round-2/32-transaction-deadline-readback.md).
|
||||
|
||||
## Privacy, data handling, and audit rules
|
||||
|
||||
### Contract rules (proposed)
|
||||
|
||||
1. Project Intake MUST be local-first by default. It MUST enumerate any network
|
||||
egress before a facility enables it and MUST not transmit footage, native
|
||||
paths, media names, transcript content, metadata values, prompts, or receipt
|
||||
bodies to telemetry or a model provider without a separately approved data
|
||||
path and retention policy.
|
||||
2. Receipts MUST use stable IDs or one-way/deliberately redacted identifiers;
|
||||
they MUST exclude native paths, media names, transcript content, raw metadata
|
||||
values, credentials, persistent workspace tokens, and full raw host events.
|
||||
3. Facility templates MUST be versioned and may contain rule IDs, field keys,
|
||||
and policy references. They MUST NOT contain secrets, production media paths,
|
||||
customer content, or hidden broad filesystem roots.
|
||||
4. Persistent state MUST be opt-in and deletable. The workflow MUST surface
|
||||
where it is stored, retention duration, and the clear action.
|
||||
5. The authoritative receipt is an operation record, not a training-data grant,
|
||||
provenance assertion, copyright determination, or productivity claim.
|
||||
|
||||
### Current constraints to honor
|
||||
|
||||
The current project-context engine is opt-in and local; it persists project
|
||||
names, hashed project/media-path identities, bounded timeline metadata, and
|
||||
explicit enrichments, while not persisting native paths. It also discards
|
||||
enrichment keys resembling paths, passwords, tokens, secrets, or API keys.
|
||||
Project Intake MUST obtain explicit operator consent before using that store and
|
||||
MUST clear it when the chosen retention policy requires it. See [project context
|
||||
storage rules](../project-context-engine.md).
|
||||
|
||||
The current UXP workspace access model returns neither the native workspace root
|
||||
nor persistent token over MCP, and current workflow checkpoints forbid secrets,
|
||||
paths, transcripts, and media names because persistent values may sync with
|
||||
cloud projects. Project Intake MUST not bypass either boundary. See [README UXP
|
||||
workspace policy](../../README.md) and [third-wave checkpoints](../third-wave-uxp-workflows.md).
|
||||
|
||||
## Host validation matrix
|
||||
|
||||
All cases below are **proposed Project Intake validation cases** and start as
|
||||
`not_run`. Unit, contract, lint, and mock-bridge tests may validate schemas and
|
||||
failure handling, but cannot mark a case licensed-host verified. Use a copied,
|
||||
disposable project with generated, non-sensitive fixture media; retain redacted
|
||||
responses, before/after Project-panel evidence, and Undo evidence. This extends
|
||||
the existing [editorial host-validation runbook](../editorial-workflow-host-validation.md).
|
||||
|
||||
| ID | Coverage | Procedure | Required pass evidence | Boundary retained |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| `PI-PLAN-001` | Each supported MCP client path on Windows and macOS | Inspect a fixture selection; create and preview a plan with one unsupported check. | No mutation; IDs/revision/digest present; unsupported check remains unresolved. | Does not prove host mutation. |
|
||||
| `PI-ORG-001` | Each claimed Premiere/UXP/OS combination | Create or resolve one bin, move one selected item, apply one color rule. | Exact stable IDs/parent/color readback, before/after Project-panel captures, and Undo restores fixture. | Structural UI state only; no editorial-quality claim. |
|
||||
| `PI-ORG-002` | Same as `PI-ORG-001` | Change the source parent after Preview. | Guard rejects before move; any earlier verified create is recorded as partial and manually undone. | No atomic rollback claim. |
|
||||
| `PI-META-001` | Each claimed Premiere/UXP/OS combination | Read and update one allowlisted metadata field, including Unicode and no-op cases. | Requested-field readback and Undo evidence. | Field readback does not validate an external asset-management system. |
|
||||
| `PI-MEDIA-001` | Each claimed Premiere/UXP/OS combination | Inspect offline/proxy health for 1, 64, and over-limit selections. | Bounded per-item receipt; no path disclosure without explicit approved request. | Does not establish real-media availability beyond exposed host state. |
|
||||
| `PI-PRODUCTION-001` | Project and Production fixture where the host advertises it | Run storage/ingest preflight without mutation. | Redacted preflight response and no project-state change. | Does not validate Production configuration mutation. |
|
||||
| `PI-FAULT-001` | Each claimed Premiere/UXP/OS combination | Disconnect/timeout after a dispatched fixture mutation; repeat with invalid readback. | `unknown_mutation`, no automatic retry, human inspection decision recorded. | Does not prove the prior command did or did not mutate. |
|
||||
| `PI-PRIVACY-001` | Windows and macOS | Attempt to place path, token-like, transcript, and media-name fields in template, receipt, and checkpoint inputs. | Rejection/redaction before persistence or output. | Does not prove third-party provider retention policy. |
|
||||
|
||||
Each report MUST include source commit, panel build hash, Premiere version, OS
|
||||
version, MCP client, fixture revision/checksum, case status, and evidence
|
||||
references. A case is `passed`, `failed`, `unsupported`, or `not_run`; a
|
||||
passing schema validator or an MCP response labeled `verified` is insufficient
|
||||
without human review of the exact host and post-state evidence. The repository
|
||||
now provides a separate, versioned
|
||||
`npm run validate:project-intake-host-report -- path/to/redacted-report.json`
|
||||
contract for this preview-only workflow. It accepts only the defined Project
|
||||
Intake cases, requires the documented non-mutation postconditions, and rejects
|
||||
project data from the shared evidence index. See the
|
||||
[Project Intake host-validation runbook](../project-intake-host-validation.md).
|
||||
|
||||
## Acceptance gates
|
||||
|
||||
These are proposed promotion gates. They are not met merely because this
|
||||
document exists or because current automated tests pass.
|
||||
|
||||
### Contract and implementation gate
|
||||
|
||||
- A versioned JSON schema validates request, plan, confirmation, receipt, and
|
||||
each failure/result state.
|
||||
- Tests prove no mutation is reachable from Inspect, Plan, Preview, Confirm,
|
||||
Verify, or Receipt.
|
||||
- Tests prove stale project/revision/template/plan/confirmation/parent guards
|
||||
fail before dispatch.
|
||||
- Tests prove duplicate or ambiguous targets, unallowlisted metadata, and
|
||||
forbidden operations fail before dispatch.
|
||||
- Tests prove a UXP failure never falls back to CEP/QE and an unknown commit is
|
||||
never automatically retried.
|
||||
- Tests prove receipts redact forbidden fields and capture per-item partial
|
||||
completion with last known phase.
|
||||
- Documentation lists every required host command, version/capability gate,
|
||||
postcondition, certainty boundary, and recovery instruction.
|
||||
|
||||
### Licensed-host pilot gate
|
||||
|
||||
- At least 100 documented, real-host Project Intake runs across every
|
||||
Premiere/OS/client combination claimed for the workflow, using the matrix
|
||||
above and the exact source/panel builds being considered.
|
||||
- Zero wrong-project or wrong-project-item mutations in those runs.
|
||||
- At least 99% of attempted supported operations reach their specified
|
||||
structural postcondition, with every exception classified and recoverable.
|
||||
- Every mutation has an attributable human confirmation, exact target IDs,
|
||||
before/after evidence, and Undo/manual-recovery evidence appropriate to the
|
||||
operation.
|
||||
- No failed or disconnected apply is labeled successful without the required
|
||||
readback; no automatic retry follows an uncertain dispatch.
|
||||
- At least two design-partner teams repeat the workflow after supervised use.
|
||||
Any time-saving claim is based on recorded baseline and assisted durations,
|
||||
sample size, and rework—not an estimate.
|
||||
|
||||
### Security and release gate
|
||||
|
||||
- The deployment mode, model routing, network egress, identity/role behavior,
|
||||
audit retention/deletion, update channel, and emergency revocation path are
|
||||
documented and accepted by the pilot facility.
|
||||
- The signed build and source/panel hashes in every receipt are reproducible.
|
||||
- A privacy review confirms that templates, context, telemetry, receipts, and
|
||||
host reports follow the rules in this contract.
|
||||
- Marketing says "proposed," "pilot," "licensed-host verified for listed
|
||||
combinations," or "unsupported" as applicable; it never extrapolates a
|
||||
successful fixture run to all productions.
|
||||
|
||||
Until every applicable gate is met, Project Intake is an implementation/pilot
|
||||
workflow only. Current automated coverage and command-specific UXP readback are
|
||||
valuable engineering evidence, but remain separate from licensed-host and
|
||||
rendered-output evidence. See [verification matrix](../ai-editorial-workflows.md)
|
||||
and [reproducible live-host lab recommendation](../recommendations/2026-08-18/17-live-host-lab.md).
|
||||
|
||||
## Implementation checklist
|
||||
|
||||
1. Add the proposed schemas and a canonical-digest implementation without
|
||||
changing existing individual tool semantics.
|
||||
2. Add a read-only `inspect` and `plan` path first; report unavailable checks
|
||||
explicitly rather than adding heuristics.
|
||||
3. Reuse the existing reviewed UXP organization route for a narrow first apply
|
||||
adapter; do not expose direct raw bin operations as the guided workflow.
|
||||
4. Add metadata only after a separate exact field allowlist, readback mapping,
|
||||
and host tests exist.
|
||||
5. Add confirmation/receipt persistence behind an explicit privacy and identity
|
||||
design; do not put receipt bodies in cloud-synced workflow checkpoints.
|
||||
6. Run the host matrix and preserve redacted evidence before widening the
|
||||
supported-version statement.
|
||||
+502
@@ -0,0 +1,502 @@
|
||||
# Security and design-partner pilot for professional post-production
|
||||
|
||||
## Purpose and status
|
||||
|
||||
This document defines a proposed 60-day design-partner pilot for a narrowly
|
||||
scoped **Project Intake Assistant**. It is intended for Premiere-based post
|
||||
teams that want to test reviewed project inspection and organization workflows
|
||||
without delegating creative authorship or uncontrolled access to production
|
||||
media.
|
||||
|
||||
The pilot is a product-discovery and evidence-gathering activity. It is **not**
|
||||
a security certification, legal advice, a TPN assessment, a claim of
|
||||
production readiness, or permission to process a customer's media. A facility
|
||||
must approve its own data, labor, clearance, security, and retention policies
|
||||
before participating.
|
||||
|
||||
Terms in this document are deliberately distinct:
|
||||
|
||||
- **Current repository behavior** is grounded in linked implementation and
|
||||
documentation evidence.
|
||||
- **Pilot requirement** is a condition for participating in the proposed
|
||||
program.
|
||||
- **Proposal** is a future product or operating control that is not represented
|
||||
as implemented until it has code, tests, and licensed-host evidence.
|
||||
|
||||
## Evidence basis and present boundaries
|
||||
|
||||
The repository documents a recommended local `stdio` deployment in which the
|
||||
MCP client, server, Premiere connector, and host run on the same computer. The
|
||||
CEP bridge uses a private per-user temporary directory; the optional UXP bridge
|
||||
listens only on `127.0.0.1` and authenticates its WebSocket connection. See the
|
||||
[local setup and security guidance](../../README.md#security) and the
|
||||
[UXP bridge transport contract](../../uxp-plugin/README.md#mcp-side-transport).
|
||||
|
||||
The current project-context store is local and opt-in. It persists bounded
|
||||
metadata and hashed project/media-path identities, not native project or media
|
||||
paths, but it can persist explicit enrichment content when an MCP client asks
|
||||
it to do so. Its storage boundary does not make an AI client or model provider
|
||||
private. See the [project-context engine](../project-context-engine.md) and the
|
||||
[context-retention proposal](../recommendations/2026-08-18-round-2/36-context-retention-policy.md).
|
||||
|
||||
The repository also supports a network-reachable HTTP transport, but it binds
|
||||
to `0.0.0.0`, requires bearer authentication in production, and is not a safe
|
||||
default for a shared post facility without identity-aware edge controls. It is
|
||||
therefore excluded from the pilot baseline. The existing UXP manifest declares
|
||||
`network.domains: "all"` for Premiere compatibility, even though the panel CSP
|
||||
and its workspace validator restrict the configured bridge to loopback URLs.
|
||||
That broad declared permission is a material installation-review issue, not a
|
||||
claim that the current panel can be accepted by every facility policy.
|
||||
|
||||
Existing code and documentation distinguish host responses and structural
|
||||
readback from playback or rendered-output proof. Automated checks do not prove
|
||||
that a licensed Premiere host created, displayed, saved, or undid an item. See
|
||||
the [licensed-host validation runbook](../editorial-workflow-host-validation.md)
|
||||
and the [sequence-sandbox proposal](../recommendations/2026-08-18-round-2/39-sequence-sandbox-verification.md).
|
||||
|
||||
## Pilot scope
|
||||
|
||||
The initial pilot is limited to this workflow:
|
||||
|
||||
1. Inspect an explicitly selected project and selected incoming media.
|
||||
2. Compare it with a facility-approved intake template.
|
||||
3. Produce a read-only issue report and an exact proposed organization plan.
|
||||
4. Let an authorized human review, edit, reject, or approve the plan.
|
||||
5. Apply only supported, explicitly approved organization actions.
|
||||
6. Reinspect the affected targets and create a content-free operation receipt.
|
||||
|
||||
The following are out of scope for all pilot stages unless a later, separately
|
||||
approved protocol says otherwise:
|
||||
|
||||
- autonomous editorial or story decisions;
|
||||
- background monitoring of projects or storage;
|
||||
- arbitrary ExtendScript or expression execution;
|
||||
- generative video, audio, voice, face, performance, or final-production
|
||||
media;
|
||||
- unreviewed external review, asset-management, delivery, or transcription
|
||||
integrations;
|
||||
- automated source-to-sequence transcript cutting, rendered-output claims, and
|
||||
production turnover claims; and
|
||||
- shared remote MCP control planes, shared bearer tokens, or public endpoints.
|
||||
|
||||
## Local-first pilot topology
|
||||
|
||||
The proposed baseline keeps control and operational evidence inside the
|
||||
facility-managed workstation or network boundary. It does not make claims about
|
||||
what an independently chosen AI client, operating system, Adobe service, or
|
||||
network appliance does with data.
|
||||
|
||||
```text
|
||||
Facility-controlled workstation
|
||||
|
||||
Approved MCP client
|
||||
| stdio only
|
||||
v
|
||||
Premiere Pro MCP server --------> local project-context store (opt-in)
|
||||
| |
|
||||
| private local IPC | facility retention policy
|
||||
v v
|
||||
CEP connector / authenticated UXP loopback bridge
|
||||
|
|
||||
v
|
||||
Licensed Premiere Pro and operator-selected workspace
|
||||
|
||||
No pilot-default Internet egress from the MCP server or connector.
|
||||
No remote HTTP/SSE transport. No vendor analytics key. No external model call
|
||||
from the workflow pack.
|
||||
```
|
||||
|
||||
### Pilot requirements
|
||||
|
||||
- Run the MCP server locally over `stdio`; keep the MCP client, server,
|
||||
connector, and Premiere host on the same facility-managed machine.
|
||||
- Do not start `http-server`, deploy the pilot workflow to Fly.io, configure
|
||||
`MCP_AUTH_TOKEN`, or expose a bridge directory through a sync agent, proxy,
|
||||
or VPN as part of the pilot.
|
||||
- Use a dedicated pilot configuration with `POSTHOG_API_KEY` unset. The pilot
|
||||
administrator must record that setting in the installation evidence.
|
||||
- Use only a facility-approved MCP client and model-routing configuration. The
|
||||
client must be able to keep prompts, tool arguments, transcript text, media
|
||||
names, project names, and local paths inside the facility's approved data
|
||||
boundary. If that cannot be shown, use synthetic fixtures only.
|
||||
- Review the exact connector package hash, server package version, and UXP
|
||||
manifest before installation. A facility that cannot accept the current
|
||||
broad UXP network declaration must not enable the UXP route in the pilot.
|
||||
- Grant the UXP panel one operator-selected workspace only. Treat workspace
|
||||
containment as a bridge policy rather than an operating-system sandbox, and
|
||||
do not use a workspace that includes unrelated productions.
|
||||
- Default to read-only inspection. Run application only through the guarded
|
||||
organization path after the named approver reviews an unstale plan.
|
||||
|
||||
## Egress inventory
|
||||
|
||||
This inventory is deliberately conservative. It records known paths in the
|
||||
repository and the pilot disposition; it is not a substitute for a facility's
|
||||
endpoint monitoring and package review.
|
||||
|
||||
| Surface | Current repository behavior | Pilot disposition | Data permitted to leave the workstation |
|
||||
| --- | --- | --- | --- |
|
||||
| MCP client to local server | Local `stdio` is the recommended path. The repository does not control the client or model provider selected by a facility. | Allowed only after the facility approves the specific client and model route. | Only what the approved client is authorized to process; this document makes no assumption that the client is private. |
|
||||
| Server to CEP connector | Local file-based IPC in a private per-user bridge directory. | Allowed. Keep both processes on the same workstation and do not sync the directory. | None off-workstation. |
|
||||
| Server to UXP panel | Authenticated WebSocket on `127.0.0.1`; panel CSP and runtime URL validation allow loopback URLs. | Allowed only after manifest review and an accepted workspace permission. | None off-workstation. |
|
||||
| Project-context store | Local application-data store; opt-in capture; paths are hashed before persistence. Explicit enrichments may contain user-provided text. | Allowed only in a customer-controlled encrypted-at-rest location with an approved retention setting. | None by the server itself. |
|
||||
| PostHog telemetry | Disabled unless `POSTHOG_API_KEY` is configured. When enabled, code records bounded operational events and disables person profiles. | Prohibited. Leave the key unset and verify no telemetry host is configured. | None. |
|
||||
| HTTP/SSE MCP transport | Optional, network-reachable server route with bearer authentication and rate limits. | Prohibited. Do not start it or route it through a tunnel, proxy, sync agent, or remote host. | None. |
|
||||
| Adobe cloud features | The repository exposes capability reporting and, in limited cases, observation after an editor uses a Premiere feature. It does not make current MCP calls to initiate Adobe generative features. | Excluded from the workflow. Any Adobe network feature remains an independent customer/Adobe relationship. | None through this pilot workflow. |
|
||||
| C2PA soft-binding inspection | A read-only, separately consented external-inspection lab is proposed, not a stable pilot action. | Prohibited. | None. |
|
||||
|
||||
Before each pilot stage, the facility administrator records the package hashes,
|
||||
environment-variable names and whether set, enabled transports, the selected
|
||||
MCP client, and observed outbound destinations. The record must contain no
|
||||
tokens, prompts, local paths, project names, or media names.
|
||||
|
||||
## Telemetry and content-handling rules
|
||||
|
||||
The existing optional PostHog implementation documents a bounded event contract:
|
||||
operational events may include a method, tool name, outcome, status code, and
|
||||
duration; it excludes authentication tokens, IP addresses, MCP arguments,
|
||||
project paths, media names, tool results, and person profiles. That is useful
|
||||
implementation evidence, but the design-partner baseline is stricter: no vendor
|
||||
telemetry is enabled.
|
||||
|
||||
The pilot must not collect, transmit, or place in shared pilot reports:
|
||||
|
||||
- video, audio, stills, proxies, exports, render frames, checksums that can be
|
||||
used to retrieve content, or raw file contents;
|
||||
- project, Production, sequence, bin, clip, media, storage-root, user, client,
|
||||
production, or facility names;
|
||||
- native paths, workspace tokens, bridge tokens, credentials, IP addresses,
|
||||
device identifiers, browser storage, or authentication headers;
|
||||
- prompts, tool arguments, tool results, editor notes, raw transcript text,
|
||||
shot descriptions, dialogue, captions, review notes, or metadata values;
|
||||
- face, voice, performance, biometric, likeness, talent, clearance, or labor
|
||||
information; and
|
||||
- persistent cross-facility identifiers or behavioral profiles.
|
||||
|
||||
**Proposal — content-free pilot measurements.** Use locally generated,
|
||||
rotating participant and project aliases; retain the alias mapping only inside
|
||||
the facility. Share aggregates such as stage, host version, action class,
|
||||
result certainty, elapsed duration band, and issue category. A shared report
|
||||
must redact or omit any field that could identify a production or reconstruct a
|
||||
request.
|
||||
|
||||
## Roles and approvals
|
||||
|
||||
The pilot does not give an AI client independent authority. One person may hold
|
||||
multiple roles only if the facility explicitly accepts that separation-of-duty
|
||||
risk.
|
||||
|
||||
| Role | Responsibilities | May approve |
|
||||
| --- | --- | --- |
|
||||
| Facility administrator | Installs approved packages, confirms local-only configuration, controls access and revocation, and keeps the egress record. | Enrollment, configuration changes, and any exception to the local-first baseline. |
|
||||
| Workflow owner / post supervisor | Converts an existing intake SOP into a versioned pilot template, defines expected outputs, and reviews pilot outcomes. | Template changes and promotion between pilot stages. |
|
||||
| Assistant editor | Selects the intended project/media, reviews issues and proposed actions, and performs or witnesses the workflow. | Read-only runs and submission of a plan for approval. |
|
||||
| Editor or designated post approver | Retains editorial judgment and confirms that a specific plan may modify the identified project targets. | Each mutating plan; a separate confirmation for non-undoable action. |
|
||||
| Security/privacy reviewer | Reviews model route, telemetry state, permissions, retention, and incident evidence. | Any data-flow exception, use of cleared active-project media, and case-study release. |
|
||||
| Pilot evidence reviewer | Checks redaction, host facts, post-state evidence, and claim wording. | A result may be counted toward a published case study. |
|
||||
|
||||
### Approval contract for a mutation
|
||||
|
||||
For each application attempt, the system and pilot record must present:
|
||||
|
||||
1. the project and target identities as aliases plus a facility-local lookup;
|
||||
2. the captured project/context revision and plan digest;
|
||||
3. the exact proposed creates, moves, labels, or metadata actions;
|
||||
4. action-level undoability and known verification boundary;
|
||||
5. the approving human, time, and expiration; and
|
||||
6. the post-operation readback and result certainty.
|
||||
|
||||
The pilot must reject a stale plan, ambiguous target, expired approval, changed
|
||||
project, unavailable host capability, missing bridge authentication, or unknown
|
||||
workspace authority. It must never automatically retry a mutation after an
|
||||
uncertain commit. A partial result is a visible outcome, not a successful batch.
|
||||
|
||||
**Proposal — two-person gate.** Require both the assistant editor and the
|
||||
designated post approver for a plan that crosses projects, writes outside the
|
||||
expected intake bins, affects more than the facility-defined batch limit, or
|
||||
contains a non-undoable action. No role may approve an `unsafe-script` action
|
||||
in this pilot because that authority remains out of scope.
|
||||
|
||||
## Generative-media separation
|
||||
|
||||
Generative operations require their own data, rights, talent, labor, clearance,
|
||||
and provenance review. They are not an extension of ordinary project
|
||||
organization.
|
||||
|
||||
The design-partner pilot therefore:
|
||||
|
||||
- does not invoke or ask an AI service to synthesize video, stills, dialogue,
|
||||
music, sound effects, voice, face, performance, captions, or metadata;
|
||||
- does not send source material, transcripts, likenesses, or performance data
|
||||
to a generative provider;
|
||||
- does not claim that a Premiere-generated item is cleared, human-authored,
|
||||
licensed, factual, or authentic;
|
||||
- may inspect an already-existing item only as an ordinary project/timeline
|
||||
item, without treating inspection as evidence of provenance; and
|
||||
- keeps any future generative experiment in a separate feature flag, consent
|
||||
record, approved data route, rights/clearance review, and visibly labeled
|
||||
output path.
|
||||
|
||||
The current repository similarly reports generative features as user-assisted
|
||||
or unavailable rather than presenting a stable MCP generation operation. The
|
||||
proposed C2PA inspection lab is read-only, disabled by default, and explicitly
|
||||
does not make an authenticity verdict. See
|
||||
[advanced feature boundaries](../../README.md#collaboration-and-ai-feature-boundaries)
|
||||
and the [C2PA inspection proposal](../recommendations/2026-08-19-round-3/48-c2pa-inspection-lab.md).
|
||||
|
||||
## Audit, receipts, and retention
|
||||
|
||||
The immediate audit record is an operational receipt, not a surveillance log
|
||||
and not a claim that a rendered result is correct. Existing guidance already
|
||||
distinguishes bounded, redacted event receipts and licensed-host evidence from
|
||||
visual or render verification.
|
||||
|
||||
**Proposal — minimum receipt fields.** Store the following in a facility-owned
|
||||
location with access limited to the pilot roles:
|
||||
|
||||
```json
|
||||
{
|
||||
"receiptVersion": "1",
|
||||
"pilotRunAlias": "facility-local alias",
|
||||
"workflowPackVersion": "version or source commit",
|
||||
"host": {
|
||||
"os": "Windows or macOS",
|
||||
"premiereVersion": "observed version",
|
||||
"connectorBuild": "build hash",
|
||||
"backend": "cep or uxp"
|
||||
},
|
||||
"plan": {
|
||||
"digest": "hash of the reviewed plan",
|
||||
"capturedRevision": "facility-local revision alias",
|
||||
"actionCounts": { "inspect": 0, "create": 0, "move": 0, "label": 0 }
|
||||
},
|
||||
"approval": { "approverRole": "post_approver", "expiresAt": "timestamp" },
|
||||
"result": {
|
||||
"state": "planned | rejected_before_mutation | committed_unverified | structurally_verified | render_verified",
|
||||
"perAction": "content-free statuses only",
|
||||
"undoChecked": false
|
||||
},
|
||||
"evidence": ["facility-controlled redacted evidence reference"]
|
||||
}
|
||||
```
|
||||
|
||||
No receipt may include raw targets, names, paths, prompt content, transcript
|
||||
text, token values, or media-derived content. `render_verified` must remain
|
||||
unused for Project Intake unless a documented render-specific procedure is
|
||||
separately run; a successful API response or property readback is not enough.
|
||||
|
||||
**Proposal — retention rule.** Default receipt retention to 30 days for the
|
||||
pilot, with a facility-selected shorter period where required. Keep only
|
||||
aggregated, fully de-identified measurement results after deletion. Deletion
|
||||
must remove primary and derived local pilot records and produce a content-free
|
||||
deletion receipt. Do not retain a transcript or enrichment merely because a
|
||||
receipt exists. The 30-day interval is an operational starting point, not a
|
||||
legal retention recommendation.
|
||||
|
||||
## TPN-readiness framing
|
||||
|
||||
TPN readiness is a useful way to organize a facility-security conversation, but
|
||||
this repository and pilot do **not** claim TPN membership, assessment, approval,
|
||||
certification, endorsement, or compliance.
|
||||
|
||||
**Proposal — readiness evidence pack.** Before a facility considers a formal
|
||||
third-party assessment, map the pilot's evidence to questions a content-security
|
||||
review commonly asks:
|
||||
|
||||
- asset and data-flow inventory, including each outbound destination and the
|
||||
proof that the default pilot has none;
|
||||
- package origin, build hash, signing/distribution method, dependency inventory,
|
||||
update owner, and revocation/rollback procedure;
|
||||
- individual identities, least privilege, approval records, secret handling,
|
||||
workstation access controls, and offboarding;
|
||||
- network architecture, firewall/egress rules, remote-support policy, logging
|
||||
boundaries, incident escalation, and evidence preservation;
|
||||
- encryption, facility-selected storage and backup policy, retention/deletion,
|
||||
vendor/model review, and subcontractor exclusions; and
|
||||
- security test results, licensed-host validation reports, known limitations,
|
||||
and remediation ownership.
|
||||
|
||||
This pack should identify gaps plainly. A completed checklist is readiness
|
||||
evidence for a future review, not a substitute for the requirements or decision
|
||||
of a studio, facility, insurer, customer, or TPN assessor.
|
||||
|
||||
## Design-partner recruitment
|
||||
|
||||
Recruit three to five Premiere-based teams. The first cohort should favor teams
|
||||
whose intake work is frequent, documented, and structurally verifiable:
|
||||
|
||||
- documentary, unscripted, interview-heavy, trailer/promotional, branded, or
|
||||
independent-feature post teams;
|
||||
- approximately three to twenty editorial users, with at least one working
|
||||
assistant editor and one empowered post supervisor;
|
||||
- a licensed Premiere installation that the facility may use for controlled
|
||||
fixture and duplicate-project tests on a supported operating system;
|
||||
- a real intake SOP containing naming, bin, label, metadata, proxy, and
|
||||
exception rules that can be expressed without story judgment;
|
||||
- a technical/security contact who can approve the client/model route and
|
||||
local-only setup; and
|
||||
- willingness to measure a manual baseline, run supervised sessions, report
|
||||
failures, and decline to use the workflow when its evidence is insufficient.
|
||||
|
||||
Exclude a candidate from the first cohort if it requires public remote access,
|
||||
cannot disable telemetry, needs generated media, expects autonomous editing,
|
||||
cannot use duplicate or cleared project material for early stages, or cannot
|
||||
assign a named approver.
|
||||
|
||||
## Proposed 60-day pilot stages
|
||||
|
||||
| Stage | Days | Allowed material and actions | Required exit evidence |
|
||||
| --- | ---: | --- | --- |
|
||||
| 0. Enrollment and threat review | 1–7 | No project actions. Review SOP, model route, installation package, permissions, topology, retention, roles, and stop procedure. | Signed facility-local pilot charter; egress inventory; template v1; named roles; baseline measurement plan. |
|
||||
| 1. Fixture rehearsal | 8–21 | Generated or non-sensitive fixture media only. Read-only reports first, then one-action organization tests in disposable copied projects. | At least ten runs per team; redacted before/after/Undo evidence for each mutation; no unapproved egress. |
|
||||
| 2. Duplicate-project validation | 22–42 | Completed, cleared, or duplicate projects approved by the facility. Apply only approved bin, move, label, and metadata operations. | At least twenty additional runs per team; stale-plan/ambiguous-target/host-disconnect drills; per-action structural readback and recovery evidence. |
|
||||
| 3. Supervised operational trial | 43–60 | Facility-approved active-project intake only if the security reviewer authorizes it. Human approval remains mandatory; no generative or remote integration. | Repeated voluntary use, baseline comparison, unresolved-risk register, and an evidence-reviewed end-of-pilot decision. |
|
||||
|
||||
The transition to a later stage requires the workflow owner and security/privacy
|
||||
reviewer to accept the prior-stage evidence. Failure to meet a target does not
|
||||
justify changing the evidence definition or silently broadening a claim.
|
||||
|
||||
## Metrics and decision gates
|
||||
|
||||
Measure both benefit and safety. All measurements must use facility-local
|
||||
aliases and time bands or aggregates; do not export content-bearing logs.
|
||||
|
||||
| Category | Metric | Interpretation boundary |
|
||||
| --- | --- | --- |
|
||||
| Reliability | Completed runs / attempted runs; structurally verified actions / approved actions; partial/unknown results | Counts host and workflow outcomes, not editorial correctness or render quality. |
|
||||
| Targeting safety | Wrong-project, wrong-sequence, wrong-item, stale-plan, and approval-bypass events | Any wrong-target mutation is a stop condition, not an acceptable error rate. |
|
||||
| Recoverability | Undo/recovery success, time to identify uncertainty, time to restore fixture state | Recovery in a fixture does not prove recovery for every production condition. |
|
||||
| Human control | Plan edit/rejection rate, approval rate, approver identity coverage, and unapproved-action count | A high rejection rate may reveal useful guardrails or a poor template; it is not automatically failure. |
|
||||
| Workflow value | Median manual versus assisted intake time, manual correction time, and repeat voluntary use | Report sample size, task definition, material type, and confidence limits; do not generalize to all editing. |
|
||||
| Security/privacy | Observed outbound destinations, telemetry-disabled checks, permission exceptions, receipt-redaction defects | A passing check verifies the inspected setup only; it is not a facility-wide security assessment. |
|
||||
| Usability | Install-to-first-verified-run time, operator confidence, and support interventions | Self-reported confidence is not proof of host reliability. |
|
||||
|
||||
**Proposed promotion gate.** Do not present Project Intake as production-ready
|
||||
until at least 100 licensed-host runs across every claimed host configuration
|
||||
show no wrong-project, wrong-sequence, or wrong-media mutation; every mutation
|
||||
has attributable approval; uncertain commits were not retried; and structural
|
||||
readback, recovery, and egress records were independently reviewed. This is a
|
||||
future gate, not a statement that the current repository has passed it.
|
||||
|
||||
## Stop conditions and incident handling
|
||||
|
||||
Immediately pause the affected workflow and prohibit further application in the
|
||||
following situations:
|
||||
|
||||
- a mutation targets the wrong project, Production, sequence, item, bin, or
|
||||
workspace;
|
||||
- a plan is applied without a valid named approval, or a stale/digest-mismatched
|
||||
plan is accepted;
|
||||
- a mutation returns an uncertain, partial, conflicting, or unverifiable result
|
||||
that the operator cannot safely inspect and recover;
|
||||
- any prompt, transcript, tool argument/result, path, token, media name, or
|
||||
customer content appears in vendor telemetry, a shared report, or an
|
||||
unapproved outbound destination;
|
||||
- the configured MCP client or model route changes without security review;
|
||||
- a bridge token, package, manifest permission, workspace authority, endpoint,
|
||||
or project-storage root changes unexpectedly;
|
||||
- an attempted feature crosses into generative, remote, arbitrary-script, or
|
||||
external-integration scope; or
|
||||
- a participant reports a labor, privacy, clearance, security, or customer
|
||||
policy conflict.
|
||||
|
||||
The facility administrator first disconnects the bridge and preserves only
|
||||
content-free diagnostic facts. The workflow owner then determines whether the
|
||||
project needs manual inspection, Undo/recovery, or escalation under the
|
||||
facility's incident process. The pilot evidence reviewer records the condition
|
||||
as `failed`, `partial`, `unknown`, or `not_run`; it must never be reclassified
|
||||
as successful merely because the host later appears normal. Resume requires a
|
||||
documented root-cause review, updated template or control, a fixture rehearsal,
|
||||
and fresh approver authorization.
|
||||
|
||||
## Evidence template
|
||||
|
||||
Use one redacted record per run. Keep screenshots, bridge responses, project
|
||||
copies, and alias mappings inside the facility; references below are opaque,
|
||||
facility-controlled IDs rather than files to be shared externally.
|
||||
|
||||
```yaml
|
||||
pilot_run_alias: P-017
|
||||
date_bucket: 2026-W35
|
||||
stage: fixture_rehearsal
|
||||
workflow: project_intake_v1
|
||||
workflow_pack_version: "commit-or-signed-package-hash"
|
||||
host:
|
||||
os: Windows
|
||||
premiere_version: "facility-recorded"
|
||||
connector_build: "hash"
|
||||
backend: uxp
|
||||
configuration:
|
||||
transport: stdio
|
||||
http_server_started: false
|
||||
telemetry_key_configured: false
|
||||
uxp_manifest_reviewed: true
|
||||
approved_workspace_confirmed: true
|
||||
outbound_destinations_observed: []
|
||||
plan:
|
||||
project_alias: PRJ-LOCAL-4
|
||||
revision_alias: REV-LOCAL-9
|
||||
digest: "sha256-or-equivalent"
|
||||
actions: { inspect: 12, create: 1, move: 4, label: 4 }
|
||||
approval:
|
||||
assistant_editor_present: true
|
||||
post_approver_present: true
|
||||
approval_expires_before: "facility-local timestamp"
|
||||
result:
|
||||
status: structurally_verified
|
||||
per_action_summary: { succeeded: 9, rejected_before_mutation: 0, partial: 0, unknown: 0 }
|
||||
undo_checked: true
|
||||
render_verified: false
|
||||
evidence_references:
|
||||
- FACILITY-ONLY-BEFORE-AFTER-001
|
||||
- FACILITY-ONLY-UNDO-001
|
||||
issues:
|
||||
- none
|
||||
review:
|
||||
redaction_checked: true
|
||||
eligible_for_aggregate_metrics: true
|
||||
```
|
||||
|
||||
This template is intentionally compatible with, but does not replace, the
|
||||
repository's [licensed-host report shape](../editorial-workflow-host-validation.md#report-shape).
|
||||
The host report remains necessary before a claim crosses from automated
|
||||
contracts to a licensed-host capability claim.
|
||||
|
||||
## Case-study claim gates
|
||||
|
||||
No public case study, sales claim, or partner quote may be created from a pilot
|
||||
until all of the following are true:
|
||||
|
||||
1. The facility has given explicit written approval for the specific identity,
|
||||
quote, logo, workflow description, and data that may be published.
|
||||
2. The security/privacy reviewer confirms that the exported evidence contains
|
||||
no customer content, identifiers, prompts, transcript text, paths, or hidden
|
||||
telemetry.
|
||||
3. The evidence reviewer confirms the exact host versions, package/build hashes,
|
||||
run count, workflow stage, outcome classifications, and failure count.
|
||||
4. The reported time comparison defines the baseline, task, measurement method,
|
||||
sample size, material class, manual-correction treatment, and date range.
|
||||
5. At least two teams have voluntarily repeated the workflow after supervised
|
||||
sessions. A single successful demonstration is not an adoption claim.
|
||||
6. Any result stated as verified is limited to the evidence actually collected:
|
||||
planning, structural project readback, Undo/recovery, or separately measured
|
||||
render verification.
|
||||
7. The copy says what happened in the measured pilot, for example, “Across
|
||||
_N_ supervised intake runs at participating teams, median measured intake
|
||||
time changed from _X_ to _Y_ for the defined workflow,” rather than claiming
|
||||
general editing speed, autonomous editing, security certification, or
|
||||
universal Premiere compatibility.
|
||||
|
||||
Published material must retain a limitations note: pilot outcomes do not prove
|
||||
creative quality, delivery correctness, rights clearance, model privacy outside
|
||||
the approved route, or compatibility with untested Premiere/client/operating
|
||||
system combinations.
|
||||
|
||||
## Next decision
|
||||
|
||||
Before recruiting a design partner, implement or formally accept the proposed
|
||||
configuration attestation, content-free receipts, retention/deletion controls,
|
||||
plan digest/expiry, per-action result certainty, and stop/resume workflow. Then
|
||||
run the existing licensed-host validation procedure with non-sensitive fixtures
|
||||
on every configuration that the pilot intends to name. Until then, this document
|
||||
is a proposed control plan, not evidence that the controls are in production.
|
||||
Executable
+74
@@ -0,0 +1,74 @@
|
||||
# Guided lecture-caption workflow
|
||||
|
||||
## Status
|
||||
|
||||
`create_caption_track` now has a `plan_lecture_workflow` action that parses a
|
||||
caller-provided SRT or VTT locally and returns a timing-correction preview plus
|
||||
a review checklist. It does not write the artifact, upload it, import it into
|
||||
Premiere, or call an AI/provider service.
|
||||
|
||||
Use this when a long lecture, interview, or training recording has an existing
|
||||
caption artifact and an editor needs to distinguish a constant offset from a
|
||||
duration mismatch before importing it.
|
||||
|
||||
## Plan a timing review
|
||||
|
||||
Provide the artifact content, its syntax, and only the timing observations an
|
||||
editor has already made:
|
||||
|
||||
```json
|
||||
{
|
||||
"action": "plan_lecture_workflow",
|
||||
"artifact_format": "srt",
|
||||
"caption_content": "<caller-owned SRT content>",
|
||||
"target_duration_seconds": 1620,
|
||||
"observed_offset_seconds": 0.4,
|
||||
"timing_tolerance_seconds": 0.25
|
||||
}
|
||||
```
|
||||
|
||||
`observed_offset_seconds` is positive when captions currently appear later
|
||||
than intended. The response contains cue count, first/last timing, a beginning/
|
||||
middle/end sample, and one of these review-only outcomes:
|
||||
|
||||
| Status | Meaning |
|
||||
| --- | --- |
|
||||
| `aligned` | No requested correction is needed within the tolerance. |
|
||||
| `constant_offset` | A safe inverse shift is proposed from the editor-observed offset. |
|
||||
| `proportional_drift` | A bounded scale preview is proposed only after the caller sets `allow_proportional_scaling: true`. |
|
||||
| `review_required` | The artifact is invalid, its mismatch is ambiguous, its first cue is not safely anchored, or the proposed operation could create negative time. |
|
||||
|
||||
The tool rejects malformed timecodes, non-positive cue ranges, overlaps, more
|
||||
than 10,000 cues, and overly large artifacts. It deliberately withholds a
|
||||
proportional correction by default: a caption file ending before a sequence
|
||||
does not prove drift, because a recording can contain intentional lead-in or
|
||||
tail time.
|
||||
|
||||
## Apply only after review
|
||||
|
||||
The plan does not authorize a mutation. Follow its steps separately:
|
||||
|
||||
1. Work in a duplicate/test sequence. Use a documented UXP clone workflow only
|
||||
when the connected host advertises it; otherwise duplicate in Premiere and
|
||||
re-query its stable sequence ID.
|
||||
2. Review the sampled ranges and update the caller-owned SRT/VTT outside this
|
||||
server if the editor accepts a correction.
|
||||
3. Import the reviewed artifact into the project, then call
|
||||
`create_caption_track` with `action: "import"`, the imported `item_id`, and
|
||||
an intentional `start_seconds` value.
|
||||
4. Call `read_sequence_captions` for structural track readback.
|
||||
5. Review beginning/middle/end frames and play those ranges in Premiere.
|
||||
6. Treat final rendered output review as a separate delivery gate.
|
||||
|
||||
## Evidence boundary
|
||||
|
||||
| Evidence | What it establishes | What it does not establish |
|
||||
| --- | --- | --- |
|
||||
| Local timing plan | SRT/VTT syntax, non-overlap, supplied timing assumptions, and a deterministic preview | That any caption file was changed or that Premiere agrees with the plan |
|
||||
| Caption-track readback | A host-exposed structural track result | Synchronization in playback, line breaks, safe area, or accessibility quality |
|
||||
| Review frames | A sampled visual artifact | Temporal playback behavior or exported delivery quality |
|
||||
| Playback/render review | A human-reviewed output at its stated scope | General compatibility for all Premiere, client, or caption versions |
|
||||
|
||||
The workflow is a guide and returns `not_run` for structural, playback, and
|
||||
rendered-output verification until the editor performs and records those steps
|
||||
on the actual host.
|
||||
Executable
+20
@@ -0,0 +1,20 @@
|
||||
{
|
||||
"sourceCommit": "0000000000000000000000000000000000000000",
|
||||
"host": {
|
||||
"os": "Windows",
|
||||
"premiereVersion": "26.3.0",
|
||||
"panelBuild": "0000000"
|
||||
},
|
||||
"fixture": {
|
||||
"revision": "fixture-v1",
|
||||
"sha256": "0000000000000000000000000000000000000000000000000000000000000000"
|
||||
},
|
||||
"cases": [
|
||||
{
|
||||
"id": "EWP-ORG-001",
|
||||
"status": "not_run",
|
||||
"evidence": [],
|
||||
"undoEvidence": false
|
||||
}
|
||||
]
|
||||
}
|
||||
Executable
+35
@@ -0,0 +1,35 @@
|
||||
{
|
||||
"schemaVersion": "premiere-pro-mcp.licensed-host-sweep-matrix.v1",
|
||||
"id": "core-connection-and-edit-v1",
|
||||
"title": "Core connection and bounded-edit licensed-host sweep",
|
||||
"cases": [
|
||||
{
|
||||
"id": "LHS-CONNECTION-001",
|
||||
"operationClass": "read_only",
|
||||
"tool": "verify_premiere_connection",
|
||||
"purpose": "Confirm the selected bridge, a project, and an active sequence without returning project details.",
|
||||
"requiredEvidenceKinds": ["host_state", "structured_response"]
|
||||
},
|
||||
{
|
||||
"id": "LHS-CEP-PING-001",
|
||||
"operationClass": "read_only",
|
||||
"tool": "ping",
|
||||
"purpose": "Confirm the installed CEP bridge can reach the licensed Premiere host.",
|
||||
"requiredEvidenceKinds": ["panel_state", "structured_response"]
|
||||
},
|
||||
{
|
||||
"id": "LHS-UXP-CONNECTION-001",
|
||||
"operationClass": "read_only",
|
||||
"tool": "verify_premiere_connection",
|
||||
"purpose": "Confirm an explicitly selected authenticated UXP bridge, or record it as unsupported or not run.",
|
||||
"requiredEvidenceKinds": ["panel_state", "structured_response"]
|
||||
},
|
||||
{
|
||||
"id": "LHS-MARKER-UNDO-001",
|
||||
"operationClass": "mutation",
|
||||
"tool": "add_marker",
|
||||
"purpose": "Create one marker in a generated fixture, confirm the returned state, then prove Undo restores the before state.",
|
||||
"requiredEvidenceKinds": ["before_state", "after_state", "structured_response", "undo"]
|
||||
}
|
||||
]
|
||||
}
|
||||
Executable
+73
@@ -0,0 +1,73 @@
|
||||
# Licensed-host sweep
|
||||
|
||||
This is a reproducible reporting workflow for a real, licensed Premiere Pro
|
||||
host. It is deliberately a **curated** connection-and-bounded-edit sweep, not
|
||||
a claim that every registered tool has been run. CI can validate its report
|
||||
shape, but it cannot supply licensed-host evidence.
|
||||
|
||||
The checked-in matrix is
|
||||
[`licensed-host-sweep.matrix.json`](licensed-host-sweep.matrix.json). It covers
|
||||
read-only connection checks for CEP and authenticated UXP plus one generated-
|
||||
fixture marker mutation with an Undo check. An `unsupported`, `failed`, or
|
||||
`not_run` outcome is useful evidence and must remain recorded as such.
|
||||
|
||||
[`licensed-host-sweep.template.json`](licensed-host-sweep.template.json) is a
|
||||
static example of the same report shape. Prefer the generator so the source
|
||||
commit and selected matrix cases are not copied by hand.
|
||||
|
||||
## Prepare a report
|
||||
|
||||
Use a generated, disposable fixture and write the report outside the repository
|
||||
unless every input and artifact is deliberately public. The generator does not
|
||||
open Premiere, read project data, or call MCP tools. It only records supplied
|
||||
safe identifiers and the checked-out source SHA.
|
||||
|
||||
```bash
|
||||
npm run prepare:host-sweep -- \
|
||||
--host-os Windows \
|
||||
--premiere-version 26.3.0 \
|
||||
--panel-build 0123abcd \
|
||||
--fixture-revision generated-fixture-v1 \
|
||||
--fixture-sha256 0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef \
|
||||
--output ../premiere-host-evidence/sweep.json
|
||||
```
|
||||
|
||||
Add `--case LHS-CONNECTION-001` one or more times to create a smaller,
|
||||
explicitly scoped run. The resulting report starts with every selected status
|
||||
as `not_run`; it cannot create a passing result.
|
||||
|
||||
## Run and record
|
||||
|
||||
1. Fully close Premiere, install or repair the exact connector bytes under
|
||||
test, then reopen a copy of the generated fixture.
|
||||
2. Record the operating-system, Premiere, panel-build, fixture, and source
|
||||
values in the generated report. Do not use an account, machine, project, or
|
||||
media name as an identifier.
|
||||
3. Run each selected matrix case manually. Keep raw captures and any redacted
|
||||
structured response in the approved private evidence location, not in this
|
||||
JSON report.
|
||||
4. Add opaque evidence references only, such as
|
||||
`{ "kind": "panel_state", "ref": "lhs-cep-ping-panel-001" }`.
|
||||
A reference cannot contain a path, URL, account, prompt, token, project
|
||||
name, or response content.
|
||||
5. For `LHS-MARKER-UNDO-001`, retain before state, after state, structured
|
||||
response, and Undo proof. Do not mark it `passed` unless Undo restores the
|
||||
fixture.
|
||||
|
||||
## Validate before review
|
||||
|
||||
```bash
|
||||
npm run validate:host-report -- ../premiere-host-evidence/sweep.json
|
||||
```
|
||||
|
||||
The validator enforces
|
||||
[`licensed-host-sweep.schema.json`](licensed-host-sweep.schema.json), matrix
|
||||
membership, opaque evidence references, and the required evidence types for a
|
||||
passed case. It rejects local paths, credential-like text, and fields that
|
||||
could carry a raw response. A passing validation result means the record is
|
||||
well-formed enough for human evidence review; it does not prove a tool,
|
||||
version, or workflow is generally supported.
|
||||
|
||||
See also the focused
|
||||
[editorial workflow host-validation runbook](editorial-workflow-host-validation.md)
|
||||
for the planning and organization acceptance matrix.
|
||||
Executable
+70
@@ -0,0 +1,70 @@
|
||||
{
|
||||
"$schema": "https://json-schema.org/draft/2020-12/schema",
|
||||
"$id": "https://premiere-pro-mcp.com/schemas/licensed-host-sweep.v1.json",
|
||||
"title": "Premiere MCP licensed-host sweep report",
|
||||
"type": "object",
|
||||
"additionalProperties": false,
|
||||
"required": ["schemaVersion", "sourceCommit", "host", "fixture", "sweep", "cases"],
|
||||
"properties": {
|
||||
"schemaVersion": { "const": "premiere-pro-mcp.licensed-host-sweep.v1" },
|
||||
"sourceCommit": { "type": "string", "pattern": "^[0-9a-fA-F]{40}$" },
|
||||
"host": {
|
||||
"type": "object",
|
||||
"additionalProperties": false,
|
||||
"required": ["os", "premiereVersion", "panelBuild"],
|
||||
"properties": {
|
||||
"os": { "enum": ["Windows", "macOS"] },
|
||||
"premiereVersion": { "type": "string", "minLength": 1, "maxLength": 64 },
|
||||
"panelBuild": { "type": "string", "pattern": "^[0-9a-fA-F]{7,64}$" }
|
||||
}
|
||||
},
|
||||
"fixture": {
|
||||
"type": "object",
|
||||
"additionalProperties": false,
|
||||
"required": ["revision", "sha256"],
|
||||
"properties": {
|
||||
"revision": { "type": "string", "pattern": "^[A-Za-z0-9][A-Za-z0-9._-]{0,63}$" },
|
||||
"sha256": { "type": "string", "pattern": "^[0-9a-fA-F]{64}$" }
|
||||
}
|
||||
},
|
||||
"sweep": {
|
||||
"type": "object",
|
||||
"additionalProperties": false,
|
||||
"required": ["matrixId", "matrixVersion"],
|
||||
"properties": {
|
||||
"matrixId": { "const": "core-connection-and-edit-v1" },
|
||||
"matrixVersion": { "const": "1" }
|
||||
}
|
||||
},
|
||||
"cases": {
|
||||
"type": "array",
|
||||
"minItems": 1,
|
||||
"items": { "$ref": "#/$defs/case" }
|
||||
}
|
||||
},
|
||||
"$defs": {
|
||||
"case": {
|
||||
"type": "object",
|
||||
"additionalProperties": false,
|
||||
"required": ["id", "operationClass", "status", "evidence", "undoEvidence"],
|
||||
"properties": {
|
||||
"id": { "type": "string", "pattern": "^LHS-[A-Z0-9-]+$" },
|
||||
"operationClass": { "enum": ["read_only", "mutation"] },
|
||||
"status": { "enum": ["passed", "failed", "unsupported", "not_run"] },
|
||||
"evidence": {
|
||||
"type": "array",
|
||||
"items": {
|
||||
"type": "object",
|
||||
"additionalProperties": false,
|
||||
"required": ["kind", "ref"],
|
||||
"properties": {
|
||||
"kind": { "enum": ["host_state", "panel_state", "before_state", "after_state", "structured_response", "undo", "artifact_check"] },
|
||||
"ref": { "type": "string", "pattern": "^[A-Za-z0-9][A-Za-z0-9._-]{0,127}$" }
|
||||
}
|
||||
}
|
||||
},
|
||||
"undoEvidence": { "type": "boolean" }
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
Executable
+47
@@ -0,0 +1,47 @@
|
||||
{
|
||||
"schemaVersion": "premiere-pro-mcp.licensed-host-sweep.v1",
|
||||
"sourceCommit": "0000000000000000000000000000000000000000",
|
||||
"host": {
|
||||
"os": "Windows",
|
||||
"premiereVersion": "26.3.0",
|
||||
"panelBuild": "0000000"
|
||||
},
|
||||
"fixture": {
|
||||
"revision": "generated-fixture-v1",
|
||||
"sha256": "0000000000000000000000000000000000000000000000000000000000000000"
|
||||
},
|
||||
"sweep": {
|
||||
"matrixId": "core-connection-and-edit-v1",
|
||||
"matrixVersion": "1"
|
||||
},
|
||||
"cases": [
|
||||
{
|
||||
"id": "LHS-CONNECTION-001",
|
||||
"operationClass": "read_only",
|
||||
"status": "not_run",
|
||||
"evidence": [],
|
||||
"undoEvidence": false
|
||||
},
|
||||
{
|
||||
"id": "LHS-CEP-PING-001",
|
||||
"operationClass": "read_only",
|
||||
"status": "not_run",
|
||||
"evidence": [],
|
||||
"undoEvidence": false
|
||||
},
|
||||
{
|
||||
"id": "LHS-UXP-CONNECTION-001",
|
||||
"operationClass": "read_only",
|
||||
"status": "not_run",
|
||||
"evidence": [],
|
||||
"undoEvidence": false
|
||||
},
|
||||
{
|
||||
"id": "LHS-MARKER-UNDO-001",
|
||||
"operationClass": "mutation",
|
||||
"status": "not_run",
|
||||
"evidence": [],
|
||||
"undoEvidence": false
|
||||
}
|
||||
]
|
||||
}
|
||||
Executable
+46
@@ -0,0 +1,46 @@
|
||||
# MCP for Adobe Premiere Pro Marketing Assets
|
||||
|
||||
The approved launch set lives in `landing/public/marketing/`. Use the original `v1` assets for public product marketing.
|
||||
|
||||
| Asset | Intended use | Dimensions |
|
||||
| --- | --- | --- |
|
||||
| `premiere-pro-mcp-mark-v1.png` | Navigation, app icon, avatar, and organization logo | 1254 × 1254 PNG with transparency |
|
||||
| `premiere-pro-mcp-campaign-hero-v1.png` | Landing hero, launch articles, and wide campaign placements | 1672 × 941 PNG |
|
||||
| `premiere-pro-mcp-social-square-v1.png` | Open Graph, X, LinkedIn, GitHub, and directory social creative | 1254 × 1254 PNG |
|
||||
| `premiere-pro-mcp-workflow-v1.png` | Architecture explanation, documentation, and launch posts | 1672 × 941 PNG |
|
||||
|
||||
## Approved positioning
|
||||
|
||||
Lead with the outcome and local-first architecture:
|
||||
|
||||
> Connect a compatible AI assistant to Adobe Premiere Pro with structured tools for project inspection, supported editing workflows, diagnostics, and export.
|
||||
|
||||
Supporting proof:
|
||||
|
||||
- Free and MIT licensed
|
||||
- Recommended local-first setup
|
||||
- 349 registered core tools; 347 in the default profile
|
||||
- 93 additional capability-gated tools with an authenticated compatible UXP host
|
||||
- Windows and macOS packaging for supported Premiere versions
|
||||
|
||||
## Claim boundaries
|
||||
|
||||
- Do not call an illustrated or simulated animation a live Premiere recording.
|
||||
- Do not claim a static compatibility matrix proves a successful host operation.
|
||||
- Do not say the project is affiliated with or endorsed by Adobe.
|
||||
- Do not use the Adobe Premiere `Pr` tile as the project logo.
|
||||
- Do not claim customer adoption, successful installations, or tool outcomes without current evidence.
|
||||
- Qualify UXP as capability-gated and keep CEP as the default production bridge until the documented release boundary changes.
|
||||
|
||||
## Distribution checklist
|
||||
|
||||
For each launch placement, record the destination and use lowercase UTM values:
|
||||
|
||||
```text
|
||||
utm_source=<directory-or-community>
|
||||
utm_medium=<social|directory|referral|email>
|
||||
utm_campaign=premiere_pro_mcp_<release-or-theme>
|
||||
utm_content=<asset-or-cta>
|
||||
```
|
||||
|
||||
Link to `https://premiere-pro-mcp.com/` as the canonical product page. Link directly to the current GitHub release only when the placement is specifically about release artifacts.
|
||||
+69
@@ -0,0 +1,69 @@
|
||||
# Adobe Video Partner brief
|
||||
|
||||
**Status:** prepared for an owner-operated Adobe Video Partner application.
|
||||
This document is not an application, endorsement, Marketplace listing, or
|
||||
claim of Adobe affiliation.
|
||||
|
||||
## Suggested application summary
|
||||
|
||||
MCP for Adobe Premiere Pro is a free, MIT-licensed local integration that lets
|
||||
compatible AI clients use structured, capability-aware Premiere workflows. It
|
||||
is designed for reviewable work: start with a read-only connection check,
|
||||
inspect supported project state, preview meaningful changes where available,
|
||||
and return explicit results or limitations. The recommended setup keeps the AI
|
||||
client, server, connector, and Premiere host on the editor's computer.
|
||||
|
||||
The project complements Adobe's evolving native AI experiences. It does not
|
||||
claim to replace them, to be affiliated with Adobe, or to provide unattended
|
||||
editing, universal host compatibility, or a hosted relay into a customer's
|
||||
desktop Premiere process.
|
||||
|
||||
## Links for the application owner
|
||||
|
||||
- Adobe Video Partner Program: <https://www.adobevideopartner.com/>
|
||||
- Product site: <https://premiere-pro-mcp.com/>
|
||||
- Source and support: <https://github.com/leancoderkavy/premiere-pro-mcp>
|
||||
- Current release: <https://github.com/leancoderkavy/premiere-pro-mcp/releases/latest>
|
||||
- [Installation and local-first boundary](../../README.md)
|
||||
- [Capability and support boundary](../supported-actions.md)
|
||||
- [Marketplace release checklist](../adobe-marketplace-release-checklist.md)
|
||||
- [Design-partner pilot controls](../industry/security-and-design-partner-pilot.md)
|
||||
|
||||
## Evidence the owner should attach or link
|
||||
|
||||
1. A current release build and the Marketplace-targeted connector package only
|
||||
when it has passed the channel-specific validation.
|
||||
2. Three real, redacted licensed-host walkthroughs: read-only connection
|
||||
verification, a review-first workflow, and a returned verification or
|
||||
limitation. Label simulations and illustrations as such.
|
||||
3. The exact host version, operating system, artifact hash, workflow boundary,
|
||||
and observed result for every claimed demonstration.
|
||||
4. Current privacy, security, and support pages, plus the reviewer instructions
|
||||
needed to install and test the local connector.
|
||||
|
||||
## Conversation goals
|
||||
|
||||
- Ask for feedback on UXP integration and distribution expectations.
|
||||
- Offer a narrowly scoped design-partner evaluation using synthetic or
|
||||
facility-approved fixtures, not production media by default.
|
||||
- Invite review of one repeatable workflow—Project Intake, review planning, or
|
||||
delivery preflight—rather than claiming general autonomous editing.
|
||||
|
||||
## Do not say
|
||||
|
||||
- "Adobe-approved," "Adobe-endorsed," or "Adobe-certified" before Adobe
|
||||
independently grants that status.
|
||||
- "Marketplace available" before a public Marketplace URL is live.
|
||||
- "Production-proven," "safe for every project," or "works on every Premiere
|
||||
version" without evidence for the specific workflow and host.
|
||||
- That local-first architecture changes the privacy terms of a chosen AI client
|
||||
or model provider.
|
||||
|
||||
## Owner actions still required
|
||||
|
||||
1. Use the Adobe Video Partner Program's current application path and provide
|
||||
the final publisher/contact details.
|
||||
2. Verify current Marketplace reviewer requirements in Adobe Developer
|
||||
Distribution; account status and requested materials are time-sensitive.
|
||||
3. Approve any public contact, customer reference, screenshot, or demonstration
|
||||
before it is sent or posted.
|
||||
Executable
+73
@@ -0,0 +1,73 @@
|
||||
# Premiere Pro MCP community launch kit
|
||||
|
||||
**Status:** prepared drafts only. Nothing in this file has been posted, sent, or scheduled.
|
||||
|
||||
## Use this only when it helps the current conversation
|
||||
|
||||
- Check each community's self-promotion rules before posting.
|
||||
- Answer the workflow question first. Link a guide only when it genuinely answers the follow-up.
|
||||
- Never represent illustrated site assets as a live Premiere session.
|
||||
- Do not claim every tool or host version will work. Direct readers to the read-only connection check and capability inspection.
|
||||
- Do not say the local server changes the privacy terms of the AI client the reader chooses.
|
||||
- Do not contact people from this document without an approved contact list and owner authorization.
|
||||
|
||||
## Owned social draft
|
||||
|
||||
AI editing is most useful when it removes repeated Premiere work without hiding the edit.
|
||||
|
||||
Premiere Pro MCP is a free, MIT-licensed local bridge between a compatible AI client and supported Premiere workflows. Start with a read-only connection check, inspect the project, preview a bounded request, and verify the returned result before relying on it.
|
||||
|
||||
Practical setup and workflow guides: `https://premiere-pro-mcp.com/blog/?utm_source=linkedin&utm_medium=organic_social&utm_campaign=premiere_workflow_guides`
|
||||
|
||||
## Technical-community draft
|
||||
|
||||
I maintain an open-source MCP server for supported Adobe Premiere Pro workflows. The goal is not autonomous editing. It is to make repeated work inspectable: check the connection, inspect a project, create a non-mutating plan where available, preview it, and verify the returned result.
|
||||
|
||||
The project is local-first and independent from Adobe's AI Assistant. This guide compares the workflows without claiming either is universally better:
|
||||
|
||||
`https://premiere-pro-mcp.com/blog/adobe-premiere-ai-assistant-vs-mcp/?utm_source=community&utm_medium=organic_referral&utm_campaign=premiere_workflow_comparison`
|
||||
|
||||
Useful feedback: installation friction, capability boundaries, and the first repeatable Premiere task a team would test.
|
||||
|
||||
## Editorial-community reply pattern
|
||||
|
||||
1. Name the specific Premiere task the person is trying to repeat.
|
||||
2. Share one concrete, non-promotional way to make it safer: define the target sequence, what must not change, and how the result will be checked.
|
||||
3. If the person asks for a tool or implementation, disclose the project relationship and link the one relevant guide.
|
||||
4. Invite correction or workflow details. Do not push a download.
|
||||
|
||||
## Design-partner interview invitation draft
|
||||
|
||||
**Subject:** Could we map one repeatable Premiere workflow?
|
||||
|
||||
Hi [name],
|
||||
|
||||
I maintain Premiere Pro MCP, an open-source local bridge for reviewable Premiere workflows through compatible AI clients. I am looking to learn how post teams handle one repeated task such as project intake, cutdown preparation, or delivery checks.
|
||||
|
||||
This is a 30-minute research conversation, not a product-sale call. We will map the current steps, what must stay under editor control, and what evidence would make an automation trustworthy. We will not ask for project media, client footage, credentials, or confidential project names.
|
||||
|
||||
If it is useful, I can send the workflow questions in advance.
|
||||
|
||||
Thanks,
|
||||
Premiere Pro MCP contributors
|
||||
|
||||
## Interview guide
|
||||
|
||||
- Which Premiere task repeats often enough to document?
|
||||
- What triggers it, who owns it, and where does handoff fail?
|
||||
- What input must an assistant see, and what must it never change?
|
||||
- What output would prove the workflow succeeded?
|
||||
- Which host versions and AI clients are involved?
|
||||
- What would make setup too risky or too time-consuming?
|
||||
- May we retain this feedback anonymously? Do not record customer claims or quotes without separate written approval.
|
||||
|
||||
## Measurement
|
||||
|
||||
Use campaign links with the existing allowlisted UTM format:
|
||||
|
||||
- `utm_source`: channel or named partner
|
||||
- `utm_medium`: `organic_social`, `referral`, or `email`
|
||||
- `utm_campaign`: `premiere_workflow_guides` or another stable lowercase campaign ID
|
||||
- `utm_content`: a stable creative ID when variants are tested
|
||||
|
||||
Primary success signal: a completed read-only connection check and an observable first workflow result. Likes, impressions, stars, and downloads are diagnostic only.
|
||||
+42
@@ -0,0 +1,42 @@
|
||||
# MCP Registry readiness
|
||||
|
||||
**Status:** v1.14.8 local and published-npm metadata verified on 2026-09-04; not submitted to the official registry.
|
||||
|
||||
The official MCP Registry is a separate public listing. A repository change, an npm package, or a GitHub release does not create a listing. Submission requires a user-authorized registry login and publication action.
|
||||
|
||||
The verified v1.14.8 npm artifact exposes
|
||||
`mcpName: io.github.leancoderkavy/premiere-pro`, and its checked-in `registry/server.json`
|
||||
matches the published package name, version, repository, and local `stdio`
|
||||
transport. Run the official validator and the read-only preflight below at the
|
||||
moment of submission; their results are readiness evidence, not a publication
|
||||
claim.
|
||||
|
||||
Before an owner-authorized submission:
|
||||
|
||||
1. Run `npm run validate:mcp-registry-metadata` followed by
|
||||
`npm run preflight:mcp-registry`. The latter checks the published npm
|
||||
artifact and searches the official registry; it does not authenticate or
|
||||
publish.
|
||||
2. Inspect `registry/server.json` from the exact release tag and confirm the
|
||||
entry continues to describe only the local `stdio` route. Do not present the
|
||||
local Premiere bridge as a hosted service.
|
||||
3. Obtain action-time approval, authenticate with `mcp-publisher login github`,
|
||||
and publish once with `mcp-publisher publish registry/server.json`.
|
||||
4. Query the registry for the exact listing name and retain the returned URL as
|
||||
public evidence. Do not create a second record merely because search results
|
||||
are delayed.
|
||||
|
||||
Use only these evidence-bounded facts in a future directory entry:
|
||||
|
||||
- Free, MIT-licensed, local-first MCP server for supported Premiere Pro workflows.
|
||||
- A compatible AI client calls structured tools through a local Premiere connection.
|
||||
- Begin with `verify_premiere_connection`; support remains capability- and host-dependent.
|
||||
- The chosen AI client's privacy behavior is separate from the server's local-first recommendation.
|
||||
|
||||
Do not submit until the package version, transport, authentication expectations, privacy disclosures, and source URL are all verified for that directory.
|
||||
|
||||
Official references:
|
||||
|
||||
- <https://modelcontextprotocol.io/registry/quickstart>
|
||||
- <https://registry.modelcontextprotocol.io/docs>
|
||||
- <https://modelcontextprotocol.io/registry/faq>
|
||||
Executable
+98
@@ -0,0 +1,98 @@
|
||||
# MCP for Adobe Premiere Pro Organic Distribution Kit
|
||||
|
||||
## Gate before any public distribution
|
||||
|
||||
Treat this file as draft copy, not proof that a guide is public. Before a post,
|
||||
outreach message, directory submission, or community link goes out, verify the
|
||||
exact production guide URL and `/blog/` return HTTPS 200 on the intended
|
||||
deployed commit. Do not publish a URL from a local build or repository branch.
|
||||
|
||||
## Guide inventory
|
||||
|
||||
| Reader intent | Guide | Public route to verify before sharing |
|
||||
| --- | --- | --- |
|
||||
| Understand the product | What is an MCP server for Adobe Premiere Pro? | `/blog/what-is-a-premiere-pro-mcp-server/` |
|
||||
| Evaluate a safe first workflow | Premiere Pro AI workflow checklist | `/blog/premiere-pro-ai-workflow-checklist/` |
|
||||
| Compare AI routes | Adobe Premiere AI Assistant vs. MCP | `/blog/adobe-premiere-ai-assistant-vs-mcp/` |
|
||||
| Prepare assistant-editor intake | Premiere Pro Project Intake checklist | `/blog/premiere-pro-project-intake-checklist/` |
|
||||
| Preserve a recovery point | Premiere Pro project backup checklist | `/blog/premiere-pro-project-backup-checklist/` |
|
||||
| Focus a visual review | Premiere Pro review frames and scene detection | `/blog/premiere-pro-review-frames-and-scene-detection/` |
|
||||
| Inspect a delivery file | Premiere Pro delivery QC and loudness checklist | `/blog/premiere-pro-delivery-qc-and-loudness-checklist/` |
|
||||
|
||||
## Positioning
|
||||
|
||||
MCP for Adobe Premiere Pro gives compatible AI assistants a structured, local-first way to inspect Premiere projects, plan supported edits, automate repeatable work, and return observable results—without replacing the editor’s creative decision.
|
||||
|
||||
## Draft release post
|
||||
|
||||
When the checked guide URLs are live, share this for editors and workflow teams who want to use AI with Adobe Premiere Pro without handing over creative control:
|
||||
|
||||
1. A practical comparison of Adobe’s current AI Assistant beta and a structured MCP workflow
|
||||
2. A project-backup checklist before high-risk automation or organization work
|
||||
3. A visual-review guide for file-verified frames and source scene candidates
|
||||
4. A delivery-QC guide for scoped black/freeze findings and loudness measurement
|
||||
|
||||
MCP for Adobe Premiere Pro is free, MIT licensed, and local-first. Start with a read-only connection check, then inspect your active sequence before requesting an edit.
|
||||
|
||||
Read the guides: https://premiere-pro-mcp.com/blog/
|
||||
|
||||
## Short social variants
|
||||
|
||||
### LinkedIn
|
||||
|
||||
AI video editing should make repetitive Premiere work easier to review—not make creative decisions in a black box.
|
||||
|
||||
When the guide set is live, share the comparison, project-backup, visual-review, and delivery-QC checklists with the post-production teams who need a bounded way to evaluate automation.
|
||||
|
||||
Start with the safe, read-only connection check: https://premiere-pro-mcp.com/blog/
|
||||
|
||||
### X / Bluesky
|
||||
|
||||
New practical guides for AI-assisted Adobe Premiere Pro workflows.
|
||||
|
||||
Compare the current native Assistant beta with a structured MCP path, then use focused backup, review, and delivery-QC checklists before relying on a workflow.
|
||||
|
||||
Free, MIT licensed, local-first: https://premiere-pro-mcp.com/blog/
|
||||
|
||||
### Community post
|
||||
|
||||
This open-source MCP server provides structured, local-first Adobe Premiere Pro workflows. The goal is not autonomous editing: it is making repetitive work inspectable, bounded, and easier to verify.
|
||||
|
||||
The guide hub covers the connection model, workflow boundaries, the current Adobe AI Assistant beta, project backups, visual review, and delivery QC. Feedback on capability boundaries, install friction, and real editor workflows is especially welcome once the verified guide URLs are live: https://premiere-pro-mcp.com/blog/
|
||||
|
||||
## Outreach email
|
||||
|
||||
**Subject:** A practical, local-first guide to AI workflows in Premiere Pro
|
||||
|
||||
Hi [name],
|
||||
|
||||
I published a short guide series for editors and post-production teams exploring AI-assisted Adobe Premiere Pro workflows. It focuses on a gap that gets missed in “AI video editing” coverage: how to inspect a project, constrain an automation, and verify a result instead of treating a prompt as proof.
|
||||
|
||||
MCP for Adobe Premiere Pro is a free, MIT-licensed local MCP server. The guides are useful even for readers who are comparing approaches, because they explain a clear safety and review model.
|
||||
|
||||
If it is relevant to your audience, the hub is here: https://premiere-pro-mcp.com/blog/
|
||||
|
||||
Thanks,
|
||||
MCP for Adobe Premiere Pro contributors
|
||||
|
||||
## 30-day distribution cadence
|
||||
|
||||
| Week | Primary action | Success signal |
|
||||
| --- | --- | --- |
|
||||
| 1 | Announce the guide hub on owned social channels and GitHub Discussions; link to the “what is” guide. | Referral visits and completed setup-guide clicks. |
|
||||
| 2 | Share a concrete inspect-plan-apply-verify example; link to the AI workflow guide. | Time on article and safe-check copy or docs clicks. |
|
||||
| 3 | Publish one short workflow recipe from a real, approved use case; link to the automation guide. | Qualified feedback and issue/discussion quality. |
|
||||
| 4 | Reach out individually to relevant editor, MCP, and post-production publications or newsletters. | Earned links and branded search impressions. |
|
||||
|
||||
## Measurement
|
||||
|
||||
- Tag each owned social link with a channel-specific UTM source and campaign such as `utm_source=linkedin&utm_medium=organic_social&utm_campaign=guides_launch`.
|
||||
- Treat a completed installation, `verify_premiere_connection`, and first successful supported tool call as stronger outcomes than impressions, likes, stars, or downloads.
|
||||
- Review Search Console query/impression data after enough crawl and ranking time; do not rewrite a guide solely because early rankings are sparse.
|
||||
|
||||
## Boundaries
|
||||
|
||||
- Do not characterize simulated UI/video assets as live Premiere proof.
|
||||
- Do not claim a tool works in every Premiere build; direct readers to the read-only connection check and capability inspection.
|
||||
- Do not imply that the local-first server changes the privacy terms of a chosen AI client.
|
||||
- This kit is for organic distribution. Paid campaigns are intentionally not activated: they need a defined budget, audience, destination, and conversion measurement plan.
|
||||
Executable
+89
@@ -0,0 +1,89 @@
|
||||
# MCP 2026-07-28 capability report
|
||||
|
||||
Last researched: 2026-08-27
|
||||
|
||||
This repository targets the current Model Context Protocol revision, `2026-07-28`, through the stable TypeScript SDK v2 packages. The same server factory continues to serve legacy MCP clients (`2024-10-07` through `2025-11-25`) so existing Premiere integrations do not need a flag-day upgrade.
|
||||
|
||||
## Implemented protocol surface
|
||||
|
||||
| Capability | Status | Repository behavior |
|
||||
| --- | --- | --- |
|
||||
| Stateless protocol core | Implemented | HTTP uses `createMcpHandler`; every modern request receives a fresh MCP server instance and can land on any process instance. |
|
||||
| `server/discover` | Implemented | HTTP and stdio use the v2 serving entries and advertise `2026-07-28`; modern clients can probe before selecting an era. |
|
||||
| Per-request `_meta` envelope | Implemented | Validated and exposed by the SDK on modern calls; no hidden MCP session state is required. |
|
||||
| Dual-era serving | Implemented | One factory serves modern and legacy clients over both Streamable HTTP and stdio. For a stdio client that cannot complete `server/discover`, the explicit `PREMIERE_MCP_PROTOCOL_MODE=legacy` fallback serves the legacy initialization handshake only. |
|
||||
| `MCP-Protocol-Version`, `Mcp-Method`, and `Mcp-Name` routing headers | Implemented | The modern HTTP entry validates required headers and agreement with the JSON-RPC body before dispatch. |
|
||||
| `Mcp-Param-*` schema headers | Available | The v2 entry validates parameters declared with `x-mcp-header`; no current Premiere tool duplicates an argument into a routing header. |
|
||||
| Cacheable list/read results | Implemented | `tools/list` is private for 30 seconds; `prompts/list` is public for 5 minutes; `resources/list` is private for 1 minute; live `resources/read` results are private and uncached. |
|
||||
| Deterministic tool, prompt, and resource lists | Implemented | Registries are built in stable catalog order and v2 emits the modern cache fields. |
|
||||
| `subscriptions/listen` | Implemented by serving entries | Modern change streams are handled by the v2 HTTP/stdio entries. The current registries are static during a process lifetime, so they do not emit application-driven list changes. |
|
||||
| Multi Round-Trip Requests (MRTR) | SDK-ready | The server can return `input_required`, including elicitation, sampling, or roots requests. Current Premiere workflows use explicit preview/apply tools and do not yet require an interactive mid-call round trip. |
|
||||
| Required result discriminators | Implemented by serving entries | SDK v2 emits `resultType: "complete"` for ordinary modern-era results and preserves the legacy codec for older clients. |
|
||||
| Extension capability framework | Implemented | Discovery advertises `io.github.leancoderkavy/premiere-pro` with the protocol revision, transports, dual-era posture, and CEP/UXP bridge backends. |
|
||||
| Cancellation | Implemented by serving entries | Modern HTTP cancellation closes the request response stream; stdio and legacy clients retain their era-appropriate cancellation behavior. Premiere host calls remain cooperatively cancellable only where the Adobe API exposes a safe cancellation point. |
|
||||
| Progress notifications | Protocol-supported, not currently emitted | The serving entries accept request-scoped progress tokens. Existing Premiere tools return bounded final receipts and do not claim granular progress that the CEP/UXP host cannot prove. |
|
||||
| OpenTelemetry trace context | Transport pass-through | SDK v2 preserves the standard `traceparent`, `tracestate`, and `baggage` `_meta` keys. Application telemetry remains privacy-bounded and does not record tool arguments, results, media names, or paths. |
|
||||
| JSON Schema 2020-12 inputs and outputs | Implemented | Tool inputs use typed Zod schemas and every registered tool declares a validated output schema with structured content. No custom `x-mcp-header` parameters are currently required. |
|
||||
| Structured tool results | Implemented | Every tool declares one output schema and returns stable `structuredContent` plus human-readable content; frame capture can also return an image block. |
|
||||
| Tool annotations | Implemented | Read-only, destructive, idempotent, open-world, and title hints are derived per tool. |
|
||||
| Resources | Implemented | Four static guidance resources and ten bounded, path-redacted live Premiere context resources are registered. |
|
||||
| Prompts | Implemented | Eleven safety-oriented Premiere workflow prompts are registered with typed arguments. |
|
||||
| Tool discovery controls | Implemented | Capability profiles remove unauthorized tools from `tools/list`; optional workflow packs reduce context without expanding authority. |
|
||||
| Cursor pagination | Supported, not currently needed | The SDK accepts cursor-bearing list requests. The current bounded registries fit in one deterministic page and therefore return no `nextCursor`. |
|
||||
| Resource templates | Not currently exposed | All current resources have stable, bounded URIs. A template would create no repository-fit benefit until an authorized parameterized resource family exists. |
|
||||
| Completions | Not currently exposed | Current prompt arguments are free-form goals/constraints and resources are fixed URIs, so the server does not advertise low-value or path-leaking suggestions. |
|
||||
| Resource subscriptions and list-change events | Available, currently quiescent | `subscriptions/listen` is served, but the registered catalogs are immutable for a process lifetime and live Premiere resources are read on demand. No false change events are emitted. |
|
||||
| Embedded resources and resource links | Supported result types, selectively unused | The result codec supports them. Local Premiere artifacts are not converted into links until a contained, authorization-scoped artifact registry can guarantee access and expiry. |
|
||||
| Text, image, audio, and binary content blocks | Partially used | Text and structured content are standard; verified frame capture may return image content. The server does not synthesize audio or expose arbitrary local binary blobs. |
|
||||
|
||||
## Deliberate boundaries
|
||||
|
||||
| Surface | Status | Reason |
|
||||
| --- | --- | --- |
|
||||
| Tasks extension (`io.modelcontextprotocol/tasks`) | Not implemented | Current bridge calls are bounded request/response operations. Advertising durable tasks without durable, authorization-scoped storage, TTL cleanup, cancellation, and result recovery would be misleading. |
|
||||
| OAuth resource-server authorization | Implemented for trusted operators, externally provisioned | HTTP validates signed access tokens by exact issuer, canonical audience, lifetime, allowlisted subject, and scope and publishes RFC 9728 protected-resource metadata. A separately configured authorization server owns login, consent, token issuance, and MCP client registration; this repository does not issue tokens or route public users to their own desktops. |
|
||||
| OAuth Client ID Metadata Documents | Authorization-server responsibility | The resource server advertises its configured authorization server. That external service must support the registration mechanism required by the connecting MCP clients; this repository does not claim to operate CIMD or client registration. |
|
||||
| Enterprise Managed Authorization | Not implemented | No enterprise identity-policy provider is configured in this repository. |
|
||||
| MCP Apps | Not implemented | Premiere UI is delivered through CEP/UXP, not an MCP App resource. |
|
||||
| Skills over MCP | Experimental, not advertised | The repository ships client-specific local skills, but the Skills over MCP working group is still defining interoperable discovery and distribution. Local skill packaging is not claimed as protocol support. |
|
||||
| Sampling, roots, and protocol logging capabilities | Not advertised | These legacy server/client capabilities are deprecated in `2026-07-28`. The server avoids introducing new dependencies on them; MRTR is the supported path if a future workflow needs client input. |
|
||||
| Dynamic Client Registration | Not implemented | DCR is deprecated in the current protocol revision. |
|
||||
| Server Card / `.well-known` discovery | Experimental roadmap item | The Server Card working group has not finalized a stable metadata contract. The existing MCP Registry manifest remains the public machine-readable discovery surface. |
|
||||
|
||||
## Complete 2026-07-28 change checklist
|
||||
|
||||
The release-specific implementation audit covers every normative change category in
|
||||
the official changelog:
|
||||
|
||||
- **State and lifecycle:** no modern handshake, no protocol sessions, no
|
||||
`Mcp-Session-Id`, per-request version/capability metadata, and `server/discover`.
|
||||
- **Transport:** Streamable HTTP POST responses, no modern GET/SSE control channel,
|
||||
no modern SSE resume IDs, validated `Mcp-Method`/`Mcp-Name`, and optional
|
||||
`Mcp-Param-*` support through schema declarations.
|
||||
- **Results and interactivity:** required result discriminators, MRTR-capable codecs,
|
||||
request-scoped progress/cancellation, and `subscriptions/listen`.
|
||||
- **Discovery and schemas:** deterministic lists, `ttlMs`/`cacheScope`, cursor-ready
|
||||
list operations, JSON Schema 2020-12 inputs/outputs, annotations, and structured
|
||||
content.
|
||||
- **Extensions:** a declared Premiere extension plus explicit non-advertisement of
|
||||
Tasks, MCP Apps, enterprise authorization, and experimental Skills/Server Card
|
||||
surfaces that the product does not safely implement.
|
||||
- **Authorization and deprecations:** HTTP supports either controlled operator-token
|
||||
authentication or fail-closed OAuth resource-server validation and RFC 9728
|
||||
discovery; login, consent, token issuance, and CIMD remain the configured external
|
||||
authorization server's responsibility; new Roots, Sampling, Logging, DCR, or HTTP+SSE dependencies are not
|
||||
introduced.
|
||||
|
||||
## Product capability surface
|
||||
|
||||
The MCP protocol upgrade does not manufacture new Adobe host APIs. The product surface remains the registered catalog reported by `get_capabilities`, with authority, backend, minimum Premiere version, support status, and verification boundary for every tool. CEP/ExtendScript is the production bridge; UXP remains capability-aware preview coverage where documented. Contract tests do not replace licensed-Premiere host evidence.
|
||||
|
||||
Call `get_capabilities` to retrieve the current machine-readable MCP protocol posture, cache policy, active tool packs, complete registered-tool report, bridge coverage, authority profile, and host-verification requirements.
|
||||
|
||||
## Authoritative research sources
|
||||
|
||||
- [MCP 2026-07-28 release](https://blog.modelcontextprotocol.io/posts/2026-07-28/)
|
||||
- [MCP 2026-07-28 specification](https://modelcontextprotocol.io/specification/2026-07-28)
|
||||
- [MCP 2026-07-28 changelog](https://modelcontextprotocol.io/specification/2026-07-28/changelog)
|
||||
- [Official TypeScript SDK v2](https://github.com/modelcontextprotocol/typescript-sdk)
|
||||
- [TypeScript SDK protocol-era guide](https://github.com/modelcontextprotocol/typescript-sdk/blob/main/docs/protocol-versions.md)
|
||||
Executable
+92
@@ -0,0 +1,92 @@
|
||||
# Guarded After Effects MOGRT authoring
|
||||
|
||||
This repository can author and route bounded MOGRT workflows from After
|
||||
Effects into Premiere. It does not turn the MCP server into a general-purpose
|
||||
After Effects scripting endpoint, and it does not claim that a generated file
|
||||
has correct animation, editable controls, Premiere compatibility, visual
|
||||
quality, or completed-render output.
|
||||
|
||||
## What is supported
|
||||
|
||||
The template library provides five deterministic recipes: `lower_third`,
|
||||
`title_card`, `callout`, `quote_card`, and `social_end_card`. Each creates one
|
||||
comp in the already open, saved After Effects project, adds bounded headline and
|
||||
optional subtitle text plus an accent Color Control, then attempts to expose
|
||||
those controls in Essential Graphics before requesting the MOGRT export.
|
||||
|
||||
An optional `brand_kit` can constrain template naming with a prefix, supply
|
||||
approved accent/text colors, request a font by name, position content within a
|
||||
safe margin, and add an approved, workspace-contained PNG/JPEG logo. Font
|
||||
availability is resolved by After Effects at creation time; the preview cannot
|
||||
prove it is installed.
|
||||
|
||||
The base path remains constrained:
|
||||
|
||||
1. `verify_after_effects_connection` is read-only and returns only connector,
|
||||
host-version, saved-project, and project-item-count state.
|
||||
2. `preview_mogrt_recipe` validates a bounded recipe and an existing output
|
||||
directory within an operator-approved workspace. It issues a one-time token
|
||||
that expires after ten minutes.
|
||||
3. `create_mogrt_recipe` consumes that token only when `confirm_export` is
|
||||
explicitly true. It requires `edit`, `export`, and `filesystem` authority.
|
||||
4. `verify_mogrt_artifact` checks local file presence and the ZIP header only.
|
||||
|
||||
The studio tools extend this without widening authority:
|
||||
|
||||
- `preview_mogrt_batch` and `create_mogrt_batch` process up to 20 JSON/CSV
|
||||
rows serially. The batch stops at a host failure and cannot roll back earlier
|
||||
compositions or exports.
|
||||
- `validate_mogrt_brand_kit` validates a declared local kit before its preview.
|
||||
- `inspect_after_effects_template_source` returns source-comp dimensions,
|
||||
duration, fonts, layer kinds, and (on AE 16.1+) Essential Graphics controller
|
||||
names. Older hosts report this readback as unavailable.
|
||||
- `preview_mogrt_library_publish`, `publish_mogrt_to_library`, and
|
||||
`inspect_mogrt_library` manage immutable `v001`, `v002`, … copies inside an
|
||||
existing local library root; publication fails instead of overwriting.
|
||||
- `inspect_after_effects_render_templates`, `preview_after_effects_render`,
|
||||
and `enqueue_after_effects_render` read template names and enqueue one
|
||||
approved output. They never start the render queue or claim an output file.
|
||||
- `preview_mogrt_premiere_handoff` and `apply_mogrt_premiere_handoff` require
|
||||
an explicit `MOGRT Verify - …` sequence name and empty track, then verify the
|
||||
import and returned control descriptors in Premiere.
|
||||
|
||||
## Install and host preparation
|
||||
|
||||
Install the dedicated connector—not the Premiere connector—and fully restart
|
||||
After Effects:
|
||||
|
||||
```bash
|
||||
premiere-pro-mcp --install-after-effects-cep
|
||||
```
|
||||
|
||||
Open **Window > Extensions > MCP for Adobe After Effects**, then start the
|
||||
connector. It uses `AFTER_EFFECTS_MCP_TEMP_DIR`, defaulting to the OS temporary
|
||||
directory plus `after-effects-mcp-bridge`. That is intentionally distinct from
|
||||
`PREMIERE_TEMP_DIR`, so simultaneous Premiere and After Effects instances cannot
|
||||
claim each other's commands.
|
||||
|
||||
Before calling the create tool, the operator must open a saved `.aep` project
|
||||
that is itself inside `approved_workspace_path`; the planned output directory
|
||||
must already exist inside that same root. The tool rejects unsaved projects,
|
||||
projects outside the root, non-existent directories, outside paths, and an
|
||||
existing output filename. It never creates or switches projects, creates output
|
||||
directories, overwrites an existing MOGRT, or accepts arbitrary script text.
|
||||
|
||||
## Verification boundary
|
||||
|
||||
After Effects reports that it accepted the export request, and the server then
|
||||
reports immediate local artifact status. A returned boolean or an existing ZIP
|
||||
file is not proof of controls, import behavior, rendering, or design. The
|
||||
Premiere handoff is stronger evidence—it rechecks the named empty sequence,
|
||||
observes inserted track items, and returns control descriptors—but it still is
|
||||
not a visual proof. The required completion evidence is:
|
||||
|
||||
1. Verify the `.mogrt` file locally.
|
||||
2. Import it into a disposable Premiere sequence.
|
||||
3. Inspect the exposed properties and capture a rendered review frame with the
|
||||
existing `capture_frame` tool or a separate approved export workflow.
|
||||
4. Only then treat the template as usable for delivery.
|
||||
|
||||
Automated tests cover the bridge isolation, schema bounds, workspace containment,
|
||||
one-time approval, and artifact-check contracts. They do not substitute for a
|
||||
licensed After Effects and Premiere host run.
|
||||
Executable
+79
@@ -0,0 +1,79 @@
|
||||
# Native SDK header-inventory receipt
|
||||
|
||||
Adobe's public Hybrid Plugin guide identifies the UXP Hybrid SDK's `src/api`
|
||||
and `src/utilities` headers, but the SDK itself is downloaded from the Adobe
|
||||
Developer Console. Adobe likewise distributes the standalone Premiere Pro C++
|
||||
PrSDK and its documentation through the Developer Console. Neither artifact is
|
||||
present in this repository, so neither is treated as an implementation source.
|
||||
|
||||
`npm run native:sdk-header-inventory` provides a fail-closed, local receipt for
|
||||
a personally authorized SDK download. It records only relative header paths,
|
||||
byte counts, and SHA-256 hashes; it does not copy header contents, native
|
||||
sources, binary artifacts, or absolute local paths into the output.
|
||||
|
||||
```powershell
|
||||
npm run native:sdk-header-inventory -- `
|
||||
--sdk uxp-hybrid `
|
||||
--sdk-version <SDK version> `
|
||||
--archive C:\sdk-evidence\uxp-hybrid-sdk.zip `
|
||||
--sdk-root C:\sdk-evidence\uxp-hybrid-sdk `
|
||||
--output C:\sdk-evidence\uxp-hybrid-headers.json
|
||||
```
|
||||
|
||||
For `uxp-hybrid`, the command requires the public-guide layout:
|
||||
`src/api/UxpAddonTypes.h`, `src/api/UxpAddonShared.h`, and
|
||||
`src/utilities/UxpAddon.h`. The archive is hashed directly, while every header
|
||||
is hashed independently. `--check` compares a regenerated receipt with a
|
||||
reviewed one; `--validate-only` verifies the supplied artifact without writing.
|
||||
|
||||
Use the standalone verifier when a reviewer needs to inspect a receipt without
|
||||
receiving the SDK extraction or archive. It rejects extra fields (including
|
||||
header contents and absolute paths), inconsistent totals, non-canonical or
|
||||
duplicate paths, malformed digest fields, and Hybrid receipts missing the public-guide
|
||||
headers:
|
||||
|
||||
```powershell
|
||||
npm run native:sdk-header-inventory:verify -- `
|
||||
--input C:\sdk-evidence\uxp-hybrid-headers.json
|
||||
```
|
||||
|
||||
For a Hybrid benchmark candidate, append `--print-canonical-sha256` and copy
|
||||
only the resulting lowercase digest into `sdkHeaderReceiptSha256` in the
|
||||
benchmark evidence:
|
||||
|
||||
```powershell
|
||||
npm run native:sdk-header-inventory:verify -- `
|
||||
--input C:\sdk-evidence\uxp-hybrid-headers.json `
|
||||
--print-canonical-sha256
|
||||
```
|
||||
|
||||
The receipt itself stays in the authorized local evidence location and is
|
||||
supplied separately to the benchmark verifier; this repository does not receive
|
||||
the SDK extraction or archive.
|
||||
|
||||
This checks receipt structure and declared provenance only. It cannot verify
|
||||
the private archive bytes, compile the SDK, or establish that an addon can load
|
||||
in Premiere.
|
||||
|
||||
For `premiere-prsdk`, pass each documented include directory explicitly because
|
||||
Adobe does not publicly publish a stable header layout:
|
||||
|
||||
```powershell
|
||||
npm run native:sdk-header-inventory -- `
|
||||
--sdk premiere-prsdk `
|
||||
--sdk-version <SDK version> `
|
||||
--archive C:\sdk-evidence\premiere-prsdk.zip `
|
||||
--sdk-root C:\sdk-evidence\premiere-prsdk `
|
||||
--include-dir <documented include directory> `
|
||||
--output C:\sdk-evidence\premiere-prsdk-headers.json
|
||||
```
|
||||
|
||||
The receipt is header-file accounting, not complete C++ declaration parsing. It
|
||||
does not prove entitlement, a native build, a `.uxpaddon`, manifest permission,
|
||||
MCP exposure, or behavior in a licensed Premiere host. A later native change
|
||||
must separately provide source, reproducible builds, signing/notarization where
|
||||
applicable, authenticated installation, and the existing licensed-host gate.
|
||||
|
||||
Official references: [Hybrid Plugins](https://developer.adobe.com/premiere-pro/uxp/plugins/hybrid-plugins/),
|
||||
[Building Hybrid Plugins](https://developer.adobe.com/premiere-pro/uxp/plugins/hybrid-plugins/build/),
|
||||
and [Premiere developer access](https://developer.adobe.com/premiere-pro/access-the-developer-console/).
|
||||
Executable
+133
@@ -0,0 +1,133 @@
|
||||
# Next improvement pull-request roadmap
|
||||
|
||||
- **Status:** Active planning roadmap
|
||||
- **Updated:** 2026-09-04
|
||||
- **Current baseline:** `premiere-pro-mcp@1.14.7`
|
||||
|
||||
## Purpose
|
||||
|
||||
The server now has 328 registered core tools, 326 tools under the default
|
||||
authority profile, and 91 authenticated UXP additions. The next useful gains
|
||||
are dependable outcomes, evidence-backed recovery, and clearer public truth—not
|
||||
another undifferentiated increase in tool count.
|
||||
|
||||
This roadmap is deliberately not an implementation or compatibility claim.
|
||||
Every host mutation and compatibility statement still needs the appropriate
|
||||
licensed-host evidence.
|
||||
|
||||
## Delivery rules
|
||||
|
||||
1. Preserve the authority sequence: inspect, propose, preview, approve, apply,
|
||||
verify, then issue a receipt.
|
||||
2. Keep local context and imported evidence opt-in, revision-bound, and free of
|
||||
credentials, native paths, and unrelated customer data.
|
||||
3. Never silently replay a failed UXP mutation through CEP or QE.
|
||||
4. Treat structural readback, playback review, rendered-output review, and
|
||||
publication as separate evidence levels.
|
||||
5. Do not manufacture host evidence, product walkthroughs, or external review
|
||||
claims. A not-run result is useful and honest.
|
||||
6. Keep public metadata generated from canonical release metadata and validate
|
||||
it in CI before it can drift across release surfaces.
|
||||
|
||||
## Recommended dependency order
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
P1["PR 1: public truth and proof kit"] --> P4["PR 4: workflow evidence import"]
|
||||
P2["PR 2: caption timing preview"] --> P3["PR 3: guided lecture captions"]
|
||||
P4 --> P5["PR 5: published host evidence"]
|
||||
P6["PR 6: previewable doctor repairs"] --> P3
|
||||
```
|
||||
|
||||
PRs 1, 2, and 6 are independent. PR 3 should consume the timing-plan contract
|
||||
from PR 2. PR 4 must keep the existing project-context revision rules. PR 5 is
|
||||
blocked until a real, fixture-only licensed-host run is available.
|
||||
|
||||
## PR 1 — Public product truth and workflow-proof scaffolding
|
||||
|
||||
- Generate a machine-readable public product manifest from current release,
|
||||
package, and registry metadata.
|
||||
- Define four outcome-oriented workflows and their separate verification
|
||||
boundaries.
|
||||
- Publish a redacted workflow-proof runbook and receipt template.
|
||||
- Link independent user reports as historical coverage, with no implication
|
||||
that their versions, counts, or host results are current.
|
||||
|
||||
**Acceptance:** `npm run product-manifest:check` fails on metadata drift. The
|
||||
proof kit names no video or host receipt until one is actually recorded.
|
||||
|
||||
## PR 2 — Caption timing analysis and correction preview
|
||||
|
||||
- Parse a caller-provided SRT or VTT artifact without contacting Premiere or a
|
||||
provider.
|
||||
- Compare caption timing to an explicit target duration and distinguish a
|
||||
constant offset from accumulating drift.
|
||||
- Reject invalid timecodes, overlaps, and impossible scaling.
|
||||
- Emit a bounded, deterministic correction preview with an opaque plan ID.
|
||||
|
||||
**Acceptance:** the analysis is read-only; it never modifies an artifact or a
|
||||
Premiere sequence, and unit tests cover malformed files, overlap, offset,
|
||||
drift, and boundary samples.
|
||||
|
||||
## PR 3 — Guided lecture-caption workflow
|
||||
|
||||
- Turn a verified caption plan into a checklist for duplicate/test-sequence
|
||||
import, caption-track readback, and beginning/middle/end review frames.
|
||||
- Keep actual import and sequence mutation under existing tool authority and
|
||||
confirmation contracts.
|
||||
- Return `structural_readback` separately from playback or rendered-output
|
||||
verification.
|
||||
|
||||
**Acceptance:** the guide is usable with an existing artifact and never claims
|
||||
that importing captions establishes timing readability or rendered quality.
|
||||
|
||||
## PR 4 — Revision-bound editorial evidence import
|
||||
|
||||
- Add a schema for explicit transcript passages, speaker labels, shot logs,
|
||||
audio observations, operator notes, and frame references.
|
||||
- Require source/timeline revision guards where a record attaches to a source
|
||||
or sequence.
|
||||
- Normalize bounded metadata and refuse credentials, paths, and unsupported
|
||||
analysis shapes.
|
||||
- Feed only saved local evidence into `create_editorial_context_pack`.
|
||||
|
||||
**Acceptance:** imports are local-only, revision-bound, and safe to use with
|
||||
the existing context-pack/plan flow. They do not invoke vision, ASR, LLM, or
|
||||
Adobe services.
|
||||
|
||||
## PR 5 — Fixture-only licensed-host workflow evidence
|
||||
|
||||
- Execute the proof runbook on supported operating systems with disposable
|
||||
fixtures.
|
||||
- Retain redacted before/after/Undo evidence, structural results, and separate
|
||||
playback or render review when claimed.
|
||||
- Publish a short walkthrough only after a reviewer verifies the fixture-only
|
||||
evidence bundle.
|
||||
|
||||
**Gate:** no release or documentation claim widens until actual host evidence
|
||||
exists for the exact backend, Premiere version, and operation shown.
|
||||
|
||||
## PR 6 — Previewable `--doctor` repair plans
|
||||
|
||||
- Give each local readiness failure a stable diagnostic code.
|
||||
- Add `--doctor --plan-fixes` to display a no-write repair plan.
|
||||
- Add `--doctor --apply-fixes` only for safe, explicitly listed local repairs,
|
||||
with backups and post-repair verification.
|
||||
- Keep host state, project state, tokens, paths, and raw configuration out of
|
||||
the doctor report and repair plan.
|
||||
|
||||
**Acceptance:** a repair plan cannot report Premiere connected, cannot open a
|
||||
project, and cannot repair a host-side condition it did not observe.
|
||||
|
||||
## Success measures
|
||||
|
||||
- Time from install to the first safely verified workflow step.
|
||||
- Local readiness failure rate, diagnostic-code distribution, and successful
|
||||
recovery rate without collecting private project data.
|
||||
- Caption-plan validity and review completion rate, tracked only with approved
|
||||
bounded telemetry.
|
||||
- Host evidence coverage by exact Premiere version, backend, operating system,
|
||||
and verification level.
|
||||
|
||||
Stars, raw downloads, and changing tool counts are discovery signals, not
|
||||
evidence that an editor completed a safe workflow.
|
||||
@@ -0,0 +1,61 @@
|
||||
# Boas práticas de UI para os nossos painéis (CEP/UXP)
|
||||
|
||||
Padrão a seguir em qualquer tela nova ou existente deste projeto
|
||||
(`cep-plugin/`, `uxp-plugin/`, `chat-plugin/` e afins). Escrito depois de um
|
||||
caso real: o painel `cep-plugin` ficou sem scroll e com fonte grande demais
|
||||
ao adicionarmos a aba "Cortar silêncio", cortando conteúdo fora da vista.
|
||||
|
||||
## 1. Scroll sempre habilitado
|
||||
|
||||
Painéis do Premiere/Adobe rodam num container de tamanho variável e
|
||||
imprevisível (o usuário pode redimensionar o painel, encaixá-lo, ou o
|
||||
conteúdo pode crescer com o tempo — abas, listas, logs). **Nunca assumir que
|
||||
tudo cabe na tela.**
|
||||
|
||||
- O container raiz do painel (ex: `.panel-shell`) deve ter:
|
||||
```css
|
||||
overflow-y: auto;
|
||||
overflow-x: hidden;
|
||||
```
|
||||
- `height: 100%` continua correto — o scroll é vertical, dentro da altura
|
||||
disponível, não uma altura fixa maior que a tela.
|
||||
- Não usar `overflow: hidden` no elemento que contém o conteúdo real do
|
||||
painel (pode ficar em `body` como reset, mas o container interno com o
|
||||
conteúdo precisa poder rolar).
|
||||
|
||||
## 2. Tamanho de fonte
|
||||
|
||||
Painéis CEP/UXP são compactos por natureza (encaixados em painéis estreitos
|
||||
do Premiere). O padrão desta base é fonte **10% menor** que o tamanho "web
|
||||
normal" para caber mais informação sem parecer apertado:
|
||||
|
||||
- Fonte base do `body`: `10.8px` (era `12px`, reduzida em 10%).
|
||||
- Qualquer `font-size` declarado explicitamente em outro seletor deve seguir
|
||||
a mesma proporção (multiplicar o valor "normal" por `0.9`).
|
||||
- Ao adicionar um elemento novo com fonte própria, comece do tamanho que
|
||||
pareceria natural numa web app comum e aplique o fator `× 0.9`.
|
||||
|
||||
## 3. Ao criar uma aba/seção nova
|
||||
|
||||
- Reaproveitar as classes existentes (`.config-section`, `.section-heading`,
|
||||
`.action-row`, `.field-help`, `.button`, `.log-entry` com `ok`/`err`) em
|
||||
vez de inventar estilos novos — mantém a tela inteira visualmente
|
||||
consistente.
|
||||
- Toda seção com log/atividade deve ter altura própria com scroll interno
|
||||
quando fizer sentido (ex: `#log`, `#silenceLog`), mas isso não substitui o
|
||||
scroll do painel inteiro — os dois podem coexistir.
|
||||
|
||||
## 4. Depois de editar o painel CEP, sempre reinstalar
|
||||
|
||||
O Premiere carrega o painel de uma **cópia instalada** em
|
||||
`~/Library/Application Support/Adobe/CEP/extensions/MCPBridgeCEP/`, não
|
||||
direto da pasta `cep-plugin/` deste repositório. Editar os arquivos fonte
|
||||
não é suficiente — é preciso rodar:
|
||||
|
||||
```bash
|
||||
node dist/index.js --install-cep
|
||||
```
|
||||
|
||||
(ou `admin/PremiereMCP.command`, que já faz isso automaticamente) e depois
|
||||
**reiniciar o Premiere Pro por completo** — o painel não recarrega sozinho
|
||||
nem com um simples fechar/abrir da aba.
|
||||
Executable
+7
@@ -0,0 +1,7 @@
|
||||
# Adobe Premiere UXP documentation inventory
|
||||
|
||||
`src/resources/premiere-doc-inventory.json` is generated from Adobe Developer's live sitemap. It accounts for every URL under `/premiere-pro/uxp/` and classifies each page as Premiere DOM, UXP JavaScript, HTML, CSS, Spectrum, plugin guides, or supporting Premiere UXP documentation.
|
||||
|
||||
Run `npm run premiere:docs-inventory` to refresh the artifact. CI runs `npm run premiere:docs-inventory:check`, fetches the authoritative sitemap, and fails if Adobe adds, removes, reclassifies, or changes the `lastmod` value of a page.
|
||||
|
||||
Page inventory is documentation coverage only. It does not imply that every documented API should be exposed as an MCP tool, that the panel implements every UI feature, or that a capability has been validated in a licensed Premiere host.
|
||||
Executable
+105
@@ -0,0 +1,105 @@
|
||||
# Premiere API and documentation surface registry
|
||||
|
||||
The machine-readable source is
|
||||
`src/resources/premiere-surface-registry.json`; npm consumers receive it at
|
||||
`dist/resources/premiere-surface-registry.json`. It prevents the generated
|
||||
Premiere DOM declaration inventory from being mistaken for all Adobe
|
||||
extensibility documentation.
|
||||
|
||||
Adobe separates the Premiere DOM from the general UXP JavaScript runtime,
|
||||
supported HTML/CSS, Spectrum components, plugin guides, and the downloadable
|
||||
Hybrid C++ SDK. Adobe's separately distributed Premiere Pro C++ PrSDK covers
|
||||
native importers, exporters, effects, transitions, devices, and related plug-ins;
|
||||
it is not the same SDK as a UXP Hybrid addon. This project also retains CEP/ExtendScript compatibility and
|
||||
uses explicitly experimental QE behavior, for which Adobe publishes no
|
||||
authoritative reference.
|
||||
|
||||
The stable Premiere DOM and general UXP JavaScript declarations have complete
|
||||
symbol inventories. Adobe's live sitemap supplies a complete page inventory
|
||||
for HTML, CSS, Spectrum, plugin guides, and supporting UXP documentation.
|
||||
The pinned community Premiere scripting guide also has a complete member
|
||||
inventory, explicitly labeled as non-Adobe authority and not runtime proof.
|
||||
The [beta AAFExportOptions declaration receipt](adobe-beta-aaf-export-options-drift.md)
|
||||
records a beta-only factory-type migration without constructing export options,
|
||||
exposing an AAF-export operation, or claiming export behavior in any host.
|
||||
The [beta project-options declaration receipt](adobe-beta-project-options-drift.md)
|
||||
records beta factory-type migrations without constructing project options,
|
||||
opening or closing projects, or claiming lifecycle behavior in any host.
|
||||
The [beta transition-options declaration receipt](adobe-beta-transition-options-drift.md)
|
||||
records its factory migration without constructing options, applying a
|
||||
transition, or claiming transition behavior in any host.
|
||||
The [beta RectF declaration receipt](adobe-beta-rectf-drift.md) records its
|
||||
factory migration without constructing geometry, binding it to another API, or
|
||||
claiming host behavior.
|
||||
The [beta Color declaration receipt](adobe-beta-color-drift.md) records its
|
||||
factory migration without constructing a color, changing the stable Color
|
||||
workflow, binding it to another API, or claiming host behavior.
|
||||
The [beta PointF declaration receipt](adobe-beta-pointf-drift.md) records its
|
||||
factory migration without constructing a point, changing the stable PointF
|
||||
workflow, binding it to another API, or claiming host behavior.
|
||||
The [beta Guid declaration receipt](adobe-beta-guid-drift.md) records its
|
||||
factory-placement migration without constructing or parsing a GUID, changing
|
||||
existing GUID workflows, binding it to another API, or claiming host behavior.
|
||||
The [beta FrameRate declaration receipt](adobe-beta-frame-rate-drift.md) records
|
||||
its factory-placement migration without constructing a frame rate, changing
|
||||
existing frame-alignment or TickTime workflows, binding it to another API, or
|
||||
claiming host behavior.
|
||||
The [beta TickTime declaration receipt](adobe-beta-tick-time-drift.md) records
|
||||
its factory-placement migration without constructing a time value, changing
|
||||
existing TickTime arithmetic or frame-alignment workflows, binding it to
|
||||
another API, or claiming host behavior.
|
||||
The [beta Media drift receipt](adobe-beta-media-drift.md) separately records the
|
||||
pinned stable-to-beta `Media` declaration delta. It is deliberately not a beta
|
||||
surface inventory or beta-host support claim. The [beta C2PA declaration
|
||||
receipt](adobe-beta-c2pa-drift.md) records only the separate beta-only C2PA
|
||||
surface and does not expose a C2PA operation or claim a manifest can be read in
|
||||
any host. The [beta WorkAreaUtils declaration receipt](adobe-beta-work-area-drift.md)
|
||||
records the separate beta-only work-area surface without changing existing
|
||||
legacy work-area tools or claiming equivalent beta behavior.
|
||||
The [beta MediaManager declaration receipt](adobe-beta-media-manager-drift.md)
|
||||
records the separate beta-only cache-purge declaration without exposing a
|
||||
destructive cache operation or claiming host behavior.
|
||||
The [beta TranscriptStatic declaration receipt](adobe-beta-transcript-drift.md)
|
||||
records beta transcript additions without exposing transcription or claiming
|
||||
language-pack, transcript-content, or host behavior.
|
||||
Other remaining surfaces stay visibly partial, not started, externally gated,
|
||||
or unavailable from an authoritative source. Both C++ SDK
|
||||
inventories remain externally gated because their headers and packaged
|
||||
documentation require Adobe Developer Console access. An inventory is
|
||||
not implementation proof, and automated contracts are not licensed-host proof.
|
||||
|
||||
When an authorized SDK artifact becomes available, the
|
||||
[native SDK header-inventory receipt](native-sdk-header-inventory.md) can record
|
||||
its archive hash and relative header hashes without copying access-controlled
|
||||
files into this repository. That receipt leaves both C++ surfaces blocked until
|
||||
the relevant declaration classification, reproducible native build, and
|
||||
licensed-host evidence are supplied. A future Hybrid benchmark must also bind
|
||||
its submitted runs to matching verified SDK, addon-layout, and current local
|
||||
CCX receipts, as described by the [Hybrid benchmark gate](uxp-hybrid-benchmark.md);
|
||||
the digest binding is not a native-build or host-behavior claim. A temporary development bundle can also
|
||||
produce a [Hybrid addon-layout receipt](uxp-hybrid-addon-receipt.md) for the
|
||||
public root `main.js` entrypoint and three target paths without disclosing
|
||||
source or binaries; it is still not binary architecture, signing, loading, or
|
||||
runtime proof. A subsequent [Hybrid CCX archive receipt](uxp-hybrid-ccx-receipt.md)
|
||||
can bind those public layout facts to the matching files and a content-free safe
|
||||
ZIP entry-name-set digest in a local `.ccx` ZIP without disclosing archive
|
||||
contents or entry names, while rejecting inconsistent or feature-insufficient
|
||||
local ZIP version-needed, Deflate-only compression-option flags, framed non-ZIP64 extra fields, and core header fields, unaccounted local-record or central-directory-to-end
|
||||
bytes, ambiguous non-ASCII entry-name encodings or declared UTF-8 file comments, and declared Unix special file
|
||||
types, nonempty directory entries, or nonzero directory CRC-32 values. It is not UDT,
|
||||
portal, installation, or host-runtime proof. Where a ZIP entry uses a streamed
|
||||
data descriptor, the local archive verifier also checks its required CRC and
|
||||
sizes against the central directory without extracting unselected contents. The
|
||||
verifier also recomputes ZIP CRC-32 for the already-required manifest,
|
||||
entrypoint, and addon payloads; it does not decompress unselected entries.
|
||||
Deflated required entries must also consume their exact declared compressed-data
|
||||
range, rejecting unused trailing bytes without reading unselected entries. The
|
||||
verifier rejects encrypted-entry,
|
||||
central-directory-encryption, and other unsupported general-purpose flags, as
|
||||
well as ZIP64 entry metadata, before reading required payloads.
|
||||
|
||||
The same registry pins the exact competitor commits reviewed for feature-gap
|
||||
work. A competitor feature family becomes an implementation candidate only
|
||||
after source inspection proves a current gap and a concrete workflow benefit.
|
||||
Unsafe arbitrary-code defaults, copied tool-count claims, and unverified host
|
||||
behavior are excluded from parity.
|
||||
Executable
+73
@@ -0,0 +1,73 @@
|
||||
# Project context engine
|
||||
|
||||
The project context engine reduces repeated clip, transcript, audio, and timeline
|
||||
analysis without placing customer footage or an entire Premiere project in every
|
||||
model prompt. It is an opt-in local index: no context is captured until an MCP
|
||||
client calls `manage_project_context`.
|
||||
|
||||
## Storage and runtime compatibility
|
||||
|
||||
`PREMIERE_CONTEXT_BACKEND=auto` prefers Node's built-in SQLite store when the
|
||||
runtime provides `node:sqlite`. Supported Node 20 environments fall back to an
|
||||
atomic JSON store without adding a native package dependency. Operators can force
|
||||
`sqlite`, `json`, or non-persistent `memory` behavior. `PREMIERE_CONTEXT_DIR`
|
||||
overrides the OS application-data directory.
|
||||
|
||||
The store persists project names, hashed project/media-path identities, bounded
|
||||
timeline metadata, and explicit enrichments. It does not persist native project or
|
||||
media paths. Enrichment metadata keys that resemble paths, passwords, tokens,
|
||||
secrets, or API keys are discarded.
|
||||
|
||||
## Recommended workflow
|
||||
|
||||
1. Call `manage_project_context` with `action: "capture"` while the intended
|
||||
sequence is active. Capture is bounded to 2,000 timeline items and returns the
|
||||
project, source, timeline, and combined context revisions.
|
||||
2. Analyze only the required sources. Add transcript passages, shot descriptions,
|
||||
audio observations, or editor notes through `action: "enrich"`. Include the
|
||||
returned source revision to reject stale analysis.
|
||||
For a structured, caller-approved bundle, use `action: "import_evidence"`.
|
||||
It accepts transcript passages and speaker labels, shot logs, audio
|
||||
observations, operator notes, and opaque frame-reference IDs. An attachment
|
||||
to a source requires the exact current source revision; an attachment to a
|
||||
sequence or timeline item requires the exact current timeline revision.
|
||||
3. Call `search_project_context` with the current editing intent and optional
|
||||
sequence/kind filters. Results contain evidence, stable Premiere identities,
|
||||
source time ranges, and revision provenance.
|
||||
4. Call `create_context_edit_plan` for a non-mutating candidate scaffold. Review
|
||||
every candidate, capture again if the timeline changed, and resolve exact
|
||||
identities before building timeline operations.
|
||||
5. Use `preview_edit_plan` before `apply_edit_plan`. The context plan is evidence,
|
||||
not mutation authority or proof that an editorial decision is correct.
|
||||
6. Clear local project context when it is no longer required.
|
||||
|
||||
## Revision and invalidation model
|
||||
|
||||
Source and timeline state are deliberately separate:
|
||||
|
||||
- A source revision uses stable project-item identity plus a hashed media path and,
|
||||
when the local server can stat the media, file size and modification time.
|
||||
- A timeline revision covers sequence identity, timeline-item identity, source
|
||||
in/out, sequence start/end, speed, media type, and track index.
|
||||
- The context revision covers both revisions plus all enrichment content.
|
||||
|
||||
Moving or trimming a timeline item changes the timeline revision but retains
|
||||
transcript, shot, and audio enrichments for unchanged source media. A changed or
|
||||
relinked source invalidates enrichments tied to the prior source revision. Event
|
||||
loss or an ambiguous state is recovered by capturing a fresh bounded snapshot.
|
||||
|
||||
## Analysis boundaries
|
||||
|
||||
Capture does not transcribe speech, infer speakers, detect shots, calculate
|
||||
loudness, or send footage to a model. Those analyses are explicit enrichments so
|
||||
operators can choose Premiere transcript export, local software, or an approved
|
||||
provider. Premiere's documented transcript APIs support transcript import/export;
|
||||
they do not expose a stable operation for starting Speech-to-Text.
|
||||
|
||||
`import_evidence` does not read the referenced frame, resolve a file path, or
|
||||
call vision, ASR, LLM, Adobe, or a third-party provider. A frame reference is
|
||||
restricted to an opaque identifier, and metadata resembling a path, credential,
|
||||
or secret is removed before the local context index is saved.
|
||||
|
||||
Automated tests validate storage, privacy, invalidation, retrieval, and plan
|
||||
contracts. They do not replace validation against a licensed Premiere host.
|
||||
+93
@@ -0,0 +1,93 @@
|
||||
{
|
||||
"$schema": "https://json-schema.org/draft/2020-12/schema",
|
||||
"$id": "urn:premiere-pro-mcp:project-intake-host-report:v1",
|
||||
"title": "Premiere Project Intake licensed-host evidence report",
|
||||
"description": "A privacy-safe, reviewer-facing evidence index for the preview-only Project Intake workflow. The repository validator adds case-specific and redaction checks beyond this portable schema.",
|
||||
"type": "object",
|
||||
"additionalProperties": false,
|
||||
"required": ["schemaVersion", "sourceCommit", "host", "client", "fixture", "privacy", "cases"],
|
||||
"properties": {
|
||||
"schemaVersion": { "const": "project-intake-host-report/v1" },
|
||||
"sourceCommit": { "type": "string", "pattern": "^[0-9a-fA-F]{40}$" },
|
||||
"host": {
|
||||
"type": "object",
|
||||
"additionalProperties": false,
|
||||
"required": ["os", "premiereVersion", "premiereBuild", "connector"],
|
||||
"properties": {
|
||||
"os": { "enum": ["Windows", "macOS"] },
|
||||
"premiereVersion": { "type": "string", "minLength": 1, "maxLength": 64 },
|
||||
"premiereBuild": { "type": "string", "minLength": 1, "maxLength": 64 },
|
||||
"connector": {
|
||||
"type": "object",
|
||||
"additionalProperties": false,
|
||||
"required": ["type", "buildHash"],
|
||||
"properties": {
|
||||
"type": { "const": "cep" },
|
||||
"buildHash": { "type": "string", "pattern": "^[0-9a-fA-F]{7,64}$" }
|
||||
}
|
||||
}
|
||||
}
|
||||
},
|
||||
"client": {
|
||||
"type": "object",
|
||||
"additionalProperties": false,
|
||||
"required": ["name", "version"],
|
||||
"properties": {
|
||||
"name": { "type": "string", "minLength": 1, "maxLength": 128 },
|
||||
"version": { "type": "string", "minLength": 1, "maxLength": 128 }
|
||||
}
|
||||
},
|
||||
"fixture": {
|
||||
"type": "object",
|
||||
"additionalProperties": false,
|
||||
"required": ["revision", "sha256"],
|
||||
"properties": {
|
||||
"revision": { "type": "string", "pattern": "^[a-zA-Z0-9][a-zA-Z0-9._-]{0,63}$" },
|
||||
"sha256": { "type": "string", "pattern": "^[0-9a-fA-F]{64}$" }
|
||||
}
|
||||
},
|
||||
"privacy": {
|
||||
"type": "object",
|
||||
"additionalProperties": false,
|
||||
"required": ["containsOnlyGeneratedFixtureData", "localPathsRemoved", "mediaNamesRemoved", "promptsRemoved", "transcriptsRemoved", "credentialsRemoved"],
|
||||
"properties": {
|
||||
"containsOnlyGeneratedFixtureData": { "const": true },
|
||||
"localPathsRemoved": { "const": true },
|
||||
"mediaNamesRemoved": { "const": true },
|
||||
"promptsRemoved": { "const": true },
|
||||
"transcriptsRemoved": { "const": true },
|
||||
"credentialsRemoved": { "const": true }
|
||||
}
|
||||
},
|
||||
"cases": {
|
||||
"type": "array",
|
||||
"minItems": 3,
|
||||
"maxItems": 3,
|
||||
"items": { "$ref": "#/$defs/case" }
|
||||
}
|
||||
},
|
||||
"$defs": {
|
||||
"evidence": {
|
||||
"type": "object",
|
||||
"additionalProperties": false,
|
||||
"required": ["kind", "reference", "sha256"],
|
||||
"properties": {
|
||||
"kind": { "type": "string", "minLength": 1, "maxLength": 64 },
|
||||
"reference": { "type": "string", "pattern": "^evidence://[a-zA-Z0-9][a-zA-Z0-9._-]{0,127}$" },
|
||||
"sha256": { "type": "string", "pattern": "^[0-9a-fA-F]{64}$" }
|
||||
}
|
||||
},
|
||||
"case": {
|
||||
"type": "object",
|
||||
"additionalProperties": false,
|
||||
"required": ["id", "status", "evidence"],
|
||||
"properties": {
|
||||
"id": { "enum": ["PIP-CONNECT-001", "PIP-PREVIEW-001", "PIP-NO-MUTATION-001"] },
|
||||
"status": { "enum": ["passed", "failed", "unsupported", "not_run"] },
|
||||
"executedAt": { "type": "string", "format": "date-time" },
|
||||
"assertions": { "type": "object" },
|
||||
"evidence": { "type": "array", "items": { "$ref": "#/$defs/evidence" } }
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
+34
@@ -0,0 +1,34 @@
|
||||
{
|
||||
"schemaVersion": "project-intake-host-report/v1",
|
||||
"sourceCommit": "0000000000000000000000000000000000000000",
|
||||
"host": {
|
||||
"os": "Windows",
|
||||
"premiereVersion": "26.0.0",
|
||||
"premiereBuild": "template-only",
|
||||
"connector": {
|
||||
"type": "cep",
|
||||
"buildHash": "0000000"
|
||||
}
|
||||
},
|
||||
"client": {
|
||||
"name": "template-client",
|
||||
"version": "template-only"
|
||||
},
|
||||
"fixture": {
|
||||
"revision": "generated-fixture-v1",
|
||||
"sha256": "0000000000000000000000000000000000000000000000000000000000000000"
|
||||
},
|
||||
"privacy": {
|
||||
"containsOnlyGeneratedFixtureData": true,
|
||||
"localPathsRemoved": true,
|
||||
"mediaNamesRemoved": true,
|
||||
"promptsRemoved": true,
|
||||
"transcriptsRemoved": true,
|
||||
"credentialsRemoved": true
|
||||
},
|
||||
"cases": [
|
||||
{ "id": "PIP-CONNECT-001", "status": "not_run", "evidence": [] },
|
||||
{ "id": "PIP-PREVIEW-001", "status": "not_run", "evidence": [] },
|
||||
{ "id": "PIP-NO-MUTATION-001", "status": "not_run", "evidence": [] }
|
||||
]
|
||||
}
|
||||
Executable
+76
@@ -0,0 +1,76 @@
|
||||
# Project Intake licensed-host validation
|
||||
|
||||
This runbook is the evidence gate for the v1.13.0, **preview-only**
|
||||
`preview_project_intake` workflow. It is not run by unit, contract, lint, or
|
||||
package checks. It does not authorize an apply workflow, because v1.13.0 does
|
||||
not provide one.
|
||||
|
||||
The 2026-08-22 Premiere 2026 attempt is recorded as blocked before CEP and MCP
|
||||
execution in [the host-validation record](industry/host-validation-2026-08-22.md).
|
||||
Do not transform that blocked attempt into a passing report or backfill a
|
||||
report from automated tests.
|
||||
|
||||
## What this report can establish
|
||||
|
||||
For one exact source commit, CEP panel build, Premiere build, operating system,
|
||||
client, and generated fixture, a completed report can index evidence that:
|
||||
|
||||
| Case | Required observed assertion | Required redacted evidence |
|
||||
| --- | --- | --- |
|
||||
| `PIP-CONNECT-001` | `verify_premiere_connection` returned `overall: "ready"`. | Structured connection-response digest. |
|
||||
| `PIP-PREVIEW-001` | `preview_project_intake` returned `applied: false`, `capture.pathDisclosure: "redacted"`, and `organizationPlan.applied: false`. | Structured preview-response digest. |
|
||||
| `PIP-NO-MUTATION-001` | The Project panel did not change and the project was not saved by the preview call. | Before and after Project-panel capture digests plus the structured preview-response digest. |
|
||||
|
||||
The report is an evidence index, not the evidence itself. Its references are
|
||||
opaque `evidence://` identifiers and SHA-256 digests; keep the separately
|
||||
redacted artifacts in the approved evidence store. A validator pass means only
|
||||
that a human reviewer has a complete, privacy-bounded package to inspect. It
|
||||
never makes a host, client, build, or workflow universally supported.
|
||||
|
||||
## Safe procedure
|
||||
|
||||
1. Start from the exact candidate source commit and record its full SHA. Do not
|
||||
reuse a report from another build.
|
||||
2. Use a generated disposable fixture with non-sensitive labels. Never open or
|
||||
save a customer project, and never use customer media, prompts, transcripts,
|
||||
or credentials as evidence.
|
||||
3. Capture redacted before state, then call `verify_premiere_connection` and
|
||||
`preview_project_intake` with `include_paths: false`. The preview must remain
|
||||
bounded and non-mutating. Do not call an organization apply tool as part of
|
||||
this runbook.
|
||||
4. Capture redacted after state before closing the fixture. If the host is
|
||||
unavailable, the bridge fails, the preview errors, or the before/after state
|
||||
differs, record the relevant case as `failed`, `unsupported`, or `not_run`.
|
||||
Do not retry a potentially uncertain host action as if it were idempotent.
|
||||
5. Copy [the versioned template](project-intake-host-report.template.json) out
|
||||
of source control. Replace only its non-sensitive provenance values and
|
||||
opaque evidence references. The template itself is deliberately `not_run`.
|
||||
6. Validate the shared report before review:
|
||||
|
||||
```bash
|
||||
npm run validate:project-intake-host-report -- path/to/redacted-report.json
|
||||
```
|
||||
|
||||
7. A human reviewer compares the evidence artifacts to the report, the exact
|
||||
source commit, and the linked [schema](project-intake-host-report.schema.json).
|
||||
Only that reviewer can decide whether the listed combination has enough
|
||||
evidence for a narrowly worded host-validation record.
|
||||
|
||||
## Privacy and failure-closed rules
|
||||
|
||||
- The report accepts no notes, project names, media names, native paths,
|
||||
prompts, transcripts, tokens, passwords, or arbitrary evidence locations.
|
||||
- All six privacy confirmations must be `true`; any local-path or
|
||||
credential-like content makes validation fail.
|
||||
- A passed preview case requires a separate passed no-mutation case. A preview
|
||||
response alone cannot establish that Premiere state remained unchanged.
|
||||
- Non-passing cases contain no evidence references in this minimal shared
|
||||
index. Retain any sensitive diagnostic artifacts only in the approved
|
||||
restricted store, not in a repository report.
|
||||
- This is CEP-specific because v1.13.0 Project Intake is validated through the
|
||||
CEP bridge. It neither proves UXP behavior nor permits CEP/QE mutation
|
||||
fallback.
|
||||
|
||||
See the broader [editorial host-validation runbook](editorial-workflow-host-validation.md)
|
||||
for mutation evidence rules. This Project Intake runbook is intentionally
|
||||
narrower: it tests only the current read-only preview contract.
|
||||
+37
@@ -0,0 +1,37 @@
|
||||
# Qualified licensed-Premiere run checklist
|
||||
|
||||
This is an owner-run release gate. It records a real, licensed Adobe Premiere host
|
||||
run; it is not satisfied by unit tests, a simulated connector, a package build, or a
|
||||
Marketplace review.
|
||||
|
||||
## Safe setup
|
||||
|
||||
- [ ] Use a copy of a generated, disposable fixture project in an approved workspace.
|
||||
Never open, save, or mutate a customer project for release evidence.
|
||||
- [ ] Record the candidate's full source SHA, MCP client/version, operating system,
|
||||
Premiere version/build, connector type and build hash, and fixture checksum.
|
||||
- [ ] Start with `verify_premiere_connection` and `get_version_info`; retain redacted
|
||||
structured output. A connection with no document or active sequence is useful
|
||||
diagnostic evidence, not a completed workflow run.
|
||||
- [ ] Capture a redacted before state. Exclude project paths, media names, prompts,
|
||||
credentials, and customer content.
|
||||
|
||||
## Required evidence
|
||||
|
||||
- [ ] Run the relevant row(s) in
|
||||
[editorial-workflow-host-validation.md](editorial-workflow-host-validation.md) on
|
||||
each Premiere/OS combination represented by the release claim.
|
||||
- [ ] For every mutating case, retain before and after captures, the structured
|
||||
response/readback, and proof that Undo restored the fixture.
|
||||
- [ ] Store the redacted report outside source control unless it contains only
|
||||
generated fixture data, then run
|
||||
`npm run validate:host-report -- path/to/redacted-report.json`.
|
||||
- [ ] A human reviewer accepts the host facts and evidence before marketing language
|
||||
changes from package-supported to host-verified.
|
||||
|
||||
## Release boundary
|
||||
|
||||
A passing report means the evidence package is complete enough for human review. It
|
||||
does not prove Marketplace approval, universal Premiere compatibility, or editorial
|
||||
quality. A failed, unsupported, or `not_run` matrix entry remains a valid recorded
|
||||
outcome and must not be replaced by a mock result.
|
||||
Executable
+16
@@ -0,0 +1,16 @@
|
||||
# Quick-start translations
|
||||
|
||||
[`en.md`](en.md) is the maintained English source. The translations preserve
|
||||
the same marked sections and are machine-assisted drafts, not certified
|
||||
translations. Technical command names, product names, and JSON keys remain in
|
||||
English where that prevents a setup error.
|
||||
|
||||
| Language | Guide | Review status |
|
||||
| --- | --- | --- |
|
||||
| English | [English](en.md) | Source |
|
||||
| Español | [Español](es.md) | Machine-assisted draft; community review welcome |
|
||||
| 日本語 | [日本語](ja.md) | Machine-assisted draft; community review welcome |
|
||||
|
||||
When changing the source, update every marked section in each listed locale and
|
||||
run `npm run docs:quickstart:check`. The check guards structure and links; a
|
||||
native speaker still reviews wording before a translation becomes authoritative.
|
||||
Executable
+70
@@ -0,0 +1,70 @@
|
||||
# Premiere MCP quick start
|
||||
|
||||
This is the maintained English source for the translated quick-start guides.
|
||||
Use it with the repository [README](../../README.md), which has the current
|
||||
download links and supported-version details.
|
||||
|
||||
<!-- quickstart:section=before-you-start -->
|
||||
## Before you start
|
||||
|
||||
Use a copy of a test project, not active client work. The local MCP server, the
|
||||
Premiere connector, and your AI client must run on the same computer. Start
|
||||
with a read-only connection check; installation and a green panel status do not
|
||||
prove an editing workflow has succeeded in a licensed host.
|
||||
|
||||
<!-- quickstart:section=install -->
|
||||
## Install the server and connector
|
||||
|
||||
For Claude Desktop, install the current `.mcpb` bundle and the separate signed
|
||||
Premiere connector from the current GitHub release. Restart both apps.
|
||||
|
||||
For another MCP client, install the server and then the CEP connector:
|
||||
|
||||
```bash
|
||||
npm install -g premiere-pro-mcp
|
||||
premiere-pro-mcp --install-cep
|
||||
```
|
||||
|
||||
Configure the client to run `premiere-pro-mcp`. The full README includes
|
||||
client-specific JSON examples.
|
||||
|
||||
<!-- quickstart:section=prove-connection -->
|
||||
## Prove the connection safely
|
||||
|
||||
1. Open Premiere, open the copied test project, and open an active sequence.
|
||||
2. In Premiere, choose **Window > Extensions > MCP for Adobe Premiere Pro**.
|
||||
“Running” means the panel bridge is available; it is not a completed-edit
|
||||
claim.
|
||||
3. Run the local preflight:
|
||||
|
||||
```bash
|
||||
premiere-pro-mcp --doctor
|
||||
```
|
||||
|
||||
4. Ask the AI client: `Run verify_premiere_connection. Make no changes.`
|
||||
|
||||
The local doctor reports package/configuration discovery. The MCP response
|
||||
reports the selected bridge, project, and sequence readiness without returning
|
||||
project details. Treat a failure or missing sequence as a setup result to fix,
|
||||
not as permission to retry a mutation.
|
||||
|
||||
<!-- quickstart:section=first-edit -->
|
||||
## Make the first edit deliberately
|
||||
|
||||
After the read-only check succeeds, ask for a bounded plan against the copied
|
||||
test sequence. Review the target, changes, and confirmation boundary before
|
||||
allowing an edit. Re-inspect the sequence afterwards and use Undo to verify the
|
||||
fixture returns to its previous state.
|
||||
|
||||
<!-- quickstart:section=remove -->
|
||||
## Remove the connector
|
||||
|
||||
Fully quit Premiere first, then remove only this CEP connector:
|
||||
|
||||
```bash
|
||||
premiere-pro-mcp --uninstall-cep
|
||||
```
|
||||
|
||||
This leaves Adobe's shared debug setting unchanged so other CEP extensions are
|
||||
not disrupted. Remove the MCP server from the AI client's configuration and
|
||||
uninstall the npm package separately if you no longer use it.
|
||||
Executable
+77
@@ -0,0 +1,77 @@
|
||||
# Inicio rápido de Premiere MCP
|
||||
|
||||
Esta es una traducción asistida por máquina del origen en
|
||||
[inglés](en.md); agradecemos la revisión de la comunidad. Úsela junto con el
|
||||
[README](../../README.md), que contiene los enlaces de descarga y versiones
|
||||
compatibles actuales.
|
||||
|
||||
<!-- quickstart:section=before-you-start -->
|
||||
## Antes de empezar
|
||||
|
||||
Use una copia de un proyecto de prueba, nunca trabajo activo de un cliente. El
|
||||
servidor MCP local, el conector de Premiere y el cliente de IA deben ejecutarse
|
||||
en el mismo equipo. Empiece con una comprobación de conexión de solo lectura:
|
||||
la instalación y el estado verde del panel no demuestran que una edición haya
|
||||
funcionado en un host de Premiere con licencia.
|
||||
|
||||
<!-- quickstart:section=install -->
|
||||
## Instale el servidor y el conector
|
||||
|
||||
Para Claude Desktop, instale el paquete `.mcpb` actual y el conector firmado
|
||||
separado de Premiere desde la versión actual de GitHub. Reinicie ambas
|
||||
aplicaciones.
|
||||
|
||||
Para otro cliente MCP, instale el servidor y después el conector CEP:
|
||||
|
||||
```bash
|
||||
npm install -g premiere-pro-mcp
|
||||
premiere-pro-mcp --install-cep
|
||||
```
|
||||
|
||||
Configure el cliente para ejecutar `premiere-pro-mcp`. El README completo
|
||||
incluye ejemplos JSON específicos por cliente.
|
||||
|
||||
<!-- quickstart:section=prove-connection -->
|
||||
## Compruebe la conexión sin riesgos
|
||||
|
||||
1. Abra Premiere, abra el proyecto de prueba copiado y abra una secuencia
|
||||
activa.
|
||||
2. En Premiere, elija **Window > Extensions > MCP for Adobe Premiere Pro**.
|
||||
“Running” significa que el puente del panel está disponible; no demuestra
|
||||
que se haya completado una edición.
|
||||
3. Ejecute la comprobación local:
|
||||
|
||||
```bash
|
||||
premiere-pro-mcp --doctor
|
||||
```
|
||||
|
||||
4. Pida al cliente de IA: `Run verify_premiere_connection. Make no changes.`
|
||||
|
||||
El doctor local informa del descubrimiento del paquete y de la configuración.
|
||||
La respuesta MCP informa del puente seleccionado y de la disponibilidad del
|
||||
proyecto y la secuencia sin devolver detalles del proyecto. Considere un fallo
|
||||
o una secuencia ausente como un resultado de configuración que debe corregirse,
|
||||
no como permiso para repetir una mutación.
|
||||
|
||||
<!-- quickstart:section=first-edit -->
|
||||
## Realice la primera edición con cuidado
|
||||
|
||||
Tras superar la comprobación de solo lectura, pida un plan limitado para la
|
||||
secuencia de prueba copiada. Revise el destino, los cambios y el límite de
|
||||
confirmación antes de permitir una edición. Después vuelva a inspeccionar la
|
||||
secuencia y use Deshacer para comprobar que el fixture vuelve a su estado
|
||||
anterior.
|
||||
|
||||
<!-- quickstart:section=remove -->
|
||||
## Elimine el conector
|
||||
|
||||
Cierre Premiere por completo y después elimine solamente este conector CEP:
|
||||
|
||||
```bash
|
||||
premiere-pro-mcp --uninstall-cep
|
||||
```
|
||||
|
||||
Esto deja sin cambios la configuración compartida de depuración de Adobe para
|
||||
no interrumpir otras extensiones CEP. Elimine también el servidor MCP de la
|
||||
configuración del cliente de IA y desinstale el paquete npm por separado si ya
|
||||
no lo utiliza.
|
||||
Executable
+70
@@ -0,0 +1,70 @@
|
||||
# Premiere MCP クイックスタート
|
||||
|
||||
これは[英語版](en.md)を元にした機械支援翻訳のドラフトです。コミュニティによる
|
||||
レビューを歓迎します。現在のダウンロードリンクと対応バージョンについては
|
||||
[README](../../README.md) も参照してください。
|
||||
|
||||
<!-- quickstart:section=before-you-start -->
|
||||
## 始める前に
|
||||
|
||||
実案件ではなく、テスト用プロジェクトのコピーを使用してください。ローカル MCP
|
||||
サーバー、Premiere コネクター、AI クライアントは同じコンピューターで動作している
|
||||
必要があります。まず読み取り専用の接続確認を行います。インストール済みであること
|
||||
やパネルが緑色であることは、ライセンス済み Premiere ホストで編集が成功した証明には
|
||||
なりません。
|
||||
|
||||
<!-- quickstart:section=install -->
|
||||
## サーバーとコネクターをインストールする
|
||||
|
||||
Claude Desktop では、現在の GitHub リリースから `.mcpb` バンドルと、別配布の署名済み
|
||||
Premiere コネクターをインストールしてください。両方のアプリを再起動します。
|
||||
|
||||
他の MCP クライアントでは、サーバーの後に CEP コネクターをインストールします。
|
||||
|
||||
```bash
|
||||
npm install -g premiere-pro-mcp
|
||||
premiere-pro-mcp --install-cep
|
||||
```
|
||||
|
||||
クライアントには `premiere-pro-mcp` を実行するよう設定します。クライアント別の JSON
|
||||
例は完全版 README にあります。
|
||||
|
||||
<!-- quickstart:section=prove-connection -->
|
||||
## 安全に接続を確認する
|
||||
|
||||
1. Premiere を開き、コピーしたテストプロジェクトとアクティブなシーケンスを開きます。
|
||||
2. Premiere で **Window > Extensions > MCP for Adobe Premiere Pro** を選びます。
|
||||
“Running” はパネルブリッジが利用可能であることを示すだけで、編集完了の主張では
|
||||
ありません。
|
||||
3. ローカルの事前確認を実行します。
|
||||
|
||||
```bash
|
||||
premiere-pro-mcp --doctor
|
||||
```
|
||||
|
||||
4. AI クライアントに次のよう依頼します: `Run verify_premiere_connection. Make no changes.`
|
||||
|
||||
ローカル doctor はパッケージと設定の検出結果を報告します。MCP の応答は、プロジェクト
|
||||
詳細を返さずに、選択したブリッジ、プロジェクト、シーケンスの準備状態を報告します。
|
||||
失敗やシーケンス未選択は設定を修正すべき結果であり、変更操作を再試行する許可では
|
||||
ありません。
|
||||
|
||||
<!-- quickstart:section=first-edit -->
|
||||
## 最初の編集は慎重に行う
|
||||
|
||||
読み取り専用チェックが成功した後、コピーしたテストシーケンスを対象とする限定的な
|
||||
計画を依頼します。編集を許可する前に、対象、変更内容、確認境界を確認してください。
|
||||
その後シーケンスを再確認し、Undo でフィクスチャが元の状態に戻ることを確認します。
|
||||
|
||||
<!-- quickstart:section=remove -->
|
||||
## コネクターを削除する
|
||||
|
||||
最初に Premiere を完全に終了してから、この CEP コネクターだけを削除します。
|
||||
|
||||
```bash
|
||||
premiere-pro-mcp --uninstall-cep
|
||||
```
|
||||
|
||||
他の CEP 拡張機能を妨げないよう、Adobe の共有デバッグ設定は変更しません。不要になった
|
||||
場合は、AI クライアントの設定から MCP サーバーを削除し、npm パッケージも別途
|
||||
アンインストールしてください。
|
||||
Executable
+18
@@ -0,0 +1,18 @@
|
||||
{
|
||||
"schemaVersion": "premiere-pro-mcp.quickstart-locales.v1",
|
||||
"source": "en.md",
|
||||
"locales": [
|
||||
{
|
||||
"code": "es",
|
||||
"file": "es.md",
|
||||
"language": "Español",
|
||||
"reviewStatus": "machine-assisted draft; community review welcome"
|
||||
},
|
||||
{
|
||||
"code": "ja",
|
||||
"file": "ja.md",
|
||||
"language": "日本語",
|
||||
"reviewStatus": "machine-assisted draft; community review welcome"
|
||||
}
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,21 @@
|
||||
# Recommendation 21: stateless MCP 2026-07-28 migration
|
||||
|
||||
## Evidence
|
||||
|
||||
MCP 2026-07-28 removes the initialization handshake and protocol session. Each request carries its protocol version and client capabilities, while discovery moves to `server/discover`.
|
||||
|
||||
- [MCP 2026-07-28 release](https://blog.modelcontextprotocol.io/posts/2026-07-28)
|
||||
- [MCP stateless proposal](https://modelcontextprotocol.io/seps/2575-stateless-mcp)
|
||||
|
||||
## Proposed improvement
|
||||
|
||||
Add a negotiated 2026-07-28 HTTP path while preserving the current legacy path. Make every request independently validate version, client capabilities, authentication, and server identity; remove any hidden dependency on transport affinity.
|
||||
|
||||
## Acceptance criteria
|
||||
|
||||
- Tests distribute consecutive requests across fresh server instances without losing application handles.
|
||||
- Legacy clients negotiate the existing protocol rather than receiving partial 2026 behavior.
|
||||
- Unsupported versions fail with the specified typed error.
|
||||
- A migration document identifies every session-derived assumption.
|
||||
|
||||
Stateless transport does not make Premiere project state stateless or prove host execution.
|
||||
@@ -0,0 +1,21 @@
|
||||
# Recommendation 22: MRTR confirmation for consequential edits
|
||||
|
||||
## Evidence
|
||||
|
||||
MCP 2026-07-28 introduces `InputRequiredResult` so a server can request user input during an active call and the client can retry with `inputResponses`.
|
||||
|
||||
- [MCP key changes](https://modelcontextprotocol.io/specification/2026-07-28/changelog)
|
||||
- [MCP release candidate details](https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate)
|
||||
|
||||
## Proposed improvement
|
||||
|
||||
Use MRTR for overwrite, delete, relink, and export-overwrite confirmations when the client advertises support. Bind the response to a canonical operation digest, project revision, expiry, and authenticated principal.
|
||||
|
||||
## Acceptance criteria
|
||||
|
||||
- A changed plan, project revision, principal, or expired prompt invalidates the response.
|
||||
- Clients without MRTR receive the existing explicit-token flow.
|
||||
- Retries are idempotent before the host commit boundary.
|
||||
- Tests cover approve, decline, replay, mismatch, and disconnect.
|
||||
|
||||
MRTR is a confirmation transport, not evidence that a human understood the edit.
|
||||
+21
@@ -0,0 +1,21 @@
|
||||
# Recommendation 23: MCP routing-header integrity
|
||||
|
||||
## Evidence
|
||||
|
||||
MCP 2026-07-28 adds `Mcp-Method` and `Mcp-Name` headers for routing without parsing request bodies and defines `HeaderMismatchError` when they disagree with the JSON-RPC payload.
|
||||
|
||||
- [MCP key changes](https://modelcontextprotocol.io/specification/2026-07-28/changelog)
|
||||
- [MCP SDK release overview](https://blog.modelcontextprotocol.io/posts/sdk-betas-2026-07-28)
|
||||
|
||||
## Proposed improvement
|
||||
|
||||
Validate routing headers against the parsed body before authentication scope selection or dispatch. Treat headers as bounded routing hints, never as independent authorization facts, and redact sensitive resource names from access logs.
|
||||
|
||||
## Acceptance criteria
|
||||
|
||||
- Missing, duplicate, oversized, and mismatched headers have deterministic outcomes.
|
||||
- Proxies cannot authorize one tool while dispatching another.
|
||||
- Header values use strict byte and character limits.
|
||||
- Compatibility tests cover clients from both protocol generations.
|
||||
|
||||
This complements exact HTTP route admission; it addresses semantic routing after admission.
|
||||
+21
@@ -0,0 +1,21 @@
|
||||
# Recommendation 24: per-request capability envelope
|
||||
|
||||
## Evidence
|
||||
|
||||
In stateless MCP, every request carries protocol version and client capabilities in `_meta`; servers publish their identity and capabilities through discovery and result metadata.
|
||||
|
||||
- [SEP-2575: Make MCP Stateless](https://modelcontextprotocol.io/seps/2575-stateless-mcp)
|
||||
- [MCP 2026-07-28 release](https://blog.modelcontextprotocol.io/posts/2026-07-28)
|
||||
|
||||
## Proposed improvement
|
||||
|
||||
Create one validated request envelope used by tool, prompt, and resource handlers. It should normalize protocol version, client capabilities, client identity, auth scope, request ID, and advertised response features before business logic runs.
|
||||
|
||||
## Acceptance criteria
|
||||
|
||||
- Missing required capabilities fail before any bridge call.
|
||||
- Unknown optional capabilities are ignored and recorded with bounded cardinality.
|
||||
- Result metadata reports the actual server version handling the call.
|
||||
- Fuzz tests cover malformed and adversarial `_meta` objects.
|
||||
|
||||
Client metadata is self-asserted unless independently authenticated.
|
||||
@@ -0,0 +1,21 @@
|
||||
# Recommendation 25: formal MCP extension negotiation
|
||||
|
||||
## Evidence
|
||||
|
||||
MCP 2026-07-28 establishes a formal extensions framework so optional features can evolve without silently changing the protocol core.
|
||||
|
||||
- [MCP 2026-07-28 release](https://blog.modelcontextprotocol.io/posts/2026-07-28)
|
||||
- [MCP release candidate](https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate)
|
||||
|
||||
## Proposed improvement
|
||||
|
||||
Add a single extension registry describing supported versions, stability, required client capabilities, configuration gates, and fallback behavior. Route Tasks and future UI integrations through it instead of scattered feature flags.
|
||||
|
||||
## Acceptance criteria
|
||||
|
||||
- Unknown or incompatible extensions never alter core tool behavior.
|
||||
- Experimental extensions are disabled by default and labeled in discovery.
|
||||
- Registry snapshots are contract-tested across releases.
|
||||
- Each extension documents downgrade and removal behavior.
|
||||
|
||||
Advertising an extension means protocol support only, not Premiere host support.
|
||||
+21
@@ -0,0 +1,21 @@
|
||||
# Recommendation 26: request-scoped observability migration
|
||||
|
||||
## Evidence
|
||||
|
||||
MCP 2026-07-28 removes `logging/setLevel`; protocol logs become a per-request opt-in through `_meta`. The specification also formalizes deprecation of the older logging capability.
|
||||
|
||||
- [MCP stateless proposal](https://modelcontextprotocol.io/seps/2575-stateless-mcp)
|
||||
- [Python SDK migration guide](https://py.sdk.modelcontextprotocol.io/migration)
|
||||
|
||||
## Proposed improvement
|
||||
|
||||
Separate client-visible diagnostic logs from server telemetry. Honor the negotiated request log level, correlate all records with operation and bridge IDs, and export privacy-filtered traces and metrics independently of MCP notifications.
|
||||
|
||||
## Acceptance criteria
|
||||
|
||||
- No protocol log is emitted without explicit per-request opt-in.
|
||||
- Secrets, media paths, transcript text, and project names are redacted by default.
|
||||
- Trace sampling and label cardinality are bounded.
|
||||
- Legacy logging behavior is version-gated and removal-dated.
|
||||
|
||||
Telemetry can diagnose a call but cannot prove the visual result in Premiere.
|
||||
+21
@@ -0,0 +1,21 @@
|
||||
# Recommendation 27: protocol deprecation ledger
|
||||
|
||||
## Evidence
|
||||
|
||||
The 2026-07-28 MCP revision removes the initialization handshake, protocol sessions, `logging/setLevel`, and top-level `roots/list`, while establishing a formal deprecation policy.
|
||||
|
||||
- [MCP 2026-07-28 changelog](https://modelcontextprotocol.io/specification/2026-07-28/changelog)
|
||||
- [SEP-2575](https://modelcontextprotocol.io/seps/2575-stateless-mcp)
|
||||
|
||||
## Proposed improvement
|
||||
|
||||
Maintain a machine-readable ledger for every deprecated protocol behavior: first warning version, replacement, telemetry signal, planned removal, compatibility tests, and operator override.
|
||||
|
||||
## Acceptance criteria
|
||||
|
||||
- CI fails when deprecated code lacks an owner or removal condition.
|
||||
- Release notes are generated from the ledger without overstating compatibility.
|
||||
- Usage telemetry is aggregate and privacy-safe.
|
||||
- Removing a path requires zero observed use or an explicit breaking release decision.
|
||||
|
||||
The ledger governs server compatibility, not Adobe API deprecations unless separately listed.
|
||||
@@ -0,0 +1,20 @@
|
||||
# Recommendation 28: MCP error taxonomy and allocation
|
||||
|
||||
## Evidence
|
||||
|
||||
MCP 2026-07-28 reserves JSON-RPC server error codes `-32020` through `-32099` for the specification and defines typed errors for header mismatch, missing capability, and unsupported version.
|
||||
|
||||
- [MCP key changes](https://modelcontextprotocol.io/specification/2026-07-28/changelog)
|
||||
|
||||
## Proposed improvement
|
||||
|
||||
Create a central error registry that keeps protocol-reserved errors separate from Premiere, bridge, validation, authentication, and internal failures. Map errors to retryability, mutation certainty, safe client text, and telemetry class.
|
||||
|
||||
## Acceptance criteria
|
||||
|
||||
- No implementation-defined error uses the protocol-reserved range.
|
||||
- Every bridge failure states whether a host mutation may have committed.
|
||||
- Stack traces and private paths never reach clients.
|
||||
- Snapshot tests lock codes, shapes, and backward-compatible text fallbacks.
|
||||
|
||||
A structured error reports uncertainty; it must not convert unknown host state into failure or success.
|
||||
@@ -0,0 +1,21 @@
|
||||
# Recommendation 29: UXP API-era compatibility adapter
|
||||
|
||||
## Evidence
|
||||
|
||||
Adobe changed `Sequence.setSelection` in Premiere 26.3 from asynchronous `Promise<boolean>` to synchronous `boolean`, demonstrating that host-version differences can change call semantics.
|
||||
|
||||
- [Adobe UXP changelog](https://developer.adobe.com/premiere-pro/uxp/changelog)
|
||||
- [Adobe Sequence reference](https://developer.adobe.com/premiere-pro/uxp/ppro-reference/classes/sequence)
|
||||
|
||||
## Proposed improvement
|
||||
|
||||
Centralize version-sensitive Adobe calls behind typed adapters that normalize sync/async returns without guessing support. Generate an audited compatibility table from official declarations and runtime probes.
|
||||
|
||||
## Acceptance criteria
|
||||
|
||||
- The 25.x and 26.3 selection signatures have explicit contract fixtures.
|
||||
- Unknown versions fail closed for mutations and expose diagnostics.
|
||||
- Runtime probes do not mutate user projects.
|
||||
- Direct version-sensitive calls outside the adapter fail lint or review checks.
|
||||
|
||||
Contract fixtures are not a substitute for runs in each licensed host version.
|
||||
+21
@@ -0,0 +1,21 @@
|
||||
# Recommendation 30: signed host capability attestation
|
||||
|
||||
## Evidence
|
||||
|
||||
Adobe documents host and UXP runtime version inspection, while Premiere APIs declare minimum versions per method. Static package declarations can therefore differ from the connected runtime.
|
||||
|
||||
- [Understanding UXP APIs](https://developer.adobe.com/premiere-pro/uxp/resources/fundamentals/apis)
|
||||
- [Adobe UXP changelog](https://developer.adobe.com/premiere-pro/uxp/changelog)
|
||||
|
||||
## Proposed improvement
|
||||
|
||||
Have the authenticated panel produce a nonce-bound capability attestation containing host version, UXP version, plugin build hash, probed stable methods, and timestamp. Bind it to the current WebSocket connection and expire it quickly.
|
||||
|
||||
## Acceptance criteria
|
||||
|
||||
- Replayed, expired, cross-connection, and mismatched-build attestations are rejected.
|
||||
- Probes are read-only and bounded.
|
||||
- Tool discovery uses the attested intersection, not package-version assumptions.
|
||||
- Diagnostics distinguish declared, probed, and live-verified capability.
|
||||
|
||||
Attestation proves what the panel observed, not that a later host operation succeeded.
|
||||
@@ -0,0 +1,20 @@
|
||||
# Recommendation 31: Adobe sample parity drift check
|
||||
|
||||
## Evidence
|
||||
|
||||
Adobe’s official Premiere UXP samples exercise projects, sequences, markers, metadata, effects, exports, encoder, transcripts, and project conversion, with manifests treated as authoritative for version compatibility.
|
||||
|
||||
- [Adobe Premiere UXP samples](https://github.com/AdobeDocs/uxp-premiere-pro-samples)
|
||||
|
||||
## Proposed improvement
|
||||
|
||||
Add a scheduled, review-only drift job that compares pinned Adobe sample manifests and package versions with this repository’s coverage manifest. Produce candidate gaps without automatically enabling tools or beta APIs.
|
||||
|
||||
## Acceptance criteria
|
||||
|
||||
- Inputs are pinned by commit SHA and artifact hash.
|
||||
- Changes open an auditable report, not an automatic production mutation.
|
||||
- Stable and beta declarations remain separate.
|
||||
- Removed or changed APIs create blocking review items for affected tools.
|
||||
|
||||
Sample usage is implementation guidance, not a compatibility guarantee.
|
||||
+21
@@ -0,0 +1,21 @@
|
||||
# Recommendation 32: transaction deadline and readback budget
|
||||
|
||||
## Evidence
|
||||
|
||||
Adobe UXP mutations are expressed as actions and executed through project transactions; many surrounding reads remain asynchronous and can stall independently.
|
||||
|
||||
- [Adobe Sequence reference](https://developer.adobe.com/premiere-pro/uxp/ppro-reference/classes/sequence)
|
||||
- [Understanding UXP APIs](https://developer.adobe.com/premiere-pro/uxp/resources/fundamentals/apis)
|
||||
|
||||
## Proposed improvement
|
||||
|
||||
Define separate deadlines for preflight, synchronous action construction, transaction execution, and post-commit readback. Return a receipt that identifies the last known phase and never retries an uncertain mutation automatically.
|
||||
|
||||
## Acceptance criteria
|
||||
|
||||
- Tests inject timeouts at every phase and assert mutation certainty.
|
||||
- Readback exhaustion returns `committed_unverified`, not false failure.
|
||||
- The scheduler prevents a timed-out call from releasing unsafe conflicting work.
|
||||
- Phase budgets are configurable within capped limits.
|
||||
|
||||
A completed transaction still requires host readback or human observation for outcome claims.
|
||||
+21
@@ -0,0 +1,21 @@
|
||||
# Recommendation 33: generated UXP permission minimization
|
||||
|
||||
## Evidence
|
||||
|
||||
Adobe UXP manifests explicitly declare network and local-file-system permissions. Permission scope is part of the install-time trust boundary.
|
||||
|
||||
- [Adobe UXP manifest](https://developer.adobe.com/premiere-pro/uxp/plugins/concepts/manifest/)
|
||||
- [Adobe UXP network recipe](https://developer.adobe.com/premiere-pro/uxp/resources/recipes/network)
|
||||
|
||||
## Proposed improvement
|
||||
|
||||
Generate release manifests from a reviewed permission policy and fail CI on undeclared expansion. Separate development, benchmark, and production permissions; include a human-readable permission diff in releases.
|
||||
|
||||
## Acceptance criteria
|
||||
|
||||
- Production never inherits development-only addon or network permissions.
|
||||
- New permissions require rationale, threat analysis, and explicit review.
|
||||
- Runtime endpoints are still validated even when Adobe requires a broad domain declaration.
|
||||
- Packaged manifest hashes are verified in release provenance.
|
||||
|
||||
Manifest minimization reduces exposure but does not replace runtime authentication.
|
||||
+21
@@ -0,0 +1,21 @@
|
||||
# Recommendation 34: UXP filesystem token lifecycle
|
||||
|
||||
## Evidence
|
||||
|
||||
UXP local filesystem access is permission-gated and user-selected entries may be represented by persistent tokens rather than unrestricted native paths.
|
||||
|
||||
- [Adobe UXP manifest](https://developer.adobe.com/premiere-pro/uxp/plugins/concepts/manifest/)
|
||||
- [Adobe UXP file-system recipes](https://developer.adobe.com/premiere-pro/uxp/resources/recipes/)
|
||||
|
||||
## Proposed improvement
|
||||
|
||||
Introduce a token broker that records purpose, project binding, creation time, last use, and revocation without exposing raw tokens to MCP clients. Re-prompt when a token is stale or no longer resolves.
|
||||
|
||||
## Acceptance criteria
|
||||
|
||||
- Tokens are encrypted at rest or remain solely in UXP-managed storage.
|
||||
- Logs and tool results never contain token values.
|
||||
- Revocation, moved files, and denied reauthorization fail deterministically.
|
||||
- Cleanup is bounded by age and count with explicit user controls.
|
||||
|
||||
A valid token authorizes filesystem access only; it does not validate media contents.
|
||||
+21
@@ -0,0 +1,21 @@
|
||||
# Recommendation 35: versioned UXP bridge protocol
|
||||
|
||||
## Evidence
|
||||
|
||||
Adobe’s UXP runtime and Premiere API surface evolve independently, while this project connects the panel through an authenticated loopback WebSocket.
|
||||
|
||||
- [Understanding UXP APIs](https://developer.adobe.com/premiere-pro/uxp/resources/fundamentals/apis)
|
||||
- [Adobe UXP changelog](https://developer.adobe.com/premiere-pro/uxp/changelog)
|
||||
|
||||
## Proposed improvement
|
||||
|
||||
Version the panel/server hello, command envelope, event envelope, error shape, and feature flags. Negotiate the highest mutually supported bridge version and reject ambiguous downgrade.
|
||||
|
||||
## Acceptance criteria
|
||||
|
||||
- Cross-version fixtures cover the current and previous supported bridge version.
|
||||
- Unknown commands and fields have documented forward-compatibility behavior.
|
||||
- Downgrade cannot bypass authentication or capability checks.
|
||||
- Fuzz tests bound nesting, arrays, strings, and numeric values after frame parsing.
|
||||
|
||||
Bridge negotiation is distinct from MCP protocol and Adobe host-version negotiation.
|
||||
+20
@@ -0,0 +1,20 @@
|
||||
# Recommendation 36: privacy-safe context retention policy
|
||||
|
||||
## Evidence
|
||||
|
||||
Stateless MCP permits explicit application handles for state that must survive calls; it does not require indefinite application storage.
|
||||
|
||||
- [MCP stateless release candidate](https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate)
|
||||
|
||||
## Proposed improvement
|
||||
|
||||
Add per-project TTL, byte quota, transcript opt-in, field-level redaction, compaction receipts, and delete/export controls to the project-context store. Keep operational state separate from model-ready summaries.
|
||||
|
||||
## Acceptance criteria
|
||||
|
||||
- Raw transcript text is disabled by default for persistent context.
|
||||
- Quota enforcement is deterministic and never evicts an active write silently.
|
||||
- Delete removes primary and derived records with an audit receipt that contains no content.
|
||||
- Tests cover crash recovery, clock skew, corruption, and concurrent compaction.
|
||||
|
||||
Retention policy reduces stored data; it does not make model inference private by itself.
|
||||
+20
@@ -0,0 +1,20 @@
|
||||
# Recommendation 37: transcript round-trip integrity
|
||||
|
||||
## Evidence
|
||||
|
||||
Adobe’s stable UXP `Transcript` API can export transcript JSON, import JSON into text segments, create an import action, query supported languages, and test transcript presence.
|
||||
|
||||
- [Adobe Transcript reference](https://developer.adobe.com/premiere-pro/uxp/ppro-reference/classes/transcript)
|
||||
|
||||
## Proposed improvement
|
||||
|
||||
Add a dry-run transcript importer that validates schema, language metadata, time ordering, clip identity, and a canonical content digest before constructing an Adobe action. Verify post-commit presence and bounded export equivalence.
|
||||
|
||||
## Acceptance criteria
|
||||
|
||||
- Malformed, overlapping, out-of-range, and wrong-clip segments fail before mutation.
|
||||
- Confirmation binds the canonical digest and project revision.
|
||||
- Readback reports semantic differences without leaking transcript text into logs.
|
||||
- Real-host fixtures cover supported languages and large transcripts.
|
||||
|
||||
JSON equivalence does not prove word-level alignment or transcription accuracy.
|
||||
@@ -0,0 +1,20 @@
|
||||
# Recommendation 38: metadata batch planner
|
||||
|
||||
## Evidence
|
||||
|
||||
Adobe’s production-style metadata sample supports column copy/exchange, batch prefix/suffix/numbering, metadata export, and clip-marker export.
|
||||
|
||||
- [Adobe Premiere UXP samples](https://github.com/AdobeDocs/uxp-premiere-pro-samples)
|
||||
|
||||
## Proposed improvement
|
||||
|
||||
Create a bounded metadata plan/preview/apply workflow with explicit namespaces, typed coercion, per-item expected values, conflict detection, and chunked transactions. Default to exporting a rollback artifact before changes.
|
||||
|
||||
## Acceptance criteria
|
||||
|
||||
- Preview identifies writable fields, collisions, truncation, and no-op edits.
|
||||
- Apply requires exact project revision and plan digest.
|
||||
- Partial batches return per-item certainty and never retry unknown commits.
|
||||
- Sensitive metadata fields are excluded unless explicitly allowlisted.
|
||||
|
||||
Adobe’s sample demonstrates a workflow pattern; real project schemas still require host validation.
|
||||
+20
@@ -0,0 +1,20 @@
|
||||
# Recommendation 39: sequence-sandbox verification mode
|
||||
|
||||
## Evidence
|
||||
|
||||
Adobe’s stable `Sequence.createCloneAction` can clone a sequence through an undoable action.
|
||||
|
||||
- [Adobe Sequence reference](https://developer.adobe.com/premiere-pro/uxp/ppro-reference/classes/sequence)
|
||||
|
||||
## Proposed improvement
|
||||
|
||||
Offer an opt-in verification mode that clones the target sequence, applies a proposed edit plan only to the clone, captures bounded structural diffs, and requires a separate confirmation before applying an independently revalidated plan to the original.
|
||||
|
||||
## Acceptance criteria
|
||||
|
||||
- Clone names and IDs are collision-safe and traceable to an operation receipt.
|
||||
- The original sequence is never targeted during sandbox execution.
|
||||
- Cleanup is explicit and refuses deletion if identity or revision changed.
|
||||
- Tests cover clone failure, partial apply, user edits, and stale confirmation.
|
||||
|
||||
Success on a clone does not guarantee identical rendering or a safe original apply.
|
||||
@@ -0,0 +1,21 @@
|
||||
# Recommendation 40: export artifact reconciliation
|
||||
|
||||
## Evidence
|
||||
|
||||
Adobe’s stable `EncoderManager` supports Premiere and AME export workflows, and its events distinguish queue, progress, completion, error, and cancellation.
|
||||
|
||||
- [Adobe EncoderManager reference](https://developer.adobe.com/premiere-pro/uxp/ppro-reference/classes/encodermanager/)
|
||||
- [Adobe UXP changelog](https://developer.adobe.com/premiere-pro/uxp/changelog)
|
||||
|
||||
## Proposed improvement
|
||||
|
||||
Add an export reconciler that joins operation receipts, encoder events, expected destination, artifact stat/hash, and optional media probe into one state machine. On restart, recover only from durable evidence and never re-submit an uncertain job automatically.
|
||||
|
||||
## Acceptance criteria
|
||||
|
||||
- States distinguish queued, rendering, cancelled, failed, completed-no-artifact, and verified-artifact.
|
||||
- Event gaps and duplicate events produce explicit uncertainty.
|
||||
- Overwrite policy and artifact identity are bound to the original confirmation.
|
||||
- Windows/macOS live-host runs cover Premiere and AME paths.
|
||||
|
||||
An artifact hash proves file identity, not visual or editorial correctness.
|
||||
@@ -0,0 +1,25 @@
|
||||
# Recommendation 01: exact HTTP route admission
|
||||
|
||||
## Evidence
|
||||
|
||||
The MCP HTTP transport is a security boundary. The current server accepts any URL
|
||||
whose text starts with `/mcp`, so `/mcp-typo` reaches the authenticated transport.
|
||||
The latest MCP transport guidance expects one configured endpoint, and the existing
|
||||
roadmap already requires rejection before server construction.
|
||||
|
||||
- [MCP 2026-07-28 transport specification](https://modelcontextprotocol.io/specification/2026-07-28/basic/transports)
|
||||
|
||||
## Proposed improvement
|
||||
|
||||
Parse the request URL once and admit only the exact `/mcp` pathname. Allow only the
|
||||
methods supported by Streamable HTTP, return `404` for other paths and `405` with an
|
||||
`Allow` header for other methods, and do this before authentication telemetry or MCP
|
||||
server allocation.
|
||||
|
||||
## Acceptance
|
||||
|
||||
- `/mcp`, `/mcp?client=x`, and the health route retain documented behavior.
|
||||
- `/mcp-typo`, encoded separator variants, and unsupported methods never construct a server.
|
||||
- Unit tests cover malformed URLs without exposing request headers or tokens.
|
||||
|
||||
This is transport hardening only; it does not validate a live Premiere host.
|
||||
@@ -0,0 +1,24 @@
|
||||
# Recommendation 02: bound HTTP requests and sockets
|
||||
|
||||
## Evidence
|
||||
|
||||
Remote MCP requests can currently consume an unbounded body and inherit Node's
|
||||
generic timeout behavior. MCP tools can drive Premiere, so parsing and socket limits
|
||||
must apply before a transport or host operation is allocated.
|
||||
|
||||
- [MCP security best practices](https://modelcontextprotocol.io/specification/2026-07-28/basic/security_best_practices)
|
||||
- [Node HTTP server timeouts](https://nodejs.org/api/http.html#class-httpserver)
|
||||
|
||||
## Proposed improvement
|
||||
|
||||
Add validated environment settings for maximum body bytes, headers timeout, request
|
||||
timeout, keep-alive timeout, and maximum requests per socket. Count bytes while the
|
||||
request streams and return deterministic `408` or `413` responses before MCP parsing.
|
||||
|
||||
## Acceptance
|
||||
|
||||
- Oversized and slow requests never invoke `createServer` or a Premiere bridge.
|
||||
- Invalid configuration fails startup instead of silently disabling a limit.
|
||||
- Boundary tests cover chunked bodies, declared lengths, disconnects, and exact limits.
|
||||
|
||||
This is remote-transport containment, not proof of host cancellation.
|
||||
@@ -0,0 +1,24 @@
|
||||
# Recommendation 03: authorization-scoped throttling
|
||||
|
||||
## Evidence
|
||||
|
||||
Authentication establishes who may call tools but does not bound request rate. MCP
|
||||
security guidance recommends defense in depth for exposed authorization boundaries.
|
||||
|
||||
- [MCP authorization security](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization)
|
||||
|
||||
## Proposed improvement
|
||||
|
||||
Add a bounded token-bucket limiter keyed by a one-way credential fingerprint, with
|
||||
trusted-proxy-aware IP fallback only when explicitly configured. Reject before MCP
|
||||
server construction, cap key cardinality, expire idle buckets, and emit aggregate
|
||||
telemetry without tokens, IP addresses, arguments, or project data.
|
||||
|
||||
## Acceptance
|
||||
|
||||
- Burst and sustained limits have deterministic `429` behavior and `Retry-After`.
|
||||
- Different credentials do not consume each other's budgets.
|
||||
- Memory remains bounded under rotating identifiers and process restart semantics are documented.
|
||||
- Fly/edge limits remain recommended because one-process counters are not account-wide.
|
||||
|
||||
This control supplements authentication; it does not replace it.
|
||||
@@ -0,0 +1,25 @@
|
||||
# Recommendation 04: Premiere operation scheduler
|
||||
|
||||
## Evidence
|
||||
|
||||
Concurrent MCP requests can reach one interactive Premiere host. Adobe UXP mutations
|
||||
are committed through project transactions, but that does not serialize independent
|
||||
requests or make a timed-out mutation safe to replay.
|
||||
|
||||
- [Adobe Project.executeTransaction](https://developer.adobe.com/premiere-pro/uxp/ppro-reference/classes/project/#executetransaction)
|
||||
- [MCP cancellation](https://modelcontextprotocol.io/specification/2026-07-28/basic/utilities/cancellation)
|
||||
|
||||
## Proposed improvement
|
||||
|
||||
Introduce one FIFO mutation lane plus configurable safe-read concurrency. Classify
|
||||
before enqueueing, bound queue length and wait time, attach operation IDs, and stop
|
||||
queued work on disconnect. Never claim cancellation after the host commit boundary.
|
||||
|
||||
## Acceptance
|
||||
|
||||
- Mutations cannot overlap; explicitly safe reads demonstrate bounded parallelism.
|
||||
- Queue overflow and expiry return stable overload errors without host calls.
|
||||
- Tests cover fairness, disconnects, timeouts, and mutation/read classification.
|
||||
- Metrics expose counts and timings only, never project or tool arguments.
|
||||
|
||||
Contract tests cannot replace a real-host concurrency run.
|
||||
+26
@@ -0,0 +1,26 @@
|
||||
# Recommendation 05: negotiated MCP Tasks
|
||||
|
||||
## Evidence
|
||||
|
||||
The 2026-07-28 MCP release adds standardized long-running task semantics. Premiere
|
||||
exports, proxy generation, transcription, and analysis can exceed an interactive
|
||||
request, while Adobe APIs may offer no mid-call cancellation point.
|
||||
|
||||
- [MCP 2026-07-28 release](https://blog.modelcontextprotocol.io/posts/2026-07-28)
|
||||
- [MCP Tasks extension](https://modelcontextprotocol.io/seps/2663-tasks-extension)
|
||||
|
||||
## Proposed improvement
|
||||
|
||||
Negotiate Tasks and initially wrap exports only. Use authorization-scoped random
|
||||
IDs, bounded retention, progress, expiry, and precise queued/running/committed states.
|
||||
Keep the synchronous path for clients without support and persist no project args or
|
||||
results containing media data.
|
||||
|
||||
## Acceptance
|
||||
|
||||
- Compatible clients can start, inspect, cancel, and retrieve an export result.
|
||||
- Incompatible clients never receive an unknown task handle.
|
||||
- Restart and cancellation tests define recoverable states and commit boundaries.
|
||||
- Task count, retention bytes, and telemetry cardinality are capped.
|
||||
|
||||
Tasks do not make a blocking Adobe export API cancellable.
|
||||
@@ -0,0 +1,24 @@
|
||||
# Recommendation 06: strict tool output schemas
|
||||
|
||||
## Evidence
|
||||
|
||||
MCP 2026-07-28 tools may advertise `outputSchema`. The server returns structured
|
||||
results but does not publish or validate per-tool output contracts, leaving clients
|
||||
unable to distinguish schema drift from host failures.
|
||||
|
||||
- [MCP tools specification](https://modelcontextprotocol.io/specification/2026-07-28/server/tools)
|
||||
|
||||
## Proposed improvement
|
||||
|
||||
Add shared success/error/verification schemas and migrate read-only diagnostics first.
|
||||
Validate `structuredContent` before return, preserve the text block for compatibility,
|
||||
and maintain a machine-readable waiver list for unmigrated tools.
|
||||
|
||||
## Acceptance
|
||||
|
||||
- Every migrated tool publishes valid JSON Schema 2020-12 output.
|
||||
- Representative success and failure paths reject schema drift in CI.
|
||||
- Error codes, operation semantics, and verification boundaries are typed.
|
||||
- Schema failure never converts an ambiguous host mutation into a retry.
|
||||
|
||||
Start with read-only tools; mutation migration needs separate host evidence.
|
||||
@@ -0,0 +1,25 @@
|
||||
# Recommendation 07: JSON Schema constraint fidelity
|
||||
|
||||
## Evidence
|
||||
|
||||
Tool parameters are authored as JSON Schema but the server's JSON-Schema-to-Zod
|
||||
adapter currently preserves types and string enums while dropping bounds such as
|
||||
`minLength`, `maxLength`, numeric limits, and array limits. MCP treats input schemas
|
||||
as the tool contract.
|
||||
|
||||
- [MCP tools specification](https://modelcontextprotocol.io/specification/2026-07-28/server/tools)
|
||||
|
||||
## Proposed improvement
|
||||
|
||||
Compile supported constraints into Zod, reject unsupported schema keywords during CI,
|
||||
add integer and non-string enum support, and cap schema depth/size. Do not silently
|
||||
coerce values or apply defaults that change existing tool behavior.
|
||||
|
||||
## Acceptance
|
||||
|
||||
- Boundary tests cover strings, numbers, integers, arrays, enums, and nested objects.
|
||||
- Every catalog schema compiles deterministically with a bounded cache.
|
||||
- Unsupported keywords produce a build-time migration report.
|
||||
- Existing valid client calls remain compatible.
|
||||
|
||||
This improves server-side validation; it does not validate Adobe host semantics.
|
||||
@@ -0,0 +1,25 @@
|
||||
# Recommendation 08: contained artifact resource links
|
||||
|
||||
## Evidence
|
||||
|
||||
MCP tool results can return resource links and embedded resources. Export, AAF, and
|
||||
compatibility reports currently describe paths in ordinary result data, which is
|
||||
hard for clients to consume safely.
|
||||
|
||||
- [MCP tool result content](https://modelcontextprotocol.io/specification/2026-07-28/server/tools)
|
||||
- [MCP resource security](https://modelcontextprotocol.io/specification/2026-07-28/server/resources)
|
||||
|
||||
## Proposed improvement
|
||||
|
||||
Create authorization-scoped artifact IDs and expose only registered, size-bounded
|
||||
files under a dedicated URI scheme. Canonicalize paths, reject links/reparse points,
|
||||
set short expirations, and never turn an arbitrary tool-supplied path into a resource.
|
||||
|
||||
## Acceptance
|
||||
|
||||
- Export/report results include a resource link only after artifact registration.
|
||||
- Traversal, alternate separators, symlinks, oversized files, and expired IDs fail closed.
|
||||
- Resource reads recheck authorization and MIME type.
|
||||
- Existing text and structured results remain available to older clients.
|
||||
|
||||
Artifact existence still requires post-export verification.
|
||||
@@ -0,0 +1,24 @@
|
||||
# Recommendation 09: workflow-scoped tool packs
|
||||
|
||||
## Evidence
|
||||
|
||||
The server advertises 285 core tools. Large discovery payloads consume client context
|
||||
and make correct-tool selection harder. MCP discovery is capability-driven, and the
|
||||
2026-07-28 release adds cache metadata for list results.
|
||||
|
||||
- [MCP 2026-07-28 release](https://blog.modelcontextprotocol.io/posts/2026-07-28)
|
||||
|
||||
## Proposed improvement
|
||||
|
||||
Define versioned essential, rough-cut, audio, captions, color, delivery, inspection,
|
||||
and advanced packs. Operator selection controls visibility only; authority checks
|
||||
remain separate and direct calls to hidden unauthorized tools stay denied.
|
||||
|
||||
## Acceptance
|
||||
|
||||
- Every tool belongs to at least one pack and retains an authority classification.
|
||||
- Essential completes diagnosis, inspection, safe preview, save, and delivery.
|
||||
- Full-catalog mode remains available through a documented compatibility window.
|
||||
- Benchmarks measure list bytes, schema time, prompt tokens, and correct-tool selection.
|
||||
|
||||
Tool packs are context optimization, not an authorization mechanism.
|
||||
@@ -0,0 +1,24 @@
|
||||
# Recommendation 10: cacheable discovery with invalidation
|
||||
|
||||
## Evidence
|
||||
|
||||
MCP 2026-07-28 adds `ttlMs` and `cacheScope` to list results. This server repeatedly
|
||||
builds large tool catalogs whose contents vary with authority and UXP connection state.
|
||||
|
||||
- [MCP 2026-07-28 release](https://blog.modelcontextprotocol.io/posts/2026-07-28)
|
||||
|
||||
## Proposed improvement
|
||||
|
||||
Return private cache metadata for tools, prompts, and resources when the installed SDK
|
||||
supports it. Key caches by server version, authority profile, selected tool pack, UXP
|
||||
protocol/capabilities, and connector state. Emit list-changed notifications only to
|
||||
clients that negotiate them, coalescing connection churn.
|
||||
|
||||
## Acceptance
|
||||
|
||||
- Cache keys never cross authorization profiles.
|
||||
- UXP connect/disconnect and pack changes invalidate discovery deterministically.
|
||||
- Repeated list benchmarks show lower serialization work and bytes transferred.
|
||||
- Older clients retain current behavior without unknown fields or notifications.
|
||||
|
||||
No cache may preserve tools after their authority is revoked.
|
||||
@@ -0,0 +1,24 @@
|
||||
# Recommendation 11: UXP bridge backpressure
|
||||
|
||||
## Evidence
|
||||
|
||||
The authenticated UXP bridge bounds each WebSocket frame but its pending-request map
|
||||
has no count limit. A burst can therefore allocate timers and request state faster
|
||||
than a single interactive Premiere host can complete commands.
|
||||
|
||||
- [Adobe UXP network operations](https://developer.adobe.com/premiere-pro/uxp/resources/recipes/network)
|
||||
|
||||
## Proposed improvement
|
||||
|
||||
Add configurable pending and queued limits, reject excess work before generating a
|
||||
request ID, and expose aggregate active/rejected counters. Coordinate with the future
|
||||
operation scheduler so only one component owns mutation ordering.
|
||||
|
||||
## Acceptance
|
||||
|
||||
- Pending entries and timers never exceed the configured cap.
|
||||
- Rejections have a stable `UXP_OVERLOADED` code and never reach the panel.
|
||||
- Timeout, send failure, disconnect, replacement connection, and stop release capacity.
|
||||
- Load tests demonstrate bounded heap and telemetry cardinality.
|
||||
|
||||
Backpressure does not imply that Adobe host calls are cancellable.
|
||||
@@ -0,0 +1,24 @@
|
||||
# Recommendation 12: remove UXP tokens from URLs
|
||||
|
||||
## Evidence
|
||||
|
||||
The loopback bridge authenticates with a token query parameter. URLs are more likely
|
||||
than headers to appear in diagnostics, proxy logs, screenshots, or error strings.
|
||||
Adobe UXP WebSocket access remains permission-gated by the manifest and runtime URL checks.
|
||||
|
||||
- [Adobe UXP network security](https://developer.adobe.com/premiere-pro/uxp/resources/recipes/network)
|
||||
|
||||
## Proposed improvement
|
||||
|
||||
Move the secret to a WebSocket subprotocol or supported authorization header while
|
||||
retaining constant-time comparison, loopback binding, exact path checks, and a short
|
||||
documented compatibility window for query authentication. Redact both forms everywhere.
|
||||
|
||||
## Acceptance
|
||||
|
||||
- New panel connections contain no secret in the URL.
|
||||
- Missing, duplicate, malformed, and wrong credentials fail before upgrade.
|
||||
- Logs, telemetry, status UI, and errors never contain credential material.
|
||||
- Compatibility mode is opt-in, warned, tested, and assigned a removal version.
|
||||
|
||||
The chosen mechanism must be proven in Premiere 26.3 UXP, not only browser mocks.
|
||||
@@ -0,0 +1,24 @@
|
||||
# Recommendation 13: UXP connection liveness
|
||||
|
||||
## Evidence
|
||||
|
||||
A TCP/WebSocket connection can remain open while Premiere is modal, suspended, or no
|
||||
longer processing panel messages. Current state reports connected until socket closure
|
||||
or a command timeout, delaying diagnosis and tying up pending work.
|
||||
|
||||
- [Adobe UXP WebSocket guidance](https://developer.adobe.com/premiere-pro/uxp/resources/recipes/network)
|
||||
|
||||
## Proposed improvement
|
||||
|
||||
Add protocol-level heartbeat sequence numbers and bounded round-trip measurements.
|
||||
Classify `connected`, `degraded`, and `stale`; stop admitting new mutations when stale,
|
||||
but never replay a timed-out mutation after reconnection.
|
||||
|
||||
## Acceptance
|
||||
|
||||
- Heartbeats are authenticated, size-bounded, and excluded from tool telemetry.
|
||||
- Miss thresholds tolerate short event-loop stalls without reconnect storms.
|
||||
- Stale connections reject new work and settle pending requests deterministically.
|
||||
- Diagnostics distinguish socket liveness from successful Premiere host execution.
|
||||
|
||||
Live-host tests must cover modal dialogs, sleep/wake, panel reload, and Premiere exit.
|
||||
@@ -0,0 +1,25 @@
|
||||
# Recommendation 14: revisioned in-panel project index
|
||||
|
||||
## Evidence
|
||||
|
||||
Several UXP commands traverse the complete project tree to resolve items. Adobe exposes
|
||||
stable project/item identities and project events; repeated breadth-first traversal
|
||||
scales poorly and duplicate names must not resolve silently.
|
||||
|
||||
- [Adobe Premiere UXP Project API](https://developer.adobe.com/premiere-pro/uxp/ppro-reference/classes/project)
|
||||
- [Adobe UXP events](https://developer.adobe.com/premiere-pro/uxp/resources/fundamentals/events)
|
||||
|
||||
## Proposed improvement
|
||||
|
||||
Maintain a bounded index by item GUID, exact name, normalized path hash, type, and
|
||||
parent identity. Increment revisions from documented events and successful commands;
|
||||
when event evidence is incomplete, mark stale and rebuild instead of guessing.
|
||||
|
||||
## Acceptance
|
||||
|
||||
- Duplicate names return bounded matches or require a stable identity.
|
||||
- Entry count/memory are capped and cleared on project close or disconnect.
|
||||
- Lost/coalesced event tests prove a full rebuild restores correctness.
|
||||
- Large fixtures improve p50/p95 lookup without changing command results.
|
||||
|
||||
Mock benchmarks are not live-host performance evidence.
|
||||
@@ -0,0 +1,24 @@
|
||||
# Recommendation 15: paginated project discovery
|
||||
|
||||
## Evidence
|
||||
|
||||
Large Premiere projects can contain thousands of items. Returning an entire tree in
|
||||
one tool response increases host traversal time, MCP payload size, and model context.
|
||||
Adobe's Project API provides stable items; MCP tools can expose bounded cursors.
|
||||
|
||||
- [Adobe Premiere UXP Project API](https://developer.adobe.com/premiere-pro/uxp/ppro-reference/classes/project)
|
||||
|
||||
## Proposed improvement
|
||||
|
||||
Add cursor-based, revision-locked project-item discovery with explicit page and field
|
||||
limits. Cursors should be opaque, authorization-scoped, short-lived, and invalidated
|
||||
when the project-index revision changes. Default fields exclude native paths.
|
||||
|
||||
## Acceptance
|
||||
|
||||
- Page size, response bytes, traversal time, and cursor count are bounded.
|
||||
- Changed projects return `refresh_required` rather than mixed-revision pages.
|
||||
- Duplicate names retain stable IDs and parent identity.
|
||||
- Tests cover expired, forged, cross-project, and cross-credential cursors.
|
||||
|
||||
Pagination depends on stable identity but not on undocumented QE behavior.
|
||||
@@ -0,0 +1,24 @@
|
||||
# Recommendation 16: project-context delta capture
|
||||
|
||||
## Evidence
|
||||
|
||||
The durable context engine correctly separates source and timeline revisions, but a
|
||||
capture still rebuilds a bounded active-sequence snapshot. Documented project events
|
||||
and stable identities can reduce repeated work if event loss fails closed.
|
||||
|
||||
- [Adobe UXP events](https://developer.adobe.com/premiere-pro/uxp/resources/fundamentals/events)
|
||||
|
||||
## Proposed improvement
|
||||
|
||||
Accept an optional prior revision and return added, changed, removed, and retained
|
||||
record IDs. Coalesce event hints, re-read affected records, and force a full capture
|
||||
when event continuity, project identity, truncation, or schema compatibility is uncertain.
|
||||
|
||||
## Acceptance
|
||||
|
||||
- Applying a delta to its exact base equals a fresh full snapshot.
|
||||
- Wrong/stale bases return `full_refresh_required` without partial persistence.
|
||||
- Deltas and event queues are count/byte/time bounded.
|
||||
- Source enrichments survive timeline-only changes and invalidate on source revision changes.
|
||||
|
||||
Events are hints; correctness continues to come from bounded readback.
|
||||
@@ -0,0 +1,24 @@
|
||||
# Recommendation 17: reproducible live-host compatibility lab
|
||||
|
||||
## Evidence
|
||||
|
||||
Adobe's 26.3 UXP changelog includes breaking and new APIs, while automated adapters
|
||||
cannot establish behavior in licensed Premiere builds. The coverage manifest keeps
|
||||
live-host evidence separate but lacks a reproducible collection protocol.
|
||||
|
||||
- [Adobe Premiere UXP changelog](https://developer.adobe.com/premiere-pro/uxp/changelog)
|
||||
|
||||
## Proposed improvement
|
||||
|
||||
Package privacy-safe small/medium/large fixture manifests and a manual host runner.
|
||||
Record host/OS versions, artifact SHA-256, backend, command, timing phases, observable
|
||||
readback, and outcome—never project/media names, paths, transcripts, or arguments.
|
||||
|
||||
## Acceptance
|
||||
|
||||
- Reports distinguish verified, committed-unverified, unsupported, failed, and not-run.
|
||||
- Evidence promotion requires exact host, OS, artifact hash, command, and readback.
|
||||
- CI validates schemas/fixtures without labeling mocks as Premiere.
|
||||
- Reports include p50/p95/max dispatch, host, verification, and total latency.
|
||||
|
||||
The lab remains manual because CI is not a licensed interactive Premiere host.
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user