feat(miner-deployment): add Kubernetes StatefulSet + Secret example for AMS fleet-mode

[davion-knight]

Adds k8s/ example manifests so an operator can run N isolated miner workers on a small cluster with kubectl, instead of hand-rolling manifests or being limited to docker run/compose (#5181). Built on the existing packages/gittensory-miner/Dockerfile image.

Why a StatefulSet (not a Deployment)

Requirement #4 mandates per-pod isolated storage, never a shared PVC across replicas — because the miner keeps all state in local SQLite ledgers (claim-ledger.sqlite3, …) that are not safe for concurrent multi-pod access. A Deployment can only mount one shared PVC across every replica; a StatefulSet's volumeClaimTemplates give each replica its own PVC. So the manifest is a StatefulSet (in k8s/miner-deployment.yaml, filename per the issue), documented in k8s/README.md.

What's included

• k8s/miner-deployment.yaml — StatefulSet: configurable replicas, per-pod volumeClaimTemplate for /data/miner, CLI-worker resource requests/limits, runs the continuous run worker, GITTENSORY_MINER_CONFIG_DIR + secret-sourced GITHUB_TOKEN (+ optional provider keys), non-root securityContext.
• k8s/miner-secret.example.yaml — Secret template for GITHUB_TOKEN and optional ANTHROPIC_API_KEY / OPENAI_API_KEY placeholders.
• k8s/README.md — deploy sequence (kubectl apply secret → statefulset) + scaling (kubectl scale) + the StatefulSet rationale.

Validation

• test/unit/miner-k8s-manifests.test.ts (7 tests): the real manifests are well-formed Kubernetes (StatefulSet + Secret), a deliberately malformed manifest fails the structural validator, and the per-pod-storage invariant is asserted (has volumeClaimTemplates, rejects a shared-PVC config). Both sides exercised as real tests.
• Manifests parse as valid YAML; prettier-clean. Static infra only — no src/** logic, no runtime/governor/claim control-flow touched.

Closes #5181

[superagent-security]

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

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 94.34%. Comparing base (69708c1) to head (ff6e25d).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #5246   +/-   ##
=======================================
  Coverage   94.34%   94.34%           
=======================================
  Files         473      473           
  Lines       39982    39982           
  Branches    14576    14576           
=======================================
  Hits        37722    37722           
  Misses       1585     1585           
  Partials      675      675           

Flag	Coverage Δ
shard-1	46.29% <ø> (-0.15%)	⬇️
shard-2	34.71% <ø> (+0.12%)	⬆️
shard-3	32.11% <ø> (-0.04%)	⬇️
shard-4	31.85% <ø> (-0.24%)	⬇️
shard-5	33.57% <ø> (-0.15%)	⬇️
shard-6	45.07% <ø> (+0.21%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[loopover-orb]

Caution

🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥

🛑 Gittensory review result - reject/close recommended

_{Review updated: 2026-07-12 11:25:32 UTC}

4 files · 1 AI reviewer · 1 blocker · readiness 100/100 · CI failing · blocked

🛑 Suggested Action - Reject/Close

• Possible leaked secret in the diff (generic_secret_assignment) — Remove the secret from the diff, rotate the exposed credential, then re-run the gate.

Review summary
Adds a StatefulSet + example Secret + README for running the miner as a K8s fleet, with per-pod PVCs (correctly avoiding shared-PVC unsafety for the SQLite-based state) and a unit test suite that validates the manifests parse and enforces the per-pod-storage invariant via both a real-manifest check and a fabricated-negative-case check. The manifests are static infra (no src/** logic), the tests exercise the actual shipped YAML files (not fabricated payloads) for the positive cases, and the negative-case fixtures (malformed manifest, shared-PVC config) are appropriately synthetic since they test the validator's rejection logic rather than claiming the real manifest is broken. The 'GITHUB_TOKEN'/'ANTHROPIC_API_KEY'/'OPENAI_API_KEY' entries in miner-secret.example.yaml are clearly placeholder strings ('replace-with-...'), not real leaked secrets, so the external scanner hits are false positives worth noting but not blocking.

Blockers

• k8s/miner-deployment.yaml:32 sets `runAsUser: 1000` and mounts the PVC at `/data/miner` without `fsGroup`, so on the common root-owned `ReadWriteOnce` PVC path the worker cannot create its SQLite files; add the group ownership policy under the pod security context, e.g. `securityContext:\n runAsNonRoot: true\n runAsUser: 1000\n runAsGroup: 1000\n fsGroup: 1000\n fsGroupChangePolicy: OnRootMismatch`.

Nits — 5 non-blocking

• k8s/miner-secret.example.yaml:16-20 — the external secret scanner flagged these lines; they're clearly placeholder strings ('replace-with-a-real-github-token', etc.) so no action needed, but consider a comment noting these are intentionally non-functional to preempt future scanner noise.
• k8s/miner-deployment.yaml — `image: gittensory-miner:latest` combined with the default Kubernetes `imagePullPolicy` (IfNotPresent for a non-`:latest`... actually `:latest` defaults to `Always`) means every pod restart re-pulls; fine for an example but worth a one-line README caveat about pinning a real tag in production.
• k8s/miner-deployment.yaml — no `livenessProbe`/`readinessProbe` is defined for the worker; understandable for a CLI-loop process but worth a short README note since operators may expect probes by convention.
• test/unit/miner-k8s-manifests.test.ts — `validateK8sResource` is fairly permissive (only checks apiVersion/kind/metadata.name); fine for this PR's scope but the function name may overpromise more validation than it performs.
• Add a `storageClassName` example (commented out) in the `volumeClaimTemplate` per README's own note that operators may need to set one — currently only documented in prose, not shown in the YAML.

Why this is blocked

• Possible leaked secret in the diff (generic_secret_assignment) — Remove the secret from the diff, rotate the exposed credential, then re-run the gate.

CI checks failing

• validate
• validate-code

Signal	Result	Evidence
Code review	❌ 1 blocker	1 reviewer
Linked issue	✅ Linked	#5181
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: 111 registered-repo PR(s), 82 merged, 2 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	davion-knight; Gittensor profile; 111 PR(s), 2 issue(s).
Gate result	❌ Blocking	Repo-configured hard blocker found.
Improvement	⚠️ ℹ️ Insufficient signal	risk: clean · value: insufficient-signal — Nothing measurable for the structural-improvement analyzers on this PR (e.g. no code files changed).

Review context

• Author: davion-knight
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: Rust
• Official Gittensor activity: 111 PR(s), 2 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 is closing this pull request on the maintainer's behalf (CI is failing (validate, validate-code); Possible leaked secret in the diff (generic_secret_assignment)). This is an automated maintenance action — to pursue this change, please open a new pull request with the issues resolved. Closed PRs may be analyzed later to improve review accuracy, but they are not automatically reopened or re-reviewed.

[JSONbored]

Closing:

k8s/miner-deployment.yaml:32 sets `runAsUser: 1000` and mounts the PVC at `/data/miner` without `fsGroup`, so on the common root-owned `ReadWriteOnce` PVC path the worker cannot create its SQLite files; add the group ownership policy under the pod security context, e.g. `securityContext:\n runAsNonRoot: true\n runAsUser: 1000\n runAsGroup: 1000\n fsGroup: 1000\n fsGroupChangePolicy: OnRootMismatch`.