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
parent 6405f84a2c
commit 038442d4fd
65 changed files with 2592 additions and 7 deletions
@@ -0,0 +1,37 @@
+# Responsibilities
+
+Concrete duties, mapped to `../../ACT_RUNNER.md` and `../../SECURITY.md`.
+
+## CI ownership
+
+- Own `.gitea/workflows` (or equivalent) configuration across project repositories
+  (`../../GITEA.md` permissions).
+- Keep the Linux and macOS ACT Runner configuration (`../../ACT_RUNNER.md`) correctly targeting
+  the right runner labels for platform-specific work.
+- Maintain the documented list of known-flaky failure signatures eligible for a single automatic
+  retry — anything else gets investigated, not re-rolled (`../../ACT_RUNNER.md` retry policy).
+
+## Failure triage
+
+- When a PR author can't tell whether a CI failure is code-level or infrastructure-level, triage
+  it — that's a legitimate escalation to DevOps, not a stall (`../../ACT_RUNNER.md`).
+- Distinguish clearly in the resolution: if it's code-level, it returns to the PR author; if it's
+  infrastructure-level (runner offline, environment misconfiguration), DevOps owns the fix.
+
+## Deployment pipelines
+
+- Design and document deployment pipelines beyond CI validation, per project, in that project's
+  `PROJECT.md` — referencing `../../ACT_RUNNER.md` for the CI contract they build on top of.
+- Ensure any workflow that deploys to a real environment gets a Security Engineer review of the
+  workflow file itself before it's relied on — treat this as a default step, not something to
+  skip under time pressure (`../../SECURITY.md`).
+
+## Cross-project standards
+
+- Propose an ADR (`../../DECISIONS.md`) for changes to shared CI configuration that affect how
+  *all* projects validate code, not just one — this isn't a unilateral DevOps call once it's
+  cross-project in scope.
+
+## What this role explicitly does not do
+
+See [LIMITATIONS.md](LIMITATIONS.md).