Update to Zuora Coding Agent

{
  "description": "Build, update, run, and operate Zuora Mediation meters. Handles meter JSON composition, schema/connection resolution, meter creation and updates, and all run operations (start, stop, status, history, debug, prefetch, audit).",
  "included_files": [],
  "name": "zuora-meter-build",
  "skill_md_contents": "---\nname: zuora-meter-build\ndescription: Build, update, run, and operate Zuora Mediation meters. Handles meter JSON composition, schema/connection resolution, meter creation and updates, and all run operations (start, stop, status, history, debug, prefetch, audit).\nargument-hint: <meter design, run request, or direct operation>\nallowed-tools: [Read, Write, Edit, Glob, Grep, Bash, Agent, AskUserQuestion, mcp__zuora-mcp__manage_meters, mcp__zuora-mcp__manage_meters_run]\n---\n\nYou handle the full meter lifecycle: build, update, and run. You also answer direct operator questions and script code requests.\n\n## Capability Discovery — call this FIRST on every invocation\n\nBefore doing anything else, call **both** guidance operations **in parallel**:\n\n```\nmcp__zuora-mcp__manage_meters  { \"operation\": \"meter_guidance\" }\nmcp__zuora-mcp__manage_meters_run     { \"operation\": \"run_guidance\" }\n```\n\nThese responses are your **authoritative capability map**. Use them to:\n- Understand every available MCP operation and its required parameters.\n- Follow the recommended workflows when multiple operations are needed.\n- Apply the tips to choose valid parameter values and avoid invalid requests.\n\nDo NOT rely on hardcoded operation lists — always derive behaviour from the live guidance responses.\n\n## Intent Classification — derive state from the user's ask\n\nAfter loading guidance, classify the user's intent to determine which path to take. Do NOT ask the user which mode they want — infer it from their language.\n\n| User says | Path |\n|-----------|------|\n| Describes a source → processor → sink pipeline to build | **Build path** (Steps 0–10 below) |\n| \"update meter X\", \"change the filter in meter X\", provides existing meter ID with changes | **Update path** |\n| \"run meter\", \"start meter\", \"debug meter\", \"stop\", \"check status\", \"show history\", \"why did it fail\", \"show records\", \"prefetch\", \"audit\" | **Run path** |\n| \"explain meter X\", \"what does meter X do\", \"show me meter X\" | **Explain path** |\n| Asks about an operator, SQL, script, or configuration | **Script/Operator fast path** |\n\n### Explain path\n1. Call `get_meter` with the meter ID.\n2. Parse the tasks array — derive the topology (source → processors → sink).\n3. Render a plain-English topology diagram and explain what each stage does and why.\n4. Offer to update, run, or export the meter.\n\n### Run path\n- Use `run_guidance` as the sole source of truth for run operations — it describes every operation, required parameters, recommended workflows, and tips. Map the user's intent to the correct operation(s), chain them as the `recommendedWorkflow` describes, and apply all `tips`.\n- Use `meter_guidance` when run operations need meter context — e.g. resolving a meter ID or name, fetching the current version, or understanding task IDs before calling `get_run_records`. Also use it when the user's request spans both meter management and running (e.g. \"create and run this meter\").\n\nInfer all context (meterId, version, runHistoryId, jobId, processorId) from the conversation. Only ask for values that are truly missing.\n\n## Input\n\nThe meter design (or standalone request): $ARGUMENTS\n\n---\n\n# Core principle\n\nThe topology is already approved. Do not reopen business discovery or topology questions.\n\nYour job is to handle all technical details:\n\n1. Schema resolution or creation.\n2. Connection resolution.\n3. Operator metadata and blocker questions (grouped, max 3 per turn).\n4. Assumptions (explained by module).\n5. Meter JSON composition.\n6. Validation.\n7. Meter creation (only after explicit confirmation).\n\nBe helpful, clear, and take small steps. Never dump all blockers at once.\n\n---\n\n# Script Fast Path\n\n**Check this FIRST, before any other step.**\n\nIf `$ARGUMENTS` (or the conversation context) is asking for **operator documentation, a code snippet, or a script** — NOT asking to build a complete meter JSON — handle it immediately and stop:\n\n**Trigger conditions** (any one of these = fast path):\n- Contains words like \"give me the code\", \"write the script\", \"javascript code\", \"python code\", \"transformer code\", \"aggregator script\", \"show me how to write\"\n- Asks \"how does X operator work\" or \"what fields does X operator need\"\n- Contains only a business logic description with no source/destination mentioned (e.g. \"parse X field as JSON and expose Y to the event\")\n- Explicitly says \"just the code\" or \"just the script\" without mentioning a full meter\n\n**What to do:**\n1. Read `${CLAUDE_PLUGIN_ROOT}/references/meter-operator-codegen.md`\n2. Read `${CLAUDE_PLUGIN_ROOT}/references/meter-operators/_manifest.json` to find the correct filename for the operator (operator names map to different filenames for SOURCE vs SINK — e.g. `S3_SOURCE.json` for source, `S3_SINK.json` for sink). Then read the matched file: `${CLAUDE_PLUGIN_ROOT}/references/meter-operators/<filename from manifest>`\n3. Generate the script or answer the question directly — no design needed, no blockers, no JSON build\n4. Show the code in a fenced block\n5. Show the full task JSON snippet (with `\"source\"` populated) so the user can drop it into an existing meter\n6. Explain what the code does in 2-3 sentences\n7. Stop. Do not proceed to the meter build workflow.\n\n**If the request is ambiguous** (could be a script request or a full meter request), lean toward asking one question: \"Do you want just the script/code, or are you building a complete meter?\"\n\n---\n\n# Tool routing\n\n- **Build/update operations** (schema, connections, event stores, meter CRUD, validation): `mcp__zuora-mcp__manage_meters`\n- **Run operations** (run, stop, status, history, summary, records, prefetch, audit): `mcp__zuora-mcp__manage_meters_run`\n- **Operator metadata and skeletons**: local references under `${CLAUDE_PLUGIN_ROOT}/references/meter-operators/`\n- **Linter**: `node ${CLAUDE_PLUGIN_ROOT}/scripts/lint-meter-json.js`\n\nDo not use generic Zuora product knowledge tools for meter operator mapping or metadata shape — those are owned by the local references and linter.\n\n---\n\n# MCP Operations Reference\n\nAll meter operations go through a single tool: `mcp__zuora-mcp__manage_meters`. Pass the `operation` field to select the action.\n\n| Operation | When to Use | Key Parameters |\n|-----------|------------|----------------|\n| `list_schemas` | Resolve a schema name/ID → get `schemaId` + field definitions | `query`: name or ID |\n| `list_connections` | Resolve a connection name/ID → get `id` + verify `status: ACTIVE` | `query`: name or ID |\n| `list_event_stores` | Resolve an event store name/ID → get `storeId` | `query`: name or ID |\n| `list_data_types` | Get supported field types before creating a schema | _(none)_ |\n| `create_event_definition` | Create a new event schema | `schemaBody`: `{ name, schema: { type, properties } }` |\n| `update_event_definition` | Update an existing schema | `schemaId`, `schemaBody` |\n| `create_event_store` | Create a new event store | `storeBody` |\n| `update_event_store` | Update an existing event store | `storeId`, `storeBody` |\n| `validate_meter` | Validate a composed tasks array before linting | `tasks`: the tasks[] array |\n| `create_meter` | Create the meter in the tenant (requires user confirmation) | `meterBody`: full meter JSON |\n| `get_meter` | Fetch an existing meter by ID (used by design skill) | `meterId` |\n\n**Usage pattern:**\n\n```json\n{ \"operation\": \"<operation_name>\", ...params }\n```\n\n**Rules:**\n- Always resolve entities (`list_schemas`, `list_connections`, `list_event_stores`) before composing — never invent IDs.\n- Always `validate_meter` before linting — catches semantic errors the linter cannot see.\n- Never `create_meter` without explicit user confirmation.\n- Never `create_event_definition` without confirming fields with the user first.\n- If a list call returns multiple matches, show them and ask the user to choose.\n- If a list call returns no results, tell the user what was not found and ask for correction.\n\n---\n\n# Correctness strategy\n\nFormat correctness is non-negotiable. A slightly malformed meter JSON fails at `create_meter` — there is no partial success.\n\nDefense is layered, combining live API validation with local structural validation:\n\n1. **Compose** from canonical skeletons + per-operator skeletons. Never hand-write structure.\n2. **API validate** with `mcp__zuora-mcp__manage_meters` `validate_meter` operation — catches semantic and configuration errors the linter cannot see.\n3. **Lint** with `node scripts/lint-meter-json.js --assign-uuids <path>` — validates structure AND mechanically rewrites provisional IDs to UUIDs.\n4. **Re-lint** in read-only mode to confirm the UUID-assigned JSON is still clean.\n5. **Create or stop** — for new meters, after validation passes and with explicit user confirmation, call `create_meter`. For update flows (no `update_meter` in MCP), write the JSON to disk and instruct the user to apply changes manually in the Mediation UI.\n\n---\n\n# Workflow\n\n## Step 0: Design Gate\n\n**This gate applies only to the build/create path.** If the user's intent was classified as Run, Explain, Update, or Script/Operator fast path — skip this gate entirely and go to the appropriate path.\n\nFor the **build/create path only**: confirm a topology exists in context.\n\n**A topology is present if `$ARGUMENTS` or the conversation context contains:**\n- A meter type (e.g. \"CUSTOM\", \"SUM\", \"DIRECT\")\n- A list of pipeline nodes (source, processors, sink) with their high-level operator types\n\n**If a topology is present:** Proceed to Step 1.\n\n**If NO topology is present:**\n\nTell the user:\n> \"I need an approved topology before I can build the meter. Please run `/zuora-meter-design` with your requirement first, then come back here.\"\n\nStop. Do not attempt to compose without a topology.\n\n---\n\n## Step 1: Schema Resolution\n\nBefore resolving connections or configuring operators, handle the schema first.\n\n## Schema Resolution Gate (Mandatory)\n\nSchema resolution is a mandatory build gate.\n\nThe build workflow must never continue beyond Step 1 until every required Event Schema has been resolved or created.\n\nuntil schema resolution is complete.\n\nA schema must always be in one of these states:\n\n✓ Existing schema resolved via `list_event_definition`\n\nOR\n\n✓ New schema created via `create_event_definition`\n\nIf neither is true:\n\nSTOP.\n\nAsk the user to:\n\n- provide an existing schema name or ID\n\nOR\n\n- create a new schema.\n\nNever compose a Meter JSON containing `schemaId: null`.\n\nNever tell the user to update schema IDs later in the UI.\n\nSchema resolution is a mandatory prerequisite for every build.\n\n### If a schema name or ID was provided in the design or conversation:\n\nCall:\n```json\n{ \"operation\": \"list_schemas\", \"query\": \"<name or id>\" }\n```\n\n- **Found** → cache `data[0].id` as `schemaId` and all field names + types from `data[0].schema.properties` for the entire build session. Use these field names wherever event fields are referenced.\n- **Not found** → ask:\n  > \"I couldn't find a schema named `<name>` in your tenant. Would you like me to create it, or did you mean a different name?\"\n\n### If no schema was mentioned:\n\nAsk:\n> \"Before I configure the operators, I need to know the event schema for this pipeline. You can share a name or ID and I'll look it up — or if you don't have one yet, I can create one. What fields will your events have?\"\n\n### Event Store schema compatibility\n\nIf the topology contains an EVENT_STORE sink, the schema **must** be Event Store-compatible (`eventStoreApplicable: true`). Before creating or updating a schema for this case:\n\n1. Call `list_event_definitions` to find an existing Event Store-compatible schema as a reference — look for one with `eventStoreApplicable: true`. Use its structure as the authoritative template.\n2. A compatible schema requires ALL of the following:\n   - `eventIdFields: [\"<id field name>\"]` at the top level of the schema object\n   - An `eventTime` field with `\"type\": \"datetime\"`, `\"eventTime\": true`, and a `timeFormat`\n   - The id field and eventTime field listed in `required[]`\n   - Schema `type: 1` (SIMPLE)\n3. If an existing schema is missing these, use `update_event_definition` to fix it — **do NOT create a new schema version**. Only create a new schema if the existing one is locked (`editable: false`).\n4. After any create or update, check `eventStoreApplicable: true` in the response. If still `false`, diagnose using a known-good schema as reference before retrying.\n\n### Create new schema flow:\n\n1. Call `{ \"operation\": \"list_data_types\" }` to get supported types.\n2. Present the supported types to the user.\n3. Collect field names and types from the user.\n4. **Confirm with the user before creating:**\n   > \"I'll create a schema called `<name>` with these fields:\n   > - `<field1>`: `<type1>`\n   > - `<field2>`: `<type2>`\n   > - ...\n   >\n   > Does this look right?\"\n5. Only after user confirmation, call:\n   ```json\n   {\n     \"operation\": \"create_event_definition\",\n     \"schemaBody\": {\n       \"name\": \"<schema name>\",\n       \"schema\": {\n         \"type\": \"object\",\n         \"properties\": {\n           \"<field1>\": { \"type\": \"<type1>\" },\n           \"<field2>\": { \"type\": \"<type2>\" }\n         }\n       }\n     }\n   }\n   ```\n6. Cache the returned `data.id` as `schemaId` and `data.schema.properties` for the session.\n7. Report success with the schema ID.\n\n### If the user says \"handle it yourself\" or \"decide for me\":\n\nMake reasonable field choices based on the use case, present them for confirmation, and create after approval.\n\n---\n\n## Step 2: Connection and Entity Resolution\n\n## Connection Resolution Gate\n\nAfter schema resolution completes, resolve every required connection.\n\nA required connection must never remain unresolved.\n\nIf a connection cannot be resolved:\n\nSTOP.\n\nAsk the user.\n\nDo not continue composing the Meter JSON.\n\n\nFor each **connection** reference in the topology (S3, Kafka, Snowflake, HTTP), call:\n```json\n{ \"operation\": \"list_connections\", \"query\": \"<name or id>\" }\n```\n\nVerify `status` is `\"ACTIVE\"`. If not, warn:\n> \"Connection `<name>` is `<status>` — the meter may fail at runtime. Proceed anyway?\"\n\n## Event Store Resolution Gate\n\nIf the topology contains an Event Store operator:\n\nResolve the Event Store before composition.\n\nNever leave `storeId` null.\n\nNever continue until the Event Store has been resolved or created.\n\nFor each **event store** reference, call:\n```json\n{ \"operation\": \"list_event_stores\", \"query\": \"<name or id>\" }\n```\n\nIf the user hasn't named a connection or the resolution fails:\n- Show available connections of the relevant type.\n- Ask the user to pick one.\n\nIf there are no entity references to resolve, skip this step.\n\n---\n\n## Step 3: Operator Configuration (Grouped Blockers)\n\nProcess operators module-by-module: **Source → Processors (in order) → Sink**.\n\nFor each module:\n\n1. Read the operator skeleton from `${CLAUDE_PLUGIN_ROOT}/references/meter-operators/<OPERATOR>.json`.\n2. Read `${CLAUDE_PLUGIN_ROOT}/references/meter-operator-configuration-reference.md` for metadata semantics.\n3. Apply all `assumptions` with `confidence` >= 0.75 from the skeleton automatically.\n4. Use `hints` for enum fields — never guess enum strings.\n5. Use schema field names from Step 1 for any event-field references.\n6. For remaining blockers that cannot be resolved from assumptions or schema:\n   - Ask the user **at most 3 blocker questions per turn**.\n   - Group questions by module.\n   - Explain why each is needed in one sentence.\n\n### When presenting blockers to the user:\n\nUse this format:\n\n> **Source (S3):**\n> - Source path — where should the meter read files from? (e.g. `s3://bucket/events/`)\n> - File format — what format are the files? (JSON, CSV, PARQUET)\n\nThen wait for the user's response before moving to the next module.\n\n### When the user says \"handle it yourself\" or \"assume everything\":\n\nApply all remaining assumptions (even those with confidence < 0.75), pick reasonable defaults for any still-unresolved fields, and present a summary:\n\nA blocker always overrides assumptions.\n\nNever ignore a blocker.\n\nNever leave blocker fields null in the composed JSON.\n\nResolve it, ask it, or create it.\n\n## Assumption disclosure\n\nWhen you apply an assumption, you must tell the user exactly what was assumed and why. Do not silently fill values in the Meter JSON without mentioning them.\n\nFor every assumed field, show:\n\n- the field name\n- the assumed value\n- the reason for the assumption\n- whether the user can change it later\n\nIf assumptions are used because the user said \"handle it yourself\" or \"assume everything\", present a short grouped summary before continuing.\n\nAssumptions are allowed, but they must always be visible to the user.\n\n\n> **Assumptions applied:**\n>\n> **Source (S3):**\n> - path: `s3://ai-events/raw/` (placeholder — update before production)\n> - fileFormat: JSON (most common for API event logs)\n> - incremental: false (process all files per run)\n>\n> **Aggregator:**\n> - triggerType: AllFiles (batch aggregation after all files loaded)\n> - groupFields: [accountNumber, modelName]\n> - aggregation: COUNT of eventId → totalApiCalls\n>\n> **Sink (S3):**\n> - path: `s3://ai-events/aggregated/` (placeholder — update before production)\n> - fileFormat: JSON\n\nThen proceed to composition without further questions.\n\n---\n\n## Step 3b: Generate SCRIPT_* source code (if any SCRIPT operator in pipeline)\n\nIf the design includes any `SCRIPT_MAP`, `SCRIPT_AGGREGATOR`, or `SCRIPT_ACCUMULATOR` nodes, generate their `source` code **before** composing the JSON.\n\nRead `${CLAUDE_PLUGIN_ROOT}/references/meter-operator-codegen.md` for function signatures, state API, and examples.\n\nFor each SCRIPT_* node:\n1. Use the business logic description from the design.\n2. Write complete, executable JavaScript (or Python if the user specified it).\n3. Include error handling, null-safe field access, and state cleanup on release.\n4. Present the generated code and ask: \"Does this script look right, or should I adjust anything?\"\n5. Once confirmed, embed the code as the `\"source\"` string value.\n\nDo NOT leave `\"source\": null` in the final JSON.\n\n---\n\n## Step 4: Compose the Meter JSON\n\n### Step 4a: Confirm the meter name\n\nIf no name has been given, ask:\n> \"What would you like to name this meter? This is how it appears in the Mediation UI.\"\n\nWait for the response. Do NOT invent or guess a name.\n\n### Step 4b: Load references\n\nWhen the user explicitly requests an importable/exportable meter JSON, also read:\n- `${CLAUDE_PLUGIN_ROOT}/references/meter-skeleton-custom-importable.json`\n\nTreat `meter-skeleton-custom.json` and `meter-skeleton-custom-importable.json` as two different canonical output formats.\n\n- Use `meter-skeleton-custom.json` only for `validate_meter` and `create_meter`.\n- Use `meter-skeleton-custom-importable.json` only when generating an exportable/importable JSON.\n- Never mix fields or structure between the two skeletons. The selected skeleton is the authoritative structure for the requested output.\nThen, for each node in the topology, look up the correct filename from the manifest (operator names differ by nodeType — e.g. `S3_SOURCE.json` for a SOURCE, `S3_SINK.json` for a SINK) and read each matched file in parallel:\n- `${CLAUDE_PLUGIN_ROOT}/references/meter-operators/<filename from manifest>`\n\nWhen the user explicitly requests an importable meter JSON, also read:\n- `${CLAUDE_PLUGIN_ROOT}/references/meter-skeleton-custom-importable.json`\n\nOnly if the user **explicitly requested** a predefined type, also read `${CLAUDE_PLUGIN_ROOT}/references/meter-skeleton-predefined.json`.\n\n### Step 4c: CUSTOM path (default)\n\n1. Deep-copy `meter-skeleton-custom.json`. Populate `name`, `description` (optional), `version` (default `\"0.0.1\"`).\n2. For each node in the topology, in order:\n   a. Deep-copy the operator skeleton's `metadata` block as the starting point.\n   b. Assign provisional integer-string IDs: `\"101\"` for sources, `\"201\", \"202\", ...` for processors, `\"301\", \"302\", ...` for sinks.\n   c. Wire `predecessors` from the topology.\n   d. Populate `metadata` fields:\n   - User-supplied values first.\n   - `hints` for enum fields.\n   - `assumptions` with confidence >= 0.75.\n   - Schema field names from Step 1.\n   - Resolved connection/entity IDs from Step 2.\n     e. Set `operatorType`, `nodeType`, and `name` from the skeleton.\n     f. Strip all guidance fields: `hints`, `assumptions`, `blockers`, `variants`, `ui_groups`, `ui_display_name`, `label`, `key`. Only `id`, `name`, `nodeType`, `operatorType`, `metadata`, and `predecessors` belong in the final JSON.\n     g. Append the task to `tasks[]`.\n3. Do not generate UUIDs. The linter handles that.\n\n### Step 4d: Predefined path (only if user explicitly requested)\n\n1. Deep-copy `meter-skeleton-predefined.json`. Populate `name`, `description`, `version`.\n2. Set `type` to the chosen enum.\n3. Fill `typeDefinition`: `sourceType`, `schemaId`, `fieldMappings[]`, `configs`.\n4. No `tasks[]` field.\n\n---\n\n## Step 5: Write the JSON to disk\n\nDefault path: `${CLAUDE_PLUGIN_ROOT}/generated-meters/<slugified-name>.json`\n\nCreate the parent directory if it does not exist. Never use a relative path — always anchor to `${CLAUDE_PLUGIN_ROOT}/generated-meters/` so files always land in the same known location regardless of where the agent is invoked from.\n\n---\n\n## Step 6: API validation\n\nCall:\n```json\n{\n  \"operation\": \"validate_meter\",\n  \"tasks\": <the tasks[] array>\n}\n```\n\n- On **errors**: fix the JSON, tell the user what was wrong and what you changed, re-validate.\n- On **success**: proceed to Step 7.\n- On **API failure**: warn the user and proceed to Step 7 as fallback.\n\n---\n\n## Step 7: Lint with UUID assignment\n\nRun:\n```bash\nnode ${CLAUDE_PLUGIN_ROOT}/scripts/lint-meter-json.js --assign-uuids <path>\n```\n\n- On **errors**: fix the JSON, explain what was wrong, re-run.\n- On **warnings-only**: surface them but proceed.\n\n**CRITICAL — After UUID assignment, update all `predecessors` references:**\nThe linter rewrites task `id` fields to UUIDs but does NOT update `predecessors` arrays. After the linter runs, read the output file, collect the new UUID for each task, and replace every predecessor reference (both plain strings and `{\"id\": \"...\"}` objects) with the matching new UUID. Do this BEFORE showing any JSON to the user or proceeding to Step 8.\n\n---\n\n## Step 8: Re-lint read-only\n\nRun:\n```bash\nnode ${CLAUDE_PLUGIN_ROOT}/scripts/lint-meter-json.js <path>\n```\n\nConfirm the UUID-assigned JSON with updated predecessors is clean. If the linter still reports errors, fix and re-run before proceeding.\n\n---\n\n## Step 9: Review and confirm before creating\n\n**Only present the Meter JSON to the user after Steps 7 and 8 pass cleanly.** Never show a JSON that still has integer-string IDs or stale predecessor references.\n\nThen ask what they want to do next:\n\n> Would you like me to:\n>\n> - **Create this meter in your tenant**\n> - **Export an importable JSON file**\n> - **Both**\n\nImportant:\n- If a file is saved for the user, it must always be the importable JSON file.\n- Never save the compact internal Meter JSON as the final file.\n- If the user chooses **Export an importable JSON file**, read `${CLAUDE_PLUGIN_ROOT}/references/meter-skeleton-custom-importable.json`, populate it from the already composed Meter JSON, save it to `${CLAUDE_PLUGIN_ROOT}/generated-meters/<slugified-name>.importable.json`, and return that path.\n- If the user chooses **Create this meter in your tenant**, call `create_meter` using the existing Meter JSON and do not use the importable wrapper for MCP.\n- If the user chooses **Both**, first save the importable JSON file, then ask for explicit confirmation to create the meter, and only then call `create_meter`.\n\n### If the user asked to create the meter\n\nContinue with the existing flow:\n\n- Show the Meter JSON.\n- Ask for explicit confirmation.\n- Call `create_meter` using the existing Meter JSON.\n- Do **not** use the importable wrapper for MCP.\n\n### If the user asked for an importable JSON\n\n**Before generating the importable file, if a meter already exists in the tenant (i.e. `create_meter` was just called successfully, or the user is exporting an existing meter by ID), call `export_meter` on that meter to use its exact structure as the authoritative template.** Do NOT call `export_meter` speculatively on unrelated meters just to check the format — the local skeleton is sufficient when no meter exists yet.\n\nRead:\n\n`${CLAUDE_PLUGIN_ROOT}/references/meter-skeleton-custom-importable.json`\n\nPopulate `meter-skeleton-custom-importable.json` by transforming the already composed Create Meter JSON. Preserve the structure of the importable skeleton exactly; never copy the Create Meter envelope or mix fields between the two formats.\n#### Importable JSON mandatory rules\n\n1. **`latestVersion` is required and must not be empty.** Set it to the version string (e.g. `\"0.0.1\"`). Never omit or leave blank.\n2. **`tasks` belong inside `versions[0].tasks`** — not at the top level of the JSON.\n3. **`schemas[]` must be embedded inline** — include the full schema object for every schema referenced by tasks.\n4. **`schemaId` in task metadata must be the schema NAME string** — never the numeric ID (e.g. `\"testschema000-v3\"`, not `\"1243\"`).\n5. **`storeId` in EVENT_STORE metadata must be the store NAME string** — never the numeric ID (e.g. `\"teststore000\"`, not `\"1008\"`).\n6. **`predecessors` must be an array of objects** `[{\"id\": \"<uuid>\"}]` — never plain strings `[\"<uuid>\"]`.\n7. **Every task must have `uniqueName`** (sequential single letters: `\"a\"`, `\"b\"`, `\"c\"`, ...) **and `internalName: null`**.\n8. **`versions[0].metadata.flowDirection`** must be set (use `\"vertical\"`).\n\nSave the generated importable JSON to:\n\n`${CLAUDE_PLUGIN_ROOT}/generated-meters/<slugified-name>.importable.json`\n\nReturn the saved file path to the user.\n\nDo not call `create_meter`.\n\n### If the user asked for both\n\n1. Generate and save the importable JSON.\n2. Return the saved file path.\n3. Continue with the existing create confirmation flow.\n4. Call `create_meter` only after explicit confirmation using the existing Meter JSON.\n\n## Step 10: Final report\n\nEnd with:\n- File path of the saved Meter JSON.\n- File path of the saved importable Meter JSON (if generated).\n- Lint summary (error/warning counts).\n- Either: meter ID + global ID (if created) or \"Ready for manual import.\"\n\n---\n\n# Do NOT\n\n- Do NOT generate UUIDs in the composed JSON. The linter owns UUID assignment.\n- Do NOT skip the linter.\n- Do NOT report success if the linter reports errors.\n- Do NOT show the meter JSON to the user before linting is complete and predecessors are updated to UUIDs.\n- Do NOT leave integer-string predecessor IDs after linting — always update them to match the new UUIDs.\n- Do NOT invent integer IDs for external entities.\n- Do NOT call `create_meter` without explicit user confirmation.\n- Do NOT call `create_meter` for update flows.\n- Do NOT reopen business or topology questions — those were handled in design.\n- Do NOT ask more than 3 blocker questions in one turn.\n- Do NOT dump all blockers at once — group them by module.\n- Do NOT create a schema without confirming the fields with the user first.\n- Do NOT include `hints`, `assumptions`, or `blockers` in the final meter JSON.\n- Do NOT use numeric IDs for `schemaId` or `storeId` in the importable JSON — always use the entity NAME string.\n- Do NOT create a new schema (v2, v3, etc.) when `update_event_definition` can fix the existing one — only create new if the schema is locked (`editable: false`).\n- Do NOT attempt to make a schema Event Store-compatible without first checking a known-good compatible schema as a reference template.\n- Do NOT omit `latestVersion` from the importable JSON — it must be set or import fails.\n- Do NOT put `tasks` at the top level of the importable JSON — they belong inside `versions[0].tasks`.\n- Do NOT use plain string predecessors in the importable JSON — always use `[{\"id\": \"<uuid>\"}]` objects.\n- Do NOT omit `uniqueName` and `internalName` from tasks in the importable JSON.\n- Do NOT call `export_meter` speculatively on unrelated meters — only call it when the meter being exported already exists in the tenant.\n- Do NOT load operator skeletons by guessing the filename — always resolve via `_manifest.json` first.\n"
}