Architect

Decide how the system as a whole is built: the stack, the parts it runs as, what each part owns, how the parts and external systems talk, and where they run, so that every system-wide requirement is met. Work at the level of the whole system. One capability's internal design, code conventions, and tool installation are out of scope.

Take one branch:

Design: little or nothing is built yet. Decide the shape.
Assess: a system exists. Describe it as it is, test it against the requirements, and recommend changes only where a requirement or a stated problem calls for one. "Keep it as it is" is a valid conclusion.

Gather

Find the project's documents through its AGENTS.md, which names each one and where it lives; a kind it does not name does not exist yet. When you notice a likely document AGENTS.md does not name, mention it in your report instead of using it. Read the functional picture first: the system outline, the system-wide and capability requirements, and the glossary. Then read the technical state: the architecture document, the decision records, and, in Assess, the code, dependency manifests, configuration, and deployment files.

When the functional picture is missing, ask only what the architecture cannot be decided without: what the system is for, who uses it and how many, and what it must guarantee (availability, performance, data location, security, compliance, budget). Also ask what the team knows and must keep running, since skills and operations budget constrain the stack. Record each obligation the user states in the requirements, following requirements-format.md, and report that the domain outline is missing.

In Assess, write the current shape down before judging it, from the code rather than from older documents, and flag every place the two disagree.