@withpica/mcp-server 2.95.2 → 2.95.4

package/dist/skills/skills.generated.js

@@ -27,7 +27,7 @@ export const SKILLS = {
         output: "A modelling decision (work vs recording vs release) with the exact tool calls to create or restructure the entities, and — when consolidating — a safe repoint-then-relink-then-delete plan that never orphans a release track.",
         definition_of_done: "Each composition is ONE work with ONE ISWC; every variant is a recording under that work with the correct version_type; remixes are separate works; no blank-ISWC duplicate works sharing a title stem; release tracks resolve to the right work and recording.",
         when_not_to_use: "When the thing genuinely IS a separate composition — a remix or flip with new authorship, or a distinct song that merely shares a title stem. Those are their own works, not recordings under an existing one.",
-        body: "# catalog-modelling\n\nUse this before creating or restructuring catalog entities. It answers the\nquestion agents get wrong most often: \"this instrumental / acoustic / live /\nremix version — is it a new work, a recording, or a release?\" Getting it wrong\nsplinters one song into many half-blank works and breaks every downstream\nreport. Getting it right is mechanical once you know the three grains.\n\n## The three grains\n\nPICA separates a song into three distinct entities, each with its own identity\n(per `docs/data-model/CANONICAL_SCHEMA.md` and ADR-252):\n\n- **work** = the composition, the song as written. carries the **ISWC** (`works.iswc`)\n  and the composition credits. one work has many recordings.\n- **recording** = a specific master / sound recording of that work. carries the\n  **ISRC** (`recordings.isrc`), the audio, and a `version_type`. it points at its\n  work via `recordings.work_id`. a recording has no ISWC of its own — its\n  composition identity is the work it hangs off. one recording appears on many\n  releases.\n- **release** = a commercial product (single, album, compilation) that bundles\n  recordings via `release_tracks`. carries the **UPC** and catalog number.\n\nThe rule the whole model rests on: **a fact lives on exactly one entity, at the\nright grain.** ISWC is a composition fact (work). ISRC is a master fact\n(recording). UPC is a product fact (release). Never put a master or release fact\non a work.\n\n## The decision rule\n\nWhen something new shows up that looks like `<existing work> - <variant>`\n(e.g. \"confetti heart - instrumental\", \"midnight - acoustic\", \"the song - live\nat koko\"):\n\n> it is a **recording under that existing work**, created or repointed with the\n> right `version_type` — **UNLESS** it is a remix or a flip with new authorship,\n> in which case it is a **separate work**.\n\nSo:\n\n- **same composition, different rendering** (instrumental, acoustic, live_performance, demo,\n  edit, backing_track, edit, alternate) → one more **recording** under\n  the existing work. set `work_id` to the existing work and `version_type` to the\n  variant. do NOT mint a second work.\n- **new composition built on the old one** (a remix, a flip, a sample-based\n  derivative, a re-write) → a **separate work** with its **own ISWC**, created via\n  `pica_works_create`. it is its own composition because someone added new\n  authorship.\n\n### the version_type values\n\n`version_type` is the canonical way to label a variant recording. the live\n`recordings_version_type_check` constraint (and `VALID_VERSION_TYPES` in\n`lib/services/recordings.ts`) accepts exactly these thirteen values:\n\n`demo`, `master`, `alternate_master`, `music_video`, `lyric_video`,\n`live_performance`, `acoustic`, `remix`, `cover`, `alternate`, `instrumental`,\n`backing_track`, `edit`.\n\na fresh master defaults to `master`. pick the most precise value — prefer\n`instrumental` / `backing_track` / `edit` over the lossy `alternate` catch-all.\nnote `remix` and `cover` exist as recording version_types too, but a remix that\nadds new authorship is better modelled as a separate work (see below); the\n`remix` recording value is for the case where you are cataloguing the remix as a\nmaster without a distinct composition entry.\n\n## how a remix / derivative links to its parent\n\nBe honest about what the agent-facing tools can do here. PICA's internal schema\ndoes have a `work_versions` table that records parent→child derivative\nrelationships (`parent_work_id` → `child_work_id`, with a `version_type` that\nincludes `remix`, `cover`, `sample`), managed by\n`lib/services/work-versions.ts`. **But there is no MCP tool today that writes a\n`work_versions` link, and the `works` table itself has no parent/derivative FK\ncolumn.** So through the MCP surface:\n\n> a remix or derivative is a **separate work with its own ISWC**, created via\n> `pica_works_create`. there is no MCP step to formally link it back to the\n> original — do not invent one. model it as its own composition and move on.\n\nDo not tell the user you have \"linked the remix to the original\" — you cannot,\nvia these tools. Create the separate work; that is the correct and complete\naction.\n\n## composition splits vs master splits\n\nWhen you model a variant, the splits follow the grain (per\n`.claude/rules/business-logic.md`, Credit & Split Tables):\n\n- **composition splits / writer credits** live on the **work**, in\n  `work_collaborators` (writer, composer, lyricist, arranger, publisher, with\n  `split_percentage`). every recording under that work inherits the same\n  composition — you do not re-enter writer splits per variant.\n- **master ownership splits** live on the **recording**, in `recording_splits`\n  (`split_type`: master, mechanical, performance, sync); master attribution\n  (producer, performer, etc.) lives in `recording_credits`. these are\n  per-recording — an instrumental master can have different master ownership\n  from the vocal master.\n\nSo an acoustic recording added under an existing work inherits that work's\nwriter splits automatically and only needs its own master splits if the\nownership differs.\n\n## worked example — confetti heart\n\nTake a song \"confetti heart\" with an instrumental, an acoustic, and a remix.\n\n- **confetti heart** → ONE **work** with its ISWC. its writer splits live here in\n  `work_collaborators`.\n- **confetti heart (the released master)** → a **recording** under that work,\n  `version_type: master`, with its ISRC.\n- **confetti heart (instrumental)** → another **recording** under the SAME work,\n  `version_type: instrumental`. same ISWC (inherited via the work), its own ISRC.\n  do not create a second \"confetti heart instrumental\" work.\n- **confetti heart (acoustic)** → another **recording** under the same work,\n  `version_type: acoustic`.\n- **confetti heart (PRY remix)** → a **separate work** with its **own ISWC**\n  (PRY added new authorship). created via `pica_works_create`. it then gets its\n  own recording with `version_type: master` (or `remix`) and its own ISRC. no MCP\n  link back to the original — it stands as its own composition.\n\nThe wrong model — four separate works all titled some variant of \"confetti\nheart\", three of them with blank ISWCs — is exactly what\n`pica_catalog_health` flags as duplicate works sharing a title stem.\n\n## safe consolidation procedure\n\nWhen a catalog already has the wrong shape — e.g. \"confetti heart\",\n\"confetti heart instrumental\", \"confetti heart acoustic\" as three separate works,\ntwo with blank ISWCs — consolidate them under the one real work. Do it in this\norder, and not any other, because deleting a work too early orphans or destroys\nthe release tracks that reference it.\n\n1. **Pick the canonical work** — the one with the real ISWC. this is the keeper.\n2. **Repoint each variant's recording onto the keeper.** for every recording\n   hanging off a duplicate work, call `pica_recordings_update` with\n   `work_id: <keeper work id>` and the correct `version_type` (e.g.\n   `instrumental`, `acoustic`). the recording now belongs to the canonical work\n   and keeps its ISRC and master splits.\n3. **Relink any affected release tracks to the keeper.** a `release_tracks` row\n   references **both** `work_id` and `recording_id` (the table has\n   `CHECK (recording_id IS NOT NULL OR work_id IS NOT NULL)`). any track that\n   still points at a soon-to-be-deleted work via `work_id` must be repointed to\n   the keeper work first.\n4. **Only now delete the now-empty duplicate work** with `pica_works_delete`.\n\n**Why relink the release tracks before the delete, not after.** Per the deletion\ncontract (`.claude/rules/business-logic.md`), deleting a work auto-detaches its\n`release_tracks` membership by nulling `release_tracks.work_id`. for a track that\nalso carries a recording, nulling the work id is harmless — it keeps its\nrecording. but a **work-only** track (no recording) cannot have its `work_id`\nnulled without violating the CHECK, so the deletion policy **deletes that whole\ntrack** instead (its `deleteWhenOrphanColumns` is `[\"recording_id\"]`). that would\nsilently drop the track from its release. and if the duplicate work still has\nrecordings attached, the delete **archives** the work rather than removing it —\nso you must repoint the recordings (step 2) to actually empty it. relinking the\ntracks first means every track keeps a valid work reference and the final delete\nis a clean no-dependents removal.\n\n## what not to do\n\n- don't mint a new work for an instrumental, acoustic, live_performance, demo, edit, or\n  backing_track version. that is a recording under the existing work.\n- don't put an ISWC on a recording or a UPC on a work. facts live at their grain.\n- don't claim you \"linked\" a remix to its original — there is no MCP tool for\n  that link. create the separate work and say so plainly.\n- don't delete a duplicate work before repointing its recordings and relinking\n  its release tracks. order matters; a premature delete orphans or destroys\n  tracks.\n- don't re-enter writer splits per variant. composition splits live once, on the\n  work; recordings inherit the composition.\n\n## follow-on skills\n\n- `set-recording-splits` — once variants are correctly modelled as recordings,\n  set the per-recording master ownership.\n- `catalog-audit` — to sweep the whole catalog for remaining duplicate-title\n  works and blank ISWCs.\n- `register-my-works` — registered works pair with cleanly-modelled recordings.\n",
+        body: "# catalog-modelling\n\nUse this before creating or restructuring catalog entities. It answers the\nquestion agents get wrong most often: \"this instrumental / acoustic / live /\nremix version — is it a new work, a recording, or a release?\" Getting it wrong\nsplinters one song into many half-blank works and breaks every downstream\nreport. Getting it right is mechanical once you know the three grains.\n\n## The three grains\n\nPICA separates a song into three distinct entities, each with its own identity\neach answering a different question:\n\n- **work** = the composition, the song as written. carries the **ISWC** (`works.iswc`)\n  and the composition credits. one work has many recordings.\n- **recording** = a specific master / sound recording of that work. carries the\n  **ISRC** (`recordings.isrc`), the audio, and a `version_type`. it points at its\n  work via `recordings.work_id`. a recording has no ISWC of its own — its\n  composition identity is the work it hangs off. one recording appears on many\n  releases.\n- **release** = a commercial product (single, album, compilation) that bundles\n  recordings via `release_tracks`. carries the **UPC** and catalog number.\n\nThe rule the whole model rests on: **a fact lives on exactly one entity, at the\nright grain.** ISWC is a composition fact (work). ISRC is a master fact\n(recording). UPC is a product fact (release). Never put a master or release fact\non a work.\n\n## The decision rule\n\nWhen something new shows up that looks like `<existing work> - <variant>`\n(e.g. \"confetti heart - instrumental\", \"midnight - acoustic\", \"the song - live\nat koko\"):\n\n> it is a **recording under that existing work**, created or repointed with the\n> right `version_type` — **UNLESS** it is a remix or a flip with new authorship,\n> in which case it is a **separate work**.\n\nSo:\n\n- **same composition, different rendering** (instrumental, acoustic, live_performance, demo,\n  edit, backing_track, edit, alternate) → one more **recording** under\n  the existing work. set `work_id` to the existing work and `version_type` to the\n  variant. do NOT mint a second work.\n- **new composition built on the old one** (a remix, a flip, a sample-based\n  derivative, a re-write) → a **separate work** with its **own ISWC**, created via\n  `pica_works_create`. it is its own composition because someone added new\n  authorship.\n\n### the version_type values\n\n`version_type` is the canonical way to label a variant recording. the live\n`recordings_version_type_check` constraint (and `VALID_VERSION_TYPES` in\n`lib/services/recordings.ts`) accepts exactly these thirteen values:\n\n`demo`, `master`, `alternate_master`, `music_video`, `lyric_video`,\n`live_performance`, `acoustic`, `remix`, `cover`, `alternate`, `instrumental`,\n`backing_track`, `edit`.\n\na fresh master defaults to `master`. pick the most precise value — prefer\n`instrumental` / `backing_track` / `edit` over the lossy `alternate` catch-all.\nnote `remix` and `cover` exist as recording version_types too, but a remix that\nadds new authorship is better modelled as a separate work (see below); the\n`remix` recording value is for the case where you are cataloguing the remix as a\nmaster without a distinct composition entry.\n\n## how a remix / derivative links to its parent\n\nBe honest about what the agent-facing tools can do here. PICA's internal schema\ndoes have a `work_versions` table that records parent→child derivative\nrelationships (`parent_work_id` → `child_work_id`, with a `version_type` that\nincludes `remix`, `cover`, `sample`), managed by\n`lib/services/work-versions.ts`. **But there is no MCP tool today that writes a\n`work_versions` link, and the `works` table itself has no parent/derivative FK\ncolumn.** So through the MCP surface:\n\n> a remix or derivative is a **separate work with its own ISWC**, created via\n> `pica_works_create`. there is no MCP step to formally link it back to the\n> original — do not invent one. model it as its own composition and move on.\n\nDo not tell the user you have \"linked the remix to the original\" — you cannot,\nvia these tools. Create the separate work; that is the correct and complete\naction.\n\n## composition splits vs master splits\n\nWhen you model a variant, the splits follow the grain (per\n`.claude/rules/business-logic.md`, Credit & Split Tables):\n\n- **composition splits / writer credits** live on the **work**, in\n  `work_collaborators` (writer, composer, lyricist, arranger, publisher, with\n  `split_percentage`). every recording under that work inherits the same\n  composition — you do not re-enter writer splits per variant.\n- **master ownership splits** live on the **recording**, in `recording_splits`\n  (`split_type`: master, mechanical, performance, sync); master attribution\n  (producer, performer, etc.) lives in `recording_credits`. these are\n  per-recording — an instrumental master can have different master ownership\n  from the vocal master.\n\nSo an acoustic recording added under an existing work inherits that work's\nwriter splits automatically and only needs its own master splits if the\nownership differs.\n\n## worked example — confetti heart\n\nTake a song \"confetti heart\" with an instrumental, an acoustic, and a remix.\n\n- **confetti heart** → ONE **work** with its ISWC. its writer splits live here in\n  `work_collaborators`.\n- **confetti heart (the released master)** → a **recording** under that work,\n  `version_type: master`, with its ISRC.\n- **confetti heart (instrumental)** → another **recording** under the SAME work,\n  `version_type: instrumental`. same ISWC (inherited via the work), its own ISRC.\n  do not create a second \"confetti heart instrumental\" work.\n- **confetti heart (acoustic)** → another **recording** under the same work,\n  `version_type: acoustic`.\n- **confetti heart (PRY remix)** → a **separate work** with its **own ISWC**\n  (PRY added new authorship). created via `pica_works_create`. it then gets its\n  own recording with `version_type: master` (or `remix`) and its own ISRC. no MCP\n  link back to the original — it stands as its own composition.\n\nThe wrong model — four separate works all titled some variant of \"confetti\nheart\", three of them with blank ISWCs — is exactly what\n`pica_catalog_health` flags as duplicate works sharing a title stem.\n\n## safe consolidation procedure\n\nWhen a catalog already has the wrong shape — e.g. \"confetti heart\",\n\"confetti heart instrumental\", \"confetti heart acoustic\" as three separate works,\ntwo with blank ISWCs — consolidate them under the one real work. Do it in this\norder, and not any other, because deleting a work too early orphans or destroys\nthe release tracks that reference it.\n\n1. **Pick the canonical work** — the one with the real ISWC. this is the keeper.\n2. **Repoint each variant's recording onto the keeper.** for every recording\n   hanging off a duplicate work, call `pica_recordings_update` with\n   `work_id: <keeper work id>` and the correct `version_type` (e.g.\n   `instrumental`, `acoustic`). the recording now belongs to the canonical work\n   and keeps its ISRC and master splits.\n3. **Relink any affected release tracks to the keeper.** a `release_tracks` row\n   references **both** `work_id` and `recording_id` (the table has\n   `CHECK (recording_id IS NOT NULL OR work_id IS NOT NULL)`). any track that\n   still points at a soon-to-be-deleted work via `work_id` must be repointed to\n   the keeper work first.\n4. **Only now delete the now-empty duplicate work** with `pica_works_delete`.\n\n**Why relink the release tracks before the delete, not after.** Per the deletion\ncontract (`.claude/rules/business-logic.md`), deleting a work auto-detaches its\n`release_tracks` membership by nulling `release_tracks.work_id`. for a track that\nalso carries a recording, nulling the work id is harmless — it keeps its\nrecording. but a **work-only** track (no recording) cannot have its `work_id`\nnulled without violating the CHECK, so the deletion policy **deletes that whole\ntrack** instead (its `deleteWhenOrphanColumns` is `[\"recording_id\"]`). that would\nsilently drop the track from its release. and if the duplicate work still has\nrecordings attached, the delete **archives** the work rather than removing it —\nso you must repoint the recordings (step 2) to actually empty it. relinking the\ntracks first means every track keeps a valid work reference and the final delete\nis a clean no-dependents removal.\n\n## what not to do\n\n- don't mint a new work for an instrumental, acoustic, live_performance, demo, edit, or\n  backing_track version. that is a recording under the existing work.\n- don't put an ISWC on a recording or a UPC on a work. facts live at their grain.\n- don't claim you \"linked\" a remix to its original — there is no MCP tool for\n  that link. create the separate work and say so plainly.\n- don't delete a duplicate work before repointing its recordings and relinking\n  its release tracks. order matters; a premature delete orphans or destroys\n  tracks.\n- don't re-enter writer splits per variant. composition splits live once, on the\n  work; recordings inherit the composition.\n\n## follow-on skills\n\n- `set-recording-splits` — once variants are correctly modelled as recordings,\n  set the per-recording master ownership.\n- `catalog-audit` — to sweep the whole catalog for remaining duplicate-title\n  works and blank ISWCs.\n- `register-my-works` — registered works pair with cleanly-modelled recordings.\n",
     },
     "clean-up-artists": {
         name: "clean-up-artists",
@@ -54,7 +54,7 @@ export const SKILLS = {
         audience: "power user with multiple MCPs connected / agency / multi-artist manager",
         tools_required: ["pica_works_inspect", "pica_works_query", "pica_people_query", "pica_enrichment_propose", "pica_enrichment_proposals_list"],
         output: "pica_enrichment_proposals rows created with sources[].url citations from peer MCPs, ready for the user to review and apply via the existing enrichment-proposals workflow.",
-        body: "# enrich-from-peer-mcps\n\nFill PICA catalog gaps by composing across the user's other connected MCPs. This is the cross-MCP integration story for PICA — the user has Gmail or Drive or Notion connected in their AI client, the agent queries those tools when PICA shows missing data, and the resulting information lands in PICA as cited enrichment proposals.\n\n**Important framing:** PICA does NOT manage these connections. The user wires Gmail (etc.) into their AI client separately. PICA's role is to (1) signal what's missing, (2) accept enrichment proposals with `sources[].url` citations using the peer-MCP URI schemes, and (3) let the user review proposals before applying.\n\n## Pre-flight\n\nRead `pica://schemas/enrichment-resolve-required` for the canonical proposal shape, including the URI scheme convention for source citations. The scheme list (per ADR-193):\n\n| Scheme | What it cites |\n|---|---|\n| `gmail://` | An email or thread in the user's Gmail |\n| `gdrive://` | A document or file in the user's Google Drive |\n| `notion://` | A page in the user's Notion workspace |\n| `file://` | A local file on the user's machine |\n| `telegram://` | A message or thread in the user's Telegram |\n| `calendar://` | An event in the user's calendar |\n| `daw://` | A DAW session file (Ableton, Logic, Pro Tools, etc.) |\n| `user://` | The user told you directly (no external source) |\n| `web://` | A public web page |\n\nEach citation is opaque to PICA — PICA doesn't fetch the URI. It just records it as provenance so the user knows where the enrichment came from.\n\n## Step 1 — Identify the gap\n\nTwo entry paths:\n\n- **User-named work** — they said \"fill the gaps on track X from my email.\" Use `pica_works_inspect` with `sections: [\"completeness\", \"enrichment\"]` to see what's missing.\n- **Gap class across catalog** — they said \"what's missing across my catalog?\" Use `pica_works_query` with `health_filter: \"low_completeness\"` to find candidates, then `pica_works_inspect` per work.\n\nDon't try to query peer MCPs proactively for every gap. Start narrow — one work, or one gap class (e.g. \"all works missing ISWC\").\n\n## Step 2 — Map the gap to a peer MCP\n\nFor each gap, suggest the peer MCP that's likely to have the answer:\n\n| Gap | Likely peer MCP | What to look for |\n|---|---|---|\n| Missing splits | Gmail / Drive | Split sheets, email threads agreeing on percentages |\n| Missing ISWC | Gmail / Drive | PRO registration confirmation emails, MLC submissions |\n| Missing co-writer | Calendar / Gmail / DAW | Session calendar invites, email chains with collaborators, DAW project metadata |\n| Missing recording details | Gmail / DAW | Mixer/engineer emails, DAW session names |\n| Missing release date | Gmail / Drive | Distributor confirmations, release plan docs |\n| Missing publisher contact | Notion / Drive | Contact rolodex, publishing agreement PDFs |\n| Missing person email (`needs_email` people) | Gmail | Two-way correspondence where the address belongs to the person — see the email-backfill rules below |\n\nThis is a routing guide, not a prescription. The user knows their workflow — defer to them about which MCP to check.\n\n### Person email backfill (a common, footgun-prone case)\n\nFilling missing emails for `needs_email` people is the same propose-only flow — `email` is a first-class enrichable field, so a Gmail-sourced address lands via `pica_enrichment_propose` (entity_type `person`) with a `gmail://` source citation, then the user reviews. Two extra rules, because a wrong email on a rights-holder is worse than a blank one:\n\n- **Score the address, don't take the first hit.** Strongest: the address literally contains the person's name AND they are a direct sender/recipient in two-way correspondence. Weaker: name-inferred address, or a role address (`info@`/`team@`). Reject: the name only appears in the body, the sender is a third party (management, box office, a newsletter), or it's a recurring unrelated distribution thread (a reliable \"no real hit\" tell).\n- **Check for a collision first.** Before proposing, call `pica_people_query` for the candidate address — if it already sits on another person, do NOT assign it; flag the conflict for the user. (This dedup-collision check is the one thing the agent can't eyeball from Gmail alone.)\n\nNever auto-write — propose, the user confirms.\n\n## Step 3 — Ask the agent to check the relevant peer MCP\n\nThe agent connected to PICA is the same agent connected to (e.g.) Gmail. Ask the agent to run a targeted query in the peer MCP:\n\n- \"Search the user's Gmail for emails about [song title] from [approximate date range]\"\n- \"Look in the user's Drive for documents with [song title] or [collaborator name]\"\n- \"Check the user's calendar for sessions on [date range] tagged [project name]\"\n\nThe peer-MCP query is the agent's job, not PICA's. PICA waits for the agent to return with what it found.\n\n## Step 4 — Cite the source via pica_enrichment_propose\n\nOnce the agent has the missing data, call `pica_enrichment_propose` with:\n\n- The entity ID being enriched (work_id, recording_id, person_id)\n- The proposed value(s)\n- A `sources` array, each entry with a `url` field using the appropriate URI scheme\n\nExample shape:\n\n```json\n{\n  \"entity_type\": \"work\",\n  \"entity_id\": \"uuid\",\n  \"proposed\": { \"iswc\": \"T-123.456.789-0\" },\n  \"sources\": [\n    { \"url\": \"gmail://thread/abc123\", \"context\": \"PRS registration confirmation email, March 2025\" }\n  ]\n}\n```\n\nThe URI is opaque to PICA. The `context` field gives the user a human-readable hint about what the source is.\n\n## Step 5 — Review proposals\n\nCall `pica_enrichment_proposals_list` to show the user what's been queued. They review, apply (or reject), per the existing enrichment-proposals workflow. **Do not auto-apply** — enrichment from external sources always needs explicit user review.\n\n## Step 6 — Loop or close\n\nAsk the user:\n- \"Apply the proposal?\" — they confirm; the enrichment lands\n- \"Move on to the next gap?\" — continue\n- \"Done for now?\" — stop, summarise what was proposed\n\n## What not to do\n\n- Don't try to connect peer MCPs to PICA. PICA doesn't have that surface any more. The connection lives in the user's AI client.\n- Don't fabricate URIs. If the agent didn't actually find the source, don't pretend it did — record the enrichment with `user://` (told to me directly) instead.\n- Don't auto-apply proposals. Even when the source seems definitive, the user reviews.\n- Don't query peer MCPs proactively for unrelated gaps. The user named one gap; the skill works one gap at a time.\n- Don't try to enrich from `lib/services/*` paths or internal cascade endpoints. Those aren't peer MCPs and aren't in scope.\n\n## Follow-on skills\n\n- `close-the-loop` — once gaps are enriched, walk through the remaining (non-peer-MCP) gaps on the same work\n- `audit-credits` — periodic catalog-wide credit sweep\n- `register-my-works` — once IPI / ISWC are filled, registration is unblocked\n",
+        body: "# enrich-from-peer-mcps\n\nFill PICA catalog gaps by composing across the user's other connected MCPs. This is the cross-MCP integration story for PICA — the user has Gmail or Drive or Notion connected in their AI client, the agent queries those tools when PICA shows missing data, and the resulting information lands in PICA as cited enrichment proposals.\n\n**Important framing:** PICA does NOT manage these connections. The user wires Gmail (etc.) into their AI client separately. PICA's role is to (1) signal what's missing, (2) accept enrichment proposals with `sources[].url` citations using the peer-MCP URI schemes, and (3) let the user review proposals before applying.\n\n## Pre-flight\n\nRead `pica://schemas/enrichment-resolve-required` for the canonical proposal shape, including the URI scheme convention for source citations. The scheme list:\n\n| Scheme | What it cites |\n|---|---|\n| `gmail://` | An email or thread in the user's Gmail |\n| `gdrive://` | A document or file in the user's Google Drive |\n| `notion://` | A page in the user's Notion workspace |\n| `file://` | A local file on the user's machine |\n| `telegram://` | A message or thread in the user's Telegram |\n| `calendar://` | An event in the user's calendar |\n| `daw://` | A DAW session file (Ableton, Logic, Pro Tools, etc.) |\n| `user://` | The user told you directly (no external source) |\n| `web://` | A public web page |\n\nEach citation is opaque to PICA — PICA doesn't fetch the URI. It just records it as provenance so the user knows where the enrichment came from.\n\n## Step 1 — Identify the gap\n\nTwo entry paths:\n\n- **User-named work** — they said \"fill the gaps on track X from my email.\" Use `pica_works_inspect` with `sections: [\"completeness\", \"enrichment\"]` to see what's missing.\n- **Gap class across catalog** — they said \"what's missing across my catalog?\" Use `pica_works_query` with `health_filter: \"low_completeness\"` to find candidates, then `pica_works_inspect` per work.\n\nDon't try to query peer MCPs proactively for every gap. Start narrow — one work, or one gap class (e.g. \"all works missing ISWC\").\n\n## Step 2 — Map the gap to a peer MCP\n\nFor each gap, suggest the peer MCP that's likely to have the answer:\n\n| Gap | Likely peer MCP | What to look for |\n|---|---|---|\n| Missing splits | Gmail / Drive | Split sheets, email threads agreeing on percentages |\n| Missing ISWC | Gmail / Drive | PRO registration confirmation emails, MLC submissions |\n| Missing co-writer | Calendar / Gmail / DAW | Session calendar invites, email chains with collaborators, DAW project metadata |\n| Missing recording details | Gmail / DAW | Mixer/engineer emails, DAW session names |\n| Missing release date | Gmail / Drive | Distributor confirmations, release plan docs |\n| Missing publisher contact | Notion / Drive | Contact rolodex, publishing agreement PDFs |\n| Missing person email (`needs_email` people) | Gmail | Two-way correspondence where the address belongs to the person — see the email-backfill rules below |\n\nThis is a routing guide, not a prescription. The user knows their workflow — defer to them about which MCP to check.\n\n### Person email backfill (a common, footgun-prone case)\n\nFilling missing emails for `needs_email` people is the same propose-only flow — `email` is a first-class enrichable field, so a Gmail-sourced address lands via `pica_enrichment_propose` (entity_type `person`) with a `gmail://` source citation, then the user reviews. Two extra rules, because a wrong email on a rights-holder is worse than a blank one:\n\n- **Score the address, don't take the first hit.** Strongest: the address literally contains the person's name AND they are a direct sender/recipient in two-way correspondence. Weaker: name-inferred address, or a role address (`info@`/`team@`). Reject: the name only appears in the body, the sender is a third party (management, box office, a newsletter), or it's a recurring unrelated distribution thread (a reliable \"no real hit\" tell).\n- **Check for a collision first.** Before proposing, call `pica_people_query` for the candidate address — if it already sits on another person, do NOT assign it; flag the conflict for the user. (This dedup-collision check is the one thing the agent can't eyeball from Gmail alone.)\n\nNever auto-write — propose, the user confirms.\n\n## Step 3 — Ask the agent to check the relevant peer MCP\n\nThe agent connected to PICA is the same agent connected to (e.g.) Gmail. Ask the agent to run a targeted query in the peer MCP:\n\n- \"Search the user's Gmail for emails about [song title] from [approximate date range]\"\n- \"Look in the user's Drive for documents with [song title] or [collaborator name]\"\n- \"Check the user's calendar for sessions on [date range] tagged [project name]\"\n\nThe peer-MCP query is the agent's job, not PICA's. PICA waits for the agent to return with what it found.\n\n## Step 4 — Cite the source via pica_enrichment_propose\n\nOnce the agent has the missing data, call `pica_enrichment_propose` with:\n\n- The entity ID being enriched (work_id, recording_id, person_id)\n- The proposed value(s)\n- A `sources` array, each entry with a `url` field using the appropriate URI scheme\n\nExample shape:\n\n```json\n{\n  \"entity_type\": \"work\",\n  \"entity_id\": \"uuid\",\n  \"proposed\": { \"iswc\": \"T-123.456.789-0\" },\n  \"sources\": [\n    { \"url\": \"gmail://thread/abc123\", \"context\": \"PRS registration confirmation email, March 2025\" }\n  ]\n}\n```\n\nThe URI is opaque to PICA. The `context` field gives the user a human-readable hint about what the source is.\n\n## Step 5 — Review proposals\n\nCall `pica_enrichment_proposals_list` to show the user what's been queued. They review, apply (or reject), per the existing enrichment-proposals workflow. **Do not auto-apply** — enrichment from external sources always needs explicit user review.\n\n## Step 6 — Loop or close\n\nAsk the user:\n- \"Apply the proposal?\" — they confirm; the enrichment lands\n- \"Move on to the next gap?\" — continue\n- \"Done for now?\" — stop, summarise what was proposed\n\n## What not to do\n\n- Don't try to connect peer MCPs to PICA. PICA doesn't have that surface any more. The connection lives in the user's AI client.\n- Don't fabricate URIs. If the agent didn't actually find the source, don't pretend it did — record the enrichment with `user://` (told to me directly) instead.\n- Don't auto-apply proposals. Even when the source seems definitive, the user reviews.\n- Don't query peer MCPs proactively for unrelated gaps. The user named one gap; the skill works one gap at a time.\n- Don't try to enrich from `lib/services/*` paths or internal cascade endpoints. Those aren't peer MCPs and aren't in scope.\n\n## Follow-on skills\n\n- `close-the-loop` — once gaps are enriched, walk through the remaining (non-peer-MCP) gaps on the same work\n- `audit-credits` — periodic catalog-wide credit sweep\n- `register-my-works` — once IPI / ISWC are filled, registration is unblocked\n",
     },
     "first-session": {
         name: "first-session",
@@ -70,19 +70,19 @@ export const SKILLS = {
         description: "Get music into PICA — an empty catalog's first win, or a growing one's next batch. Routes to the fastest lane for what the user has — a pasted Spotify/Deezer or YouTube link, a bulk CSV/spreadsheet, or an uploaded royalty statement — leading with the streaming link as the fastest path to a populated catalog.",
         triggers: ["import my catalog", "I just connected — help me get started", "paste a spotify link", "import my music", "I have a csv of my songs", "upload my royalty statement", "get my music into pica", "bring in my back catalog"],
         audience: "new user with an empty catalog, or any user adding a batch of music",
-        tools_required: ["pica_import_streaming_link", "pica_import_youtube_link", "pica_import_fields", "pica_import_template", "pica_import_analyze", "pica_import_validate", "pica_import_execute", "pica_statements_pending", "pica_documents_read", "pica_statement_ingest_document"],
+        tools_required: ["pica_import_streaming_link", "pica_import_youtube_link", "pica_import_fields", "pica_import_template", "pica_import_analyze", "pica_import_validate", "pica_import_execute", "pica_statements_pending", "pica_documents_inspect", "pica_statement_ingest_document"],
         output: "Music landed in the catalog via whichever lane matched what the user has — a preview shown before every confirming write — plus a one-line summary of what was created and the natural next step (songwriting credits, completeness check).",
-        body: "# import-my-catalog\n\nThe single highest-value first-five-minutes job on PICA: get the user's music in. Run this whenever the catalog is empty, or whenever the user names something they want to bring in (a link, a spreadsheet, a statement). Don't make them guess how — ask what they've got, then use the fastest matching lane.\n\nIf you don't know what they have, ask once, plainly: *\"what have you got — a Spotify or YouTube link, a spreadsheet of your catalog, or a royalty statement to read in?\"*\n\n## Lane 1 — Streaming link (fastest first win)\n\nLead with this when the user has any Spotify or Deezer URL (track, album, or playlist) — it's the shortest path to a populated catalog, usually 2 calls.\n\nCall `pica_import_streaming_link` with `url` and no `confirm` — this **previews** the tracks (title, artists, ISRC, duplicates already in the catalog) without writing anything. Show the user what was found, then call again with `confirm: true` to execute. Use `selected_track_ids` if the user wants a subset.\n\nEach imported track creates a work, a recording, people, and performer credits automatically — artwork and enrichment cascade in the background. **Streaming imports never include songwriting credits** (only performer data) — always chain to `pica_credits_update` afterwards, or point the user at `audit-credits` if there's a batch of them.\n\nApple Music and artist-profile URLs aren't supported yet — if the user pastes one, say so and fall back to Lane 3 or 4.\n\n## Lane 2 — YouTube link\n\nSame preview-then-confirm shape as Lane 1: call `pica_import_youtube_link` with `url` first (no `confirm`) to see the classified version type (music_video / live_performance / acoustic / cover / remix / lyric_video / alternate / master) and whether it matched an existing work. Call again with `confirm: true` to execute. Use `target_work_id` if you already know which work it belongs to, or `override_version_type` if the heuristic classification looks wrong.\n\nIf a video is already linked to a recording in this org, use `refresh: true` instead of re-importing — it re-fetches view/like/comment counts onto the existing recording rather than creating a duplicate.\n\nLike streaming imports, YouTube never supplies songwriting credits — chain to `pica_credits_update` after.\n\n## Lane 3 — CSV / spreadsheet (bulk)\n\nFor a spreadsheet or exported catalog list, across `works`, `people`, `recordings`, `documents`, `enquiries`, or `royalties`:\n\n1. `pica_import_fields` — see the target fields for the domain (name, type, required) if the user is unsure what columns to bring\n2. `pica_import_template` — an example CSV to hand back if they're starting from scratch\n3. `pica_import_analyze` — parse the user's CSV (`file_content` for small files, `file_id` from `pica_upload_complete` for anything non-trivial) and get AI-suggested column mappings\n4. `pica_import_validate` — check the mapping against every row before writing anything; fix or accept the reported errors\n5. `pica_import_execute` — run it. Use `dry_run: true` first to preview counts with zero writes, then run for real. `skip_invalid_rows: true` lets the rest land if a few rows are broken; `conflict_strategy: \"skip\"` handles duplicate ISRC/ISWC/tunecode gracefully instead of failing the whole batch. Max 10,000 rows per call.\n\n## Lane 4 — Royalty or streaming statement (PDF / image / xlsx)\n\nIf the user has a **statement document** rather than a clean CSV — a PRO/DSP PDF, a screenshot, an xlsx export — this is a different flow with its own conservative-extraction rules: see the `ingest-my-statements` skill (`pica_statements_pending` → `pica_documents_read` → `pica_statement_ingest_document`). The short version: money is fallible, so line items are extracted with per-row confidence and staged for the owner's approval — nothing lands automatically. If the file is a clean CSV of statement rows, prefer Lane 3 (`domain: \"royalties\"`) instead — the deterministic importer is more reliable than reading numbers off a document.\n\n## What not to do\n\n- Don't skip the preview step on Lanes 1–2 — always show what will be created before calling with `confirm: true`\n- Don't guess at CSV column mappings without running `pica_import_analyze`/`pica_import_validate` first\n- Don't let a streaming or YouTube import stand without mentioning the missing songwriting credits — that's the single most common gap this skill introduces\n- Don't push every lane at once — ask what the user has, then run the one lane that matches\n- Don't treat a statement document as a CSV import target — read `ingest-my-statements` first\n\n## Follow-on skills\n\n- `audit-credits` — once music has landed, especially after a streaming/YouTube import that's performer-credits-only\n- `register-my-works` — once works exist, registration coverage is usually the next gap\n- `catalog-audit` — a full health pass once the first batch is in\n- `ingest-my-statements` — for royalty/streaming statement documents (Lane 4)\n- `set-up-workspace` — if the user also needs org/identifier setup, but don't route there first — get the music in, then tidy settings\n",
+        body: "# import-my-catalog\n\nThe single highest-value first-five-minutes job on PICA: get the user's music in. Run this whenever the catalog is empty, or whenever the user names something they want to bring in (a link, a spreadsheet, a statement). Don't make them guess how — ask what they've got, then use the fastest matching lane.\n\nIf you don't know what they have, ask once, plainly: *\"what have you got — a Spotify or YouTube link, a spreadsheet of your catalog, or a royalty statement to read in?\"*\n\n## Lane 1 — Streaming link (fastest first win)\n\nLead with this when the user has any Spotify or Deezer URL (track, album, or playlist) — it's the shortest path to a populated catalog, usually 2 calls.\n\nCall `pica_import_streaming_link` with `url` and no `confirm` — this **previews** the tracks (title, artists, ISRC, duplicates already in the catalog) without writing anything. Show the user what was found, then call again with `confirm: true` to execute. Use `selected_track_ids` if the user wants a subset.\n\nEach imported track creates a work, a recording, people, and performer credits automatically — artwork and enrichment cascade in the background. **Streaming imports never include songwriting credits** (only performer data) — always chain to `pica_credits_update` afterwards, or point the user at `audit-credits` if there's a batch of them.\n\nApple Music and artist-profile URLs aren't supported yet — if the user pastes one, say so and fall back to Lane 3 or 4.\n\n## Lane 2 — YouTube link\n\nSame preview-then-confirm shape as Lane 1: call `pica_import_youtube_link` with `url` first (no `confirm`) to see the classified version type (music_video / live_performance / acoustic / cover / remix / lyric_video / alternate / master) and whether it matched an existing work. Call again with `confirm: true` to execute. Use `target_work_id` if you already know which work it belongs to, or `override_version_type` if the heuristic classification looks wrong.\n\nIf a video is already linked to a recording in this org, use `refresh: true` instead of re-importing — it re-fetches view/like/comment counts onto the existing recording rather than creating a duplicate.\n\nLike streaming imports, YouTube never supplies songwriting credits — chain to `pica_credits_update` after.\n\n## Lane 3 — CSV / spreadsheet (bulk)\n\nFor a spreadsheet or exported catalog list, across `works`, `people`, `recordings`, `documents`, `enquiries`, or `royalties`:\n\n1. `pica_import_fields` — see the target fields for the domain (name, type, required) if the user is unsure what columns to bring\n2. `pica_import_template` — an example CSV to hand back if they're starting from scratch\n3. `pica_import_analyze` — parse the user's CSV (`file_content` for small files, `file_id` from `pica_upload_complete` for anything non-trivial) and get AI-suggested column mappings\n4. `pica_import_validate` — check the mapping against every row before writing anything; fix or accept the reported errors\n5. `pica_import_execute` — run it. Use `dry_run: true` first to preview counts with zero writes, then run for real. `skip_invalid_rows: true` lets the rest land if a few rows are broken. Duplicates (ISRC/ISWC/tunecode, or a repeated title with no artist) are handled per row by default: the duplicate becomes a warning and the rest of the batch still lands. If the result says `PARTIALLY complete`, the created rows are already saved: fix and re-send only the rows listed as failed, never the whole file. Max 10,000 rows per call.\n\n## Lane 4 — Royalty or streaming statement (PDF / image / xlsx)\n\nIf the user has a **statement document** rather than a clean CSV — a PRO/DSP PDF, a screenshot, an xlsx export — this is a different flow with its own conservative-extraction rules: see the `ingest-my-statements` skill (`pica_statements_pending` → `pica_documents_inspect` → `pica_statement_ingest_document`). The short version: money is fallible, so line items are extracted with per-row confidence and staged for the owner's approval — nothing lands automatically. If the file is a clean CSV of statement rows, prefer Lane 3 (`domain: \"royalties\"`) instead — the deterministic importer is more reliable than reading numbers off a document.\n\n## What not to do\n\n- Don't skip the preview step on Lanes 1–2 — always show what will be created before calling with `confirm: true`\n- Don't guess at CSV column mappings without running `pica_import_analyze`/`pica_import_validate` first\n- Don't let a streaming or YouTube import stand without mentioning the missing songwriting credits — that's the single most common gap this skill introduces\n- Don't push every lane at once — ask what the user has, then run the one lane that matches\n- Don't treat a statement document as a CSV import target — read `ingest-my-statements` first\n\n## Follow-on skills\n\n- `audit-credits` — once music has landed, especially after a streaming/YouTube import that's performer-credits-only\n- `register-my-works` — once works exist, registration coverage is usually the next gap\n- `catalog-audit` — a full health pass once the first batch is in\n- `ingest-my-statements` — for royalty/streaming statement documents (Lane 4)\n- `set-up-workspace` — if the user also needs org/identifier setup, but don't route there first — get the music in, then tidy settings\n",
     },
     "ingest-my-statements": {
         name: "ingest-my-statements",
         description: "Conservative-extraction doctrine for royalty and streaming statement ingestion (PDF/image/xlsx). Flags low-confidence rows, extracts fewer rows confidently over many rows wrongly, never guesses a figure, routes CSV to the deterministic importer, and passes identity hints rather than picking entities.",
         triggers: ["ingest my statement", "import my royalty statement", "upload my streaming statement", "read this royalty statement", "process this statement", "my statement is ready"],
         audience: "artist / manager / publisher",
-        tools_required: ["pica_statements_pending", "pica_documents_read", "pica_statement_ingest_document"],
+        tools_required: ["pica_statements_pending", "pica_documents_inspect", "pica_statement_ingest_document"],
         output: "A per-line confidence-annotated table surfaced to the user for review, then staged for owner approval via pica_statement_ingest_document — rows omitted where confidence is low rather than guessed.",
         when_not_to_use: "Bank statements, invoices, contracts, or non-financial documents.",
-        body: "# ingest my statements\n\nWhen the user uploads a royalty or streaming statement (PDF, image, or xlsx):\n\n1. If it is a **CSV**, do NOT use this flow — CSV goes through the deterministic importer, which is more reliable than reading numbers out of a document.\n2. Find it with `pica_statements_pending`, then read it with `pica_documents_read`.\n3. Extract the line items. **Money is fallible. A wrong royalty number is worse than no number.** Extract fewer rows confidently over many rows wrongly. Give each row a `confidence` (0–1). If you cannot confidently read a figure, leave that row OUT and tell the user you skipped it — never guess.\n4. Pass identifiers you actually see (ISRC/ISWC/IPI/tunecode/writer) as hints; PICA resolves them to the right work/recording. Do not pick the entity yourself.\n5. Call `pica_statement_ingest_document`. The import does NOT land immediately — it waits for the owner's approval (in-view in PICA or via email). Surface the full per-line table to the user in chat so they can check the figures before approving.\n",
+        body: "# ingest my statements\n\nWhen the user uploads a royalty or streaming statement (PDF, image, or xlsx):\n\n1. If it is a **CSV**, do NOT use this flow — CSV goes through the deterministic importer, which is more reliable than reading numbers out of a document.\n2. Find it with `pica_statements_pending`, then read it with `pica_documents_inspect`.\n3. Extract the line items. **Money is fallible. A wrong royalty number is worse than no number.** Extract fewer rows confidently over many rows wrongly. Give each row a `confidence` (0–1). If you cannot confidently read a figure, leave that row OUT and tell the user you skipped it — never guess.\n4. Pass identifiers you actually see (ISRC/ISWC/IPI/tunecode/writer) as hints; PICA resolves them to the right work/recording. Do not pick the entity yourself.\n5. Call `pica_statement_ingest_document`. The import does NOT land immediately — it waits for the owner's approval (in-view in PICA or via email). Surface the full per-line table to the user in chat so they can check the figures before approving.\n",
     },
     "log-a-session": {
         name: "log-a-session",
@@ -93,6 +93,15 @@ export const SKILLS = {
         output: "A pica_sessions row with title, start/end times, type, location, participants, and notes — plus optional links to multimedia (recordings / photos / lyrics drafts) and follow-on splits.",
         body: "# log-a-session\n\nHelp the user log a studio session. Capture it conversationally — don't dump a form. The session row is the ground truth for \"who was there when this song was made\" and feeds into provenance, splits decisions, and the historical record of the catalog.\n\n## Pre-flight\n\nRead `pica://schemas/session-required` for the canonical session shape. Required fields: `title`, `start_time`, `end_time`, `session_type_id` (from `pica_sessions_types`), `participants`. Optional: `work_id`, `recording_id`, `location`, `location_url`, `notes`, `is_all_day`.\n\n## Step 1 — Anchor the session\n\nIf the user named a work (or one was passed as an argument), anchor the session to that work. If not, ask: \"what was this session for?\" — and accept \"I don't know yet\" / \"no work yet\" as valid; `work_id` is optional.\n\n## Step 2 — Capture in order\n\nWalk through these pieces one at a time. Don't ask all six at once.\n\n### 2a. What — title + short description\n\nE.g. \"vocal recording for track 3\" or \"writing session for the new EP.\" Keep it short and specific. The title is the searchable index later.\n\n### 2b. What kind — session_type_id\n\nCall `pica_sessions_types` to get the type vocabulary (recording, mixing, mastering, writing, production, rehearsal, etc.). Let the user pick. Pass the chosen type's UUID as `session_type_id`.\n\n### 2c. When — start_time + end_time\n\nCapture as ISO 8601. If the user gives a relative time (\"yesterday afternoon\", \"Tuesday morning\"), confirm a specific time before writing. Default timezone is Europe/London unless the user specifies otherwise.\n\nFor full-day sessions: set `is_all_day: true` and the times become date-only.\n\n### 2d. Where — location or location_url\n\nStudio name as `location` for physical sessions. Virtual link as `location_url` for remote sessions (Zoom, Riverside, etc.). Both fields are optional but useful for searchable history.\n\n### 2e. Who — participants array\n\nFor each participant, capture `{ personId?, userId?, role? }`. The participant resolution flow:\n\n- If the user names someone you don't recognise, offer `pica_people_query` to look them up\n- If they're not on PICA yet, offer `pica_collaborators_invite` to bring them in before completing the session\n\n`role` is free text — typical values: artist, producer, engineer, writer, manager, visitor.\n\n### 2f. What happened — notes\n\nThe user's free-text recall. This is the bit they'll thank you for later. Specifics like \"tried three takes of the bridge, kept the second\" or \"agreed to split publishing 50/50 with X\" are gold.\n\n## Step 3 — Write\n\nCall `pica_sessions_create` with the captured fields. Confirm what was logged in plain language.\n\n## Step 4 — Offer natural follow-ons\n\nDon't push — surface what fits the session you just logged:\n\n- If multimedia was produced: \"Want me to attach a multimedia file from this session?\" → `pica_multimedia_create`\n- If a new recording came out of it: \"Want me to set master ownership splits for the new recording?\" → `pica_recording_splits_create` (or invoke the `set-recording-splits` skill)\n- \"Want me to log another session?\"\n\n## What not to do\n\n- Don't badger for every field. Only title, start/end times, type, and participants are strictly required. Notes are precious but skippable.\n- Don't auto-create participants you don't recognise — always offer the lookup or invite path\n- Don't infer splits from \"we agreed to split it 50/50\" in the notes — splits are a separate, deliberate step with their own confirmation flow\n- Don't try to reconcile this session with prior sessions (\"you logged a similar session last week\") unless the user asks\n\n## Follow-on skills\n\n- `set-recording-splits` — if a new recording came out of the session\n- `close-the-loop` — if the session was for a specific work, audit that work's gaps next\n- `register-my-works` — sessions contribute to provenance, which strengthens registration\n",
     },
+    "log-a-show": {
+        name: "log-a-show",
+        description: "Capture a live show or a tour credit conversationally — where, when, who played, what was in the set. Records tour_dates + setlist_items rows that feed credits, provenance, and the live dossier.",
+        triggers: ["log last night's gig", "I played", "here's the setlist", "what did I play at", "when did I last play", "I played drums with", "I programmed the tracks for"],
+        audience: "artist / session musician / MD / engineer / tour crew",
+        tools_required: ["pica_log_show", "pica_shows_query", "pica_setlist_match", "pica_people_query", "pica_collaborators_invite"],
+        output: "A show (or tour credit) with its setlist matched to works where they exist, plus optional contributors awaiting attestation.",
+        body: "# log-a-show\n\nHelp the user log a live show. Capture it as a sentence, never as a form.\n\n## Establish one thing first: were they the act?\n\n\"I played the Lexington\" is different from \"I played drums with X at the Albert Hall.\" Set\n`logged_as: \"contributor\"` for the second — it changes everything downstream. A session\nplayer's setlist is describing the gig, not claiming anything, and their own catalogue is not\nexpected to contain those songs. A wrong guess here gets the rest of the conversation wrong, so\nask if it isn't already obvious from how the user described the night.\n\n## Capture it conversationally\n\nGet the shape of the night in a sentence or two — venue, city, date, and what was played. Don't\nwalk the user through a field-by-field form. `pica_log_show` resolves the venue against what\npica already holds: an exact match attaches quietly, anything else comes back as candidates for\nthe user to confirm. A venue is never created without a human confirming it.\n\n## Never do these\n\n- **Never prompt for contributors or crew.** Only record them if the user raises them —\n  `pica_collaborators_invite` is there for when they do, not a checklist to work through.\n- **Never imply money is owed.** A song the user did not write earns them nothing from a\n  performance. Say that plainly if it comes up; do not soften it into a maybe.\n- **Never say pica filed anything with a performing-rights society.** pica produces a record and\n  a dossier, nothing more. No society accepts a setlist by API — PRS Setlists, ASCAP OnStage and\n  BMI Live are all web forms the user still has to submit themselves.\n- **Never present an unconfirmed match as a fact.** \"I think Wide Open is your work of the same\n  name — is that right?\", never \"you played Wide Open.\" `pica_setlist_match` returns a\n  confidence, not a certainty, until the user confirms it.\n\n## Tour credits\n\n\"I programmed the tracks for X, who's on tour right now\" has no date and no venue. It still\nneeds **act, year, and role** — without them the credit is unverifiable and attaches to nothing.\nIf pica already holds that tour, the credit resolves against it and can be corroborated. If not,\nit is recorded as the user's own unverified claim, and should be described that way — never as a\nconfirmed credit.\n\nThe credit itself is a person plus a role on that tour, and pica resolves a person only by\n`email` or `person_id` — a name alone would risk creating a second copy of someone who already\nexists. With neither, `pica_log_show` records the tour and says plainly that it did **not**\nrecord the credit. Relay that and ask for an email; do not let the user leave believing a credit\nexists when only a tour does.\n\n## Attestation\n\nIf the user names someone who was there and offers an email, that person can be invited to\nattest via `pica_collaborators_invite`. Ask before inviting — an invitation is a request, not a\nnotification, and a person who says they were not there is recording something meaningful too.\n\n## What not to do\n\n- Don't turn the setlist into an interrogation — capture titles as given and let matching happen\n  quietly with `pica_setlist_match` in the background.\n- Don't infer a role or a split from \"we all played on it\" in passing — that is a separate,\n  deliberate step with its own confirmation flow.\n- Don't reconcile this show against past shows (\"didn't you play this venue in March?\") unless\n  the user asks — use `pica_shows_query` only when they want the history, not to second-guess\n  what they just told you.\n",
+    },
     "prepare-for-sync": {
         name: "prepare-for-sync",
         description: "Make a catalog sync-ready — ensure audio is uploaded and analysed (BPM, key, energy, mood), genre and lyrics are set, and works are findable by music supervisors searching for tracks.",
@@ -111,16 +120,16 @@ export const SKILLS = {
         output: "One new work + linked master recording created after explicit user confirmation, with the session snapshot stored as provenance on the work's metadata, session-derived credits/samples queued as daw://-cited enrichment proposals (drafts, never verified), and an /inspect link handed to the user.",
         definition_of_done: "The work and its master recording exist, the session snapshot is stored, session-derived claims are queued as proposals (not verified facts), and the user has the /inspect link.",
         when_not_to_use: "Not for bulk catalog import (use import-my-catalog) or back-cataloguing released material from memory — this skill is for the session that is open in the DAW right now.",
-        body: "# register-from-your-daw\n\nRegister the song the user is working on, at the moment they're working on it. The DAW session is the richest primary source of rights provenance that exists — who played what, which sample pack that loop came from, what made that bass — and it is only available while the project is open. Once it's bounced and closed, that context is gone, or reconstructed from memory at its least reliable.\n\n**Important framing:** PICA does NOT connect to DAWs. The DAW MCP (e.g. a community Ableton or REAPER MCP server) is wired into the user's AI client separately, exactly like the peer MCPs in `enrich-from-peer-mcps`. The agent connected to PICA is the same agent connected to the DAW — reading the session is the agent's job; PICA receives the result.\n\n## Pre-flight\n\n- If you authenticate to PICA with a Bearer API key, call `pica_introduce_self` first (per the server instructions) — name yourself and, in `agent_role` or `on_behalf_of`, mention the DAW you're capturing from. The register should be attributable.\n- Confirm a DAW MCP is actually connected in this session — and that its bridge is alive. Several DAW MCPs need an in-DAW component enabled (e.g. Ableton's Remote Script as a Control Surface); if session reads error or time out, say so plainly rather than improvising silently.\n- Fallback ladder when the bridge is down or no DAW MCP is connected: (1) an agent with local filesystem access may read the DAW's own artifacts — Ableton's `Log.txt` names the currently loaded `.als`, and the `.als` itself is gzipped XML carrying tempo (field-proven on the first agent-lane register, 2026-07-16); same rules — parse, don't guess. (2) Take the details from the user directly (plain `pica_works_create` flow). (3) Suggest exporting stems and importing them instead. Whichever rung you land on, tell the user which read path you used. Do not pretend to read a session you cannot see.\n\n## Two capture modes\n\n- **Machine capture** — what the session can tell you: track/group structure, tempo, key/scale, instrument and device names, sample file references. Read automatically, only ever what the peer MCP actually exposes.\n- **Human attribution** — what the session cannot know: who played the part, who wrote the song, what the track is called. The capture supplies the scaffold (\"a drums group ⇒ a part to attribute\"); the human supplies the identity.\n\nCapture is instant; attribution is offered, never forced. A \"who played each of 12 tracks?\" interview would reintroduce the exact friction this removes. If the user wants to save and move on, save and move on.\n\n## Step 1 — Read the session\n\nAsk the DAW MCP for whatever session-level reads it offers: track names and count, group structure, tempo, key/scale if exposed, instrument/device names, detected sample file paths. Collect it into a compact snapshot.\n\nPeer servers vary enormously in read depth (see the per-DAW notes below). Capture what is readable; leave the rest absent. **Never fill a gap with a guess** — an invented tempo or fabricated sample list is worse than no snapshot at all.\n\n## Step 2 — Ask for what the session can't tell you\n\nMost DAW APIs expose no project/Set name, so the **title is user-entered**. Ask for:\n\n- **Title** — require a real one. If the user offers \"Untitled\" or a scratch name, ask whether this is really a work worth registering yet; a save-happy session is not automatically a work, and junk registrations pollute the catalog. If the title came from a file name, strip file-versioning suffixes (\"MAIN\", \"final\", \"v2\") and confirm the cleaned name with the user.\n- **Artist name** — the master recording carries one.\n- **Work type** — default `song`; confirm only if the session suggests otherwise (e.g. an instrumental).\n\n## Step 3 — Duplicate check\n\nCall `pica_works_query` with the title before creating anything. On a plausible match, offer the choice: **open the existing work in /inspect** or **register this as a new version** — never silently create a duplicate. If the create later returns a 409 (`WORK_ALREADY_EXISTS`), surface that same choice; it is a fork in the road, not an error.\n\n## Step 4 — Confirm before any write\n\nShow the user what will be written, in one glance: the title, artist, work type, and the snapshot summary — _\"12 tracks · drums, bass, 2 guitars, lead vocal · 3 samples detected · 124 BPM\"_. Every field is editable. **Nothing is written to PICA until the user explicitly confirms.** Splits and credits are legal facts; the agent drafts, the human signs off.\n\n## Step 5 — Create\n\nOne call: `pica_works_create` with the confirmed `title`, `work_type`, `key` (if the session exposed one), and the session snapshot in `metadata` (DAW name, capture timestamp, track/device/sample summary — the facts, not the raw session tree). `create_twin` defaults to true, so the linked master recording is created in the same call — read the twin's id from the response and pass the artist details through. If the twin needs more than the create carried (e.g. artist name corrections), update the recording afterwards rather than skipping confirmation.\n\n## Step 6 — Seed provenance as drafts, never as facts\n\nSession-derived claims flow through review — they do not land as verified data:\n\n- **Who-played-what and sample usage** → `pica_enrichment_propose` per claim, with a `sources` entry using the `daw://` URI scheme (ADR-193; opaque to PICA, recorded as provenance) and a human-readable `context` (\"Ableton session, drums group, 2026-07-16\").\n- **Writer credits** → only when the user names the writers and confirms splits, via `pica_credits_update` (splits must total 100%).\n- A detected sample is a **detection, not a clearance** — never describe it as cleared.\n\nCaptured ≠ verified. A credit read from a session is a claim; it becomes fact through the user's review, not through the capture.\n\n## Step 7 — Close the loop\n\nHand back the link — `https://withpica.com/inspect/works/<id>` — and tell the user the register is live in their catalog (it lands in the /inspect activity rail in real time). If the flow produced several mutations, call `pica_dashboard_briefing` and surface the delta. Offer the natural next steps: fill credits now, or later via `close-the-loop`.\n\n## Per-DAW peer MCP notes\n\nThese are third-party community servers, not PICA software — capability and maintenance vary, and a failed read degrades gracefully to asking the user.\n\n| DAW | Typical peer MCP read surface |\n|---|---|\n| Ableton Live | Session/track inspection is good in the common community server — but its bridge needs the Remote Script enabled as a Control Surface in Live's settings, or every read fails. Two field notes: the first call right after a set is opened can fail with a binding error (load-time race) — retry once before concluding the bridge is down; and session reads carry **no set name**, so identify the open song (and suggest a title, versioning suffixes stripped) from Live's `Log.txt` → loaded `.als` path — the artifact read complements a live bridge, it isn't only a fallback. Sample-level detail varies by fork |\n| REAPER | Deep — ReaScript exposes essentially the whole session |\n| Pro Tools | Deep — PTSL-based servers read session/track/clip data |\n| FL Studio | Good — recent servers expose live-readable project resources |\n| Bitwig | Moderate — controller-API-based reads |\n| Logic Pro | Shallowest — servers ride UI automation (AppleScript/Accessibility); expect gaps and verify reads with the user |\n\n## What not to do\n\n- Don't write anything before the user's explicit confirmation — no exceptions, however complete the snapshot looks.\n- Don't invent session data the peer MCP didn't return — no guessed tempos, keys, or sample lists.\n- Don't register every sketch. No real title, no register — offer to wait instead.\n- Don't write captured credits or samples as verified facts — they are proposals with `daw://` citations.\n- Don't call a detected sample \"cleared\".\n- Don't dump the raw session tree into `metadata` — extract the facts PICA cares about (structure, devices, samples, tempo/key), not every clip.\n- Don't stamp new facts onto an existing work's `metadata` with a bare update — the jsonb column is **replaced wholesale, not merged**. Read the current snapshot first, merge the new facts into it client-side, then write the merged object back.\n\n## Follow-on skills\n\n- `log-a-session` — record the session itself (date, participants) alongside the registered work\n- `close-the-loop` — walk the remaining gaps on the new work (credits, identifiers, splits)\n- `set-recording-splits` — when the collaborators are known and ready to commit percentages\n- `register-my-works` — when the work is ready to go out to societies\n",
+        body: "# register-from-your-daw\n\nRegister the song the user is working on, at the moment they're working on it. The DAW session is the richest primary source of rights provenance that exists — who played what, which sample pack that loop came from, what made that bass — and it is only available while the project is open. Once it's bounced and closed, that context is gone, or reconstructed from memory at its least reliable.\n\n**Important framing:** PICA does NOT connect to DAWs. The DAW MCP (e.g. a community Ableton or REAPER MCP server) is wired into the user's AI client separately, exactly like the peer MCPs in `enrich-from-peer-mcps`. The agent connected to PICA is the same agent connected to the DAW — reading the session is the agent's job; PICA receives the result.\n\n## Pre-flight\n\n- If you authenticate to PICA with a Bearer API key, call `pica_introduce_self` first (per the server instructions) — name yourself and, in `agent_role` or `on_behalf_of`, mention the DAW you're capturing from. The register should be attributable.\n- Confirm a DAW MCP is actually connected in this session — and that its bridge is alive. Several DAW MCPs need an in-DAW component enabled (e.g. Ableton's Remote Script as a Control Surface); if session reads error or time out, say so plainly rather than improvising silently.\n- Fallback ladder when the bridge is down or no DAW MCP is connected: (1) an agent with local filesystem access may read the DAW's own artifacts — Ableton's `Log.txt` names the currently loaded `.als`, and the `.als` itself is gzipped XML carrying tempo (field-proven on the first agent-lane register, 2026-07-16); same rules — parse, don't guess. (2) Take the details from the user directly (plain `pica_works_create` flow). (3) Suggest exporting stems and importing them instead. Whichever rung you land on, tell the user which read path you used. Do not pretend to read a session you cannot see.\n\n## Two capture modes\n\n- **Machine capture** — what the session can tell you: track/group structure, tempo, key/scale, instrument and device names, sample file references. Read automatically, only ever what the peer MCP actually exposes.\n- **Human attribution** — what the session cannot know: who played the part, who wrote the song, what the track is called. The capture supplies the scaffold (\"a drums group ⇒ a part to attribute\"); the human supplies the identity.\n\nCapture is instant; attribution is offered, never forced. A \"who played each of 12 tracks?\" interview would reintroduce the exact friction this removes. If the user wants to save and move on, save and move on.\n\n## Step 1 — Read the session\n\nAsk the DAW MCP for whatever session-level reads it offers: track names and count, group structure, tempo, key/scale if exposed, instrument/device names, detected sample file paths. Collect it into a compact snapshot.\n\nPeer servers vary enormously in read depth (see the per-DAW notes below). Capture what is readable; leave the rest absent. **Never fill a gap with a guess** — an invented tempo or fabricated sample list is worse than no snapshot at all.\n\n## Step 2 — Ask for what the session can't tell you\n\nMost DAW APIs expose no project/Set name, so the **title is user-entered**. Ask for:\n\n- **Title** — require a real one. If the user offers \"Untitled\" or a scratch name, ask whether this is really a work worth registering yet; a save-happy session is not automatically a work, and junk registrations pollute the catalog. If the title came from a file name, strip file-versioning suffixes (\"MAIN\", \"final\", \"v2\") and confirm the cleaned name with the user.\n- **Artist name** — the master recording carries one.\n- **Work type** — default `song`; confirm only if the session suggests otherwise (e.g. an instrumental).\n\n## Step 3 — Duplicate check\n\nCall `pica_works_query` with the title before creating anything. On a plausible match, offer the choice: **open the existing work in /inspect** or **register this as a new version** — never silently create a duplicate. If the create later returns a 409 (`WORK_ALREADY_EXISTS`), surface that same choice; it is a fork in the road, not an error.\n\n## Step 4 — Confirm before any write\n\nShow the user what will be written, in one glance: the title, artist, work type, and the snapshot summary — _\"12 tracks · drums, bass, 2 guitars, lead vocal · 3 samples detected · 124 BPM\"_. Every field is editable. **Nothing is written to PICA until the user explicitly confirms.** Splits and credits are legal facts; the agent drafts, the human signs off.\n\n## Step 5 — Create\n\nOne call: `pica_works_create` with the confirmed `title`, `work_type`, `key` (if the session exposed one), and the session snapshot in `metadata` (DAW name, capture timestamp, track/device/sample summary — the facts, not the raw session tree). `create_twin` defaults to true, so the linked master recording is created in the same call — read the twin's id from the response and pass the artist details through. If the twin needs more than the create carried (e.g. artist name corrections), update the recording afterwards rather than skipping confirmation.\n\n## Step 6 — Seed provenance as drafts, never as facts\n\nSession-derived claims flow through review — they do not land as verified data:\n\n- **Who-played-what and sample usage** → `pica_enrichment_propose` per claim, with a `sources` entry using the `daw://` URI scheme (opaque to PICA, recorded as provenance) and a human-readable `context` (\"Ableton session, drums group, 2026-07-16\").\n- **Writer credits** → only when the user names the writers and confirms splits, via `pica_credits_update` (splits must total 100%).\n- A detected sample is a **detection, not a clearance** — never describe it as cleared.\n\nCaptured ≠ verified. A credit read from a session is a claim; it becomes fact through the user's review, not through the capture.\n\n## Step 7 — Close the loop\n\nHand back the link — `https://withpica.com/inspect/works/<id>` — and tell the user the register is live in their catalog (it lands in the /inspect activity rail in real time). If the flow produced several mutations, call `pica_dashboard_briefing` and surface the delta. Offer the natural next steps: fill credits now, or later via `close-the-loop`.\n\n## Per-DAW peer MCP notes\n\nThese are third-party community servers, not PICA software — capability and maintenance vary, and a failed read degrades gracefully to asking the user.\n\n| DAW | Typical peer MCP read surface |\n|---|---|\n| Ableton Live | Session/track inspection is good in the common community server — but its bridge needs the Remote Script enabled as a Control Surface in Live's settings, or every read fails. Two field notes: the first call right after a set is opened can fail with a binding error (load-time race) — retry once before concluding the bridge is down; and session reads carry **no set name**, so identify the open song (and suggest a title, versioning suffixes stripped) from Live's `Log.txt` → loaded `.als` path — the artifact read complements a live bridge, it isn't only a fallback. Sample-level detail varies by fork |\n| REAPER | Deep — ReaScript exposes essentially the whole session |\n| Pro Tools | Deep — PTSL-based servers read session/track/clip data |\n| FL Studio | Good — recent servers expose live-readable project resources |\n| Bitwig | Moderate — controller-API-based reads |\n| Logic Pro | Shallowest — servers ride UI automation (AppleScript/Accessibility); expect gaps and verify reads with the user |\n\n## What not to do\n\n- Don't write anything before the user's explicit confirmation — no exceptions, however complete the snapshot looks.\n- Don't invent session data the peer MCP didn't return — no guessed tempos, keys, or sample lists.\n- Don't register every sketch. No real title, no register — offer to wait instead.\n- Don't write captured credits or samples as verified facts — they are proposals with `daw://` citations.\n- Don't call a detected sample \"cleared\".\n- Don't dump the raw session tree into `metadata` — extract the facts PICA cares about (structure, devices, samples, tempo/key), not every clip.\n- Don't stamp new facts onto an existing work's `metadata` with a bare update — the jsonb column is **replaced wholesale, not merged**. Read the current snapshot first, merge the new facts into it client-side, then write the merged object back.\n\n## Follow-on skills\n\n- `log-a-session` — record the session itself (date, participants) alongside the registered work\n- `close-the-loop` — walk the remaining gaps on the new work (credits, identifiers, splits)\n- `set-recording-splits` — when the collaborators are known and ready to commit percentages\n- `register-my-works` — when the work is ready to go out to societies\n",
     },
     "register-my-works": {
         name: "register-my-works",
-        description: "Check registration status across collection societies (PRS, MCPS, PPL, MLC) and prepare works for registration. Identifies blockers, fills missing identifiers, and exports CWR when works are ready.",
-        triggers: ["register my works", "register my songs with my PRO", "get this work to MLC", "CWR export", "am I ready to register"],
+        description: "Check registration status across collection societies (PRS, MCPS, PPL, MLC) and prepare works for registration. Identifies blockers, fills missing identifiers, and exports a registration bundle when works are ready.",
+        triggers: ["register my works", "register my songs with my PRO", "get this work to MLC", "CWR export", "registration bundle", "am I ready to register"],
         audience: "songwriter / publisher / admin",
         tools_required: ["pica_works_inspect", "pica_resolve_work", "pica_enrichment_proposals_list", "pica_credits_update", "pica_export_song_registration"],
-        output: "Per-society registration coverage summary + the most common blocker and how to fix it + a list of works closest to being registration-ready, with offers to enrich missing ISWCs and export CWR for ready works.",
-        body: "# register-my-works\n\nHelp the user understand which of their works are registered with collection societies, which still need registration, and what's blocking the unregistered ones. Then offer to fix the blockers and export the works that are ready.\n\nThis is the highest-pain workflow in PICA. Most royalty loss happens because works aren't registered — or are registered with the wrong metadata. Be precise and offer concrete next actions.\n\n## Pre-flight\n\nRead these two resources before any writes:\n- `pica://schemas/enrichment-resolve-required` — the canonical shape for `pica_resolve_work` calls (used to fill missing ISWCs from MLC)\n- `pica://schemas/export-required` — the CWR export shape used at the end of the flow\n\n## Step 1 — Coverage check\n\nCall `pica_works_query` to list works (default limit 50). Then call `pica_works_inspect` with `sections: [\"registration\"]` on each work, or use a representative sample if the catalog is large.\n\nThe `registration` section returns per-society status (PRS, MCPS, PPL, MLC). Three states are common:\n- **fully registered** — every relevant society has the work\n- **partially registered** — registered with some societies, missing from others\n- **not registered** — no society has it\n\n## Step 2 — Find the blockers\n\nFor unregistered or partially registered works, call `pica_works_inspect` with `sections: [\"registration\", \"completeness\"]` on a sample of 5-10 works. The completeness section names the blocker:\n\n| Blocker | What it means | How to fix |\n|---|---|---|\n| Missing ISWC | Needed for PRS/MCPS | Call `pica_resolve_work` with `sources: ['mlc']` to look up the ISWC |\n| Missing ISRC on recordings | Needed for PPL | Check recordings; if missing, the user may not have released yet or the DSP hasn't assigned one |\n| Missing writer credits | Needed for all societies | Call `pica_credits_update` to add writers (treat `pica://schemas/work-credits-required` as the canonical shape — splits must total 100%) |\n| Missing IPI on a credited writer | Needed for PRO registration | Call `pica_people_update` to add IPI; if unknown, `pica_resolve_person` may find it |\n\nTreat `pica_resolve_*` calls as black boxes — they fan out over external sources and return proposals or matches. Do NOT speculate about how the source-weighting works.\n\n## Step 3 — Enrichment proposals\n\nIf enrichment was triggered, call `pica_enrichment_proposals_list` to see what came back. Each proposal needs explicit user approval before applying. Do not auto-apply.\n\n## Step 4 — Report\n\nProduce:\n- How many works are fully / partially / not registered, as numbers and percentages\n- The most common blocker across unregistered works (one sentence)\n- The 5 works closest to being registration-ready (fewest gaps, listed by title)\n\n## Step 5 — Offers\n\nAlways end with concrete offers the user can accept or decline:\n- \"Want me to try enriching the works missing ISWCs from MLC?\" → triggers `pica_resolve_work` over the relevant set\n- \"Want me to export a CWR file for the works that are ready?\" → `pica_export_song_registration`\n- \"Want me to walk through registering a specific work?\" → user names the work\n\n## What not to do\n\n- Don't claim to register works directly — PICA exports CWR for the user to submit; it doesn't submit to PROs itself\n- Don't bulk-apply enrichment proposals without user approval\n- Don't explain the internal source-weighting of `pica_resolve_*`. The tool returns what it returns\n- Don't recommend `pica_works_delete` even on stale-looking works — registration cleanup is additive, not destructive\n\n## Follow-on skills\n\nAfter registration is in flight:\n- `catalog-audit` — confirm score improvement\n- `prepare-for-sync` — once registered, works are more attractive to sync supervisors\n",
+        output: "Per-society registration coverage summary + the most common blocker and how to fix it + a list of works closest to being registration-ready, with offers to enrich missing ISWCs and export a registration bundle for ready works.",
+        body: "# register-my-works\n\nHelp the user understand which of their works are registered with collection societies, which still need registration, and what's blocking the unregistered ones. Then offer to fix the blockers and export the works that are ready.\n\nThis is the highest-pain workflow in PICA. Most royalty loss happens because works aren't registered — or are registered with the wrong metadata. Be precise and offer concrete next actions.\n\n## Pre-flight\n\nRead these two resources before any writes:\n- `pica://schemas/enrichment-resolve-required` — the canonical shape for `pica_resolve_work` calls (used to fill missing ISWCs from MLC)\n- `pica://schemas/export-required` — the registration-bundle export shape used at the end of the flow\n\n## Step 1 — Coverage check\n\nCall `pica_works_query` to list works (default limit 50). Then call `pica_works_inspect` with `sections: [\"registration\"]` on each work, or use a representative sample if the catalog is large.\n\nThe `registration` section returns per-society status (PRS, MCPS, PPL, MLC). Three states are common:\n- **fully registered** — every relevant society has the work\n- **partially registered** — registered with some societies, missing from others\n- **not registered** — no society has it\n\n## Step 2 — Find the blockers\n\nFor unregistered or partially registered works, call `pica_works_inspect` with `sections: [\"registration\", \"completeness\"]` on a sample of 5-10 works. The completeness section names the blocker:\n\n| Blocker | What it means | How to fix |\n|---|---|---|\n| Missing ISWC | Needed for PRS/MCPS | Call `pica_resolve_work` with `sources: ['mlc']` to look up the ISWC |\n| Missing ISRC on recordings | Needed for PPL | Check recordings; if missing, the user may not have released yet or the DSP hasn't assigned one |\n| Missing writer credits | Needed for all societies | Call `pica_credits_update` to add writers (treat `pica://schemas/work-credits-required` as the canonical shape — splits must total 100%) |\n| Missing IPI on a credited writer | Needed for PRO registration | Call `pica_people_update` to add IPI; if unknown, `pica_resolve_person` may find it |\n\nTreat `pica_resolve_*` calls as black boxes — they fan out over external sources and return proposals or matches. Do NOT speculate about how the source-weighting works.\n\n## Step 3 — Enrichment proposals\n\nIf enrichment was triggered, call `pica_enrichment_proposals_list` to see what came back. Each proposal needs explicit user approval before applying. Do not auto-apply.\n\n## Step 4 — Report\n\nProduce:\n- How many works are fully / partially / not registered, as numbers and percentages\n- The most common blocker across unregistered works (one sentence)\n- The 5 works closest to being registration-ready (fewest gaps, listed by title)\n\n## Step 5 — Offers\n\nAlways end with concrete offers the user can accept or decline:\n- \"Want me to try enriching the works missing ISWCs from MLC?\" → triggers `pica_resolve_work` over the relevant set\n- \"Want me to export a registration bundle for the works that are ready?\" → `pica_export_song_registration`\n- \"Want me to walk through registering a specific work?\" → user names the work\n\n## What not to do\n\n- Don't claim to register works directly — PICA exports a registration bundle for the user to submit; it doesn't submit to PROs itself\n- ⚠️ Don't call the bundle a CWR file. PICA has **no CWR emitter**: the ZIP holds CSVs plus `mapping-guide.md`, which maps those columns onto CWR fields for whoever does the submission. Saying \"I exported a CWR file\" is false, and the user finds out at the society.\n- Don't bulk-apply enrichment proposals without user approval\n- Don't explain the internal source-weighting of `pica_resolve_*`. The tool returns what it returns\n- Don't recommend `pica_works_delete` even on stale-looking works — registration cleanup is additive, not destructive\n\n## Follow-on skills\n\nAfter registration is in flight:\n- `catalog-audit` — confirm score improvement\n- `prepare-for-sync` — once registered, works are more attractive to sync supervisors\n",
     },
     "set-recording-splits": {
         name: "set-recording-splits",
@@ -129,7 +138,7 @@ export const SKILLS = {
         audience: "producer / artist / label / manager",
         tools_required: ["pica_recording_splits_list", "pica_recording_splits_create", "pica_recording_splits_verify", "pica_recordings_query", "pica_people_query", "pica_collaborators_invite", "pica_split_sheet_generate", "pica_split_sheet_send"],
         output: "Confirmed + verified recording_splits rows totalling 100%, with the option to generate and send a split sheet PDF for signatures.",
-        body: "# set-recording-splits\n\nHelp the user set master ownership splits on a recording. These are master-side royalty shares — distinct from publishing splits, which are credits on a work. Splits flow into payments, so the skill prioritises accuracy over speed: propose → dry-run → confirm → commit → verify.\n\n## Pre-flight\n\nRead `pica://schemas/recording-splits-required` before any write. The canonical shape is `recording_id`, `person_id`, `split_percentage`, `split_type`. **Splits must total 100% across all rows for a recording.**\n\n## Step 1 — Pick the recording\n\nIf the user names a recording or gives an ID, use it. Otherwise, call `pica_recordings_query` and let the user pick from recent recordings.\n\n## Step 2 — Show current state\n\nCall `pica_recording_splits_list` for the recording. Three states:\n\n- **Empty** — no splits set yet. Proceed to step 3.\n- **Partial** — some splits exist but don't total 100%. Ask the user whether they want to add to the existing rows or replace them.\n- **Complete** — splits total 100%. Ask whether the user wants to verify (mark agreed-upon) or replace.\n\nAlways summarise the current state plainly: \"right now this recording has [N] splits totalling [X]%, with [A] holding [P]%...\"\n\n## Step 3 — Capture proposed splits\n\nFor each split row, capture:\n\n- **Who owns this share?** — `person_id` from `pica_people_query`. If the person isn't on PICA yet, offer `pica_collaborators_invite` to bring them in before writing the split.\n- **What percentage?** — must sum to 100% across all rows.\n- **What kind?** — `split_type` — typical values: `artist`, `producer`, `label`, `featured`.\n\nSum the percentages out loud as you go. If they're not totalling 100% when the user finishes describing them, stop and ask them to adjust before proceeding.\n\n## Step 4 — Dry-run preview\n\nPer ADR-199, call `pica_recording_splits_create` with `dry_run: true` for each proposed row. Surface the would-affect preview to the user — what would be written, what the totals are after writing, any side-effects.\n\nSum the percentages one more time. **If they don't total 100%, stop.** Do not proceed to commit.\n\n## Step 5 — Explicit confirmation\n\nSay something like:\n\n> \"I'm about to set [N] splits on this recording totalling 100%:\n> - [A] — [P]% ([type])\n> - [B] — [Q]% ([type])\n> Reply 'yes' to commit, or tell me what to change.\"\n\nWait for the user's explicit \"yes\" (or equivalent). Don't write on ambiguous signals.\n\n## Step 6 — Commit\n\nFor each split, call `pica_recording_splits_create` (this time without `dry_run`). Report each row back as it lands. If any write fails, stop the loop — don't partially commit.\n\n## Step 7 — Verify\n\nFor each newly created split, call `pica_recording_splits_verify` with the `split_id`. Verification marks the split as agreed-upon — a separate state from \"exists in the database.\"\n\n## Step 8 — Offer next moves\n\n- \"Want me to generate a split sheet PDF for signatures?\" → `pica_split_sheet_generate`\n- \"Want me to send the split sheet to the parties?\" → `pica_split_sheet_send`\n- \"Want me to set splits on another recording?\"\n\n## What not to do\n\n- Don't write splits without an explicit \"yes\" from the user\n- Don't proceed if the totals don't equal 100% — re-prompt instead\n- Don't auto-skip the verify step. Verification is a deliberate user moment.\n- Don't speculate about typical splits by genre or scene — if the user doesn't know what % someone deserves, that's a business conversation outside this skill\n- Don't conflate with writer splits — those are credits on a work, set via `pica_credits_update`. Different table, different semantics.\n\n## Follow-on skills\n\n- `close-the-loop` — recording splits are usually one gap among several on a work; close-the-loop fits the others\n- `register-my-works` — registered works pair with recordings that have clear ownership chains\n- `audit-credits` — splits health-check across the whole catalog\n",
+        body: "# set-recording-splits\n\nHelp the user set master ownership splits on a recording. These are master-side royalty shares — distinct from publishing splits, which are credits on a work. Splits flow into payments, so the skill prioritises accuracy over speed: propose → dry-run → confirm → commit → verify.\n\n## Pre-flight\n\nRead `pica://schemas/recording-splits-required` before any write. The canonical shape is `recording_id`, `person_id`, `split_percentage`, `split_type`. **Splits must total 100% across all rows for a recording.**\n\n## Step 1 — Pick the recording\n\nIf the user names a recording or gives an ID, use it. Otherwise, call `pica_recordings_query` and let the user pick from recent recordings.\n\n## Step 2 — Show current state\n\nCall `pica_recording_splits_list` for the recording. Three states:\n\n- **Empty** — no splits set yet. Proceed to step 3.\n- **Partial** — some splits exist but don't total 100%. Ask the user whether they want to add to the existing rows or replace them.\n- **Complete** — splits total 100%. Ask whether the user wants to verify (mark agreed-upon) or replace.\n\nAlways summarise the current state plainly: \"right now this recording has [N] splits totalling [X]%, with [A] holding [P]%...\"\n\n## Step 3 — Capture proposed splits\n\nFor each split row, capture:\n\n- **Who owns this share?** — `person_id` from `pica_people_query`. If the person isn't on PICA yet, offer `pica_collaborators_invite` to bring them in before writing the split.\n- **What percentage?** — must sum to 100% across all rows.\n- **What kind?** — `split_type` — typical values: `artist`, `producer`, `label`, `featured`.\n\nSum the percentages out loud as you go. If they're not totalling 100% when the user finishes describing them, stop and ask them to adjust before proceeding.\n\n## Step 4 — Dry-run preview\n\nCall `pica_recording_splits_create` with `dry_run: true` for each proposed row. Surface the would-affect preview to the user — what would be written, what the totals are after writing, any side-effects.\n\nSum the percentages one more time. **If they don't total 100%, stop.** Do not proceed to commit.\n\n## Step 5 — Explicit confirmation\n\nSay something like:\n\n> \"I'm about to set [N] splits on this recording totalling 100%:\n> - [A] — [P]% ([type])\n> - [B] — [Q]% ([type])\n> Reply 'yes' to commit, or tell me what to change.\"\n\nWait for the user's explicit \"yes\" (or equivalent). Don't write on ambiguous signals.\n\n## Step 6 — Commit\n\nFor each split, call `pica_recording_splits_create` (this time without `dry_run`). Report each row back as it lands. If any write fails, stop the loop — don't partially commit.\n\n## Step 7 — Verify\n\nFor each newly created split, call `pica_recording_splits_verify` with the `split_id`. Verification marks the split as agreed-upon — a separate state from \"exists in the database.\"\n\n## Step 8 — Offer next moves\n\n- \"Want me to generate a split sheet PDF for signatures?\" → `pica_split_sheet_generate`\n- \"Want me to send the split sheet to the parties?\" → `pica_split_sheet_send`\n- \"Want me to set splits on another recording?\"\n\n## What not to do\n\n- Don't write splits without an explicit \"yes\" from the user\n- Don't proceed if the totals don't equal 100% — re-prompt instead\n- Don't auto-skip the verify step. Verification is a deliberate user moment.\n- Don't speculate about typical splits by genre or scene — if the user doesn't know what % someone deserves, that's a business conversation outside this skill\n- Don't conflate with writer splits — those are credits on a work, set via `pica_credits_update`. Different table, different semantics.\n\n## Follow-on skills\n\n- `close-the-loop` — recording splits are usually one gap among several on a work; close-the-loop fits the others\n- `register-my-works` — registered works pair with recordings that have clear ownership chains\n- `audit-credits` — splits health-check across the whole catalog\n",
     },
     "set-up-workspace": {
         name: "set-up-workspace",
@@ -138,8 +147,8 @@ export const SKILLS = {
         audience: "new user / returning user reconfiguring / admin onboarding a team",
         tools_required: ["pica_organisation_profile", "pica_user_profile", "pica_update_organisation_profile", "pica_update_my_identity", "pica_get_privacy_settings", "pica_storage_status", "pica_storage_configure_start", "pica_subscription_status", "pica_acknowledge_onboarding"],
         output: "A 6-block setup walkthrough — each block returns \"already done\", \"missing\", or \"ready to do now\" with the specific tool call that completes it. Ends with a one-line summary of what's left and a call to pica_acknowledge_onboarding when the user is satisfied.",
-        body: "# set-up-workspace\n\nHelp the user get their workspace properly configured. This skill is for the moment right after signup, and for returning users who want to fill gaps they skipped. It is NOT for importing music — that's `import-my-catalog`. This skill is purely about **settings, identifiers, and infrastructure**.\n\nSetup is high-value but low-glamour. Every block has a concrete payoff:\n\n- **No org identifiers** → registrations and exports will be missing critical metadata\n- **No user IPI** → if you write songs, your PRO can't pay you what your catalog earns\n- **No storage configured** → uploads land on PICA's bucket; for BYOC orgs that's a billing surprise\n- **No team invited** → if you're managing a roster, every collaborator is doing duplicate work (team invites are managed by a human in /settings — see Block 5)\n\nPICA does NOT manage external service integrations (Gmail, Drive, Notion, etc.) — those live in the user's AI client (Claude Desktop, Cursor, ChatGPT). The cross-MCP composition workflow is a separate skill (`enrich-from-peer-mcps`) — surface it after setup if the user mentions they use other tools alongside PICA.\n\nThe skill walks 6 blocks in order of compound value. Each block has the same shape: **read current state → describe gap → offer the specific tool call**. Skip blocks where state is already complete.\n\n## Pre-flight\n\nCall `pica_organisation_profile` and `pica_user_profile` first. These two reads give you the orientation for everything that follows — what type of org this is, what role the user plays, what's already set.\n\nIf `pica_organisation_profile` indicates this org was created today (or the user's profile shows no identifiers), assume fresh-signup mode and go through all blocks in order. If the user says \"I want to update my settings\" assume returning-user mode and ask which block matters.\n\n## Block 1 — Org profile\n\nThe organisation's own metadata: legal name, country, business type (publisher / label / artist / management / sync agency / etc), contact, registered office.\n\nWhat to check from `pica_organisation_profile`:\n- Is `name` set to something other than the auto-generated default?\n- Is `country` set? (drives default territory on registrations and exports)\n- Is `business_type` set? (drives which tools are most relevant — e.g. publishers care more about IPI, labels care more about ISRC)\n- For publishers: is the publisher IPI set?\n- For labels: is the label proprietary number set?\n\nIf gaps, offer the specific update via `pica_update_organisation_profile`. Always show the user what you're about to change and ask before writing.\n\n## Block 2 — User identity (IPI / ISNI)\n\nThe connected user's own identifiers as a creator. This is where royalty leak happens — a songwriter without an IPI on their PICA profile will have works registered without the writer-side identifier, which means the PRO can't route royalties to them.\n\nWhat to check from `pica_user_profile`:\n- Is the user named correctly (legal name for registrations, plus any pseudonyms / stage names)\n- Is the user's IPI set?\n- Is the user's ISNI set?\n- Is the user's role/business posture set (writer / producer / artist / publisher rep / etc)\n\nIf missing identifiers and the user doesn't know their IPI:\n- For writers: it comes from their PRO (PRS, ASCAP, BMI, SACEM, etc) — they have it in their PRO portal\n- If they're not a PRO member yet, this block is also a flag to start that process (out of scope — but mention it)\n\nOffer the update via `pica_update_my_identity`. Treat IPI / ISNI as plain strings — the tool validates format.\n\n## Block 3 — Privacy & sharing defaults\n\nCall `pica_get_privacy_settings`. This controls what other PICA users see about the org's catalog by default. Common gotcha: the default is conservative — if the user expects their catalog to appear in PICA's public directory, this block is what turns it on.\n\nWhat to check:\n- Directory visibility — is the org opted into the public directory?\n- Sharing defaults — do new works inherit private or public defaults?\n- Email contact preferences — who can reach the user through PICA\n\nIf the user is a sync-pitch operation or wants their catalog discoverable, surface the directory opt-in clearly. If the user is a high-privacy operation (sale prep, M&A, working with sensitive sync briefs), reinforce the conservative default.\n\n## Block 4 — Storage configuration\n\nCall `pica_storage_status`. PICA supports BYOC storage (bring-your-own-cloud) — the user can wire their own S3/R2/GCS bucket so audio + multimedia live in infrastructure they control.\n\nThree states:\n- **Default (PICA-managed)** — fine for trial and small catalogs. Mention BYOC as an upgrade path for users with compliance needs or existing buckets.\n- **Configuring** — the user is partway through `pica_storage_configure_start` and hasn't completed credential setup. Offer to walk through the remaining steps.\n- **Connected** — confirmed working. Mention the disconnect tool exists if they need it.\n\nIf the user has compliance constraints, sensitive content, or a large existing audio library, call out BYOC as worth doing now (before upload). Cheaper to wire correctly than to migrate later.\n\n## Block 5 — Billing & team\n\nCall `pica_subscription_status`.\n\nBilling:\n- If `billing_state` is `trial` with >3 days remaining, no action needed\n- If trial is ending (≤3 days) or already ended, surface `pica_subscription_manage` to mint a checkout URL\n- If active, confirm the tier matches the user's expected usage\n\nTeam:\n- Team membership is human-only by design (ADR-248) — there are no MCP tools for it. If the user is managing a roster, point them at the team section of https://withpica.com/settings to invite teammates and manage roles themselves\n- Distinct from `pica_collaborators_invite` which is for **external** collaborators on specific works (writers, producers) — team is for **PICA-account access**\n\n## Block 6 — Acknowledge & close out\n\nWhen the user is satisfied with setup (whether they completed every block or deliberately skipped some), call `pica_acknowledge_onboarding`. This dismisses the onboarding nudges in the UI so they don't keep getting reminded.\n\nThen summarise:\n- What was set this session (3-5 line bullet list)\n- What's intentionally left for later (e.g. \"you'll add your IPI once your PRO registration finalises\")\n- The natural next step — probably `import-my-catalog` if no catalog yet, or `catalog-audit` if catalog exists\n\n## What not to do\n\n- Don't run all 6 blocks in one giant message. Walk through them. Each block is a check + an offer; the user agrees or declines per block.\n- Don't change settings without showing the user what's about to change and asking confirmation\n- Don't push BYOC storage or paid tiers if the user hasn't asked — surface them, don't sell them\n- Don't speculate about which PRO the user should join — that's a business decision outside this skill\n- Don't try to set IPI/ISNI values you've guessed. If the user doesn't know, leave the field empty and explain where to look\n- Don't try to \"connect Gmail to PICA\" or similar — PICA doesn't manage peer-service integrations. The user wires Gmail/Drive/etc. into their AI client separately; PICA's role is to consume the resulting URIs during enrichment (see `enrich-from-peer-mcps`).\n\n## Follow-on skills\n\n- `import-my-catalog` — if the catalog is empty, this is the natural next move\n- `catalog-audit` — if there's already a catalog, audit it now that identifiers are in place\n- `register-my-works` — once identifiers are set, registration coverage tends to be the next thing the user wants to fix\n- `enrich-from-peer-mcps` (Stage 2) — if the user mentions they have other MCPs connected (Gmail, Drive, etc.), this is the cross-MCP workflow that consumes them\n",
+        body: "# set-up-workspace\n\nHelp the user get their workspace properly configured. This skill is for the moment right after signup, and for returning users who want to fill gaps they skipped. It is NOT for importing music — that's `import-my-catalog`. This skill is purely about **settings, identifiers, and infrastructure**.\n\nSetup is high-value but low-glamour. Every block has a concrete payoff:\n\n- **No org identifiers** → registrations and exports will be missing critical metadata\n- **No user IPI** → if you write songs, your PRO can't pay you what your catalog earns\n- **No storage configured** → uploads land on PICA's bucket; for BYOC orgs that's a billing surprise\n- **No team invited** → if you're managing a roster, every collaborator is doing duplicate work (team invites are managed by a human in /settings — see Block 5)\n\nPICA does NOT manage external service integrations (Gmail, Drive, Notion, etc.) — those live in the user's AI client (Claude Desktop, Cursor, ChatGPT). The cross-MCP composition workflow is a separate skill (`enrich-from-peer-mcps`) — surface it after setup if the user mentions they use other tools alongside PICA.\n\nThe skill walks 6 blocks in order of compound value. Each block has the same shape: **read current state → describe gap → offer the specific tool call**. Skip blocks where state is already complete.\n\n## Pre-flight\n\nCall `pica_organisation_profile` and `pica_user_profile` first. These two reads give you the orientation for everything that follows — what type of org this is, what role the user plays, what's already set.\n\nIf `pica_organisation_profile` indicates this org was created today (or the user's profile shows no identifiers), assume fresh-signup mode and go through all blocks in order. If the user says \"I want to update my settings\" assume returning-user mode and ask which block matters.\n\n## Block 1 — Org profile\n\nThe organisation's own metadata: legal name, country, business type (publisher / label / artist / management / sync agency / etc), contact, registered office.\n\nWhat to check from `pica_organisation_profile`:\n- Is `name` set to something other than the auto-generated default?\n- Is `country` set? (drives default territory on registrations and exports)\n- Is `business_type` set? (drives which tools are most relevant — e.g. publishers care more about IPI, labels care more about ISRC)\n- For publishers: is the publisher IPI set?\n- For labels: is the label proprietary number set?\n\nIf gaps, offer the specific update via `pica_update_organisation_profile`. Always show the user what you're about to change and ask before writing.\n\n## Block 2 — User identity (IPI / ISNI)\n\nThe connected user's own identifiers as a creator. This is where royalty leak happens — a songwriter without an IPI on their PICA profile will have works registered without the writer-side identifier, which means the PRO can't route royalties to them.\n\nWhat to check from `pica_user_profile`:\n- Is the user named correctly (legal name for registrations, plus any pseudonyms / stage names)\n- Is the user's IPI set?\n- Is the user's ISNI set?\n- Is the user's role/business posture set (writer / producer / artist / publisher rep / etc)\n\nIf missing identifiers and the user doesn't know their IPI:\n- For writers: it comes from their PRO (PRS, ASCAP, BMI, SACEM, etc) — they have it in their PRO portal\n- If they're not a PRO member yet, this block is also a flag to start that process (out of scope — but mention it)\n\nOffer the update via `pica_update_my_identity`. Treat IPI / ISNI as plain strings — the tool validates format.\n\n## Block 3 — Privacy & sharing defaults\n\nCall `pica_get_privacy_settings`. This controls what other PICA users see about the org's catalog by default. Common gotcha: the default is conservative — if the user expects their catalog to appear in PICA's public directory, this block is what turns it on.\n\nWhat to check:\n- Directory visibility — is the org opted into the public directory?\n- Sharing defaults — do new works inherit private or public defaults?\n- Email contact preferences — who can reach the user through PICA\n\nIf the user is a sync-pitch operation or wants their catalog discoverable, surface the directory opt-in clearly. If the user is a high-privacy operation (sale prep, M&A, working with sensitive sync briefs), reinforce the conservative default.\n\n## Block 4 — Storage configuration\n\nCall `pica_storage_status`. PICA supports BYOC storage (bring-your-own-cloud) — the user can wire their own S3/R2/GCS bucket so audio + multimedia live in infrastructure they control.\n\nThree states:\n- **Default (PICA-managed)** — fine for trial and small catalogs. Mention BYOC as an upgrade path for users with compliance needs or existing buckets.\n- **Configuring** — the user is partway through `pica_storage_configure_start` and hasn't completed credential setup. Offer to walk through the remaining steps.\n- **Connected** — confirmed working. Mention the disconnect tool exists if they need it.\n\nIf the user has compliance constraints, sensitive content, or a large existing audio library, call out BYOC as worth doing now (before upload). Cheaper to wire correctly than to migrate later.\n\n## Block 5 — Billing & team\n\nCall `pica_subscription_status`.\n\nBilling:\n- If `billing_state` is `trial` with >3 days remaining, no action needed\n- If trial is ending (≤3 days) or already ended, surface `pica_subscription_manage` to mint a checkout URL\n- If active, confirm the tier matches the user's expected usage\n\nTeam:\n- Team membership is human-only by design — there are no MCP tools for it. If the user is managing a roster, point them at the team section of https://withpica.com/settings to invite teammates and manage roles themselves\n- Distinct from `pica_collaborators_invite` which is for **external** collaborators on specific works (writers, producers) — team is for **PICA-account access**\n\n## Block 6 — Acknowledge & close out\n\nWhen the user is satisfied with setup (whether they completed every block or deliberately skipped some), call `pica_acknowledge_onboarding`. This dismisses the onboarding nudges in the UI so they don't keep getting reminded.\n\nThen summarise:\n- What was set this session (3-5 line bullet list)\n- What's intentionally left for later (e.g. \"you'll add your IPI once your PRO registration finalises\")\n- The natural next step — probably `import-my-catalog` if no catalog yet, or `catalog-audit` if catalog exists\n\n## What not to do\n\n- Don't run all 6 blocks in one giant message. Walk through them. Each block is a check + an offer; the user agrees or declines per block.\n- Don't change settings without showing the user what's about to change and asking confirmation\n- Don't push BYOC storage or paid tiers if the user hasn't asked — surface them, don't sell them\n- Don't speculate about which PRO the user should join — that's a business decision outside this skill\n- Don't try to set IPI/ISNI values you've guessed. If the user doesn't know, leave the field empty and explain where to look\n- Don't try to \"connect Gmail to PICA\" or similar — PICA doesn't manage peer-service integrations. The user wires Gmail/Drive/etc. into their AI client separately; PICA's role is to consume the resulting URIs during enrichment (see `enrich-from-peer-mcps`).\n\n## Follow-on skills\n\n- `import-my-catalog` — if the catalog is empty, this is the natural next move\n- `catalog-audit` — if there's already a catalog, audit it now that identifiers are in place\n- `register-my-works` — once identifiers are set, registration coverage tends to be the next thing the user wants to fix\n- `enrich-from-peer-mcps` (Stage 2) — if the user mentions they have other MCPs connected (Gmail, Drive, etc.), this is the cross-MCP workflow that consumes them\n",
     },
 };
-export const SKILL_NAMES = ["audit-credits", "catalog-audit", "catalog-modelling", "clean-up-artists", "close-the-loop", "enrich-from-peer-mcps", "first-session", "import-my-catalog", "ingest-my-statements", "log-a-session", "prepare-for-sync", "register-from-your-daw", "register-my-works", "set-recording-splits", "set-up-workspace"];
+export const SKILL_NAMES = ["audit-credits", "catalog-audit", "catalog-modelling", "clean-up-artists", "close-the-loop", "enrich-from-peer-mcps", "first-session", "import-my-catalog", "ingest-my-statements", "log-a-session", "log-a-show", "prepare-for-sync", "register-from-your-daw", "register-my-works", "set-recording-splits", "set-up-workspace"];
 //# sourceMappingURL=skills.generated.js.map

package/dist/skills/skills.generated.js.map

@@ -1 +1 @@
-{"version":3,"file":"skills.generated.js","sourceRoot":"","sources":["../../src/skills/skills.generated.ts"],"names":[],"mappings":"AAAA,6DAA6D;AA+B7D,MAAM,CAAC,MAAM,MAAM,GAA0B;IAC3C,eAAe,EAAE;QACf,IAAI,EAAE,eAAe;QACrB,WAAW,EAAE,4WAA4W;QACzX,QAAQ,EAAE,CAAC,kBAAkB,EAAC,iBAAiB,EAAC,kBAAkB,EAAC,uCAAuC,EAAC,qBAAqB,CAAC;QACjI,QAAQ,EAAE,6BAA6B;QACvC,cAAc,EAAE,CAAC,kBAAkB,EAAC,mBAAmB,EAAC,mBAAmB,EAAC,qBAAqB,CAAC;QAClG,MAAM,EAAE,4NAA4N;QACpO,IAAI,EAAE,4iJAA4iJ;KACnjJ;IACD,eAAe,EAAE;QACf,IAAI,EAAE,eAAe;QACrB,WAAW,EAAE,sMAAsM;QACnN,QAAQ,EAAE,CAAC,kBAAkB,EAAC,wBAAwB,EAAC,gBAAgB,EAAC,mBAAmB,EAAC,mBAAmB,CAAC;QAChH,QAAQ,EAAE,0BAA0B;QACpC,cAAc,EAAE,CAAC,yBAAyB,EAAC,oBAAoB,EAAC,kBAAkB,EAAC,oBAAoB,EAAC,sBAAsB,CAAC;QAC/H,MAAM,EAAE,iLAAiL;QACzL,IAAI,EAAE,s8GAAs8G;KAC78G;IACD,mBAAmB,EAAE;QACnB,IAAI,EAAE,mBAAmB;QACzB,WAAW,EAAE,+PAA+P;QAC5Q,QAAQ,EAAE,CAAC,yBAAyB,EAAC,+BAA+B,EAAC,sBAAsB,EAAC,kBAAkB,EAAC,gCAAgC,EAAC,wBAAwB,EAAC,mBAAmB,CAAC;QAC7L,QAAQ,EAAE,0BAA0B;QACpC,cAAc,EAAE,CAAC,mBAAmB,EAAC,wBAAwB,EAAC,wBAAwB,EAAC,mBAAmB,EAAC,qBAAqB,CAAC;QACjI,MAAM,EAAE,iOAAiO;QACzO,kBAAkB,EAAE,iQAAiQ;QACrR,eAAe,EAAE,gNAAgN;QACjO,IAAI,EAAE,42SAA42S;KACn3S;IACD,kBAAkB,EAAE;QAClB,IAAI,EAAE,kBAAkB;QACxB,WAAW,EAAE,+TAA+T;QAC5U,QAAQ,EAAE,CAAC,qBAAqB,EAAC,wBAAwB,EAAC,sCAAsC,EAAC,yBAAyB,EAAC,uCAAuC,EAAC,yBAAyB,CAAC;QAC7L,QAAQ,EAAE,0BAA0B;QACpC,cAAc,EAAE,CAAC,mBAAmB,EAAC,uBAAuB,EAAC,sCAAsC,EAAC,uBAAuB,EAAC,oBAAoB,CAAC;QACjJ,MAAM,EAAE,uOAAuO;QAC/O,IAAI,EAAE,ujJAAujJ;KAC9jJ;IACD,gBAAgB,EAAE;QAChB,IAAI,EAAE,gBAAgB;QACtB,WAAW,EAAE,oMAAoM;QACjN,QAAQ,EAAE,CAAC,6BAA6B,EAAC,6BAA6B,EAAC,4BAA4B,EAAC,kBAAkB,EAAC,oBAAoB,CAAC;QAC5I,QAAQ,EAAE,mEAAmE;QAC7E,cAAc,EAAE,CAAC,oBAAoB,EAAC,kBAAkB,EAAC,mBAAmB,EAAC,qBAAqB,EAAC,mBAAmB,EAAC,6BAA6B,EAAC,oBAAoB,CAAC;QAC1K,MAAM,EAAE,qLAAqL;QAC7L,IAAI,EAAE,4vHAA4vH;KACnwH;IACD,uBAAuB,EAAE;QACvB,IAAI,EAAE,uBAAuB;QAC7B,WAAW,EAAE,wRAAwR;QACrS,QAAQ,EAAE,CAAC,6BAA6B,EAAC,iCAAiC,EAAC,sBAAsB,EAAC,qCAAqC,EAAC,mCAAmC,EAAC,yCAAyC,EAAC,kDAAkD,EAAC,yCAAyC,CAAC;QACnT,QAAQ,EAAE,yEAAyE;QACnF,cAAc,EAAE,CAAC,oBAAoB,EAAC,kBAAkB,EAAC,mBAAmB,EAAC,yBAAyB,EAAC,gCAAgC,CAAC;QACxI,MAAM,EAAE,4KAA4K;QACpL,IAAI,EAAE,s5NAAs5N;KAC75N;IACD,eAAe,EAAE;QACf,IAAI,EAAE,eAAe;QACrB,WAAW,EAAE,sVAAsV;QACnW,QAAQ,EAAE,CAAC,kBAAkB,EAAC,kBAAkB,EAAC,SAAS,EAAC,wBAAwB,EAAC,mBAAmB,EAAC,kBAAkB,EAAC,4BAA4B,CAAC;QACxJ,QAAQ,EAAE,oFAAoF;QAC9F,cAAc,EAAE,CAAC,yBAAyB,EAAC,yBAAyB,EAAC,0BAA0B,EAAC,iBAAiB,EAAC,mBAAmB,EAAC,kBAAkB,EAAC,kBAAkB,EAAC,4BAA4B,EAAC,0BAA0B,CAAC;QACpO,MAAM,EAAE,iUAAiU;QACzU,IAAI,EAAE,0qdAA0qd;KACjrd;IACD,mBAAmB,EAAE;QACnB,IAAI,EAAE,mBAAmB;QACzB,WAAW,EAAE,uTAAuT;QACpU,QAAQ,EAAE,CAAC,mBAAmB,EAAC,wCAAwC,EAAC,sBAAsB,EAAC,iBAAiB,EAAC,0BAA0B,EAAC,6BAA6B,EAAC,wBAAwB,EAAC,0BAA0B,CAAC;QAC9N,QAAQ,EAAE,qEAAqE;QAC/E,cAAc,EAAE,CAAC,4BAA4B,EAAC,0BAA0B,EAAC,oBAAoB,EAAC,sBAAsB,EAAC,qBAAqB,EAAC,sBAAsB,EAAC,qBAAqB,EAAC,yBAAyB,EAAC,qBAAqB,EAAC,gCAAgC,CAAC;QACzQ,MAAM,EAAE,6OAA6O;QACrP,IAAI,EAAE,ohKAAohK;KAC3hK;IACD,sBAAsB,EAAE;QACtB,IAAI,EAAE,sBAAsB;QAC5B,WAAW,EAAE,+SAA+S;QAC5T,QAAQ,EAAE,CAAC,qBAAqB,EAAC,6BAA6B,EAAC,+BAA+B,EAAC,6BAA6B,EAAC,wBAAwB,EAAC,uBAAuB,CAAC;QAC9K,QAAQ,EAAE,8BAA8B;QACxC,cAAc,EAAE,CAAC,yBAAyB,EAAC,qBAAqB,EAAC,gCAAgC,CAAC;QAClG,MAAM,EAAE,sMAAsM;QAC9M,eAAe,EAAE,mEAAmE;QACpF,IAAI,EAAE,giCAAgiC;KACviC;IACD,eAAe,EAAE;QACf,IAAI,EAAE,eAAe;QACrB,WAAW,EAAE,8NAA8N;QAC3O,QAAQ,EAAE,CAAC,eAAe,EAAC,qBAAqB,EAAC,qBAAqB,EAAC,8BAA8B,EAAC,iCAAiC,CAAC;QACxI,QAAQ,EAAE,iDAAiD;QAC3D,cAAc,EAAE,CAAC,qBAAqB,EAAC,sBAAsB,EAAC,mBAAmB,EAAC,2BAA2B,EAAC,wBAAwB,EAAC,8BAA8B,CAAC;QACtK,MAAM,EAAE,0LAA0L;QAClM,IAAI,EAAE,u4HAAu4H;KAC94H;IACD,kBAAkB,EAAE;QAClB,IAAI,EAAE,kBAAkB;QACxB,WAAW,EAAE,yLAAyL;QACtM,QAAQ,EAAE,CAAC,2BAA2B,EAAC,kBAAkB,EAAC,8CAA8C,EAAC,iBAAiB,EAAC,wBAAwB,CAAC;QACpJ,QAAQ,EAAE,+BAA+B;QACzC,cAAc,EAAE,CAAC,oBAAoB,EAAC,kBAAkB,EAAC,kBAAkB,EAAC,oBAAoB,EAAC,oBAAoB,EAAC,sBAAsB,CAAC;QAC7I,MAAM,EAAE,oLAAoL;QAC5L,IAAI,EAAE,kjHAAkjH;KACzjH;IACD,wBAAwB,EAAE;QACxB,IAAI,EAAE,wBAAwB;QAC9B,WAAW,EAAE,sTAAsT;QACnU,QAAQ,EAAE,CAAC,oBAAoB,EAAC,kCAAkC,EAAC,+BAA+B,EAAC,wBAAwB,EAAC,0BAA0B,EAAC,wBAAwB,EAAC,kCAAkC,CAAC;QACnN,QAAQ,EAAE,uEAAuE;QACjF,cAAc,EAAE,CAAC,kBAAkB,EAAC,mBAAmB,EAAC,yBAAyB,CAAC;QAClF,MAAM,EAAE,wSAAwS;QAChT,kBAAkB,EAAE,mLAAmL;QACvM,eAAe,EAAE,0KAA0K;QAC3L,IAAI,EAAE,wmRAAwmR;KAC/mR;IACD,mBAAmB,EAAE;QACnB,IAAI,EAAE,mBAAmB;QACzB,WAAW,EAAE,uMAAuM;QACpN,QAAQ,EAAE,CAAC,mBAAmB,EAAC,+BAA+B,EAAC,sBAAsB,EAAC,YAAY,EAAC,wBAAwB,CAAC;QAC5H,QAAQ,EAAE,gCAAgC;QAC1C,cAAc,EAAE,CAAC,oBAAoB,EAAC,mBAAmB,EAAC,gCAAgC,EAAC,qBAAqB,EAAC,+BAA+B,CAAC;QACjJ,MAAM,EAAE,kNAAkN;QAC1N,IAAI,EAAE,quHAAquH;KAC5uH;IACD,sBAAsB,EAAE;QACtB,IAAI,EAAE,sBAAsB;QAC5B,WAAW,EAAE,uPAAuP;QACpQ,QAAQ,EAAE,CAAC,mBAAmB,EAAC,sBAAsB,EAAC,kBAAkB,EAAC,yBAAyB,EAAC,gBAAgB,EAAC,mBAAmB,CAAC;QACxI,QAAQ,EAAE,qCAAqC;QAC/C,cAAc,EAAE,CAAC,4BAA4B,EAAC,8BAA8B,EAAC,8BAA8B,EAAC,uBAAuB,EAAC,mBAAmB,EAAC,2BAA2B,EAAC,2BAA2B,EAAC,uBAAuB,CAAC;QACxO,MAAM,EAAE,mIAAmI;QAC3I,IAAI,EAAE,i5HAAi5H;KACx5H;IACD,kBAAkB,EAAE;QAClB,IAAI,EAAE,kBAAkB;QACxB,WAAW,EAAE,6PAA6P;QAC1Q,QAAQ,EAAE,CAAC,qBAAqB,EAAC,wBAAwB,EAAC,yBAAyB,EAAC,2CAA2C,EAAC,oBAAoB,EAAC,wBAAwB,EAAC,mBAAmB,CAAC;QAClM,QAAQ,EAAE,mEAAmE;QAC7E,cAAc,EAAE,CAAC,2BAA2B,EAAC,mBAAmB,EAAC,kCAAkC,EAAC,yBAAyB,EAAC,2BAA2B,EAAC,qBAAqB,EAAC,8BAA8B,EAAC,0BAA0B,EAAC,6BAA6B,CAAC;QACxQ,MAAM,EAAE,yQAAyQ;QACjR,IAAI,EAAE,srPAAsrP;KAC7rP;CACF,CAAC;AAEF,MAAM,CAAC,MAAM,WAAW,GAA0B,CAAC,eAAe,EAAC,eAAe,EAAC,mBAAmB,EAAC,kBAAkB,EAAC,gBAAgB,EAAC,uBAAuB,EAAC,eAAe,EAAC,mBAAmB,EAAC,sBAAsB,EAAC,eAAe,EAAC,kBAAkB,EAAC,wBAAwB,EAAC,mBAAmB,EAAC,sBAAsB,EAAC,kBAAkB,CAAC,CAAC"}
+{"version":3,"file":"skills.generated.js","sourceRoot":"","sources":["../../src/skills/skills.generated.ts"],"names":[],"mappings":"AAAA,6DAA6D;AA+B7D,MAAM,CAAC,MAAM,MAAM,GAA0B;IAC3C,eAAe,EAAE;QACf,IAAI,EAAE,eAAe;QACrB,WAAW,EAAE,4WAA4W;QACzX,QAAQ,EAAE,CAAC,kBAAkB,EAAC,iBAAiB,EAAC,kBAAkB,EAAC,uCAAuC,EAAC,qBAAqB,CAAC;QACjI,QAAQ,EAAE,6BAA6B;QACvC,cAAc,EAAE,CAAC,kBAAkB,EAAC,mBAAmB,EAAC,mBAAmB,EAAC,qBAAqB,CAAC;QAClG,MAAM,EAAE,4NAA4N;QACpO,IAAI,EAAE,4iJAA4iJ;KACnjJ;IACD,eAAe,EAAE;QACf,IAAI,EAAE,eAAe;QACrB,WAAW,EAAE,sMAAsM;QACnN,QAAQ,EAAE,CAAC,kBAAkB,EAAC,wBAAwB,EAAC,gBAAgB,EAAC,mBAAmB,EAAC,mBAAmB,CAAC;QAChH,QAAQ,EAAE,0BAA0B;QACpC,cAAc,EAAE,CAAC,yBAAyB,EAAC,oBAAoB,EAAC,kBAAkB,EAAC,oBAAoB,EAAC,sBAAsB,CAAC;QAC/H,MAAM,EAAE,iLAAiL;QACzL,IAAI,EAAE,s8GAAs8G;KAC78G;IACD,mBAAmB,EAAE;QACnB,IAAI,EAAE,mBAAmB;QACzB,WAAW,EAAE,+PAA+P;QAC5Q,QAAQ,EAAE,CAAC,yBAAyB,EAAC,+BAA+B,EAAC,sBAAsB,EAAC,kBAAkB,EAAC,gCAAgC,EAAC,wBAAwB,EAAC,mBAAmB,CAAC;QAC7L,QAAQ,EAAE,0BAA0B;QACpC,cAAc,EAAE,CAAC,mBAAmB,EAAC,wBAAwB,EAAC,wBAAwB,EAAC,mBAAmB,EAAC,qBAAqB,CAAC;QACjI,MAAM,EAAE,iOAAiO;QACzO,kBAAkB,EAAE,iQAAiQ;QACrR,eAAe,EAAE,gNAAgN;QACjO,IAAI,EAAE,w1SAAw1S;KAC/1S;IACD,kBAAkB,EAAE;QAClB,IAAI,EAAE,kBAAkB;QACxB,WAAW,EAAE,+TAA+T;QAC5U,QAAQ,EAAE,CAAC,qBAAqB,EAAC,wBAAwB,EAAC,sCAAsC,EAAC,yBAAyB,EAAC,uCAAuC,EAAC,yBAAyB,CAAC;QAC7L,QAAQ,EAAE,0BAA0B;QACpC,cAAc,EAAE,CAAC,mBAAmB,EAAC,uBAAuB,EAAC,sCAAsC,EAAC,uBAAuB,EAAC,oBAAoB,CAAC;QACjJ,MAAM,EAAE,uOAAuO;QAC/O,IAAI,EAAE,ujJAAujJ;KAC9jJ;IACD,gBAAgB,EAAE;QAChB,IAAI,EAAE,gBAAgB;QACtB,WAAW,EAAE,oMAAoM;QACjN,QAAQ,EAAE,CAAC,6BAA6B,EAAC,6BAA6B,EAAC,4BAA4B,EAAC,kBAAkB,EAAC,oBAAoB,CAAC;QAC5I,QAAQ,EAAE,mEAAmE;QAC7E,cAAc,EAAE,CAAC,oBAAoB,EAAC,kBAAkB,EAAC,mBAAmB,EAAC,qBAAqB,EAAC,mBAAmB,EAAC,6BAA6B,EAAC,oBAAoB,CAAC;QAC1K,MAAM,EAAE,qLAAqL;QAC7L,IAAI,EAAE,4vHAA4vH;KACnwH;IACD,uBAAuB,EAAE;QACvB,IAAI,EAAE,uBAAuB;QAC7B,WAAW,EAAE,wRAAwR;QACrS,QAAQ,EAAE,CAAC,6BAA6B,EAAC,iCAAiC,EAAC,sBAAsB,EAAC,qCAAqC,EAAC,mCAAmC,EAAC,yCAAyC,EAAC,kDAAkD,EAAC,yCAAyC,CAAC;QACnT,QAAQ,EAAE,yEAAyE;QACnF,cAAc,EAAE,CAAC,oBAAoB,EAAC,kBAAkB,EAAC,mBAAmB,EAAC,yBAAyB,EAAC,gCAAgC,CAAC;QACxI,MAAM,EAAE,4KAA4K;QACpL,IAAI,EAAE,w4NAAw4N;KAC/4N;IACD,eAAe,EAAE;QACf,IAAI,EAAE,eAAe;QACrB,WAAW,EAAE,sVAAsV;QACnW,QAAQ,EAAE,CAAC,kBAAkB,EAAC,kBAAkB,EAAC,SAAS,EAAC,wBAAwB,EAAC,mBAAmB,EAAC,kBAAkB,EAAC,4BAA4B,CAAC;QACxJ,QAAQ,EAAE,oFAAoF;QAC9F,cAAc,EAAE,CAAC,yBAAyB,EAAC,yBAAyB,EAAC,0BAA0B,EAAC,iBAAiB,EAAC,mBAAmB,EAAC,kBAAkB,EAAC,kBAAkB,EAAC,4BAA4B,EAAC,0BAA0B,CAAC;QACpO,MAAM,EAAE,iUAAiU;QACzU,IAAI,EAAE,0qdAA0qd;KACjrd;IACD,mBAAmB,EAAE;QACnB,IAAI,EAAE,mBAAmB;QACzB,WAAW,EAAE,uTAAuT;QACpU,QAAQ,EAAE,CAAC,mBAAmB,EAAC,wCAAwC,EAAC,sBAAsB,EAAC,iBAAiB,EAAC,0BAA0B,EAAC,6BAA6B,EAAC,wBAAwB,EAAC,0BAA0B,CAAC;QAC9N,QAAQ,EAAE,qEAAqE;QAC/E,cAAc,EAAE,CAAC,4BAA4B,EAAC,0BAA0B,EAAC,oBAAoB,EAAC,sBAAsB,EAAC,qBAAqB,EAAC,sBAAsB,EAAC,qBAAqB,EAAC,yBAAyB,EAAC,wBAAwB,EAAC,gCAAgC,CAAC;QAC5Q,MAAM,EAAE,6OAA6O;QACrP,IAAI,EAAE,muKAAmuK;KAC1uK;IACD,sBAAsB,EAAE;QACtB,IAAI,EAAE,sBAAsB;QAC5B,WAAW,EAAE,+SAA+S;QAC5T,QAAQ,EAAE,CAAC,qBAAqB,EAAC,6BAA6B,EAAC,+BAA+B,EAAC,6BAA6B,EAAC,wBAAwB,EAAC,uBAAuB,CAAC;QAC9K,QAAQ,EAAE,8BAA8B;QACxC,cAAc,EAAE,CAAC,yBAAyB,EAAC,wBAAwB,EAAC,gCAAgC,CAAC;QACrG,MAAM,EAAE,sMAAsM;QAC9M,eAAe,EAAE,mEAAmE;QACpF,IAAI,EAAE,miCAAmiC;KAC1iC;IACD,eAAe,EAAE;QACf,IAAI,EAAE,eAAe;QACrB,WAAW,EAAE,8NAA8N;QAC3O,QAAQ,EAAE,CAAC,eAAe,EAAC,qBAAqB,EAAC,qBAAqB,EAAC,8BAA8B,EAAC,iCAAiC,CAAC;QACxI,QAAQ,EAAE,iDAAiD;QAC3D,cAAc,EAAE,CAAC,qBAAqB,EAAC,sBAAsB,EAAC,mBAAmB,EAAC,2BAA2B,EAAC,wBAAwB,EAAC,8BAA8B,CAAC;QACtK,MAAM,EAAE,0LAA0L;QAClM,IAAI,EAAE,u4HAAu4H;KAC94H;IACD,YAAY,EAAE;QACZ,IAAI,EAAE,YAAY;QAClB,WAAW,EAAE,oMAAoM;QACjN,QAAQ,EAAE,CAAC,sBAAsB,EAAC,UAAU,EAAC,oBAAoB,EAAC,oBAAoB,EAAC,sBAAsB,EAAC,qBAAqB,EAAC,6BAA6B,CAAC;QAClK,QAAQ,EAAE,uDAAuD;QACjE,cAAc,EAAE,CAAC,eAAe,EAAC,kBAAkB,EAAC,oBAAoB,EAAC,mBAAmB,EAAC,2BAA2B,CAAC;QACzH,MAAM,EAAE,8HAA8H;QACtI,IAAI,EAAE,2/GAA2/G;KAClgH;IACD,kBAAkB,EAAE;QAClB,IAAI,EAAE,kBAAkB;QACxB,WAAW,EAAE,yLAAyL;QACtM,QAAQ,EAAE,CAAC,2BAA2B,EAAC,kBAAkB,EAAC,8CAA8C,EAAC,iBAAiB,EAAC,wBAAwB,CAAC;QACpJ,QAAQ,EAAE,+BAA+B;QACzC,cAAc,EAAE,CAAC,oBAAoB,EAAC,kBAAkB,EAAC,kBAAkB,EAAC,oBAAoB,EAAC,oBAAoB,EAAC,sBAAsB,CAAC;QAC7I,MAAM,EAAE,oLAAoL;QAC5L,IAAI,EAAE,kjHAAkjH;KACzjH;IACD,wBAAwB,EAAE;QACxB,IAAI,EAAE,wBAAwB;QAC9B,WAAW,EAAE,sTAAsT;QACnU,QAAQ,EAAE,CAAC,oBAAoB,EAAC,kCAAkC,EAAC,+BAA+B,EAAC,wBAAwB,EAAC,0BAA0B,EAAC,wBAAwB,EAAC,kCAAkC,CAAC;QACnN,QAAQ,EAAE,uEAAuE;QACjF,cAAc,EAAE,CAAC,kBAAkB,EAAC,mBAAmB,EAAC,yBAAyB,CAAC;QAClF,MAAM,EAAE,wSAAwS;QAChT,kBAAkB,EAAE,mLAAmL;QACvM,eAAe,EAAE,0KAA0K;QAC3L,IAAI,EAAE,+lRAA+lR;KACtmR;IACD,mBAAmB,EAAE;QACnB,IAAI,EAAE,mBAAmB;QACzB,WAAW,EAAE,yNAAyN;QACtO,QAAQ,EAAE,CAAC,mBAAmB,EAAC,+BAA+B,EAAC,sBAAsB,EAAC,YAAY,EAAC,qBAAqB,EAAC,wBAAwB,CAAC;QAClJ,QAAQ,EAAE,gCAAgC;QAC1C,cAAc,EAAE,CAAC,oBAAoB,EAAC,mBAAmB,EAAC,gCAAgC,EAAC,qBAAqB,EAAC,+BAA+B,CAAC;QACjJ,MAAM,EAAE,oOAAoO;QAC5O,IAAI,EAAE,+hIAA+hI;KACtiI;IACD,sBAAsB,EAAE;QACtB,IAAI,EAAE,sBAAsB;QAC5B,WAAW,EAAE,uPAAuP;QACpQ,QAAQ,EAAE,CAAC,mBAAmB,EAAC,sBAAsB,EAAC,kBAAkB,EAAC,yBAAyB,EAAC,gBAAgB,EAAC,mBAAmB,CAAC;QACxI,QAAQ,EAAE,qCAAqC;QAC/C,cAAc,EAAE,CAAC,4BAA4B,EAAC,8BAA8B,EAAC,8BAA8B,EAAC,uBAAuB,EAAC,mBAAmB,EAAC,2BAA2B,EAAC,2BAA2B,EAAC,uBAAuB,CAAC;QACxO,MAAM,EAAE,mIAAmI;QAC3I,IAAI,EAAE,o4HAAo4H;KAC34H;IACD,kBAAkB,EAAE;QAClB,IAAI,EAAE,kBAAkB;QACxB,WAAW,EAAE,6PAA6P;QAC1Q,QAAQ,EAAE,CAAC,qBAAqB,EAAC,wBAAwB,EAAC,yBAAyB,EAAC,2CAA2C,EAAC,oBAAoB,EAAC,wBAAwB,EAAC,mBAAmB,CAAC;QAClM,QAAQ,EAAE,mEAAmE;QAC7E,cAAc,EAAE,CAAC,2BAA2B,EAAC,mBAAmB,EAAC,kCAAkC,EAAC,yBAAyB,EAAC,2BAA2B,EAAC,qBAAqB,EAAC,8BAA8B,EAAC,0BAA0B,EAAC,6BAA6B,CAAC;QACxQ,MAAM,EAAE,yQAAyQ;QACjR,IAAI,EAAE,4qPAA4qP;KACnrP;CACF,CAAC;AAEF,MAAM,CAAC,MAAM,WAAW,GAA0B,CAAC,eAAe,EAAC,eAAe,EAAC,mBAAmB,EAAC,kBAAkB,EAAC,gBAAgB,EAAC,uBAAuB,EAAC,eAAe,EAAC,mBAAmB,EAAC,sBAAsB,EAAC,eAAe,EAAC,YAAY,EAAC,kBAAkB,EAAC,wBAAwB,EAAC,mBAAmB,EAAC,sBAAsB,EAAC,kBAAkB,CAAC,CAAC"}

package/dist/tools/agent-identity.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"agent-identity.d.ts","sourceRoot":"","sources":["../../src/tools/agent-identity.ts"],"names":[],"mappings":"AAEA;;;;;;;;;;;;;;;;;;;GAmBG;AAEH,OAAO,EAAE,UAAU,EAAE,MAAM,mBAAmB,CAAC;AAa/C,OAAO,EAAE,cAAc,EAAE,YAAY,EAAc,MAAM,YAAY,CAAC;AAEtE,qBAAa,kBAAkB;IAC7B,OAAO,CAAC,IAAI,CAAa;gBAEb,IAAI,EAAE,UAAU;IAI5B,QAAQ,IAAI,KAAK,CAAC;QAAE,UAAU,EAAE,cAAc,CAAC;QAAC,QAAQ,EAAE,YAAY,CAAA;KAAE,CAAC;YA0G3D,cAAc;YAmCd,UAAU;YAsEV,YAAY;YAmCZ,WAAW;YA8BX,WAAW;CAgD1B"}
+{"version":3,"file":"agent-identity.d.ts","sourceRoot":"","sources":["../../src/tools/agent-identity.ts"],"names":[],"mappings":"AAEA;;;;;;;;;;;;;;;;;;;GAmBG;AAEH,OAAO,EAAE,UAAU,EAAE,MAAM,mBAAmB,CAAC;AAa/C,OAAO,EAAE,cAAc,EAAE,YAAY,EAAc,MAAM,YAAY,CAAC;AAEtE,qBAAa,kBAAkB;IAC7B,OAAO,CAAC,IAAI,CAAa;gBAEb,IAAI,EAAE,UAAU;IAI5B,QAAQ,IAAI,KAAK,CAAC;QAAE,UAAU,EAAE,cAAc,CAAC;QAAC,QAAQ,EAAE,YAAY,CAAA;KAAE,CAAC;YA2G3D,cAAc;YAmCd,UAAU;YAsEV,YAAY;YAmCZ,WAAW;YA8BX,WAAW;CAgD1B"}

package/dist/tools/agent-identity.js

@@ -86,7 +86,8 @@ export class AgentIdentityTools {
                     scope: "write:agent_identity",
                     audiences: ["stdio", "http", "public"],
                     tier: "read",
-                    description: "List agent_action_log rows whose grant's identity you own — your own provenance-stamped agent writes, sorted newest first. Optionally narrow by agent_identity_id or agent_grant_id. Paginated (default 50, max 500 per call). Session-auth only.",
+                    description: "List agent write records whose grant's identity you own — your own provenance-stamped agent writes, sorted newest first. Optionally narrow by agent_identity_id or agent_grant_id. Paginated (default 50, max 500 per call). Session-auth only. " +
+                        "For the grants themselves rather than what they did, use pica_list_my_agent_grants.",
                     workflows: "infrastructure",
                     vernacular_kind: "specialist",
                     vernacular_reason: "Specialist context; not yet covered by the Creator Question Atlas — pending telemetry-driven addition per ADR-226 Phase 4 substrate writes.",

package/dist/tools/agent-identity.js.map

@@ -1 +1 @@
-{"version":3,"file":"agent-identity.js","sourceRoot":"","sources":["../../src/tools/agent-identity.ts"],"names":[],"mappings":"AAAA,6DAA6D;AAwB7D,OAAO,EACL,sCAAsC,EACtC,8BAA8B,EAC9B,kCAAkC,EAClC,0BAA0B,EAC1B,qCAAqC,EACrC,6BAA6B,EAC7B,mCAAmC,EACnC,2BAA2B,EAC3B,mCAAmC,EACnC,2BAA2B,GAC5B,MAAM,qBAAqB,CAAC;AAG7B,MAAM,OAAO,kBAAkB;IACrB,IAAI,CAAa;IAEzB,YAAY,IAAgB;QAC1B,IAAI,CAAC,IAAI,GAAG,IAAI,CAAC;IACnB,CAAC;IAED,QAAQ;QACN,OAAO;YACL;gBACE,UAAU,EAAE;oBACV,IAAI,EAAE,4BAA4B;oBAClC,KAAK,EAAE,sBAAsB;oBAC7B,SAAS,EAAE,CAAC,OAAO,EAAE,MAAM,EAAE,QAAQ,CAAC;oBACtC,IAAI,EAAE,OAAO;oBACb,WAAW,EACT,mOAAmO;oBACrO,SAAS,EAAE,gBAAgB;oBAC3B,eAAe,EAAE,YAAY;oBAC7B,iBAAiB,EACf,6IAA6I;oBAC/I,WAAW,EAAE;wBACX,IAAI,EAAE,QAAQ;wBACd,UAAU,EAAE,sCAAsC;wBAClD,QAAQ,EAAE,8BAA8B;qBACzC;iBACF;gBACD,QAAQ,EAAE,IAAI,CAAC,cAAc,CAAC,IAAI,CAAC,IAAI,CAAC;aACzC;YACD;gBACE,UAAU,EAAE;oBACV,IAAI,EAAE,wBAAwB;oBAC9B,KAAK,EAAE,sBAAsB;oBAC7B,SAAS,EAAE,CAAC,OAAO,EAAE,MAAM,EAAE,QAAQ,CAAC;oBACtC,IAAI,EAAE,OAAO;oBACb,WAAW,EACT,wNAAwN;wBACxN,mTAAmT;oBACrT,SAAS,EAAE,gBAAgB;oBAC3B,eAAe,EAAE,YAAY;oBAC7B,iBAAiB,EACf,6IAA6I;oBAC/I,WAAW,EAAE;wBACX,IAAI,EAAE,QAAQ;wBACd,UAAU,EAAE,kCAAkC;wBAC9C,QAAQ,EAAE,0BAA0B;qBACrC;iBACF;gBACD,QAAQ,EAAE,IAAI,CAAC,UAAU,CAAC,IAAI,CAAC,IAAI,CAAC;aACrC;YACD;gBACE,UAAU,EAAE;oBACV,IAAI,EAAE,2BAA2B;oBACjC,KAAK,EAAE,sBAAsB;oBAC7B,SAAS,EAAE,CAAC,OAAO,EAAE,MAAM,EAAE,QAAQ,CAAC;oBACtC,IAAI,EAAE,MAAM;oBACZ,WAAW,EACT,6HAA6H;oBAC/H,SAAS,EAAE,gBAAgB;oBAC3B,eAAe,EAAE,YAAY;oBAC7B,iBAAiB,EACf,6IAA6I;oBAC/I,WAAW,EAAE;wBACX,IAAI,EAAE,QAAQ;wBACd,UAAU,EAAE,qCAAqC;wBACjD,QAAQ,EAAE,6BAA6B;qBACxC;iBACF;gBACD,QAAQ,EAAE,IAAI,CAAC,YAAY,CAAC,IAAI,CAAC,IAAI,CAAC;aACvC;YACD;gBACE,UAAU,EAAE;oBACV,IAAI,EAAE,yBAAyB;oBAC/B,KAAK,EAAE,sBAAsB;oBAC7B,SAAS,EAAE,CAAC,OAAO,EAAE,MAAM,EAAE,QAAQ,CAAC;oBACtC,IAAI,EAAE,aAAa;oBACnB,WAAW,EACT,oLAAoL;oBACtL,SAAS,EAAE,gBAAgB;oBAC3B,eAAe,EAAE,YAAY;oBAC7B,iBAAiB,EACf,qGAAqG;oBACvG,WAAW,EAAE;wBACX,IAAI,EAAE,QAAQ;wBACd,UAAU,EAAE,mCAAmC;wBAC/C,QAAQ,EAAE,2BAA2B;qBACtC;iBACF;gBACD,QAAQ,EAAE,IAAI,CAAC,WAAW,CAAC,IAAI,CAAC,IAAI,CAAC;aACtC;YACD;gBACE,UAAU,EAAE;oBACV,IAAI,EAAE,yBAAyB;oBAC/B,KAAK,EAAE,sBAAsB;oBAC7B,SAAS,EAAE,CAAC,OAAO,EAAE,MAAM,EAAE,QAAQ,CAAC;oBACtC,IAAI,EAAE,MAAM;oBACZ,WAAW,EACT,mPAAmP;oBACrP,SAAS,EAAE,gBAAgB;oBAC3B,eAAe,EAAE,YAAY;oBAC7B,iBAAiB,EACf,6IAA6I;oBAC/I,WAAW,EAAE;wBACX,IAAI,EAAE,QAAQ;wBACd,UAAU,EAAE,mCAAmC;wBAC/C,QAAQ,EAAE,2BAA2B;qBACtC;iBACF;gBACD,QAAQ,EAAE,IAAI,CAAC,WAAW,CAAC,IAAI,CAAC,IAAI,CAAC;aACtC;SACF,CAAC;IACJ,CAAC;IAEO,KAAK,CAAC,cAAc,CAAC,IAAyB;QACpD,MAAM,WAAW,GACf,OAAO,IAAI,CAAC,YAAY,KAAK,QAAQ,CAAC,CAAC,CAAC,IAAI,CAAC,YAAY,CAAC,IAAI,EAAE,CAAC,CAAC,CAAC,EAAE,CAAC;QACxE,IAAI,CAAC,WAAW,EAAE,CAAC;YACjB,OAAO;gBACL,OAAO,EAAE,CAAC,EAAE,IAAI,EAAE,MAAM,EAAE,IAAI,EAAE,kCAAkC,EAAE,CAAC;gBACrE,OAAO,EAAE,IAAI;aACd,CAAC;QACJ,CAAC;QACD,MAAM,iBAAiB,GACrB,OAAO,IAAI,CAAC,kBAAkB,KAAK,QAAQ;YAC3C,IAAI,CAAC,kBAAkB,CAAC,IAAI,EAAE;YAC5B,CAAC,CAAC,IAAI,CAAC,kBAAkB,CAAC,IAAI,EAAE;YAChC,CAAC,CAAC,IAAI,CAAC;QAEX,MAAM,MAAM,GAAG,MAAM,IAAI,CAAC,IAAI,CAAC,aAAa,CAAC,cAAc,CAAC;YAC1D,WAAW;YACX,iBAAiB;SAClB,CAAC,CAAC;QACH,MAAM,IAAI,GAAG,MAAM,EAAE,IAAI,IAAI,MAAM,CAAC;QACpC,OAAO;YACL,OAAO,EAAE;gBACP;oBACE,IAAI,EAAE,MAAM;oBACZ,IAAI,EAAE,4BAA4B,WAAW,UAAU,IAAI,EAAE,EAAE,IAAI,SAAS,iEAAiE;iBAC9I;aACF;YACD,iBAAiB,EAAE;gBACjB,IAAI,EAAE,kCAAkC;gBACxC,OAAO,EAAE,CAAC;gBACV,IAAI;aACL;SACF,CAAC;IACJ,CAAC;IAEO,KAAK,CAAC,UAAU,CAAC,IAAyB;QAChD,MAAM,eAAe,GACnB,OAAO,IAAI,CAAC,iBAAiB,KAAK,QAAQ;YACxC,CAAC,CAAC,IAAI,CAAC,iBAAiB,CAAC,IAAI,EAAE;YAC/B,CAAC,CAAC,EAAE,CAAC;QACT,IAAI,CAAC,eAAe,EAAE,CAAC;YACrB,OAAO;gBACL,OAAO,EAAE;oBACP,EAAE,IAAI,EAAE,MAAM,EAAE,IAAI,EAAE,uCAAuC,EAAE;iBAChE;gBACD,OAAO,EAAE,IAAI;aACd,CAAC;QACJ,CAAC;QACD,IAAI,CAAC,KAAK,CAAC,OAAO,CAAC,IAAI,CAAC,MAAM,CAAC,IAAI,IAAI,CAAC,MAAM,CAAC,MAAM,KAAK,CAAC,EAAE,CAAC;YAC5D,OAAO;gBACL,OAAO,EAAE;oBACP;wBACE,IAAI,EAAE,MAAM;wBACZ,IAAI,EAAE,qDAAqD;qBAC5D;iBACF;gBACD,OAAO,EAAE,IAAI;aACd,CAAC;QACJ,CAAC;QACD,MAAM,MAAM,GAAG,IAAI,CAAC,MAAM,CAAC,MAAM,CAC/B,CAAC,CAAU,EAAE,EAAE,CAAC,OAAO,CAAC,KAAK,QAAQ,CAC1B,CAAC;QACd,IAAI,MAAM,CAAC,MAAM,KAAK,IAAI,CAAC,MAAM,CAAC,MAAM,EAAE,CAAC;YACzC,OAAO;gBACL,OAAO,EAAE,CAAC,EAAE,IAAI,EAAE,MAAM,EAAE,IAAI,EAAE,gCAAgC,EAAE,CAAC;gBACnE,OAAO,EAAE,IAAI;aACd,CAAC;QACJ,CAAC;QACD,MAAM,SAAS,GACb,OAAO,IAAI,CAAC,UAAU,KAAK,QAAQ,IAAI,IAAI,CAAC,UAAU,CAAC,IAAI,EAAE;YAC3D,CAAC,CAAC,IAAI,CAAC,UAAU;YACjB,CAAC,CAAC,IAAI,CAAC;QAEX,MAAM,MAAM,GAAG,MAAM,IAAI,CAAC,IAAI,CAAC,aAAa,CAAC,UAAU,CAAC;YACtD,eAAe;YACf,MAAM;YACN,SAAS;SACV,CAAC,CAAC;QACH,MAAM,IAAI,GAAG,MAAM,EAAE,IAAI,IAAI,MAAM,CAAC;QAEpC,gEAAgE;QAChE,8DAA8D;QAC9D,gEAAgE;QAChE,mBAAmB;QACnB,OAAO;YACL,OAAO,EAAE;gBACP;oBACE,IAAI,EAAE,MAAM;oBACZ,IAAI,EACF,qBAAqB,IAAI,EAAE,EAAE,IAAI,SAAS,KAAK;wBAC/C,YAAY,IAAI,EAAE,UAAU,IAAI,KAAK,IAAI;wBACzC,WAAW,MAAM,CAAC,IAAI,CAAC,IAAI,CAAC,OAAO;wBACnC,gBAAgB,IAAI,EAAE,WAAW,IAAI,EAAE,MAAM;wBAC7C,oDAAoD;wBACpD,8DAA8D;iBACjE;aACF;YACD,iBAAiB,EAAE;gBACjB,IAAI,EAAE,8BAA8B;gBACpC,OAAO,EAAE,CAAC;gBACV,IAAI;aACL;SACF,CAAC;IACJ,CAAC;IAEO,KAAK,CAAC,YAAY,CAAC,KAA0B;QACnD,MAAM,MAAM,GAAG,MAAM,IAAI,CAAC,IAAI,CAAC,aAAa,CAAC,YAAY,EAAE,CAAC;QAC5D,MAAM,IAAI,GAAG,MAAM,EAAE,IAAI,IAAI,MAAM,CAAC;QACpC,MAAM,IAAI,GAAG,KAAK,CAAC,OAAO,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC,IAAI,CAAC,CAAC,CAAC,EAAE,CAAC;QAC7C,MAAM,KAAK,GAAG,IAAI,CAAC,MAAM;YACvB,CAAC,CAAC,IAAI;iBACD,GAAG,CAAC,CAAC,GAAQ,EAAE,EAAE;gBAChB,MAAM,IAAI,GAAG,GAAG,EAAE,QAAQ,EAAE,YAAY,IAAI,SAAS,CAAC;gBACtD,MAAM,MAAM,GAAG,KAAK,CAAC,OAAO,CAAC,GAAG,EAAE,MAAM,CAAC;oBACvC,CAAC,CAAC,GAAG,CAAC,MAAM,CAAC,IAAI,CAAC,IAAI,CAAC;oBACvB,CAAC,CAAC,EAAE,CAAC;gBACP,MAAM,MAAM,GAAG,GAAG,EAAE,UAAU;oBAC5B,CAAC,CAAC,WAAW,GAAG,CAAC,UAAU,EAAE;oBAC7B,CAAC,CAAC,WAAW,CAAC;gBAChB,MAAM,OAAO,GAAG,GAAG,EAAE,UAAU,CAAC,CAAC,CAAC,YAAY,CAAC,CAAC,CAAC,EAAE,CAAC;gBACpD,OAAO,KAAK,IAAI,KAAK,GAAG,EAAE,EAAE,IAAI,SAAS,MAAM,MAAM,KAAK,MAAM,GAAG,OAAO,EAAE,CAAC;YAC/E,CAAC,CAAC;iBACD,IAAI,CAAC,IAAI,CAAC;YACf,CAAC,CAAC,aAAa,CAAC;QAElB,OAAO;YACL,OAAO,EAAE;gBACP;oBACE,IAAI,EAAE,MAAM;oBACZ,IAAI,EAAE,sBAAsB,IAAI,CAAC,MAAM,OAAO,KAAK,EAAE;iBACtD;aACF;YACD,iBAAiB,EAAE;gBACjB,IAAI,EAAE,6BAA6B;gBACnC,OAAO,EAAE,CAAC;gBACV,IAAI,EAAE,IAAI;aACX;SACF,CAAC;IACJ,CAAC;IAEO,KAAK,CAAC,WAAW,CAAC,IAAyB;QACjD,MAAM,OAAO,GACX,OAAO,IAAI,CAAC,QAAQ,KAAK,QAAQ,CAAC,CAAC,CAAC,IAAI,CAAC,QAAQ,CAAC,IAAI,EAAE,CAAC,CAAC,CAAC,EAAE,CAAC;QAChE,IAAI,CAAC,OAAO,EAAE,CAAC;YACb,OAAO;gBACL,OAAO,EAAE,CAAC,EAAE,IAAI,EAAE,MAAM,EAAE,IAAI,EAAE,8BAA8B,EAAE,CAAC;gBACjE,OAAO,EAAE,IAAI;aACd,CAAC;QACJ,CAAC;QAED,MAAM,MAAM,GAAG,MAAM,IAAI,CAAC,IAAI,CAAC,aAAa,CAAC,WAAW,CAAC,EAAE,OAAO,EAAE,CAAC,CAAC;QACtE,MAAM,IAAI,GAAG,MAAM,EAAE,IAAI,IAAI,MAAM,CAAC;QACpC,OAAO;YACL,OAAO,EAAE;gBACP;oBACE,IAAI,EAAE,MAAM;oBACZ,IAAI,EACF,SAAS,IAAI,EAAE,EAAE,IAAI,OAAO,eAAe,IAAI,EAAE,UAAU,IAAI,KAAK,IAAI;wBACxE,6DAA6D;wBAC7D,oBAAoB;iBACvB;aACF;YACD,iBAAiB,EAAE;gBACjB,IAAI,EAAE,+BAA+B;gBACrC,OAAO,EAAE,CAAC;gBACV,IAAI;aACL;SACF,CAAC;IACJ,CAAC;IAEO,KAAK,CAAC,WAAW,CAAC,IAAyB;QACjD,MAAM,eAAe,GACnB,OAAO,IAAI,CAAC,iBAAiB,KAAK,QAAQ;YAC1C,IAAI,CAAC,iBAAiB,CAAC,IAAI,EAAE;YAC3B,CAAC,CAAC,IAAI,CAAC,iBAAiB,CAAC,IAAI,EAAE;YAC/B,CAAC,CAAC,IAAI,CAAC;QACX,MAAM,YAAY,GAChB,OAAO,IAAI,CAAC,cAAc,KAAK,QAAQ,IAAI,IAAI,CAAC,cAAc,CAAC,IAAI,EAAE;YACnE,CAAC,CAAC,IAAI,CAAC,cAAc,CAAC,IAAI,EAAE;YAC5B,CAAC,CAAC,IAAI,CAAC;QACX,MAAM,KAAK,GAAG,OAAO,IAAI,CAAC,KAAK,KAAK,QAAQ,CAAC,CAAC,CAAC,IAAI,CAAC,KAAK,CAAC,CAAC,CAAC,SAAS,CAAC;QACtE,MAAM,MAAM,GAAG,OAAO,IAAI,CAAC,MAAM,KAAK,QAAQ,CAAC,CAAC,CAAC,IAAI,CAAC,MAAM,CAAC,CAAC,CAAC,SAAS,CAAC;QAEzE,MAAM,MAAM,GAAG,MAAM,IAAI,CAAC,IAAI,CAAC,aAAa,CAAC,WAAW,CAAC;YACvD,eAAe;YACf,YAAY;YACZ,KAAK;YACL,MAAM;SACP,CAAC,CAAC;QACH,MAAM,IAAI,GAAG,MAAM,EAAE,IAAI,IAAI,MAAM,CAAC;QACpC,MAAM,IAAI,GAAG,KAAK,CAAC,OAAO,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC,IAAI,CAAC,CAAC,CAAC,EAAE,CAAC;QAC7C,MAAM,KAAK,GAAG,IAAI,CAAC,MAAM;YACvB,CAAC,CAAC,IAAI;iBACD,GAAG,CAAC,CAAC,GAAQ,EAAE,EAAE;gBAChB,MAAM,IAAI,GAAG,GAAG,EAAE,KAAK,EAAE,QAAQ,EAAE,YAAY,IAAI,SAAS,CAAC;gBAC7D,MAAM,MAAM,GAAG,GAAG,EAAE,MAAM,IAAI,GAAG,CAAC;gBAClC,MAAM,KAAK,GAAG,GAAG,EAAE,YAAY,IAAI,GAAG,CAAC;gBACvC,MAAM,IAAI,GAAG,GAAG,EAAE,SAAS,IAAI,GAAG,CAAC;gBACnC,MAAM,IAAI,GAAG,GAAG,EAAE,UAAU,IAAI,EAAE,CAAC;gBACnC,OAAO,KAAK,IAAI,KAAK,IAAI,KAAK,MAAM,IAAI,KAAK,QAAQ,IAAI,EAAE,CAAC;YAC9D,CAAC,CAAC;iBACD,IAAI,CAAC,IAAI,CAAC;YACf,CAAC,CAAC,yEAAyE,CAAC;QAE9E,OAAO;YACL,OAAO,EAAE;gBACP;oBACE,IAAI,EAAE,MAAM;oBACZ,IAAI,EAAE,wBAAwB,IAAI,CAAC,MAAM,OAAO,KAAK,EAAE;iBACxD;aACF;YACD,iBAAiB,EAAE;gBACjB,IAAI,EAAE,0BAA0B;gBAChC,OAAO,EAAE,CAAC;gBACV,IAAI,EAAE,IAAI;aACX;SACF,CAAC;IACJ,CAAC;CACF"}
+{"version":3,"file":"agent-identity.js","sourceRoot":"","sources":["../../src/tools/agent-identity.ts"],"names":[],"mappings":"AAAA,6DAA6D;AAwB7D,OAAO,EACL,sCAAsC,EACtC,8BAA8B,EAC9B,kCAAkC,EAClC,0BAA0B,EAC1B,qCAAqC,EACrC,6BAA6B,EAC7B,mCAAmC,EACnC,2BAA2B,EAC3B,mCAAmC,EACnC,2BAA2B,GAC5B,MAAM,qBAAqB,CAAC;AAG7B,MAAM,OAAO,kBAAkB;IACrB,IAAI,CAAa;IAEzB,YAAY,IAAgB;QAC1B,IAAI,CAAC,IAAI,GAAG,IAAI,CAAC;IACnB,CAAC;IAED,QAAQ;QACN,OAAO;YACL;gBACE,UAAU,EAAE;oBACV,IAAI,EAAE,4BAA4B;oBAClC,KAAK,EAAE,sBAAsB;oBAC7B,SAAS,EAAE,CAAC,OAAO,EAAE,MAAM,EAAE,QAAQ,CAAC;oBACtC,IAAI,EAAE,OAAO;oBACb,WAAW,EACT,mOAAmO;oBACrO,SAAS,EAAE,gBAAgB;oBAC3B,eAAe,EAAE,YAAY;oBAC7B,iBAAiB,EACf,6IAA6I;oBAC/I,WAAW,EAAE;wBACX,IAAI,EAAE,QAAQ;wBACd,UAAU,EAAE,sCAAsC;wBAClD,QAAQ,EAAE,8BAA8B;qBACzC;iBACF;gBACD,QAAQ,EAAE,IAAI,CAAC,cAAc,CAAC,IAAI,CAAC,IAAI,CAAC;aACzC;YACD;gBACE,UAAU,EAAE;oBACV,IAAI,EAAE,wBAAwB;oBAC9B,KAAK,EAAE,sBAAsB;oBAC7B,SAAS,EAAE,CAAC,OAAO,EAAE,MAAM,EAAE,QAAQ,CAAC;oBACtC,IAAI,EAAE,OAAO;oBACb,WAAW,EACT,wNAAwN;wBACxN,mTAAmT;oBACrT,SAAS,EAAE,gBAAgB;oBAC3B,eAAe,EAAE,YAAY;oBAC7B,iBAAiB,EACf,6IAA6I;oBAC/I,WAAW,EAAE;wBACX,IAAI,EAAE,QAAQ;wBACd,UAAU,EAAE,kCAAkC;wBAC9C,QAAQ,EAAE,0BAA0B;qBACrC;iBACF;gBACD,QAAQ,EAAE,IAAI,CAAC,UAAU,CAAC,IAAI,CAAC,IAAI,CAAC;aACrC;YACD;gBACE,UAAU,EAAE;oBACV,IAAI,EAAE,2BAA2B;oBACjC,KAAK,EAAE,sBAAsB;oBAC7B,SAAS,EAAE,CAAC,OAAO,EAAE,MAAM,EAAE,QAAQ,CAAC;oBACtC,IAAI,EAAE,MAAM;oBACZ,WAAW,EACT,6HAA6H;oBAC/H,SAAS,EAAE,gBAAgB;oBAC3B,eAAe,EAAE,YAAY;oBAC7B,iBAAiB,EACf,6IAA6I;oBAC/I,WAAW,EAAE;wBACX,IAAI,EAAE,QAAQ;wBACd,UAAU,EAAE,qCAAqC;wBACjD,QAAQ,EAAE,6BAA6B;qBACxC;iBACF;gBACD,QAAQ,EAAE,IAAI,CAAC,YAAY,CAAC,IAAI,CAAC,IAAI,CAAC;aACvC;YACD;gBACE,UAAU,EAAE;oBACV,IAAI,EAAE,yBAAyB;oBAC/B,KAAK,EAAE,sBAAsB;oBAC7B,SAAS,EAAE,CAAC,OAAO,EAAE,MAAM,EAAE,QAAQ,CAAC;oBACtC,IAAI,EAAE,aAAa;oBACnB,WAAW,EACT,oLAAoL;oBACtL,SAAS,EAAE,gBAAgB;oBAC3B,eAAe,EAAE,YAAY;oBAC7B,iBAAiB,EACf,qGAAqG;oBACvG,WAAW,EAAE;wBACX,IAAI,EAAE,QAAQ;wBACd,UAAU,EAAE,mCAAmC;wBAC/C,QAAQ,EAAE,2BAA2B;qBACtC;iBACF;gBACD,QAAQ,EAAE,IAAI,CAAC,WAAW,CAAC,IAAI,CAAC,IAAI,CAAC;aACtC;YACD;gBACE,UAAU,EAAE;oBACV,IAAI,EAAE,yBAAyB;oBAC/B,KAAK,EAAE,sBAAsB;oBAC7B,SAAS,EAAE,CAAC,OAAO,EAAE,MAAM,EAAE,QAAQ,CAAC;oBACtC,IAAI,EAAE,MAAM;oBACZ,WAAW,EACT,kPAAkP;wBAClP,qFAAqF;oBACvF,SAAS,EAAE,gBAAgB;oBAC3B,eAAe,EAAE,YAAY;oBAC7B,iBAAiB,EACf,6IAA6I;oBAC/I,WAAW,EAAE;wBACX,IAAI,EAAE,QAAQ;wBACd,UAAU,EAAE,mCAAmC;wBAC/C,QAAQ,EAAE,2BAA2B;qBACtC;iBACF;gBACD,QAAQ,EAAE,IAAI,CAAC,WAAW,CAAC,IAAI,CAAC,IAAI,CAAC;aACtC;SACF,CAAC;IACJ,CAAC;IAEO,KAAK,CAAC,cAAc,CAAC,IAAyB;QACpD,MAAM,WAAW,GACf,OAAO,IAAI,CAAC,YAAY,KAAK,QAAQ,CAAC,CAAC,CAAC,IAAI,CAAC,YAAY,CAAC,IAAI,EAAE,CAAC,CAAC,CAAC,EAAE,CAAC;QACxE,IAAI,CAAC,WAAW,EAAE,CAAC;YACjB,OAAO;gBACL,OAAO,EAAE,CAAC,EAAE,IAAI,EAAE,MAAM,EAAE,IAAI,EAAE,kCAAkC,EAAE,CAAC;gBACrE,OAAO,EAAE,IAAI;aACd,CAAC;QACJ,CAAC;QACD,MAAM,iBAAiB,GACrB,OAAO,IAAI,CAAC,kBAAkB,KAAK,QAAQ;YAC3C,IAAI,CAAC,kBAAkB,CAAC,IAAI,EAAE;YAC5B,CAAC,CAAC,IAAI,CAAC,kBAAkB,CAAC,IAAI,EAAE;YAChC,CAAC,CAAC,IAAI,CAAC;QAEX,MAAM,MAAM,GAAG,MAAM,IAAI,CAAC,IAAI,CAAC,aAAa,CAAC,cAAc,CAAC;YAC1D,WAAW;YACX,iBAAiB;SAClB,CAAC,CAAC;QACH,MAAM,IAAI,GAAG,MAAM,EAAE,IAAI,IAAI,MAAM,CAAC;QACpC,OAAO;YACL,OAAO,EAAE;gBACP;oBACE,IAAI,EAAE,MAAM;oBACZ,IAAI,EAAE,4BAA4B,WAAW,UAAU,IAAI,EAAE,EAAE,IAAI,SAAS,iEAAiE;iBAC9I;aACF;YACD,iBAAiB,EAAE;gBACjB,IAAI,EAAE,kCAAkC;gBACxC,OAAO,EAAE,CAAC;gBACV,IAAI;aACL;SACF,CAAC;IACJ,CAAC;IAEO,KAAK,CAAC,UAAU,CAAC,IAAyB;QAChD,MAAM,eAAe,GACnB,OAAO,IAAI,CAAC,iBAAiB,KAAK,QAAQ;YACxC,CAAC,CAAC,IAAI,CAAC,iBAAiB,CAAC,IAAI,EAAE;YAC/B,CAAC,CAAC,EAAE,CAAC;QACT,IAAI,CAAC,eAAe,EAAE,CAAC;YACrB,OAAO;gBACL,OAAO,EAAE;oBACP,EAAE,IAAI,EAAE,MAAM,EAAE,IAAI,EAAE,uCAAuC,EAAE;iBAChE;gBACD,OAAO,EAAE,IAAI;aACd,CAAC;QACJ,CAAC;QACD,IAAI,CAAC,KAAK,CAAC,OAAO,CAAC,IAAI,CAAC,MAAM,CAAC,IAAI,IAAI,CAAC,MAAM,CAAC,MAAM,KAAK,CAAC,EAAE,CAAC;YAC5D,OAAO;gBACL,OAAO,EAAE;oBACP;wBACE,IAAI,EAAE,MAAM;wBACZ,IAAI,EAAE,qDAAqD;qBAC5D;iBACF;gBACD,OAAO,EAAE,IAAI;aACd,CAAC;QACJ,CAAC;QACD,MAAM,MAAM,GAAG,IAAI,CAAC,MAAM,CAAC,MAAM,CAC/B,CAAC,CAAU,EAAE,EAAE,CAAC,OAAO,CAAC,KAAK,QAAQ,CAC1B,CAAC;QACd,IAAI,MAAM,CAAC,MAAM,KAAK,IAAI,CAAC,MAAM,CAAC,MAAM,EAAE,CAAC;YACzC,OAAO;gBACL,OAAO,EAAE,CAAC,EAAE,IAAI,EAAE,MAAM,EAAE,IAAI,EAAE,gCAAgC,EAAE,CAAC;gBACnE,OAAO,EAAE,IAAI;aACd,CAAC;QACJ,CAAC;QACD,MAAM,SAAS,GACb,OAAO,IAAI,CAAC,UAAU,KAAK,QAAQ,IAAI,IAAI,CAAC,UAAU,CAAC,IAAI,EAAE;YAC3D,CAAC,CAAC,IAAI,CAAC,UAAU;YACjB,CAAC,CAAC,IAAI,CAAC;QAEX,MAAM,MAAM,GAAG,MAAM,IAAI,CAAC,IAAI,CAAC,aAAa,CAAC,UAAU,CAAC;YACtD,eAAe;YACf,MAAM;YACN,SAAS;SACV,CAAC,CAAC;QACH,MAAM,IAAI,GAAG,MAAM,EAAE,IAAI,IAAI,MAAM,CAAC;QAEpC,gEAAgE;QAChE,8DAA8D;QAC9D,gEAAgE;QAChE,mBAAmB;QACnB,OAAO;YACL,OAAO,EAAE;gBACP;oBACE,IAAI,EAAE,MAAM;oBACZ,IAAI,EACF,qBAAqB,IAAI,EAAE,EAAE,IAAI,SAAS,KAAK;wBAC/C,YAAY,IAAI,EAAE,UAAU,IAAI,KAAK,IAAI;wBACzC,WAAW,MAAM,CAAC,IAAI,CAAC,IAAI,CAAC,OAAO;wBACnC,gBAAgB,IAAI,EAAE,WAAW,IAAI,EAAE,MAAM;wBAC7C,oDAAoD;wBACpD,8DAA8D;iBACjE;aACF;YACD,iBAAiB,EAAE;gBACjB,IAAI,EAAE,8BAA8B;gBACpC,OAAO,EAAE,CAAC;gBACV,IAAI;aACL;SACF,CAAC;IACJ,CAAC;IAEO,KAAK,CAAC,YAAY,CAAC,KAA0B;QACnD,MAAM,MAAM,GAAG,MAAM,IAAI,CAAC,IAAI,CAAC,aAAa,CAAC,YAAY,EAAE,CAAC;QAC5D,MAAM,IAAI,GAAG,MAAM,EAAE,IAAI,IAAI,MAAM,CAAC;QACpC,MAAM,IAAI,GAAG,KAAK,CAAC,OAAO,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC,IAAI,CAAC,CAAC,CAAC,EAAE,CAAC;QAC7C,MAAM,KAAK,GAAG,IAAI,CAAC,MAAM;YACvB,CAAC,CAAC,IAAI;iBACD,GAAG,CAAC,CAAC,GAAQ,EAAE,EAAE;gBAChB,MAAM,IAAI,GAAG,GAAG,EAAE,QAAQ,EAAE,YAAY,IAAI,SAAS,CAAC;gBACtD,MAAM,MAAM,GAAG,KAAK,CAAC,OAAO,CAAC,GAAG,EAAE,MAAM,CAAC;oBACvC,CAAC,CAAC,GAAG,CAAC,MAAM,CAAC,IAAI,CAAC,IAAI,CAAC;oBACvB,CAAC,CAAC,EAAE,CAAC;gBACP,MAAM,MAAM,GAAG,GAAG,EAAE,UAAU;oBAC5B,CAAC,CAAC,WAAW,GAAG,CAAC,UAAU,EAAE;oBAC7B,CAAC,CAAC,WAAW,CAAC;gBAChB,MAAM,OAAO,GAAG,GAAG,EAAE,UAAU,CAAC,CAAC,CAAC,YAAY,CAAC,CAAC,CAAC,EAAE,CAAC;gBACpD,OAAO,KAAK,IAAI,KAAK,GAAG,EAAE,EAAE,IAAI,SAAS,MAAM,MAAM,KAAK,MAAM,GAAG,OAAO,EAAE,CAAC;YAC/E,CAAC,CAAC;iBACD,IAAI,CAAC,IAAI,CAAC;YACf,CAAC,CAAC,aAAa,CAAC;QAElB,OAAO;YACL,OAAO,EAAE;gBACP;oBACE,IAAI,EAAE,MAAM;oBACZ,IAAI,EAAE,sBAAsB,IAAI,CAAC,MAAM,OAAO,KAAK,EAAE;iBACtD;aACF;YACD,iBAAiB,EAAE;gBACjB,IAAI,EAAE,6BAA6B;gBACnC,OAAO,EAAE,CAAC;gBACV,IAAI,EAAE,IAAI;aACX;SACF,CAAC;IACJ,CAAC;IAEO,KAAK,CAAC,WAAW,CAAC,IAAyB;QACjD,MAAM,OAAO,GACX,OAAO,IAAI,CAAC,QAAQ,KAAK,QAAQ,CAAC,CAAC,CAAC,IAAI,CAAC,QAAQ,CAAC,IAAI,EAAE,CAAC,CAAC,CAAC,EAAE,CAAC;QAChE,IAAI,CAAC,OAAO,EAAE,CAAC;YACb,OAAO;gBACL,OAAO,EAAE,CAAC,EAAE,IAAI,EAAE,MAAM,EAAE,IAAI,EAAE,8BAA8B,EAAE,CAAC;gBACjE,OAAO,EAAE,IAAI;aACd,CAAC;QACJ,CAAC;QAED,MAAM,MAAM,GAAG,MAAM,IAAI,CAAC,IAAI,CAAC,aAAa,CAAC,WAAW,CAAC,EAAE,OAAO,EAAE,CAAC,CAAC;QACtE,MAAM,IAAI,GAAG,MAAM,EAAE,IAAI,IAAI,MAAM,CAAC;QACpC,OAAO;YACL,OAAO,EAAE;gBACP;oBACE,IAAI,EAAE,MAAM;oBACZ,IAAI,EACF,SAAS,IAAI,EAAE,EAAE,IAAI,OAAO,eAAe,IAAI,EAAE,UAAU,IAAI,KAAK,IAAI;wBACxE,6DAA6D;wBAC7D,oBAAoB;iBACvB;aACF;YACD,iBAAiB,EAAE;gBACjB,IAAI,EAAE,+BAA+B;gBACrC,OAAO,EAAE,CAAC;gBACV,IAAI;aACL;SACF,CAAC;IACJ,CAAC;IAEO,KAAK,CAAC,WAAW,CAAC,IAAyB;QACjD,MAAM,eAAe,GACnB,OAAO,IAAI,CAAC,iBAAiB,KAAK,QAAQ;YAC1C,IAAI,CAAC,iBAAiB,CAAC,IAAI,EAAE;YAC3B,CAAC,CAAC,IAAI,CAAC,iBAAiB,CAAC,IAAI,EAAE;YAC/B,CAAC,CAAC,IAAI,CAAC;QACX,MAAM,YAAY,GAChB,OAAO,IAAI,CAAC,cAAc,KAAK,QAAQ,IAAI,IAAI,CAAC,cAAc,CAAC,IAAI,EAAE;YACnE,CAAC,CAAC,IAAI,CAAC,cAAc,CAAC,IAAI,EAAE;YAC5B,CAAC,CAAC,IAAI,CAAC;QACX,MAAM,KAAK,GAAG,OAAO,IAAI,CAAC,KAAK,KAAK,QAAQ,CAAC,CAAC,CAAC,IAAI,CAAC,KAAK,CAAC,CAAC,CAAC,SAAS,CAAC;QACtE,MAAM,MAAM,GAAG,OAAO,IAAI,CAAC,MAAM,KAAK,QAAQ,CAAC,CAAC,CAAC,IAAI,CAAC,MAAM,CAAC,CAAC,CAAC,SAAS,CAAC;QAEzE,MAAM,MAAM,GAAG,MAAM,IAAI,CAAC,IAAI,CAAC,aAAa,CAAC,WAAW,CAAC;YACvD,eAAe;YACf,YAAY;YACZ,KAAK;YACL,MAAM;SACP,CAAC,CAAC;QACH,MAAM,IAAI,GAAG,MAAM,EAAE,IAAI,IAAI,MAAM,CAAC;QACpC,MAAM,IAAI,GAAG,KAAK,CAAC,OAAO,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC,IAAI,CAAC,CAAC,CAAC,EAAE,CAAC;QAC7C,MAAM,KAAK,GAAG,IAAI,CAAC,MAAM;YACvB,CAAC,CAAC,IAAI;iBACD,GAAG,CAAC,CAAC,GAAQ,EAAE,EAAE;gBAChB,MAAM,IAAI,GAAG,GAAG,EAAE,KAAK,EAAE,QAAQ,EAAE,YAAY,IAAI,SAAS,CAAC;gBAC7D,MAAM,MAAM,GAAG,GAAG,EAAE,MAAM,IAAI,GAAG,CAAC;gBAClC,MAAM,KAAK,GAAG,GAAG,EAAE,YAAY,IAAI,GAAG,CAAC;gBACvC,MAAM,IAAI,GAAG,GAAG,EAAE,SAAS,IAAI,GAAG,CAAC;gBACnC,MAAM,IAAI,GAAG,GAAG,EAAE,UAAU,IAAI,EAAE,CAAC;gBACnC,OAAO,KAAK,IAAI,KAAK,IAAI,KAAK,MAAM,IAAI,KAAK,QAAQ,IAAI,EAAE,CAAC;YAC9D,CAAC,CAAC;iBACD,IAAI,CAAC,IAAI,CAAC;YACf,CAAC,CAAC,yEAAyE,CAAC;QAE9E,OAAO;YACL,OAAO,EAAE;gBACP;oBACE,IAAI,EAAE,MAAM;oBACZ,IAAI,EAAE,wBAAwB,IAAI,CAAC,MAAM,OAAO,KAAK,EAAE;iBACxD;aACF;YACD,iBAAiB,EAAE;gBACjB,IAAI,EAAE,0BAA0B;gBAChC,OAAO,EAAE,CAAC;gBACV,IAAI,EAAE,IAAI;aACX;SACF,CAAC;IACJ,CAAC;CACF"}

package/dist/tools/agreement-types.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"agreement-types.d.ts","sourceRoot":"","sources":["../../src/tools/agreement-types.ts"],"names":[],"mappings":"AAEA;;;;;GAKG;AAEH,OAAO,EAAE,UAAU,EAAE,MAAM,mBAAmB,CAAC;AAC/C,OAAO,EAAE,cAAc,EAAE,YAAY,EAAc,MAAM,YAAY,CAAC;AAetE,qBAAa,mBAAmB;IAC9B,OAAO,CAAC,IAAI,CAAa;gBAEb,IAAI,EAAE,UAAU;IAI5B,OAAO,CAAC,WAAW;IAanB,OAAO,CAAC,QAAQ;IAWhB,QAAQ,IAAI,KAAK,CAAC;QAAE,UAAU,EAAE,cAAc,CAAC;QAAC,QAAQ,EAAE,YAAY,CAAA;KAAE,CAAC;YAwQ3D,KAAK;YAML,OAAO;YAMP,MAAM;YA8CN,MAAM;YAON,MAAM;YASN,cAAc;YAMd,iBAAiB;YAOjB,kBAAkB;CAMjC"}
+{"version":3,"file":"agreement-types.d.ts","sourceRoot":"","sources":["../../src/tools/agreement-types.ts"],"names":[],"mappings":"AAEA;;;;;GAKG;AAEH,OAAO,EAAE,UAAU,EAAE,MAAM,mBAAmB,CAAC;AAC/C,OAAO,EAAE,cAAc,EAAE,YAAY,EAAc,MAAM,YAAY,CAAC;AAetE,qBAAa,mBAAmB;IAC9B,OAAO,CAAC,IAAI,CAAa;gBAEb,IAAI,EAAE,UAAU;IAI5B,OAAO,CAAC,WAAW;IAanB,OAAO,CAAC,QAAQ;IAWhB,QAAQ,IAAI,KAAK,CAAC;QAAE,UAAU,EAAE,cAAc,CAAC;QAAC,QAAQ,EAAE,YAAY,CAAA;KAAE,CAAC;YAoR3D,KAAK;YAML,OAAO;YAMP,MAAM;YA8CN,MAAM;YAON,MAAM;YASN,cAAc;YAMd,iBAAiB;YAOjB,kBAAkB;CAMjC"}

package/dist/tools/agreement-types.js

@@ -38,7 +38,9 @@ export class AgreementTypesTools {
                     scope: "read:agreements",
                     audiences: ["stdio", "http", "public"],
                     tier: "read",
-                    description: "List agreements by type — templates, producer agreements, or work-for-hire contracts.",
+                    description: "List agreements by type — templates, producer agreements, or work-for-hire contracts. " +
+                        "For one agreement in full, use pica_agreement_types_inspect; " +
+                        "this one lists by type.",
                     workflows: "infrastructure",
                     vernacular_kind: "specialist",
                     vernacular_reason: "Specialist context; not yet covered by the Creator Question Atlas — pending telemetry-driven addition per ADR-226 Phase 4 substrate writes.",
@@ -66,7 +68,9 @@ export class AgreementTypesTools {
                     scope: "read:agreements",
                     audiences: ["stdio", "http", "public"],
                     tier: "read",
-                    description: "Get a specific agreement by type and ID — full details including body, terms, and metadata.",
+                    description: "Get a specific agreement by type and ID — full details including body, terms, and metadata. " +
+                        "To browse every agreement of a type, use " +
+                        "pica_agreement_types_query; this one needs the id.",
                     workflows: "infrastructure",
                     vernacular_kind: "specialist",
                     vernacular_reason: "Specialist context; not yet covered by the Creator Question Atlas — pending telemetry-driven addition per ADR-226 Phase 4 substrate writes.",
@@ -99,10 +103,10 @@ export class AgreementTypesTools {
                         "work-for-hire — contractor waives royalty share, takes a flat fee + services description; " +
                         "producer agreement — producer takes points off the top of master royalties + deliverables. " +
                         "Pick the shape that matches the deal. Three branches dispatched via 'type': " +
-                        "template (→ agreement_templates, needs name + category + templateText), " +
-                        "producer (→ producer_agreements, needs producer_id + royalty_points + deliverables + work_id|recording_id), " +
-                        "work_for_hire (→ work_for_hire_agreements, needs contractor_id + contractor_role + fee_amount + services_description + work_id|recording_id). " +
-                        "Per-branch field applicability is documented on each property.",
+                        "template (needs name + category + templateText), " +
+                        "producer (needs producer_id + royalty_points + deliverables + work_id|recording_id), " +
+                        "work_for_hire (needs contractor_id + contractor_role + fee_amount + services_description + work_id|recording_id). " +
+                        "Prefer pica_agreement_templates_duplicate when the user wants a copy of an existing template.",
                     workflows: "infrastructure",
                     vernacular_kind: "specialist",
                     vernacular_reason: "Specialist context; not yet covered by the Creator Question Atlas — pending telemetry-driven addition per ADR-226 Phase 4 substrate writes.",
@@ -123,7 +127,9 @@ export class AgreementTypesTools {
                     description: "Update an existing agreement by type and ID. " +
                         "Note: PATCH on producer_agreements and work_for_hire_agreements is action-only " +
                         "(send_for_signature / countersign / mark_advance_paid / mark_paid / record_recoupment / " +
-                        "calculate_royalty), not generic field-level. Template branch accepts field updates.",
+                        "calculate_royalty), not generic field-level. Template branch accepts field updates. " +
+                        "Prefer pica_agreement_templates_set_default when the change is " +
+                        "just making a template the default for its type.",
                     workflows: "infrastructure",
                     vernacular_kind: "specialist",
                     vernacular_reason: "Specialist context; not yet covered by the Creator Question Atlas — pending telemetry-driven addition per ADR-226 Phase 4 substrate writes.",
@@ -143,7 +149,8 @@ export class AgreementTypesTools {
                     tier: "destructive",
                     description: "Delete a template / producer agreement / work-for-hire record by type + id — the " +
                         "agreement_types family. Standard agreements (master_recording, publishing_admin, etc.) " +
-                        "use pica_agreements_delete instead. No undo.",
+                        "use pica_agreements_delete instead. No undo — use " +
+                        "pica_agreement_types_inspect to check the record first.",
                     workflows: "infrastructure",
                     vernacular_kind: "specialist",
                     vernacular_reason: "Destructive operation; invoked by exact name after explicit user confirmation in a specialist flow.",
@@ -172,7 +179,9 @@ export class AgreementTypesTools {
                     scope: "read:agreements",
                     audiences: ["stdio", "http", "public"],
                     tier: "read",
-                    description: "Fill an agreement template with work and people data — generates a ready-to-send agreement. Pass the template ID plus work_id and/or people_ids to populate the placeholders with real catalog data.",
+                    description: "Fill an agreement template with work and people data — generates a ready-to-send agreement. Pass the template ID plus work_id and/or people_ids to populate the placeholders with real catalog data. " +
+                        "Find the template id with pica_agreement_types_query type:template; " +
+                        "this one only fills it in and returns the text.",
                     workflows: ["agreement-required"],
                     vernacular_kind: "specialist",
                     vernacular_reason: "Specialist context; not yet covered by the Creator Question Atlas — pending telemetry-driven addition per ADR-226 Phase 4 substrate writes.",
@@ -208,7 +217,8 @@ export class AgreementTypesTools {
                     scope: "write:agreements",
                     audiences: ["stdio", "http", "public"],
                     tier: "write",
-                    description: "Duplicate an agreement template — creates a copy you can customise without changing the original.",
+                    description: "Duplicate an agreement template — creates a copy you can customise without changing the original. " +
+                        "Prefer pica_agreement_types_update to edit the original in place.",
                     workflows: "infrastructure",
                     vernacular_kind: "specialist",
                     vernacular_reason: "Specialist context; not yet covered by the Creator Question Atlas — pending telemetry-driven addition per ADR-226 Phase 4 substrate writes.",
@@ -231,7 +241,9 @@ export class AgreementTypesTools {
                     scope: "write:agreements",
                     audiences: ["stdio", "http", "public"],
                     tier: "write",
-                    description: "Set a template as the default for its type — when creating agreements of that type, this template will be suggested first.",
+                    description: "Set a template as the default for its type — when creating agreements of that type, this template will be suggested first. " +
+                        "Use pica_agreement_types_query type:template to list the " +
+                        "templates you can choose from.",
                     workflows: "infrastructure",
                     vernacular_kind: "specialist",
                     vernacular_reason: "Specialist context; not yet covered by the Creator Question Atlas — pending telemetry-driven addition per ADR-226 Phase 4 substrate writes.",

package/dist/tools/agreement-types.js.map

@@ -1 +1 @@
-{"version":3,"file":"agreement-types.js","sourceRoot":"","sources":["../../src/tools/agreement-types.ts"],"names":[],"mappings":"AAAA,6DAA6D;AAW7D,OAAO,EAAE,YAAY,EAAE,UAAU,EAAE,aAAa,EAAE,MAAM,qBAAqB,CAAC;AAC9E,OAAO,EACL,aAAa,EACb,sBAAsB,EACtB,eAAe,GAChB,MAAM,qBAAqB,CAAC;AAC7B,OAAO,EACL,gCAAgC,EAChC,+BAA+B,EAC/B,+BAA+B,GAChC,MAAM,qBAAqB,CAAC;AAI7B,MAAM,OAAO,mBAAmB;IACtB,IAAI,CAAa;IAEzB,YAAY,IAAgB;QAC1B,IAAI,CAAC,IAAI,GAAG,IAAI,CAAC;IACnB,CAAC;IAEO,WAAW,CAAC,IAAmB;QACrC,QAAQ,IAAI,EAAE,CAAC;YACb,KAAK,UAAU;gBACb,OAAO,IAAI,CAAC,IAAI,CAAC,kBAAkB,CAAC;YACtC,KAAK,UAAU;gBACb,OAAO,IAAI,CAAC,IAAI,CAAC,kBAAkB,CAAC;YACtC,KAAK,eAAe;gBAClB,OAAO,IAAI,CAAC,IAAI,CAAC,WAAW,CAAC;YAC/B;gBACE,MAAM,IAAI,KAAK,CAAC,2BAA2B,IAAI,EAAE,CAAC,CAAC;QACvD,CAAC;IACH,CAAC;IAEO,QAAQ,CAAC,IAAmB;QAClC,QAAQ,IAAI,EAAE,CAAC;YACb,KAAK,UAAU;gBACb,OAAO,oBAAoB,CAAC;YAC9B,KAAK,UAAU;gBACb,OAAO,oBAAoB,CAAC;YAC9B,KAAK,eAAe;gBAClB,OAAO,yBAAyB,CAAC;QACrC,CAAC;IACH,CAAC;IAED,QAAQ;QACN,OAAO;YACL,mEAAmE;YACnE;gBACE,UAAU,EAAE;oBACV,IAAI,EAAE,4BAA4B;oBAClC,KAAK,EAAE,iBAAiB;oBACxB,SAAS,EAAE,CAAC,OAAO,EAAE,MAAM,EAAE,QAAQ,CAAC;oBACtC,IAAI,EAAE,MAAM;oBACZ,WAAW,EACT,uFAAuF;oBACzF,SAAS,EAAE,gBAAgB;oBAC3B,eAAe,EAAE,YAAY;oBAC7B,iBAAiB,EACf,6IAA6I;oBAC/I,WAAW,EAAE;wBACX,IAAI,EAAE,QAAQ;wBACd,UAAU,EAAE;4BACV,IAAI,EAAE;gCACJ,IAAI,EAAE,QAAQ;gCACd,IAAI,EAAE,CAAC,UAAU,EAAE,UAAU,EAAE,eAAe,CAAC;gCAC/C,WAAW,EAAE,6BAA6B;6BAC3C;4BACD,KAAK,EAAE;gCACL,IAAI,EAAE,QAAQ;gCACd,WAAW,EAAE,aAAa;6BAC3B;yBACF;wBACD,QAAQ,EAAE,CAAC,MAAM,CAAC;qBACnB;iBACF;gBACD,QAAQ,EAAE,IAAI,CAAC,KAAK,CAAC,IAAI,CAAC,IAAI,CAAC;aAChC;YACD;gBACE,UAAU,EAAE;oBACV,IAAI,EAAE,8BAA8B;oBACpC,KAAK,EAAE,iBAAiB;oBACxB,SAAS,EAAE,CAAC,OAAO,EAAE,MAAM,EAAE,QAAQ,CAAC;oBACtC,IAAI,EAAE,MAAM;oBACZ,WAAW,EACT,6FAA6F;oBAC/F,SAAS,EAAE,gBAAgB;oBAC3B,eAAe,EAAE,YAAY;oBAC7B,iBAAiB,EACf,6IAA6I;oBAC/I,WAAW,EAAE;wBACX,IAAI,EAAE,QAAQ;wBACd,UAAU,EAAE;4BACV,IAAI,EAAE;gCACJ,IAAI,EAAE,QAAQ;gCACd,IAAI,EAAE,CAAC,UAAU,EAAE,UAAU,EAAE,eAAe,CAAC;gCAC/C,WAAW,EAAE,oBAAoB;6BAClC;4BACD,EAAE,EAAE;gCACF,IAAI,EAAE,QAAQ;gCACd,WAAW,EAAE,cAAc;6BAC5B;yBACF;wBACD,QAAQ,EAAE,CAAC,MAAM,EAAE,IAAI,CAAC;qBACzB;iBACF;gBACD,QAAQ,EAAE,IAAI,CAAC,OAAO,CAAC,IAAI,CAAC,IAAI,CAAC;aAClC;YACD;gBACE,UAAU,EAAE;oBACV,IAAI,EAAE,6BAA6B;oBACnC,KAAK,EAAE,kBAAkB;oBACzB,SAAS,EAAE,CAAC,OAAO,EAAE,MAAM,EAAE,QAAQ,CAAC;oBACtC,IAAI,EAAE,OAAO;oBACb,WAAW,EACT,uEAAuE;wBACvE,0IAA0I;wBAC1I,4FAA4F;wBAC5F,6FAA6F;wBAC7F,8EAA8E;wBAC9E,0EAA0E;wBAC1E,8GAA8G;wBAC9G,gJAAgJ;wBAChJ,gEAAgE;oBAClE,SAAS,EAAE,gBAAgB;oBAC3B,eAAe,EAAE,YAAY;oBAC7B,iBAAiB,EACf,6IAA6I;oBAC/I,WAAW,EAAE;wBACX,IAAI,EAAE,QAAQ;wBACd,UAAU,EAAE,gCAAgC;wBAC5C,QAAQ,EAAE,CAAC,GAAG,+BAA+B,CAAC;qBAC/C;iBACF;gBACD,QAAQ,EAAE,eAAe,CACvB,IAAI,CAAC,IAAI,EACT,yBAAyB,EACzB,IAAI,CAAC,MAAM,CAAC,IAAI,CAAC,IAAI,CAAC,CACvB;aACF;YACD;gBACE,UAAU,EAAE;oBACV,IAAI,EAAE,6BAA6B;oBACnC,KAAK,EAAE,kBAAkB;oBACzB,SAAS,EAAE,CAAC,OAAO,EAAE,MAAM,EAAE,QAAQ,CAAC;oBACtC,IAAI,EAAE,OAAO;oBACb,WAAW,EACT,+CAA+C;wBAC/C,iFAAiF;wBACjF,0FAA0F;wBAC1F,qFAAqF;oBACvF,SAAS,EAAE,gBAAgB;oBAC3B,eAAe,EAAE,YAAY;oBAC7B,iBAAiB,EACf,6IAA6I;oBAC/I,WAAW,EAAE;wBACX,IAAI,EAAE,QAAQ;wBACd,UAAU,EAAE,gCAAgC;wBAC5C,QAAQ,EAAE,CAAC,GAAG,+BAA+B,CAAC;qBAC/C;iBACF;gBACD,QAAQ,EAAE,eAAe,CACvB,IAAI,CAAC,IAAI,EACT,uBAAuB,EACvB,IAAI,CAAC,MAAM,CAAC,IAAI,CAAC,IAAI,CAAC,CACvB;aACF;YACD;gBACE,UAAU,EAAE;oBACV,IAAI,EAAE,6BAA6B;oBACnC,KAAK,EAAE,kBAAkB;oBACzB,SAAS,EAAE,CAAC,OAAO,EAAE,MAAM,EAAE,QAAQ,CAAC;oBACtC,IAAI,EAAE,aAAa;oBACnB,WAAW,EACT,mFAAmF;wBACnF,yFAAyF;wBACzF,8CAA8C;oBAChD,SAAS,EAAE,gBAAgB;oBAC3B,eAAe,EAAE,YAAY;oBAC7B,iBAAiB,EACf,qGAAqG;oBACvG,WAAW,EAAE;wBACX,IAAI,EAAE,QAAQ;wBACd,UAAU,EAAE;4BACV,IAAI,EAAE;gCACJ,IAAI,EAAE,QAAQ;gCACd,IAAI,EAAE,CAAC,UAAU,EAAE,UAAU,EAAE,eAAe,CAAC;gCAC/C,WAAW,EAAE,oBAAoB;6BAClC;4BACD,EAAE,EAAE;gCACF,IAAI,EAAE,QAAQ;gCACd,WAAW,EAAE,iDAAiD;6BAC/D;yBACF;wBACD,QAAQ,EAAE,CAAC,MAAM,EAAE,IAAI,CAAC;qBACzB;iBACF;gBACD,QAAQ,EAAE,eAAe,CACvB,IAAI,CAAC,IAAI,EACT,yBAAyB,EACzB,IAAI,CAAC,MAAM,CAAC,IAAI,CAAC,IAAI,CAAC,CACvB;aACF;YAED,mEAAmE;YACnE;gBACE,UAAU,EAAE;oBACV,IAAI,EAAE,iCAAiC;oBACvC,KAAK,EAAE,iBAAiB;oBACxB,SAAS,EAAE,CAAC,OAAO,EAAE,MAAM,EAAE,QAAQ,CAAC;oBACtC,IAAI,EAAE,MAAM;oBACZ,WAAW,EACT,sMAAsM;oBACxM,SAAS,EAAE,CAAC,oBAAoB,CAAC;oBACjC,eAAe,EAAE,YAAY;oBAC7B,iBAAiB,EACf,6IAA6I;oBAC/I,WAAW,EAAE;wBACX,IAAI,EAAE,QAAQ;wBACd,UAAU,EAAE;4BACV,EAAE,EAAE;gCACF,IAAI,EAAE,QAAQ;gCACd,WAAW,EAAE,uBAAuB;6BACrC;4BACD,OAAO,EAAE;gCACP,IAAI,EAAE,QAAQ;gCACd,WAAW,EACT,mDAAmD;6BACtD;4BACD,UAAU,EAAE;gCACV,IAAI,EAAE,OAAO;gCACb,KAAK,EAAE,EAAE,IAAI,EAAE,QAAQ,EAAE;gCACzB,WAAW,EACT,mDAAmD;6BACtD;4BACD,SAAS,EAAE;gCACT,IAAI,EAAE,QAAQ;gCACd,WAAW,EACT,wFAAwF;6BAC3F;yBACF;wBACD,QAAQ,EAAE,CAAC,IAAI,CAAC;qBACjB;iBACF;gBACD,QAAQ,EAAE,IAAI,CAAC,cAAc,CAAC,IAAI,CAAC,IAAI,CAAC;aACzC;YACD;gBACE,UAAU,EAAE;oBACV,IAAI,EAAE,oCAAoC;oBAC1C,KAAK,EAAE,kBAAkB;oBACzB,SAAS,EAAE,CAAC,OAAO,EAAE,MAAM,EAAE,QAAQ,CAAC;oBACtC,IAAI,EAAE,OAAO;oBACb,WAAW,EACT,mGAAmG;oBACrG,SAAS,EAAE,gBAAgB;oBAC3B,eAAe,EAAE,YAAY;oBAC7B,iBAAiB,EACf,6IAA6I;oBAC/I,WAAW,EAAE;wBACX,IAAI,EAAE,QAAQ;wBACd,UAAU,EAAE;4BACV,EAAE,EAAE;gCACF,IAAI,EAAE,QAAQ;gCACd,WAAW,EAAE,0BAA0B;6BACxC;yBACF;wBACD,QAAQ,EAAE,CAAC,IAAI,CAAC;qBACjB;iBACF;gBACD,QAAQ,EAAE,eAAe,CACvB,IAAI,CAAC,IAAI,EACT,sBAAsB,EACtB,IAAI,CAAC,iBAAiB,CAAC,IAAI,CAAC,IAAI,CAAC,CAClC;aACF;YACD;gBACE,UAAU,EAAE;oBACV,IAAI,EAAE,sCAAsC;oBAC5C,KAAK,EAAE,kBAAkB;oBACzB,SAAS,EAAE,CAAC,OAAO,EAAE,MAAM,EAAE,QAAQ,CAAC;oBACtC,IAAI,EAAE,OAAO;oBACb,WAAW,EACT,4HAA4H;oBAC9H,SAAS,EAAE,gBAAgB;oBAC3B,eAAe,EAAE,YAAY;oBAC7B,iBAAiB,EACf,6IAA6I;oBAC/I,WAAW,EAAE;wBACX,IAAI,EAAE,QAAQ;wBACd,UAAU,EAAE;4BACV,EAAE,EAAE;gCACF,IAAI,EAAE,QAAQ;gCACd,WAAW,EAAE,+BAA+B;6BAC7C;yBACF;wBACD,QAAQ,EAAE,CAAC,IAAI,CAAC;qBACjB;iBACF;gBACD,QAAQ,EAAE,eAAe,CACvB,IAAI,CAAC,IAAI,EACT,kBAAkB,EAClB,IAAI,CAAC,kBAAkB,CAAC,IAAI,CAAC,IAAI,CAAC,CACnC;aACF;SACF,CAAC;IACJ,CAAC;IAED,uEAAuE;IAE/D,KAAK,CAAC,KAAK,CAAC,IAAyB;QAC3C,MAAM,QAAQ,GAAG,IAAI,CAAC,WAAW,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;QAC7C,MAAM,KAAK,GAAG,MAAM,QAAQ,CAAC,IAAI,EAAE,CAAC;QACpC,OAAO,UAAU,CAAC,KAAK,EAAE,EAAE,KAAK,EAAE,KAAK,CAAC,MAAM,EAAE,CAAC,CAAC;IACpD,CAAC;IAEO,KAAK,CAAC,OAAO,CAAC,IAAyB;QAC7C,MAAM,QAAQ,GAAG,IAAI,CAAC,WAAW,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;QAC7C,MAAM,IAAI,GAAG,MAAM,QAAQ,CAAC,GAAG,CAAC,IAAI,CAAC,EAAE,CAAC,CAAC;QACzC,OAAO,YAAY,CAAC,IAAI,CAAC,CAAC;IAC5B,CAAC;IAEO,KAAK,CAAC,MAAM,CAAC,IAAyB;QAC5C,MAAM,EAAE,IAAI,EAAE,GAAG,MAAM,EAAE,GAAG,IAAI,CAAC;QACjC,MAAM,QAAQ,GAAG,IAAI,CAAC,WAAW,CAAC,IAAI,CAAC,CAAC;QACxC,MAAM,IAAI,GAAG,MAAM,QAAQ,CAAC,MAAM,CAAC,MAAM,CAAC,CAAC;QAE3C,uCAAuC;QACvC,IAAI,IAAI,KAAK,UAAU,IAAI,MAAM,CAAC,WAAW,EAAE,CAAC;YAC9C,MAAM,OAAO,GAAG,MAAM,aAAa,CAAC,IAAI,CAAC,IAAI,EAAE;gBAC7C;oBACE,SAAS,EAAE,MAAM,CAAC,WAAW;oBAC7B,OAAO,EAAE,8CAA8C,MAAM,CAAC,KAAK,IAAI,UAAU,6BAA6B;oBAC9G,OAAO,EAAE,MAAM,CAAC,OAAO;oBACvB,iBAAiB,EAAE,mBAAmB;iBACvC;aACF,CAAC,CAAC;YACH,MAAM,aAAa,GAAG,sBAAsB,CAAC,OAAO,CAAC,CAAC;YACtD,IAAI,aAAa,EAAE,CAAC;gBAClB,OAAO,aAAa,CAClB,+BAA+B,aAAa,EAAE,EAC9C,IAAI,CACL,CAAC;YACJ,CAAC;QACH,CAAC;QAED,iCAAiC;QACjC,IAAI,IAAI,KAAK,eAAe,IAAI,MAAM,CAAC,aAAa,EAAE,CAAC;YACrD,MAAM,OAAO,GAAG,MAAM,aAAa,CAAC,IAAI,CAAC,IAAI,EAAE;gBAC7C;oBACE,SAAS,EAAE,MAAM,CAAC,aAAa;oBAC/B,OAAO,EAAE,gDAAgD,MAAM,CAAC,KAAK,IAAI,UAAU,mBAAmB;oBACtG,OAAO,EAAE,MAAM,CAAC,OAAO;oBACvB,iBAAiB,EAAE,mBAAmB;iBACvC;aACF,CAAC,CAAC;YACH,MAAM,aAAa,GAAG,sBAAsB,CAAC,OAAO,CAAC,CAAC;YACtD,IAAI,aAAa,EAAE,CAAC;gBAClB,OAAO,aAAa,CAClB,oCAAoC,aAAa,EAAE,EACnD,IAAI,CACL,CAAC;YACJ,CAAC;QACH,CAAC;QAED,OAAO,aAAa,CAAC,GAAG,IAAI,CAAC,QAAQ,CAAC,IAAI,CAAC,UAAU,EAAE,IAAI,CAAC,CAAC;IAC/D,CAAC;IAEO,KAAK,CAAC,MAAM,CAAC,IAAyB;QAC5C,MAAM,EAAE,IAAI,EAAE,EAAE,EAAE,GAAG,OAAO,EAAE,GAAG,IAAI,CAAC;QACtC,MAAM,QAAQ,GAAG,IAAI,CAAC,WAAW,CAAC,IAAI,CAAC,CAAC;QACxC,MAAM,IAAI,GAAG,MAAM,QAAQ,CAAC,MAAM,CAAC,EAAE,EAAE,OAAO,CAAC,CAAC;QAChD,OAAO,aAAa,CAAC,GAAG,IAAI,CAAC,QAAQ,CAAC,IAAI,CAAC,UAAU,EAAE,IAAI,CAAC,CAAC;IAC/D,CAAC;IAEO,KAAK,CAAC,MAAM,CAAC,IAAyB;QAC5C,MAAM,EAAE,IAAI,EAAE,EAAE,EAAE,GAAG,IAAI,CAAC;QAC1B,MAAM,QAAQ,GAAG,IAAI,CAAC,WAAW,CAAC,IAAI,CAAC,CAAC;QACxC,MAAM,QAAQ,CAAC,MAAM,CAAC,EAAE,CAAC,CAAC;QAC1B,OAAO,aAAa,CAAC,GAAG,IAAI,CAAC,QAAQ,CAAC,IAAI,CAAC,IAAI,EAAE,UAAU,CAAC,CAAC;IAC/D,CAAC;IAED,uEAAuE;IAE/D,KAAK,CAAC,cAAc,CAAC,IAAyB;QACpD,MAAM,EAAE,EAAE,EAAE,GAAG,UAAU,EAAE,GAAG,IAAI,CAAC;QACnC,MAAM,QAAQ,GAAG,MAAM,IAAI,CAAC,IAAI,CAAC,kBAAkB,CAAC,MAAM,CAAC,EAAE,EAAE,UAAU,CAAC,CAAC;QAC3E,OAAO,aAAa,CAAC,qCAAqC,EAAE,QAAQ,CAAC,CAAC;IACxE,CAAC;IAEO,KAAK,CAAC,iBAAiB,CAC7B,IAAyB;QAEzB,MAAM,SAAS,GAAG,MAAM,IAAI,CAAC,IAAI,CAAC,kBAAkB,CAAC,SAAS,CAAC,IAAI,CAAC,EAAE,CAAC,CAAC;QACxE,OAAO,aAAa,CAAC,qBAAqB,EAAE,SAAS,CAAC,CAAC;IACzD,CAAC;IAEO,KAAK,CAAC,kBAAkB,CAC9B,IAAyB;QAEzB,MAAM,MAAM,GAAG,MAAM,IAAI,CAAC,IAAI,CAAC,kBAAkB,CAAC,UAAU,CAAC,IAAI,CAAC,EAAE,CAAC,CAAC;QACtE,OAAO,aAAa,CAAC,sCAAsC,EAAE,MAAM,CAAC,CAAC;IACvE,CAAC;CACF"}
+{"version":3,"file":"agreement-types.js","sourceRoot":"","sources":["../../src/tools/agreement-types.ts"],"names":[],"mappings":"AAAA,6DAA6D;AAW7D,OAAO,EAAE,YAAY,EAAE,UAAU,EAAE,aAAa,EAAE,MAAM,qBAAqB,CAAC;AAC9E,OAAO,EACL,aAAa,EACb,sBAAsB,EACtB,eAAe,GAChB,MAAM,qBAAqB,CAAC;AAC7B,OAAO,EACL,gCAAgC,EAChC,+BAA+B,EAC/B,+BAA+B,GAChC,MAAM,qBAAqB,CAAC;AAI7B,MAAM,OAAO,mBAAmB;IACtB,IAAI,CAAa;IAEzB,YAAY,IAAgB;QAC1B,IAAI,CAAC,IAAI,GAAG,IAAI,CAAC;IACnB,CAAC;IAEO,WAAW,CAAC,IAAmB;QACrC,QAAQ,IAAI,EAAE,CAAC;YACb,KAAK,UAAU;gBACb,OAAO,IAAI,CAAC,IAAI,CAAC,kBAAkB,CAAC;YACtC,KAAK,UAAU;gBACb,OAAO,IAAI,CAAC,IAAI,CAAC,kBAAkB,CAAC;YACtC,KAAK,eAAe;gBAClB,OAAO,IAAI,CAAC,IAAI,CAAC,WAAW,CAAC;YAC/B;gBACE,MAAM,IAAI,KAAK,CAAC,2BAA2B,IAAI,EAAE,CAAC,CAAC;QACvD,CAAC;IACH,CAAC;IAEO,QAAQ,CAAC,IAAmB;QAClC,QAAQ,IAAI,EAAE,CAAC;YACb,KAAK,UAAU;gBACb,OAAO,oBAAoB,CAAC;YAC9B,KAAK,UAAU;gBACb,OAAO,oBAAoB,CAAC;YAC9B,KAAK,eAAe;gBAClB,OAAO,yBAAyB,CAAC;QACrC,CAAC;IACH,CAAC;IAED,QAAQ;QACN,OAAO;YACL,mEAAmE;YACnE;gBACE,UAAU,EAAE;oBACV,IAAI,EAAE,4BAA4B;oBAClC,KAAK,EAAE,iBAAiB;oBACxB,SAAS,EAAE,CAAC,OAAO,EAAE,MAAM,EAAE,QAAQ,CAAC;oBACtC,IAAI,EAAE,MAAM;oBACZ,WAAW,EACT,wFAAwF;wBACxF,+DAA+D;wBAC/D,yBAAyB;oBAC3B,SAAS,EAAE,gBAAgB;oBAC3B,eAAe,EAAE,YAAY;oBAC7B,iBAAiB,EACf,6IAA6I;oBAC/I,WAAW,EAAE;wBACX,IAAI,EAAE,QAAQ;wBACd,UAAU,EAAE;4BACV,IAAI,EAAE;gCACJ,IAAI,EAAE,QAAQ;gCACd,IAAI,EAAE,CAAC,UAAU,EAAE,UAAU,EAAE,eAAe,CAAC;gCAC/C,WAAW,EAAE,6BAA6B;6BAC3C;4BACD,KAAK,EAAE;gCACL,IAAI,EAAE,QAAQ;gCACd,WAAW,EAAE,aAAa;6BAC3B;yBACF;wBACD,QAAQ,EAAE,CAAC,MAAM,CAAC;qBACnB;iBACF;gBACD,QAAQ,EAAE,IAAI,CAAC,KAAK,CAAC,IAAI,CAAC,IAAI,CAAC;aAChC;YACD;gBACE,UAAU,EAAE;oBACV,IAAI,EAAE,8BAA8B;oBACpC,KAAK,EAAE,iBAAiB;oBACxB,SAAS,EAAE,CAAC,OAAO,EAAE,MAAM,EAAE,QAAQ,CAAC;oBACtC,IAAI,EAAE,MAAM;oBACZ,WAAW,EACT,8FAA8F;wBAC9F,2CAA2C;wBAC3C,oDAAoD;oBACtD,SAAS,EAAE,gBAAgB;oBAC3B,eAAe,EAAE,YAAY;oBAC7B,iBAAiB,EACf,6IAA6I;oBAC/I,WAAW,EAAE;wBACX,IAAI,EAAE,QAAQ;wBACd,UAAU,EAAE;4BACV,IAAI,EAAE;gCACJ,IAAI,EAAE,QAAQ;gCACd,IAAI,EAAE,CAAC,UAAU,EAAE,UAAU,EAAE,eAAe,CAAC;gCAC/C,WAAW,EAAE,oBAAoB;6BAClC;4BACD,EAAE,EAAE;gCACF,IAAI,EAAE,QAAQ;gCACd,WAAW,EAAE,cAAc;6BAC5B;yBACF;wBACD,QAAQ,EAAE,CAAC,MAAM,EAAE,IAAI,CAAC;qBACzB;iBACF;gBACD,QAAQ,EAAE,IAAI,CAAC,OAAO,CAAC,IAAI,CAAC,IAAI,CAAC;aAClC;YACD;gBACE,UAAU,EAAE;oBACV,IAAI,EAAE,6BAA6B;oBACnC,KAAK,EAAE,kBAAkB;oBACzB,SAAS,EAAE,CAAC,OAAO,EAAE,MAAM,EAAE,QAAQ,CAAC;oBACtC,IAAI,EAAE,OAAO;oBACb,WAAW,EACT,uEAAuE;wBACvE,0IAA0I;wBAC1I,4FAA4F;wBAC5F,6FAA6F;wBAC7F,8EAA8E;wBAC9E,mDAAmD;wBACnD,uFAAuF;wBACvF,oHAAoH;wBACpH,+FAA+F;oBACjG,SAAS,EAAE,gBAAgB;oBAC3B,eAAe,EAAE,YAAY;oBAC7B,iBAAiB,EACf,6IAA6I;oBAC/I,WAAW,EAAE;wBACX,IAAI,EAAE,QAAQ;wBACd,UAAU,EAAE,gCAAgC;wBAC5C,QAAQ,EAAE,CAAC,GAAG,+BAA+B,CAAC;qBAC/C;iBACF;gBACD,QAAQ,EAAE,eAAe,CACvB,IAAI,CAAC,IAAI,EACT,yBAAyB,EACzB,IAAI,CAAC,MAAM,CAAC,IAAI,CAAC,IAAI,CAAC,CACvB;aACF;YACD;gBACE,UAAU,EAAE;oBACV,IAAI,EAAE,6BAA6B;oBACnC,KAAK,EAAE,kBAAkB;oBACzB,SAAS,EAAE,CAAC,OAAO,EAAE,MAAM,EAAE,QAAQ,CAAC;oBACtC,IAAI,EAAE,OAAO;oBACb,WAAW,EACT,+CAA+C;wBAC/C,iFAAiF;wBACjF,0FAA0F;wBAC1F,sFAAsF;wBACtF,iEAAiE;wBACjE,kDAAkD;oBACpD,SAAS,EAAE,gBAAgB;oBAC3B,eAAe,EAAE,YAAY;oBAC7B,iBAAiB,EACf,6IAA6I;oBAC/I,WAAW,EAAE;wBACX,IAAI,EAAE,QAAQ;wBACd,UAAU,EAAE,gCAAgC;wBAC5C,QAAQ,EAAE,CAAC,GAAG,+BAA+B,CAAC;qBAC/C;iBACF;gBACD,QAAQ,EAAE,eAAe,CACvB,IAAI,CAAC,IAAI,EACT,uBAAuB,EACvB,IAAI,CAAC,MAAM,CAAC,IAAI,CAAC,IAAI,CAAC,CACvB;aACF;YACD;gBACE,UAAU,EAAE;oBACV,IAAI,EAAE,6BAA6B;oBACnC,KAAK,EAAE,kBAAkB;oBACzB,SAAS,EAAE,CAAC,OAAO,EAAE,MAAM,EAAE,QAAQ,CAAC;oBACtC,IAAI,EAAE,aAAa;oBACnB,WAAW,EACT,mFAAmF;wBACnF,yFAAyF;wBACzF,oDAAoD;wBACpD,yDAAyD;oBAC3D,SAAS,EAAE,gBAAgB;oBAC3B,eAAe,EAAE,YAAY;oBAC7B,iBAAiB,EACf,qGAAqG;oBACvG,WAAW,EAAE;wBACX,IAAI,EAAE,QAAQ;wBACd,UAAU,EAAE;4BACV,IAAI,EAAE;gCACJ,IAAI,EAAE,QAAQ;gCACd,IAAI,EAAE,CAAC,UAAU,EAAE,UAAU,EAAE,eAAe,CAAC;gCAC/C,WAAW,EAAE,oBAAoB;6BAClC;4BACD,EAAE,EAAE;gCACF,IAAI,EAAE,QAAQ;gCACd,WAAW,EAAE,iDAAiD;6BAC/D;yBACF;wBACD,QAAQ,EAAE,CAAC,MAAM,EAAE,IAAI,CAAC;qBACzB;iBACF;gBACD,QAAQ,EAAE,eAAe,CACvB,IAAI,CAAC,IAAI,EACT,yBAAyB,EACzB,IAAI,CAAC,MAAM,CAAC,IAAI,CAAC,IAAI,CAAC,CACvB;aACF;YAED,mEAAmE;YACnE;gBACE,UAAU,EAAE;oBACV,IAAI,EAAE,iCAAiC;oBACvC,KAAK,EAAE,iBAAiB;oBACxB,SAAS,EAAE,CAAC,OAAO,EAAE,MAAM,EAAE,QAAQ,CAAC;oBACtC,IAAI,EAAE,MAAM;oBACZ,WAAW,EACT,uMAAuM;wBACvM,sEAAsE;wBACtE,iDAAiD;oBACnD,SAAS,EAAE,CAAC,oBAAoB,CAAC;oBACjC,eAAe,EAAE,YAAY;oBAC7B,iBAAiB,EACf,6IAA6I;oBAC/I,WAAW,EAAE;wBACX,IAAI,EAAE,QAAQ;wBACd,UAAU,EAAE;4BACV,EAAE,EAAE;gCACF,IAAI,EAAE,QAAQ;gCACd,WAAW,EAAE,uBAAuB;6BACrC;4BACD,OAAO,EAAE;gCACP,IAAI,EAAE,QAAQ;gCACd,WAAW,EACT,mDAAmD;6BACtD;4BACD,UAAU,EAAE;gCACV,IAAI,EAAE,OAAO;gCACb,KAAK,EAAE,EAAE,IAAI,EAAE,QAAQ,EAAE;gCACzB,WAAW,EACT,mDAAmD;6BACtD;4BACD,SAAS,EAAE;gCACT,IAAI,EAAE,QAAQ;gCACd,WAAW,EACT,wFAAwF;6BAC3F;yBACF;wBACD,QAAQ,EAAE,CAAC,IAAI,CAAC;qBACjB;iBACF;gBACD,QAAQ,EAAE,IAAI,CAAC,cAAc,CAAC,IAAI,CAAC,IAAI,CAAC;aACzC;YACD;gBACE,UAAU,EAAE;oBACV,IAAI,EAAE,oCAAoC;oBAC1C,KAAK,EAAE,kBAAkB;oBACzB,SAAS,EAAE,CAAC,OAAO,EAAE,MAAM,EAAE,QAAQ,CAAC;oBACtC,IAAI,EAAE,OAAO;oBACb,WAAW,EACT,oGAAoG;wBACpG,mEAAmE;oBACrE,SAAS,EAAE,gBAAgB;oBAC3B,eAAe,EAAE,YAAY;oBAC7B,iBAAiB,EACf,6IAA6I;oBAC/I,WAAW,EAAE;wBACX,IAAI,EAAE,QAAQ;wBACd,UAAU,EAAE;4BACV,EAAE,EAAE;gCACF,IAAI,EAAE,QAAQ;gCACd,WAAW,EAAE,0BAA0B;6BACxC;yBACF;wBACD,QAAQ,EAAE,CAAC,IAAI,CAAC;qBACjB;iBACF;gBACD,QAAQ,EAAE,eAAe,CACvB,IAAI,CAAC,IAAI,EACT,sBAAsB,EACtB,IAAI,CAAC,iBAAiB,CAAC,IAAI,CAAC,IAAI,CAAC,CAClC;aACF;YACD;gBACE,UAAU,EAAE;oBACV,IAAI,EAAE,sCAAsC;oBAC5C,KAAK,EAAE,kBAAkB;oBACzB,SAAS,EAAE,CAAC,OAAO,EAAE,MAAM,EAAE,QAAQ,CAAC;oBACtC,IAAI,EAAE,OAAO;oBACb,WAAW,EACT,6HAA6H;wBAC7H,2DAA2D;wBAC3D,gCAAgC;oBAClC,SAAS,EAAE,gBAAgB;oBAC3B,eAAe,EAAE,YAAY;oBAC7B,iBAAiB,EACf,6IAA6I;oBAC/I,WAAW,EAAE;wBACX,IAAI,EAAE,QAAQ;wBACd,UAAU,EAAE;4BACV,EAAE,EAAE;gCACF,IAAI,EAAE,QAAQ;gCACd,WAAW,EAAE,+BAA+B;6BAC7C;yBACF;wBACD,QAAQ,EAAE,CAAC,IAAI,CAAC;qBACjB;iBACF;gBACD,QAAQ,EAAE,eAAe,CACvB,IAAI,CAAC,IAAI,EACT,kBAAkB,EAClB,IAAI,CAAC,kBAAkB,CAAC,IAAI,CAAC,IAAI,CAAC,CACnC;aACF;SACF,CAAC;IACJ,CAAC;IAED,uEAAuE;IAE/D,KAAK,CAAC,KAAK,CAAC,IAAyB;QAC3C,MAAM,QAAQ,GAAG,IAAI,CAAC,WAAW,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;QAC7C,MAAM,KAAK,GAAG,MAAM,QAAQ,CAAC,IAAI,EAAE,CAAC;QACpC,OAAO,UAAU,CAAC,KAAK,EAAE,EAAE,KAAK,EAAE,KAAK,CAAC,MAAM,EAAE,CAAC,CAAC;IACpD,CAAC;IAEO,KAAK,CAAC,OAAO,CAAC,IAAyB;QAC7C,MAAM,QAAQ,GAAG,IAAI,CAAC,WAAW,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;QAC7C,MAAM,IAAI,GAAG,MAAM,QAAQ,CAAC,GAAG,CAAC,IAAI,CAAC,EAAE,CAAC,CAAC;QACzC,OAAO,YAAY,CAAC,IAAI,CAAC,CAAC;IAC5B,CAAC;IAEO,KAAK,CAAC,MAAM,CAAC,IAAyB;QAC5C,MAAM,EAAE,IAAI,EAAE,GAAG,MAAM,EAAE,GAAG,IAAI,CAAC;QACjC,MAAM,QAAQ,GAAG,IAAI,CAAC,WAAW,CAAC,IAAI,CAAC,CAAC;QACxC,MAAM,IAAI,GAAG,MAAM,QAAQ,CAAC,MAAM,CAAC,MAAM,CAAC,CAAC;QAE3C,uCAAuC;QACvC,IAAI,IAAI,KAAK,UAAU,IAAI,MAAM,CAAC,WAAW,EAAE,CAAC;YAC9C,MAAM,OAAO,GAAG,MAAM,aAAa,CAAC,IAAI,CAAC,IAAI,EAAE;gBAC7C;oBACE,SAAS,EAAE,MAAM,CAAC,WAAW;oBAC7B,OAAO,EAAE,8CAA8C,MAAM,CAAC,KAAK,IAAI,UAAU,6BAA6B;oBAC9G,OAAO,EAAE,MAAM,CAAC,OAAO;oBACvB,iBAAiB,EAAE,mBAAmB;iBACvC;aACF,CAAC,CAAC;YACH,MAAM,aAAa,GAAG,sBAAsB,CAAC,OAAO,CAAC,CAAC;YACtD,IAAI,aAAa,EAAE,CAAC;gBAClB,OAAO,aAAa,CAClB,+BAA+B,aAAa,EAAE,EAC9C,IAAI,CACL,CAAC;YACJ,CAAC;QACH,CAAC;QAED,iCAAiC;QACjC,IAAI,IAAI,KAAK,eAAe,IAAI,MAAM,CAAC,aAAa,EAAE,CAAC;YACrD,MAAM,OAAO,GAAG,MAAM,aAAa,CAAC,IAAI,CAAC,IAAI,EAAE;gBAC7C;oBACE,SAAS,EAAE,MAAM,CAAC,aAAa;oBAC/B,OAAO,EAAE,gDAAgD,MAAM,CAAC,KAAK,IAAI,UAAU,mBAAmB;oBACtG,OAAO,EAAE,MAAM,CAAC,OAAO;oBACvB,iBAAiB,EAAE,mBAAmB;iBACvC;aACF,CAAC,CAAC;YACH,MAAM,aAAa,GAAG,sBAAsB,CAAC,OAAO,CAAC,CAAC;YACtD,IAAI,aAAa,EAAE,CAAC;gBAClB,OAAO,aAAa,CAClB,oCAAoC,aAAa,EAAE,EACnD,IAAI,CACL,CAAC;YACJ,CAAC;QACH,CAAC;QAED,OAAO,aAAa,CAAC,GAAG,IAAI,CAAC,QAAQ,CAAC,IAAI,CAAC,UAAU,EAAE,IAAI,CAAC,CAAC;IAC/D,CAAC;IAEO,KAAK,CAAC,MAAM,CAAC,IAAyB;QAC5C,MAAM,EAAE,IAAI,EAAE,EAAE,EAAE,GAAG,OAAO,EAAE,GAAG,IAAI,CAAC;QACtC,MAAM,QAAQ,GAAG,IAAI,CAAC,WAAW,CAAC,IAAI,CAAC,CAAC;QACxC,MAAM,IAAI,GAAG,MAAM,QAAQ,CAAC,MAAM,CAAC,EAAE,EAAE,OAAO,CAAC,CAAC;QAChD,OAAO,aAAa,CAAC,GAAG,IAAI,CAAC,QAAQ,CAAC,IAAI,CAAC,UAAU,EAAE,IAAI,CAAC,CAAC;IAC/D,CAAC;IAEO,KAAK,CAAC,MAAM,CAAC,IAAyB;QAC5C,MAAM,EAAE,IAAI,EAAE,EAAE,EAAE,GAAG,IAAI,CAAC;QAC1B,MAAM,QAAQ,GAAG,IAAI,CAAC,WAAW,CAAC,IAAI,CAAC,CAAC;QACxC,MAAM,QAAQ,CAAC,MAAM,CAAC,EAAE,CAAC,CAAC;QAC1B,OAAO,aAAa,CAAC,GAAG,IAAI,CAAC,QAAQ,CAAC,IAAI,CAAC,IAAI,EAAE,UAAU,CAAC,CAAC;IAC/D,CAAC;IAED,uEAAuE;IAE/D,KAAK,CAAC,cAAc,CAAC,IAAyB;QACpD,MAAM,EAAE,EAAE,EAAE,GAAG,UAAU,EAAE,GAAG,IAAI,CAAC;QACnC,MAAM,QAAQ,GAAG,MAAM,IAAI,CAAC,IAAI,CAAC,kBAAkB,CAAC,MAAM,CAAC,EAAE,EAAE,UAAU,CAAC,CAAC;QAC3E,OAAO,aAAa,CAAC,qCAAqC,EAAE,QAAQ,CAAC,CAAC;IACxE,CAAC;IAEO,KAAK,CAAC,iBAAiB,CAC7B,IAAyB;QAEzB,MAAM,SAAS,GAAG,MAAM,IAAI,CAAC,IAAI,CAAC,kBAAkB,CAAC,SAAS,CAAC,IAAI,CAAC,EAAE,CAAC,CAAC;QACxE,OAAO,aAAa,CAAC,qBAAqB,EAAE,SAAS,CAAC,CAAC;IACzD,CAAC;IAEO,KAAK,CAAC,kBAAkB,CAC9B,IAAyB;QAEzB,MAAM,MAAM,GAAG,MAAM,IAAI,CAAC,IAAI,CAAC,kBAAkB,CAAC,UAAU,CAAC,IAAI,CAAC,EAAE,CAAC,CAAC;QACtE,OAAO,aAAa,CAAC,sCAAsC,EAAE,MAAM,CAAC,CAAC;IACvE,CAAC;CACF"}