Release 0.1.1

CHANGELOG.md

@@ -2,10 +2,12 @@
 
 ## [Unreleased]
 
+## [0.1.1] - 2026-10-17
+
 ### Changed
 
 - Rewrite the README around a quick start: the real clone URL, how to start a feature with smithy, red-amber-green next to the gates it belongs to, a table of the `damascus` commands, and a `vX.Y.Z` upgrade example instead of a release that doesn't exist ([#28](https://github.com/forkrul/damascus_development/pull/28))
-- Mark `docs/production-readiness.md` as a record of the original plan with branch protection the one open item, and describe the docs as harness-agnostic rather than Claude Code-only ([#28](https://github.com/forkrul/damascus_development/pull/28))
+- Mark `docs/production-readiness.md` as a record of the original plan, with `master` protected by a repository ruleset, and describe the docs as harness-agnostic rather than Claude Code-only ([#28](https://github.com/forkrul/damascus_development/pull/28))
 
 ### Added
 
@@ -62,5 +64,6 @@ _Initial release._
 - Document the single-founder production-readiness plan ([#3](https://github.com/forkrul/damascus_development/pull/3))
 - License the project under MIT; vendored submodules keep their upstream licenses ([#3](https://github.com/forkrul/damascus_development/pull/3))
 
-[Unreleased]: https://github.com/forkrul/damascus_development/compare/v0.1.0...HEAD
+[Unreleased]: https://github.com/forkrul/damascus_development/compare/v0.1.1...HEAD
+[0.1.1]: https://github.com/forkrul/damascus_development/releases/tag/v0.1.1
 [0.1.0]: https://github.com/forkrul/damascus_development/releases/tag/v0.1.0

README.md

@@ -14,10 +14,10 @@ From your repo root, pinning a release tag (see [Releases](https://github.com/fo
 
 ```bash
 git submodule add https://github.com/forkrul/damascus_development.git vendor/damascus
-git -C vendor/damascus checkout v0.1.0                          # pin a release, never a moving branch
+git -C vendor/damascus checkout v0.1.1                          # pin a release, never a moving branch
 git -C vendor/damascus submodule update --init --recursive      # damascus's own pinned submodules
 ./vendor/damascus/install.sh
-git add .gitmodules vendor/damascus && git commit -m "chore: vendor damascus v0.1.0"
+git add .gitmodules vendor/damascus && git commit -m "chore: vendor damascus v0.1.1"
 ```
 
 Then, in an agent session in that repo, start a feature with the orchestrator — in Claude Code, `/smithy` (or its alias `/spdd-pipeline`), or just say "let's build *feature X*" and ask for the smithy skill. Smithy runs the next stage, halts at every gate for your signoff, and picks up where it left off on `smithy --resume`. To see what a finished run looks like before starting one, read [`examples/`](examples/): one feature's complete artifact trail through all five gates.

docs/README.md

@@ -6,7 +6,7 @@ This folder is a [Sphinx](https://www.sphinx-doc.org/) site that also reads well
 |------|----------------|
 | [Architecture](architecture.md) | The contracts as diagrams: pipeline and artifacts, smithy's state machine, the adversarial review round, red-amber-green, parallel `[P]` tasks, how `install.sh` places a link, the superpowers policy |
 | [Configuration and CLI reference](reference.md) | Running the `damascus` commands; model routing (`.damascus/models.conf`, `DAMASCUS_*` variables); every gate's flags and file formats; stage addenda; the evaluation harness and live critic benchmark |
-| [Production readiness](production-readiness.md) | The phased single-founder plan, kept as a record; what is still open |
+| [Production readiness](production-readiness.md) | The phased single-founder plan, kept as a record |
 | [Hero image provenance](assets/README.md) | How `hero.png` was made and why it carries no lettering |
 
 The rest of the site is generated at build time from the files that ship, so there is

docs/production-readiness.md

@@ -17,10 +17,10 @@ choice below: prefer automation over process, CI gates over human review, and
 scheduled bots over remembering things.
 
 > **Status (2026-10):** this is the plan as written before the work, kept as a
-> record; checked boxes are done. `v0.1.0` is
-> [released](https://github.com/forkrul/damascus_development/releases/tag/v0.1.0).
-> One item is still open: **branch protection on `master`** (require PR + green CI,
-> no force-push, no required approver count), set in repo Settings → Branches.
+> record; checked boxes are done. Releases are on the
+> [Releases page](https://github.com/forkrul/damascus_development/releases), and
+> `master` is protected by a repository ruleset (pull request required, no
+> force-push, no deletion, no required approver count).
 > Where an item below describes the starting point — bash ≥ 4, GNU coreutils —
 > Phase 1 removed it: `install.sh` now runs on stock macOS bash 3.2.
 
@@ -92,7 +92,10 @@ Consumers add damascus as a submodule — today they can only pin an opaque SHA
       `git -C vendor/damascus checkout v0.1.0` — and add an **Upgrading** section
       (checkout new tag → commit pointer → re-run `install.sh`; the install is
       idempotent and prunes/refreshes its own links).
-- [ ] **Branch protection on `master`**: require PR + green CI, no force-push.
+- [x] **Branch protection on `master`**: require PR + green CI, no force-push.
+      *(Done as a repository ruleset on the default branch: pull request
+      required, force-push and deletion blocked. Green CI is enforced by the
+      merge flow rather than a required status check.)*
       Do **not** require a second approver — that deadlocks a solo maintainer;
       CI is the gate, and the temper-style self-review discipline covers the rest.