Align external plugin trigger capability and metadata docs

[haos666]

Summary

Follow-up to #316.

This aligns the external plugin manifest schema and plugin guide with the current runtime model:

• Add capabilities.triggers to plugins/manifest.schema.json
• Add capabilities.sql_dialect to the manifest schema and document the supported splitter dialect values
• Document trigger-related external plugin RPCs in PLUGIN_GUIDE.md
• Update the get_columns example to use the current runtime field names: default_value and is_pk

Notes

This PR intentionally does not implement trigger RPC forwarding or splitter behavior changes for external plugins. Runtime forwarding and Oracle-like block splitting will be handled separately so this schema/docs alignment remains low-risk and reviewable.

Validation

• python3 -m json.tool plugins/manifest.schema.json
• pnpm run typecheck
• pnpm run lint (passes with one existing warning in src/components/settings/LocalizationTab.tsx)

[kilo-code-bot]

Code Review Summary

Status: No Issues Found | Recommendation: Merge

Previously Reported Issues

File	Line	Issue	Status
plugins/PLUGIN_GUIDE.md	821	get_triggers result field mismatch (schema vs definition)	Fixed

Files Reviewed (2 files)

• plugins/PLUGIN_GUIDE.md — previous issue resolved; get_triggers now correctly documents definition; get_columns example updated to default_value and is_pk (matching runtime); trigger RPC docs align with backend signatures
• plugins/manifest.schema.json — schema additions for triggers and sql_dialect are correct and backward-compatible

---

_{Reviewed by kimi-k2.6-20260420 · 1,179,130 tokens}

[kilo-code-bot]

WARNING: get_triggers result field mismatch — the runtime TriggerInfo struct uses definition (optional string), not schema.

The backend and frontend models expect { name, table_name, event, timing, definition? }. Plugin authors returning schema here will have the field ignored, and omitting definition is fine when the driver provides it via get_trigger_definition instead.

Suggested change

	"schema": "public"
	"definition": null

[debba]

Thanks for the follow-up! Since this documents trigger RPCs and a sql_dialect capability that the host doesn't act on yet, I'd prefer to land the runtime forwarding first, so the guide never describes behavior external plugins can't actually use.

Do you plan to open a PR for the trigger RPC forwarding (and the splitter changes)? If that's coming soon, we can simply keep this one open and merge it right after that lands.

Otherwise, I'd suggest extracting the get_columns example fix (default_value / is_pk) into its own PR — that part is already accurate today and can be merged right away — while the trigger/sql_dialect schema and docs changes stay here, sequenced after the runtime implementation.

[haos666]

Thanks, that sequencing makes sense to me.

I'll keep this PR open for now rather than extracting the get_columns example fix separately. My plan is to follow up with runtime PRs first, then come back to this contract/docs PR once the behavior it documents is available in the host:

1. External plugin trigger RPC forwarding (get_triggers, get_trigger_definition, create_trigger, drop_trigger)
2. Oracle/DM splitter behavior for sql_dialect: "oracle" (/ terminator, PL/SQL-style blocks, DM CLASS / JAVA CLASS forms, q-quoting)

That should avoid merging guide/schema text ahead of runtime support, while keeping this PR as the docs/schema alignment companion once the runtime pieces land.