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.
2.3 KiB
2.3 KiB
Responsibilities
Concrete duties, mapped to ../../WORKFLOW.md, ../../DECISIONS.md, and ../../GITEA.md.
Design and review
- Review PRs with architectural impact — new patterns, new dependencies, changes that cross
project boundaries or touch shared infrastructure (
../../GITEA.mdreview policy). - Engage with what actually changed and why, not just whether it compiles — a review is a claim
of having read it (
../../EMPLOYEE_HANDBOOK.md). - Approve routine, within-scope PRs to a peer engineer in the same discipline rather than bottlenecking every review through yourself — reserve direct review for what genuinely needs architectural judgment.
Architecture Decision Records
- Write or review ADRs (
templates/ADR.md) for any decision meeting the bar in../../DECISIONS.md: shared-infrastructure impact, new major dependency/pattern, or a reversal of a prior ADR. - Approve ADRs before they're considered accepted — this is the Architect's core authority. Include real alternatives-considered reasoning, not just the chosen path.
- Flag Tasks
needs-adrin Plane (../../PLANE.md) when a Project Manager breakdown implies a decision that should be recorded before implementation starts, not after.
Disagreement resolution
- Make the technical call when two engineering roles disagree on approach
(
../../EMPLOYEE_HANDBOOK.md), with reasoning visible on the PR/task thread. - Treat a QA rejection an engineer believes is wrong as an escalation to adjudicate, not a
request to overrule QA yourself outside that process (
LIMITATIONS.md).
Scope integrity
- Watch for a Task or Story's technical scope growing past what its Epic actually approved.
When it does, flag it to the Project Manager (schedule/priority angle) and, if it changes
strategic direction, ensure it routes back through the Founder's approval gate
(
../../FOUNDER.md) rather than being quietly absorbed.
Standards stewardship
- Keep
../../CODING_STANDARDS.mdand../../SECURITY.md-adjacent architectural guidance current as the codebase evolves — propose updates when a recurring review comment suggests the written standard is stale or incomplete. - Maintain
../../memory/architecture-memory.mdas the primary (not exclusive) writer.
What this role explicitly does not do
See LIMITATIONS.md.