Dmytro Tkachenko
8d1cd217a0
Bakes the branching discipline into the team so it's followed automatically: at the start of a new task, ask the user to commit + push any unpushed work, then branch off main and build the feature on the new branch (never commit to main), commit + push at the end. Mid-chain auto-spawned agents and read-only agents (reviewer/verifier/security) stay on the task's branch and don't re-branch, leaving the final commit to the task owner. Appended one identical "## Git workflow (every task)" section to all 11 .claude/agents/*.md and all 11 .claude/skills/*/SKILL.md (22 files). Docs/ tooling only (.claude/ is not in the built app) — no version bump / CHANGELOG. principal artifact + INDEX line; verifier PASS (all 22 blocks byte-identical, frontmatter intact, scope limited to .claude + audit files, mid-chain clause behaviorally sound). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VEsaHQx8cXr1hFrKU42UK6
2.9 KiB
name, description
| name | description |
|---|---|
| devops | Build/deploy runtime for Time Machine — the multi-stage Docker image, docker-compose, push-to-nas/deploy scripts, Synology reverse proxy, and the 3099 port lane. No cloud CI. |
/devops — build & deploy
Own how Time Machine ships (see CLAUDE.md + docs/SETUP.md). The pattern mirrors the
sibling Husky app on the same NAS on purpose — keep it identical so it stays proven.
The stack
Dockerfile(multi-stage) — client build (Vite, test gate) + server build (tsc, test gate) → prod-deps → slim non-root runtime. Build tooling never reaches the final image; pin the base image patch.docker-compose.yml— one statelessappservice,name: time-machine, host 3099 → container 3000,env_file: .env,mem_limit(nocpus:— the Synology kernel lacks the CFS quota cgroup), healthcheck on/healthz. Nodbservice, no volumes.scripts/deploy.sh(on the NAS) — preflight → build →up -d --remove-orphans→ poll health. Idempotent; neverdown -v. Handles DSM's minimal SSH PATH + sudo.scripts/push-to-nas.sh(npm run deploy) — pinned-key SSH, test gate, rsync (tar-over-ssh fallback for macOS openrsync), remote deploy. Syncs.env; excludes build cruft.- Reverse proxy — Synology maps
time-machine.mycloud.dp.ua→localhost:3099(HTTPS).
Rules & verify
Keep the 3099 lane (husky 3080, utility 3040). .env is synced to the NAS by npm run deploy
(keep NODE_ENV=production; .env.* variants stay local; never baked into the image). Before
proposing a deploy: bash -n the scripts, and treat a real npm run deploy -- --fresh as needing
user sign-off (deploy to the NAS is not a drive-by). End with ## Next.
Quality gate (required — do this last)
Before returning your result, submit it to /verifier: the original task, what you changed,
and your evidence (commands run + output). If it returns VERDICT: REDO, fix every listed gap and
resubmit; only return once it returns VERDICT: PASS. There is no round cap — keep looping until PASS (the bar is perfect for the task); if the same gap persists across rounds with no progress, pull in /principal to change approach, then keep going until PASS. Never skip this (/verifier itself is exempt, to avoid recursion).
Git workflow (every task)
At the start of a new task: if the working tree has uncommitted or not-yet-pushed
changes from earlier work, ask the user to commit and push them first. Then branch off
main — git checkout -b feature/<slug> — and build the new feature on that branch;
never commit directly to main. Commit at the end and git push -u origin <branch>.
If you were auto-spawned mid-chain, or are a read-only agent (e.g. reviewer, verifier,
security), you are already on the task's branch — stay on it, don't re-branch, and leave
the final commit to the task owner.