SuperAPI AI Directory

chengfeng-check-updates

General & other

View repository

Updated 10-15 16:42

About this skill

Check for updates (Environment Manager)

All environment logic is written only in this Skill: skills version, Runtime installation and health check. Business Skills reference the "Readiness Check" below in a single line in step 0, and carry no environment logic themselves — when the environment policy changes, only this one file is changed. This Skill does not create projects, does not open Studio, and does not transcribe any media.

Readiness Check (business Skills execute step 0 from here)

After all three steps are completed, output one of three states:Ready / New session required / Stop。

1. Locate the current Plugin cache (read-only)

From the host-providedactual source file path of this SkillLocate: the directory containing this file, going up two levels, is <插件根>. Use a file-reading tool to confirm that <插件根>/.codex-plugin/plugin.json and <插件根>/scripts/check-plugin-update.cjs both exist. When the path cannot be obtained, the directory hierarchy does not match, or the file does not exist, use installed_identity_missing to stop the update comparison; do not call CODEX_HOME under the user's codex plugin list to guess, and do not search the entire disk.

In all subsequent commands, <插件根> is substituted with this literal path(if it contains spaces, wrap the whole segment in quotes). Command blocks do not use shell variables or command substitution — the assignment syntax of bash and PowerShell is incompatible. The check script reads the installed manifest, provenance, Marketplace exact revision, and bundle digest directly from the cache it resides in; the check phase does not depend on the user's Marketplace CLI output.

2. Are the skills up to date?

node "<插件根>/scripts/check-plugin-update.cjs" --marketplace chengfeng-videocut --json

(Marketplace name defaults to chengfeng-videocut; if the user has configured another name, use the one they configured.)

  • current → continue to step 3
  • update_available_confirmation_required → display installed、candidate and the four candidate items: version, 40-hex snapshotRevision(B)、40-hex contentRevision(A)、 publisherChecksum(SHA-256), then stop and wait for user confirmation; after confirmation, proceed to the "Activation" section below. Activation success = New session required: the skill text was already loaded at the start of the session, and a mid-session update does not take effect for this session. Ask the user to open a new session before continuing the task
    • If there is also legacyInstalledIdentity=true, this indicates a one-time compatibility migration from historical 0.10.5 to the new provenance format; the same confirmation gate is still used, and the user is not required to modify the Marketplace ref in advance
  • marketplace_not_found / marketplace_source_untrusted / marketplace_ref_unsafe → the current user Marketplace is missing, its source is untrusted, or it is not an exact 40-hex pin; do not call the user's Codex CLI to fix it, report and continue to step 3
  • installed_identity_missing / installed_identity_untrusted → the current cache identity cannot be safely read or proven; do not guess the version and do not activate; report and continue to step 3
  • installed_context_mismatch → the actual cache path of the current Skill, the Marketplace name, or the explicit CODEX_HOME are inconsistent; do not search other caches and do not activate
  • isolated_stage_failed / isolated_stage_schema_invalid / isolated_cleanup_failed → temporary candidate stage, CLI schema, or temporary directory cleanup failed; zero writes to the user's HOME, report and continue to step 3
  • update_metadata_untrusted → the version + B + A + SHA-256 proof does not hold; do not activate; report and continue to step 3
  • candidate_older_than_installed → downgrade is prohibited; report and continue to step 3
  • Network unreachable or other check error → explain one sentence to the user, continue with step three using the current Runtime check— Update check failure does not block the work

Normal checks are only allowed in a temporary CODEX_HOME using the official stable to discover candidates; for the user CODEX_HOME do not call any codex command, and do not write configuration, Marketplace, or cache. All version directories in the current cache must be strict semver; lower versions may remain, but only the single highest semver priority is regarded as active. If at the highest position there are directories with the same priority, return installed_identity_untrusted, and do not pick by the literal order of directory names.

Three, is the Runtime compatible

node "<插件根>/scripts/ensure-runtime.cjs" --install-if-missing --json
  • ready → Ready, business Skill continues
    • runtime.kind=desktop-managed indicates the desktop App has installed the bundled Runtime, Bun, FFmpeg, and FFprobe into the Product's unified managed directory; Skills reuse them directly, without installing additional dependencies or starting additional services
    • runtime.kind=managed/path/source is still a compatible CLI install source; the subsequent business contract is the same
  • missing: the script prompts only once "Installing from GitHub Release", and after SHA-256 verification completes it automatically resumes
  • runtime_unhealthy, install failure, or post-install doctor failure → stop, report structured diagnostics. Stop means stop: it is forbidden to continue the process with a self-made review page, player, timeline, or any substitute interface. Any output produced when the product is unavailable is untrustworthy (real case: when the Runtime was missing, the Agent hand-built a "review desk" webpage, whose review decisions were completely incompatible with the product's ledger format, and the user had to redo everything). There is only one correct action: give the structured diagnostics to the user, and guide them to install or report an Issue
  • runtime_capability_missing → stop: the Runtime is healthy but lower than the contract requires. Report the two version numbers and the differences, and guide the user to confirm before upgrading (the upgrade replaces ~/.chengfeng-videocut/app, project data is not touched); before the user confirms, do not touch the existing installation, and do not roll back to the old editing chain
  • During the readiness check phase, it is forbidden to start services, open Studio, or create projects

Machine prerequisites

Supports macOS and Windows 10/11, with two installation paths:

桌面版(推荐)
  安装并至少启动一次 Chengfeng VideoCut
  -> App 随包安装 Bun、FFmpeg、FFprobe 和 Runtime
  -> 不要求用户把这些工具加入系统 PATH
  -> Skills 通过 ~/.chengfeng-videocut/bin 的稳定入口复用同一服务

纯 CLI 安装
  macOS     brew install bun ffmpeg
  Windows   winget install Oven-sh.Bun Gyan.FFmpeg
            装完新开一个终端/会话,PATH 才生效

Both paths still require Node.js ≥ 20 to execute Plugin scripts; exporting subtitles/animations still requires Google Chrome. Pure CLI users install it themselves; on Windows you can use winget install OpenJS.NodeJS.LTS Google.Chrome. When something is missing, you must stop explicitly and not silently skip it.

Skills update identity self-verification also requires Git; on Windows you can use winget install Git.Git. When Git cannot be executed or cannot read the official snapshot's origin/HEAD/commit relationships, the update check is fail-closed, but still continue the Runtime check according to the above rules.

Cloud transcription additionally requires Volcano Engine credentials:node "<插件根>/scripts/videocut-cli.cjs" config set transcription.apiKey <key>。

For the detailed protocol, see Runtime and product contract。

Skills update: inspect and activate

A pure view only reads the current Plugin cache: no network access, no calling codex, and no writing to the user's CODEX_HOME:

node "<插件根>/scripts/check-plugin-update.cjs" --marketplace "<市场名>" --inspect --json

On success it returns inspected_no_refresh, containing only the current pinned Marketplace and cache identity, and does not generate remote candidates.

Network-isolated check (when the user explicitly says "check for updates", or step two of the readiness check):

node "<插件根>/scripts/check-plugin-update.cjs" --marketplace "<市场名>" --json
  • current: report the latest release identity found in installed and the temporary environment.
  • update_available_confirmation_required: display installed and the candidate's four items version, snapshotRevision(B)、contentRevision(A)、publisherChecksum; stop and wait for user confirmation.
  • legacyInstalledIdentity=true: This is currently the compatible historical 0.10.5 cache. It can enter the previous normal confirmation flow; the old identity is jointly bound by the Marketplace exact revision, cache directory version, manifest version, and inventory digest. Do not have the user change the ref first, and do not create another "migration successful" state.
  • marketplace_not_found / marketplace_source_untrusted / marketplace_ref_unsafe: The current user Marketplace is missing, untrusted, or not pinned to its own exact 40-hex revision; do not automatically change the ref.
  • installed_identity_missing / installed_identity_untrusted: The current cache is unrecognizable or untrusted; do not guess the installed version.
  • installed_context_mismatch: The script execution location is not the current Marketplace's sole highest active cache, or the explicit CODEX_HOME is inconsistent with the HOME to which that cache belongs; do not guess across directories.
  • isolated_stage_failed / isolated_stage_schema_invalid / isolated_cleanup_failed: Only explains a temporary stage, CLI JSON schema, or cleanup failure; does not imply the user's installation has been refreshed.
  • update_metadata_untrusted: The temporary snapshot lacks B, A, SHA-256/manifest recomputation proof, or the identities of the manifest, Marketplace revision, and provenance contradict each other.
  • candidate_older_than_installed: Downgrading from a newer local version is forbidden.
  • Any snapshot/parse/version error: preserve the structured JSON; the user HOME userMutationPerformed=false。

The script executes the official Marketplace CLI only in a newly created temporary CODEX_HOME : first use marketplace add Agentchengfeng/chengfeng-videocut-skills --ref stable to establish the discovery source, then within the same temporary HOME use marketplace upgrade to materialize the snapshot, and with plugin list obtain the candidate.stable The 40-hex B obtained from parsing, the 40-hex A in provenance, the manifest version, and the recomputable SHA-256 jointly constitute the candidate. Git must also prove that the temporary Marketplace origin is the official repository, HEAD=B, A is an ancestor of B, the Plugin working tree is clean, and that A→B changes only the provenance in the Plugin subtree. The temporary directory is deleted after use. The user HOME's Marketplace must remain at the previously confirmed exact B; during the check phase, not even a read-only codex command is invoked on it.

When resolving codex / git on Windows, first look up executable extensions by PATHEXT , then try the extensionless file;.cmd / .bat is wrapped via ComSpec . Therefore a Unix codex shim in the same directory as pnpm will not shadow codex.cmd。

Activate only after explicit user confirmation

Confirmation must occur after the user has seen the exact candidate version, B, A, and checksum:

node "<插件根>/scripts/check-plugin-update.cjs" --marketplace "<市场名>" --activate --confirmed --expected-version "<展示过的版本>" --expected-snapshot-revision "<展示过的B>" --expected-content-revision "<展示过的A>" --expected-sha256 "<展示过的包SHA256>" --json

The script must recreate the temporary CODEX_HOME, stage the candidate again from stable , and compare all four items with --expected-* . If the candidate drifts before or after staging or the parameters do not match, return confirmation_mismatch, with zero writes to the user HOME. After passing, record the exact snapshot revision and cache identity from before the update, then use only official commands to perform on the user HOME:

plugin marketplace remove <市场名>
plugin marketplace add Agentchengfeng/chengfeng-videocut-skills --ref <B>
plugin marketplace upgrade <市场名>

<B> must be the 40-hex snapshotRevision;stablethat was just re-staged and matches what the user confirmed; any other branch, tag, short SHA, or arbitrary different ref returns marketplace_ref_unsafe. After upgrade, the script rereads directly from the cache and verifies version + B + A + SHA-256; only if they are completely identical does it return activated. After successful activation, tell the user to restart Codex or open a new session. If --confirmed is missing, return confirmation_required; if any expected field is missing, different, or drifts after re-staging, return confirmation_mismatch, and both keep zero writes to the user HOME.

Before entering the first write command, the script rereads the user Marketplace and active cache via CAS. If they differ from the old identity saved before staging, return activation_state_changed, activation does not begin, and there are zero writes to the user HOME. If any step of the write transaction fails, the script first checks the post-state of the Marketplace and cache:

  • activation_failed_no_change: after failure it still fully equals the old identity; no rollback needed. userMutationPerformed=false
  • activation_failed_rolled_back: candidate activation failed, but the old exact revision and old cache have been fully restored
  • activation_cache_locked_rolled_back: the failure was identified as cache/file handle occupation, and the old state has been fully restored
  • activation_failed_rollback_incomplete: rollback failed, or you cannot prove that both Marketplace and cache returned to the old identity; report the actual post-state and stop

Only when the post-state has changed, use the saved old exact revision to perform the official remove → add --ref <old B> → upgrade rollback, and directly re-read the cache again. None of the above failure states may be described as "updated". Do not manually copy or delete the cache to fake success; do not touch the Runtime, project, media, EDL, or Studio state.

The user says "set up the editing environment / install players / check the environment"

Directly run the full readiness check; after getting "ready", run the full self-check and report it verbatim:

node "<插件根>/scripts/videocut-cli.cjs" doctor --json

Report: Runtime version and location, each doctor check result, and how to fix missing items (machine dependencies: point to installation; transcription credentials: point to node "<插件根>/scripts/videocut-cli.cjs" config set transcription.apiKey <key>). If runtime.kind=desktop-managed, clearly state that Bun/FFmpeg/FFprobe come from the desktop package and there is no need to modify the system PATH. After installation is complete, tell the user: just say "cut the talking-head video" to start.

Boundaries

  • The Plugin version and Runtime version are independent of each other; the Runtime's minimum compatibility and Release target are controlled by the runtime-requirements.json contract, and no version number is hardcoded in this document
  • stable is used only for temporary discovery; do not write it as a persistent ref installed by the user, and do not describe temporary staging, legacy cache, or local directories as an activated version
  • During the check-for-updates phase, there are zero Codex calls and zero writes to the user's HOME; rollback-capable activation may begin only after seeing and confirming version + B + A + SHA-256
  • Do not publish, and do not modify project data or media; after user confirmation, the official Codex activation and Runtime installation are the only write exceptions
  • Do not search for Electron .app, the NSIS installation directory, or hand Electron resource paths to business Skills; the desktop App is responsible for writing the stable Product entry point, and Skills recognize only that entry point