`/openspec:proposal` Generates Non-Standard `proposal.md`

[YuanQY]

proposal.md

Title: Bug: /openspec:proposal Generates Non-Standard proposal.md Causing Warnings During Archive

Description:
The /openspec:proposal slash command generates proposal.md files that do not conform to the standard structure defined in openspec/AGENTS.md. This leads to non-blocking warnings during the openspec archive step, causing user confusion and requiring manual fixes or more complex workarounds in later stages of the workflow.

Steps to Reproduce:

1. Use the /openspec:proposal slash command to create a new OpenSpec change.
2. Observe the generated openspec/changes//proposal.md file.
3. Complete the implementation for the change.
4. Run the openspec archive command on the completed change.

Expected Behavior:

• The proposal.md file generated by /openspec:proposal should contain the standard markdown headers, specifically ## Why and ## What Changes, as required by the openspec/AGENTS.md conventions.
• The openspec archive command should execute without any warnings related to the structure of proposal.md.

Actual Behavior:

• The proposal.md file was generated with non-standard headers (e.g., ## 1.Objective, ## 3. Proposal).
• During the openspec archive command, the following non-blocking warning was displayed:
  1 Proposal warnings in proposal.md (non-blocking):
  2 ⚠ Change must have a Why section. Missing required sections. Expected
  headers: "## Why" and "## What Changes".

Root Cause Analysis:
The issue originates entirely from the /openspec:proposal command. The internal prompt or template used by this command to generate the proposal.md boilerplate is outdated or incorrect. It does not align with the project's own documented standards (openspec/AGENTS.md), leading to the creation of non-compliant files from the very beginning of a change's lifecycle.

Suggested Solution:
The internal template for the /openspec:proposal command must be updated to produce a proposal.md file that strictly adheres to the standard format. It should, at a minimum, generate the following structure for all new proposals:
1 # Change: [A brief title for the change]
2
3 ## Why
4 [A description of the problem or opportunity]
5
6 ## What Changes
7 - [A bulleted list of the proposed changes]
8
9 ## Impact
10 - Affected specs:
11 - Affected code:

By enforcing the standard at the point of creation, this fix will ensure that all new changes start with a compliant proposal file, preventing downstream issues and warnings during the archive phase. 

The attachment is the chat content exported from the Gemini CLI. ORI-133939-refactor-dedupe-traceability-bug.md

[YuanQY]

proposal.md This is the generated proposal file.