Merge origin/main into feat/init-dir-python-cli

Assisted-by: OpenAI Codex (model: GPT-5, autonomous)

Author: PascalThuet

.devcontainer/post-create.sh

@@ -56,7 +56,7 @@ run_command "npm install -g @jetbrains/junie-cli@latest"
 echo "✅ Done"
 
 echo -e "\n🤖 Installing Pi Coding Agent..."
-run_command "npm install -g @mariozechner/pi-coding-agent@latest"
+run_command "npm install -g @earendil-works/pi-coding-agent@latest"
 echo "✅ Done"
 
 echo -e "\n🤖 Installing Kiro CLI..."

.github/ISSUE_TEMPLATE/bundle_submission.yml

@@ -0,0 +1,293 @@
+name: Bundle Submission
+description: Submit your bundle metadata for community catalog validation
+title: "[Bundle]: Add "
+labels: ["enhancement", "needs-triage"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Thanks for contributing a bundle! This template captures metadata for maintainers to validate formatting, links, component resolution, and installation evidence. Maintainers do not audit, endorse, or support bundle code or installed components.
+
+        **Before submitting:**
+        - Review the [Bundles reference](https://github.com/github/spec-kit/blob/main/docs/reference/bundles.md)
+        - Ensure your bundle has a valid `bundle.yml` manifest
+        - Create a GitHub release with a versioned bundle artifact
+        - Test installation from a downloaded artifact: `specify bundle install ./your-bundle-1.0.0.zip`
+        - If you host a bundle catalog, test catalog installation with `specify bundle catalog add <catalog-url> --id <catalog-id> --policy install-allowed` and `specify bundle install <bundle-id>`
+        - If your bundle depends on components from non-default catalogs, document those catalog URLs and test installation from a clean project
+
+  - type: input
+    id: bundle-id
+    attributes:
+      label: Bundle ID
+      description: Unique bundle identifier; must start and end with a lowercase letter or digit and may contain lowercase letters, digits, dots, underscores, and hyphens between
+      placeholder: "e.g., security-governance-stack"
+    validations:
+      required: true
+
+  - type: input
+    id: bundle-name
+    attributes:
+      label: Bundle Name
+      description: Human-readable bundle name
+      placeholder: "e.g., Security Governance Stack"
+    validations:
+      required: true
+
+  - type: input
+    id: version
+    attributes:
+      label: Version
+      description: Semantic version number
+      placeholder: "e.g., 1.0.0"
+    validations:
+      required: true
+
+  - type: input
+    id: role
+    attributes:
+      label: Role or Team
+      description: Primary role, team, or persona this bundle provisions
+      placeholder: "e.g., security-engineer, product-manager, platform-team"
+    validations:
+      required: true
+
+  - type: textarea
+    id: description
+    attributes:
+      label: Description
+      description: Brief description of the stack this bundle installs
+      placeholder: Installs a security governance stack with compliance presets, review commands, and evidence workflows
+    validations:
+      required: true
+
+  - type: input
+    id: author
+    attributes:
+      label: Author
+      description: Your name or organization
+      placeholder: "e.g., Jane Doe or Acme Corp"
+    validations:
+      required: true
+
+  - type: input
+    id: repository
+    attributes:
+      label: Repository URL
+      description: GitHub repository URL for your bundle source
+      placeholder: "https://github.com/your-org/spec-kit-bundle-your-bundle"
+    validations:
+      required: true
+
+  - type: input
+    id: download-url
+    attributes:
+      label: Download URL
+      description: URL to the versioned bundle artifact generated by `specify bundle build`
+      placeholder: "https://github.com/your-org/spec-kit-bundle-your-bundle/releases/download/v1.0.0/your-bundle-1.0.0.zip"
+    validations:
+      required: true
+
+  - type: input
+    id: documentation
+    attributes:
+      label: Documentation URL
+      description: Link to documentation that explains what the bundle installs and how to use it
+      placeholder: "https://github.com/your-org/spec-kit-bundle-your-bundle/blob/main/README.md"
+    validations:
+      required: true
+
+  - type: input
+    id: license
+    attributes:
+      label: License
+      description: Open source license type
+      placeholder: "e.g., MIT, Apache-2.0"
+    validations:
+      required: true
+
+  - type: input
+    id: speckit-version
+    attributes:
+      label: Required Spec Kit Version
+      description: Minimum Spec Kit version required by the bundle
+      placeholder: "e.g., >=0.9.0"
+    validations:
+      required: true
+
+  - type: input
+    id: integration
+    attributes:
+      label: Integration Target (optional)
+      description: Integration ID if the bundle pins one; leave empty if integration-agnostic
+      placeholder: "e.g., claude, copilot, gemini"
+
+  - type: textarea
+    id: components-provided
+    attributes:
+      label: Components Provided
+      description: List the extensions, presets, workflows, and steps this bundle installs
+      placeholder: |
+        - extensions: sicario-guard@0.5.1
+        - presets: sicario-core@0.5.1, sicario-ai-governance@0.5.1
+        - workflows: evidence-review@1.0.0
+        - steps: threat-model
+    validations:
+      required: true
+
+  - type: textarea
+    id: required-catalogs
+    attributes:
+      label: Required Component Catalogs
+      description: List any non-default catalogs users must add before this bundle can resolve its components; enter "None" if every component resolves from built-in or bundled catalogs
+      placeholder: |
+        - Presets: https://github.com/your-org/your-bundle/releases/download/v1.0.0/presets.json
+        - Extensions: https://github.com/your-org/your-bundle/releases/download/v1.0.0/extensions.json
+    validations:
+      required: true
+
+  - type: textarea
+    id: tags
+    attributes:
+      label: Tags
+      description: 2-5 relevant tags (lowercase, separated by commas)
+      placeholder: "security, governance, compliance"
+    validations:
+      required: true
+
+  - type: textarea
+    id: features
+    attributes:
+      label: Key Features
+      description: List the main capabilities this bundle provides
+      placeholder: |
+        - Installs evidence-first security governance templates
+        - Adds automated bundle verification commands
+        - Pins all components to release-tested versions
+    validations:
+      required: true
+
+  - type: checkboxes
+    id: testing
+    attributes:
+      label: Testing Checklist
+      description: Confirm that your bundle has been tested
+      options:
+        - label: Validation succeeds with `specify bundle validate --path <bundle-directory>`
+          required: true
+        - label: Build succeeds with `specify bundle build --path <bundle-directory>` and produces the submitted artifact
+          required: true
+        - label: Bundle installs successfully from the built artifact
+          required: true
+        - label: The submitted distribution path was tested end to end, including bundle-ID installation from an install-allowed catalog when a catalog entry is proposed
+          required: true
+        - label: Installation was tested in a clean Spec Kit project
+          required: true
+        - label: Required component catalogs are documented and were included in testing, or no extra catalogs are required
+          required: true
+        - label: Documentation is complete and accurate
+          required: true
+
+  - type: checkboxes
+    id: requirements
+    attributes:
+      label: Submission Requirements
+      description: Verify your bundle meets all requirements
+      options:
+        - label: Valid `bundle.yml` manifest included
+          required: true
+        - label: README.md explains the bundle's intended role, installed components, and installation steps
+          required: true
+        - label: LICENSE file included
+          required: true
+        - label: GitHub release created with a version tag
+          required: true
+        - label: Bundle ID matches the manifest and follows naming conventions
+          required: true
+        - label: Every extension, preset, workflow, and step reference is pinned where the manifest requires a version
+          required: true
+
+  - type: textarea
+    id: testing-details
+    attributes:
+      label: Testing Details
+      description: Describe how you tested your bundle
+      placeholder: |
+        **Tested on:**
+        - macOS 15 with Spec Kit v0.9.0
+        - Ubuntu 24.04 with Spec Kit v0.9.0
+
+        **Test project:** [Link or description]
+
+        **Test scenarios:**
+        1. Added required catalogs
+        2. Validated bundle manifest
+        3. Built release artifact
+        4. Installed bundle in a clean project
+        5. Ran the installed commands or workflows
+    validations:
+      required: true
+
+  - type: textarea
+    id: example-usage
+    attributes:
+      label: Example Usage
+      description: Provide a simple example of installing and using your bundle
+      render: markdown
+      placeholder: |
+        ```bash
+        # Add any required component catalogs first
+        specify preset catalog add https://github.com/your-org/your-bundle/releases/download/v1.0.0/presets.json --name your-bundle --install-allowed
+        specify extension catalog add https://github.com/your-org/your-bundle/releases/download/v1.0.0/extensions.json --name your-bundle --install-allowed
+
+        # Install the downloaded bundle artifact
+        curl -L -o your-bundle-1.0.0.zip https://github.com/your-org/your-bundle/releases/download/v1.0.0/your-bundle-1.0.0.zip
+        specify bundle install ./your-bundle-1.0.0.zip
+
+        # Or test through an install-allowed bundle catalog
+        specify bundle catalog add https://github.com/your-org/your-bundle/releases/download/v1.0.0/bundles.json --id your-bundle-catalog --policy install-allowed
+        specify bundle install your-bundle
+        ```
+    validations:
+      required: true
+
+  - type: textarea
+    id: catalog-entry
+    attributes:
+      label: Proposed Catalog Entry
+      description: Provide the JSON entry that would appear under the top-level `bundles` object in a bundle catalog (helps reviewers)
+      render: json
+      placeholder: |
+        {
+          "your-bundle": {
+            "name": "Your Bundle",
+            "id": "your-bundle",
+            "version": "1.0.0",
+            "role": "security-engineer",
+            "description": "Brief description of the stack",
+            "author": "Your Name",
+            "license": "MIT",
+            "download_url": "https://github.com/your-org/your-bundle/releases/download/v1.0.0/your-bundle-1.0.0.zip",
+            "repository": "https://github.com/your-org/your-bundle",
+            "requires": {
+              "speckit_version": ">=0.9.0"
+            },
+            "provides": {
+              "extensions": 1,
+              "presets": 2,
+              "steps": 0,
+              "workflows": 1
+            },
+            "tags": ["security", "governance"],
+            "verified": false
+          }
+        }
+    validations:
+      required: true
+
+  - type: textarea
+    id: additional-context
+    attributes:
+      label: Additional Context
+      description: Any other information that would help reviewers
+      placeholder: Screenshots, demo videos, links to related projects, dependency-resolution notes, etc.

AGENTS.md

@@ -75,7 +75,6 @@ class WindsurfIntegration(MarkdownIntegration):
         "args": "$ARGUMENTS",
         "extension": ".md",
     }
-    context_file = ".windsurf/rules/specify-rules.md"
 ```
 
 **TOML agent (Gemini):**
@@ -101,7 +100,6 @@ class GeminiIntegration(TomlIntegration):
         "args": "{{args}}",
         "extension": ".toml",
     }
-    context_file = "GEMINI.md"
 ```
 
 **Skills agent (Codex):**
@@ -129,7 +127,6 @@ class CodexIntegration(SkillsIntegration):
         "args": "$ARGUMENTS",
         "extension": "/SKILL.md",
     }
-    context_file = "AGENTS.md"
 
     @classmethod
     def options(cls) -> list[IntegrationOption]:
@@ -150,7 +147,6 @@ class CodexIntegration(SkillsIntegration):
 | `key` | Class attribute | Unique identifier; for CLI-based integrations (`requires_cli: True`), must match the CLI executable name |
 | `config` | Class attribute (dict) | Agent metadata: `name`, `folder`, `commands_subdir`, `install_url`, `requires_cli` |
 | `registrar_config` | Class attribute (dict) | Command output config: `dir`, `format`, `args` placeholder, file `extension` |
-| `context_file` | Class attribute (str or None) | Path to agent context/instructions file (e.g., `"CLAUDE.md"`, `".github/copilot-instructions.md"`) |
 
 **Key design rule:** For CLI-based integrations (`requires_cli: True`), `key` must be the actual executable name (e.g., `"cursor-agent"` not `"cursor"`). This ensures `shutil.which(key)` works for CLI-tool checks without special-case mappings. IDE-based integrations (`requires_cli: False`) should use their canonical identifier (e.g., `"windsurf"`, `"copilot"`).
 
@@ -175,9 +171,11 @@ def _register_builtins() -> None:
 
 ### 4. Context file behavior
 
-Set `context_file` on the integration class. The base integration setup creates or updates the managed Spec Kit section in that file, and uninstall removes the managed section when appropriate.
+The Specify CLI carries **no agent-context state whatsoever**. Integration classes do **not** declare a `context_file`, and the CLI never creates, updates, removes, resolves, or migrates a context/instruction file (`CLAUDE.md`, `AGENTS.md`, `.github/copilot-instructions.md`, …). New integrations add nothing for context handling.
 
-The managed section is owned by the bundled `agent-context` extension (`extensions/agent-context/`). All configuration flows through the extension's own config file at `.specify/extensions/agent-context/agent-context-config.yml`:
+Managing the "Spec Kit" section in the context file is fully owned by the bundled `agent-context` extension (`extensions/agent-context/`), which is a **full opt-in**: `specify init` does not install it. A user adds/enables it through the standard extension verbs, after which the extension's own bundled scripts maintain the context section. When the extension is absent or disabled, nothing in Spec Kit touches the context file.
+
+The extension reads its own config file at `.specify/extensions/agent-context/agent-context-config.yml`:
 
 ```yaml
 # Path to the coding agent context file managed by this extension
@@ -189,10 +187,10 @@ context_markers:
   end: "<!-- SPECKIT END -->"
 ```
 
-- `context_file` is written automatically from the integration's class attribute when `specify init` or `specify integration use` is run.
-- `context_markers.{start,end}` defaults to `IntegrationBase.CONTEXT_MARKER_START` / `CONTEXT_MARKER_END`. Users who want custom markers edit `agent-context-config.yml` directly — both the Python layer (`upsert_context_section()` / `remove_context_section()`) and the bundled scripts (`extensions/agent-context/scripts/bash/update-agent-context.sh` and `.ps1`) read from this single source of truth.
+- The Specify CLI does **not** write this config. When `context_file` is empty, the extension's bundled scripts self-seed it by looking up the active integration's key in the extension's own `agent-context-defaults.json` map (`extensions/agent-context/scripts/bash/update-agent-context.sh` and `.ps1`). The CLI registry is never consulted — all agent→context-file knowledge lives inside the extension.
+- `context_markers.{start,end}` are read solely by the extension's scripts; they default to the Spec Kit markers shown above and can be customized by editing `agent-context-config.yml` directly.
 
-Users can opt out entirely with `specify extension disable agent-context`; while disabled, Spec Kit skips context-file creation, updates, and removal (the gates are inside `upsert_context_section()` and `remove_context_section()`).
+Existing projects created by older Spec Kit versions keep working: any previously written managed section or extension config is left intact and is only ever updated by the extension when run.
 
 Only add custom setup logic when the agent needs non-standard behavior. Integrations no longer require per-agent thin wrapper scripts or shared context-update dispatcher scripts — the `agent-context` extension is fully generic.
 
@@ -401,7 +399,6 @@ Implementation: Extends `YamlIntegration` (parallel to `TomlIntegration`):
 2. Extracts title and description from frontmatter
 3. Renders output as Goose recipe YAML (version, title, description, author, extensions, activities, prompt)
 4. Uses `yaml.safe_dump()` for header fields to ensure proper escaping
-5. Sets `context_file = "AGENTS.md"` so the base setup manages the Spec Kit context section there
 
 ## Branch Naming Convention
 
@@ -466,7 +463,7 @@ Disclosure is **continuous**, not a one-time event. A single AI-disclosure parag
 ## Common Pitfalls
 
 1. **Using shorthand keys for CLI-based integrations**: For CLI-based integrations (`requires_cli: True`), the `key` must match the executable name (e.g., `"cursor-agent"` not `"cursor"`). `shutil.which(key)` is used for CLI tool checks — mismatches require special-case mappings. IDE-based integrations (`requires_cli: False`) are not subject to this constraint.
-2. **Forgetting context configuration**: The bundled `agent-context` extension reads from `.specify/extensions/agent-context/agent-context-config.yml`. New integrations only need to set `context_file` on the class — markers and dispatcher scripts are managed centrally.
+2. **Reintroducing context handling into the CLI**: The opt-in `agent-context` extension owns everything about context files — including the per-agent default mapping in `agent-context-defaults.json`. Integration classes must **not** declare a `context_file`, and no CLI code should read, write, resolve, or migrate context files. All context-file logic lives in `.specify/extensions/agent-context/` and its bundled scripts.
 3. **Incorrect `requires_cli` value**: Set to `True` only for agents that have a CLI tool; set to `False` for IDE-based agents.
 4. **Wrong argument format**: Use `$ARGUMENTS` for Markdown agents, `{{args}}` for TOML agents.
 5. **Skipping registration**: The import and `_register()` call in `_register_builtins()` must both be added.