feat(aidd-dev): report rule influence on development decisions

[waewoo]

Problem

aidd-dev:01-plan identifies project rules that apply to a planned file projection, and aidd-dev:05-review can cite a rule when it finds a violation. Neither provides an observable trace from a rule that materially influenced a development decision to the affected artifact.

When generated code is undesirable, a maintainer cannot reliably distinguish a bad implementation decision from an ambiguous, conflicting, or unsuitable project rule. Listing every rule available in context would not answer that question.

Scope

• Report a rule influence trace only when a project rule materially influences a development decision.
• For each reported entry, identify the rule, the decision, and the affected artifact or file where meaningful.
• Make the output explicit about its reliability: captured or observed influence where the workflow can support it; otherwise model-reported influence, never guaranteed provenance or hidden reasoning.
• Start from the existing rule-selection seam in planning; let the implementation decide whether the report belongs in plan output, implementation output, a shared AIDD-owned artifact, or a compatible extension of review reporting.
• Preserve a useful no-influence result when no project-specific rule materially affects the change.
• Keep generated application source free of provenance-only comments.

Acceptance criteria

• A development workflow can report a project rule that materially influenced a decision.
• Every reported entry identifies the rule and the decision it influenced.
• Every reported entry identifies an affected artifact or file when meaningful.
• The report does not mechanically list every rule loaded or available in context.
• An unrelated rule is not reported merely because it exists in the project.
• The output states whether each trace is captured, observed, or model-reported; it does not claim to prove internal LLM reasoning.
• No application source file is modified solely to persist rule provenance.
• A workflow with no materially influential project rule remains valid and reports no invented influence.
• Existing Plan, Implement, and Review behavior remains backward compatible unless the accepted design deliberately changes its contract.

Prior art in this repo

01-plan/02-explore already selects applicable project rules and justifies them. This is the strongest initial integration seam, but applicability is not material influence.

02-implement owns code transformation against an existing plan.

05-review/03-review-relevancy discovers declared rules and can cite a violated rule, but does not report influences that led to compliant decisions.

docs/ARCHITECTURE.md assigns code transformation to aidd-dev; therefore this concern belongs there rather than in aidd-context.

Related, complementary issues:

• feat(aidd-context): check existing rules for overlap or conflicts during rule generation #791 prevents overlap or conflicts while creating a new Rule.
• feat(aidd-context): audit an existing rule corpus for conflicts, duplication and drift #792 audits an existing Rule corpus for conflicts, duplication, and drift.
• feat(aidd-context): audit the project context architecture and ownership #793 audits context architecture and ownership across artifact types.

I checked open and closed issues, merged/open PRs, Discussions, and the current main contracts. No proposal covers Rule -> materially influenced decision -> artifact. PR #795 concerns session telemetry, not rule-to-decision traceability.

Out of scope

• Exposing chain-of-thought or claiming proof of internal LLM reasoning.
• Treating every loaded Rule as applied.
• Adding provenance comments to application source.
• Automatically rewriting, deleting, or resolving conflicts between Rules.
• Replacing feat(aidd-context): check existing rules for overlap or conflicts during rule generation #791, feat(aidd-context): audit an existing rule corpus for conflicts, duplication and drift #792, feat(aidd-context): audit the project context architecture and ownership #793, or redesigning the whole context architecture.
• Enterprise-specific behavior.