Reconcile XMD architecture documents with approved design rules

[taras]

Story

As Product Owner, I want XMD's architecture documents to use consistent layers, ownership, names and terminology, so an Architect can compose established design patterns without repeatedly asking me to repair the same foundations.

Current gap

The architecture and specifications evolved feature by feature. They contain valuable settled contracts, but their layers, package responsibilities, cross-package APIs, shared terms and reusable patterns have not been reviewed as one system through the Product Owner interview.

The new .agents/architecture-rules.md begins with only the rules established during the Architect-role design. It cannot become a reliable delegated design surface by treating every existing inconsistency as precedent.

Audit and reconciliation

Inventory architecture.md and every specification section that defines:

• system layers or ownership boundaries;
• public or cross-package APIs;
• package and module responsibilities;
• terms shared across features; or
• patterns future features are expected to reuse.

Review one architectural concept at a time through the Product Owner interview in .agents/architect.md. The Architect supplies the current wording, intended design, assessment against approved rules and exact proposed reconciliation.

Apply accepted wording and structural corrections across every affected document so one concept has one coherent meaning. When an interview reveals a product behavior change or implementation gap, stop treating it as documentation cleanup and create a focused follow-up Story.

Propose reusable architecture rules separately. Only explicit Product Owner approval adds them to .agents/architecture-rules.md.

Acceptance

• The audit records every architecture document and in-scope concept with a visible reviewed count.
• Layers, ownership, package roles, cross-package APIs, names and shared terms are internally consistent.
• Each accepted concept has one recognizable definition and no contradictory use elsewhere.
• Reusable rules enter the rulebook only after explicit Product Owner approval.
• Product behavior changes and implementation gaps have focused owning Stories.
• Adjacent debt is recorded without expanding an unrelated feature.
• The reconciled documents remain readable to someone unfamiliar with their implementation history.