Files
PaperClipAI/doc/skill-ephemeral-web-servers.md
T
DottaandPaperclip 9efee7ee16 fix(runtime): save dynamic skill bundles before native admission (#19729)
## Thinking Path

> - Paperclip manages agents, tasks, and their saved execution state.
> - A replacement server must restore each admitted skill from shared
storage.
> - Installed company skills already have immutable versions.
> - Connector skills add assigned resources and tool definitions for
each run.
> - Those dynamic bytes keep a null version ID and differ from the
static skill.
> - Native admission saved their input before it saved a durable package
receipt.
> - This change stages the exact packages first and publishes the input
and receipt together.
> - A new connector turn can then survive an empty server home.

## Linked Issues or Issue Description

Refs #19675 for the existing runtime asset preservation owner.

**What happened?**

A new native run with an assigned Slack connector creates a concrete
local skill bundle after the old runtime assets were migrated. Admission
saves its execution input without a preservation receipt. The new run
creates a local durability dependency again.

**Expected behavior**

With S3 configured, the exact dynamic bundle must be durable before the
execution input becomes visible. Its null version ID and admitted bytes
must remain unchanged. Local storage must keep its volume-backed
behavior.

**Steps to reproduce**

1. Configure S3 and a native agent with an assigned Slack resource.
2. Prepare a new native task through the normal runtime selection owner.
3. Inspect its runtime skill receipt or restore its skills with an empty
server home. The previous owner saved no receipt.

**Paperclip version or commit**

Reproduced on master `d1ee25d0f7`. The fix is tested on `4a3396d9b9`.

**Deployment mode**

S3-configured server. Local tests use PostgreSQL 18.1 and a private disk
transport with the S3 receipt contract.

## What Changed

- Extend the existing runtime asset owner with package staging and
transaction-bound receipt validation.
- Stage exact unversioned skill packages before native admission. Keep
storage I/O outside the run transaction.
- Publish the frozen input and receipt together under the existing run,
cancellation, and package collection locks.
- Reject changed input bindings and retired package metadata.
- Reuse valid same-run receipts without reading the previous host's
bundle path or requiring a new object read.
- Keep existing online preservation and local storage behavior.
- Add a bounded preparation span and document its work.

## Verification

- Genuine unchanged-production RED: the actual Slack overlay and real
admission transaction save no preservation receipt.
- Final rebased head: 68 tests pass in three suites in 25.36 seconds.
These include all runtime-selection, runtime-preservation, and connector
controls.
- The new positive checks that no execution input or coordinator is
visible during package readback. It restores exact skill and tool bytes,
modes, digests, and null version IDs in a cold home.
- Guards cover an uncertain storage failure, cancellation during upload,
a changed binding, retired package metadata, and local mode. An existing
receipt remains usable after removing the original bundle and during a
storage outage.
- The canonical PostgreSQL wrapper uses one owned disposable PostgreSQL
18.1 container. Each suite's database is cleaned up. Real package
archives, streams, and readback run locally; no external provider or
model is called.
- Strict server TypeScript, module boundaries, changed-line private-data
checks, and `git diff --check` pass.
- [Final-head
CI](https://github.com/paperclipai/paperclip/actions/runs/42337473062)
passes all required build, typecheck, test, and Runner gates. Fresh
Greptile is 5/5 with no open review threads.

## Risks

New S3-backed admission now requires its dynamic packages to be saved
before execution can proceed. A storage failure can therefore stop
preparation. Existing resource cleanup keeps its authority. Failed or
cancelled staging retains original files and the package owner's pending
receipts. Same-run recovery retains its original capture provenance and
cache behavior. The tests replace the external S3 transport; they do not
qualify live S3 permissions or provider execution. No schema, API,
workflow, company skill version, or provider protocol changes are
included.

## Model Used

OpenAI Codex (GPT-6 family; the exact runtime model ID and context
capacity are not exposed in this session), with reasoning, repository
editing, code execution, and tool use.

## Checklist

- [x] I have included a thinking path that traces from project context
to this change
- [x] I have specified the model used (with version and capability
details)
- [x] I have checked ROADMAP.md and confirmed this PR does not duplicate
planned core work
- [x] I have searched GitHub for duplicate or related PRs and linked
them above
- [x] I have either (a) linked existing issues with `Fixes: #` / `Closes
#` / `Refs #` OR (b) described the issue in-PR following the relevant
issue template
- [x] I have not referenced internal/instance-local Paperclip issues or
links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip`
URLs)
- [x] My branch name describes the change (e.g. `docs/...`, `fix/...`)
and contains no internal Paperclip ticket id or instance-derived details
- [x] I have run tests locally and they pass
- [x] I have added or updated tests where applicable
- [x] I have updated relevant documentation to reflect my changes
- [x] I have considered and documented any risks above
- [x] All Paperclip CI gates are green
- [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups
- [x] I will address all Greptile and reviewer comments before
requesting merge

Co-authored-by: Paperclip <noreply@paperclip.ing>
2026-11-06 22:34:44 -06:00

13 KiB

Skills on ephemeral web servers

The skills guarantee is replacement of A by B, and then C, with empty web-server homes and the same database, object storage, secrets and supported application artifacts. Disk remains useful for scratch archives, verified caches and transport staging. It does not own acknowledged managed edits or installed version selection. This guarantee does not qualify instructions, workspaces, controller state, run logs, traffic switching or readiness/draining for volume removal.

Ownership and publication

managed is Paperclip ownership. Its locator is null; editability does not depend on a directory's position beneath a managed root. Existing policies normalize it to workspace, the policy category previously used by managed local skills. Repository provenance and tracking remain separate from installed content. Forks and disconnected editable copies retain source access and cannot publish restricted content through a public source category.

managed-skill-content.ts reads immutable version inventories, prepares candidates, and publishes them against a captured head. Package upload and verification happen before the final database transaction. That transaction rechecks identity/access, locks names in sorted order, locks the skill, verifies the base, and publishes the version, head, projections and applicable mutation audit/receipt. Publication races return 409; clients must reconcile instead of automatically rebasing. Complete inline versions remain the compatibility fallback when external writes are disabled; they never depend on an installed directory. Normal cloud qualification uses remote object storage.

The initial create response, including its original version, can be replayed after a lost response and subsequent edits. Its durable API receipt retains the response projection without Markdown; the immutable version supplies the body. Receipts remain scoped to company, actor and operation context. A deleted skill's receipt fails explicitly rather than creating another identity.

skill-execution-content.ts owns temporary materialization. Heartbeat preparation selects authorized immutable versions, saves the selection (including an empty selection), and only then materializes admitted entries while retaining the existing retention lock. A renamed skill is recovered through the version's stable skill ID. Native recovery resolves the version, reconstructs its v1 projection and requires the admitted digest, manifest digest, file count and byte count to match. Adjacent compatible releases must preserve that projection contract.

Dynamic connector skills include run-specific resources and tool definitions. They retain null version IDs because their bytes differ from the static company skill. With S3 configured, native runtime selection stages and verifies their exact packages before its admission transaction. That transaction checks the frozen input and cancellation state, locks the package rows against collection, and publishes the input and its preservation receipt together. Storage failure leaves the input unpublished. Existing receipts retain their capture provenance on same-run recovery; hot cache reads can continue during a storage outage. Local storage keeps its existing volume-backed behavior.

Older native inputs can contain immutable skill bundles without a version ID. Retained recovery obligations and current task sessions keep those bundles as local durability dependencies until the runtime-assets maintenance phase copies their authenticated files into the existing package store. The receipt binds the original run input, skill selection, native manifest and package content hash. Recovery restores the original bytes and read/execute modes, verifies the admitted digests, and preserves the null version ID. Package collection protects these receipts under the same row lock used by receipt publication.

This conversion may run online, including for an active run: it only copies an immutable bundle under its publication/collection lock and appends an input-bound receipt. It does not claim provider or controller ownership, settle recovery, start a turn, change task intent or remove local data. Missing or changed sources remain blockers. Ordinary new admission without a completed execution input is not itself a local asset obligation. Both migration and replacement startup check the concrete retained asset obligations independently of installation eligibility.

Run on the host retaining the original runtime asset files, and follow its cursor:

pnpm --filter @paperclipai/server exec tsx scripts/migrate-skill-packages.ts --phase=runtime-assets --company=<uuid> --limit=10
pnpm --filter @paperclipai/server exec tsx scripts/migrate-skill-packages.ts --phase=runtime-assets --company=<uuid> --limit=10 --apply

Studio tests deliver the selected saved version through the same native Runner path, even without a permanent agent assignment. Their skill_test mode remains explicit in the execution input. The durable test row replaces ordinary agent assignments with its exact version, independently of the Beta skills preference; required environment skills remain subject to their existing policy. A shadowed or inaccessible test skill fails preparation. Preconfigured Runner homes cannot receive this managed delivery, so Studio requires an isolated home. Task-bound credentials and native authorization retain the admitted scope through restart and task-mode edits. Native tools expose only the harness task and admitted skills; company browsing, task creation, connectors and assigned MCP tools are unavailable. A rollback image must understand that mode to continue an active Studio test. Settle tests before rolling back to an earlier image that rejects it.

Native task completion publishes the Studio result and output snapshot in the same transaction as its status decision. Replaying a committed decision cannot recapture later document edits or duplicate completion activity. A successful provider turn alone does not complete a test whose task remains unfinished.

Bundled release snapshots remain immutable. Reconciliation preserves an installed head; an older process must never promote its shipped bytes over another installed version. The shipped release history remains independently selectable. Linked-local skills retain mutable source behavior and are explicitly excluded from cloud readiness.

One-time conversion

First deploy compatible readers and shared/API types. Preserve the old volume and keep legacy writers until the final supported contents can be captured. Automatic JSONB package migration is separate from installation conversion; passing one does not prove the other is finished.

Run the existing bounded CLI with the target's explicit database and storage config:

pnpm --filter @paperclipai/server exec tsx scripts/migrate-skill-packages.ts --phase=eligibility --company=<uuid> --limit=10
pnpm --filter @paperclipai/server exec tsx scripts/migrate-skill-packages.ts --phase=installations --company=<uuid> --limit=10

These commands return a cursor. Continue each phase with --after=<uuid> until an empty batch. Eligibility is a metadata-only report, not a storage verification claim. Installation preview inspects candidate legacy contents without publishing them. For remote legacy imports it can acquire their exact pinned source; it must never use the latest branch as a replacement for missing installed content.

  1. Inventory all companies and source kinds. Identify missing versions, incomplete inventory, local storage receipts, catalog reset snapshots and unresolved runs.

  2. Backfill legacy package/version bodies with the existing snapshots and versions phases. The latter also fills missing version metadata indexes so subsequent library/history reads need no object downloads. Keep original bytes until independent verification succeeds.

  3. Copy installations on the host with the legacy files. This phase shares the cache, publication and row locks with normal writers. It checks the exact local source again before publication:

    pnpm --filter @paperclipai/server exec tsx scripts/migrate-skill-packages.ts --phase=installations --company=<uuid> --limit=10 --apply
    
  4. Keep all original directories, versions and inline bytes. Conversion does not settle old execution, recovery or pin uncertainty. Preserve or settle every remaining local dependency through its owner before removing the volume.

  5. Sweep eligibility and verification, including all historical versions. The latter verifies object bytes independently of caches. Follow all cursors; a successful first batch is not a complete readiness report.

  6. Start a compatible server with a fresh home and test list, file read, authoring, history and exact selected execution before reopening normal admission.

Managed conversion preserves skill IDs, keys, history, assignments, pins and access provenance. Identical complete snapshots reuse their version IDs. Catalog conversion preserves the original reset version as well as installed content. A missing legacy directory can use a complete verified saved version. A partial Markdown-only rescue, unknown revision or unsafe source tree blocks conversion. An active legacy selection without exact version identity remains a retention and volume-removal blocker even after copy-only conversion. Preserve or settle such runs while A is still available; do not cancel them simply to pass preflight.

Report statuses distinguish linked-local sources, legacy managed/catalog records, missing current versions, unknown active-run selections, missing/corrupt packages, local storage and provider mismatch. Expired unused Git history keeps its existing 30-day/exact-commit policy. Current, pinned, authored and recovering versions need independent durable content. local_storage is supported self-hosted durability; it does not satisfy remote empty-disk recovery.

Storage and rollback

Cloud readiness requires external Postgres and remote object storage. Migrate and verify existing local-disk objects before changing provider/bucket configuration; changing configuration alone does not copy receipts or objects. Keep the old provider available until a provider migration has copied and independently verified every referenced object and atomically updated its storage receipt. This command does not perform provider migration: local_storage and provider_mismatch are blocking results for cloud qualification, not instructions to switch configuration and retry. A directory of extracted caches is never a durable object backend.

The maintenance CLI reads the existing storage configuration directly so it can verify legacy local-disk objects before cutover. On Cloud it still requires the persisted runtime configuration and never seeds or changes that configuration. This maintenance boundary does not start a server or relax Cloud server startup requirements for external PostgreSQL, shared object storage and a stable secret key. Apply operations retain their existing stopped-writer gates.

Conversion establishes the rollback floor. Afterward only compatible version-reading binaries may overlap or be rolled back against the same remote state. Reattaching an old volume does not roll back committed content. Filesystem-authoritative binaries require an explicit reverse migration and are unsupported rollback targets. A routine compatible A → B upgrade needs no skills conversion or filesystem copy.

A current version ID alone does not establish conversion completeness. Eligibility and independent verification compare its file inventory with the installed record and report incomplete_current_version when supporting files are missing. Installation conversion can reacquire a complete exact pinned source; unavailable or unpinned sources remain blockers. Historical versions are not compared with newer installed inventories, since later revisions may legitimately add files.

Qualification

The focused service suite covers publication rollback/conflict, supporting and binary files, executable modes, restore/fork/rename, active-run deletion protection and legacy conversion. The opt-in process suite starts independent Node servers with one database connection each, exercises real HTTP routes and object storage, removes predecessor homes and executes a delivered harmless script. It also injects a lost response, failed upload and process death during upload. It is a skills-router qualification, not a full hosted Runner or whole-application deployment claim.

Use owned disposable Postgres and S3-compatible fixtures. The optional admin URL creates a random database per test suite and never migrates the database named in that URL. The S3 test creates and removes its own random bucket. Supply test-only AWS credentials through the environment:

PAPERCLIP_TEST_POSTGRES_ADMIN_URL=<disposable-postgres-url> \
PAPERCLIP_TEST_S3_ENDPOINT=<disposable-s3-endpoint> \
pnpm exec vitest run server/src/__tests__/ephemeral-skills-process.test.ts

Record revision, fixture image digests, version IDs, cache/object reads, cold/warm timings and useful output. These local timings do not establish hosted latency. Separately qualify one disposable staging tenant and a real remote Runner, including an explicit repository import, historical pin, fresh-home replacements, compatible rollback and recovery without predecessor paths. Publish the observed evidence with the PR; a passing local suite is not that staging evidence.