feat(miner): add a systemd bare-host service example for the miner loop

[jaytbarimbao-collab]

Adds a systemd unit example so an operator can run the miner continuously on a plain Linux host without Docker — the non-Docker counterpart to DEPLOYMENT.md's fleet-mode docker-compose invocation, which was the only continuous-run path documented until now.

What this adds

• systemd/gittensory-miner.service.example — a ready-to-adapt unit that supervises gittensory-miner loop, with an install-steps header mirroring the existing gittensory-docker-prune.*.example.
• A "Bare-host (systemd, no Docker)" section in packages/gittensory-miner/DEPLOYMENT.md pointing at it.

Run model (the issue's requirement 1)

Determined from the code: gittensory-miner loop (bin/gittensory-miner.js → lib/loop-cli.js) is a long-running daemon (#5135) that schedules its own discover → attempt → manage cycles internally. So this is a persistent Type=simple service with Restart=on-failure — not a oneshot unit fired by a .timer, which is the right shape only for a genuine periodic batch like the existing gittensory-docker-prune job. The file header and DEPLOYMENT.md both call out that distinction.

Secrets guidance: GITHUB_TOKEN (and any coding-agent credentials) go in a root-owned 0600 EnvironmentFile, never in the unit file. systemctl stop sends SIGTERM, which the loop handles at its next kill-switch check.

Validation

• Template/docs only — no runtime logic touched.
• docs:drift-check, check-miner-package, git diff --check: all clean. Rebased onto latest main.

Closes #5197

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[loopover-orb]

Tip

🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩

✅ Gittensory review result - approve/merge recommended

_{Review updated: 2026-07-12 14:44:41 UTC}

2 files · 2 AI reviewers · no blockers · readiness 100/100 · CI green · clean

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
This adds a systemd unit example and DEPLOYMENT.md section for running `gittensory-miner loop` as a persistent daemon on a bare host, mirroring the existing docker-compose fleet-mode docs. The unit and doc content are well-reasoned (Type=simple + Restart=on-failure vs. a .timer, EnvironmentFile secrets guidance, SIGTERM/kill-switch behavior) and internally consistent between the two changed files. One discrepancy worth resolving before merge: the referenced `docker-compose.miner.yml` documents the continuous fleet-worker CLI subcommand as `run` ("`run` is the continuous fleet-worker loop"), while this PR's unit file and DEPLOYMENT.md addition use `gittensory-miner loop` as `ExecStart` — if these are actually the same subcommand under two names, the docs are inconsistent; if they're genuinely different subcommands, that distinction should be spelled out since an operator following only the new section could run the wrong command.

Nits — 6 non-blocking

• systemd/gittensory-miner.service.example doesn't set any hardening directives (e.g. `NoNewPrivileges=true`, `ProtectSystem=strict`, `ProtectHome=true`, `PrivateTmp=true`) that are conventional in example units running with a dedicated non-root user; worth at least a commented suggestion.
• The linked issue Add a systemd unit + timer example for running gittensory-miner continuously on a bare host (no Docker) #5197 asks for a "unit + timer example"; the PR explicitly argues (correctly) that a `.timer` is the wrong shape for a persistent daemon — worth calling that out plainly in the PR/issue thread rather than only in the file header, so the issue can be closed with an explicit rationale rather than silently diverging from its literal ask.
• `RestartSec=30` with no `StartLimitIntervalSec`/`StartLimitBurst` guard means a crash-looping process restarts indefinitely every 30s forever; consider documenting/adding a burst limit so a persistent failure doesn't hammer GitHub's API in a tight retry loop.
• Clarify in DEPLOYMENT.md whether `loop` and the fleet-mode `run` command (docker-compose.miner.yml) are the same operation under different names, or genuinely distinct, so the bare-host and fleet-mode docs don't silently diverge on the correct entrypoint.
• Consider adding `StartLimitIntervalSec=`/`StartLimitBurst=` to the `[Unit]` section as a commented example alongside the existing `Restart=on-failure` guidance.
• Diff looks like trivial or whitespace-only churn — Reduce whitespace-only or formatting-only churn and keep the diff focused on substantive changes.

Signal	Result	Evidence
Code review	✅ No blockers	2 reviewers, synthesized
Linked issue	✅ Linked	#5197
Related work	✅ No active overlap found	No same-issue or scoped active PR overlap found.
Change scope	✅ 20/20	Low review scope from cached public metadata (1 linked issue).
Validation posture	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 20 registered-repo PR(s), 9 merged, 1 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	jaytbarimbao-collab; Gittensor profile; 20 PR(s), 1 issue(s).
Gate result	✅ Passing	No configured blocker found.
Improvement	⚠️ ℹ️ Insufficient signal	risk: low · value: insufficient-signal — Nothing measurable for the structural-improvement analyzers on this PR (e.g. no code files changed). LLM value judgment: moderate — The PR fills a genuinely missing bare-host deployment path with well-justified systemd design choices, though its value is tempered by an unresolved run-vs-loop command-name inconsistency with the existing fleet-mode docs.

Linked issue satisfaction

Partially addressed
The PR delivers the core ask — a systemd service example for running `gittensory-miner loop` on a bare host, correctly reasoned as a persistent daemon (no unnecessary timer), plus DEPLOYMENT.md docs and install steps — but it places the file at top-level `systemd/gittensory-miner.service.example` rather than the issue's explicitly requested `packages/gittensory-miner/systemd/gittensory-miner.servi

Review context

• Author: jaytbarimbao-collab
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: not available
• Official Gittensor activity: 20 PR(s), 1 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Keep the PR focused and include validation evidence before maintainer review.

Signal definitions

• Related work = same linked issue, overlapping active PRs, or title/path similarity.
• Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
• Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
• Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
• Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

[BETA] Chat with Gittensory

Ask Gittensory a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.

• @gittensory ask <question> answers contribution-quality Q&A with source citations and freshness.
• @gittensory chat <question> answers in natural prose from cached decision-pack facts via local inference (maintainer/collaborator; read-only).
• A plain-language @gittensory mention with a real question is routed to the closest matching read-only command automatically -- no exact syntax required.

Full command reference: https://gittensory.aethereal.dev/docs/gittensory-commands

_{🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed}

---

💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →.

Checked by Gittensory, a quiet PR intelligence layer for OSS maintainers.

• Re-run Gittensory review

[loopover-orb]

Gittensory approves — the gate is satisfied and CI is green.