|
| 1 | +# Add notice that git extension will no longer be enabled by default at 1.0.0 |
| 2 | + |
| 3 | +> **Source**: [#2165](https://github.com/github/spec-kit/issues/2165) — imported on 2026-04-12 |
| 4 | +
|
| 5 | +## Overview |
| 6 | + |
| 7 | +Add a deprecation notice during `specify init` to inform users that the git extension, currently auto-enabled by default, will require explicit opt-in starting with v1.0.0. This ensures users are aware of the upcoming behavioral change well in advance. |
| 8 | + |
| 9 | +## Problem Statement |
| 10 | + |
| 11 | +The `git` extension is currently bundled and enabled by default during `specify init`. Starting with v1.0.0, it will still be bundled but no longer enabled by default — users will need to explicitly opt in. Without advance notice, users may be surprised by this change when upgrading to v1.0.0. |
| 12 | + |
| 13 | +## Requirements |
| 14 | + |
| 15 | +### Functional Requirements |
| 16 | + |
| 17 | +- FR-1: During `specify init`, display a warning notice when the git extension is auto-enabled |
| 18 | +- FR-2: The notice must clearly state the timeline (v1.0.0) for the change |
| 19 | +- FR-3: The notice must explain how to opt in after the change (`specify init --extension git` or `specify extension add git`) |
| 20 | +- FR-4: The notice must be non-blocking (warning styling, does not halt initialization) |
| 21 | + |
| 22 | +### Non-Functional Requirements |
| 23 | + |
| 24 | +- NFR-1: Notice should use yellow/warning styling consistent with existing CLI warning patterns |
| 25 | +- NFR-2: Notice should be concise and actionable |
| 26 | + |
| 27 | +## User Scenarios |
| 28 | + |
| 29 | +### Scenario 1: User runs specify init and sees deprecation notice |
| 30 | + |
| 31 | +**Given** a user is initializing a new project with `specify init` |
| 32 | +**When** the git extension is auto-enabled as part of the default behavior |
| 33 | +**Then** a warning notice is displayed informing them that the git extension will require explicit opt-in starting with v1.0.0 |
| 34 | + |
| 35 | +### Scenario 2: User understands how to opt in after v1.0.0 |
| 36 | + |
| 37 | +**Given** a user sees the deprecation notice during `specify init` |
| 38 | +**When** they read the notice |
| 39 | +**Then** they understand they can use `specify init --extension git` or `specify extension add git` to enable the git extension after v1.0.0 |
| 40 | + |
| 41 | +## Acceptance Criteria |
| 42 | + |
| 43 | +- [ ] AC-1: `specify init` shows a notice when the git extension is auto-enabled |
| 44 | +- [ ] AC-2: Notice is visible but non-blocking (yellow/warning styling) |
| 45 | +- [ ] AC-3: Message clearly states the timeline (v1.0.0) and how to opt in |
| 46 | + |
| 47 | +## Out of Scope |
| 48 | + |
| 49 | +- Changes to the git extension itself or its functionality |
| 50 | +- Changes to the bundled status of the git extension (it remains bundled/shipped with spec-kit) |
| 51 | +- Actually removing the default-enabled behavior (that happens at v1.0.0, not now) |
0 commit comments