Audit XMD product interfaces for human clarity

[taras]

Story

As Product Owner, I want to review the interfaces people and agents type or read while using XMD, so the product becomes consistently understandable to humans and future interface design needs less intervention.

Current gap

The product-interface and component-description guides now define how new work is reviewed, but most existing syntax, commands, prompts, documentation, output and failures predate those rules. Existing wording and interaction patterns may be clear, inconsistent or misleading; there is no complete inventory or Product Owner-reviewed account of that debt.

#668 covers reader-first executable workflow writing. It does not audit every existing product interface.

Audit

Inventory and review:

• public XMD syntax, component forms and props;
• CLI commands, arguments, flags and interactive input;
• prompts, questions and choices shown by XMD;
• help, component descriptions and other product documentation;
• ordinary output, warnings, errors and refusals;
• generated artifacts presented to people; and
• internal agent prompts that shape product output.

Group related interfaces, record the total, and review one unresolved surface at a time through the Product Owner interview in .agents/architect.md. Show conforming surfaces and the approved rules that settle them without asking for approval again.

Each accepted interview outcome is either a correction local to the audited surface or an explicitly approved reusable rule. Record approved rules in .agents/product-interface.md; record runtime, compatibility or broader documentation changes as focused follow-up Stories rather than hiding them in an editorial pass.

Reconcile #668's workflow-writing guidance with the general product-interface process instead of creating a second interview or conflicting rules.

Acceptance

• The audit identifies every in-scope product interface and keeps a visible reviewed count.
• Every reviewed surface records the existing interface, intended behavior, applicable rules, proposed disposition and Product Owner feedback.
• Conforming surfaces name the rules that settle them.
• Reusable rules enter the rulebook only after explicit Product Owner approval.
• Every unresolved interface debt item has one owning follow-up Story and is not duplicated.
• Component descriptions continue to use their specialized guide while inheriting the general interface process.
• Document reader-first executable workflow writing #668 is reconciled with the resulting rules and interview.
• The audit does not change runtime behavior without a separate accepted product contract.