screen-locker/docs/design-audit/shared-gatelock-library.md
Krzysztof kuhy Rudnicki 40a2f28734 Split DESIGN_AUDIT_TODO.md into one file per audited surface
341 lines -> a 19-line index plus three topic files under docs/design-audit/:
the Python/Tkinter lock UI, the Flutter workout app, and the shared gatelock
library. Findings are unchanged -- same 6 entries, same three section headers,
verified by counting both before and after.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EveB813BQ8abAP68VSqZ5Y
2026-08-15 21:27:19 +02:00

1.5 KiB

Shared gatelock library

~/utils/gatelock is not its own git repo — git -C ~/utils/gatelock rev-parse --show-toplevel resolves to /home/kuhy/utils, so it's a subdirectory of the ~/utils monorepo. Per audit scope, gatelock itself was not walked against all 28 rules and no separate ~/utils/gatelock/DESIGN_AUDIT_TODO.md was written.

What's relevant here: gatelock defines exactly one real design token — LockConfig.bg: str = "#1a1a1a" (~/utils/gatelock/gatelock/_window.py:71), applied via self.root.configure(bg=self._config.bg, ...) in LockWindow.setup() (_window.py:143). Both consumer repos re-hardcode this same literal instead of reading it back off their own LockConfig instance:

  • screen-locker (this repo) — #1a1a1a appears 31 times across 9 files (see the Tkinter section above) despite screen_lock.py:148-153 constructing a LockConfig instance (as config) just a few lines above each of those files' widget-creation call sites.
  • diet-guard — not inspected as part of this audit (out of scope for this repo's report), but per the shared-infra note in the task, it is the other known consumer of LockConfig/LockWindow and should be checked for the same duplication pattern if/when a design audit is run there.

Fixing the screen-locker Rule 4 finding above by having widget-creation code read self._lock_config.bg (threaded through from the LockConfig already built in ScreenLocker.__init__) instead of re-typing "#1a1a1a" would close this loop without needing any gatelock-side change.