slipwai 1.4.0.dev10__tar.gz → 1.4.1.dev4__tar.gz

{slipwai-1.4.0.dev10 → slipwai-1.4.1.dev4}/CHANGELOG.md

@@ -2,6 +2,61 @@
 
 No public releases yet. Release notes are recorded here newest first.
 
+## 1.4.0 — MINOR
+
+**`slipwai generate` runs the project's `./init` as its last step, and every missing tool is named with the
+command that installs it on your machine.** Answering the questions at a terminal now ends the way
+`slipwai adopt` does: `./init` runs from inside the new project, so Spec Kit and the agent's skills are in
+place without a second command. `--integration <agent>` passes the agent through; `--init` asks for the run
+from the argument form, which otherwise leaves it as the next step as before; `--no-init` skips it anywhere.
+
+The machine is now detected — macOS, Linux, WSL or Windows, and which of Homebrew, MacPorts, apt, dnf,
+pacman, zypper, apk, winget, Scoop or Chocolatey it has — so a production target's refusal says
+`brew install opentofu` or `winget install --exact --id OpenTofu.Tofu` beside the install page, and
+`./init` without uv or Python says the line that installs uv there. On native Windows, where a `/bin/sh`
+script cannot run as it is, `generate` and `adopt` (experimental) run `./init` through Git for Windows' `sh`
+when it is installed and otherwise say to use WSL or Git Bash; neither starts `./init` on a machine with no
+`python3`, and both name the command that installs it.
+
+**`./init` has uv make PyYAML importable by the `python3` Spec Kit's scripts call, with nothing to
+activate.** Spec Kit's scripts need PyYAML on the bare `python3` they take off the PATH. On a Python that
+refuses pip outside a venv (PEP 668: Homebrew's on macOS, Debian's and Ubuntu's), `./init` used to build a
+venv at `.delivery-tools/venv` and ask you to `export PATH="$PWD/.delivery-tools/venv/bin:$PATH"` before
+starting the agent — in every shell, and in no agent session unless it was started from one. It now runs
+`uv pip install --python python3`, into that `python3`'s venv if it is a venv's and otherwise `--target`
+its user site, which it already reads: uv is what slipwai is installed with, needs no pip on that Python,
+and writes a directory rather than the managed environment, so PEP 668 has nothing to refuse and the
+system's packages are never touched. Without uv, `./init` says the line that installs it on that machine.
+No venv is made, and no `PATH` line is printed.
+
+**Catch-up.** If `./init` gave you the `export PATH=…/.delivery-tools/venv/bin…` line, run `./init` once
+more — with no arguments it leaves Spec Kit alone and only repeats this step — then drop that line from
+your shell profile and `rm -rf .delivery-tools/venv`.
+
+**`slipwai generate` works in PowerShell, and a generated repository's scripts stay runnable in a Windows
+clone.** Every file slipwai reads or writes, and every one the Python scripts a project ships read or write,
+is now opened as UTF-8 by name. Before, they took the locale's encoding, which is cp1252 on Windows, so the
+first `slipwai generate` there stopped with `UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d`
+reading slipwai's own skill files; setting `PYTHONUTF8=1` was the workaround, and is no longer needed. A
+test now holds every text-mode `open`, `read_text` and `write_text` to it. Every text file they *write*
+is also written with LF (`newline="\n"`): on Windows a write without it turns each line ending into CRLF,
+so the pruner `generate` runs left the new project's files, `./init` among them, CRLF on disk.
+
+A generated repository gets a root `.gitattributes`: `* text=auto eol=lf`, with CRLF kept for `.bat` and
+`.cmd`. Git for Windows defaults `core.autocrlf` to `true`, which checked every file out with CRLF, and a
+`#!/bin/sh` script with CRLF does not run (`/bin/sh^M: bad interpreter`), which made `./init` and the gate
+unrunnable under Git Bash and printed an "LF will be replaced by CRLF" warning per file on every commit. An
+adopted repository keeps its own root `.gitattributes` untouched and gets one scoped to the delivery
+directory (experimental), which decides only for the files under it.
+
+A generated project's `make verify` also runs on native Windows now (from Git Bash, with GNU Make and Node
+installed). It failed at one recipe, `check-drawio`, which called `node_modules/.bin/tsx`: npm's POSIX shim,
+which a Windows `make` cannot run. The event-model recipes now run tsx's entry point with `node`.
+
+**Catch-up.** `slipwai migrate` brings the `.gitattributes`. In a Windows clone whose files were already
+checked out with CRLF, re-check them out once so they take it: with a clean tree,
+`git rm -r --cached -q . && git reset --hard`.
+
 ## 1.3.0 — MINOR
 
 **`slipwai adopt` refuses an unclean tree, a directory that is not a Git repository, or one already holding a

{slipwai-1.4.0.dev10 → slipwai-1.4.1.dev4}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: slipwai
-Version: 1.4.0.dev10
+Version: 1.4.1.dev4
 Summary: One-shot scaffolder for product monorepos: a walking skeleton, a verify gate, a path to production, and a repository set up for coding agents.
 Project-URL: Homepage, https://github.com/ROBCOATVG/slipwai
 Project-URL: Repository, https://git.treyco.dev/ROBCOATVG/slipwai
@@ -43,11 +43,13 @@ The canonical source is
 there.
 
 ```sh
-slipwai generate            # answer a few questions -> a fresh Git repo, one commit, on main
-cd ledger && ./init         # Spec Kit + your coding agent, on demand
-make verify                 # the gate, the same one CI runs
+slipwai generate            # answer a few questions -> a fresh Git repo on main, with Spec Kit
+                            # and your coding agent already set up
+cd ledger && make verify    # the gate, the same one CI runs
 ```
 
+It runs on macOS, Linux, WSL and Windows. On Windows, a project's scripts run under Git Bash (Git for Windows).
+
 **Jump to** — [New to this](#new-to-this--start-here) · [What it is](#what-it-is) ·
 [Getting started](#getting-started) · [Cruise](#cruise-drive-with-nobody-at-the-wheel) ·
 [What you get](#what-you-get) · [The answers you give](#the-answers-you-give) · [Documentation](#documentation)
@@ -84,8 +86,9 @@ It is not a one-way door. You can run the factory again inside a project it made
   that list the project's applications. The factory derives that set by generating the project twice and
   comparing the results, so it cannot drift from a hand-kept list. **`slipwai describe-service`** records
   what a service already there is for — its purpose and its bounded contexts — and regenerates the same way.
-- **`./init`** answers the event store, HTTP, staff identity and customer identity questions again, by
-  removing what the old answers brought.
+- **The project's `./init`, run again,** answers the event store, HTTP, staff identity and customer identity
+  questions again, by removing what the old answers brought. (`generate` runs it once for you; running it
+  again is for changing an answer, the coding agent, or the extensions.)
 
 Both respect what the project has become, not what it was generated from.
 
@@ -130,7 +133,7 @@ Every other question has its own answer, and a project can answer most of them a
 
 ## Getting started
 
-Four steps. You install a `slipwai` command and run it. You do not clone this repository.
+Three steps. You install a `slipwai` command and run it. You do not clone this repository.
 
 New here? Follow the runsheet for your case: [generate a new project](docs/learn-generate.md), or
 [adopt an existing repository](docs/learn-adopt.md). Each is every step in order, from installing the
@@ -144,8 +147,14 @@ how you know it worked, and what the terminal shows.
 
 Scaffolding needs **Python 3.11 or later** and **Git**.
 
-**`uv` is the recommended installer.** It is worth having anyway: a generated project's `./init` uses `uv`
-to fetch Spec Kit, so one tool covers both ends.
+**`uv` is the recommended installer.** It is worth having anyway: when `generate` or `adopt` sets a project up,
+it uses `uv` to fetch Spec Kit and to give your `python3` the PyYAML that Spec Kit's scripts need, so one tool
+covers both ends.
+
+When `slipwai` finds a tool missing, it names the command that installs it with the package manager your
+machine has: Homebrew or MacPorts on macOS; apt, dnf, pacman, zypper or apk on Linux and WSL; winget, Scoop or
+Chocolatey on Windows. On Windows you also need [Git for Windows](https://git-scm.com/download/win), because a
+project's scripts and `Makefile` run under its Git Bash.
 
 ```sh
 uv tool install slipwai
@@ -162,23 +171,39 @@ of `main` as well.
 This repository is the factory that *makes* the command. Clone it only to change the factory.
 [Work on the factory](docs/maintaining.md) is that path.
 
-**Going to a cloud needs four more things on the machine before you generate**, because `./init` there
-pushes the repository and bootstraps the account:
+**Going to a cloud needs four more things on the machine before you generate**, because setting the project
+up there pushes the repository and bootstraps the account:
 
 1. OpenTofu.
 2. That cloud's CLI, signed in with enough authority to create what the bootstrap creates.
 3. A region.
 4. Access to your forge.
 
-`slipwai generate` checks all four as soon as you choose `aws` or `azure`, and refuses with what is missing.
+`slipwai generate` checks all four as soon as you choose `aws` or `azure`, and refuses with what is missing
+and the command that installs each one on this machine.
 [Tools required](docs/requirements.md) has the full list. Running costs are in
 [The AWS target](docs/aws-target.md) and [The Azure target](docs/azure-target.md), which is also where the
 two are compared.
 
 ### 2. Generate a project
 
-Run `generate` with no arguments to be asked one question at a time. Pass the answers as flags for scripts
-and CI:
+```sh
+slipwai generate
+```
+
+It asks one question at a time, writes the repository as one commit on `main`, and then sets it up for your
+coding agent in the same command:
+
+- it installs Spec Kit;
+- it asks which coding agent to project `skills/`, `commands/` and `agents/` into — any of
+  [36 harnesses](docs/spec-kit.md);
+- it offers optional extensions as a checkbox menu: CodeGraph, UI/UX Pro Max and the UX gates.
+
+What that setup writes is left uncommitted for you to read, then `git add -A && git commit`. On Windows it runs
+under Git Bash.
+
+For scripts and CI, pass every answer as a flag. Add `--init` to get the same setup, and `--integration` to name
+the agent instead of being asked:
 
 ```sh
 slipwai generate ledger \
@@ -186,28 +211,22 @@ slipwai generate ledger \
   --language typescript \
   --frontend react-vite \
   --event-store postgres \
-  --http fastify
+  --http fastify \
+  --init --integration claude
 ```
 
-That creates `./ledger` in the current directory, initialised on `main` with one commit. The target
-directory must not already exist. `--output` names a different **parent directory**.
-
-### 3. Bootstrap the new repository
-
-Spec Kit is deliberately absent until you ask for it. From inside the generated project:
-
-```sh
-./init
-```
+That creates `./ledger` in the current directory. The target directory must not already exist, and `--output`
+names a different **parent directory**. Without `--init`, the flag form writes the repository and stops there;
+`--no-init` does the same for the interactive form.
 
-That installs Spec Kit. It then asks which coding agent to project `skills/`, `commands/` and `agents/`
-into — any of [36 harnesses](docs/spec-kit.md). It then offers optional extensions as a checkbox menu:
-CodeGraph, UI/UX Pro Max and the UX gates.
+**`slipwai adopt`** is the same single command for a repository that already exists: it installs the method
+around your code and sets it up for your agent. See [Adopt an existing repository](docs/learn-adopt.md).
 
-`--integration <name>` and `--extension <key>` skip those questions. `--extension` also adds one later. See
+**Changing the setup later.** The project keeps its `./init`, so you can switch or add a coding agent
+(`./init --integration <agent>`) or add an extension (`./init --extension <key>`) at any time. See
 [Extensions](docs/extensions.md).
 
-### 4. Work in it, and run it
+### 3. Work in it, and run it
 
 ```sh
 make help        # every target, with a line each
@@ -307,7 +326,7 @@ Everything below is in a generated repository from its first commit.
 | **[Generated documentation](docs/what-you-get.md#documentation-written-for-this-project)** | Thirteen pages written for this project's actual shape rather than copied, and an index built from the files that shipped |
 | **[Services and bounded contexts](docs/services.md)** | One list of applications, each with its own language, framework and answers. `add-service` and `add-frontend` grow it. Contexts are found rather than declared |
 | **[A path to production](docs/aws-target.md)** | `--target aws` or `--target azure` gives you `infra/` in OpenTofu, one deployable per application released blue/green, a pipeline from every push to `main` through staging to production, and a one-command rollback. The same promise on either cloud. [The Azure page](docs/azure-target.md) is where they are compared |
-| **[Extensions](docs/extensions.md)** | Optional dev tooling, adopted with `./init --extension <key>`: a code index, a design-system generator, and objective UX gates in `make verify`. None of them changes the generated skeleton's code |
+| **[Extensions](docs/extensions.md)** | Optional dev tooling, offered when you generate or adopt, or added later with `./init --extension <key>`: a code index, a design-system generator, and objective UX gates in `make verify`. None of them changes the generated skeleton's code |
 
 ### The commands a project gets
 
@@ -447,7 +466,7 @@ is which, what each answer brings, and how a project answers a question again la
 | [The skill catalogue](docs/skills.md) | The 51 skills grouped by what they are for, why a project is given only the ones whose subject it has, how examples are rendered in your own languages, and where to edit them |
 | [The global event model](docs/event-model.md) | Why the model is global, what `make model` renders, the status ladder `make check-model` enforces, and how the browsable page is published |
 | [Gates](docs/verification.md) | What `make verify` runs, what is deliberately outside it, and why the split falls where it does |
-| [Bootstrap Spec Kit](docs/spec-kit.md) | `./init`, the 36 agent integrations, how Spec Kit is obtained, and the constitution floor gated from both sides |
+| [Bootstrap Spec Kit](docs/spec-kit.md) | How `generate` and `adopt` set up Spec Kit (and `./init`, which re-runs that setup), the 36 agent integrations, how Spec Kit is obtained, and the constitution floor gated from both sides |
 | [Services](docs/services.md) | `project.json`'s one list of applications, everything that reads it, what a second service is in each language, `add-service` and `add-frontend` and their agent commands, and what a maintainer owes a new generated file that names an application |
 | [Extensions](docs/extensions.md) | `./init --extension <key>`, the contract every extension's `init.py` owes, and what makes a second one a catalog entry plus one file |
 | [The AWS target](docs/aws-target.md) | What `--target aws` gives: the stacks, the images, the pipeline and the rollback. What it costs, what the factory proves about it and what it cannot, and how the next cloud becomes a row |

{slipwai-1.4.0.dev10 → slipwai-1.4.1.dev4}/README.md

@@ -14,11 +14,13 @@ The canonical source is
 there.
 
 ```sh
-slipwai generate            # answer a few questions -> a fresh Git repo, one commit, on main
-cd ledger && ./init         # Spec Kit + your coding agent, on demand
-make verify                 # the gate, the same one CI runs
+slipwai generate            # answer a few questions -> a fresh Git repo on main, with Spec Kit
+                            # and your coding agent already set up
+cd ledger && make verify    # the gate, the same one CI runs
 ```
 
+It runs on macOS, Linux, WSL and Windows. On Windows, a project's scripts run under Git Bash (Git for Windows).
+
 **Jump to** — [New to this](#new-to-this--start-here) · [What it is](#what-it-is) ·
 [Getting started](#getting-started) · [Cruise](#cruise-drive-with-nobody-at-the-wheel) ·
 [What you get](#what-you-get) · [The answers you give](#the-answers-you-give) · [Documentation](#documentation)
@@ -55,8 +57,9 @@ It is not a one-way door. You can run the factory again inside a project it made
   that list the project's applications. The factory derives that set by generating the project twice and
   comparing the results, so it cannot drift from a hand-kept list. **`slipwai describe-service`** records
   what a service already there is for — its purpose and its bounded contexts — and regenerates the same way.
-- **`./init`** answers the event store, HTTP, staff identity and customer identity questions again, by
-  removing what the old answers brought.
+- **The project's `./init`, run again,** answers the event store, HTTP, staff identity and customer identity
+  questions again, by removing what the old answers brought. (`generate` runs it once for you; running it
+  again is for changing an answer, the coding agent, or the extensions.)
 
 Both respect what the project has become, not what it was generated from.
 
@@ -101,7 +104,7 @@ Every other question has its own answer, and a project can answer most of them a
 
 ## Getting started
 
-Four steps. You install a `slipwai` command and run it. You do not clone this repository.
+Three steps. You install a `slipwai` command and run it. You do not clone this repository.
 
 New here? Follow the runsheet for your case: [generate a new project](docs/learn-generate.md), or
 [adopt an existing repository](docs/learn-adopt.md). Each is every step in order, from installing the
@@ -115,8 +118,14 @@ how you know it worked, and what the terminal shows.
 
 Scaffolding needs **Python 3.11 or later** and **Git**.
 
-**`uv` is the recommended installer.** It is worth having anyway: a generated project's `./init` uses `uv`
-to fetch Spec Kit, so one tool covers both ends.
+**`uv` is the recommended installer.** It is worth having anyway: when `generate` or `adopt` sets a project up,
+it uses `uv` to fetch Spec Kit and to give your `python3` the PyYAML that Spec Kit's scripts need, so one tool
+covers both ends.
+
+When `slipwai` finds a tool missing, it names the command that installs it with the package manager your
+machine has: Homebrew or MacPorts on macOS; apt, dnf, pacman, zypper or apk on Linux and WSL; winget, Scoop or
+Chocolatey on Windows. On Windows you also need [Git for Windows](https://git-scm.com/download/win), because a
+project's scripts and `Makefile` run under its Git Bash.
 
 ```sh
 uv tool install slipwai
@@ -133,23 +142,39 @@ of `main` as well.
 This repository is the factory that *makes* the command. Clone it only to change the factory.
 [Work on the factory](docs/maintaining.md) is that path.
 
-**Going to a cloud needs four more things on the machine before you generate**, because `./init` there
-pushes the repository and bootstraps the account:
+**Going to a cloud needs four more things on the machine before you generate**, because setting the project
+up there pushes the repository and bootstraps the account:
 
 1. OpenTofu.
 2. That cloud's CLI, signed in with enough authority to create what the bootstrap creates.
 3. A region.
 4. Access to your forge.
 
-`slipwai generate` checks all four as soon as you choose `aws` or `azure`, and refuses with what is missing.
+`slipwai generate` checks all four as soon as you choose `aws` or `azure`, and refuses with what is missing
+and the command that installs each one on this machine.
 [Tools required](docs/requirements.md) has the full list. Running costs are in
 [The AWS target](docs/aws-target.md) and [The Azure target](docs/azure-target.md), which is also where the
 two are compared.
 
 ### 2. Generate a project
 
-Run `generate` with no arguments to be asked one question at a time. Pass the answers as flags for scripts
-and CI:
+```sh
+slipwai generate
+```
+
+It asks one question at a time, writes the repository as one commit on `main`, and then sets it up for your
+coding agent in the same command:
+
+- it installs Spec Kit;
+- it asks which coding agent to project `skills/`, `commands/` and `agents/` into — any of
+  [36 harnesses](docs/spec-kit.md);
+- it offers optional extensions as a checkbox menu: CodeGraph, UI/UX Pro Max and the UX gates.
+
+What that setup writes is left uncommitted for you to read, then `git add -A && git commit`. On Windows it runs
+under Git Bash.
+
+For scripts and CI, pass every answer as a flag. Add `--init` to get the same setup, and `--integration` to name
+the agent instead of being asked:
 
 ```sh
 slipwai generate ledger \
@@ -157,28 +182,22 @@ slipwai generate ledger \
   --language typescript \
   --frontend react-vite \
   --event-store postgres \
-  --http fastify
+  --http fastify \
+  --init --integration claude
 ```
 
-That creates `./ledger` in the current directory, initialised on `main` with one commit. The target
-directory must not already exist. `--output` names a different **parent directory**.
-
-### 3. Bootstrap the new repository
-
-Spec Kit is deliberately absent until you ask for it. From inside the generated project:
-
-```sh
-./init
-```
+That creates `./ledger` in the current directory. The target directory must not already exist, and `--output`
+names a different **parent directory**. Without `--init`, the flag form writes the repository and stops there;
+`--no-init` does the same for the interactive form.
 
-That installs Spec Kit. It then asks which coding agent to project `skills/`, `commands/` and `agents/`
-into — any of [36 harnesses](docs/spec-kit.md). It then offers optional extensions as a checkbox menu:
-CodeGraph, UI/UX Pro Max and the UX gates.
+**`slipwai adopt`** is the same single command for a repository that already exists: it installs the method
+around your code and sets it up for your agent. See [Adopt an existing repository](docs/learn-adopt.md).
 
-`--integration <name>` and `--extension <key>` skip those questions. `--extension` also adds one later. See
+**Changing the setup later.** The project keeps its `./init`, so you can switch or add a coding agent
+(`./init --integration <agent>`) or add an extension (`./init --extension <key>`) at any time. See
 [Extensions](docs/extensions.md).
 
-### 4. Work in it, and run it
+### 3. Work in it, and run it
 
 ```sh
 make help        # every target, with a line each
@@ -278,7 +297,7 @@ Everything below is in a generated repository from its first commit.
 | **[Generated documentation](docs/what-you-get.md#documentation-written-for-this-project)** | Thirteen pages written for this project's actual shape rather than copied, and an index built from the files that shipped |
 | **[Services and bounded contexts](docs/services.md)** | One list of applications, each with its own language, framework and answers. `add-service` and `add-frontend` grow it. Contexts are found rather than declared |
 | **[A path to production](docs/aws-target.md)** | `--target aws` or `--target azure` gives you `infra/` in OpenTofu, one deployable per application released blue/green, a pipeline from every push to `main` through staging to production, and a one-command rollback. The same promise on either cloud. [The Azure page](docs/azure-target.md) is where they are compared |
-| **[Extensions](docs/extensions.md)** | Optional dev tooling, adopted with `./init --extension <key>`: a code index, a design-system generator, and objective UX gates in `make verify`. None of them changes the generated skeleton's code |
+| **[Extensions](docs/extensions.md)** | Optional dev tooling, offered when you generate or adopt, or added later with `./init --extension <key>`: a code index, a design-system generator, and objective UX gates in `make verify`. None of them changes the generated skeleton's code |
 
 ### The commands a project gets
 
@@ -418,7 +437,7 @@ is which, what each answer brings, and how a project answers a question again la
 | [The skill catalogue](docs/skills.md) | The 51 skills grouped by what they are for, why a project is given only the ones whose subject it has, how examples are rendered in your own languages, and where to edit them |
 | [The global event model](docs/event-model.md) | Why the model is global, what `make model` renders, the status ladder `make check-model` enforces, and how the browsable page is published |
 | [Gates](docs/verification.md) | What `make verify` runs, what is deliberately outside it, and why the split falls where it does |
-| [Bootstrap Spec Kit](docs/spec-kit.md) | `./init`, the 36 agent integrations, how Spec Kit is obtained, and the constitution floor gated from both sides |
+| [Bootstrap Spec Kit](docs/spec-kit.md) | How `generate` and `adopt` set up Spec Kit (and `./init`, which re-runs that setup), the 36 agent integrations, how Spec Kit is obtained, and the constitution floor gated from both sides |
 | [Services](docs/services.md) | `project.json`'s one list of applications, everything that reads it, what a second service is in each language, `add-service` and `add-frontend` and their agent commands, and what a maintainer owes a new generated file that names an application |
 | [Extensions](docs/extensions.md) | `./init --extension <key>`, the contract every extension's `init.py` owes, and what makes a second one a catalog entry plus one file |
 | [The AWS target](docs/aws-target.md) | What `--target aws` gives: the stacks, the images, the pipeline and the rollback. What it costs, what the factory proves about it and what it cannot, and how the next cloud becomes a row |

slipwai-1.4.1.dev4/VERSION

@@ -0,0 +1 @@
+1.4.1.dev4

slipwai-1.4.0.dev10/VERSION

@@ -1 +0,0 @@
-1.4.0.dev10

slipwai-1.4.0.dev10/changelog.d/generate-runs-init.md

@@ -1,15 +0,0 @@
-MINOR
-
-**`slipwai generate` runs the project's `./init` as its last step, and every missing tool is named with the
-command that installs it on your machine.** Answering the questions at a terminal now ends the way
-`slipwai adopt` does: `./init` runs from inside the new project, so Spec Kit and the agent's skills are in
-place without a second command. `--integration <agent>` passes the agent through; `--init` asks for the run
-from the argument form, which otherwise leaves it as the next step as before; `--no-init` skips it anywhere.
-
-The machine is now detected — macOS, Linux, WSL or Windows, and which of Homebrew, MacPorts, apt, dnf,
-pacman, zypper, apk, winget, Scoop or Chocolatey it has — so a production target's refusal says
-`brew install opentofu` or `winget install --exact --id OpenTofu.Tofu` beside the install page, and
-`./init` without uv or Python says the line that installs uv there. On native Windows, where a `/bin/sh`
-script cannot run as it is, `generate` and `adopt` (experimental) run `./init` through Git for Windows' `sh`
-when it is installed and otherwise say to use WSL or Git Bash; neither starts `./init` on a machine with no
-`python3`, and both name the command that installs it.

slipwai-1.4.0.dev10/changelog.d/pyyaml-without-activation.md

@@ -1,16 +0,0 @@
-PATCH
-
-**`./init` has uv make PyYAML importable by the `python3` Spec Kit's scripts call, with nothing to
-activate.** Spec Kit's scripts need PyYAML on the bare `python3` they take off the PATH. On a Python that
-refuses pip outside a venv (PEP 668: Homebrew's on macOS, Debian's and Ubuntu's), `./init` used to build a
-venv at `.delivery-tools/venv` and ask you to `export PATH="$PWD/.delivery-tools/venv/bin:$PATH"` before
-starting the agent — in every shell, and in no agent session unless it was started from one. It now runs
-`uv pip install --python python3`, into that `python3`'s venv if it is a venv's and otherwise `--target`
-its user site, which it already reads: uv is what slipwai is installed with, needs no pip on that Python,
-and writes a directory rather than the managed environment, so PEP 668 has nothing to refuse and the
-system's packages are never touched. Without uv, `./init` says the line that installs it on that machine.
-No venv is made, and no `PATH` line is printed.
-
-**Catch-up.** If `./init` gave you the `export PATH=…/.delivery-tools/venv/bin…` line, run `./init` once
-more — with no arguments it leaves Spec Kit alone and only repeats this step — then drop that line from
-your shell profile and `rm -rf .delivery-tools/venv`.

slipwai-1.4.0.dev10/changelog.d/windows-utf8-and-line-endings.md

@@ -1,25 +0,0 @@
-MINOR
-
-**`slipwai generate` works in PowerShell, and a generated repository's scripts stay runnable in a Windows
-clone.** Every file slipwai reads or writes, and every one the Python scripts a project ships read or write,
-is now opened as UTF-8 by name. Before, they took the locale's encoding, which is cp1252 on Windows, so the
-first `slipwai generate` there stopped with `UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d`
-reading slipwai's own skill files; setting `PYTHONUTF8=1` was the workaround, and is no longer needed. A
-test now holds every text-mode `open`, `read_text` and `write_text` to it. Every text file they *write*
-is also written with LF (`newline="\n"`): on Windows a write without it turns each line ending into CRLF,
-so the pruner `generate` runs left the new project's files, `./init` among them, CRLF on disk.
-
-A generated repository gets a root `.gitattributes`: `* text=auto eol=lf`, with CRLF kept for `.bat` and
-`.cmd`. Git for Windows defaults `core.autocrlf` to `true`, which checked every file out with CRLF, and a
-`#!/bin/sh` script with CRLF does not run (`/bin/sh^M: bad interpreter`), which made `./init` and the gate
-unrunnable under Git Bash and printed an "LF will be replaced by CRLF" warning per file on every commit. An
-adopted repository keeps its own root `.gitattributes` untouched and gets one scoped to the delivery
-directory (experimental), which decides only for the files under it.
-
-A generated project's `make verify` also runs on native Windows now (from Git Bash, with GNU Make and Node
-installed). It failed at one recipe, `check-drawio`, which called `node_modules/.bin/tsx`: npm's POSIX shim,
-which a Windows `make` cannot run. The event-model recipes now run tsx's entry point with `node`.
-
-**Catch-up.** `slipwai migrate` brings the `.gitattributes`. In a Windows clone whose files were already
-checked out with CRLF, re-check them out once so they take it: with a clean tree,
-`git rm -r --cached -q . && git reset --hard`.