Development workflow
Use this page as a lightweight checklist for code changes.
Before changing code
Identify the owner package.
Check existing tests for the behavior.
Decide whether docs or changelog entries are needed.
Keep generated files out of the patch unless the source file is meant to be generated.
Where changes usually belong
Change type |
Start here |
|---|---|
App setup, Flask app, database initialization |
|
Runtime state |
|
Direct-control routes |
|
Workflow design routes |
|
Execution routes and queue entry points |
|
Workflow execution |
|
Workflow models and generated script behavior |
|
Type conversion and interface schema parsing |
|
Dynamic form behavior |
|
Database models |
|
Optional services |
|
Optimizer adapters |
|
If a change crosses several rows, document the boundary in the merge request or add a short developer page.
Changelog and docs
Update CHANGELOG.md when a change affects users, integrators, public behavior, dependency requirements, or release-visible bugs.
Update docs when a change affects:
UI workflows;
ivoryos.run(...)options;input type behavior;
generated proxy behavior;
route behavior;
optimizer configuration;
runtime behavior such as queue, pause, stop, retry, or cleanup.
Use Docs organization to decide where a page belongs.
Pull request checklist
The behavior is covered by a focused unit or integration test where practical.
Existing tests pass, or any failure is explained.
The docs build passes when docs changed.
User-facing behavior is mentioned in
CHANGELOG.md.Generated build output is not committed.
Runtime data under
ivoryos_data/is not committed.New public behavior has an obvious place in the user, integrator, or developer docs.
Generated docs pages
The suite README pages under docs/source/integrators/ are generated during the Sphinx build from upstream repositories:
client-api.mdmcp-server.mdplugins.md
Do not edit those generated files directly. Change their source repositories or update external_readmes in docs/source/conf.py.