specify-cli 0.15.0__tar.gz → 0.15.1__tar.gz

{specify_cli-0.15.0 → specify_cli-0.15.1}/.github/workflows/publish-pypi.yml

@@ -35,7 +35,7 @@ jobs:
         uses: astral-sh/setup-uv@c771a70e6277c0a99b617c7a806ffedaca235ff9 # v9.0.0
 
       - name: Set up Python
-        uses: actions/setup-python@ece7cb06caefa5fff74198d8649806c4678c61a1 # v6
+        uses: actions/setup-python@5fda3b95a4ea91299a34e894583c3862153e4b97 # v7.0.0
         with:
           python-version: "3.13"
 

{specify_cli-0.15.0 → specify_cli-0.15.1}/.github/workflows/security.yml

@@ -27,7 +27,7 @@ jobs:
         uses: astral-sh/setup-uv@c771a70e6277c0a99b617c7a806ffedaca235ff9 # v9.0.0
 
       - name: Set up Python
-        uses: actions/setup-python@ece7cb06caefa5fff74198d8649806c4678c61a1 # v6
+        uses: actions/setup-python@5fda3b95a4ea91299a34e894583c3862153e4b97 # v7.0.0
         with:
           python-version: "3.14"
 
@@ -58,7 +58,7 @@ jobs:
         uses: astral-sh/setup-uv@c771a70e6277c0a99b617c7a806ffedaca235ff9 # v9.0.0
 
       - name: Set up Python ${{ matrix.python-version }}
-        uses: actions/setup-python@ece7cb06caefa5fff74198d8649806c4678c61a1 # v6
+        uses: actions/setup-python@5fda3b95a4ea91299a34e894583c3862153e4b97 # v7.0.0
         with:
           python-version: ${{ matrix.python-version }}
 

{specify_cli-0.15.0 → specify_cli-0.15.1}/.github/workflows/stale.yml

@@ -14,7 +14,7 @@ jobs:
   stale:
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/stale@1e223db275d687790206a7acac4d1a11bd6fe629 # v10
+      - uses: actions/stale@4391f3da665fdf50b6810c1a66712fb9ba21aa93 # v11.0.0
         with:
           # Days of inactivity before an issue or PR becomes stale
           days-before-stale: 150

{specify_cli-0.15.0 → specify_cli-0.15.1}/.github/workflows/test.yml

@@ -19,7 +19,7 @@ jobs:
         uses: astral-sh/setup-uv@c771a70e6277c0a99b617c7a806ffedaca235ff9 # v9.0.0
 
       - name: Set up Python
-        uses: actions/setup-python@ece7cb06caefa5fff74198d8649806c4678c61a1 # v6
+        uses: actions/setup-python@5fda3b95a4ea91299a34e894583c3862153e4b97 # v7.0.0
         with:
           python-version: "3.14"
 
@@ -40,7 +40,7 @@ jobs:
         uses: astral-sh/setup-uv@c771a70e6277c0a99b617c7a806ffedaca235ff9 # v9.0.0
 
       - name: Set up Python ${{ matrix.python-version }}
-        uses: actions/setup-python@ece7cb06caefa5fff74198d8649806c4678c61a1 # v6
+        uses: actions/setup-python@5fda3b95a4ea91299a34e894583c3862153e4b97 # v7.0.0
         with:
           python-version: ${{ matrix.python-version }}
 

{specify_cli-0.15.0 → specify_cli-0.15.1}/CHANGELOG.md

@@ -2,6 +2,31 @@
 
 <!-- insert new changelog below this comment -->
 
+## [0.15.1] - 2026-07-31
+
+### Changed
+
+- fix: escape Rich markup in `workflow resolve` output (#3879)
+- chore(deps): bump actions/stale from 10.4.0 to 11.0.0 (#3877)
+- chore(deps): bump actions/setup-python from 6.3.0 to 7.0.0 (#3876)
+- feat: support tar archives for installs (#3874)
+- fix: eliminate TOCTOU race in file unlink calls (#3819)
+- fix(scripts): tolerate an unusable integration.json in the Python helper (#3785)
+- fix(catalogs): validate the port in the shared catalog-URL validator, like its mirrors do (#3804)
+- feat(presets): add opt-in constitution-sync preset (#3873)
+- fix: reject non-object workflow caches (#3860)
+- Harden extension URL download cache against symlink and junction races (#3869)
+- fix: escape workflow step metadata (#3863)
+- [bug-fix] Fix bundle-update-force-mislead: add refresh() to DefaultPrimitiveInstaller (#3452)
+- fix: use chunked read for extension manifest hash (#3841)
+- fix: preserve unreadable event config files (#3861)
+- fix(scripts): use a .NET Framework-safe trim in the PowerShell init-dir resolver (#3872)
+- Add ContextForge MCP extension to community catalog (#3487)
+- fix: normalize non-UTF-8 integration manifests (#3862)
+- feat: bind gate verdict to workflow input via verdict_input (#3725)
+- docs: use absolute image URLs in README for PyPI rendering (#3867)
+- chore: release 0.15.0, begin 0.15.1.dev0 development (#3871)
+
 ## [0.15.0] - 2026-07-30
 
 ### Changed

{specify_cli-0.15.0 → specify_cli-0.15.1}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: specify-cli
-Version: 0.15.0
+Version: 0.15.1
 Summary: Specify CLI, part of GitHub Spec Kit. A tool to bootstrap your projects for Spec-Driven Development (SDD).
 License-File: LICENSE
 Requires-Python: >=3.11
@@ -19,7 +19,7 @@ Requires-Dist: pytest>=7.0; extra == 'test'
 Description-Content-Type: text/markdown
 
 <div align="center">
-    <img src="./media/logo_large.webp" alt="Spec Kit Logo" width="200" height="200"/>
+    <img src="https://raw.githubusercontent.com/github/spec-kit/main/media/logo_large.webp" alt="Spec Kit Logo" width="200" height="200"/>
     <h1>🌱 Spec Kit</h1>
     <h3><em>Define what to build before building it — with any AI coding agent.</em></h3>
 </div>
@@ -156,7 +156,7 @@ For detailed step-by-step instructions, see our [comprehensive guide](./spec-dri
 
 Want to see Spec Kit in action? Watch our [video overview](https://www.youtube.com/watch?v=a9eR1xsfvHg&pp=0gcJCckJAYcqIYzv)!
 
-[![Spec Kit video header](/media/spec-kit-video-header.jpg)](https://www.youtube.com/watch?v=a9eR1xsfvHg&pp=0gcJCckJAYcqIYzv)
+[![Spec Kit video header](https://raw.githubusercontent.com/github/spec-kit/main/media/spec-kit-video-header.jpg)](https://www.youtube.com/watch?v=a9eR1xsfvHg&pp=0gcJCckJAYcqIYzv)
 
 ## 🌍 Community
 

{specify_cli-0.15.0 → specify_cli-0.15.1}/README.md

@@ -1,5 +1,5 @@
 <div align="center">
-    <img src="./media/logo_large.webp" alt="Spec Kit Logo" width="200" height="200"/>
+    <img src="https://raw.githubusercontent.com/github/spec-kit/main/media/logo_large.webp" alt="Spec Kit Logo" width="200" height="200"/>
     <h1>🌱 Spec Kit</h1>
     <h3><em>Define what to build before building it — with any AI coding agent.</em></h3>
 </div>
@@ -136,7 +136,7 @@ For detailed step-by-step instructions, see our [comprehensive guide](./spec-dri
 
 Want to see Spec Kit in action? Watch our [video overview](https://www.youtube.com/watch?v=a9eR1xsfvHg&pp=0gcJCckJAYcqIYzv)!
 
-[![Spec Kit video header](/media/spec-kit-video-header.jpg)](https://www.youtube.com/watch?v=a9eR1xsfvHg&pp=0gcJCckJAYcqIYzv)
+[![Spec Kit video header](https://raw.githubusercontent.com/github/spec-kit/main/media/spec-kit-video-header.jpg)](https://www.youtube.com/watch?v=a9eR1xsfvHg&pp=0gcJCckJAYcqIYzv)
 
 ## 🌍 Community
 

{specify_cli-0.15.0 → specify_cli-0.15.1}/docs/community/extensions.md

@@ -50,6 +50,7 @@ The following community-contributed extensions are available in [`catalog.commun
 | Coding Standards Drift Control | Generate coding-standards drift reports and remediation tasks for active Spec Kit features | `code` | Read+Write | [spec-kit-coding-standards-drift-control](https://github.com/benizzio/spec-kit-coding-standards-drift-control) |
 | Conduct Extension | Orchestrates spec-kit phases via sub-agent delegation to reduce context pollution. | `process` | Read+Write | [spec-kit-conduct-ext](https://github.com/twbrandon7/spec-kit-conduct-ext) |
 | Confluence Extension | Create a doc in Confluence summarizing the specifications and planning files | `integration` | Read+Write | [spec-kit-confluence](https://github.com/aaronrsun/spec-kit-confluence) |
+| ContextForge MCP | Integrates codebase-memory-mcp + headroom into Spec Kit — graph-based code intelligence and context compression for the implement phase | `code` | Read+Write | [contextforge-mcp](https://github.com/capatinore/contextforge-mcp) |
 | Cost Tracker | Track real LLM dollar cost across SDD workflows — per-feature budgets, per-integration comparison, and finance-ready exports | `visibility` | Read+Write | [spec-kit-cost](https://github.com/Quratulain-bilal/spec-kit-cost) |
 | Data Model Diagram | Generates Mermaid ER diagrams from Spec Kit data models after planning | `docs` | Read+Write | [spec-kit-data-model-diagram](https://github.com/benizzio/spec-kit-data-model-diagram) |
 | DocGuard — CDD Enforcement | The only doc-integrity engine with an MCP server, SARIF/JUnit output, and a deterministic zero-LLM core. Validates, scores, and traces documentation against code — 27 validators, stable finding codes, adoption baseline for legacy repos, compliance-evidence reports, GitHub Action with PR annotations, spec-kit hooks. Pure Node.js, one pinned dep. | `docs` | Read+Write | [spec-kit-docguard](https://github.com/raccioly/docguard) |

{specify_cli-0.15.0 → specify_cli-0.15.1}/docs/reference/workflows.md

@@ -39,6 +39,21 @@ specify workflow run my-pipeline.yml --json
 
 `workflow_id` is the `workflow.id` declared inside the YAML, not the file name. The object is printed exactly as shown — pretty-printed with two-space indentation, on plain stdout with no Rich markup — so it always parses. While the workflow runs under `--json`, any progress a step would print (for example a gate prompt, or output from a prompt step's CLI subprocess) is redirected to stderr, so stdout carries only the JSON object. Read the object from stdout; leave stderr attached to the terminal or capture it separately.
 
+For `failed` and `aborted` runs, the payload includes an `error` field carrying the terminal step's error message:
+
+```json
+{
+  "run_id": "662bf791",
+  "workflow_id": "build-and-review",
+  "status": "failed",
+  "current_step_id": "boom",
+  "current_step_index": 0,
+  "error": "Command exited with code 3"
+}
+```
+
+`completed` and `paused` runs omit the `error` field. The error is persisted in the run's `state.json`, so `specify workflow status <run_id> --json` surfaces the same message after the fact.
+
 > **Note:** Most workflow commands require a project already initialized with `specify init`. The exception is `specify workflow run <local-file.{yml,yaml}>`, which can run outside a project; in that case, run state is stored under the current directory's `.specify/workflows/runs/<run_id>/`.
 
 ## Resume a Workflow
@@ -88,10 +103,17 @@ specify workflow add <source>
 
 | Option          | Description                                            |
 | --------------- | ------------------------------------------------------ |
-| `--dev`         | Install from a local workflow YAML file or directory   |
+| `--dev`         | Install from a local YAML file, package directory, or archive |
 | `--from <url>`  | Install from a custom URL (`<source>` names the expected workflow ID) |
 
-Installs a workflow from the catalog, a URL (HTTPS required), a local YAML file, or a local directory containing `workflow.yml`.
+Installs a workflow from the catalog, an HTTPS URL, a local YAML file, a
+directory containing `workflow.yml`, or a `.zip`, `.tar.gz`, or `.tgz`
+archive. Archives may contain `workflow.yml` at the root or inside one
+top-level directory.
+
+Directory and archive installs preserve the complete workflow package,
+including scripts and other companion files. ZIP, `.tar.gz`, and `.tgz`
+archives follow the same validation and installation behavior.
 
 ## Workflow Overlays
 
@@ -266,7 +288,9 @@ Lower priority values have higher precedence. Change this overlay to `priority:
 
 ### Interaction with Bundles and Updates
 
-`specify workflow add <local-directory>` installs `workflow.yml` from the local directory into `.specify/workflows/<id>/`.
+`specify workflow add <local-directory>` installs the complete local workflow
+package into `.specify/workflows/<id>/`. Archive installs preserve the same
+package contents.
 
 When an installed workflow is refreshed or reinstalled, project overlays in `.specify/workflows/overlays/<id>/` are preserved because they live outside the installed workflow directory.
 
@@ -554,6 +578,51 @@ Each workflow run persists its state at `.specify/workflows/runs/<run_id>/`:
 
 This enables `specify workflow resume` to continue from the exact step where a run was paused (e.g., at a gate) or failed.
 
+### Gate Verdict Inputs
+
+`verdict_input` binds a gate's verdict to a named workflow input. The input must be declared in the workflow's `inputs` block; `specify workflow validate` reports an undeclared reference.
+
+`verdict_input` is not supported inside a `fan-out` template. Fan-out items
+share workflow inputs, while workflow state can represent only one paused
+gate. Place a gate before the fan-out to approve the whole batch, or after a
+fan-in to review the aggregated results.
+
+**Input value semantics:**
+
+| Value | Behavior |
+|---|---|
+| Non-empty string, matches an option (case-insensitive) | Gate auto-decides; `output.choice` is set to the configured option spelling |
+| Non-empty string, no match | Gate fails immediately |
+| Non-string | Gate fails immediately |
+| Missing or empty | Gate prompts on a TTY; pauses otherwise |
+
+**Default value semantics:** A non-empty `default` is consumed as a verdict on the first run — matching an option auto-decides the gate, not matching fails it immediately.
+
+```yaml
+inputs:
+  spec_verdict:
+    type: string
+    default: ""
+steps:
+  - id: review-spec
+    type: gate
+    message: "Approve the specification?"
+    options: [approve, reject]
+    on_reject: retry
+    verdict_input: spec_verdict
+```
+
+Supply a verdict when resuming:
+
+```bash
+specify workflow resume <run_id> --input spec_verdict=approve
+```
+
+For `on_reject: retry`, a bound reject verdict is consumed before the gate
+pauses: the named stored input is reset to `""`. A later resume therefore
+prompts or pauses again until another verdict is supplied. Approve, abort, and
+skip outcomes leave the input unchanged.
+
 ## FAQ
 
 ### What happens when a workflow hits a gate step?

{specify_cli-0.15.0 → specify_cli-0.15.1}/docs/upgrade.md

@@ -208,6 +208,74 @@ Restart your IDE to refresh the command list.
 
 ---
 
+## Behavior change: `/constitution` no longer propagates into templates
+
+The `/constitution` command ([#3790](https://github.com/github/spec-kit/pull/3790)) is scoped to
+its own artifact. It updates
+`.specify/memory/constitution.md` and writes a Sync Impact Report, and **no longer edits**
+`plan-template.md`, `spec-template.md`, `tasks-template.md`, installed command files, or
+guidance docs.
+
+### Why
+
+Spec Kit uses **runtime resolution**: `plan`, `tasks`, and `analyze` read
+`.specify/memory/constitution.md` live on every run, and `analyze` is the dedicated drift
+checker. The governed templates carry a pointer, not a copy — `plan-template.md` ships
+`[Gates determined based on constitution file]`, and `/plan` fills that section from the live
+constitution each run. Propagation duplicated the single source of truth and fought the
+preset/override composition system (a `replace` preset shadows an edited core template).
+
+More broadly, presets and extensions — not in-place file edits — are how Spec Kit now governs
+shared assets. Composing policy through the resolution stack keeps it centrally owned, versioned,
+and auditable across repositories, instead of frozen into per-repo copies no core team can see.
+
+### Is this a breaking change for existing projects?
+
+**No — your workflow keeps working.** You would only notice a difference if you relied on
+`/constitution` editing those files in place. The templates are scaffolds, not authorities. When you
+run `/plan`, it copies the template into a per-feature `plan.md` and re-derives the Constitution
+Check from the live constitution; `/analyze` validates against it. Even if a previous
+`/constitution` run materialized concrete gate text into `.specify/templates/plan-template.md`,
+the live constitution remains the source of truth at runtime.
+
+On a **non-forced upgrade**, a materialized template is *preserved* (its hash diverges from the
+recorded managed copy, so the refresh treats it as a customization and does not overwrite it).
+Nothing regresses.
+
+### Optional cleanup — return to the runtime pointer
+
+A frozen, pre-filled Constitution Check is a slightly misleading scaffold and can bias the first
+`/plan` pass. To move fully back to runtime resolution, reset the section body in
+`.specify/templates/plan-template.md` to the pointer:
+
+```text
+## Constitution Check
+
+*GATE: Must pass before Phase 0 research. Re-check after Phase 1 design.*
+
+[Gates determined based on constitution file]
+```
+
+Leave the rest of the file untouched. This is cleanup, not a required migration.
+
+### Keeping the old behavior (opt-in)
+
+If your team treats the materialized templates as **reviewed, committed artifacts** and wants
+`/constitution` to keep propagating, install the bundled **`constitution-sync`** preset:
+
+```bash
+specify preset add constitution-sync
+```
+
+It wraps the core `/constitution` command and re-adds the propagation pass. It does **not** edit
+versioned preset- or extension-provided templates or command files (those are owned by their
+packages and are recomposed on reconciliation). Note that this edit-in-place propagation model
+conflicts with the composition model used by the rest of the SDD commands when they are
+preset/extension-managed — see the "Interaction with the resolution stack" section in
+`presets/constitution-sync/README.md` for the tradeoffs and when to prefer the default instead.
+
+---
+
 ## Common Scenarios
 
 ### Scenario 1: "I just want new slash commands"

{specify_cli-0.15.0 → specify_cli-0.15.1}/extensions/catalog.community.json

@@ -1070,6 +1070,41 @@
       "created_at": "2026-03-29T00:00:00Z",
       "updated_at": "2026-03-29T00:00:00Z"
     },
+    "contextforge-mcp": {
+      "name": "ContextForge MCP",
+      "id": "contextforge-mcp",
+      "description": "Integrates codebase-memory-mcp + headroom into Spec Kit — graph-based code intelligence and context compression for the implement phase.",
+      "author": "capatinore",
+      "version": "0.1.0",
+      "download_url": "https://github.com/capatinore/contextforge-mcp/releases/download/ext-v0.1.0/contextforge-mcp-speckit-extension.zip",
+      "repository": "https://github.com/capatinore/contextforge-mcp",
+      "homepage": "https://github.com/capatinore/contextforge-mcp",
+      "documentation": "https://github.com/capatinore/contextforge-mcp/blob/main/README.md",
+      "changelog": "",
+      "license": "MIT",
+      "category": "code",
+      "effect": "read-write",
+      "requires": {
+        "speckit_version": ">=0.10.0"
+      },
+      "provides": {
+        "commands": 4,
+        "hooks": 0
+      },
+      "tags": [
+        "mcp",
+        "code-intelligence",
+        "context-compression",
+        "tokens",
+        "claude",
+        "spec-driven-development"
+      ],
+      "verified": false,
+      "downloads": 0,
+      "stars": 0,
+      "created_at": "2026-07-13T00:00:00Z",
+      "updated_at": "2026-07-13T00:00:00Z"
+    },
     "cost": {
       "name": "Cost Tracker",
       "id": "cost",

{specify_cli-0.15.0 → specify_cli-0.15.1}/presets/catalog.json

@@ -25,6 +25,29 @@
         "workflow",
         "core"
       ]
+    },
+    "constitution-sync": {
+      "name": "Constitution Template Sync",
+      "id": "constitution-sync",
+      "version": "1.0.0",
+      "description": "Opt-in: restores /constitution propagation of amended guidance into plan/spec/tasks templates and installed command files, for teams that treat materialized templates as reviewed artifacts.",
+      "author": "github",
+      "repository": "https://github.com/github/spec-kit",
+      "license": "MIT",
+      "bundled": true,
+      "requires": {
+        "speckit_version": ">=0.14.4"
+      },
+      "provides": {
+        "commands": 1,
+        "templates": 0
+      },
+      "tags": [
+        "constitution",
+        "governance",
+        "templates",
+        "compatibility"
+      ]
     }
   }
 }

specify_cli-0.15.1/presets/constitution-sync/README.md

@@ -0,0 +1,126 @@
+# Constitution Template Sync
+
+An **opt-in** preset that restores `/constitution`'s ability to propagate amended guidance into your
+project's own templates and command files. After you update the constitution, it aligns
+`plan-template.md`, `spec-template.md`, `tasks-template.md`, project-local command files, and
+guidance docs so they reflect the current principles.
+
+This propagation used to be built into `/constitution`; it was dropped when the command moved to the
+preset model. Installing this preset opts you back into it: you get the guidance materialized into
+reviewed, committed artifacts instead of relying on runtime resolution alone.
+
+> **What you're opting into.** Propagation was removed deliberately — it duplicates the constitution
+> as the source of truth and can fight the composition stack (materialized edits get shadowed or
+> clobbered on the next recompose). This preset knowingly **reintroduces** that behavior, and those
+> tradeoffs, for teams that want it. Read the [caveats](#caveats-you-take-on) before installing.
+
+For most projects the default composable stack is the **recommended** approach, and at organization
+scale it is usually the stronger governance model. Runtime resolution keeps the live constitution as
+the single source of truth (nothing to re-sync, so nothing drifts), and the stack composes the
+**entire** Spec Kit ecosystem — not just the SDD commands, but every command, template, script and
+extension — with explicit priority levels, strategies, and independent versioning. It is a
+capability, not automatic governance: a core team authors its own organizational presets and
+extensions, then owns, versions, and audits that policy in one place and rolls it across many
+repositories, instead of scattering frozen, per-repo copies no central team can see. This preset is
+a supported escape hatch for teams whose workflow depends on reviewing materialized artifacts
+directly — useful as a bridge, though for org-wide policy the better long-term path is usually a
+versioned preset a core team maintains.
+
+## What it does
+
+Ships a single `wrap`-strategy override of `speckit.constitution`. It composes on top of the
+current core command (via `{CORE_TEMPLATE}`), so it stays forward-compatible with core changes, and
+appends a propagation pass that, after the constitution is written:
+
+- Aligns `plan/spec/tasks-template.md` in `.specify/templates/` with the updated principles.
+- Updates **project-local** command files and guidance docs to correct stale references.
+- Extends the Sync Impact Report in `.specify/memory/constitution.md` with the files it touched.
+
+## What it does not do
+
+- It does **not** change behavior for anyone who does not install it — the default runtime
+  resolution model is untouched.
+- It does **not** disable runtime resolution. `plan`, `tasks`, and `analyze` still read the live
+  constitution every run; this preset adds materialized copies on top — it does not replace the
+  source of truth.
+- It does **not** edit versioned, package-owned files — templates or command files provided or
+  wrapped by another preset or extension. Those are recomposed from the resolution stack, so it
+  only ever writes into your project's own `.specify/templates/` scaffolds and command files that
+  are not managed by a preset/extension.
+
+## When to use it
+
+Install it **only** if your team treats the materialized templates and commands as
+**reviewed, committed artifacts** — for example, if `plan-template.md`'s Constitution Check is
+read in PRs as "here are our current gates" and is expected to track the constitution.
+
+If you rely on the default runtime-resolution model, you do **not** need this preset: the live
+constitution is already the single source of truth and there is nothing to sync.
+
+## Caveats you take on
+
+The preset resolution stack is how Spec Kit composes templates and commands going forward: they are
+**layered, package-owned artifacts recomposed on demand**, not frozen files you edit in place.
+Propagation is the opposite idea — it **materializes** guidance into files and freezes it. That
+tension is the main thing to understand before installing:
+
+- **Materialized copies can drift.** Anything propagated is a snapshot; if you amend the
+  constitution and do not re-run `/constitution`, the copies fall out of sync. The default runtime
+  model has no drift because it reads the live constitution every run.
+
+- **Edits to composed files do not survive reconciliation.** If the rest of your SDD flow is
+  preset/extension-managed, the commands it materializes (`speckit.plan`, `speckit.specify`,
+  `speckit.tasks`, `speckit.analyze`, `speckit.implement`, …) are recomputed from the stack. Any
+  guidance propagated into them is clobbered the next time the stack reconciles — on
+  `specify integration use <key>` / `switch`, `specify integration upgrade`, or any preset/extension
+  install or remove. The same applies to templates owned by another preset/extension. This is why
+  the preset restricts itself to project-local files; propagation is reliable **only** for
+  artifacts you own outright.
+
+- **A pre-filled Constitution Check can bias `/plan`.** Materializing concrete gates into
+  `plan-template.md` replaces the runtime pointer, so the first `/plan` pass may anchor on the
+  frozen text. Keep the pointer unless you specifically want committed gates.
+
+**Bottom line:** this preset fits projects whose governed templates and commands are project-local
+artifacts they review, with the rest of the SDD flow on the plain bundled core. If your
+`plan`/`specify`/`tasks`/`analyze` commands or templates come from other presets or extensions,
+prefer the default runtime-resolution model.
+
+## Installation
+
+```bash
+# constitution-sync is a bundled preset — no download needed
+specify preset add constitution-sync
+```
+
+## Development
+
+```bash
+# Test from local directory
+specify preset add --dev ./presets/constitution-sync
+
+# Verify the wrapped command resolves
+specify preset resolve speckit.constitution
+
+# Remove when done
+specify preset remove constitution-sync
+```
+
+## Migrating back to the default
+
+To move back to runtime resolution, reset each materialized `## Constitution Check` section in
+`.specify/templates/plan-template.md` to the pointer:
+
+```text
+## Constitution Check
+
+*GATE: Must pass before Phase 0 research. Re-check after Phase 1 design.*
+
+[Gates determined based on constitution file]
+```
+
+Then remove this preset. See `docs/upgrade.md` for details.
+
+## License
+
+MIT

specify_cli-0.15.1/presets/constitution-sync/commands/speckit.constitution.md

@@ -0,0 +1,54 @@
+---
+description: Create or update the project constitution, then propagate the amended guidance into dependent templates and installed command files (opt-in template sync).
+strategy: wrap
+handoffs:
+  - label: Build Specification
+    agent: speckit.specify
+    prompt: Implement the feature specification based on the updated constitution. I want to build...
+---
+
+{CORE_TEMPLATE}
+
+## Constitution Template Sync
+
+> **This section supersedes the "Scope Guard" above for template and command propagation.**
+> The core Scope Guard states that dependent templates and commands "are not modified here" —
+> that restriction is intentionally lifted by this preset. Propagating amended guidance into the
+> project's own dependent scaffolds and installed command files (as described below) **is in
+> scope** whenever this preset is installed. The Scope Guard's other constraints still apply:
+> do not implement features, generate application code, or touch artifacts unrelated to the
+> constitution/template workflow.
+
+After you have written the updated constitution above, perform a consistency propagation pass
+so the dependent artifacts reflect the amended principles:
+
+1. Read `.specify/templates/plan-template.md` and ensure any "Constitution Check" or rules align
+   with the updated principles. Only materialize concrete gate text here if your team intends to
+   review it as committed content; otherwise leave the runtime pointer
+   `[Gates determined based on constitution file]` in place so `/plan` fills it from the live
+   constitution.
+2. Read `.specify/templates/spec-template.md` for scope/requirements alignment — update if the
+   constitution adds/removes mandatory sections or constraints.
+3. Read `.specify/templates/tasks-template.md` and ensure task categorization reflects new or
+   removed principle-driven task types (e.g., observability, versioning, testing discipline).
+4. Read each installed Spec Kit command file for your agent (including this one) — named
+   `speckit.*` or `speckit-*` (dot or hyphen depending on the agent), or laid out as
+   `speckit-<name>/SKILL.md` for skills-based integrations, e.g. in `.github/agents/`,
+   `.github/skills/`, `.claude/skills/`, or your agent's equivalent commands directory — to verify
+   no outdated references (CLAUDE-only or other agent-specific names) remain when generic guidance
+   is required. **Only hand-edit a command file if it is a project-local file not managed by a
+   preset or extension.** Command files that are composed from the resolution stack (anything
+   provided or wrapped by a preset/extension) must be regenerated through the stack — do **not**
+   edit them in place, because reconciliation (`specify integration use`, `specify integration
+   upgrade`, or any preset/extension install/remove) will clobber the edits.
+5. Read any runtime guidance docs (e.g., `README.md`, `docs/quickstart.md`, or agent-specific
+   guidance files if present) and update references to principles that changed.
+
+Then extend the Sync Impact Report at the top of `.specify/memory/constitution.md` with:
+
+- Templates requiring updates (✅ updated / ⚠ pending) with file paths.
+
+**Do not edit versioned preset- or extension-provided template or command files directly.** Those
+artifacts are owned by their packages and are recomposed on the package's next update or on stack
+reconciliation — hand edits are clobbered. Limit propagation to the project's own
+`.specify/templates/` scaffolds and to command files that are not managed by a preset or extension.

specify_cli-0.15.1/presets/constitution-sync/preset.yml

@@ -0,0 +1,30 @@
+schema_version: "1.0"
+
+preset:
+  id: "constitution-sync"
+  name: "Constitution Template Sync"
+  version: "1.0.0"
+  description: "Opt-in: restores /constitution propagation of amended guidance into plan/spec/tasks templates and installed command files, for teams that treat materialized templates as reviewed artifacts."
+  author: "github"
+  repository: "https://github.com/github/spec-kit"
+  license: "MIT"
+
+requires:
+  # Requires the runtime-resolution baseline (#3790, shipped in 0.14.4) where the
+  # core /constitution command no longer propagates. Installing this preset on an
+  # older core would double-apply propagation.
+  speckit_version: ">=0.14.4"
+
+provides:
+  templates:
+    - type: "command"
+      name: "speckit.constitution"
+      file: "commands/speckit.constitution.md"
+      description: "Wrap /constitution to also propagate guidance into dependent templates and command files"
+      strategy: "wrap"
+
+tags:
+  - "constitution"
+  - "governance"
+  - "templates"
+  - "compatibility"

{specify_cli-0.15.0 → specify_cli-0.15.1}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "specify-cli"
-version = "0.15.0"
+version = "0.15.1"
 description = "Specify CLI, part of GitHub Spec Kit. A tool to bootstrap your projects for Spec-Driven Development (SDD)."
 readme = "README.md"
 requires-python = ">=3.11"
@@ -49,6 +49,7 @@ packages = ["src/specify_cli"]
 "workflows/speckit" = "specify_cli/core_pack/workflows/speckit"
 # Bundled presets (installable via `specify preset add <name>` or `specify init --preset <name>`)
 "presets/lean" = "specify_cli/core_pack/presets/lean"
+"presets/constitution-sync" = "specify_cli/core_pack/presets/constitution-sync"
 # Community bundle catalog snapshot (used for offline discovery)
 "bundles/catalog.community.json" = "specify_cli/core_pack/bundles/catalog.community.json"
 

{specify_cli-0.15.0 → specify_cli-0.15.1}/scripts/powershell/common.ps1

@@ -55,9 +55,17 @@ function Resolve-SpecifyInitDir {
     }
     # Resolve-Path echoes back any trailing separator from the input; trim it so
     # the returned root matches the bash resolver, whose `cd && pwd` never yields
-    # one. TrimEndingDirectorySeparator is a no-op on a bare root and on a path
-    # that already has no trailing separator.
-    $initRoot = [System.IO.Path]::TrimEndingDirectorySeparator($resolved.Path)
+    # one. TrimEnd (not [Path]::TrimEndingDirectorySeparator, which is .NET Core
+    # only) keeps this working on Windows PowerShell 5.1 / .NET Framework, as
+    # Get-FeaturePathsEnv already does below. Unlike a bare TrimEnd, the
+    # GetPathRoot check preserves a path that *is* its own root ('C:\' must not
+    # become 'C:', which every later API re-resolves against the current
+    # directory instead of the drive root). No-op on a path with no trailing
+    # separator.
+    $initRoot = $resolved.Path.TrimEnd('/', '\')
+    if ($initRoot.Length -lt [System.IO.Path]::GetPathRoot($resolved.Path).Length) {
+        $initRoot = $resolved.Path
+    }
     if (-not (Test-Path -LiteralPath (Join-Path $initRoot '.specify') -PathType Container)) {
         [Console]::Error.WriteLine("ERROR: SPECIFY_INIT_DIR is not a Spec Kit project (no .specify/ directory): $initRoot")
         if ($ReturnNullOnError) { return $null }