feat(code-editing): Step 3 — multi-file model + agent versioning (data layer)

[WayforthOfficial]

Step 3 of code-editing v1 — the versioning data layer, per the approved design (Part B). Builds on the canary-proven security core (Steps 1–2). Pure data layer, no merge — for review.

What's here

• agent_versions table: (id, agent_id, version_no, files JSONB {path:content}, requirements JSONB, params_schema JSONB, image_ref, status, created_at), UNIQUE(agent_id, version_no), FK→hosted_agents ON DELETE CASCADE.
• hosted_agents.active_version_id pointer (nullable FK→agent_versions).
• Backfill (migration 069 + mirrored in check_db): each existing agent's single-file code → one v1 version row {entrypoint: code} (entrypoint by runtime — agent.py/agent.ts), params_schema carried over, no requirements. hosted_agents.code is left untouched.
• core/agent_versions.py: data-access helpers — create_version, get_active_version, get_version, list_versions, activate_version (ownership-guarded so one agent can't point at another's version), next_version_no.
• 14 unit tests (fake-db). Full suite 607 passed.

Confirmation (1): migration is safe + reversible, dispatch unchanged ✅

Ran the actual 069 file against a real Postgres 18.3 with representative + edge-case agents (python, node, no-schema, null-code):

agents=5  versions=5 (one v1 each)   all_have_active_ptr=true   all_v1=true
code_mirrored_right_entrypoint=true  (python→agent.py, node→agent.ts)
params_schema_carried=true   node_uses_agent_ts=true   blank_code_to_empty_string=true
code_UNCHANGED=true   (hosted_agents.code byte-identical pre/post)
reverted_clean=true   (DROP column + table → hosted_agents identical to original)

• Dispatch behavior unchanged — active_version_id/agent_versions are referenced only by the migration, the data layer, and tests. cloud.py has 0 references and still dispatches from hosted_agents.code (cloud.py:373), which the migration never writes. The active pointer is inert until Step 4 wires it.
• Idempotent — re-applying the migration produces already exists, skipping + the NOT EXISTS/active_version_id IS NULL guards make the backfill a no-op, so check_db is safe on every boot.
• Reversible — down-migration is DROP COLUMN active_version_id; DROP TABLE agent_versions;; .code is never touched.

Note: the real DB has 9 agents (you mentioned 6 — likely the deployed subset). All 9 are python3.12, all have code, 0 blank — the migration backfills all of them regardless of status, each → an agent.py v1 mirror.

Confirmation (2): the private mirror is NOT a blocker for this step

The mirror is needed by the build pipeline (Step 1's install-from-mirror). Step 3 builds nothing — backfilled v1 versions have image_ref=NULL and no requirements, and dispatch still runs the unchanged .code path. So the mirror is a parallel infra task, needed at Step 4 (when save→redeploy wires the build that installs deps from the mirror). It can be stubbed/deferred until Step 4; not a blocker here.

🤖 Generated with Claude Code

[railway-app]

🚅 Deployed to the wayforth-pr-66 environment in wayforth

Service	Status	Web	Updated (UTC)
api	❌ Build Failed (View Logs)	Web	Jun 27, 2026 at 7:22 pm

8 services not affected by this PR

• Postgres-DLNK
• Redis
• vault-api
• Postgres
• wayforth-rank
• mcp-server
• crawler
• labs