keystone_render fails under omp: legacy run registration shape is never dispatched

[rz1989s]

Bug

keystone_render registers via the legacy pi extension shape async run(input) (extensions/render.ts). Current pi SDK and omp (pi-mono fork) both contract on execute(toolCallId, params, signal, onUpdate, ctx) (pi SDK core/extensions/types.d.ts:372). pi runtime tolerates the legacy field; omp dispatch calls definition.execute and crashes:

this.registeredTool.definition.execute is not a function

Repro

• omp 18.1.x, omp plugin install @getpipher/keystone (v1.0.0)
• Ask the model to call keystone_render → TypeError before args validation; skill itself discovers fine

Root cause

Registration written against an outdated pi ExtensionAPI. No omp-side shim translates legacy run for plugin-loaded tools.

Fix

Swap registration to the modern signature (execute receives params as arg 2). Live-verified under omp via omp -e extensions/render.ts: render produced screenshots + computed.json (main: oklch(97.07% 0.0026 286.28) on oklch(15.15% 0.0085 285.33), 1280×229).

Follow-up (upstream, optional)

omp's legacy-pi compat layer could map legacy run → execute for pi-era packages; would help the whole pi ecosystem load under omp.

[rz1989s]

Resolved across three layers, shipped as v1.0.1 (execute signature) + v1.0.2 (TypeBox parameters + AgentToolResult content blocks) via #18/#19/#20.

Full contract keystone now follows (house pattern per @getpipher/term):

pi.registerTool({
  name, description,
  parameters: Type.Object({...}),                          // not a plain property map
  async execute(_toolCallId, params) {                     // not legacy run(input)
    const result = await work(params)
    return { content: [{ type: "text", text: JSON.stringify(result) }], details: result }  // not a raw object
  },
})

Verified end-to-end under omp from the published npm package: render at 1280×800 → screenshots + computed.json OKLCH pairs (main: oklch(97.07% 0.0026 286.28) on oklch(15.15% 0.0085 285.33)).

Note for pi users: v1.0.2 remains fully pi-compatible — the modern contract is what current pi SDK declares (core/extensions/types.d.ts:372).