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.
49 lines
2.3 KiB
Markdown
49 lines
2.3 KiB
Markdown
# 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.md` review 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-adr` in 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.md` and `../../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.md` as the primary (not exclusive) writer.
|
|
|
|
## What this role explicitly does not do
|
|
|
|
See [LIMITATIONS.md](LIMITATIONS.md).
|