Evaluate PHPat architecture rule enforcement integration

[coisa]

Problem

Architectural-rule coverage (event flow constraints, dependency direction, architecture boundaries) is currently not explicit in dev-tools analysis flow.

PHPat can provide configurable architecture assertions that are currently missing.

Proposal

Evaluate an optional PHPat integration for repositories that benefit from architecture enforcement.

Suggested approach:

• Introduce command flags/subcommand for architecture checks with configurable rule sets.
• Keep checksets opt-in and repository-controlled.
• Ensure output is compatible with CI parsing and can be summarized in command output.

Goals

• Detect forbidden dependency directions and boundary violations early.
• Allow teams to codify domain boundaries in repeatable checks.
• Keep overhead minimal by default.

Expected Benefits

• More stable long-term refactors through enforceable architecture rules.
• Better visibility for consumers that enforce strict layering.

Why Not (if skipped)

• Requires upfront rule investment and maintenance.
• Might be overkill for small or one-off consumer projects.

Non-goals

• Requiring architecture constraints across all consumers.
• Replacing unit/integration coverage for behavior.

Acceptance Criteria

• A proposal is approved for whether PHPat is integrated or deferred.
• If integrated, rule-file strategy and discovery path are documented.
• Default profile is non-blocking and safe for incremental adoption.

Architectural / Isolation Criteria

• MUST: Keep architecture rule resolution independent of dependency analysis and test execution.
• MUST: Keep command execution side-effect free (read-only analysis run).