From 6470d726c3b97867299ea8b89f23c1e165f8cc3e Mon Sep 17 00:00:00 2001
From: cjimti <cj@imti.co>
Date: Sat, 5 Sep 2026 17:45:57 -0700
Subject: [PATCH] feat(scripts): manage_script reads who wrote each version, so
 an author outlives a transfer of the script's ownership (#1639)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

`manage_script command=versions name=<script>` returns the version history newest first: the version number, its author, the roles that author held at that save, the status, when it was written, and the descriptive fields the snapshot carried (display_name, description, category, tags). The response also carries the script's current owner_email, so the two facts are answered side by side.

They are two facts. owner_email is where the script is filed now, and an administrator can move a script to another owner (#1404), after which it names somebody who may never have written a line of it. The author is recorded per version and does not move, so the oldest entry still names whoever created the script. The roles on an entry are the authority a run of that version presents.

The history carries no source. A version holds the whole body, and returning every version's would turn one call into the complete edit history of the file; an earlier version's code is read with command=diff. Who may read the history is who may read the script — its owner, and an administrator on any script — refused in the words command=get uses, and a deployment whose store keeps no versions is refused in the words command=diff uses rather than answered with an empty list.

The tool description and command=help name the command, and docs/scripts/running.md states which command answers which question.

The in-memory store fake answered versions oldest-first while the PostgreSQL store answers ORDER BY version DESC, so it now reverses on the way out and fills the Category and CreatedAt a real row carries.

Claude-Session: https://claude.ai/code/session_01X6eWaeUVdP569e3hMn7GXP
---
 docs/llms.txt                                 |   2 +-
 docs/scripts/running.md                       |  38 +++
 docs/server/tools.md                          |   4 +-
 internal/platform/scriptlayer/content.go      |  46 ++++
 internal/platform/scriptlayer/content_test.go | 105 ++++++++
 internal/platform/scriptlayer/help.go         |  17 +-
 .../platform/scriptlayer/scriptlayer_test.go  |  12 +-
 internal/platform/scriptlayer/tool.go         |   4 +-
 test/acceptance/issue_1639_test.go            | 250 ++++++++++++++++++
 9 files changed, 470 insertions(+), 8 deletions(-)
 create mode 100644 test/acceptance/issue_1639_test.go

diff --git a/docs/llms.txt b/docs/llms.txt
index d1ca05ac3..6fe606773 100644
--- a/docs/llms.txt
+++ b/docs/llms.txt
@@ -44,7 +44,7 @@ Using the platform. These are the pages under `docs` > End User in the site nav.
 - [API Operation Browser](https://mcp-data-platform.txn2.com/server/api-browser/): Two read-only surfaces over the indexed operations of every API connection: /admin/apis lists what has been loaded, catalog by catalog and spec by spec, including catalogs no connection references yet; /apis lists what one caller may call, narrowed by their persona's connection rules and by the route policy api_discover applies, so an operation a deny rule refuses is absent from the list and from the connection's count. An operation's parameters, request body and per-status responses come from the same resolution api_discover returns, and each one carries a copyable curl against POST /api/v1/gateway/{connection}/invoke with the method, path and required parameters filled in, which is what a non-MCP client (Apache NiFi, a cron job) needs to compose a call. Read-only: the page names operations and makes no upstream calls
 - [Session-Start Notices](https://mcp-data-platform.txn2.com/server/session-notices/): The `notices` block platform_info attaches to the first call of every session, for the person who works through an agent and opens neither email nor the portal: unresolved feedback other people left on assets the caller owns (the caller's own threads and their own replies excluded, capped at ten with a total count, each carrying the asset's mcp:asset: reference for fetch and manage_feedback), and the assets, collections, and prompts newly shared with them by name (a public link nobody was named on is not a share with anyone; who shared it is the person who made the grant, not the artifact's owner). Each list is capped and the watermark advances past what did not fit, so the note tells the agent to name the portal as the complete view. Delivery is single-shot: a per-user watermark advances as the digest is issued, so the next session hears only what is new, and the agent instructions in the same response tell the agent to relay it rather than act on it silently. A caller never briefed gets a 30-day window rather than their whole history, and a half that failed to load holds the watermark back rather than being swallowed. No configuration: present wherever the portal and a database are
 - [Resources](https://mcp-data-platform.txn2.com/portal/resources/): Human-uploaded reference files surfaced to AI assistants via MCP resources/list and resources/read, with global, persona, and user scopes. PostgreSQL metadata, S3 blobs, REST API at /api/v1/resources. Also discoverable through the universal search: a background indexer embeds each resource's metadata plus a bounded text prefix extracted from the uploaded file, search hits carry an mcp:resource:<id> reference and an MCP resource link, and fetch returns text contents inline or metadata plus the canonical URI for binary files. Content is revisable in place: a replacement upload keeps the resource id, URI, and filename so references and prompt attachments keep resolving, every revision is recorded in a bounded version history (default 10, oldest blob pruned) with download and restore, a revision the platform wrote on the uploader's behalf carries the reason it was written and the panel renders it beneath the row (#1450), matching what a corrected portal asset's version has always shown, reads through all three surfaces (MCP read, search fetch, REST download) produce resource_read audit events, and the portal shows per-surface read counts, last-read recency, and a never-read flag. One resource opens at a route of its own -- /resources/{id} for the reader, /admin/resources/{id} for the administrator -- taking the same chrome a portal asset takes: the content at the page's full width in the page's own scroll region, with the metadata, tags, canonical URI, usage rollup, version history, table registration panel and attaching prompts in a sidebar beside it, and Download, Edit and Delete in the header under the uploader-or-administrator rule. The library is browsed as a TREE of folders (#1530): its LOCATION -- which library, which folder -- is a route segment (`/resources/lib/global/data/media-manager`, always at least two segments so it can never be confused with `/resources/{id}`, which is exactly one) rather than a query parameter, because `readPath()` drops the query string; each level is a distinct address that a reload returns to, a link opens, and Back steps out of one folder at a time, with breadcrumbs from the library down that navigate to every level and that the resource viewer renders as the same component. A folder's count is everything beneath it at every depth, written `12+` while pages are still loading because it is how many have arrived rather than how many the folder holds. Search spans the WHOLE library rather than the open folder, each hit showing the path it was found at with a Reveal control that walks the tree to it. The library reads like the Assets gallery (#1553): ONE Library dropdown (All, Mine, one entry per persona, Global) replaces the tab strip and All is where both pages open, a persisted grid/table switch replaces the old images-only-folder heuristic and drives the folders, the recents and the files alike, so EVERY file gets a card. A resource's tile is a CAPTURED PNG stored beside its object (#1554, migration 000134): the same browser queue that captures assets renders markdown/CSV/JSON/HTML/SVG and DOWNSCALES a raster image onto the tile, `PUT|GET|DELETE /api/v1/resources/{id}/thumbnail` and `GET /api/v1/resources/thumbnails/pending` are its surface, and pending is a capture that is missing or older than the row's `updated_at` — a TIMESTAMP rather than a version because a resource row has none (its revisions live in `resource_versions`), so the write must not touch `updated_at` or every capture would queue itself forever. The tile used to be the file itself, scaled by CSS and blank past a cutoff. A type nothing can rasterize keeps its content-type icon; `ThumbCard` now falls back to that icon on a FAILED load, not only on a missing URL. That capture rule is one definition per language rather than four (#1568): `internal/thumbtypes` in Go, `CAPTURABLE_FAMILIES` in `ui/src/lib/thumbnailSupport.ts` for the browser gate AND the capturer's dispatch, held to each other by a Go test that reads the TypeScript table; the merged list is html, jsx, svg, markdown, csv, json, plain text and the raster formats a browser DECODES (png, jpeg, gif, webp, avif, bmp, ico -- named one by one rather than as an `image/` prefix, since a TIFF or HEIC can never be captured and the pending query is a bounded window, so offering one starves the drawable files behind it), with markdown, csv, json and plain text captured in both schemes. The four copies had drifted, so a JSX resource and an image asset were never offered work the capturer can do, and plain text was in no list at all although the capturer has prose CSS that draws it. The tile builder now takes the reader's colour scheme for a resource as it always has for an asset -- the grid and the recently-updated strip drew the LIGHT capture in a dark portal, a white card in a dark grid, from a dark capture that was already stored -- and a resource's own page carries the same Thumbnail panel an asset has, with a Recapture control under `CanModifyResource`; `DELETE /api/v1/resources/{id}/thumbnail` takes BOTH variants and no longer reads a `variant` parameter, because two views of one file go together. Drawing an image tile is audited as its own `portal_preview` read surface, the one surface that does not stamp `last_read_at`, so browsing a library of photographs cannot clear the never-read flag on every image in it or reorder the recently-read sort. The asset capture queue no longer stops: its eight-per-poll budget (with a five-minute poll) is gone in favour of the idle gate that was already there, and a failed capture gets three attempts rather than one per tab. a RECENTLY UPDATED strip of the ten files that changed last heads a library at its ROOT only (left off inside a folder and under a search or tag filter, each of which already answers what is relevant), and the upload dialog's folder is a listbox of the folders that exist plus a `New folder...` entry that swaps in a text field, since a folder is created by filing into it and a path that does not exist yet must stay typeable. The All view names no library, so the upload dialog asks, offering the libraries `CanWriteScope` accepts with the caller's own first; folder RENAME is withheld there, naming one library being what a prefix rewrite needs. A library's FACETS come from the server in one request (#1555): `GET /api/v1/resources/facets` returns every folder with its EXACT count (a lateral expansion over each path's segments, so a folder counts everything beneath it at every depth) and the distinct tags its resources carry. Both were derived in the browser from the paged listing, so a folder read `25+` until the last page landed, the tag facet offered only what that page mentioned, and a library ROOT paged 138 rows to draw 4 folder names and displayed none of them — with a Load-more control and a `showing 100 of 138` line over content that was nowhere on screen. A root now runs NO listing at all; a search, and a tag chosen at a root, are the exceptions that replace the tree with a flat list of hits. Server side, `resource.ListScopes` is the listing predicate: a platform administrator's unnarrowed listing is unrestricted (`Filter.AllScopes`, a `TRUE` visibility clause, since user libraries are keyed by subject and address and there is no roster to enumerate) and a narrowed one accepts any library `CanSeeLibrary` allows — membership OR write authority, the rule a folder move already ran under — so an administrator can list back the persona material `CanWriteScope` let them upload and `CanAccessResource` let them open by id. Every other caller's listing is unchanged, and the agent-facing ranked SEARCH stays membership-scoped whoever asks -- enumeration hands a caller material they did not name -- while `fetch` on a stated `mcp:resource:` reference resolves on `CanAccessResource`, the by-id rule, so an administrator is not told a file does not exist while the same session can download and replace it (#1584); `resources/read` remains membership-scoped. A tag filter sits beside the search box and sets the `tag` parameter the list endpoint has always supported. Rows are multi-selectable, with one Move, Tag or Delete over the selection reporting what it did to each file; a file dragged onto a folder is refiled into it and a folder dragged onto another is nested inside it, both through the same confirmation. A page of records that POINT AT resources reads them in one query through `Store.GetByIDs`, keyed by id with a missing row simply absent, which is what the cross-source scratch-table listing resolves its source names and head keys with (#1472). A resource is filed under a FOLDER PATH inside its library (#1529, replacing the one flat `category` that could not nest): slash-separated, each segment keeping the rule the flat label carried (`^[a-z][a-z0-9-]{0,30}$`) so every pre-tree row is already a legal one-segment path and no existing URI changes, at most 8 segments and 200 characters, with a refusal naming the rule it broke. Folders are DERIVED from the paths in use rather than stored as rows, so an empty folder cannot exist; renaming or nesting one is a prefix rewrite over every resource beneath it in a single transaction (`POST /api/v1/resources/folders/move`), each recording the address it vacated, refused whole on a collision or on a file the caller may not change, and capped at 500 resources with the true count stated rather than a partial move. Six first-level names are suggested in the portal -- `data`, `visual`, `samples`, `playbooks`, `templates`, `references`, `data` for records read as fact and `visual` for logos, photographs, diagrams and design elements meant to be displayed, the two that do not describe prose -- as completions and not a closed set, with the server left a shape check. A resource can also be MOVED to another library after upload (#1502), through a Library field on the Edit dialog carrying `scope`/`scope_id` on the existing PATCH route: the owner may move a file into a persona they merely BELONG to (looser than uploading, which still needs `persona-admin:{name}`), and an administrator to any persona, the global library, or a named person's library. Editing the FOLDER is the same rewrite on the other half of that address (#1528, which it did not do before: the breadcrumb came from the `path` column and the Details panel from the `uri` column, and a category edit changed only the first, so a resource's own page printed two different paths for one file); a library and a folder changed in one save produce one URI carrying both, one alias for the one address vacated, and one audit event. The row's scope, folder and canonical URI are rewritten while the blob, id, version trail, table registration and read history are not, every address the resource has vacated stays resolvable through a `resource_uri_aliases` table that a live URI always wins over, declaring assets and attaching prompts keep serving the file because both key on the resource id, a move onto an address another resource holds is refused naming that resource, and each move writes a `resource_move` audit event carrying the library and URI on both sides
-- [Running Managed Scripts](https://mcp-data-platform.txn2.com/scripts/running/): How a managed script runs and what happens when it does. Covers the central rule — a SAVED script runs: `run_script`, the portal's run action, and a cron schedule all execute the script's latest saved version, there is no approval step and no state in which a script exists but nothing may execute it, and `manage_script run_draft` remains the way to execute an edit as yourself before saving it. Covers the authority a run carries (the script's own principal presenting the roles its author held at the save, captured on the immutable version row and settable no other way, resolved to a persona by the middleware at every call so the persona filter decides which connections a run reaches at run time and a persona change takes effect on the next run), who may save (a script is one person's, so its owner and an administrator edit it, schedule it, and DELETE it from the script's own page in the portal (`DELETE /api/v1/portal/scripts/{id}`, #1575) or with `manage_script command=delete` — one store call behind both, taking the saved versions, the schedule, the run history and the carried state, leaving the assets and resources the script wrote and the producer records naming it as their writer, and answering with one account composed once (`script.DeleteMessage`, #1593) that names only what the script actually had, so a script that was never scheduled and carried no state is not reported as having lost either, and recorded from the portal as a `script_delete` audit event of kind `admin`, and an administrator can move it to another owner, chosen from the people who have signed in at least once because an address nobody has authenticated with cannot open the portal — a transfer that hands over everything at once and re-captures the run identity from the administrator making it, recorded in the audit log, and that states what happens to the assets and collections the script's runs have created: `outputs: move` hands them to the new owner in the same transaction, `outputs: keep` leaves them behind and the response lists the files the new owner cannot open, share or delete, and a script that has created any is not moved until the request says which (#1588)), and where output may go (`scripts.destinations` declares each bucket destination by name and complete address — connection, bucket, optional prefix — resolved at run time so repointing one takes effect on the next run, with the portal built in). Covers WHAT A RUN MAY CALL (`platform.call(tool, args)` invokes any platform tool by name and hands the script its structured result — writing a table with `trino_execute`, fetching an external API server-side with `api_invoke_endpoint`, reading an object, capturing a memory — with `platform.query`/`platform.export`/`platform.publish_data` kept as named helpers for the same mechanism; every one of them is one ordinary MCP tool call authorized by the persona filter at the moment it is made under the roles the version's author held at the save, so a script reaches exactly what its author reaches and a deployment that does not want scheduled writes withholds `trino_execute` from the persona rather than from the script layer; `validate` reads the literal tool names into `tools` and reports `dynamic_tools` for a computed one; a write made by tool call is NOT one of the run's outputs — the run's output list and the per-run output cap cover platform.export and platform.publish_data, and everything else is in the audit log — and a query issued by tool call carries no row cap pushed into the statement, which is why the helpers remain the way to do those three things; a tool answering with plain text arrives as {"text": "..."}; `run_script` and `manage_script run_draft` are refused from inside a run because a worker executes one run at a time per replica). Covers `run_script` (arguments checked against the script's parameter contract, a queued run executed by a worker on whichever replica claims it, a bounded wait that hands back a run id and pending status rather than holding the call open, and the run executing the version it was queued against so a save during the wait does not swap code underneath it), stable output identity (one portal asset per script and output name, a new version per run, so a daily report accumulates versions instead of assets), WHO THE OUTPUT BELONGS TO (#1551: the person who owns the script — it is in their Assets page and their `manage_asset action=list` beside the ones they saved themselves, `search` finds it, `fetch` resolves its `mcp:asset:` reference, and they open, rename, retag, share, register a table over and delete it with no administrator; the row records the run's principal as `owner_id`, which is what keeps one asset per (script, output) and what the stored object key is built from, and the script owner's address as `owner_email`, and ownership is judged on EITHER identifier, so a transfer hands over what the script's runs have already produced along with everything else), the two content shapes an output takes (rows serialized in the declared format for csv/json/markdown/text, or a string body written verbatim so a script can compose a document — an HTML or JSX dashboard, a prose report — in markdown, text, html, or jsx) and external delivery for the other case (`platform.export` with a `destination` configuration declares as a bucket writes the same bytes out of the platform at a `key` beneath the configured prefix, so one computed result can refresh a dashboard AND hand a CSV to another system, once per destination per run), the DATA-REGION REFRESH of a semi-dynamic dashboard (`platform.publish_data(name, data)`: the presentation lives in the asset — an html, jsx, or markdown document marking exactly one element `id="data"`, conventionally a `<script type="application/json">` island — and the script refreshes only that element's interior, its dict-or-list payload serialized as JSON and structurally spliced through the same anchored-editing engine `manage_asset` patch uses, writing an ordinary new asset version so every refresh is a self-contained as-of snapshot; the name resolves through the same output identity an export uses, a document without the marked region fails the run, and the layout is edited in the asset like any document with no script change at all), a draft run that persists nothing and reports the size a real run would write, measured by serializing the rows in the declared format rather than estimating them and refused at the same output ceiling, reading run history and logs through `manage_script runs` / `get_run`, the failure model (a script failure is never retried because it reproduces exactly; a `rate_limited` refusal of a script's call is not a script failure, the host waits the envelope's `retry_after_seconds` against the run's deadline, re-issues the call, and logs each wait, so a run whose deadline arrives while pacing fails as a timeout; platform faults retry with backoff; a crashed worker's run is reclaimed by lease and cannot double-write its output), configurable run retention (`scripts.run_retention_days`, one year by default because run history is refresh history), where runs execute (`scripts.worker.enabled`, a `*bool` default on: every replica executes what it enqueues unless a deployment splits serving from execution, and a worker-off replica still registers `run_script`, validates, enqueues, and waits on the result a worker deployment produces), and the drain behavior of a stopping worker (claiming stops at once, a run in flight gets a short capped window out of the shutdown budget rather than the whole of it, anything unfinished is RELEASED rather than failed and is claimable immediately, and every write the stopping worker makes is itself bounded). Covers cron SCHEDULING (a `script_schedules` row of cadence, timezone, and bound parameters and nothing else; standard five-field expressions or descriptors, parsed by robfig/cron/v3 parse-only, read in an IANA zone so a report keeps its wall clock across a daylight-saving change; at most one schedule per script, replaced in place, never deleted because disabling keeps the row that explains its runs; a paused schedule reports no next fire, the stored due time being what it resumes on; set by the script's owner at any scope or by an administrator, from `manage_script` or from the portal's own cadence controls, which ask for a cadence in the terms a person has it in and DERIVE the cron expression rather than asking for it, keeping a Custom field for what the builder cannot express; the `${fire_date}` token expanded onto the run at materialization so a scheduled run is reproducible; single-fire across every replica by a unique index on (schedule, fire time) rather than a leader; skip-if-running overlap recorded as a visible `skipped_overlap` run; fire-once-latest misfire so recovery from downtime produces one run and a missed-fire count instead of a catch-up burst; a failed scheduled run mailed to the script's OWNER, while a `run_script` failure is not, being already in its caller's response; and the alert's rate-limit key being the script principal so one bad night does not silence every other automation's alerts). Covers editing from the portal (`PUT /api/v1/portal/scripts/{id}/source` through `script.ApplyEdit`, the one gate every mutation surface crosses: the edit lands on the live row, is captured as a version, and is the version that runs from then on, with the save saying so — or saying instead that the script is disabled or retired and nothing will execute it), documenting a script (`PUT /api/v1/portal/scripts/{id}/metadata`, or `manage_script update`: display name at 200 characters, the markdown DESCRIPTION rendered as the document it is, the lowercase-slug CATEGORY the listings filter on, and tags; a description refused only above 64 KiB, a structural limit because `script_fts` is built into a GIN index, with an advisory at about 16 KiB that the background might belong in a knowledge page; the category and tag axes narrowing `manage_script list` and the portal listing on the SERVER), CHECKING an edit before saving it (`validate` parses and reports what the edit would reach without executing or storing anything, and reports each destination it names that this deployment does not declare, so a script broken by a configuration change is found without running it; `dry-run` executes the source it is given — the saved version when none is sent — as the caller with the draft limits and persists nothing, one implementation shared with `manage_script run_draft`, leaving an account of the run keyed by the SHA-256 of the source that executed so it attaches to whichever version later carries that code — and a version with no account is code that first executes unattended, which the version detail states plainly), the `connection` parameter type (the platform holds the whole set of values, so every surface that asks for one offers the connections the caller's persona reaches, narrowed to the connections a script can query since a connection is identified by kind and name together and a deployment may carry one name across kinds; an optional one must declare a default, since there is no meaningful empty connection), RUNNING one from the portal (`POST /api/v1/portal/scripts/{id}/runs` queues exactly what `run_script` queues under the same gate, worker and principal, recording `portal` as the trigger, and a script nothing would execute says so instead of offering a control that cannot work), reading what happened in the portal's Scripts pages (the listing, one script's contract, its version history with each version's author and the roles a run of it presents, its run history with logs and output links, and — on a script the caller owns — the cadence, timezone, bound parameters, and pause/resume; a run is readable by the script's owner, an administrator, and whoever requested that run), that every run is measured (script_runs_total, script_run_duration_seconds, script_runs_running, script_missed_fires_total) with the admin portal's Runs tab drawing them beside the run rows themselves, and what a deployment needs for each capability. Covers STATE, what a run carries to the next (#1537): one JSON object per script, `run.state` in and `platform.save_state(obj)` out, 64 KiB, keys meaning whatever the script says (a watermark is `state["synced_through"]`); read once at creation with its revision and recorded on the run row beside params, applied when the run SUCCEEDS in the same transaction under a compare-and-set on the revision read, so a failed run leaves it alone and a second run that read the same revision fails at its write naming the first with its outputs standing; the misfire remedy that follows (a job written against its own watermark reads where the last successful run stopped and needs no backfill after downtime); the owner's and administrator's `manage_script command=state` with `state_action` get/set/clear and the portal page's State card, a reset moving the revision so a run in flight fails at its write; a draft reading the live state and reporting what it would have saved; `validate` reporting `reads_state`/`saves_state` and the contract's `state` block; state surviving a save, a disable and a transfer, and deleted with the script; and the worked example `example-incremental-sync`
+- [Running Managed Scripts](https://mcp-data-platform.txn2.com/scripts/running/): How a managed script runs and what happens when it does. Covers the central rule — a SAVED script runs: `run_script`, the portal's run action, and a cron schedule all execute the script's latest saved version, there is no approval step and no state in which a script exists but nothing may execute it, and `manage_script run_draft` remains the way to execute an edit as yourself before saving it. Covers the authority a run carries (the script's own principal presenting the roles its author held at the save, captured on the immutable version row and settable no other way, resolved to a persona by the middleware at every call so the persona filter decides which connections a run reaches at run time and a persona change takes effect on the next run), who may save (a script is one person's, so its owner and an administrator edit it, schedule it, and DELETE it from the script's own page in the portal (`DELETE /api/v1/portal/scripts/{id}`, #1575) or with `manage_script command=delete` — one store call behind both, taking the saved versions, the schedule, the run history and the carried state, leaving the assets and resources the script wrote and the producer records naming it as their writer, and answering with one account composed once (`script.DeleteMessage`, #1593) that names only what the script actually had, so a script that was never scheduled and carried no state is not reported as having lost either, and recorded from the portal as a `script_delete` audit event of kind `admin`, and an administrator can move it to another owner, chosen from the people who have signed in at least once because an address nobody has authenticated with cannot open the portal — a transfer that hands over everything at once and re-captures the run identity from the administrator making it, recorded in the audit log, and that states what happens to the assets and collections the script's runs have created: `outputs: move` hands them to the new owner in the same transaction, `outputs: keep` leaves them behind and the response lists the files the new owner cannot open, share or delete, and a script that has created any is not moved until the request says which (#1588)), and where output may go (`scripts.destinations` declares each bucket destination by name and complete address — connection, bucket, optional prefix — resolved at run time so repointing one takes effect on the next run, with the portal built in). Covers WHAT A RUN MAY CALL (`platform.call(tool, args)` invokes any platform tool by name and hands the script its structured result — writing a table with `trino_execute`, fetching an external API server-side with `api_invoke_endpoint`, reading an object, capturing a memory — with `platform.query`/`platform.export`/`platform.publish_data` kept as named helpers for the same mechanism; every one of them is one ordinary MCP tool call authorized by the persona filter at the moment it is made under the roles the version's author held at the save, so a script reaches exactly what its author reaches and a deployment that does not want scheduled writes withholds `trino_execute` from the persona rather than from the script layer; `validate` reads the literal tool names into `tools` and reports `dynamic_tools` for a computed one; a write made by tool call is NOT one of the run's outputs — the run's output list and the per-run output cap cover platform.export and platform.publish_data, and everything else is in the audit log — and a query issued by tool call carries no row cap pushed into the statement, which is why the helpers remain the way to do those three things; a tool answering with plain text arrives as {"text": "..."}; `run_script` and `manage_script run_draft` are refused from inside a run because a worker executes one run at a time per replica). Covers `run_script` (arguments checked against the script's parameter contract, a queued run executed by a worker on whichever replica claims it, a bounded wait that hands back a run id and pending status rather than holding the call open, and the run executing the version it was queued against so a save during the wait does not swap code underneath it), stable output identity (one portal asset per script and output name, a new version per run, so a daily report accumulates versions instead of assets), WHO THE OUTPUT BELONGS TO (#1551: the person who owns the script — it is in their Assets page and their `manage_asset action=list` beside the ones they saved themselves, `search` finds it, `fetch` resolves its `mcp:asset:` reference, and they open, rename, retag, share, register a table over and delete it with no administrator; the row records the run's principal as `owner_id`, which is what keeps one asset per (script, output) and what the stored object key is built from, and the script owner's address as `owner_email`, and ownership is judged on EITHER identifier, so a transfer hands over what the script's runs have already produced along with everything else), the two content shapes an output takes (rows serialized in the declared format for csv/json/markdown/text, or a string body written verbatim so a script can compose a document — an HTML or JSX dashboard, a prose report — in markdown, text, html, or jsx) and external delivery for the other case (`platform.export` with a `destination` configuration declares as a bucket writes the same bytes out of the platform at a `key` beneath the configured prefix, so one computed result can refresh a dashboard AND hand a CSV to another system, once per destination per run), the DATA-REGION REFRESH of a semi-dynamic dashboard (`platform.publish_data(name, data)`: the presentation lives in the asset — an html, jsx, or markdown document marking exactly one element `id="data"`, conventionally a `<script type="application/json">` island — and the script refreshes only that element's interior, its dict-or-list payload serialized as JSON and structurally spliced through the same anchored-editing engine `manage_asset` patch uses, writing an ordinary new asset version so every refresh is a self-contained as-of snapshot; the name resolves through the same output identity an export uses, a document without the marked region fails the run, and the layout is edited in the asset like any document with no script change at all), a draft run that persists nothing and reports the size a real run would write, measured by serializing the rows in the declared format rather than estimating them and refused at the same output ceiling, reading run history and logs through `manage_script runs` / `get_run`, the failure model (a script failure is never retried because it reproduces exactly; a `rate_limited` refusal of a script's call is not a script failure, the host waits the envelope's `retry_after_seconds` against the run's deadline, re-issues the call, and logs each wait, so a run whose deadline arrives while pacing fails as a timeout; platform faults retry with backoff; a crashed worker's run is reclaimed by lease and cannot double-write its output), configurable run retention (`scripts.run_retention_days`, one year by default because run history is refresh history), where runs execute (`scripts.worker.enabled`, a `*bool` default on: every replica executes what it enqueues unless a deployment splits serving from execution, and a worker-off replica still registers `run_script`, validates, enqueues, and waits on the result a worker deployment produces), and the drain behavior of a stopping worker (claiming stops at once, a run in flight gets a short capped window out of the shutdown budget rather than the whole of it, anything unfinished is RELEASED rather than failed and is claimable immediately, and every write the stopping worker makes is itself bounded). Covers cron SCHEDULING (a `script_schedules` row of cadence, timezone, and bound parameters and nothing else; standard five-field expressions or descriptors, parsed by robfig/cron/v3 parse-only, read in an IANA zone so a report keeps its wall clock across a daylight-saving change; at most one schedule per script, replaced in place, never deleted because disabling keeps the row that explains its runs; a paused schedule reports no next fire, the stored due time being what it resumes on; set by the script's owner at any scope or by an administrator, from `manage_script` or from the portal's own cadence controls, which ask for a cadence in the terms a person has it in and DERIVE the cron expression rather than asking for it, keeping a Custom field for what the builder cannot express; the `${fire_date}` token expanded onto the run at materialization so a scheduled run is reproducible; single-fire across every replica by a unique index on (schedule, fire time) rather than a leader; skip-if-running overlap recorded as a visible `skipped_overlap` run; fire-once-latest misfire so recovery from downtime produces one run and a missed-fire count instead of a catch-up burst; a failed scheduled run mailed to the script's OWNER, while a `run_script` failure is not, being already in its caller's response; and the alert's rate-limit key being the script principal so one bad night does not silence every other automation's alerts). Covers editing from the portal (`PUT /api/v1/portal/scripts/{id}/source` through `script.ApplyEdit`, the one gate every mutation surface crosses: the edit lands on the live row, is captured as a version, and is the version that runs from then on, with the save saying so — or saying instead that the script is disabled or retired and nothing will execute it), documenting a script (`PUT /api/v1/portal/scripts/{id}/metadata`, or `manage_script update`: display name at 200 characters, the markdown DESCRIPTION rendered as the document it is, the lowercase-slug CATEGORY the listings filter on, and tags; a description refused only above 64 KiB, a structural limit because `script_fts` is built into a GIN index, with an advisory at about 16 KiB that the background might belong in a knowledge page; the category and tag axes narrowing `manage_script list` and the portal listing on the SERVER), CHECKING an edit before saving it (`validate` parses and reports what the edit would reach without executing or storing anything, and reports each destination it names that this deployment does not declare, so a script broken by a configuration change is found without running it; `dry-run` executes the source it is given — the saved version when none is sent — as the caller with the draft limits and persists nothing, one implementation shared with `manage_script run_draft`, leaving an account of the run keyed by the SHA-256 of the source that executed so it attaches to whichever version later carries that code — and a version with no account is code that first executes unattended, which the version detail states plainly), the `connection` parameter type (the platform holds the whole set of values, so every surface that asks for one offers the connections the caller's persona reaches, narrowed to the connections a script can query since a connection is identified by kind and name together and a deployment may carry one name across kinds; an optional one must declare a default, since there is no meaningful empty connection), RUNNING one from the portal (`POST /api/v1/portal/scripts/{id}/runs` queues exactly what `run_script` queues under the same gate, worker and principal, recording `portal` as the trigger, and a script nothing would execute says so instead of offering a control that cannot work), reading what happened in the portal's Scripts pages (the listing, one script's contract, its version history with each version's author and the roles a run of it presents (the same history `manage_script command=versions` returns over MCP, newest first and without the source, so an agent asked who WROTE a script answers from the version records rather than from `owner_email`, which an administrator's transfer moves), its run history with logs and output links, and — on a script the caller owns — the cadence, timezone, bound parameters, and pause/resume; a run is readable by the script's owner, an administrator, and whoever requested that run), that every run is measured (script_runs_total, script_run_duration_seconds, script_runs_running, script_missed_fires_total) with the admin portal's Runs tab drawing them beside the run rows themselves, and what a deployment needs for each capability. Covers STATE, what a run carries to the next (#1537): one JSON object per script, `run.state` in and `platform.save_state(obj)` out, 64 KiB, keys meaning whatever the script says (a watermark is `state["synced_through"]`); read once at creation with its revision and recorded on the run row beside params, applied when the run SUCCEEDS in the same transaction under a compare-and-set on the revision read, so a failed run leaves it alone and a second run that read the same revision fails at its write naming the first with its outputs standing; the misfire remedy that follows (a job written against its own watermark reads where the last successful run stopped and needs no backfill after downtime); the owner's and administrator's `manage_script command=state` with `state_action` get/set/clear and the portal page's State card, a reset moving the revision so a run in flight fails at its write; a draft reading the live state and reporting what it would have saved; `validate` reporting `reads_state`/`saves_state` and the contract's `state` block; state surviving a save, a disable and a transfer, and deleted with the script; and the worked example `example-incremental-sync`
 - [Overview](https://mcp-data-platform.txn2.com/knowledge/overview/): Tribal knowledge capture for data catalogs: memory_capture records insights during AI sessions and, through its sources argument, confirms the recorded call that answered the question so a refined query survives as something the next person can find, apply_knowledge promotes reviewed knowledge to one of three homes -- a DataHub entity, a canonical knowledge page, or the deployment's own byte-bounded customized agent instructions (section-addressed, so a promotion rewrites one rule and leaves the rest byte-identical, with a long body diverted to a page the section then indexes) -- all with changeset tracking and rollback, and the universal search/fetch tools are the discovery and read path across every knowledge source (including the business glossary, tags, and domains as first-class entities, and the caller's own sessions, found by what their calls said they were for and opened to the work they did), bounded by the caller's persona connection rules and reporting what those rules withheld. A delivered insight whose linked entity resolves to a queryable table carries a verifiable block naming that table and connection, on every delivery surface (search hits, fetch, and the memory_context enrichment block), so a claim arrives with the one query that would settle it
 - [Governance Workflow](https://mcp-data-platform.txn2.com/knowledge/governance/): Human-in-the-loop curation: bulk review, approve/reject, synthesized change proposals, DataHub write-back, changeset tracking, and rollback (which returns the reverted changeset's source insights to the review queue as pending, keeping the application they lost, so undoing a promotion never strands the fact that motivated it), with review-queue staleness reported to whoever looks and emailed to operators who do not, and the observed warehouse state a pending claim is decided against (what the entity is queryable as, the rows it currently estimates, and an advisory marker when a stated count disagrees)
 - [Overview](https://mcp-data-platform.txn2.com/memory/overview/): Persistent memory for agent and analyst sessions backed by PostgreSQL + pgvector, with hybrid semantic/lexical recall, cross-enrichment attachment, recall-first capture dedup with duplicate consolidation review, staleness detection, and embedding backfill
diff --git a/docs/scripts/running.md b/docs/scripts/running.md
index 7fa10f362..fe94e8a39 100644
--- a/docs/scripts/running.md
+++ b/docs/scripts/running.md
@@ -105,6 +105,43 @@ whose it is, and the script's page marks the same files under Files written.
 The audit event records the disposition and, for a move, how many rows it
 touched.
 
+### Who owns it and who wrote it
+
+These are two facts about a script, and after a transfer they name two
+different people. `owner_email` — on `manage_script command=get` and on each
+row of `command=list` — is the person the script is filed under NOW: who sees
+it, edits it, runs it, schedules it. The move above changes it.
+
+The author does not move. Every version records the person who saved it and the
+roles they held at that save, and `manage_script command=versions
+name=<script>` reads that history, newest first:
+
+```json
+{
+  "name": "daily-sales-report",
+  "owner_email": "sam@example.com",
+  "count": 3,
+  "versions": [
+    {"version": 3, "author": "admin@example.com", "author_roles": ["admin"], "status": "applied", "created_at": "2026-08-20T09:12:00Z", "display_name": "Daily Sales", "description": "…", "category": "reporting", "tags": ["sales"]},
+    {"version": 2, "author": "jane@example.com", "author_roles": ["analyst"], "status": "applied", "created_at": "2026-08-14T16:04:00Z", "display_name": "Daily Sales", "description": "…", "category": "reporting", "tags": ["sales"]},
+    {"version": 1, "author": "jane@example.com", "author_roles": ["analyst"], "status": "applied", "created_at": "2026-08-13T14:30:00Z", "display_name": "Daily sales", "description": "…", "category": "reporting", "tags": []}
+  ]
+}
+```
+
+The oldest entry names whoever created the script, so "who wrote this?" survives
+a transfer that made `owner_email` somebody else. The roles on an entry are the
+authority a run of that version presents, which is why the transfer's own
+version carries the administrator's roles. The same history is on the script's
+page in the portal.
+
+It carries no source. A version holds the whole body, and returning every
+version's would turn one call into the complete edit history of the file; read
+an earlier version's code with `command=diff`. Who may read the history is who
+may read the script: its owner, and an administrator on any script. A
+deployment whose store keeps no versions refuses the command rather than
+answering with an empty history.
+
 ### What a run may call
 
 A script calls the tools its author can call. `platform.query`,
@@ -859,6 +896,7 @@ record is readable through the tool:
 | `manage_script command=runs name=daily-sales` | What has this script done lately? |
 | `manage_script command=get_run run_id=…` | What did this run do, and what did it print? |
 | `manage_script command=state name=daily-sales` | What will the next run read as `run.state`, and who wrote it? |
+| `manage_script command=versions name=daily-sales` | Who wrote each version of this script, and with what authority? |
 
 ## State: what a run carries to the next
 
diff --git a/docs/server/tools.md b/docs/server/tools.md
index 5cd907bfc..36f9bcd56 100644
--- a/docs/server/tools.md
+++ b/docs/server/tools.md
@@ -1365,7 +1365,9 @@ A script is its owner's, so a reference to one resolves for that owner and for n
 
 `manage_script` authors, validates, and dry-runs **managed scripts**: small Starlark programs the platform stores, versions, and governs, so a process whose logic is already solved (a KPI report, a recurring export) can be re-run without deriving it again through a conversation. Write a script when the logic is settled and the work will repeat; keep using the query tools directly while you are still exploring.
 
-**The loop.** `create` (or `update`/`patch`), then `validate`, then `run_draft`. `validate` parses and resolves the source without executing it, and reports the capabilities and connections the code references, plus a finding for any destination this deployment does not declare. `run_draft` executes it for real, under **your own identity and persona**, with tighter limits than a saved run has, persisting nothing. Both act on the `source` argument when one is sent and on the saved version when it is not, so an edit can be checked and executed before it becomes the version that runs. Commands: `create`, `update`, `patch`, `delete`, `get`, `list`, `diff`, `validate`, `run_draft`, `help`, the run-history commands `runs` and `get_run`, the state command `state` (`state_action` `get`, `set` or `clear`, the owner's and an administrator's read and reset of the one object a script carries between runs), the schedule commands `schedule_set`, `schedule_list`, `schedule_enable`, and `schedule_disable`, plus the shared content verbs (`locate`, `get_content`, `outline`, `stats`) documented in [Editing content in place](#editing-content-in-place).
+**The loop.** `create` (or `update`/`patch`), then `validate`, then `run_draft`. `validate` parses and resolves the source without executing it, and reports the capabilities and connections the code references, plus a finding for any destination this deployment does not declare. `run_draft` executes it for real, under **your own identity and persona**, with tighter limits than a saved run has, persisting nothing. Both act on the `source` argument when one is sent and on the saved version when it is not, so an edit can be checked and executed before it becomes the version that runs. Commands: `create`, `update`, `patch`, `delete`, `get`, `list`, `diff`, `versions`, `validate`, `run_draft`, `help`, the run-history commands `runs` and `get_run`, the state command `state` (`state_action` `get`, `set` or `clear`, the owner's and an administrator's read and reset of the one object a script carries between runs), the schedule commands `schedule_set`, `schedule_list`, `schedule_enable`, and `schedule_disable`, plus the shared content verbs (`locate`, `get_content`, `outline`, `stats`) documented in [Editing content in place](#editing-content-in-place).
+
+**Who owns it and who wrote it.** `owner_email`, on `get` and on each row of `list`, is the person the script is filed under now. An administrator can move a script to another owner, and that field moves with it. The author does not: every version records who saved it and the roles they held at that save, and `versions` reads that history newest first — `version`, `author`, `author_roles`, `status`, `created_at`, and the descriptive fields the snapshot carried (`display_name`, `description`, `category`, `tags`). The oldest entry names whoever created the script, so the question survives a transfer, and the roles on an entry are the authority a run of that version presents. It carries no source; read an earlier version's code with `diff`. Its visibility is `get`'s — the owner's own script, and any script for an administrator — and a deployment whose store keeps no versions refuses it rather than answering with an empty history.
 
 **The dialect, in-context.** Call `help` before writing your first script. Starlark is Python-shaped but deliberately smaller, and `help` states exactly what is available and what a Python instinct will reach for and not find, with the corrective form for each. `help` also returns a `see_also` list naming the platform's built-in authoring pages by slug, each with the reference `fetch` reads it by, so the reasoning the contract states in outline (output identity, the choice between composing a whole document per run and refreshing one document's data region, provenance) is one call away rather than dependent on a search ranking it. `get` also retrieves seeded worked examples (`example-daily-sales`, `example-region-rollup`) so a first script starts from a script that runs. `validate` recognizes the predictable Python-isms and answers with a correction rather than a bare parse error: `import` is not available (`json` and `date` are already predeclared), `try`/`except` does not exist (an error fails the run by design; stop deliberately with `fail("why")`), f-strings are not supported (use `.format()` or `%`), `while` and recursion are off, and there is no clock, no randomness, no filesystem, and no network.
 
diff --git a/internal/platform/scriptlayer/content.go b/internal/platform/scriptlayer/content.go
index 77ee13801..96dcc9edd 100644
--- a/internal/platform/scriptlayer/content.go
+++ b/internal/platform/scriptlayer/content.go
@@ -185,3 +185,49 @@ func versionSource(ctx context.Context, versions script.VersionStore, history []
 	}
 	return v.Source, nil
 }
+
+// handleVersions returns the script's version history: who wrote each version
+// and the authority they held, newest first.
+//
+// It answers a different question from get. `owner_email` is where the script
+// is filed now, and an administrator can move a script to somebody else
+// (#1404), so after a transfer that field names a person who may never have
+// written a line of it. The author is recorded per version and does not move,
+// which is why the oldest entry still names whoever created the script.
+//
+// The source stays out. A history entry carries the whole body, and returning
+// every version's would turn one call into the complete edit history of the
+// file; the body of an earlier version is read through command=diff.
+func (h *Handle) handleVersions(ctx context.Context, input manageScriptInput) (*mcp.CallToolResult, any, error) {
+	sc, errResult := h.readable(ctx, input)
+	if errResult != nil {
+		return errResult, nil, nil
+	}
+	if h.versions == nil {
+		return errorResult("script versioning is unavailable on this deployment"), nil, nil
+	}
+	history, err := h.versions.ListVersions(ctx, sc.ID)
+	if err != nil {
+		slog.Error("failed to list script versions", fieldName, sc.Name, logKeyError, err)
+		return errorResult("failed to read the version history"), nil, nil
+	}
+	entries := make([]map[string]any, 0, len(history))
+	for i := range history {
+		entries = append(entries, versionFields(&history[i]))
+	}
+	return jsonResult(map[string]any{
+		fieldName: sc.Name, "owner_email": sc.OwnerEmail,
+		"versions": entries, "count": len(entries),
+	})
+}
+
+// versionFields renders one version for a history response: what was saved,
+// who saved it, and the authority they held at that save.
+func versionFields(v *script.Version) map[string]any {
+	return map[string]any{
+		fieldVersion: v.Version, "author": v.Author, "author_roles": orEmpty(v.AuthorRoles),
+		fieldStatus: v.Status, "created_at": v.CreatedAt.UTC(),
+		"display_name": v.DisplayName, "description": v.Description,
+		"category": v.Category, "tags": orEmpty(v.Tags),
+	}
+}
diff --git a/internal/platform/scriptlayer/content_test.go b/internal/platform/scriptlayer/content_test.go
index ac2983b2d..188c27ac4 100644
--- a/internal/platform/scriptlayer/content_test.go
+++ b/internal/platform/scriptlayer/content_test.go
@@ -1,6 +1,7 @@
 package scriptlayer
 
 import (
+	"context"
 	"encoding/json"
 	"errors"
 	"reflect"
@@ -10,6 +11,7 @@ import (
 	"github.com/stretchr/testify/assert"
 	"github.com/stretchr/testify/require"
 
+	"github.com/txn2/mcp-data-platform/pkg/script"
 	"github.com/txn2/mcp-data-platform/pkg/textpatch"
 )
 
@@ -230,3 +232,106 @@ func TestDiff_StoreFailureIsNotReportedAsAMissingVersion(t *testing.T) {
 	assert.Contains(t, resultText(res), "version history")
 	assert.NotContains(t, resultText(res), "not found")
 }
+
+// TestVersions_ReportsEveryAuthorNewestFirst is the history read: two applied
+// versions, newest first, each naming its author and the authority that author
+// held at the save.
+func TestVersions_ReportsEveryAuthorNewestFirst(t *testing.T) {
+	h, _ := newHandle()
+	createDaily(t, h)
+	call(t, h, authorCtx(), manageScriptInput{Command: cmdUpdate, Name: "daily", Source: "print(\"changed\")\n"})
+
+	fields := resultFields(t, call(t, h, authorCtx(), manageScriptInput{Command: cmdVersions, Name: "daily"}))
+	assert.EqualValues(t, 2, fields["count"])
+	assert.Equal(t, "jane@example.com", fields["owner_email"])
+	versions, ok := fields["versions"].([]any)
+	require.True(t, ok)
+	require.Len(t, versions, 2)
+
+	newest, ok := versions[0].(map[string]any)
+	require.True(t, ok)
+	assert.EqualValues(t, 2, newest[fieldVersion])
+	assert.Equal(t, "jane@example.com", newest["author"])
+	assert.Equal(t, []any{"analyst"}, newest["author_roles"])
+	assert.Equal(t, script.VersionStatusApplied, newest[fieldStatus])
+	assert.NotEmpty(t, newest["created_at"])
+	assert.Equal(t, "Daily", newest["display_name"])
+	assert.NotContains(t, newest, fieldSource, "the history carries no source; diff reads a version's code")
+
+	oldest, ok := versions[1].(map[string]any)
+	require.True(t, ok)
+	assert.EqualValues(t, 1, oldest[fieldVersion])
+	assert.Equal(t, "jane@example.com", oldest["author"])
+}
+
+// TestVersions_SurvivesAnOwnerTransfer is the question the command exists for:
+// after an administrator moves a script (#1404), owner_email names the new
+// owner and the history still names the person who wrote the first version.
+func TestVersions_SurvivesAnOwnerTransfer(t *testing.T) {
+	h, store := newHandle()
+	createDaily(t, h)
+	sc, err := store.GetByName(context.Background(), "jane@example.com", "daily")
+	require.NoError(t, err)
+	require.NotNil(t, sc)
+	_, err = store.Transfer(context.Background(),
+		script.TransferRequest{ID: sc.ID, NewOwnerEmail: "sam@example.com"},
+		script.Author{Email: "admin@example.com", Roles: []string{"admin"}})
+	require.NoError(t, err)
+
+	got := resultFields(t, call(t, h, adminCtx(), manageScriptInput{
+		Command: cmdGet, Name: "daily", OwnerEmail: "sam@example.com",
+	}))
+	assert.Equal(t, "sam@example.com", got["owner_email"])
+
+	fields := resultFields(t, call(t, h, adminCtx(), manageScriptInput{
+		Command: cmdVersions, Name: "daily", OwnerEmail: "sam@example.com",
+	}))
+	assert.Equal(t, "sam@example.com", fields["owner_email"])
+	versions, ok := fields["versions"].([]any)
+	require.True(t, ok)
+	require.Len(t, versions, 2)
+	first, ok := versions[len(versions)-1].(map[string]any)
+	require.True(t, ok)
+	assert.EqualValues(t, 1, first[fieldVersion])
+	assert.Equal(t, "jane@example.com", first["author"], "the author of the first version does not move with the script")
+}
+
+// TestVersions_NotTheOwnerGetsTheGetRefusal holds the history to the visibility
+// get already applies, in the same words: naming the difference would confirm
+// the script exists to somebody who may not see it.
+func TestVersions_NotTheOwnerGetsTheGetRefusal(t *testing.T) {
+	h, _ := newHandle()
+	createDaily(t, h)
+	stranger := callerCtx("sam@example.com", "analyst")
+
+	versionsRes := call(t, h, stranger, manageScriptInput{Command: cmdVersions, Name: "daily"})
+	getRes := call(t, h, stranger, manageScriptInput{Command: cmdGet, Name: "daily"})
+	assert.True(t, versionsRes.IsError)
+	assert.Equal(t, resultText(getRes), resultText(versionsRes))
+}
+
+// TestVersions_WithoutAVersionStoreRefusesLikeDiff covers the degraded
+// deployment: no versioning means no history, refused in the terms diff
+// already refuses in rather than answered with an empty list.
+func TestVersions_WithoutAVersionStoreRefusesLikeDiff(t *testing.T) {
+	h := New(Config{Store: &unversionedStore{inner: newMemStore()}, AdminPersona: "admin"})
+	require.Nil(t, h.versions)
+	createDaily(t, h)
+
+	res := call(t, h, authorCtx(), manageScriptInput{Command: cmdVersions, Name: "daily"})
+	diffRes := call(t, h, authorCtx(), manageScriptInput{Command: cmdDiff, Name: "daily"})
+	assert.True(t, res.IsError)
+	assert.Equal(t, resultText(diffRes), resultText(res))
+}
+
+// TestVersions_StoreFailureIsReportedAsSuch keeps a store that blinked from
+// reading as a script with no history.
+func TestVersions_StoreFailureIsReportedAsSuch(t *testing.T) {
+	h, store := newFailingHandle()
+	createDaily(t, h)
+	store.listVersionsErr = errors.New("pq: connection reset")
+
+	res := call(t, h, authorCtx(), manageScriptInput{Command: cmdVersions, Name: "daily"})
+	require.True(t, res.IsError)
+	assert.Contains(t, resultText(res), "version history")
+}
diff --git a/internal/platform/scriptlayer/help.go b/internal/platform/scriptlayer/help.go
index 861099819..6de086a37 100644
--- a/internal/platform/scriptlayer/help.go
+++ b/internal/platform/scriptlayer/help.go
@@ -23,7 +23,9 @@ const manageScriptDescription = "Author, validate, and dry-run managed scripts:
 	"reports what the script would reach, runs nothing), then run_draft (executes for real under YOUR " +
 	"identity and persona, with tighter limits, persisting nothing). " +
 	"A saved script runs: run_script executes its latest saved version as the script's own principal, " +
-	"presenting the roles you held when you saved it, and a schedule fires it the same way."
+	"presenting the roles you held when you saved it, and a schedule fires it the same way. " +
+	"command=versions reads the history of who wrote each version, which is not the same question as " +
+	"who owns the script now."
 
 // DialectContract is the help command's body: what a script is, what is
 // predeclared, and what a Python instinct will reach for and not find.
@@ -233,7 +235,18 @@ THE LOOP
   A draft reads the script's live state and reports what it would have saved;
   manage_script command=state reads, replaces or clears the state itself, which
   is how a wrong watermark is corrected: clear it and let the next run start
-  over.`
+  over.
+
+WHO OWNS IT AND WHO WROTE IT
+  These are two facts, and two commands answer them. get reports owner_email,
+  the person the script is filed under NOW; an administrator can move a script
+  to somebody else, and the address moves with it. command=versions reports the
+  history newest first — the version number, its author, the roles that author
+  held at that save, the status, when it was written, and what the script
+  called itself then. The roles are the authority a run of that version
+  presents, and the oldest entry names whoever created the script, so a
+  transfer never loses the author. It carries no source; read an earlier
+  version's code with command=diff.`
 
 // example is one built-in worked script, retrievable by name through get.
 type example struct {
diff --git a/internal/platform/scriptlayer/scriptlayer_test.go b/internal/platform/scriptlayer/scriptlayer_test.go
index 0a2b95f26..a2ae2d850 100644
--- a/internal/platform/scriptlayer/scriptlayer_test.go
+++ b/internal/platform/scriptlayer/scriptlayer_test.go
@@ -122,9 +122,10 @@ func (m *memStore) Create(_ context.Context, sc *script.Script, author script.Au
 func (m *memStore) snapshot(sc *script.Script, author script.Author, status string) {
 	m.versions[sc.ID] = append(m.versions[sc.ID], script.Version{
 		ID: fmt.Sprintf("sver_%s_%d", sc.ID, sc.Version), ScriptID: sc.ID, Version: sc.Version,
-		DisplayName: sc.DisplayName, Description: sc.Description, Source: sc.Source,
+		DisplayName: sc.DisplayName, Description: sc.Description, Category: sc.Category,
+		Source: sc.Source,
 		Params: sc.Params, Tags: sc.Tags, Author: author.Email, AuthorRoles: author.Roles,
-		Status: status,
+		Status: status, CreatedAt: time.Now().UTC(),
 	})
 }
 
@@ -235,8 +236,13 @@ func (m *memStore) UpdateWithVersion(ctx context.Context, sc *script.Script, aut
 	return m.Update(ctx, sc)
 }
 
+// ListVersions answers newest first, as the PostgreSQL store's ORDER BY
+// version DESC does. The fake appends in save order, so it reverses on the way
+// out rather than leaving the ordering half of the contract to the caller.
 func (m *memStore) ListVersions(_ context.Context, scriptID string) ([]script.Version, error) {
-	return slices.Clone(m.versions[scriptID]), nil
+	history := slices.Clone(m.versions[scriptID])
+	slices.Reverse(history)
+	return history, nil
 }
 
 func (m *memStore) GetVersionByID(_ context.Context, id string) (*script.Version, error) {
diff --git a/internal/platform/scriptlayer/tool.go b/internal/platform/scriptlayer/tool.go
index 3ac24fe26..8741e59d2 100644
--- a/internal/platform/scriptlayer/tool.go
+++ b/internal/platform/scriptlayer/tool.go
@@ -32,6 +32,7 @@ const (
 	cmdOutline    = "outline"
 	cmdStats      = "stats"
 	cmdDiff       = "diff"
+	cmdVersions   = "versions"
 	cmdRuns       = "runs"
 	cmdGetRun     = "get_run"
 	cmdState      = "state"
@@ -167,6 +168,7 @@ func (h *Handle) commands() map[string]commandHandler {
 		cmdOutline:    h.handleOutline,
 		cmdStats:      h.handleStats,
 		cmdDiff:       h.handleDiff,
+		cmdVersions:   h.handleVersions,
 		cmdRuns:       h.handleRuns,
 		cmdGetRun:     h.handleGetRun,
 		cmdState:      h.handleState,
@@ -267,7 +269,7 @@ func manageScriptSchema() any {
 			keyEnum: []string{
 				cmdCreate, cmdUpdate, cmdDelete, cmdGet, cmdList, cmdValidate,
 				cmdRunDraft, cmdHelp, cmdPatch, cmdLocate, cmdGetContent,
-				cmdOutline, cmdStats, cmdDiff, cmdRuns, cmdGetRun, cmdState,
+				cmdOutline, cmdStats, cmdDiff, cmdVersions, cmdRuns, cmdGetRun, cmdState,
 				cmdScheduleSet, cmdScheduleList, cmdScheduleEnable, cmdScheduleDisable,
 			},
 			keyDescription: "The operation to perform. Call 'help' first if you have not written a " +
diff --git a/test/acceptance/issue_1639_test.go b/test/acceptance/issue_1639_test.go
new file mode 100644
index 000000000..2465c0ee7
--- /dev/null
+++ b/test/acceptance/issue_1639_test.go
@@ -0,0 +1,250 @@
+//go:build integration
+
+package acceptance
+
+import (
+	"net/http"
+	"strings"
+	"testing"
+)
+
+// Issue #1639: an agent asked who wrote a script had only owner_email to
+// answer with, which is where the script is filed and not who wrote the code.
+// An administrator can move a script to another owner (#1404), and after a
+// move that field names somebody who may never have written a line of it. The
+// authors are recorded — every version carries its author and the roles that
+// author held at the save — and until now that history was readable in the
+// portal and nowhere else.
+//
+// manage_script command=versions returns it: newest first, each entry naming
+// the version, its author, the roles captured at that save, the status, when
+// it was written, and the descriptive fields the snapshot carried. Every
+// criterion below is executed through the real surfaces — the tool through a
+// real tools/call as the person it is about, the transfer through the portal
+// route the transfer dialog calls, as an administrator.
+//
+// Wire forms: the manage_script parameters these calls send are typed in the
+// tool's closed input schema and each admits exactly one JSON form — command,
+// name, source, description and owner_email are strings, params an array of
+// objects — and every call below sends them as literal tools/call parameters
+// of that form. The one route touched, PUT /portal/scripts/{id}/owner, takes
+// owner_email, a string. There is no untyped or `any` parameter on this path,
+// so no parameter has a second form to send.
+//
+// One criterion in the ticket is not executable here and is covered by a unit
+// test instead: a deployment whose store does not implement script.VersionStore
+// refuses the command in the terms command=diff refuses in. The dev stack runs
+// the PostgreSQL store, which implements versioning, so that shape cannot be
+// stood up through the real surface; it is asserted in
+// TestVersions_WithoutAVersionStoreRefusesLikeDiff.
+
+// scriptSource1639 is a script that runs nothing external, because these
+// criteria are about the record of who SAVED a version, not about execution.
+const scriptSource1639 = `
+print("acceptance 1639")
+`
+
+// scriptSource1639Edited is the second save, which is what produces a second
+// version to read an author off.
+const scriptSource1639Edited = `
+print("acceptance 1639, edited")
+`
+
+// createScript1639 saves a script owned and authored by the calling person and
+// returns the id the portal route addresses it by.
+func createScript1639(t *testing.T, c *client, name string) string {
+	t.Helper()
+	c.call("manage_script", map[string]any{
+		"command":     "create",
+		"name":        name,
+		"description": "Acceptance #1639: a script whose authors outlive its ownership.",
+		"source":      scriptSource1639,
+	})
+	t.Cleanup(func() {
+		_, _, _ = c.callRaw("manage_script", map[string]any{"command": "delete", "name": name})
+	})
+	return scriptIDOf1579(t, c, name)
+}
+
+// versions1639 reads the history through the tool and returns the entries.
+func versions1639(t *testing.T, c *client, args map[string]any) []map[string]any {
+	t.Helper()
+	args["command"] = "versions"
+	out := c.call("manage_script", args)
+	raw, ok := out["versions"].([]any)
+	if !ok {
+		t.Fatalf("manage_script command=versions returned no versions list: %v", out)
+	}
+	entries := make([]map[string]any, 0, len(raw))
+	for _, item := range raw {
+		entry, ok := item.(map[string]any)
+		if !ok {
+			t.Fatalf("a version entry is not an object: %v", item)
+		}
+		entries = append(entries, entry)
+	}
+	if count, _ := out["count"].(float64); int(count) != len(entries) {
+		t.Fatalf("count %v does not match the %d entries returned", out["count"], len(entries))
+	}
+	return entries
+}
+
+// authorOf1639 reads one entry's author, failing when it carries none.
+func authorOf1639(t *testing.T, entry map[string]any) string {
+	t.Helper()
+	author, _ := entry["author"].(string)
+	if author == "" {
+		t.Fatalf("a version entry names no author: %v", entry)
+	}
+	return author
+}
+
+// rolesOf1639 reads one entry's captured roles, failing when it carries none.
+func rolesOf1639(t *testing.T, entry map[string]any) []string {
+	t.Helper()
+	raw, ok := entry["author_roles"].([]any)
+	if !ok || len(raw) == 0 {
+		t.Fatalf("a version entry carries no author_roles: %v", entry)
+	}
+	roles := make([]string, 0, len(raw))
+	for _, r := range raw {
+		role, _ := r.(string)
+		roles = append(roles, role)
+	}
+	return roles
+}
+
+// TestIssue1639_EveryVersionNamesItsAuthorNewestFirst is criterion 1: a script
+// with two applied versions answers with two entries, newest first, each
+// carrying a non-empty author and the roles recorded at that save.
+func TestIssue1639_EveryVersionNamesItsAuthorNewestFirst(t *testing.T) {
+	owner := connectAs(t, devOwnerAPIKey)
+	name := "acceptance-1639-history-" + unique1579()
+	createScript1639(t, owner, name)
+	owner.call("manage_script", map[string]any{
+		"command": "update", "name": name, "source": scriptSource1639Edited,
+	})
+
+	entries := versions1639(t, owner, map[string]any{"name": name})
+	if len(entries) != 2 {
+		t.Fatalf("want two applied versions, got %d: %v", len(entries), entries)
+	}
+	newest, _ := entries[0]["version"].(float64)
+	older, _ := entries[1]["version"].(float64)
+	if newest != 2 || older != 1 {
+		t.Fatalf("the history is not newest first: %v then %v", newest, older)
+	}
+	for i, entry := range entries {
+		if author := authorOf1639(t, entry); author != devOwnerEmail {
+			t.Fatalf("entry %d names %q as its author, want %q", i, author, devOwnerEmail)
+		}
+		if roles := rolesOf1639(t, entry); len(roles) == 0 {
+			t.Fatalf("entry %d carries no roles from its save: %v", i, entry)
+		}
+		if status, _ := entry["status"].(string); status != "applied" {
+			t.Fatalf("entry %d has status %q, want applied", i, status)
+		}
+		if created, _ := entry["created_at"].(string); created == "" {
+			t.Fatalf("entry %d says nothing about when it was written: %v", i, entry)
+		}
+		if _, carriesSource := entry["source"]; carriesSource {
+			t.Fatalf("entry %d carries the source; the history is metadata and diff reads a version's code: %v", i, entry)
+		}
+	}
+	t.Logf("history of %s: %v", name, entries)
+}
+
+// TestIssue1639_TheAuthorSurvivesAnOwnerTransfer is criterion 2, the question
+// the command exists for: after an administrator moves the script, get reports
+// the new owner and the history still reports the original author on the
+// oldest entry.
+func TestIssue1639_TheAuthorSurvivesAnOwnerTransfer(t *testing.T) {
+	owner := connectAs(t, devOwnerAPIKey)
+	// The peer connects before the transfer: an address nobody has ever
+	// authenticated with is not one a script can be handed to.
+	peer := connectAs(t, devPeerAPIKey)
+	admin := connect(t)
+
+	name := "acceptance-1639-transfer-" + unique1579()
+	scriptID := createScript1639(t, owner, name)
+	owner.call("manage_script", map[string]any{
+		"command": "update", "name": name, "source": scriptSource1639Edited,
+	})
+	t.Cleanup(func() {
+		_, _, _ = peer.callRaw("manage_script", map[string]any{"command": "delete", "name": name})
+	})
+
+	before := versions1639(t, owner, map[string]any{"name": name})
+	original := authorOf1639(t, before[len(before)-1])
+
+	status, body := admin.rest(http.MethodPut, "/api/v1/portal/scripts/"+scriptID+"/owner",
+		strings.NewReader(`{"owner_email":"`+devPeerEmailAddr+`"}`))
+	if status != http.StatusOK {
+		t.Fatalf("the transfer to %s failed: status %d: %v", devPeerEmailAddr, status, body)
+	}
+
+	got := peer.call("manage_script", map[string]any{"command": "get", "name": name})
+	if ownerEmail, _ := got["owner_email"].(string); ownerEmail != devPeerEmailAddr {
+		t.Fatalf("get reports %q as the owner after the transfer, want %q", ownerEmail, devPeerEmailAddr)
+	}
+
+	after := versions1639(t, peer, map[string]any{"name": name})
+	oldest := after[len(after)-1]
+	if v, _ := oldest["version"].(float64); v != 1 {
+		t.Fatalf("the last entry is version %v, want the first version: %v", v, oldest)
+	}
+	if author := authorOf1639(t, oldest); author != original || author != devOwnerEmail {
+		t.Fatalf("the first version now names %q as its author, want the person who wrote it (%q)",
+			author, devOwnerEmail)
+	}
+	t.Logf("after the transfer to %s, version 1 is still written by %s", devPeerEmailAddr, original)
+}
+
+// TestIssue1639_ARefusalIsTheOneGetGives is criterion 3: somebody who is
+// neither the owner nor an administrator is refused the history in exactly the
+// words they are refused the script, because naming the difference would
+// confirm the script exists to a caller who may not see it.
+func TestIssue1639_ARefusalIsTheOneGetGives(t *testing.T) {
+	owner := connectAs(t, devOwnerAPIKey)
+	stranger := connectAs(t, devPeerAPIKey)
+	name := "acceptance-1639-private-" + unique1579()
+	createScript1639(t, owner, name)
+
+	versionsRes, versionsText, err := stranger.callRaw("manage_script",
+		map[string]any{"command": "versions", "name": name})
+	if err != nil {
+		t.Fatalf("manage_script command=versions: transport error: %v", err)
+	}
+	getRes, getText, err := stranger.callRaw("manage_script",
+		map[string]any{"command": "get", "name": name})
+	if err != nil {
+		t.Fatalf("manage_script command=get: transport error: %v", err)
+	}
+	if !versionsRes.IsError || !getRes.IsError {
+		t.Fatalf("a stranger reached the script: versions error=%v (%s), get error=%v (%s)",
+			versionsRes.IsError, versionsText, getRes.IsError, getText)
+	}
+	if versionsText != getText {
+		t.Fatalf("the two refusals differ, which tells a stranger the script exists:\n  versions: %q\n  get:      %q",
+			versionsText, getText)
+	}
+	t.Logf("both refusals read: %s", getText)
+}
+
+// TestIssue1639_AnAdministratorReadsAnybodysHistory covers the other half of
+// the visibility rule get applies: an administrator reads the history of a
+// script they do not own, addressed by its owner.
+func TestIssue1639_AnAdministratorReadsAnybodysHistory(t *testing.T) {
+	owner := connectAs(t, devOwnerAPIKey)
+	admin := connect(t)
+	name := "acceptance-1639-admin-read-" + unique1579()
+	createScript1639(t, owner, name)
+
+	entries := versions1639(t, admin, map[string]any{"name": name, "owner_email": devOwnerEmail})
+	if len(entries) == 0 {
+		t.Fatalf("an administrator read no history for %s", name)
+	}
+	if author := authorOf1639(t, entries[len(entries)-1]); author != devOwnerEmail {
+		t.Fatalf("the first version names %q as its author, want %q", author, devOwnerEmail)
+	}
+}