# 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).