docs: the contributor-facing docs stop promising things the project cannot do

Smell-audited: 2: this is the ungated-negative-doc-claim class
(.dev/lessons/2026-08-03) caught at the last possible moment. Three documents
made commitments that outlived the project, and the version bump would have
shipped them into the final tag. Depth 2 rather than 1 because SECURITY.md is
not a documentation defect — a policy that promises fixes is one someone can
rely on while waiting for a patch that will never come.

Found while sweeping demo references: CONTRIBUTING.md opens with "Issues and
Pull Requests are open." Issues are disabled on this repository and always were
(verified via the API: has_issues=false), so the sentence was false, and the
divergence-report link it offered led to a form nobody can open.

- **SECURITY.md** claimed `main` and the newest 1.x line were supported and
  that fixes land in the next release cut from `main`. Neither is true and
  neither can become true. It now says plainly that no version is supported and
  there will be no fixes including for critical vulnerabilities, and that
  migrating off is the fix. The threat model and scope sections are kept and
  relabelled for forks, because those parts are still accurate. It also points
  vulnerabilities in the embedded engine at zwasm, which IS maintained and can
  still act on them — the one report that remains worth filing.
- **CONTRIBUTING.md** becomes a fork guide. The build, gate and test-layout
  sections were correct and are the things a fork would otherwise
  reverse-engineer, so they stay (and gained the two properties worth knowing
  before changing anything: dual-backend e2e, and clojure.core diffed against
  real clj). The PR-workflow and "what helps a PR land" sections describe a
  review that will not happen, and are gone.
- **PULL_REQUEST_TEMPLATE.md** said PRs were "currently PAUSED" and asked people
  to come back through Discussions. That framing promised a resumption.
- **ISSUE_TEMPLATE/config.yml** asserted "Issues are open" in a directory that
  does not render at all. The templates are kept deliberately — a fork enabling
  Issues gets a working set — and the comment now says so.
- **docs/clojure_vs_clojurewasm.md** described Part 2 gaps as "scheduled" and
  "on the roadmap". Nothing is scheduled; they are what was planned and never
  built, which is still useful to a fork as intent.

Author: chaploud

.github/CONTRIBUTING.md

@@ -1,29 +1,19 @@
-# Contributing to ClojureWasm
+# Working on ClojureWasm
 
-Thanks for your interest. **Issues and Pull Requests are open.** This is a
-small project, so replies can take a while — but the queue is real and it gets
-read.
+> [!IMPORTANT]
+> **ClojureWasm is no longer maintained, so there is nothing to contribute
+> *to*.** Issues and Pull Requests are disabled and always were — deliberately,
+> because they could not be serviced. Nothing will be merged here.
+>
+> **Fork it.** The licence (EPL-2.0) asks no permission and the project asks no
+> credit. This document is kept because everything below still works and is what
+> you would otherwise have to reverse-engineer: how to build it, how to run the
+> gate, and where the design is written down.
 
-## The most useful thing you can do
+## Building and testing
 
-**Report Clojure code that behaves differently here than on the JVM.**
-
-ClojureWasm targets behavioural equivalence with JVM Clojure on the
-user-observable surface. Every divergence you find is either a bug or a gap
-that has not been written down yet — and finding them from the outside is worth
-more than anything else, because a project cannot easily see its own blind
-spots.
-
-There is a [Clojure divergence issue template](https://github.com/clojurewasm/ClojureWasm/issues/new?template=divergence.yml)
-that asks for the three things that make such a report actionable: the
-expression, what `cljw` prints, and what a JVM REPL prints.
-
-Some differences are deliberate — check
-[`docs/clojure_vs_clojurewasm.md`](../docs/clojure_vs_clojurewasm.md) first. If
-one is listed there and you think the reasoning is wrong, that is a good
-Discussion.
-
-## Working on the code
+Everything here is current and verified — it is the same gate the final release
+was cut on.
 
 ```sh
 direnv allow                              # one-time: load Zig 0.16.0 via Nix (or: nix develop)
@@ -33,63 +23,60 @@ bash test/run_all.sh --serial-e2e         # the full gate; must be green before
 
 For a quick loop while iterating, `bash test/run_all.sh --smoke <e2e-step>`
 runs the unit tests, the dual-backend differential oracle, the linter, and the
-one end-to-end step you touched — tens of seconds instead of ~20 minutes. Run
-the full gate before you open the PR.
+one end-to-end step you touched — tens of seconds instead of ~20 minutes.
 
-Branch from `main` as `develop/<short-slug>`, open a PR, and let CI run. CI
-runs the same gate on macOS and Linux; a green CI is what merges.
+CI (`.github/workflows/ci.yml`) runs that same full gate on macOS and Linux, and
+runs exactly one configuration everywhere, so a green CI and a green local gate
+mean the same thing.
 
-### What we do **not** ask of you
+### Where the tests live
 
-This repository is developed largely by an autonomous loop working under
-written guardrails, and that loop follows conventions that exist to keep *it*
-honest. **None of them apply to your contribution:**
+- **Unit tests** in `test "..."` blocks next to the code they cover.
+- **CLI behaviour** in `test/e2e/*.sh`.
+- **`clojure.core` behaviour** additionally as a line in the relevant corpus
+  under `test/diff/clj_corpus/`, which is re-checked against a real `clj`.
+- The taxonomy, including which kinds of assertion are known to rot, is in
+  [`.claude/rules/test_taxonomy.md`](../.claude/rules/test_taxonomy.md).
 
-- You do not need a `Smell-audited:` line in your commit message.
-- You do not need to add a row to `.dev/debt.yaml`.
-- You do not need to write an ADR, a per-task note, or a ROADMAP amendment.
-- You do not need to match the commit-message style of the surrounding history.
+Two properties of the suite are worth knowing before you change anything, since
+they are what caught most of the bugs in this project's history: every
+end-to-end test runs on **both** the tree-walking interpreter and the bytecode
+VM and fails if they disagree, and `clojure.core` behaviour is diffed against
+real JVM Clojure rather than against hand-written expected values.
 
-Write a clear commit message, keep the gate green, and that is enough. If a
-change turns out to need a design record, writing it is the maintainer's job,
-not yours.
+### Conventions you can ignore
 
-### What helps a PR land
-
-- **One concern per PR.** A 30-line fix with a test merges; a 600-line
-  refactor bundled with a fix stalls.
-- **A test that fails before your change and passes after it.** The test
-  taxonomy is in [`.claude/rules/test_taxonomy.md`](../.claude/rules/test_taxonomy.md);
-  in short, unit tests live in `test "..."` blocks next to the code and CLI
-  behaviour lives in `test/e2e/*.sh`.
-- For a `clojure.core` behaviour change, **a line in the relevant corpus under
-  `test/diff/clj_corpus/`**, so the behaviour stays checked against real `clj`
-  from then on.
-
-A note on provenance: much of this codebase is machine-written under human
-review and direction. Contributions from people are very welcome and are
-reviewed the same way — on whether the code is right, not on who wrote it.
+Much of this repository was written by an autonomous loop under written
+guardrails, and the history reflects conventions that existed to keep *it*
+honest — `Smell-audited:` commit trailers, `.dev/debt.yaml` rows, ADRs,
+per-task notes. **None of it binds a fork.** They are documentation of how the
+work was done, not a process you inherit.
 
 ## Design context, if you want it
 
 Load-bearing decisions are recorded as ADRs under
 [`.dev/decisions/`](../.dev/decisions/); the plan and its principles live in
 [`.dev/ROADMAP.md`](../.dev/ROADMAP.md); the development loop itself is
-described in [`.claude/CLAUDE.md`](../.claude/CLAUDE.md). None of this is
-required reading to send a patch — it is there if you want to know why
-something is the way it is.
+described in [`.claude/CLAUDE.md`](../.claude/CLAUDE.md). Deliberate
+divergences from JVM Clojure — the ones that are decisions rather than bugs —
+are catalogued in
+[`docs/clojure_vs_clojurewasm.md`](../docs/clojure_vs_clojurewasm.md); read it
+before treating a difference as a defect.
+
+Nothing here is required reading. It is there so a fork does not have to
+re-derive why something is the way it is, and `.dev/debt.yaml` in particular is
+an honest list of what was known to be unfinished.
 
 ## Getting in touch
 
-Open-ended questions belong in
-[GitHub Discussions](https://github.com/clojurewasm/ClojureWasm/discussions);
-the wider Clojure community also gathers on the
+[GitHub Discussions](https://github.com/clojurewasm/ClojureWasm/discussions)
+stays open and may go unanswered; the wider Clojure community gathers on the
 [Clojurians Slack](https://clojurians.slack.com).
 
-Security problems should **not** be reported publicly — see
-[`SECURITY.md`](./SECURITY.md).
+There are no security fixes — see [`SECURITY.md`](./SECURITY.md), which is
+explicit about that.
 
 ## License
 
-By contributing, you agree that your contributions are licensed under the
-Eclipse Public License 2.0 (see [LICENSE](../LICENSE)).
+The project is under the Eclipse Public License 2.0 (see
+[LICENSE](../LICENSE)), and stays that way. A fork inherits it.

.github/ISSUE_TEMPLATE/config.yml

@@ -1,5 +1,7 @@
-# Issues are open. Blank issues stay disabled so every report starts from a
-# template that asks for the one or two facts that make it actionable.
+# Issues are DISABLED on this repository and always were, so nothing in this
+# directory currently renders. The templates are kept for forks, which get a
+# working set of report forms the moment they enable Issues; this config keeps
+# blank issues off so every report starts from one of them.
 blank_issues_enabled: false
 contact_links:
   - name: 💬 Questions, ideas, "is this supposed to work?"

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,14 +1,15 @@
 <!--
-  Pull Requests are currently PAUSED for ClojureWasm.
+  ClojureWasm is no longer maintained, and Pull Requests are disabled here.
+  This is not a backlog or a pause — nothing will be reviewed or merged.
 
-  ClojureWasm is a small, resource-limited project and cannot review external
-  PRs right now. Please close this PR and instead start a thread in Discussions:
+  Fork it instead. EPL-2.0 asks no permission and the project asks no credit;
+  see CONTRIBUTING.md for how to build it and run the gate.
 
-      https://github.com/clojurewasm/ClojureWasm/discussions
+  Discussions stay open and may go unanswered:
+  https://github.com/clojurewasm/ClojureWasm/discussions
 
-  and mention @chaploud. Thanks for understanding — we do want to hear about
-  behaviour that differs from JVM Clojure, just through Discussions while PRs
-  are closed.
+  There are no security fixes either — SECURITY.md is explicit about that.
 
-  For security issues, see SECURITY.md (do not post exploit details publicly).
+  (This template is kept for forks, which get it the moment they enable PRs.
+  Replace this text with your own.)
 -->

.github/SECURITY.md

@@ -1,30 +1,49 @@
 # Security Policy
 
+> [!IMPORTANT]
+> **ClojureWasm is no longer maintained, and no version is supported. There
+> will be no security fixes, including for critical vulnerabilities.**
+>
+> Do not deploy `cljw` where it is exposed to untrusted input. If you already
+> have, treat the migration off it as the fix — waiting for a patch here is
+> waiting for something that will not come.
+>
+> The rest of this document is kept because the threat model and the scope
+> boundaries are still accurate, and are the right starting point for anyone
+> forking the project. **A fork takes on its own security policy**; this one no
+> longer speaks for it.
+
 ClojureWasm (`cljw`) is a Clojure runtime with a **WebAssembly FFI**: it can
 load and execute **untrusted `.wasm` bytecode** in the same process as the host
-(through the embedded zwasm engine), and — in embeddings like the public
-playground — it evaluates **untrusted Clojure source** in-process. Memory
-safety and sandbox integrity are therefore first-class concerns, and we take
-reports seriously.
+(through the embedded zwasm engine), and — in embeddings that accept
+user-submitted code, as the now-retired public playground did — it evaluates
+**untrusted Clojure source** in-process. Memory safety and sandbox integrity
+are therefore first-class concerns for anyone running it.
 
 ## Supported versions
 
-Security fixes land on the `main` branch and in the next release cut from it.
-Only the newest release line is supported — this is a small project and there
-is no backport branch.
+**None.** The project stopped at v1.10.1; there is no supported line, no
+backport branch, and nothing that will be cut from `main`.
 
-| Version                        | Supported |
-|--------------------------------|-----------|
-| `main`                         | ✅        |
-| newest `1.x` release           | ✅        |
-| any older release              | ❌        |
+| Version                 | Supported |
+|-------------------------|-----------|
+| `main`                  | ❌        |
+| v1.10.1 (final release) | ❌        |
+| any earlier release     | ❌        |
 
-If you are on Homebrew, `brew upgrade clojurewasm/tap/cljw` puts you on the
-supported line.
+Note that the embedded WebAssembly engine, **zwasm**, is a separate project and
+[continues under its own maintainership](https://github.com/zwasm/zwasm) — a
+vulnerability in the engine should go there, and is worth reporting because that
+project can still act on it. What is unmaintained is `cljw`'s own runtime and
+the specific zwasm version this project pinned.
 
 ## Reporting a vulnerability
 
-**Please do not open a public issue or Discussion for security problems.**
+Reports about `cljw` itself will not be acted on. If you find something anyway
+and want it recorded for the benefit of anyone forking the project, the channel
+below still exists — but expect no fix and no timeline.
+
+**Please do not open a public Discussion for security problems.**
 
 Report privately via GitHub's **[Private Vulnerability Reporting](https://github.com/clojurewasm/ClojureWasm/security/advisories/new)**
 (the "Report a vulnerability" button under the repository's *Security* tab).
@@ -41,12 +60,14 @@ Please include, where possible:
 - the observed impact (host memory corruption, Wasm sandbox escape, WASI
   capability bypass, denial of service, etc.).
 
-We aim to acknowledge a report within a few days. Because this is a small,
-resource-limited project, please allow reasonable time for a fix before any
-public disclosure.
+There is no acknowledgement window and no fix window; see the notice at the top.
+You are under no obligation to delay disclosure on this project's behalf.
 
 ## Scope
 
+The boundaries below describe what *would* have counted as a vulnerability in
+`cljw`. They are retained as a threat model for forks, not as an active offer.
+
 In scope: host memory corruption from a malformed or adversarial `.wasm`
 module, Wasm sandbox / WASI-capability escapes, JIT code-generation bugs with a
 security impact, and memory-safety faults in the Zig runtime reachable from

docs/clojure_vs_clojurewasm.md

@@ -169,10 +169,15 @@ Note that Java *arrays* are implemented (type-erased — see AD-019), as is
 
 A divergence listed in **Part 1** is *designed*: it derives from a project
 invariant and is pinned by a regression test, so it reads as a deliberate
-choice rather than a defect. A gap listed in **Part 2** is *scheduled*: it
-is on the roadmap (or, for the JVM-only corners, intentionally excluded).
-Anything not on this page that still differs from Clojure is a bug —
-please report it.
+choice rather than a defect. A gap listed in **Part 2** was *planned but never
+built* — it sat on the roadmap when the project stopped, or, for the JVM-only
+corners, was intentionally excluded. Anything not on this page that differs
+from Clojure is a bug that was never found.
+
+Since the project is no longer maintained, treat both parts as a map for a fork
+rather than as a list of things about to change. Part 1 marks behaviour not to
+"correct" without first understanding the invariant behind it; Part 2 marks
+what is genuinely missing, with what was intended.
 
 For the authoritative, machine-readable form of Part 1, see
 [`.dev/accepted_divergences.yaml`](../.dev/accepted_divergences.yaml); each