Document the repo, and stop server/data at the gitignore

The setup notes described moving the project as a tarball and never mentioned
git, because until now there was no repo. They now lead with the clone URL and
what a push needs — the credential helper, a token, and the hostname rather
than 10.3.8.90, since the stored credential is keyed to the hostname and a
remote written against the bare IP prompts every time.

server/.gitignore only excluded data/*.json, which was enough for the checklist
file and nothing else. Running the server locally creates data/uploads, data/docs
and data/backups beside it, so an attached PDF or a backup would have been
committed on the next add. The whole directory is ignored now. That data lives
on the NAS; a stale copy of it restored over production is the accident worth
designing out.

Also records that the NAS password is a keychain item rather than a file, so a
future machine knows to store it instead of hunting for the line that used to
be in build-deploy.sh.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Waters Church
2026-09-24 13:05:30 -04:00
co-authored by Claude Opus 5
parent 469db5bc60
commit 5770db370b
2 changed files with 48 additions and 1 deletions
+41
View File
@@ -5,6 +5,35 @@ deliberately **stay** on the Mac Studio.
---
## Source control
The project is in git, on the church Gitea:
**`http://chronicles-ab.waterschurch.org:3000/christian/recurring-checklist`** (private)
```bash
git clone http://chronicles-ab.waterschurch.org:3000/christian/recurring-checklist.git
```
That replaces the tarball below as the way to move the code — but **only the code**. Git
deliberately carries none of the secrets and none of the live data, so the "Restore the
secrets" section further down still applies to every new machine, and always will.
Pushing needs a credential for the Gitea. Store it once per machine and the osxkeychain
helper answers every push after that, unattended:
```bash
git config --global credential.helper osxkeychain
```
The first `git push` then asks for the username (`christian`) and a personal access token
with `write:repository`, generated at *Settings ▸ Applications* in the Gitea web UI. Write
the remote with the **hostname**, not `10.3.8.90` — the stored credential is keyed to the
hostname, and a remote written against the bare IP will prompt every time.
The forge is LAN-only. Cloning and pushing need the church network or a VPN into it, the
same as a web deploy.
## What to copy
`checklist-app-transfer.tgz` — the whole project minus `node_modules`, build output and
@@ -65,6 +94,18 @@ They are **not** in the transfer bundle on purpose. They are already in
chmod 600 ~/.appstoreconnect/private_keys/AuthKey_NXR7767SYK.p8
```
**The NAS password is a keychain item, not a file.** `build-deploy.sh` and
`backup-to-drive.sh` used to carry it in plaintext; they now read it from the login keychain,
so it stays out of the repo and rotating it is one command instead of a history rewrite.
Store it once per machine — omit the value and `security` prompts for it, so it never reaches
your shell history:
```bash
security add-generic-password -U -s checklist-nas -a Christian -w
```
Both scripts also accept `NAS_PASS` from the environment, for anywhere without a keychain.
Then fix the absolute path inside `keystore.properties`:
```
+7 -1
View File
@@ -1,4 +1,10 @@
node_modules
.env
data/*.json
*.log
# The live checklists, uploads, docs and backups. These belong on the NAS, not in
# the repo: the previous rule only caught data/*.json, so an uploaded PDF or a backup
# would have been committed. Ignore the directory outright — a stale copy restored
# over production is exactly the accident worth designing out.
data/
data-smoke/