null
/
Privacy-Period-Tracker
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
Privacy-Period-Tracker/docs/TOOLS.md

4.4 KiB
Raw Blame History

Tools — where the scripts are, and which ones can stop you

Status: Current
Owner: _null
Last reviewed: 2026-08-18
Governs: scripts/**, .githooks/**
Review trigger: Any script added to, removed from or repurposed in scripts/; any
                change to which of them gates a commit or a release

A signpost, deliberately. Every project that adopts this template has a docs/TOOLS.md, so "read docs/TOOLS.md first" is an instruction that works without knowing anything about the project — which is the whole reason this file exists at a fixed path.

The list is not here

architecture/README.md holds the table of what this project has and what each script is. That is the one copy.

A second table here would be two records of one fact, and the other one would never hear that a script was renamed. So this file answers the questions that table does not, and points at it for everything else.

Period has six of them, and that is deliberate

The template this repository adopted ships around twenty scripts. Period took six. scaffold.sh copies none of them on purpose — "an unconfigured release.sh landing in every new repository is a loaded gun, not a head start" — so each one is taken having been read and configured.

The ones not taken were not forgotten. release.sh, deploy.py, backup.sh, restore-check.sh, preflight.sh, healthcheck.sh, migrate.sh, status.sh, dev.sh, audit-gate.mjs, release-notes.mjs, duplication.py and dead-code.py all assume a deployed Node or Postgres service with an npm dependency tree and a URL. Period is an Android app that ships through Google Play and has no server at all. A release here is an AAB and a Play Console submission, so security/SECURITY_CHECKLIST.md carries what release.sh would have gated.

Two were deferred rather than declined:

  • verify.sh — worth having once there is a real check suite to aggregate. Today ./gradlew check is the whole answer and wrapping it would add a layer that could only be wrong.
  • check-env.sh — its SPEC ships empty and exits 2 until it has entries, and Period has no environment variables yet. It gets taken with the first signing or Play credential, which is exactly the moment it becomes worth running.

If this project later grows a script the template already has, take that one rather than writing a new one — the arguments in its header are the part that took the longest.

Which ones can stop you

Not in a table, because the honest answer lives in each script's own header and would go stale here. The rule that matters:

Exit code 2 is never a pass. These scripts distinguish "the check ran and found nothing" from "the check did not run", because those look identical from the outside and only one of them is evidence. A hook or a CI step that treats a 2 as success has quietly turned the check off. Each script states its codes at the top; read them there.

The hooks are the other place work gets stopped: architecture/githooks/README.md has the one install command and the table of what each hook runs. Note that post-commit pushes, and that pre-commit here runs Gradle rather than the template's TypeScript typecheck.

Where to start in a fresh clone

  1. git config core.hooksPath .githooks — per clone, every time, and an uninstalled hook fails silently.
  2. bash scripts/secrets.sh --tracked — the one-time audit of what is already committed. The staged-diff mode is for the hook; this mode is for the day you clone.
  3. ./gradlew test — the prediction acceptance tests run on the JVM, so this needs no emulator and should be fast.
  4. architecture/GUARDS.md — how to write a check that can actually fail, before you write one. scripts/prove-guard.sh performs its first rule.

Adding one

Put it in scripts/, give it a header saying what it does and which incident motivated it, state its exit codes, and add a row to architecture/README.md's table — this file's Review trigger fires on exactly that.

The bar, from the scripts that are already here: done by hand three times, or once with a consequence. A script written before either of those has no failure to describe in its header, which is the part that stops the next person deleting it.