Projects
The project list and the generator workspace — file explorer, code editor, plugin inspector, and a console that previews each stage of the pipeline.
A project is a generator directory on disk: a generator.yml file together with the templates, scripts, samples and pattern files it refers to. Studio lists the directories found under the configured path.generators_dir and opens each of them in a workspace that edits the configuration and its files side by side.
Project list
Every project carries a badge for each instance registered against it, colored by that instance's status. The filters search by project name or by instance name, and narrow the list to projects that are in use or to those that no instance references.
The Create new button writes a new directory with a minimal generator.yml in it. Renaming a project also updates the instances that point at it; deleting one is refused while any instance still does.
The workspace
Four panels divide the workspace, and every divider between them can be dragged.
| Panel | Purpose |
|---|---|
| Explorer | The files of the project — create, upload, move, rename |
| Editor | Editing those files |
| Inspector | The plugins of the selected stage and their parameters |
| Console | Previewing the selected stage without running a generator |
Pipeline stages
The strip in the header is the generator's three-stage pipeline, and each entry names what the stage currently holds. Selecting a stage retargets the Inspector and the Console. Open files are unaffected.
So is the work in the Console. Generated timestamps, a running debugger session and typed-in sample events are all still there after switching stages and coming back.
Saving
The configuration and the project's files are edited in one place but saved as separate things.
- The Save button in the header writes the configuration together with every modified file. While anything is unsaved, the badge beside the button names what is pending — the configuration, a number of files, or both.
- The Save file button in the Editor header, or
Ctrl/Cmd+S, writes only the file currently in front of you.
Navigating away with anything unsaved asks for confirmation first.
Explorer
Files and directories are created from the panel header or from the right-click menu, and existing files are added with the Upload files button or by dropping them onto the tree from outside the browser — a drop lands in the directory under the cursor. Dragging an entry inside the tree moves it.
generator.yml is what makes the directory a project, so it cannot be renamed, moved or deleted here.
Editor
Files open as tabs and stay open until closed, including across a change of stage. Jinja, Python, JSON, YAML and Markdown files are highlighted; anything else opens as plain text. In a .jinja file, autocomplete covers the context variables and modules a template can reach.
Ctrl/Cmd+F opens find and replace, with case, whole-word and regular-expression matching. Ctrl/Cmd+Alt+G jumps to a line.
Files larger than 10 MB are not opened. Sample data of that size is better edited outside Studio.
Inspector
The Inspector holds the same three sections at every stage, filled from the stage selected in the pipeline strip.
The Plugins section lists what the stage is configured with, and adds or removes entries. The input and output stages accept any number of plugins; the event stage accepts exactly one.
The Parameters section holds the form for the selected plugin, validated against that plugin's configuration as you type. Fields that are not free text still accept ${params.name} and ${secrets.name} placeholders, which are resolved when an instance loads the configuration.
The Configuration section shows the YAML the form produces, exactly as it will be written into generator.yml.
Console
The Console exercises the selected stage on its own, without registering or starting a generator. Which tool it offers follows that stage.
| Stage | Tool | What it produces |
|---|---|---|
| Input | Timestamps preview | The timestamps the input plugins would emit, as a distribution and as a list |
| Event | Event debugger | Events rendered on demand, with the failures behind them |
| Event | Template state | The live state of the plugin the debugger is running |
| Output | Formatter preview | Sample events passed through a formatter |
The panel can be collapsed to its header, or maximized over the rest of the workspace.
Timestamps preview
The Generate button runs the input plugins and returns the timestamps they produce. The fields beside it decide what takes part and how the result is shaped: the Plugins field selects which of them run — left empty it runs all of them merged, as a generator would, and a subset isolates it — Count caps how many timestamps are generated, Time span sets the width of one histogram bin, and the Skip past switch starts the result at the first timestamp that is not in the past.
Each plugin has its own color in the distribution, stacked where they overlap. Four of them contribute to the run above: a workday curve, a per-minute heartbeat, an evenly spaced backfill and a burst at start. Beside the chart are the timestamps themselves; a long run lists the first and the last of them with the number skipped in between.
Event debugger
The Start button starts an event plugin from the current configuration and keeps it running; the Produce button renders events with it.
The Event timestamp and Tags fields stand in for what an input plugin would have supplied, so a template that branches on either is exercised through them. The Count field sets how many events one run produces from those same values, up to a hundred. With the Auto checkbox on, the timestamp is reset to the current time after each run.
Produced events are listed on the left, with an optional syntax to highlight them by. Failures are listed on the right, each naming the event it happened on, the reason and the traceback.
The plugin reads its templates when it starts and keeps them for the whole session. After editing a template, press Stop and then Start for the next run to use the new version.
Template state
The template plugin keeps state across renders, and the State view reads and writes that state on the plugin the debugger is running. It becomes available once a debugger session has been started.
| Scope | Reach |
|---|---|
| Local state | One template — pick it in the toolbar |
| Shared state | Every template of this generator |
| Global state | Every generator in the application |
Values are edited as JSON, individual keys can be deleted, and a scope can be cleared as a whole. Writing a key directly puts a template into a state a short debugging run would not otherwise reach.
Global state is shared with every running instance, not only the generator open in the workspace. Scenarios show which generators read and write which keys.
Formatter preview
Add raw events, choose a format with its options, and the Format button shows the payload a destination would receive, together with the errors the formatter raised and the event behind each of them.
The formatter is configured in the tool itself and is independent of the output plugins on this stage. The preview answers what a format does to an event, not what a particular destination is currently set to send.
When the configuration cannot be loaded
A generator.yml that fails to parse or validate leaves the stages with nothing to describe, so the pipeline strip, the Inspector and the Console are withdrawn and the workspace keeps the Explorer and the Editor. The alert reports what the validation rejected.
Fix the file in the editor, save it, then press the Reload button to bring the rest of the workspace back.
Monitoring
The application dashboard — aggregate pipeline flow, throughput and failure charts, each instance's share of the load, and host and process resources.
Instances
The instance list with live throughput and error counts, lifecycle controls, the per-instance metrics diagram, and the instance page with its settings and logs.