Salon_Assistant/AGENTS.md

Agent notes — Salon_Assistant / Lumina

What this repo is

Product seed for a NemoClaw + Hermes salon/spa owner assistant.
Remote: Gitea Ty_Tech/Salon_Assistant (via gitea_vps MCP only for this product’s Git ops).

Read first

1. design/DESIGN_PLAN.md
2. design/use-cases.md
3. design/scenarios.md
4. design/DECISIONS.md
5. docs/README.md (operator manuals)
6. This file’s Git hygiene — binding for every agent session
7. CONTRIBUTING.md for PR/branch detail

Hard rules

• Platform-first: nemohermes / openshell for config; no parallel control API.
• No build until user says build / implement.
• No gitea_mcp_for_ty / localhost Git MCP for this product — gitea_vps only.
• Owner never gets terminal/nano/docker instructions.
• No agent pay; no silent send/publish.
• design/ = product POR SSOT; docs/ = operator runbooks.
• Git hygiene below is mandatory for every agent (Grok, Claude, Cursor, subagents, scripts).

Git MCP

• Server: gitea_vps
• URL: https://giteamcp1.vps1.afterthedemo.com/mcp
• User-Agent: grok-connectors-manager/
• Repo: owner Ty_Tech, repo Salon_Assistant, default branch main

---

Git hygiene (mandatory)

Every agent that opens or works in this workspace must follow these practices. Deeper dirs inherit this file; do not weaken these rules in subdirectory AGENTS.md files.

Identity of the remote

Item	Value
Hosted remote	Gitea Ty_Tech/Salon_Assistant
Default branch	main
Agent Git / PR MCP	gitea_vps only
Forbidden	gitea_mcp_for_ty, localhost Git MCP, inventing a second product remote

Prefer local git for status/diff/commit/branch on the workspace clone; use gitea_vps for remote PR/branch/file ops against the product repo when MCP is appropriate. Never mix this product’s Git ops onto another MCP server.

Never (unless the user explicitly orders that exact action)

Action	Why
git config (any scope)	Do not change user or repo identity/settings
Commit or push secrets	.env, tokens, keys, OAuth dumps, provider credentials, PII exports
Force-push to main (or rewrite its history)	Shared default branch is protected by practice
--force / --force-with-lease push without explicit ask	Easy to destroy remote work
--no-verify / skip hooks	Hooks exist to catch mistakes
Amend a commit already pushed	Rewrites shared history
reset --hard, clean -fd, branch delete on remote	Destructive; confirm first
Push, open/merge PR, or tag release without user request	Shared/remote side effects need intent
Commit unrelated dirty files “while you’re at it”	Keeps history reviewable
Commit build artifacts, caches, venvs, logs, local IDE noise	Belongs in .gitignore
Paste secrets into commit messages, PR bodies, or issues	Transcripts and remotes leak

Always

1. Orient before mutating Git: git status, git diff / git diff --staged, and recent git log (e.g. git log -5 --oneline) so commits match repo style.
2. Work on a branch for anything beyond a trivial single-commit fix the user asked to land on main. Prefer names:
   • docs/…, design/…, chore/…, fix/…, feat/…
   • Base new branches on up-to-date main when practical.
3. Stage only intended paths (git add <paths>). Never git add -A / git add . without reviewing the full set.
4. Scan the staged diff for secrets before every commit (.env*, keys, tokens, cookies, private URLs with credentials).
5. Commit only when the user asks to commit/save/checkpoint (or an explicit workflow that includes commit).
6. Commit messages: concise focus line in imperative mood; 1–3 sentences of why when non-obvious. Match existing history tone. No secret data. No noisy AI trailer spam unless the user asks for a trailer.
7. Push only when the user asks. Prefer upstream tracking (-u) on first push of a branch.
8. PRs via gitea_vps: base main, clear title/body (summary + test plan / how verified), draft/WIP when incomplete. Do not merge unless asked.
9. Confirm before destructive or shared-visible actions: force-push, hard reset, remote branch delete, PR merge/close, rewriting published commits, mass file deletes.
10. Leave the tree honest: do not hide failures by amending away broken intermediate state the user still needs; do not discard uncommitted user work.
11. Respect “no build”: do not commit product implementation until build / implement is authorized; docs/design/scaffold hygiene changes are fine when requested.
12. Subagents inherit these rules. When spawning agents, point them at this file or restate: no secrets, no force to main, no push/PR/merge without user ask, gitea_vps only for product remote Git MCP.

Commit checklist (before git commit)

[ ] User asked to commit (or workflow explicitly includes commit)
[ ] Branch is correct (not accidental detached HEAD / wrong fork)
[ ] git status + staged diff reviewed; only intended files staged
[ ] No secrets, credentials, owner PII, or local absolute machine dumps
[ ] No caches/venv/logs/state that should be gitignored
[ ] Message explains purpose; matches repo style
[ ] Hooks will run (do not pass --no-verify)

Push / PR checklist

[ ] User asked to push and/or open PR
[ ] Branch name is descriptive
[ ] Remote is origin → Ty_Tech/Salon_Assistant (Gitea)
[ ] PR uses gitea_vps; base = main
[ ] Description states what/why and how checked
[ ] No secrets in PR text or screenshots paths

Recovering from mistakes

• Unstaged junk → restore files carefully; never clean -fd without listing what will die and getting confirmation.
• Bad unpushed commit → amend only if HEAD is yours, not pushed, and user wants amend; otherwise new commit or interactive fix with consent.
• Secret committed → stop; do not keep pushing. Tell the user; rotate credentials; remove from history only with explicit coordinated procedure (not casual push --force to main).

Related docs

• Branch/PR conventions: CONTRIBUTING.md
• Security / no secrets in git: SECURITY.md
• Ignore patterns: .gitignore