Apply Architecture Playbook

Treat every entry as an explicit owner preference, not a claim of universal optimality. Use a preference to choose a default only after it fits the system's actual constraints; expose deviations instead of forcing the preferred shape.

Authority and composition

Run this as a read-only preference application workflow. Inspect authorized context and return a brief in the conversation by default. Do not edit architecture documents, code, tracker state, or the dictionary itself; do not commit, push, or publish.

Apply authority in this order:

1. law, safety requirements, and consuming-repository instructions;
2. current explicit user direction within that user's decision authority;
3. accepted product behavior, architecture decisions, and operational constraints not explicitly superseded by their owning authority;
4. observed workload and system evidence;
5. this playbook's applicable preferences;
6. generic convention or popularity.

When authorities conflict, name the conflict and keep the preference unapplied unless the authority that owns the decision accepts a change. Do not convert an explicit invocation into blanket permission to replace an accepted architecture.