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 first explains how things work today and what is difficult or missing, then why a change is valuable and who benefits, then the additional need or desired change and expected behavior in a real situation. The form uses 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 Current situation and desired change, four plain-language prompts, and optional placeholder starters. Explain the current situation first, then lead the requested change with its value for the user before asking for the change and observable behavior. This preserves minimum submission usability and URL-prefill identity without adding mandatory sections.

• Ask in this order: How do things work today, and what is difficult or missing?, Who would benefit from a change, and why would it be valuable?, What additional need or change would you like to see?, and In a real situation, what would you do and expect to happen?. Use matching current-state, user-value, desired-change, and expected-result placeholder starters. Do not solicit implementation suggestions or 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 merged on November 3, 2026, and the canonical planning page now contains the verified consumer-expectations boundary and retained Task/Bug technical plans.

• 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 user-directed form revision is committed and published at 54b07712718d5f61e14d633e5de29ff8184659cf in PSModule/.github#89: all 25 parsed public form/routing checks, strict feature-form YAML lint, PowerShell analysis, and branch whitespace/scope checks pass. Seven changed prompt-order assertions failed before the form edit. The requested author review of this new head is pending; the old-head approval is not reused as current evidence.

The native PR remains open, not draft, unmerged, and with GitHub autoMergeRequest=null; this user-directed revision does not change its review state or enable landing. The source guidance in MSXOrg/docs#230 is merged and both shipped canonical pages resolve. The old unmerged-source dependency is resolved.

The new head initially has no check runs. The latest read-only branch-rules query returned no required-status-check rules; do not carry the October strict-check assertion forward as verified current governance. This delivery does not modify CI/validation/rules. The October missing-feature-label observation remains historical and untouched, not a new fleet claim.

Git transport returned repeated GitHub Internal Server Error rejections. The identical verified commit was published through the supported Git data APIs: matching root tree and commit SHA, fast-forward-only ref update, and independent ref/PR readback. No force-push, governance bypass, replacement commit, or PR-state change occurred.

User-directed current-situation-first revision

The November 4 request changes the sequence, not the intake or routing scope: establish the current situation before introducing the additional need or desired change, and lead that change with its value to the user. Task/Bug technical plans, external feedback routing, and the single required field are unchanged. The PR is already open for review; do not silently change its draft state or enable automatic landing.

• Update focused assertions for the current-situation-first introduction, exact ordered prompts, and matching optional starters; show the old form fails before editing it.
• Update only the feature form copy, retaining GitHub structure, submission requirements, identity, labels, and maintainer routing.
• Run focused Pester, strict YAML lint, PowerShell analysis, and diff checks; commit and push the verified revision and refresh the PR evidence and author review.