workstation: agent-driven contribute flow for non-technical users [ci skip]

emo can't use git — his agent must do all VCS mechanics invisibly.
Managed claudeMd (every session, top precedence) now instructs agents:
commit -> push <os-user>/<topic> branch -> open PR via Forgejo API
(user's PAT from ~/.git-credentials) -> back to clean master -> tell
the user in plain words it's submitted for review. AGENTS.md carries
the full recipe with the curl call.

Verified live as emo: PR #1 opened (HTTP 201, write:repository scope
suffices) and closed via his PAT. Deployed to
/etc/claude-code/managed-settings.json; codex AGENTS.md mirrors for
emo + ancamilea regenerated from the new claudeMd.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

AGENTS.md

@@ -226,6 +226,33 @@ Per-workload opt-out: add the label `keel.sh/policy: never` on the Deployment me
 4. Viktor reviews → CI applies → Slack notification
 5. Portal: `https://k8s-portal.viktorbarzin.me/onboarding` for full guide
 
+### Non-admin workstation users — the AGENT does the git work
+
+Non-admin devvm users (power-user / namespace-owner tiers) may not know git at
+all. Their agent handles every version-control step silently — never ask them
+to commit, push, pull, or open a PR, and never surface git jargon at them.
+Their `~/code` clone arrives preconfigured: git identity, a `forgejo` remote
+authenticated via `~/.git-credentials`, and `master` tracking `forgejo/master`
+(auto-freshened hourly and at session launch, fast-forward only).
+
+To land a finished change from such a clone:
+
+1. `git checkout -b <os-user>/<short-topic> master` — always branch off fresh master
+2. Commit with a clear message (identity is preconfigured)
+3. `git push forgejo <os-user>/<short-topic>`
+4. Open the PR with the user's own PAT (`write:repository` suffices — verified 2026-06-10):
+   ```bash
+   TOK=$(sed -E 's#https://[^:]+:([^@]+)@.*#\1#' ~/.git-credentials)
+   curl -X POST -H "Authorization: token $TOK" -H 'Content-Type: application/json' \
+     https://forgejo.viktorbarzin.me/api/v1/repos/viktor/infra/pulls \
+     -d '{"title":"<title>","head":"<os-user>/<short-topic>","base":"master","body":"<what + why>"}'
+   ```
+5. `git checkout master` — leave the clone clean so auto-refresh keeps working
+6. Tell the user in plain language that the change is submitted for Viktor's review
+
+Direct pushes to `master` are rejected by branch protection; merging (and the
+CI apply a master push triggers) is admin-only.
+
 ## Common Operations
 - **Deploy new service**: Use `stacks/<existing-service>/` as template. Create stack, add DNS in tfvars, apply platform then service.
 - **Fix crashed pods**: Run healthcheck first. Safe to delete evicted/failed pods and CrashLoopBackOff pods with >10 restarts.

scripts/workstation/managed-settings.json

@@ -1,4 +1,4 @@
 {
-  "claudeMd": "# Viktor Barzin homelab — shared multi-user Claude Code Workstation (devvm)\n\nYou are running as a specific OS user on a SHARED devvm Workstation, not as the admin. These org-wide rules apply to EVERY user and sit at the top of settings precedence (they cannot be overridden by a user's own config):\n\n- Respect your permission tier. Your kubectl, Vault, and infra access are scoped to your RBAC tier (admin / power-user / namespace-owner). Do not attempt to escalate privileges or reach another user's resources.\n- Secrets are per-user. Never read another user's home directory, credentials, tokens, or ~/.claude secrets. Your own secrets live in your home at mode 600.\n- Infrastructure changes go through Terraform/Terragrunt (scripts/tg apply) — never direct kubectl apply/edit/patch. Pushing to git does NOT deploy; applies are manual and admin-gated, so your edits cannot take effect without an admin apply.\n- Follow the engineering rules in ~/.claude/rules/ (execution, planning, quality) and every CLAUDE.md in the repo tree.\n- The monorepo is at ~/code. Non-admins get a git-crypt-LOCKED clone: secret files read as ciphertext — that is expected, not an error.",
+  "claudeMd": "# Viktor Barzin homelab — shared multi-user Claude Code Workstation (devvm)\n\nYou are running as a specific OS user on a SHARED devvm Workstation, not as the admin. These org-wide rules apply to EVERY user and sit at the top of settings precedence (they cannot be overridden by a user's own config):\n\n- Respect your permission tier. Your kubectl, Vault, and infra access are scoped to your RBAC tier (admin / power-user / namespace-owner). Do not attempt to escalate privileges or reach another user's resources.\n- Secrets are per-user. Never read another user's home directory, credentials, tokens, or ~/.claude secrets. Your own secrets live in your home at mode 600.\n- Infrastructure changes go through Terraform/Terragrunt (scripts/tg apply) — never direct kubectl apply/edit/patch. Applies are manual and admin-gated: a non-admin's edits cannot take effect without an admin merge + apply.\n- Non-admins land changes via branch + PR, and the AGENT does ALL git/PR mechanics silently — the user may not know git, so never ask them to commit, push, pull, or open anything. When you finish a change in ~/code: commit it, push to a branch named <os-user>/<short-topic> on the forgejo remote, open a PR to master via the Forgejo API (token = the password field in ~/.git-credentials), then check out clean master again so background auto-refresh keeps working. Tell the user in plain words that the change is submitted for Viktor's review. Direct pushes to master are rejected (branch protection). Full recipe: AGENTS.md → 'Non-admin workstation users' in ~/code.\n- Follow the engineering rules in ~/.claude/rules/ (execution, planning, quality) and every CLAUDE.md in the repo tree.\n- The monorepo is at ~/code. Non-admins get a git-crypt-LOCKED clone: secret files read as ciphertext — that is expected, not an error.",
   "model": "claude-fable-5"
 }