TSYSGroupAIOS/BASELINE-PROMPT.md

Global Baseline Prompt

The canonical set of working principles for every agent (AI or human) across every project. This is the source of truth; project AGENTS.md files inherit and specialize it. Derived from the owner's operating notes, deduplicated and stripped of project-specific detail.

Phase context: we have exited the "move fast and loose" phase. This is production infrastructure — it is in production right now. The bar is the bar.

---

1. You are an employee, not a lone genius

• Stop over-thinking. Get to code and output faster. Explore with code; gather ground truth. Do not burn tokens reasoning about things a quick command can answer.
• Ask questions early. Use a git-tracked questions-v(N).md file (see §9) that the human reviews inline. Questions, answers, and the reasoning behind decisions are often more important than the code. Capture and synthesize them to Discourse/Redmine.
• Don't ruminate or self-debate at length in context — gather data from the human, from code, or both, and proceed.
• You are not alone. Ask for guidance when you need it.

2. Token efficiency is a hard constraint

• The owner has a quota. Burning tokens to parse huge code blocks or reason about easily-answerable questions is unacceptable.
• Farm work out to deterministic tooling: linters, LSPs, formatters, test runners — run them, read their output, don't reason about what they can tell you.
• If an LSP is wired up for the language (code or docs), use it. If not, pull a Docker image and lint inside it. Prose linting belongs in a Docker image too.
• Use STATUS.md as a durable, git-tracked scratchpad for high-fidelity tactical notes (see §8) so context doesn't have to be re-derived.
• Use sub-agents as subcontractors for well-defined parallel deliverables (see §12), not as staff augmentation.

3. Systems of record (do not duplicate)

• Redmine is the single system of record for ALL project work — tickets, tasks, schedules, Gantt, dependency modeling. Use the redmine-cli tool. Gitea issues are not used.
• Discourse is the single system of record for documentation. It is all Markdown. Use the discourse-cli tool. Do not author long-form docs in gitea.
• Git-tracked .md files should be stubs that point to the relevant Discourse URL. Short operational files that must live next to code (e.g. AGENTS.md, STATUS.md) are the exception.
• Engineering already works this way. Operations now does too.
• Cross-referencing is mandatory. Every Redmine ticket links to its Discourse doc; every Discourse doc links to its Redmine ticket(s); every commit references [#NNN]; every PR links to both Redmine and Discourse. Keep them in sync at all times.
• Code, docs, and tests must be kept in sync at all times. When you change code, update the corresponding docs (Discourse) and tests in the same commit. Never leave them out of sync.

4. Infrastructure change approval workflow

For infrastructure (operations) work, agents do NOT execute changes without explicit human approval. The workflow is:

1. Prepare: Agent creates scripts, configs, and a plan. Documents the exact changes, blast radius, and rollback procedure in a Redmine ticket.
2. Review: Human reviews and approves (or rejects) via Redmine.
3. Execute: Agent applies the change ONLY after approval.
4. Verify: Agent verifies the change worked and documents results in Discourse.

This applies to all production infrastructure: network configs, host tuning, VM settings, DNS records, switch configs, etc. Read-only audits and probes do NOT require approval — only changes that alter system behavior.

Code projects (software development) follow normal git/PR workflow and do not require per-change Redmine approval.

5. Git workflow

• Use the tea CLI for pull requests.
• Work smart off master generally. Branches on the workstation are encouraged for moving fast, exploring ideas, and avoiding stash churn.
• Once work leaves the workstation, it goes through a PR.
• Branching strategy is open to per-project discussion.
• Commits and PRs must cross-link to Redmine tickets ([#NNN] in subject or body) and Discourse docs (in PR body).

6. CI/CD — shift left, keep in lockstep

• Strong preference that the local workstation can run the same CI/CD that the hosted infrastructure runs. Maintain them in lockstep across all projects.
• The further left CI/CD runs, the better. Catch it before push, before PR, before merge.
• We have a mix of developers and agents, some inside the hosted security boundary, some on beefy workstations. CI/CD must work for all of them.

7. Docker and Kubernetes for everything

• Use Docker and Kubernetes for everything — a cluster of 1 or 100 is the same. Don't presume scale. Containers are containers; k8s is k8s.
• All development work happens in containers — custom, off-the-shelf, or a mix. docker pull freely without asking.
• Container naming: never use Docker's default. Always name with a project prefix (e.g. <project>-<service>).
• Use Docker Compose with hook scripts to bring services up/down (lifecycle scripts). See ~/projects for established examples.
• Host hygiene is inviolable. The host runs only git, docker, and standard Unix utilities (awk, sed, grep, cut, tr, jq, find, xargs, etc.). No language runtimes or package-managed tools beyond the base OS.
  • One-off utility needed? docker pull a pinned image and run it ephemerally. Do not install on the host.
  • Broadly useful tool? Create a Redmine ticket requesting the human add it via the system package manager. Do not install it yourself.

8. Infrastructure-as-Code testing

• When working on IAC, test against the corresponding sectestbed- VM. These are snapshot-able to a known base state (Tailscale-joined, Beszel-registered, SSH keys in place). The base state evolves; the delta of tested code shrinks over time.
• A new functional-area VM starts in that ultra-basic base state and has roles applied on top.
• preprod- VMs are for testing upgrades to new vendor software versions — they carry a snapshot of current prod. Snapshot/rollback semantics are work-stream-specific and need explicit discussion.
• Compliance mitigations may need to flow through both sectestbed- and preprod- testing, in lockstep. Redmine Gantt and dependency-relationship modeling are heavily used here.
• Portability and reproducibility by anyone — do not require AWX as a prerequisite (optional nice-to-have; not mandatory for bootstrap).

9. STATUS.md — scratchpad, not system of record

• STATUS.md is a durable, git-tracked scratchpad for token efficiency. It is not the system of record (Redmine is).
• The agent fully owns STATUS.md; the human only consumes it.
• Use it for high-fidelity tactical notes as you work — input for commit logs, PRs, and Redmine updates.
• The harness todo tool is fine for tracking current work; STATUS.md is the durable cross-session record.
• STATUS.md has an Inbox section. When the human tosses new work mid-task in another conversation turn, do NOT pivot. Log it in the Inbox. If it's materially different, spin up a Redmine ticket.

10. Questions file — questions-v(N).md

• NEVER use a harness "question"/"ask user" tool (structured prompts, modal forms, tabbed questions, etc.). Ever. They are banned across every project. They are not portable across harnesses, they don't version history, and they bypass the git-tracked record. This is non-negotiable.
• All questions go in the git-tracked questions-v(N).md file. Write the question; the human edits the answer inline in the same file. This preserves history, works under every harness, and keeps reasoning next to the answer. Version up (questions-v2.md, …) when a round lands.
• Capture questions in a versioned file: questions-v1.md, questions-v2.md, …
• The human reviews and edits it inline. Version it when a round of answers goes in.
• Synthesize resolved Q&A into Discourse (decisions/rationale) and Redmine (work items).

11. Belt-and-suspenders protocol enforcement

• Enforce the rules in two layers: prose policy in AGENTS.md and mechanical enforcement in git pre-commit / pre-push hooks. Harness-specific hooks (e.g. Crush PreToolUse) are avoided — keep enforcement portable so it works under any agent framework.
• Never rely on memory or prose alone.

12. Gardening — keep docs from sprawling

• Run a routine gardening loop. Agents are disciplined with code but tend to sprawl .md files everywhere.
• Keep docs, code, and tests in sync at all times.
• scripts/garden.sh reports .md sprawl and files that should be migrated to Discourse.

13. Sub-agents as subcontractors

The owner has a quota; the driving context is the expensive one. The biggest token cost is prefix mutation, not per-call work — so keep the driving prefix stable and push volatility into side-channels (sub-agents, STATUS.md).

• Mandate: use sub-agents for any non-trivial search, audit, parallel review, or large-output read. Never read 10+ files sequentially — batch them into 2-3 agent calls.
• Self vs. delegate: read the 3-4 files you will immediately edit yourself (you need their content in-context for the edit anyway); dispatch agents for everything else.
• Output contract: request distilled findings only, never raw file contents. Specify the output format in the prompt. A sub-agent that returns a 500-line file dump has failed the contract.
• Parallelize independent work; chain dependent work (one agent's distilled summary feeds the next).
• Why: keeps the main context lean and preserves the cached prompt prefix.

This is scoped, contract-style work with a clear handback — not staff augmentation.

14. TDD and linting

• Red/green TDD for all code. Write the failing test first.
• Linters on all code, as early as possible. Be token-efficient — let deterministic tools find the issues.
• Prefer Unix utilities (awk, sed, grep, cut, tr, etc.) for file editing and text processing over built-in harness edit tools when feasible. Harness edit tools can be unreliable with whitespace/indentation; Unix tools are deterministic and exact.