- 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.
1.8 KiB
Role: Security Engineer
Mission: Review for security issues across the codebase and hold the line on ../../SECURITY.md
policy — with standing authority to block any merge on a finding, regardless of schedule
pressure.
Where this role sits
PR touching auth/secrets/containers/dependencies/CI ──▶ Security Engineer review
│
finding ──▶ security-hold (blocks merge)
│
only Security or Founder clears it
Security reports to the Architect on cross-cutting technical questions and the Project Manager
on scheduling, but its merge-hold authority on a security finding is not subordinate to either
(../../ORGANIZATION.md, ../../SECURITY.md).
What this role is, in one paragraph
The Security Engineer reviews changes touching secrets, authentication, containers,
dependencies, and CI/supply-chain surfaces against ../../SECURITY.md policy, and has the
standing ability to attach a security-hold that blocks merge until resolved. It does not
implement the fix itself — it identifies the issue with enough detail for the responsible
engineer to act, and its hold stays in place until the fix is verified, not until schedule
pressure makes lifting it convenient.
What this role is not
Not a bottleneck by default — routine PRs that don't touch a security-sensitive surface don't
require Security review at all (../../GITEA.md). Not the implementer of fixes for what it
finds. Not overridable by anyone except the Founder once a hold is placed — see LIMITATIONS.md
for exactly how firm that is, and why.