knowless 1.1.0 → 1.1.1

package/CHANGELOG.md

@@ -12,6 +12,12 @@ Versioning is [SemVer](https://semver.org/).
   auth+mail layer. ~1,150 LOC of bespoke auth/mail code removed,
   ~35 LOC of knowless wiring added (~33× reduction). Drove audit
   findings AF-7 → AF-17 across v0.1.5–v0.1.10.
+- **2026-05-02 — Three adopters in production.** plato (Mode B,
+  forum) and gitdone (Mode A, multi-party email workflows) joined
+  addypin (Mode A, location sharing). gitdone's pre-merge review
+  surfaced the "wrong-shape integration" failure mode (parallel
+  tokens table + manual session minting alongside knowless instead
+  of `auth.startLogin`). Patched docs in v1.1.1; no API change.
 
 ## [Unreleased]
 
@@ -24,6 +30,32 @@ v1.0.0 are:
 - Documentation corrections
 - Helper exports that pull existing mechanism back into the library
 
+## [1.1.1] — 2026-05-02
+
+Documentation-only release. Adds the wrong-shape-integration
+anti-pattern callout that gitdone's pre-merge review surfaced, and
+records plato + gitdone as the second and third production adopters.
+No code changes.
+
+### Documented
+
+- `README.md` — replaced "Sibling projects" with an "Adopters"
+  section explicitly listing addypin (Mode A), plato (Mode B), and
+  gitdone (Mode A) with a pointer that addypin and gitdone are the
+  Mode A worked references.
+- `GUIDE.md` § "Two adoption modes" — added an anti-pattern callout
+  at the top: if you're considering writing pending rows to a
+  custom tokens table or minting your own confirmation links, that's
+  Mode A and `auth.startLogin({ subjectOverride, bodyOverride })`
+  already does it. Includes a side-by-side wrong-shape vs Mode A
+  sketch. Surfaced by gitdone's pre-merge review where a parallel
+  activation system was built before the existing Mode A flow was
+  noticed.
+- `GUIDE.md` Mode A/B sub-headings — appended the API entrypoint
+  (`auth.startLogin` for Mode A, `auth.login` for Mode B) so the
+  use-case leads and `startLogin` doesn't read as "login button
+  click."
+
 ## [1.1.0] — 2026-05-02
 
 Mailer-contract clarification release. Pulls FR-6 sham-routing

package/GUIDE.md

@@ -286,7 +286,31 @@ both out of the box; pick per-action, not per-app — they coexist.
 The Mode A/B labels are used here and in the CHANGELOG so
 discussions across the docs stay unambiguous.
 
-**Mode B — "sign in, then do the thing" (register-first, the default).**
+> ⚠ **Stop before you build a parallel activation system.** If
+> you're considering writing pending rows to a custom tokens table,
+> minting your own confirmation links, or calling into the sessions
+> table directly to mark an account "activated by email" — that is
+> Mode A, and it's already in this library. Use
+> `auth.startLogin({ email, subjectOverride, bodyOverride })` and
+> promote your pending resource in the callback handler. The
+> wrong-shape integration is what every adopter has tried first; the
+> right shape is the worked example below.
+
+The wrong shape vs Mode A, side by side:
+
+```
+WRONG SHAPE                         MODE A (use auth.startLogin)
+─────────────────────────────       ─────────────────────────────
+your_tokens table                   (none — knowless owns the token)
+your custom email composer          subjectOverride + bodyOverride
+your /confirm/:token handler        auth.callback (already mounted)
+manual session insert               handled by callback
+your duplicate rate-limit code      knowless rate-limit applies
+                                    sham-work + timing equivalence
+                                    preserved automatically
+```
+
+**Mode B — "sign in, then do the thing" (register-first, the default, `auth.login`).**
 User must log in before performing the action. Wire `auth.login` /
 `auth.callback` as above; gate your action with
 `auth.handleFromRequest(req)`. Use when the action requires a session
@@ -301,7 +325,7 @@ app.post('/api/comments', (req, res) => {
 });
 ```
 
-**Mode A — "do the thing, confirm by email" (use-first, claim-later).**
+**Mode A — "do the thing, confirm by email" (use-first, claim-later, `auth.startLogin`).**
 User performs the action without logging in; you capture their email
 and trigger a magic link. Clicking it opens a session and your
 callback handler "promotes" the deferred resource. Use for "drop a

package/README.md

@@ -148,12 +148,21 @@ rate-limits) belong above the library — patterns in
 Full detail in [`knowless.context.md`](knowless.context.md) §
 "Threat model summary."
 
-## Sibling projects
+## Adopters
 
-- [`addypin`](https://github.com/hamr0/addypin) — location sharing,
-  first knowless adopter
-- [`gitdone`](https://github.com/hamr0/gitdone) — verified email
-  actions via DKIM/SPF inbound
+Production users of knowless, in adoption order:
+
+- [`addypin`](https://github.com/hamr0/addypin) — pin-drop location
+  sharing. First knowless adopter; Mode A (drop-pin-then-confirm).
+- [`plato`](https://github.com/hamr0/plato) — forum (Reddit-shaped,
+  one fingerprint per site). Mode B (sign-in-then-do).
+- [`gitdone`](https://github.com/hamr0/gitdone) — multi-party email
+  workflows verified via DKIM/SPF inbound. Mode A
+  (start-workflow-then-confirm).
+
+If you're picking knowless up: the addypin and gitdone callsites are
+both Mode A and good worked references for the use-first / claim-later
+shape.
 
 ## License
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "knowless",
-  "version": "1.1.0",
+  "version": "1.1.1",
   "description": "Small, opinionated, full-stack passwordless auth for Node.js services that don't need to email their users for anything but the sign-in link.",
   "type": "module",
   "main": "./src/index.js",