Continue development and diagnose problems
Preserve the existing add-on and technology choices, locate the actual fault, and perform the necessary checks.
Continue the same project
Confirm the add-on name, source, framework copy, page entry, and currently loaded location. Keep these for small changes; do not regenerate the add-on, change its identity, or overwrite the template just to restyle it.
With a separate source repository, edit source and update through the existing build/install flow. Do not manually edit source and installed copies simultaneously.
Identify the affected layer
| Symptom | Check first |
|---|---|
| Incorrect layout or images | Page source, build output, and resource URLs. |
| No response to clicks | Script loading, action names, registration after binding, and original errors. |
| Reads work but data stays stale | Invalidation notifications and component subscriptions. |
| Header will not drag or controls miss clicks | Transparency, hit markers, and drag exclusions. |
| Changes have no effect | Which files Blender loaded, and whether they were synchronized or restarted. |
Preserve the first error
Use existing status messages, diagnostics, or logs. Add minimal temporary diagnostics only if needed and remove them afterward. Do not swallow exceptions or build a permanent debug panel for a one-off issue.
If action or state is undefined, check whether whenNexusWebUIReady's result was mistaken for the SDK. Acquire the interface with acquireNexusWebUI.
Follow dependencies through the change
- Find existing source and calls instead of copying a second implementation.
- Change only what the issue requires. Decide framework upgrades, format migrations, and toolchain changes separately.
- Build frontend projects through their existing flow; update real entry references for static pages.
- Add new runtime files to the manifest and check references before removing or replacing files.
- Recheck the original issue and directly affected behavior. State what real behavior was not tested.
Leave a clear result for the next change
For example: name validation changed; empty or missing names show a reason; page syntax checked; real object reads await your confirmation. This is more maintainable than a vague Everything fixed.
When ready to deliver, see Packaging and delivery; before a framework update, see Updates and coexistence. Upgrading is not a universal troubleshooting method.