Skip to main content

Studying the Default Plugin

The default plugin (plugins/default_plugin/) isn't just an example — it's the intended starting point. Its primary purpose is to be a complete, working reference for every part of the plugin contract, and the recommended way to build your own is to copy it and adapt. Time spent reading it pays back quickly.

What it demonstrates​

The default plugin exercises the whole contract with a generic "Thing" entity:

  • a manifest with all required fields and all four extension points;
  • the database pattern — entity object table, join table with is_deleted/is_archived, section/output/input domain tables, helper views;
  • workspace statuses and their progression (new → text_generated → input_provided → media_generated → completed);
  • active and final workspace pointers, and the creates_new_workspace branching in the result handler;
  • plugin-owned status transitions (the "provide input" step) via coreWorkspaceService.updateStatus;
  • finalization (frozen read-only mode) driven by the manifest's finalizable status;
  • consumption of core services and the frontend patterns (list page, manage page, workflow picker, execution history);
  • a test suite and a shared cleanup helper.

Whatever you're building, there's a good chance the default plugin already shows the pattern you need — read the relevant file before writing your own.

See it from the operator's side, too​

Reading the code shows you how it's built; it's just as valuable to see how it's used. The default plugin is what the Operator docs describe when they walk through managing a Thing, organizing sections, and finalizing — so the same reference implementation you're studying as a template is also a live product an operator drives. Walking that experience is the fastest way to build the empathy that separates a working plugin from a good one:

Study the code and walk the experience, and the rest of this package reads as "here's how the reference did each piece" — which is exactly the point.