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.
64 lines
2.7 KiB
Markdown
64 lines
2.7 KiB
Markdown
# 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).
|