Internal Change Guide¶
Use this page when a change goes below the maintainer-facing APIs listed in the package reference. Internal modules are implementation areas, not stable public APIs, but each area has a clear owner and test surface.
Start from the behavior you need to change. Read the facade first, then the support modules and tests named in the same row. Prefer adding or adjusting a small test before editing support code.
Change Map¶
Editing Rules¶
Keep user-facing CLI commands declared in
pyproject.tomland implemented undersrc/dsw_document_template_tool/cli/.Keep GitHub Actions YAML as orchestration. Parsing, branch selection, migration policy, release staging, and GitHub API behavior belong in Python.
Keep generated files under ignored output roots. If a generated file needs to be reviewed, turn it into a fixture or release artifact intentionally.
Update docs and Sphinx API pages in the same commit as behavior changes.
When parser or translation-tree behavior changes, run unit tests, migration dry-run, and at least one preview/regression path before trusting the change.