Express Epic and PBI issues as consumer expectations #228

Context and request

Authors and consumers of Epics and PBIs need issues to explain the consumer's need, expectation, and observable outcome rather than prescribe solution components or implementation checklists. The user confirmed a behavior-driven style for these aggregate types only; Tasks and Bugs retain their technical decisions and executable plans.

Acceptance criteria

• Epic/PBI guidance and examples describe consumer context, motivation, and observable scenarios at the appropriate altitude, without requiring architecture choices, file/function lists, or technical implementation plans in their bodies.
• Task/Bug guidance still includes consumer outcomes plus technical decisions, test-first plans, and evidence appropriate to a delivery leaf.
• Completion requires relevant design/documentation to reflect the delivered behavior, be updated where needed, and have aligned working links/instructions; an already-correct design is evidenced rather than churned.
• Issue planning/type/readiness pages, documentation templates, workflows, and the thin issue skill/instruction routes agree on those boundaries with one canonical process.
• Native hierarchy and aggregate completion remain valid, and existing documentation validation and complete review pass.

Technical decisions

Deliver one focused standards PR in MSXOrg/docs. Reconcile the Issues process/type pages, planning/readiness/completion guidance, documentation ownership and templates, and dependent thin pointers without duplicating a BDD process or creating another skill. Preserve the release communication contract already prepared in PR #209; do not fold this independent change into #209/#196/#208. Repository-specific community guidance is separate work, not permission for fleet file cleanup.

Implementation plan

• Compare current Epic/PBI/Task/Bug authoring examples and identify altitude contradictions before editing.
• Establish representative consumer scenarios plus Task/Bug technical-plan counterexamples.
• Align canonical issue/type/planning guidance and completion/documentation ownership while preserving native delivery-leaf mechanics.
• Reconcile all affected workflow/template/skill links and instructions with the owning pages.
• Run existing documentation checks and full review; record the expected consumer behavior and preserved delivery-plan evidence in the PR.