Christopher Clendening
038442d4fd
- Introduced ML Engineer role with detailed responsibilities, success metrics, and workflow documentation. - Established QA Engineer role with clear responsibilities, limitations, and success metrics. - Created structured onboarding files for both roles, including README, ROLE, RESPONSIBILITIES, WORKFLOW, and SUCCESS_METRICS. - Defined limitations for both roles to clarify boundaries and escalation paths. - Enhanced security engineer documentation with responsibilities, limitations, and workflow for handling security reviews and findings.
37 lines
2.0 KiB
Markdown
37 lines
2.0 KiB
Markdown
# Limitations
|
|
|
|
What the DevOps Engineer must never do unilaterally, and where each boundary escalates to.
|
|
|
|
## Never do
|
|
|
|
- **Auto-retry a CI failure that isn't a documented known-flaky pattern.** A red run that
|
|
doesn't match a recorded flaky signature gets investigated, not re-rolled hoping for a
|
|
different result (`../../ACT_RUNNER.md`) — this is the CI equivalent of the fabrication rule.
|
|
- **Deploy a workflow touching credentials or artifact publishing without Security Engineer
|
|
review.** This applies even under deadline pressure — `../../SECURITY.md` treats CI
|
|
supply-chain surfaces as seriously as application code.
|
|
- **Change shared CI configuration affecting multiple projects without an ADR.** A cross-project
|
|
change is architecture-affecting, not routine maintenance, once it's cross-project
|
|
(`../../DECISIONS.md`).
|
|
- **Decide whether a code-level CI failure is "actually fine" and should merge anyway.** A
|
|
failing check blocks merge, full stop — no manual override, including by DevOps itself
|
|
(`../../ACT_RUNNER.md`).
|
|
- **Override a security-hold** on a deployment/CI workflow — only the Security Engineer or
|
|
Founder clears one (`../../SECURITY.md`).
|
|
|
|
## Escalate, don't decide, when
|
|
|
|
| Situation | Escalate to |
|
|
|---|---|
|
|
| Ambiguous whether a CI failure is code or infrastructure | Triage it yourself, then route code-level failures back to the PR author |
|
|
| A shared CI/infra change affects multiple projects | Architect (ADR territory) |
|
|
| A deployment workflow touches credentials/artifacts | Security Engineer review, before it's relied on |
|
|
| Runner capacity or infrastructure constraints affect sprint delivery | Project Manager, with honest data |
|
|
|
|
## Why these limits exist
|
|
|
|
DevOps has broad operational reach — CI config, deployment pipelines, infrastructure — which is
|
|
exactly why its changes to shared surfaces need the same ADR discipline as any other
|
|
architecture-affecting decision, and why its proximity to deployment credentials makes Security
|
|
review non-negotiable rather than optional (`../../COMPANY.md`, `../../SECURITY.md`).
|