Consider consolidating the seven copies of the GARDENER_STATE_DIR resolution

[dmccoystephenson]

Not filed as a bug — this is a documented decision, and the issue is whether to revisit it.

Seven modules resolve GARDENER_STATE_DIR with their own private copy of the same two lines: state.py, garden.py, merge_allowlist.py, overnight.py, notify.py, run_log.py, repo_lock.py.

Three of them say so explicitly. run_log.py:

# Same override and default as state.py/notify.py/overnight.py/
# repo_lock.py's own `_default_state_dir` — kept as a separate copy
# rather than a shared import, matching how those modules already each
# define it themselves.

repo_lock.py carries the same comment, and tests/test_run_log.py's docstring records it as "this repo's existing convention".

Why it might be worth revisiting

The stated reason is consistency with the other copies — which is circular: each copy is justified by the existence of the others, so the convention can only ever grow. There's no technical constraint behind it. state.py imports nothing from the package, so a shared helper (in state.py or a small paths.py) creates no import cycle for any of the seven. I checked the graph specifically for this.

The cost is real but currently invisible: these modules are two halves of the same conversations. The dashboard reads the logs dir run_log.py writes; cmd_overnight reads the cursor beside the db state.py records into; repo_lock.py's exclusion is only exclusion if every process computes the same lock path. A single copy drifting doesn't raise — it silently reads or writes somewhere else.

What's changed since the decision

#93 added TestStateDirIsHonouredEverywhere, which asserts all eight helpers agree in both the override and fallback cases, with filenames verbatim. So the drift risk is now detected even without consolidation — which arguably weakens the case for changing anything, and is worth weighing. It also means that if consolidation does happen, there's a safety net for it that didn't exist before.

Deliberately not implemented

I ran a cycle intending to do this refactor and stopped on reading the comments above. Undoing an explicitly recorded decision isn't something an autonomous loop should do on its own read of the tradeoff, so this is a proposal for the maintainer rather than a PR. Happy either way — "no, the convention stands" is a perfectly good outcome and worth recording in the issue if so, since the next reader will otherwise ask the same question.

Found while picking test-expansion targets from coverage.

drafted by Claude on behalf of Daniel Stephenson

[dmccoystephenson]

Deferred again this cycle, recorded here for the audit trail.

Two reasons, neither of which is a judgement on the proposal's merit. The cycle was spent adopting the carried-over PR #87 — it had gone CONFLICTING against main and needed a rebase, and the loop does not open a second PR while one is already open against the repo. Independently, this issue asks for a maintainer ruling on whether to undo an explicitly recorded convention, which is not a call an autonomous cycle should make on its own reading of the tradeoff — as the issue body itself argues.

To keep this from accruing an identical note every cycle: this should be treated as deferred by default until a maintainer rules one way or the other. "The convention stands" closes it just as well as a refactor would, and either answer is more useful recorded here than left open.

This comment was drafted during a Gardener session (https://github.com/Stephenson-Software/gardener).