Developer Workflows Overview

Purpose

Developer workflows describe how to change Amvionlie without creating drift.

Normal implementation flow

1. Read the owner addon or central system.
2. Read nearby patterns before editing.
3. Identify the smallest responsible change.
4. Use central helpers instead of local duplicates.
5. Keep UI labels admin-friendly and free of developer diagnostics.
6. Lint changed PHP files.
7. Verify affected admin/public URLs return 200.
8. Update docs or changelog only where the task requires it.

Build path vs reference path

Tutorial pages should guide implementation in order. Reference pages should provide copyable shapes. Do not make a developer hunt through long samples before they know the build sequence.

Working in a dirty tree

There may be user or generated changes already present. Do not revert unrelated work. If a file has existing changes, work with them carefully.

Cleanup direction

Prefer removing old fallback/sample paths after a governed owner exists. Do not leave old code around as accidental future template code.

Practical standard

If a future developer can tell who owns the feature by reading the files, the change is probably heading the right way.