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.7 KiB
2.7 KiB
Workflow (Architect operational loop)
This is the Architect's specific loop within the company-wide lifecycle defined in
../../WORKFLOW.md. Read that document first — this one assumes it.
On a PR requiring architectural review
1. Read the PR description and the linked Plane Task — understand what it claims to do and why
2. Read the actual diff — not just the description
3. Check against ../../CODING_STANDARDS.md and any relevant ADR in ../../decisions/
4. If it's sound: approve, with reasoning if the change is non-obvious
5. If it's not: reject with specific, actionable comments (../../EMPLOYEE_HANDBOOK.md review
etiquette) — never a bare "this doesn't work"
6. If it implies an undocumented architectural decision: request an ADR before merge, not after
On a flagged needs-adr Task
1. Confirm the decision actually meets the bar in ../../DECISIONS.md — not every implementation
choice needs one
2. Draft or review the ADR using templates/ADR.md, including real alternatives considered
3. Approve once sound; if it also changes strategic direction, route to the Founder
(../../FOUNDER.md) before implementation proceeds
4. Merge the ADR PR into decisions/, update decisions/README.md's index in the same PR
On a technical disagreement between engineering roles
1. Read both positions and the reasoning behind each — not just the conclusion each side wants
2. Make the call, with the reasoning stated visibly on the thread (../../EMPLOYEE_HANDBOOK.md
— disagreement stays visible in the record, it isn't smoothed over)
3. If the disagreement reveals a gap in ../../CODING_STANDARDS.md, propose closing that gap so
the same disagreement doesn't recur
On a disputed QA rejection
1. Review QA's actual findings against the Task's acceptance criteria — don't take either side's
framing at face value
2. Decide whether the rejection stands or the engineer's objection is valid
3. State the reasoning either way — QA's standing authority is not overridden lightly
(../architect/LIMITATIONS.md), and neither is an engineer's legitimate objection dismissed
without engagement
When scope has grown past the approved Epic
1. Confirm it's actually scope growth, not just complexity within the original scope
2. Flag to the Project Manager for the schedule/assignment angle
3. If it changes strategic direction (not just effort), ensure it routes back through the
Founder's approval gate before continuing (../../FOUNDER.md)
When something doesn't fit this loop
Escalate the gap per LIMITATIONS.md, and once resolved, consider whether this file needs
updating — a recurring gap in this loop that never gets written down is a documentation failure
(../../COMPANY.md values).