Correcting the previous commit's reasoning. It claimed the difference between
this file and what production published was inert — a defaulted `webSearch:
false` and a reordered skills list. That was based on comparing the file
against the LIVE row in agent_definitions. The live row was the wrong thing to
compare against: Snapshot compares against the stored v1 in
definition_versions, and those two had diverged.
Read from production directly, v1 as published carries two skills:
skills:
- anomaly-detection
- operational-risk
and the live row carries three, with activity-analysis added. So a skill was
added to this agent after v1 was published, in place, without the version being
raised — the exact silent rewrite this branch exists to stop. It is a genuine
change of behaviour: an agent with a third skill answers differently from one
with two.
So the version is raised rather than the file being bent to match. v1 keeps
what was approved; the current definition, which is what production has been
serving, becomes v2. The earlier alignment of field order and `webSearch:
false` is kept — that part WAS serialisation, and matching it keeps future
imports quiet.
Production has three agents with version rows at all, so two others may hold
the same kind of drift. They did not conflict on this import, which means their
live rows still match what was published; it does not mean nobody edited them.
The image ships agents/, so this file only reaches production on the next
image build. Any build from main at or after this commit carries it; a build
from an older tree will fail the import again, by design.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PJvibeSc1JYXjatankqM1g
The first run of the new importagents against production refused, which is the
guard working rather than a fault: version 1 of activity-agent was already
published and said something different from the file this repository ships.
The difference is inert. Production's copy adds `webSearch: false`, which is
exactly what the parser defaults to when the key is absent (agent.go:471 reads
`data["webSearch"] == true`), and lists the same three skills in a different
order. Both forms parse to the identical agent — 2 tools, 0 sources, 3 skills,
confirmed by running the importer's own dry-run over each.
What happened is a round trip: somebody edited this agent in the UI, the editor
re-serialised it, and that serialisation is what got snapshotted as v1. The
hand-authored file was never the published artefact for this one.
So the file is updated to match rather than the version being bumped. Bumping
would publish a v2 that differs from v1 only in field order and a defaulted
key, which is noise in a history whose whole purpose is to say what changed.
This unblocks the import. It does not address the underlying awkwardness: the
comparison is textual, so any future UI edit that reformats without changing
meaning will block a deploy the same way. Comparing the PARSED definition
instead would fix that properly and is the right follow-up — it needs a
decision about what counts as semantically equal (skill order, starter order)
and should not be rushed in behind a deploy.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PJvibeSc1JYXjatankqM1g
