Without a stable documentation entry point, readers have to reconstruct the mirror, release, and asset flows from code alone, which makes operational review and onboarding harder.
New contributors have to infer the runtime sequence and safety invariants from scattered README sections and code paths. That makes changes around release synchronization, delayed tag availability and non-deletion behavior easier to misunderstand.
The token expiry check read response headers that an earlier, unrelated
request had left behind in module state. Its correctness depended on call
order that nothing but a comment enforced, so inserting or reordering a
request would have silently checked the wrong response, or none at all.
The exit code had the mirrored problem: any function in the call tree could
raise a shared error count, so nothing at the top level revealed which steps
could contribute to a failing run.
Both now travel as return values. The ordering constraint becomes a data
dependency the interpreter enforces instead of a convention the next reader
has to know about.
The old name left the mirror direction open — it could just as well be read
as Gitea being the source. Naming source and target in that order removes the
ambiguity for anyone setting this up, and matches the title the README already
carried.
The name is not just internal: it is the install directory and the identifier
both APIs record in their request logs, so an inconsistent name would stay
visible in places that are awkward to correct after the fact.
Existing installations are not migrated. The old directory and its cron entry
survive an installer re-run and would sync a second time in parallel, so they
need to be removed by hand.
Gitea pull mirrors preserve Git refs but leave release notes and uploaded artifacts outside the backup. Without a separate synchronization path, restoring a repository would still depend on GitHub for important release context and binaries.