skills: replace edit-services with an update-service front door

[gnguralnick]

What

Editing an existing service had no clear entry point in the skill set. The old edit-services skill only documented the supervisord [program:*] plumbing, so an agent that just edited a service's backend or frontend logic never had a reason to load it -- and nothing reliably prompted the two things that leave the user looking at stale state: reloading the process so the change takes effect, and refreshing the open web tab so they can see it.

This replaces edit-services with update-service, a front-door skill whose description triggers on editing/fixing/restyling/extending an existing service -- web service or background daemon -- and, on top of that, encodes how to change a service without ever risking the user's data.

The new skill

• Live change loop: apply the change so it takes effect (restart for backend changes, since the runner has use_reloader=False; nothing for frontend-only; reread/update for definition changes), refresh the user's tab for web services (layout.py refresh <name>), then verify.
• Scope-aware routing: a contained change goes straight through the live loop; a larger-scope change (redesign, new view, look-and-feel shift) routes back through the same interactive-delivery (mock-confirm) flow used to build the service, so heavy work never happens against an unconfirmed shape.
• Turn-end handoff to the update-artifact / heal-artifact hardening core, mirroring how update-system-interface wraps that core for the workspace UI.

The supervisord program mechanics move into update-service/references/service-processes.md, cited only for definition-level changes. Cross-links in build-web-service (SKILL + cleanup.md), libs/bootstrap/README.md, and CLAUDE.md now point at update-service.

Protecting user data on service edits

A recurring, expensive failure mode when editing a service is not the code edit: it's verifying the change by writing test data into the live store and then "cleaning up" with a delete/reset whose predicate is too broad and takes real user records with it. The skill now encodes data isolation as the safeguard -- deliberately lighter than deferring every edit to an isolated worktree, which isolates the wrong thing (code) and doesn't even protect the data, since the running service still reads and writes the same runtime/<name>/.

• The scaffold generates a redirectable data pointer. New services' runner.py now defines a DATA_DIR constant that defaults to runtime/<name>/ but honors a per-service <PACKAGE_UPPER>_DATA_DIR env var. Routing all persistent state through it lets an editing agent run a throwaway instance against a copy of the data with a single env var, never touching the live store. It's a per-service variable (not a shared SERVICE_DATA_DIR) so it can't leak into supervisord's inherited environment and silently repoint every service at once.
• build-web-service documents the DATA_DIR convention where services are created, and why a hardcoded runtime/<name>/ at a call site silently bypasses the override and re-exposes the live data.
• update-service gains a "Protect the user's data while you verify" section, ordered cheapest-first: read-only verification needs no ceremony (reading, including to render a preview, is safe -- only writes are dangerous); if verification must write, run against a copy outside runtime/ via the override and delete the copy; never delete from the live store to clean up (leave a stray test record rather than run a broad delete); snapshot before any genuine in-place change to the real store, strictly as a recovery net and never as a routine wipe-and-restore (overwriting a running store tears its state and loses any real writes that land during the test window); retrofit older hardcoded services when you touch them; and teardown leaves the data dir in place unless the user explicitly asks to remove it.

Scope

Skills plus one scaffold script -- no runtime application code changed. The scaffolder change was verified by generating services and confirming the output lints clean (ruff check / ruff format), imports correctly, and that DATA_DIR redirects to the env-var path while defaulting to runtime/<name>/. The skill validator passes on the new skill, and the code-guardian diff/verify and conversation gates ran clean on the front-door replacement.

Notes

• The front-door replacement improves the odds the right process is invoked, but triggering is still model-judgment; an agent that never considers any skill can still slip through. A deterministic PreToolUse hook (detect an edit to a registered service's lib, inject a reminder) remains available as a backstop if stale-tab / skipped-hardening keeps recurring.
• The data-safety guidance is advisory, not enforced -- nothing mechanically blocks a destructive op against a runtime/* store. A PreToolUse hook that blocks or confirms such ops would make it a hard backstop if the guidance alone proves insufficient. Existing services are retrofitted lazily (when next edited) rather than in a big-bang migration; until then they fall back to read-only verification plus the snapshot net.

[gnguralnick]

if an agent is reading this text it has already loaded the skill - only the description is seen without loading it

[gnguralnick]

we're probably hammering this point too much - don't need it both here and in the description. in general we can probably make this whole skill a bit more concise