Add Product Owner collaboration to the Architect role

[taras]

Why

The Architect currently consults the Product Owner only when it discovers a material choice. That lets user-facing interfaces, lasting architecture conventions, and product verification become settled without the iterative collaboration needed to build reusable product rules.

What changes

Before:

The Architect could finalize an apparently obvious interface or verification design independently. Product Owner feedback had no dedicated rulebooks, promotion process, or delegated path for applying an accepted rule later.

After:

The Product Owner leads public-interface, durable architecture-convention, and product-verification design. The Architect brings a first pass, applies approved rules autonomously, and interviews the Product Owner only where novelty, ambiguity, conflict, or an exception remains.

Approved reusable rules are recorded immediately. Every rule is one sentence of at most 160 characters, with rationale and examples kept outside it.

How it works

feature inventory → apply approved rules → show conforming decisions
                  → interview unresolved decisions → approve and record rules
                  → finalize architecture and verification

The role uses three rulebooks:

• .agents/product-interface.md
• .agents/architecture-rules.md
• .agents/product-verification.md

When the Product Owner says something is not understood, the Architect stops and uses the five-part Current, Intent, Reconsideration, Proposed, Feedback interview.

Component descriptions inherit the general product-interface process while retaining their specialized writing rules.

Review guide

Start with: .agents/architect.md

Then review:

1. The collaboration, misunderstanding-interview, delegation, and rule-promotion process.
2. The human-first interface rules and feature inventory.
3. The architecture ownership boundary and existing-debt treatment.
4. The Product Owner-led verification rules.
5. The inherited component-description interview.

Look carefully at:

• Approved rules delegate only conforming decisions; new rules still require explicit Product Owner approval.
• Rule approval authorizes only the corresponding rulebook edit, not GitHub or other project changes.
• Human clarity remains the standard even when agents author most XMD.

What must stay true

• The Architect brings a concrete first pass instead of asking the Product Owner to design from a blank page.
• Conforming decisions stay visible without requiring repeated approval.
• Interface and product verification approval precede finalized architecture and implementation handoffs.
• Adjacent debt becomes a proposed follow-up Story instead of silently expanding a feature.
• The Architect remains separate from implementation and existing GitHub authorization boundaries remain intact.

How to verify it

• git diff --check passes.
• A rule-length scan reports no maintained rule over 160 characters.
• Every referenced rulebook and inherited guide exists.

Scope

Included

• Product Owner collaboration in the Architect role.
• Product-interface, architecture, and product-verification rulebooks.
• The 160-character rule format and explicit promotion/delegation process.
• Product-interface inheritance for component descriptions.

Intentionally unchanged

• Runtime behavior, specifications, production architecture, and implementation roles.
• Existing product interfaces, architecture-document debt, and the test corpus; Audit XMD product interfaces for human clarity #766, Reconcile XMD architecture documents with approved design rules #767, and Audit XMD tests against approved product behavior #768 own those audits.

Follow-up debt

• Audit XMD product interfaces for human clarity #766 audits existing XMD product interfaces for human clarity.
• Reconcile XMD architecture documents with approved design rules #767 reconciles architecture documents with approved design rules.
• Audit XMD tests against approved product behavior #768 audits XMD tests against approved product behavior.
• Document reader-first executable workflow writing #668 remains the focused reader-first executable-workflow guide.
• Quest: Ensure every specification requirement has exactly one test #542 remains the requirement-to-test traceability Quest.

Risks and limitations

• The initial rulebooks are intentionally small. Their authority grows only through explicit Product Owner interviews and approval.
• Recovery is to revert this documentation-only commit; it changes no runtime or stored data.

Scope confirmation

• Every changed file supports the purpose described above.
• Unrelated cleanup and formatting changes are excluded.
• Generated or mechanical changes are clearly identified.
• The description matches the final diff and verification.

[github-actions]

PR #769: Add Product Owner collaboration to the Architect role

5 files, +257 / -46

Scope

✅ PR scope looks good.

Structural

✅ No structural bloat detected.

Slop

✅ Slop indicators look low.

Static Analysis

✅ Oxlint found no issues.

Correctness

No extraneous code patterns detected.