Merge upstream main into feat/4421-github-extension

Resolve the extensions catalog conflict by retaining the latest catalog metadata and the bundled GitHub extension entry.

Assisted-by: GitHub Copilot (model: GPT-5.6 Sol Fast (Internal only), autonomous)

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

Author: mnriem

.github/ISSUE_TEMPLATE/agent_request.yml

@@ -8,7 +8,7 @@ body:
       value: |
         Thanks for requesting a new agent! Before submitting, please check if the agent is already supported.
 
-        **Currently supported agents**: Alquimia AI, Amp, Antigravity, Auggie CLI, Claude Code, Cline, CodeBuddy, Codex CLI, Command Code, Cursor, Devin for Terminal, Docker Agent, Factory Droid, DeepSeek Harness, Firebender, Forge, Gemini CLI, GitHub Copilot, Goose, Grok Build, Hermes Agent, IBM Bob, Junie, Kilo Code, Kimi Code, Kiro CLI, Lingma, Mistral Vibe, Muse Code, Oh My Pi, opencode, Pi Coding Agent, Qoder CLI, Qwen Code, RovoDev ACLI, SHAI, Tabnine CLI, Trae, ZCode, Zed
+        **Currently supported agents**: Alquimia AI, Amp, Antigravity, Auggie CLI, Claude Code, Cline, CodeBuddy, Codex CLI, Command Code, Cursor, Devin for Terminal, Docker Agent, Factory Droid, DeepSeek Harness, Firebender, Forge, Gemini CLI, GitHub Copilot, Goose, Grok Build, Hermes Agent, IBM Bob, Junie, Kilo Code, Kimi Code, Kiro CLI, Lingma, MiniMax Code, Mistral Vibe, Muse Code, Oh My Pi, opencode, Pi Coding Agent, Qoder CLI, Qwen Code, RovoDev ACLI, SHAI, Tabnine CLI, Trae, ZCode, Zed
 
   - type: input
     id: agent-name

.github/ISSUE_TEMPLATE/bug_report.yml

@@ -89,6 +89,7 @@ body:
         - Kimi Code
         - Kiro CLI
         - Lingma
+        - MiniMax Code
         - Mistral Vibe
         - Muse Code
         - Oh My Pi

.github/ISSUE_TEMPLATE/feature_request.yml

@@ -83,6 +83,7 @@ body:
         - Kimi Code
         - Kiro CLI
         - Lingma
+        - MiniMax Code
         - Mistral Vibe
         - Muse Code
         - Oh My Pi

.github/workflows/stale.yml

@@ -22,13 +22,33 @@ jobs:
           days-before-close: 30
 
           # Stale issue settings
-          stale-issue-message: 'This issue has been automatically marked as stale because it has not had any activity for 60 days. It will be closed in 30 days if no further activity occurs.'
-          close-issue-message: 'This issue has been automatically closed due to inactivity (90 days total). If you believe this issue is still relevant, please reopen it or create a new issue.'
+          stale-issue-message: >-
+            This issue has been automatically marked as stale because it has had no activity for 60 days.
+            It will be closed in 30 days unless there is a substantive update. If the problem still applies,
+            please provide updated context such as whether it is still reproducible, the affected version or
+            environment, its current impact, and any new reproduction details. A comment that only states that
+            the issue is "still relevant" does not give maintainers enough information to reconsider it.
+          close-issue-message: >-
+            This issue has been automatically closed after 90 days without activity. To request reconsideration,
+            please provide updated reproduction details, the currently affected version or environment, and the
+            present impact. Ask a maintainer to reopen this issue if it is fundamentally the same problem. If the
+            scope or reproduction has materially changed, create a new issue, link this one, and explain what has
+            changed.
           stale-issue-label: 'stale'
 
           # Stale PR settings
-          stale-pr-message: 'This pull request has been automatically marked as stale because it has not had any activity for 60 days. It will be closed in 30 days if no further activity occurs.'
-          close-pr-message: 'This pull request has been automatically closed due to inactivity (90 days total). If you believe this PR is still relevant, please reopen it or create a new PR.'
+          stale-pr-message: >-
+            This pull request has been automatically marked as stale because it has had no activity for 60 days.
+            It will be closed in 30 days unless there is a substantive update. If you intend to continue, please
+            describe the current status, address or acknowledge outstanding feedback, and confirm whether the
+            branch can be updated and the change remains ready for review. A comment that only states that the
+            pull request is "still relevant" does not provide enough context for maintainers.
+          close-pr-message: >-
+            This pull request has been automatically closed after 90 days without activity. To request
+            reconsideration, please explain why the change is still needed, confirm that the implementation is
+            current and ready for review, and address any outstanding feedback or conflicts. Ask a maintainer to
+            reopen this pull request if the existing branch and approach remain valid. Otherwise, create a new pull
+            request, link this one, and explain what has changed.
           stale-pr-label: 'stale'
 
           # Exempt issues and PRs with these labels from being marked as stale

docs/community/extensions.md

@@ -116,7 +116,7 @@ The following community-contributed extensions are available in [`catalog.commun
 | OpenUP Governed Lifecycle | Adds the OpenUP lifecycle to Spec Kit: phases, iterations, a seven-level WBS, an executable risk register, bi-directional traceability, and machine-checkable milestone gates. | `process` | Read+Write | [specup](https://github.com/anvigo12/specup) |
 | Optimize | Audit and optimize AI governance for context efficiency — token budgets, rule health, interpretability, compression, coherence, and echo detection | `process` | Read+Write | [spec-kit-optimize](https://github.com/sakitA/spec-kit-optimize) |
 | Orchestration Task Context Management | Adds subagent work-unit orchestration to generated Spec Kit task files | `process` | Read+Write | [spec-kit-orchestration-task-context-management](https://github.com/benizzio/spec-kit-orchestration-task-context-management) |
-| OWASP LLM Threat Model | OWASP Top 10 for LLM Applications 2025 threat analysis on agent artifacts | `code` | Read-only | [spec-kit-threatmodel](https://github.com/NaviaSamal/spec-kit-threatmodel) |
+| OWASP LLM Threat Model | OWASP Top 10 for LLM Applications 2026 threat analysis on agent artifacts | `code` | Read-only | [spec-kit-threatmodel](https://github.com/NaviaSamal/spec-kit-threatmodel) |
 | PatchWarden Evidence Pack | Map Spec Kit tasks into a guarded PatchWarden Goal and export bounded, traceable evidence for an accepted lineage. | `process` | Read+Write | [spec-kit-patchwarden](https://github.com/jiezeng2004-design/spec-kit-patchwarden) |
 | Plan Review Gate | Require spec.md and plan.md to be merged via MR/PR before allowing task generation | `process` | Read-only | [spec-kit-plan-review-gate](https://github.com/luno/spec-kit-plan-review-gate) |
 | PR Bridge | Auto-generate pull request descriptions, checklists, and summaries from spec artifacts | `process` | Read-only | [spec-kit-pr-bridge-](https://github.com/Quratulain-bilal/spec-kit-pr-bridge-) |

docs/community/friends.md

@@ -20,3 +20,5 @@ Community projects that extend, visualize, or build on Spec Kit:
 - **[spec-kit-copilot](https://github.com/github/spec-kit-copilot)** — *First-party GitHub project.* A GitHub Copilot **skills plugin** that exposes the Spec Kit `specify` CLI to the Copilot agent in both the Copilot CLI and the GitHub Copilot app. It provides a focused skill per `specify` command group — setup, init, check, extensions, presets, bundles, workflows, workflow steps, and self-upgrade — so you can navigate and drive the entire Spec Kit ecosystem through natural language, letting Copilot decide when and how to run the right `specify` commands on your behalf.
 
 - **[Spec Kit Workflow Cockpit](https://github.com/markuswondrak/spec-kit-workflow-cockpit)** — A terminal control panel for running Spec Kit workflows locally. It replaces the fragmented CLI flow with a single live view: see the whole workflow at a glance, follow progress node by node, read and edit feature documents at human review gates without leaving the terminal, and make gate decisions from clearly presented options with confirmation. It also provides a `cockpit-run-context` skill that connects your interactive coding session directly to the current workflow run.
+
+- **[Specstride](https://github.com/mairp/specstride)** — A standalone implementation orchestrator that consumes a Spec Kit feature's `tasks.md` and uses its `spec.md`, `plan.md`, and contracts as read-only context. It runs a coding agent (Claude Code, Codex, or a local model) through the task phases one at a time. Each phase advances only when a separate LLM critic approves its evidence against the acceptance criteria and the code. Stuck phases get a diagnostician and a narrowed retry. An opt-in loop learns per-phase settings from run telemetry and reverts any change that makes things worse.

docs/guides/monorepo.md

@@ -78,8 +78,14 @@ ERROR: SPECIFY_INIT_DIR is not a Spec Kit project (no .specify/ directory): /hom
 ```
 
 `SPECIFY_INIT_DIR` selects the **project**; `SPECIFY_FEATURE_DIRECTORY` selects
-the **feature** within it. They compose: set both to pick a project and a
-feature non-interactively. See the
+the **feature**. A relative feature path is joined to that project root
+without a containment check, so a value like `../shared-feature` still
+resolves outside it; an absolute path is used as-is and may likewise point
+outside the project root. Either way, the selected feature directory is not
+required to live inside it — the project root identifies the Spec Kit project
+and its command/configuration context, not a containment boundary for feature
+documents. They compose: set both to pick a project and a feature
+non-interactively. See the
 [`SPECIFY_INIT_DIR` reference](../reference/core.md#environment-variables) for
 the full contract and the two-axes model.
 

docs/reference/bundles.md

@@ -174,6 +174,8 @@ from; `discovery-only` sources appear in `search` and `info` but refuse
 installation. Inspect the active stack before installing a bundle from a
 non-default source.
 
+> **Vet both the bundle source and its component catalogs.** A project can supply its own bundle catalog and `install-allowed` component catalogs (extension, preset, workflow, and step) under `.specify/`; that project configuration existing is not evidence anything in it was reviewed. Before installing a bundle from an unfamiliar project, run `specify bundle catalog list` — and the equivalent `extension`/`preset`/`workflow catalog list` and `specify workflow step catalog list` commands for the components it pulls in — and treat any source you didn't add yourself as unvetted until you've reviewed it.
+
 ### List the Catalog Stack
 
 ```bash

docs/reference/core.md

@@ -52,11 +52,11 @@ specify init my-project --integration copilot --preset compliance
 | ----------------- | ------------------------------------------------------------------------ |
 | `SPECKIT_INTEGRATION_DEFAULT` | Override the fallback integration used by `specify init` when `--integration` is omitted (interactive prompt default and non-interactive fallback). Set it to any registered integration key (e.g. `gemini`, `claude`). An unrecognized value is ignored with a warning and the built-in default (`copilot`) is used. An explicit `--integration <key>` always takes precedence. |
 | `SPECIFY_INIT_DIR` | Target a member project from outside its directory (e.g. a monorepo root) without `cd`, for non-interactive / CI use. Set it to the **project root** — the directory *containing* `.specify/` (relative paths resolve against the current directory). The path must exist and contain `.specify/`, otherwise the command errors and does **not** fall back to the current directory. Resolved once in the core root helper (`get_repo_root` in Bash, `Get-RepoRoot` in PowerShell), so it is honored by the core feature scripts (`/speckit.plan`, `/speckit.tasks`, …) and the Git extension's feature-branch creation, which inherit it. The `specify` CLI applies the **same** validation rules to every project-scoped subcommand (`specify integration …`, `specify extension …`, `specify workflow …`, `specify preset …`, and the rest that operate on a `.specify/` project), so those can target a member project too. When unset, Bash/PowerShell helpers keep their existing upward search; the `specify` CLI keeps its project-scoped resolver cwd-only unless a command explicitly defines broader detection (for example, bundle commands). |
-| `SPECIFY_FEATURE_DIRECTORY` | Override the active feature directory *within* the resolved project (takes precedence over `.specify/feature.json`). Relative paths resolve under the project root. Combine with `SPECIFY_INIT_DIR` to pick both the project and the feature non-interactively. |
+| `SPECIFY_FEATURE_DIRECTORY` | Override the active feature directory (takes precedence over `.specify/feature.json`). A relative path is joined to the project root without a containment check, so a value like `../shared-feature` still resolves outside it; an absolute path is used as-is and may likewise point outside the project root. The project root still identifies the Spec Kit project and its command/configuration context, but the selected feature directory itself is not required to live under it. Combine with `SPECIFY_INIT_DIR` to pick both the project and the feature non-interactively. |
 | `SPECIFY_FEATURE` | Explicitly override the active feature **label** (e.g. `001-photo-albums`) — the identifier the core helpers report as the current feature/branch (`get_current_branch` in Bash, `Get-CurrentBranch` in PowerShell). Those helpers never inspect Git: when the variable is set they return it verbatim, and when it is unset they return an empty string. The basename fallback happens later — `get_feature_paths` / `Get-FeaturePathsEnv` substitute the resolved feature directory's basename so the reported label is still usable — so calling the named helpers directly does **not** give you that fallback. You set it yourself: the Bash and Python feature scripts only **print** a commented `export SPECIFY_FEATURE=…` / `$env:SPECIFY_FEATURE = …` hint for you to run, because a child process cannot change its parent's environment, and `/speckit.specify` persists `feature_directory` to `.specify/feature.json` instead of setting this variable. (The PowerShell feature scripts do assign `$env:SPECIFY_FEATURE`, but that only reaches you when the script runs inside your current PowerShell session.) It does **not** locate the feature directory: with only `SPECIFY_FEATURE` set, `get_feature_paths` fails with *"Feature directory not found. Set `SPECIFY_FEATURE_DIRECTORY` or run the specify command to create `.specify/feature.json`."* Use `SPECIFY_FEATURE_DIRECTORY` (above) or `.specify/feature.json` to select the directory. |
 | `SPECIFY_FEATURE_NO_PERSIST` | Set to `1` or `true` to stop every core script from writing `.specify/feature.json`, even when it would otherwise persist `SPECIFY_FEATURE_DIRECTORY` on read. Useful when multiple agents run concurrently against the same checkout, each with its own `SPECIFY_FEATURE_DIRECTORY`: without it, each invocation's persist step can overwrite another agent's pinned feature directory. |
 
-> **Two resolution axes.** `SPECIFY_INIT_DIR` selects the **project** (which directory contains `.specify/`); `SPECIFY_FEATURE_DIRECTORY` / `.specify/feature.json` select the **feature** within that project. They are independent — project first, then feature.
+> **Two resolution axes.** `SPECIFY_INIT_DIR` selects the **project** (which directory contains `.specify/`); `SPECIFY_FEATURE_DIRECTORY` / `.specify/feature.json` select the **feature** — its default location is under `specs/` in that project, but an explicitly selected feature directory is not restricted to living inside it. They are independent — project first, then feature.
 >
 > **Version control.** `specify init` scaffolds a managed `.specify/.gitignore` that excludes machine-local state — `feature.json` (the current-feature pointer, rewritten on every feature switch) and per-machine extension `extensions/*/local-config.yml` overrides — while leaving everything else under `.specify/` (constitution, templates, scripts, extension config) shareable so teams stay aligned. Like the rest of `.specify/`'s shared scripts and templates, the file is tracked in the shared-infrastructure manifest: your edits are preserved on re-init and `specify init --here --force` restores the managed content. It is intentionally left in place by `specify integration uninstall`, which only removes the uninstalled agent's own files.
 >

docs/reference/integrations.md

@@ -33,6 +33,7 @@ The Specify CLI supports a wide range of AI coding agents. When you run `specify
 | [Kimi Code](https://code.kimi.com/)                                                  | `kimi`           | Skills-based integration; installs into `.kimi-code/skills/`. `--migrate-legacy` moves old `.kimi/skills/` installs to the new paths |
 | [Kiro CLI](https://kiro.dev/docs/cli/)                                               | `kiro-cli`       | Kiro CLI does not substitute `$ARGUMENTS` in file-based prompts, so Spec Kit ships a prose fallback at render time (see [Manage prompts](https://kiro.dev/docs/cli/chat/manage-prompts/) and issue [#1926](https://github.com/github/spec-kit/issues/1926)). Alias: `--integration kiro` |
 | [Lingma](https://lingma.aliyun.com/)                                                 | `lingma`         | Skills-based integration; skills are installed automatically                                                                               |
+| [MiniMax Code](https://github.com/MiniMax-AI/minimax-code)                          | `mcode`          | Skills-based integration; installs skills into `.minimax/skills` and invokes them as `/speckit-<command>`. Headless workflow dispatch uses `--permission full` so tool actions are not blocked by headless permission gating; set `SPECKIT_INTEGRATION_MCODE_EXTRA_ARGS="--permission smart"` to use MiniMax Code's stricter policy. |
 | [Mistral Vibe](https://github.com/mistralai/mistral-vibe)                            | `vibe`           |                                                                                                                                           |
 | [Muse Code](https://dev.meta.ai/docs/muse-code)                                     | `muse`           | Skills-based integration; installs skills into `.agents/skills` and invokes them as `/speckit-<command>`                                   |
 | [Oh My Pi](https://www.npmjs.com/package/@oh-my-pi/pi-coding-agent)                  | `omp`            | Installs slash commands into `.omp/commands`                                                                                               |
@@ -317,6 +318,7 @@ The currently declared multi-install safe integrations are:
 | `kilocode` | `.kilo/commands` |
 | `kiro-cli` | `.kiro/prompts` |
 | `lingma` | `.lingma/skills` |
+| `mcode` | `.minimax/skills` |
 | `omp` | `.omp/commands` |
 | `opencode` | `.opencode/commands` |
 | `pi` | `.pi/prompts` |