# shared/platform-tools is a git submodule (again)

Was vendored as a plain committed directory from 2026-09-24 to 2026-09-25
(`VENDORED.md`, since removed — its content is folded in below). Switched back
to a proper submodule on 2026-09-25 once the two concrete problems that broke
it the first time were fixed:

- `.gitmodules` now pins `branch = main` explicitly. The old submodule had no
  branch, so "Atualizar submódulo" fell back to `refs/remotes/origin/HEAD` — a
  ref a plain server-side clone never creates — and failed with
  `Unable to find refs/remotes/origin/HEAD revision`.
- The submodule URL is `../platform-tools.git` (relative, resolves to
  `https://git.andmore.pt/andre/platform-tools.git`), not `http://`. The old
  one used `http://`, which the origin answers with 523.

The third original reason ("the site is deployed by uploading files, so a
submodule is invisible to it") doesn't apply to fitme's actual deploy method —
`deploy.sh` does `git pull --ff-only` — so it no longer justifies staying
vendored once the other two are fixed. `deploy.sh` now runs
`git submodule update --init --recursive` after the pull, matching every other
`config/`-based platform in the fleet (fotografia, dsa, moremio, tickets).

**Before converting back (2026-09-25):** verified the vendored copy was
byte-identical to upstream `platform-tools@12f26fd` (the SHA it was frozen at)
— only difference was CRLF→LF normalization in four `social/` files, already
noted in the old `VENDORED.md`. Nothing site-specific was hand-patched into
the vendored copy, so nothing was lost by re-pointing at the submodule pinned
to that same commit.

To bump the submodule to a newer platform-tools commit: `git submodule update
--remote shared/platform-tools && git add shared/platform-tools && git commit`
(see the platform-tools README, "Wiring up a platform", step 6) — same as
fotografia.

## Deploy-on-push

`master` now deploys itself: Gitea webhook id 6 on `fitme3070.pt` (push, branch
`master`) POSTs to `api/platform.php?endpoint=auto_update` (the router — no
per-file `api/auto_update.php` stub needed, since the router's default target
for that endpoint already resolves to the same
`shared/platform-tools/api/auto_update.php` a stub would have required).
`AUTO_UPDATE_SECRET` is in `.env` on the VPS (not in git — see
`CLAUDE_GITEA/.auto-update-secrets` on Andre's machine), and
`system_settings.auto_update_enabled = '1'`. Toggle it off from Sistema →
Atualizar plataforma if a push needs to land without auto-deploying.

**Why the checkout stays group-writable (664/2775, `deploy:www-data`):** the
webhook's `git pull` runs *inside the PHP request*, as `www-data`, not as
`deploy`. Tried tightening to 644/2755 on 2026-09-25 (audit 2.6) and the very
next push failed with "Permission denied" creating a new file — reverted
within minutes. `config/cache/` and `assets/img/seo/` (the app's only two
runtime-write targets inside the checkout besides `uploads/`/`logs/`/
`backups/`, which already had their own volumes) got their own bind mounts
from `/srv/data/fitme.andmore.pt/` in `compose.yml`, same pattern fotografia
uses — but the checkout itself can't go read-only for `www-data` without
giving up deploy-on-push.