diff --git a/BASELINE-PROMPT.md b/BASELINE-PROMPT.md index 050ce4c..4bacc24 100644 --- a/BASELINE-PROMPT.md +++ b/BASELINE-PROMPT.md @@ -34,7 +34,28 @@ - **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. Git workflow +## 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. @@ -42,13 +63,13 @@ - 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). -## 5. CI/CD — shift left, keep in lockstep +## 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. -## 6. Docker and Kubernetes for everything +## 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. @@ -58,7 +79,7 @@ - **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. -## 7. Infrastructure-as-Code testing +## 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. @@ -66,7 +87,7 @@ - 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). -## 8. STATUS.md — scratchpad, not system of record +## 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. @@ -74,24 +95,24 @@ - 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. -## 9. Questions file — `questions-v(N).md` +## 10. Questions file — `questions-v(N).md` - Capture questions in a git-tracked, 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). -## 10. Belt-and-suspenders protocol enforcement +## 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. -## 11. Gardening — keep docs from sprawling +## 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. -## 12. Sub-agents as subcontractors +## 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 @@ -105,7 +126,7 @@ stable and push volatility into side-channels (sub-agents, STATUS.md). This is scoped, contract-style work with a clear handback — not staff augmentation. -## 13. TDD and linting +## 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.