- 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.
2.0 KiB
2.0 KiB
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.mdtreats 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).