Files
Christopher Clendening 038442d4fd Add ML and QA Engineer documentation and workflows
- 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.
2026-07-30 14:02:50 -04:00

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.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).