Align inherited feature requests with consumer needs and scenarios #88

Describe the change

Context and request

Contributors opening feature requests in PSModule repositories that inherit the organization defaults need to describe their need, motivation, and expected behavior without designing the implementation. Align the organization-owned feature intake with the user-confirmed Epic/PBI intent while preserving external feedback intake and maintainer routing. Internal Tasks and Bugs keep their technical decisions and test-first plans.

Acceptance criteria

• A contributor can explain what they want to do, who benefits, why it matters, and what they expect in a real situation, using ordinary language rather than architecture choices or literal Gherkin syntax.
• The form keeps its existing chooser name, description, title prefix, feature/triage labels, description field ID, and one required textarea. It adds no native issue type, assignee, project, mandatory planning fields, or prefilled answer.
• The introduction identifies the submission as feedback reviewed and routed by maintainers and links the canonical MSX issue and planning guidance instead of copying the standard.
• Focused assertions demonstrate the old implementation-first prompts fail the desired consumer contract, then pass for the updated form; GitHub form structure and routing checks pass before and after the edit.
• Only the feature form and its directly scoped test evidence change. The PR remains separate from PSModule/.github#82 and PSModule/.github#86.
• Final correspondence is checked against the frozen guidance/anchor handoff for MSXOrg/docs#228 and MSXOrg/docs#230; pending source work is not represented as adopted or complete.

Constraints and non-goals

Change .github\ISSUE_TEMPLATE\10-feature.yml and directly necessary focused evidence only. Bug/patch/general forms, fallback PR scaffold and README, Markdown CI/containment guards, YAML/hook onboarding, workflow permissions/rulesets, live labels, community-file copying/cleanup, and release documentation are out of scope. Do not merge, enable auto-merge, or change live governance.

Technical decisions

• Retain the existing two-element form: introductory Markdown and one required description textarea. Use the label Consumer need and expected behavior, three plain-language prompts, and optional placeholder starters. This preserves minimum submission usability and URL-prefill identity without adding mandatory sections.

• Ask exactly: What are you trying to do, and who would benefit?, Why does it matter, and what is difficult or missing today?, and In a real situation, what would you do and expect to happen?. Remove the solicitation for implementation suggestions and implementation alternatives.

• State that maintainers review and route feedback. Do not classify every external submission as an internal Task and do not change existing labels or native classification.

• Link the currently working MSX issue guidance and planning guidance. Implement against the confirmed intent now; the frozen correspondence check is verified against MSXOrg/docs#230 at 1c8f98cabe64b12aaa5fa9fb5f51b9d03f5de9de. Shipped links use currently working canonical pages without new anchors. The source PR is still unmerged; this is not a claim of adoption on main.

• Use the already available Pester 6.1.0 and powershell-yaml 0.4.12 tooling in tests\FeatureIntake.Tests.ps1 for a narrow regression contract. Check documented GitHub root/body keys, nonempty content, textarea validation, exact prompts, links, and routing. Do not introduce a general validation framework or CI configuration.

• Run existing yamllint --strict on the changed form and distinguish unchanged baseline style diagnostics from regressions. PSModule/.github#87 already owns the broader YAML formatting/enforcement gap; this Task does not claim that gap or the separate containment correction is complete.

• Use small logical commits. Open a draft PR after the first passing routing/schema-check commit; add the consumer assertions and demonstrate red locally before editing the form, then push only the passing final state.

• Add a YAML document start only to the edited feature form and wrap its new prose so targeted strict YAML lint passes without adding configuration or editing other forms.

Implementation plan

• Add and run passing baseline GitHub form-structure and preserved-routing assertions in tests\FeatureIntake.Tests.ps1; capture existing strict YAML diagnostics.
• Commit the passing baseline checks and open a separate early draft PR closing only this Task.
• Add exact consumer-prompt, placeholder, canonical-link, plain-language, and feedback-routing assertions; demonstrate their failure against the unchanged feature form before implementation.
• Replace only the feature form's implementation-first copy with the agreed consumer prompts and optional starters.
• Run the focused Pester suite, PowerShell analysis, YAML diagnostic comparison, canonical-link checks, and scoped diff review; record exact results and standards/convergence evidence in the PR.
• Check final correspondence against the supplied frozen canonical guidance/anchors, complete the author review handoff, and leave the PR unmerged for human review.

Review readiness

The scoped form contract, strict YAML lint, PowerShell analysis, frozen-source correspondence, standards pass, and exact-path convergence sweep are recorded in PSModule/.github#89 at a747f719e55056056ab4053e423643c031bf9028. Only this Task is delivered by that PR. The explicit Copilot author review approved the exact candidate head at 2026-10-31T16:35:54Z, covered both changed files, left zero inline comments, and reported no active review issues.

Formal readiness is not claimed: the actual candidate head reports only one successful copilot-pull-request-reviewer check and zero commit statuses (combined state pending). The active strict main rule requires Community file validation, bound to integration 15368, and that check is absent on this head, and MSXOrg/docs#230 remains unmerged. Both shipped canonical page routes work; no new anchor or source adoption on main is claimed. The separate validation/governance deliveries retain their scope.

Live hub metadata is a separate pre-existing observation: the declared feature label returns HTTP 404, while triage resolves the existing Triage label. The original declarations are preserved; no live label, native classification, permission, rule, or auto-merge setting is changed. This is not a fleet-wide claim.

The scoped draft and native Task were published in this session and the coordinator handoff was saved with the assigned work identity. The implementation plan is complete; the Task stays open until merge, and the PR stays draft while the recorded external CI/source gates remain unmet.