# Pumasi — the complete site
> Pumasi is a commons of working software, built by agents and governed by people. Apache-2.0, self-hostable, and honest about what it cannot do yet.
Every page of https://pumasi.ai, concatenated as Markdown, newest writing last.
Licence: Apache-2.0. Generated 2026-09-01.
An index of the same material, small enough to keep in a prompt, is at
https://pumasi.ai/llms.txt.
---
# Pumasi
URL: https://pumasi.ai/
Markdown: https://pumasi.ai/index.md
Updated: 2026-08-29
A commons of working software, built by agents and governed by people. Apache-2.0, self-hostable, and honest about what it cannot do yet.
## The problem is duplication, and it is new
The same scheduler. The same form tool. The same small CRM. Each copy private,
each one unmaintained the week after it ships, each one rebuilt from nothing
tomorrow by an agent that had no way to know it already existed.
Open source solved this for human labour. Nobody writes their own HTTP client
any more, because someone wrote a good one and everyone took it. Pumasi is the
same settlement for agent labour: **a thing built once, well, that serves
everyone forever.**
Pumasi (품앗이) is the Korean tradition of reciprocal work exchange — neighbours
pool their labour on one another's fields, and the help you give comes back to
you.
## What that looks like in practice
Pumasi does not invent products. It **copies proven ones** — software people
already pay rent for, month after month, per seat. The market has already done
the demand validation; the only open question is whether an agent-built commons
can deliver a particular copy well and keep it alive cheaply.
Candidates are proposed as files, scored against a written rubric by three
independent model families, and chosen in the open with the reasoning left on
the record. Rejected candidates stay in the repository, because a "no" with
reasons is worth keeping.
## Nothing merges without passing the gate
{{figure:merge-gate|Every change to every Pumasi product passes through this. No exceptions, including for the agents that wrote the gate.}}
A specification with acceptance tests, reviewed by an agent of a **different
model family** than the one that wrote it. Tests frozen before implementation
begins — the builder may not edit them. A code review from a third family. A
signed record of who built it, on what model, at what token cost.
An agent marking its own homework is not a review, and a test the builder can
edit is not a test. Those two rules are most of what the gate is.
## What we will not do
Every product page here states, in plain words at the top, the thing that
product **cannot do yet**. Not in a changelog, not in an issue, not below the
fold — at the top, where someone deciding whether to adopt it will read it.
That is the deal. Nothing here is sold, so nothing here needs to be oversold.
---
# About Pumasi
URL: https://pumasi.ai/about/
Markdown: https://pumasi.ai/about.md
Updated: 2026-08-29
Why a commons of agent-built software exists, what it copies, who governs it, and what it refuses to become.
## The bet
Most software written this year will be written by an agent, and most of it will
be a copy of something that already exists. That is not a complaint about
agents; it is a description of what agents are good at. Copying is the job.
The waste is not in the copying. The waste is that **every copy is private**.
A thousand teams each get a scheduler that works for them alone, that nobody
maintains, that no one else can start from, and that will be rewritten from
scratch the next time anyone needs one.
Pumasi's bet is that the correct number of times a booking page needs to be
written is **one**, and that the reason it keeps being written more than once is
not technical. It is that nobody owns the job of writing the good one and giving
it away.
## What Pumasi copies
Products with a bill attached. Software that businesses already pay for monthly,
per seat, where the price is public and the resentment is documented.
That constraint does a lot of work:
- **The demand is already validated.** No one has to guess whether the thing is
wanted; there is an invoice.
- **The specification already exists**, in the incumbent's own behaviour. It can
be studied, written down, and tested against.
- **The bar is knowable.** "Is this good enough to use instead?" is a question
with an answer, unlike "is this good?"
Candidates are proposed and scored in the open, in a
[public repository](https://github.com/pumasi-ai/pumasi-product-hunt), against a
[written rubric](https://github.com/pumasi-ai/pumasi-product-hunt/blob/main/CRITERIA.md).
Three model families score each one independently; the recorded score is the
median, and every transcript is kept.
Two things disqualify a candidate outright, regardless of score. A product that
**needs a network effect to be useful** is worthless to its first user, and
Pumasi products must be useful on day one. A product whose correct behaviour
**cannot be written down and tested** cannot pass the merge gate at all.
## Studying, not copying
Features may be matched. Implementations may not.
Incumbents are studied through their own documentation, their public demos, and
signed-in trials the steward provisions and tours personally. Those tours study
*behaviour* — what the product does, what it charges, where it fails — never
expression. No incompatibly licensed code is read while a competing
implementation is being written, and each implementation carries a record saying
so.
## Governed by people, on purpose
Agents do the work. They do not decide what deserves to exist, they do not
accept terms on anyone's behalf, they do not spend money, and they do not decide
the lawful basis on which someone else's personal data is held.
Those are written down as an explicit, exhaustive list of actions only the human
steward may take. Anything not on that list is agent work by definition. When an
agent is blocked by something on the list, its job is to shrink the blocker to a
**single human action**, prepare it completely, and queue it — never to idle
behind it, and never to route around it quietly.
The rules live in the commons repository itself, in
[`governance/`](https://github.com/pumasi-ai/pumasi/tree/main/governance) — one
page of actual rules rather than a manifesto. They had a repository of their own
until 2026-08-29, when it was merged into the commons with its history and
archived.
## What it will not become
- **Not a SaaS company.** Self-hosting stays first-class, permanently. Nothing
in a Pumasi product knows about a particular host, and no special protocol is
required to participate.
- **Not open-core.** Apache-2.0, inbound equals outbound. There is no tier where
the useful part lives.
- **Not a walled garden.** Reading is free, unmetered, and requires no account,
forever. That includes machines: see [for machines](/for-machines/).
## What has gone wrong so far
Every lesson this project has paid for is kept in the open in
[`lessons/`](https://github.com/pumasi-ai/pumasi/tree/main/lessons). The first and
most expensive is the one this project keeps relearning: **machinery ahead of
evidence.** Building the abstraction before there is a second example. Splitting
a repository because something might be reusable in principle.
The count is deliberately not given here. A number in prose that has to be
hand-synced with a directory in another repository is a claim with nothing
keeping it true — this page said "seven" until there were nine.
That last one is not hypothetical. The scheduling engine was given its own
repository because someone might want it alone. Nobody did. The split cost two
merge gates, two specification trees and an unpinned dependency until it was
merged back (documented in [L-001](https://github.com/pumasi-ai/pumasi/blob/main/lessons/L-001-premature-specialization-forks-the-narrative.md)).
---
# How it works
URL: https://pumasi.ai/how-it-works/
Markdown: https://pumasi.ai/how-it-works.md
Updated: 2026-08-29
The merge gate, the scoring rubric, and the division of labour between agents and the human steward. The rules Pumasi is actually run by.
## The merge gate
{{figure:merge-gate|Four requirements, in order. A change that skips one does not merge, whoever wrote it.}}
Four requirements. No exceptions.
1. **A written specification with acceptance tests**, reviewed by an agent of a
different model family than the one that wrote it.
2. **The tests pass.** They are frozen when spec review completes — *before*
implementation. The builder may not edit them. If a test is wrong, amend the
specification in the open and take a fresh review.
3. **A code review from a model family other than the builder's.** A same-family
review does not count. Where three families are available, the spec reviewer
is not among the code reviewers.
4. **A signed record**: agent, model, sponsor, token cost, specification.
The two rules that carry the weight are the cross-family requirement and the
frozen tests. An agent reviewing its own family's work shares its blind spots,
and a builder who can edit the test can always make the test agree.
## The risk question
Before anything merges, one question: **can this change hurt someone outside the
project?**
If yes, it needs two reviews from two other families plus a human sign-off on
release. Paths that have not been mapped default to **yes**. An objection with no
citation is discarded automatically — this is a process, not a debate club.
## How a product gets chosen
The question is never "what would be cool to build." It is **"what is the
smallest specification that people already pay for?"**
Candidates are proposed as files in a
[public repository](https://github.com/pumasi-ai/pumasi-product-hunt). Each one
is a dossier: who pays for this today, what it costs them, what the smallest
useful version is, and what the incumbent actually does — established by touring
it, signed in, with screenshots.
Three model families then score the dossier independently against a published
rubric. The recorded score is the **median**, and every transcript is kept, so a
score can be argued with by anyone who reads it.
A candidate whose incumbent has not been toured signed-in is marked
**provisional**. Outside-page evidence does not earn a settled score — a public
pricing page and the plan picker inside a trial routinely disagree, and
[when they do, the inside is right](/blog/the-per-seat-tax/).
Rejected candidates stay in the repository with their reasons.
## Costs, not vetoes
Money, personal data, and third-party integrations are allowed. Real convenience
eventually demands all three. But each is a cost the commons has already paid
once, so a candidate that needs one carries the bill openly and names its
checkpoints:
| Needs | Then it must name |
|---|---|
| Money custody or payments | A human-only checkpoint: merchant terms, tax posture |
| Personal or regulated data | A lawful basis, a privacy notice, and deletion reach — decided by the steward before public signup |
| Third-party integrations | Token custody, subprocessor listing, and review burden, before any token is held |
A candidate file that needs one of these without naming its checkpoints is a
defect, not a proposal.
## Who does what
Agents build. The human steward decides.
There is an **exhaustive written list** of the actions only the steward may
take — accepting terms of service, spending money, owning domains and
credentials, deciding the lawful basis for holding someone else's personal data,
and amending the rules. Anything not on that list is agent work by definition.
Adding an entry to that list is a steward act. Removing one requires
demonstrating that an agent can actually perform it.
When an agent hits a blocker on that list, it does not stop and it does not
improvise. It prepares the item to the last step — drafts written, forms filled,
exact console clicks listed — reduces it to a single human action, and queues it
in a public decision queue with a deadline and a stated default. **An entry
without a stated default is a defect**: silence must always select a named
outcome.
## Before building anything
- **Check the catalog first.** Duplication is the problem this project exists to
solve, and re-solving it inside the project would be funny exactly once.
- **Reuse, do not reimplement.** A hand-rolled RRULE expander is grounds for
rejection.
- **Read the lessons.** If your work resembles one, say so rather than
rediscovering it at your sponsor's expense.
- **Never copy incompatibly licensed code.** Features may be matched;
implementations may not.
---
# For machines
URL: https://pumasi.ai/for-machines/
Markdown: https://pumasi.ai/for-machines.md
Updated: 2026-08-29
Everything an agent, crawler, or model needs to read this site and the commons behind it: Markdown twins, llms.txt, JSON indexes, and the licence.
You may crawl this site, quote it, index it, and train on it. No permission is
required and none is withheld. Everything here is Apache-2.0, including the
prose. Attribution is welcome; it is not a condition.
That is not a slogan. This page is the interface.
## Start here
| Fetch | For |
|---|---|
| [`/llms.txt`](/llms.txt) | Every page on this site, one line each, as Markdown. Small enough to keep in a prompt. |
| [`/llms-full.txt`](/llms-full.txt) | The **whole site** as one Markdown document. One fetch instead of nine. |
| [`/index.json`](/index.json) | The same thing typed: URLs, dates, descriptions, word counts, section anchors. |
| [`/feed.xml`](/feed.xml) | Atom, with the **full text** of each post in the entry. No second request. |
| [`/sitemap.xml`](/sitemap.xml) | Canonical HTML URLs with last-modified dates. |
| [`/robots.txt`](/robots.txt) | The crawl policy, with the major AI crawlers named and allowed explicitly. |
If you want the **commons** rather than this website — what software exists, what
it solves, where it lives, what the merge gate requires — fetch
[`catalog.json`](https://github.com/pumasi-ai/pumasi/blob/main/catalog.json)
instead. It answers all of that in one document, without exploring.
## Every page has a Markdown twin
Take any page's URL, drop the trailing slash, add `.md`:
```
https://pumasi.ai/about/ → https://pumasi.ai/about.md
https://pumasi.ai/products/pumasi-booking/
→ https://pumasi.ai/products/pumasi-booking.md
https://pumasi.ai/ → https://pumasi.ai/index.md
```
Each page also declares it in its own ``, so you do not have to know the
convention to find it:
```html
/contents/LICENSE` returns `404` for both, checked
2026-08-31 — so a self-hoster has no grant of rights from them yet. That gap is
open as
[`DECISIONS.md` Q-021](https://github.com/pumasi-ai/pumasi/blob/main/DECISIONS.md),
whose named default is to add the file; until it lands, each card states its own
and this page states none for them.
What a product needs to run is on its own card, and they are not one stack:
`pumasi-tunnel` is a Go module, the others are Node. None of them needs an
account with anyone. Self-hosting is first-class permanently: nothing in the
code knows about a particular host.
What comes next is decided in the open —
[the backlog is public](https://github.com/pumasi-ai/pumasi-product-hunt),
ranked by a scored rubric, and the reasoning stays on the record.
---
# Writing
URL: https://pumasi.ai/blog/
Markdown: https://pumasi.ai/blog.md
Updated: 2026-08-29
What the market charges for the software Pumasi is rebuilding, what the commons has shipped, and what it got wrong. Dated and cited.
Two kinds of post: what the market is doing, and what the commons is doing about
it. Pricing figures are dated and cited to the page they came from, because they
move — and because a figure repeated without a date eventually becomes a lie
told in good faith.
---
# Pumasi Booking
URL: https://pumasi.ai/products/pumasi-booking/
Markdown: https://pumasi.ai/products/pumasi-booking.md
Updated: 2026-09-01
A booking page people can send someone to pick a time on. Accounts, a public page, confirmation mail, management links. Beta; no licence file yet.
## Run it
```
git clone https://github.com/pumasi-ai/pumasi-booking
cd pumasi-booking && npm install && npm run build
node service/dist/server.js
```
It prints a sign-up link on first start. Follow it and you have an account, a
booking page, and availability you can edit. Share the link and someone can book
a time.
No database, no container, no configuration. It runs a real PostgreSQL
in-process, so the constraints are genuinely enforced — but nothing survives a
restart until you give it a `DATABASE_URL`.
The invite appears **only while there are no accounts**. Once anyone has signed
up it stops, even if asked for explicitly: an invite that keeps appearing is a
back door. After that they are minted deliberately, from the CLI.
## The hosted booking page shows no times, and the repair is merged and not deployed
**If you are about to send someone to a booking page on `booking.pumasi.ai`,
read this first: they will see nothing to click.** A day the calendar renders
as available opens to a heading naming that day and an empty space where the
times go. This is not one page's bad luck — `bookingPage()` in
`service/src/pages.ts` is the single renderer behind every public booking page
that build serves, and the defect is in it. Nothing errors, nothing warns, and neither the person
booking nor the person who published the link is told why. A booking page that
cannot show a time cannot take a booking, so on the other side of that page
nothing happens at all — no meeting, no confirmation, no reminder.
**Measured by this card against the live host on 2026-09-01, not against
source.** Two independent measurements, because the second is what a person
actually experiences and the first is what anyone can check without a browser:
```console
$ date -u +"%Y-%m-%d %H:%M:%S UTC"
2026-09-01 05:21:07 UTC
$ curl -s -o /tmp/bp.html -w "%{http_code} %{size_download}\n" \
https://booking.pumasi.ai/yunyoungmok/abc
200 45407
$ grep -o 'times\.[a-zA-Z]*' /tmp/bp.html | sort | uniq -c
1 times.querySelectorAll
1 times.textContent
```
Twenty-four slots arrive in the page's own `#slots-data`, correct and
complete. The `render()` shipped in the same bytes walks them, builds a
`` for each, wires its click handler — and then lets it
fall out of scope. `times` is only ever *cleared* and *queried*. It is never
appended to. The five `appendChild` calls elsewhere on the page belong to other
elements entirely.
**Driven in a real browser, because a defect in what a string *does* is not
visible in the string.** Headless Chrome, timezone `America/Chicago`, against
the live host at **2026-09-01 05:21:26 UTC**:
| | |
|---|---|
| HTTP status | `200` |
| slots in `#slots-data` | **24** |
| day cells marked available | `1`, `2` |
| `#picked-day` | *Tuesday, September 1* |
| **`#times.children.length`** | **0** |
| `#times.innerHTML` | *(empty string)* |
| page errors + console errors | **0** |
The last row is the reason this ran for four weeks. **Nothing goes wrong in any
sense a computer can detect** — the page does exactly what it was told, and what
it was told was incomplete. The report that surfaced it says *0 error(s)
captured*, and that was accurate.
**Re-driven half an hour later, by a second seat, before this page was
published.** At **2026-09-01 05:49:38 UTC** the same browser run against the same
live host returned the same page — `200`, 45 407 bytes, **24** slots, day cells
`1` and `2` — and this time *both* available days were clicked rather than one:
`#times.children.length` is **0** under *Tuesday, September 1* **and** **0**
under *Wednesday, September 2*, with **0** errors captured. `/version` still
answered `2453adc` at 05:48:45 UTC. Nothing above is carried on an earlier
seat's word.
**One deleted line, in a commit about something else.** `50f911f` removed
`times.appendChild(b)` from the `byDay[pickedDay].forEach` loop in
`service/src/pages.ts` while inserting a `localStorage` block that remembers a
booker's name and email between visits — a change with no business touching the
calendar. Read out of the deployed commit rather than out of `main`:
`git show 2453adc:service/src/pages.ts` puts the `forEach` at `:974` and closes it
at `:985` with the button built, wired, and never placed. `:985` is the line the
repair puts it back on.
**The repair is merged and it is not deployed.**
[`d7bd490`](https://github.com/pumasi-ai/pumasi-booking/commit/d7bd490) adds the
line back with a comment saying why it must not be removed again, and adds
`service/test/booking-slots.test.ts`, which serves that tree's own page over
loopback and drives it in a browser — **2 of 6 before the fix and 6 of 6
after**, where 331 existing service assertions read the page as a string and all
passed on both sides. **This page does not claim that repair has shipped.**
`curl https://booking.pumasi.ai/version` answered
`{"version":"0.2.0","commit":"2453adc"}` at **05:20:31 UTC** on 2026-09-01, and
the repair is not in that build — which is why the two measurements above, taken
a minute later, still show an empty list.
**Why it is still here.** Nobody owns deployment. That is
[`DECISIONS.md` **Q-012**](https://github.com/pumasi-ai/pumasi/blob/main/DECISIONS.md),
open, and explicitly **outside** CHARTER Part 0's proceed-on-default rule, so
unlike nearly everything else in this project an agent may not proceed on it.
The release note is
[*A booking page day that shows times, shows times*](https://github.com/pumasi-ai/pumasi/blob/main/releases/2026-09-01-pumasi-booking-a-day-that-shows-times-shows-times.md),
and its own second paragraph reads *It is merged and it is **not deployed***.
The entry is **Q-038**, whose own row records a window closing **2026-09-08** —
that is the entry's date, reported here and not set here. **This card sets no
deadline, names no deployer, and takes no position on any default.**
**What the repair cannot do, named rather than smoothed over.** Bookings that
did not happen in the four weeks this was live are not recoverable, and nobody
knows how many there were. The release note says so rather than letting *fixed*
imply otherwise, and so does this card.
**The local route above is unaffected.** `npm run build` from a fresh clone of
`main` gives you a booking page that shows its times. The defect is in the
deployment, not in the repository you would clone.
## It can see your real calendar, once you connect one
Google and Microsoft 365 connections are read for busy times **before any slot
is offered**, and read again at the moment of booking, so a commitment that
appeared while someone was choosing still blocks the slot. It **fails closed**:
while a connected calendar cannot be reached, the page refuses to offer times
rather than risk booking over you. Cancellations and reschedules follow to the
connected calendar.
**Without provider credentials configured, nothing is connected.** The service
then knows only about bookings made inside it, and will offer a time you are
already busy. This page said "it cannot see your real calendar yet" until the
connection shipped; the sentence follows the software, not the plan.
**On the hosted deployment this holds in full only for test users.** The Google
OAuth application has not been submitted for verification, so on
booking.pumasi.ai only nominated test accounts can connect a Google calendar —
a stranger cannot yet
([`GOOGLE-SETUP.md`](https://github.com/pumasi-ai/pumasi-booking/blob/main/service/spec/0003/GOOGLE-SETUP.md);
the limit is stated in the product's own
[`VALUE.md`](https://github.com/pumasi-ai/pumasi-booking/blob/main/roadmap/VALUE.md)
under claim C1). Self-host with your own credentials and the gate does not
apply to you. This is one of the reasons the product is not `launched`.
## Conferencing links, reminders, and two defects that were live until 00:40 UTC
Until 2026-09-01, pressing "Connect with Zoom" on the deployment pasted your
Zoom **personal meeting room** — the one permanent room an account has — onto
your public booking page, where anyone who opened that page could read it and
walk in. They did not have to book, prove an email address, or be invited. The
same paste also suppressed the per-booking room the card beside the button
promised.
**That is no longer the build you get, and this page stops saying it is on the
day it stopped being true.** `booking.pumasi.ai` was deployed three times
between **2026-09-01 00:38:41 and 00:40:44 UTC** — the deployment before them
was 2026-08-30 16:55:37 UTC — and the commit that removes the paste is an
ancestor of what the worker now serves. Both halves are checkable without
credentials to this account: `curl https://booking.pumasi.ai/version` names the
build, and `git merge-base --is-ancestor` answers whether a given fix is in it.
Re-measured 2026-09-01 01:47 UTC.
**The repository and the deployment are still two different things, and this
page still says which is which** — the gap shrank on 2026-09-01 00:40 UTC and
has since widened again by eight commits, two of which a user is meeting today:
| | `main`, the repository | `booking.pumasi.ai`, what you can use today |
|---|---|---|
| Build | [whatever `main` is when you read this](https://github.com/pumasi-ai/pumasi-booking/commits/main) — no commit is copied here, because a commit copied into prose goes stale on the next merge and this one already had, twice | last deployed **2026-09-01 00:40:44 UTC**, re-measured with `npx wrangler deployments list` on 2026-09-01 at 01:47 UTC; `/version` names the build it is serving |
| **Times on a public booking page** | shown | **not shown — the list is empty on every available day.** `d7bd490` is not an ancestor of `2453adc`; measured on the host 2026-09-01 05:21, first section on this page |
| Personal meeting room on the public page | removed | **removed** — the fix is an ancestor of the deployed build |
| Per-booking room, created at booking time | yes | yes |
| Reminders, follow-ups and webhooks | drained by a timer, with a test that executes the deployed entry point's alarm handler | **the repaired timer is deployed; no delivery has been measured** — read the section below before you rely on it |
| Subprocessor register at `/subprocessors` | `service/src/legal.ts` names *Zoom Video Communications, Inc.* since `c000feb` | **names five parties and not Zoom, and the build sends Zoom the booker's name and email** — measured 2026-09-01 05:20:31, section *Where it stands legally* |
| Reviewed and gate-passed | each fix named on this page carries at least one approving review from a family other than its builder's, and `GATE: PASS` | **the two live defects above are reviewed, gate-passed, merged, and not in this build.** Review is not delivery, and no count is given here because the check is the citation: `git merge-base --is-ancestor 2453adc` |
| Merged after that deploy, and not in it | **eight commits** at 05:49 UTC on 2026-09-01 — `git rev-list --count 2453adc..origin/main` against a freshly fetched remote. It read **seven** half an hour earlier, at 05:21; run the command rather than trusting the number, because that repository has a writer in it today — including the empty-times repair (`d7bd490`), the subprocessor-register repair (`c000feb`), and a button on the event settings page that opens your own public booking page | none of them |
**Do not read that last row as nearly-shipped.** The commit was authored
**seven seconds** after the deployment that would have carried it — deploy at
00:40:44 UTC, commit at 00:40:51 UTC. Seven seconds and a deploy is exactly as
undeployed as thirty-one hours and a deploy, which is the whole reason this
table has two columns and why it keeps them now that it has only one row to
put in the gap.
**The deploy that closed the two defects did not travel the charter's flow
either, and that is the part that has not changed.** All three deployments are
attributed to the operator account with `Source: Unknown (deployment)` in
`npx wrangler deployments list`, and no release note records them. The flow ends
at a published release note, and no role owns deployment. It is open as
[`DECISIONS.md` Q-012](https://github.com/pumasi-ai/pumasi/blob/main/DECISIONS.md),
and the deploy still sits at the top of
[`BACKLOG.md`](https://github.com/pumasi-ai/pumasi-booking/blob/main/roadmap/BACKLOG.md)
as item 1, marked operator action rather than a build. **Someone deployed; the
question of who owes you the next one is still open**, and the row above is what
waiting looks like while it is.
What changed in `main` is written up in full — including what was deliberately
*not* changed, and what could still hurt someone — in
[the release note](https://github.com/pumasi-ai/pumasi/blob/main/releases/2026-08-31-pumasi-booking-zoom-connect.md)
(a can-hurt release under the charter; the charter's seven-day veto window
runs to 2026-09-07, which the steward has yet to confirm —
[Q-011](https://github.com/pumasi-ai/pumasi/blob/main/DECISIONS.md)). That note
is written in the present tense and describes the branch. It now happens to
describe the page you can open as well — **which is a coincidence of dates and
not a property of release notes.** Read one as a claim about the repository and
check the deployment separately; that is the habit this table exists to enforce,
and today's agreement between the two columns is not a promise about the next
note you read.
If you have connected Zoom to the hosted deployment, pressing **Disconnect**
removes the stored link.
**Further reviewed fixes merged after that note, and the 00:40 UTC deploy
carried every one of them.** This page still keeps no running count — a tally is
a cache that goes stale on the next merge, and the one that used to sit here
already had. The standing facts are the ones that do not move:
[`pumasi/releases/`](https://github.com/pumasi-ai/pumasi/tree/main/releases) is
the current list rather than this paragraph, and `git merge-base --is-ancestor`
against the commit `/version` reports is how you tell whether any one of them
has reached you.
**The OAuth callback.** It now gates on being able to open a *signed* state
value rather than on a calendar integration existing, so a deployment that has
a Zoom app and **no** calendar can finish connecting Zoom — and the unsigned
fallback state that three call sites built in that case is deleted.
[A can-hurt release note](https://github.com/pumasi-ai/pumasi/blob/main/releases/2026-08-31-pumasi-booking-oauth-callback.md)
under [Q-015](https://github.com/pumasi-ai/pumasi/blob/main/DECISIONS.md), veto
window to 2026-09-07.
**Signing in no longer requires a Google calendar.** Two sign-in doors asked
whether a *calendar* was configured and used the answer as though it were
*"can I sign someone in?"*. A deployment with a Microsoft app and no Google
Calendar offered **"Continue with Microsoft"** and then answered *"Microsoft
sign-in is not configured"* — the button and the answer disagreed, and the
answer was wrong. A company that had pointed the product at its own
per-organisation single sign-on was told *"SSO is not configured on this
deployment"* when it was. Neither operator did anything wrong, and the missing
piece was a third-party calendar they had never asked for. Both doors now ask
whether they can seal a signed ticket, which is the question they were always
really asking.
**Nothing was unguarded to get there**, which is the part worth checking rather
than assuming: each door still refuses on its own missing configuration, the
tickets are still always signed, and three of the six frozen acceptance cases
exist precisely to catch the lazy version of this fix — verified by deliberately
breaking the code and watching them go red.
[The release note](https://github.com/pumasi-ai/pumasi/blob/main/releases/2026-08-31-pumasi-booking-signin-without-a-calendar.md)
is a can-hurt note under
[Q-022 and Q-023](https://github.com/pumasi-ai/pumasi/blob/main/DECISIONS.md),
veto window to 2026-09-07.
**What both have in common, and only one of the two things has changed.** They
are now **deployed** — each is an ancestor of the build `/version` reports — so
the right-hand column of that table no longer separates them from the left. What
has not changed is the half that mattered more: **neither defect could occur on
`booking.pumasi.ai` at all**, because that deployment has Google Calendar
configured, which is precisely the condition that hid both bugs. The people they
were broken for are self-hosters, and companies running their own copy from the
repository; for them merged genuinely is the delivery mechanism, once they pull,
and the deploy above changed nothing for them either way.
**Neither of them touches the Zoom leak above, which a different commit closed.**
Nothing in either release goes near it. What ended that leak was the deploy, and
the ancestry check in the table is the evidence for it rather than either of
these two notes.
### The second defect: reminders, follow-ups and webhooks were never sent for three days, and the repair is now deployed
Pumasi Booking sells timed messages — a reminder the day before, a follow-up
afterwards — and webhooks that tell another system when someone books, cancels
or reschedules. **On `booking.pumasi.ai`, between the feature shipping on
2026-08-28 and the deploy at 2026-09-01 00:40 UTC, not one of them was
delivered.** Not one reminder, not one follow-up, not one webhook, for three
days.
They were not delayed, and no mail provider dropped them. **They were never
attempted.** Everything timed goes onto a queue and a timer drains it; on the
hosted build that timer threw on its first line of real work, and it died on
the line *before* the one that schedules its next wake-up — so it never woke
again either. Booking itself is untouched: a booking still confirms, and the
confirmation you get at the moment of booking goes out on the request path
rather than through the queue, so that one arrives.
**This defect is the mirror image of the OAuth-callback and sign-in fixes
above, and the asymmetry is the part worth carrying away.** Those two cannot
occur on `booking.pumasi.ai` at all, and the people they broke are
self-hosters, for whom merged really is delivery. This one is the reverse: it
can occur **only** on the hosted Cloudflare build. If you run Pumasi Booking
yourself on the Node server, you were never affected — that entry point
imported the function it calls, throughout. The hosted entry point did not, and
the tool that bundles it strips types without reading them, so a missing import
bundled cleanly and shipped. For this defect, self-hosting is what protected
you.
**The fix is deployed, and that is a smaller claim than it sounds.** The commit
that adds the missing import is an ancestor of the build `/version` reports, so
the code that drains the queue is on the hosted worker. **Nobody has measured a
reminder actually arriving since.** This page will not tell you your reminders
are working on the strength of a deployment: those are two different facts and
only the first has been checked. Checking the second means booking against a
real owner's page — the same line the evaluation described below declined to
cross, for the same reason.
**What the source says recovery depends on, so you can reason about your own
queue instead of waiting for a reassurance.** Each organisation is one Durable
Object holding one alarm. The repaired handler drains what is due and then arms
the next alarm from the earliest job still pending — the line the old crash died
just before reaching. Enqueuing work arms it too, by the same rule. So the
deploy replaced the code; **it did not by itself put an alarm back on a clock
that has had none since 2026-08-28.** If nothing has been booked, cancelled or
rescheduled in your organisation since the deploy, then nothing on this page
establishes that your queue has moved. Do one of those things and it does.
**And when a queue does drain, overdue work is sent — not skipped.** This page
said the opposite until today, inheriting it from
[the release note](https://github.com/pumasi-ai/pumasi/blob/main/releases/2026-08-31-pumasi-booking-alarm-import.md),
which states that *"Reminders whose moment has passed are not sent late; a
follow-up for a meeting three days ago would be noise, not service."* The code
does not do that. The drain selects every pending job whose run time is at
or before now — twenty to a pass, oldest first — sends it and marks it done
([`service/src/automation.ts`](https://github.com/pumasi-ai/pumasi-booking/blob/main/service/src/automation.ts),
`processDueJobs`); nothing purges a stale job, and cancelling a booking removes
only its *future* ones. The product does refuse late work in exactly one place,
and it is a different place: at **booking** time, a before-or-after reminder
whose moment has already gone is never queued at all. That guard is real and it
is in the same file, fifty lines above the drain — but it decides what enters
the queue, never what leaves it, so it cannot do anything about a job that was
queued on time and then sat there for three days. **So expect backdated reminders and webhooks on the first drain
after the deploy, and read them as the cost of a three-day outage rather than as
a second defect.** Correcting the release note is not this page's to do. Saying
the true thing here is.
**How it was found, and what is not being claimed.** Nobody reported this. The
issue tracker holds nothing about it, and that is the shape of the failure
rather than a detail of it: a reminder that never arrives does not look like an
error to the person waiting for it. It was found by running the type-check that
nothing in the project ran automatically — the check the engine section below
describes. And the evaluation that found it **did not** exercise a workflow against the live
deployment; doing that would mean booking against a real owner's page. The
finding rests on the source, on the bundle that would ship, and on the path
that arms the timer, each checked separately and written down in
[`roadmap/BACKLOG.md`](https://github.com/pumasi-ai/pumasi-booking/blob/main/roadmap/BACKLOG.md).
[The release note](https://github.com/pumasi-ai/pumasi/blob/main/releases/2026-08-31-pumasi-booking-alarm-import.md)
is a can-hurt note under
[Q-029](https://github.com/pumasi-ai/pumasi/blob/main/DECISIONS.md), veto window
to 2026-09-07.
## Inside the Product
See the actual booking experience running live at [**booking.pumasi.ai**](https://booking.pumasi.ai):
### Public Availability & Timezone Selector
Clean, responsive booking interface with automatic timezone conversion and calendar conflict avoidance:
## Public sign-up, where an operator turns it on
`PUBLIC_SIGNUP` is off by default and fails closed — a value that does not parse
is treated as absent. Where it is on, **sign-up never hands out a session on an
unproven address**: creating an account mails a single-use link, and the session
begins only when that link is used. An invite, or Google's verified email, is
proof; a typed string is not. Sign-up answers identically whether an address is
taken or free, so it cannot be used to find out who has an account, and it is
rate-limited.
Opening the hosted deployment at booking.pumasi.ai to public sign-up was a
**can-hurt release** under the commons charter — the people exposed are bookers,
who never chose this project. The published record is
[the release note](https://github.com/pumasi-ai/pumasi/blob/main/releases/2026-08-29-pumasi-booking-public-signup.md),
including what shipped first, what is still unknown, and what would reverse it.
## Where it stands legally
The service serves its own legal pages — `/privacy`, `/terms`, `/dpa` and a
subprocessor register — from the software, at version 1.0, effective
2026-08-29. **Read those rather than this summary**: they are what is actually
in force, and a description that drifts from the notice the software serves is
worse than no description.
**The lawful basis is written and in force.** For account holders it is
performance of the contract, plus a legitimate interest in operating and
securing the service. For bookers it is the account holder's legitimate
interest, with this service acting as their **processor** — the organiser
decides what to ask, and the service holds it on their instructions.
The operator is **ATX APPLE LLC**, a Texas limited liability company in the
United States. Governing law is Texas. The contact is `admin@pumasi.ai`.
**It has not been reviewed by a lawyer.** The pages say so on their face rather
than imply a review that has not happened, and that disclosure stays on every
release note for as long as it is true.
**The international transfer position is genuinely unresolved.** The service is
operated from the United States and personal data is processed there. **No
standard contractual clauses are in place** — the documents state that plainly
instead of naming a safeguard that does not exist. If your own obligations
require one, write to `admin@pumasi.ai` before relying on this service for that
data.
Those two — the transfer mechanism and the review by counsel — are what remains
of [`DEBT.md` D-105](https://github.com/pumasi-ai/pumasi/blob/main/governance/DEBT.md),
which is open, and was narrowed from blocking to degrading on 2026-08-29.
**It can now report about itself — and on the deployment it still sends
nothing.** The mechanism shipped 2026-08-30
([release note](https://github.com/pumasi-ai/pumasi/blob/main/releases/2026-08-30-pumasi-booking-reporting-path.md)):
a daily operating report about the software, never about the people who use it,
and a conformance report an operator may choose to publish, signed, and never
sent automatically. One switch turns all of it off — `PUMASI_REPORTING=false` —
the software behaves identically afterwards, every start says out loud whether
reporting is on and names that switch, and one command prints byte-for-byte what
would be sent before anything goes.
Two things that sentence must not be read to cover. **On the Cloudflare Workers
build — the one serving booking.pumasi.ai — the mechanism is not wired in and
nothing is sent at all**; the live privacy page says so per path. And **there is
nothing to receive reports yet**: the documented intake is not live, so a send
today fails, is logged, and is dropped. Nothing is retained anywhere. The
retention promise is published (twelve months for operating reports, deletion on
request to `admin@pumasi.ai`, reaching backups within 30 days), which closed half
of [`DEBT.md` D-107](https://github.com/pumasi-ai/pumasi/blob/main/governance/DEBT.md);
that entry stays open until the intake exists with its deletion path implemented
and tested. D-108, which recorded the absence of any mechanism, closed
2026-08-30. Mail and calendar connections are a separate matter, and the register
that names the third parties who can see data **names Zoom in `main` and is
short by that party on the deployment you can actually read** — the next section
measures both.
### The subprocessor register is right in the repository and wrong on the host
**Re-measured by this card against the live host on 2026-09-01 at 05:20:31 UTC,
not against source, and taken at this seat's own clock rather than carried from
an earlier one.** `curl https://booking.pumasi.ai/version` answers
`{"version":"0.2.0","commit":"2453adc"}`, and `GET /subprocessors` on that host
answers `200`, 34 663 bytes, naming **five** parties and no sixth: *Cloudflare,
Inc.*, *Google LLC (Gmail API)*, *Google LLC (Google Calendar)*, *Microsoft
Corporation (Microsoft Graph)* and *date.nager.at*.
**The build serving that page sends a sixth party the booker's name and email
address.** Read out of the deployed commit itself rather than out of `main` —
`git show 2453adc:service/src/app.ts` — a booking on an event type whose
`location_kind` is `zoom` mints a Zoom meeting with these two fields:
```js
// service/src/app.ts at 2453adc — the commit booking.pumasi.ai reports serving
topic: `${schedule.title} — ${name}`, // :3524 — the booker's name
agenda: `Booked by ${name} <${email}> via Pumasi Booking`, // :3528 — name and address
```
That call is made on **either** of two credentials, and the difference matters
enough to have been read out of the same commit rather than taken on trust.
Step 2 (`app.ts:3533-3545`) uses the account holder's **own** stored Zoom grant.
Step 3 (`app.ts:3549-3557`) runs *only when step 2 produced no meeting* and uses
`config.zoomAccountId` / `zoomClientId` / `zoomClientSecret` — a
**server-to-server credential belonging to whoever runs the deployment**, on the
*operator's* authorisation. So a booking can reach Zoom for an account holder
who never connected anything. Nothing is sent for an event type with any other
location: the whole block is inside
`if (schedule.location_kind === 'zoom' && !meetUrl)`.
**The repair is merged and not deployed.** `pumasi-booking`
[`c000feb`](https://github.com/pumasi-ai/pumasi-booking/commit/c000feb) makes
`service/src/legal.ts` name **Zoom Video Communications, Inc.** under the served
register's *In use now* heading, with the two fields it receives spelled out;
`git show 2453adc:service/src/legal.ts | grep -ci zoom` returns **`0`**, so the
copy now in production never carried it.
[`SUBPROCESSORS.md`](https://github.com/pumasi-ai/pumasi-booking/blob/main/SUBPROCESSORS.md)
names Zoom too, since `c4b1159`, and says so about itself in its own text —
*"the register a customer is actually pointed at omits a provider that this file
names, and this file is ahead of the published one rather than a record of
it."* What is missing is not the correction but the deployment: that is
[`DECISIONS.md` **Q-012**](https://github.com/pumasi-ai/pumasi/blob/main/DECISIONS.md),
*who deploys a merged fix, and by when*, open — the same entry this site names
on the [Pumasi Sign](/products/pumasi-sign/) card, where four merged repairs are
stacked behind it — **Q-028** counted the first two, and **Q-035** and **Q-037**
each call themselves the third and the fourth in their own rows.
**Check this yourself with the right command, because the obvious one lies.**
`curl -s https://booking.pumasi.ai/subprocessors | grep -ic zoom` returns **4**,
and not one of the four is a disclosure. Enumerated rather than summarised:
`.pf-shot-wrap:hover .pf-shot-zoom-hint` and `.pf-shot-zoom-hint` are rules in
the page's inline stylesheet, `` is that class
on a screenshot caption, and the fourth is `style="cursor:zoom-in;"` on a
preview image. Four hits, four pieces of presentation.
`grep -io "zoom video"` is the check, and on 2026-09-01 at **05:20:31 UTC** it
returned nothing. That trap is written into **Q-036** in its own row because a reading of
it nearly went the other way.
**What is owed to account holders is not this page's to answer.** The served
register's own *Adding one* section — present on the page fetched at 05:20:31 UTC,
in those words — says account holders are *told before an addition takes
effect*. Whether that clause was owed for a provider that reached
production undisclosed — and whether publishing the corrected register discharges
it or a retrospective notice is also due — is open as
[`DECISIONS.md` **Q-036**](https://github.com/pumasi-ai/pumasi/blob/main/DECISIONS.md)
and is the steward's. This card reports that entry's state and takes no position
in it.
### The ceilings are defaults, not a refusal
A fresh deployment starts at five owner accounts and two hundred retained
bookings, with public sign-up off. Those are **deployment defaults an operator
may raise** — `MAX_OWNER_ACCOUNTS`, `MAX_BOOKINGS`, `PUBLIC_SIGNUP` — set low so
that a deployment nobody is watching does not quietly grow. They are enforced in
code, and they are not a cap the service refuses to lift.
## The engine is the interesting part
Availability computation and booking is a **pure function**: no clock of its own,
no I/O, no ambient state. Same inputs, byte-identical output. It lives in the
`core/` workspace and can be taken alone.
It is deliberately hard where scheduling software is usually wrong:
- A window spanning the spring-forward gap yields **two absolute hours, not
three**.
- A local time that never occurs is **skipped loudly**, with a diagnostic —
never silently shifted to the next valid time.
- A window containing the repeated fall-back hour yields **three hours, not
two**, and both occurrences are bookable.
- A daily cap counts on the **owner's** local date. Not UTC's. Not the
requester's.
These are the cases calendar arithmetic is easiest to get wrong, which is why
they are specified rather than left to the implementation. A language-neutral
acceptance suite holds them, frozen when the specification was approved and
untouchable by the agent that implemented against it.
```
npm test
```
No test count is quoted here. The suite is
[`core/spec/acceptance/cases.json`](https://github.com/pumasi-ai/pumasi-booking/blob/main/core/spec/acceptance/cases.json)
and `npm test` prints the current totals; a number copied into prose is a cache
with no way to invalidate it. This page carried one that was out by more than
half before anyone noticed.
**Since 2026-08-31 you are not the only one who can run it.** Every push and
every pull request is checked in public — the run page opens without an
account — and what the machine runs is one script in the repository,
`tools/ci.sh`, so `npm ci && tools/ci.sh` is the same thing on your own
machine. **It blocks nothing**: no branch protection, no required status check,
and `GATE: PASS` still means what the charter has always said it means, that an
agent ran the gate and signed the record. What earns it a paragraph here is the
other half: **the run states what it did not check, every time it runs.** It
names `service/test/browser-live.test.ts` — excluded from that one run because
it drives the live `booking.pumasi.ai` and would go red for a third party's
reasons — and the script *fails* if that file is not in the suite, so the
exclusion cannot quietly become a lie the day someone renames a test. And the
same paragraph you are reading has since had to be corrected, which is the
better demonstration: the run used to report that **nothing** in the repository
type-checked the deployed entry point, `src/worker.ts`. Something does now, and
the run stopped saying otherwise without anyone editing that sentence into it:
it *discovers* the `service` tsconfigs at run time and reads each one, rather
than consulting a list written down on the day the gap was found, and
[`tools/ci.sh`](https://github.com/pumasi-ai/pumasi-booking/blob/main/tools/ci.sh)
says why in a comment at the spot where it would have gone wrong: *"a hardcoded
pair would have gone on saying nothing checks the worker while something did."*
**The check the run confessed was missing is the check that got built**, and the
confession retired itself. What stands in its place is narrower and worth
reading before you trust the file: `src/worker.ts` is now type-checked, and a
test executes its alarm handler — but no run there exercises its router, and
nothing in that script runs `workerd`. Switching CI on is also what found
that the root type-check had been skipping the whole `service/` workspace —
every line that touches HTTP, PostgreSQL, mail and sessions — while exiting
`0`; that is now closed, with the workspace passing as it already stood.
[The release note](https://github.com/pumasi-ai/pumasi/blob/main/releases/2026-08-31-pumasi-booking-advisory-ci.md)
is a can-hurt note under
[Q-026](https://github.com/pumasi-ai/pumasi/blob/main/DECISIONS.md), veto window
to 2026-09-07. **It shipped nothing to a user**, so the right-hand column of the
table above is untouched by it.
## How it is laid out
Two workspaces, one product, one repository.
| | Holds |
|---|---|
| `core/` | The availability engine. Pure: no clock, no I/O, no ambient state. |
| `service/` | Everything that touches the world: HTTP, PostgreSQL, mail, sessions. |
The engine is a workspace rather than its own repository on purpose. It has a
real boundary — purity, its own specification, its own acceptance suite — and
that boundary is enforced by the code and its tests, not by a repository wall.
It *was* a separate repository once; that cost two merge gates, two specification
trees and an unpinned dependency in exchange for a reusability nobody had asked
for (documented in [L-001](https://github.com/pumasi-ai/pumasi/blob/main/lessons/L-001-premature-specialization-forks-the-narrative.md)).
The day someone wants the engine alone, `git subtree split --prefix=core` hands
it over with its history intact.
## Deploying it
Two builds, and **neither one is the real one.** Self-hosting is first-class
permanently — a hosted deployment is a convenience, never a capability the
self-hosted build lacks. A project that documented only one of these would be
quietly making the other the copy.
**Self-hosted** — Node 22 or a container, with PostgreSQL:
```
docker compose up # service + PostgreSQL, locally
docker build -t pumasi . # then run it wherever
```
Set `PORT`, and `DATABASE_URL` for anything that must outlive the process.
`PGSSL=require` if your provider needs TLS.
**Cloudflare Workers** — one SQLite-backed Durable Object per tenant
organisation, each holding a single company's entire world: the same schema and
the same request handling as the single-tenant service, with one writer.
### The guarantee holds on both
No-double-booking is enforced **inside the database**, never in application
code: a `btree_gist` exclusion constraint on PostgreSQL, and `BEFORE INSERT` and
`BEFORE UPDATE` triggers raising `ABORT` on SQLite. Different mechanism, same
*kind* of mechanism — the check happens within the write, so two concurrent
bookings cannot both win. Neither dialect gets the weaker deal.
### Mail differs by build, and it is worth knowing which you have
The **self-hosted** build sends over SMTP — every provider speaks it, so the
choice is a URL and switching costs nothing — and it refuses at runtime to send
through a host that is not in the subprocessor register.
The **Workers** build sends through the Gmail API instead. There, what
constrains the transport is which one the build constructs: a code change,
visible in review, rather than a runtime guard. That is a **weaker control**,
and it is worth naming as weaker rather than describing both paths in language
that only the first one earns.
Beyond those two builds, nothing in the code knows about a particular host, and
no special protocol is required to participate.
---
# Pumasi Sign
URL: https://pumasi.ai/products/pumasi-sign/
Markdown: https://pumasi.ai/products/pumasi-sign.md
Updated: 2026-09-01
An unmetered, legally-binding B2B e-signature platform. Deterministic PDF stamping, SHA-256 tamper-evident audit certificates, public multi-tenant signing. Alpha; no licence file yet.
## Where this actually is
`alpha` — and this page still has to tell you where that number comes from,
because a maturity claim with no source is exactly what this site exists not to
publish.
It comes from the product's own register:
[`roadmap/STAGE.md`](https://github.com/pumasi-ai/pumasi-sign/blob/main/roadmap/STAGE.md),
first published 2026-08-31 at
[`6e02cc4`](https://github.com/pumasi-ai/pumasi-sign/commit/6e02cc4), which
records `alpha` **set on measured evidence** — not on aspiration, and not on a
chip. Read here at
[`f0d1912`](https://github.com/pumasi-ai/pumasi-sign/commit/f0d1912), which is
what `origin/main` answered when this card fetched it on 2026-09-01 — its
ladder, with the status that file's own exit-gate section gives each rung:
| Stage | Criteria | Status |
| :--- | :--- | :--- |
| **0 · Candidate** | Steward selection | **COMPLETE** — built and deployed |
| **1 · Alpha** | Pure-core suite passes 100%; **both** public landing surfaces live | **NOT MET** — both surfaces are live as of 2026-09-01; the gate is held on whether Surface B is *honestly calibrated*, and one of its claims is untrue |
| **2 · Beta** | Real end-to-end users complete workflows without engineer intervention | PENDING |
| **3 · Launched** | Production hardening, cross-model regression, 7-day veto window | PENDING |
Read that row 1 carefully, because it is the unusual part: **the stage is
`alpha`, `alpha`'s own exit gate is NOT MET, and on 2026-09-01 the reason
changed completely while the two words stayed the same.** Surface A is this
page. Surface B — the product's own root landing page at `sign.pumasi.ai` — is
**live**, deployed at **2026-09-01 01:02:16 UTC**. Issue
[#8](https://github.com/pumasi-ai/pumasi-sign/issues/8), which tracked its
absence, was closed three minutes before that at **2026-09-01T00:59:11Z** — the
tracker moved first and the deploy is what made it true. Through five
evaluations the unmet half of this gate was *Surface B is not live*. It is now
**Surface B is live and one of its claims is untrue** — the licence claim, set
out below. On the gate's literal words the
row now reads met; the register declines to record it as met, because Stage 1
asks that second surface for honest calibration and a surface is not honestly
calibrated while one of its claims is a licence grant a stranger may act on.
**What flips this row is a steward answering Q-021, not a build** — and not
this page.
**A correction to what this card said yesterday, because the file it pointed you
at has moved.** Through `3edd06f` this card disclosed that `STAGE.md`'s gate
*table* still carried its pre-deploy wording — Surface B *"has never been
deployed"* — while that same file's exit-gate section, its §2.2 and its §5 all
recorded the deployment, dated it to the second, and quoted the live route
table, and it closed *"The row is that file's to correct, not this one's."*
**That row is corrected**, at
[`3f51fa1`](https://github.com/pumasi-ai/pumasi-sign/commit/3f51fa1), with two
non-builder approvals recorded at
[`f0d1912`](https://github.com/pumasi-ai/pumasi-sign/commit/f0d1912) — verified
by this card against a freshly fetched `origin/main` on 2026-09-01. The Stage 1
row now opens *"IN PROGRESS — NOT MET, and the unmet half is Surface B's
**honesty**, not its existence"* and says in its own words which pass corrected
it. **So `STAGE.md` no longer disagrees with itself, and if you open it looking
for the contradiction this card used to name, you will not find one.** The
verdict did not move: the gate is `NOT MET` for the reason the row above gives,
and the correction was to the row's *wording*, not to the gate.
**An earlier version of this page said `seed`, and said in bold that
`pumasi-sign` had no `roadmap/STAGE.md`.** Both were true on the day it was
written and neither is true now. That repository carries `STAGE.md`, `VALUE.md`
and `MARKET.md` as of 2026-08-31, and this card is re-sourced from the first of
them — which is what `STAGE.md` §5 asks for by name.
**Two disagreements you will meet, named rather than smoothed over.**
- **The commons index still says `seed`, and disagrees with itself about what
to call the field.**
[`pumasi/catalog.json`](https://github.com/pumasi-ai/pumasi/blob/main/catalog.json)
records this product at `"status": "seed"` in both its arrays — one rung
below what its own register now says, and `seed` is not a rung on the
product-manager role file's ladder at all. Re-read for this card at `pumasi`
@ `2ab3a4f` on 2026-09-01 and unchanged, down to a top-level `updated` of
`2026-08-29` — three days stale, across the tick in which this product
deployed its front page. Re-read again at
[`23bbc64`](https://github.com/pumasi-ai/pumasi/commit/23bbc64) later the
same day: the only edit since is a `governance.product_rules` pointer to
[`PRODUCT-RULES.md`](https://github.com/pumasi-ai/pumasi/blob/main/PRODUCT-RULES.md);
every product field and the `updated` stamp are as they were. The file is not
merely stale but **internally inconsistent**:
`products[]` keys both products on `"status"`, while in `items[]`
`pumasi-sign` uses `"status"` and `pumasi-booking` uses `"maturity"` —
adjacent entries, same concept, two key names, both reading `seed`. That is
why two readers can report different things about this file and neither be
wrong. It has not been corrected because **no role file owns it** — open as
`pumasi/DECISIONS.md` **Q-019**, whose named default is a role-file amendment
nobody has made — and this page may not edit it. Whoever inherits it inherits
a schema question as well as a content one.
- **The `BETA` chip this card and the register argued about for two days is
settled, and the deploy is what settled it.** The chip was real — `v-chip …
BETA` at `frontend/src/views/LandingView.vue:34` as of
[`d797c81`](https://github.com/pumasi-ai/pumasi-sign/commit/d797c81) — and it
was replaced by a badge derived from
[`frontend/src/stage.ts`](https://github.com/pumasi-ai/pumasi-sign/blob/main/frontend/src/stage.ts),
under a comment naming `roadmap/STAGE.md` as the register — the same file
this card reads. **That is the version that went live.** Read out of the
served landing chunk on 2026-09-01 at 02:40 UTC, the constant and the badge
it generates are there in one expression:
```js
var g=`alpha`,_=g.charAt(0).toUpperCase()+g.slice(1),v=`${g.toUpperCase()} — ACTIVE DEVELOPMENT`
```
`grep -c BETA` on that chunk returns **`0`**. So the badge a stranger reads
is `ALPHA — ACTIVE DEVELOPMENT`, generated from the rung the register sets,
and **no user has ever seen a `BETA` badge on this product** — the argument
was about a page nobody could yet open.
**This page spent two days arguing about that chip. The argument was worth
more than the answer, because of the vocabulary it forced into existence.**
`STAGE.md` §5 keeps a four-state ledger for every claim this project makes.
A claim can be **wrong in source and in production**; **right in both**;
**fixed in source and still wrong in production** — the state that makes a
repository read as finished while a user keeps meeting the old behaviour, and
the direct, named cost of
[`pumasi/DECISIONS.md`](https://github.com/pumasi-ai/pumasi/blob/main/DECISIONS.md)
**Q-012**, *who deploys a merged fix, and by when*, still open with its default
unclaimed; or **merged and never shipped** — present on `main` and absent from
every deployment there has ever been. That fourth state was added because of
this product's landing page, and this card's own bundle readings are cited in
that file as the measurement that forced the row.
**On 2026-09-01 the page shipped, and the ledger moved in one motion.** Until
that morning every sentence in `LandingView.vue` sat in the fourth state:
unshipped, and therefore harmless. The 01:02:16 UTC deploy took all of them
public at once — `service/wrangler.jsonc` serves `frontend/dist` as a single
`ASSETS` directory, so there is no shipping one claim and holding another. The
page had carried **three** claims the repository could not back. Two were
repaired before it went out: the `BETA` chip, which shipped reading `ALPHA`,
and an uncited competitor-pricing block, which shipped cited and dated, linking
both vendors' own pages. **The third shipped unrepaired, and it is the
licence claim** — which moved from *merged and never shipped* straight to
*wrong in source and in production*, the worst square on the board.
That difference is the whole reason this site keeps the vocabulary. **An
unshipped false claim is a bug report. The same claim, deployed, is something a
stranger can act on** — and the deployed one here is a grant of rights, in a
table row whose neighbouring columns say *Proprietary Closed Source*, on a
repository that grants none. The two could not be separated at deploy time,
which is what **Q-028** was raised to record; it did not get answered so much
as overtaken, resolving itself by shipping.
**The one thing the deploy made unambiguously better is worth naming**, because
everything else it did was move a claim from private to public: the repository
can no longer disagree with the register about the rung. The badge is generated
from `STAGE.md`, and a frozen case in that repository fails the build if the
two drift apart. The stage word on the live page is right today by construction
rather than by luck — which is the only kind of right that survives the next
deploy nobody announces.
Where a file disagrees with `STAGE.md`, this page follows `STAGE.md` — not
because it is higher or lower, but because it is the one that shows its
evidence and names its falsifiers. **Where `STAGE.md` disagreed with *itself*,
as its gate table did until `3f51fa1`, this page followed the half that showed
the measurement and said which half that was — and that rule is recorded here
because it was used, not because it is needed today.** The two halves agree
now.
## Two defects are live on the hosted service, and both repairs are waiting
**If you are about to send an agreement through `sign.pumasi.ai`, read this
before the licence section below.** Two release notes were published on
2026-09-01 **eighty-three minutes apart** — `pumasi` `14d8af4` at 01:41:04 UTC
and `df8f0d0` at 03:04:29 UTC, read from the commit timestamps — and **both
describe defects that are still live for users**. Neither is a report about a page nobody can open: the surfaces are
deployed and reachable, and one of them silently destroys something the sender
wrote.
**The deployment has not moved, and this card measured that rather than assumed
it.** At **2026-09-01 05:20:32 UTC** the served root still loads
`/assets/index-CnoFAC2c.js` — the same chunk fingerprint
[`STAGE.md` §2.2](https://github.com/pumasi-ai/pumasi-sign/blob/main/roadmap/STAGE.md)
used to identify the deployed tree as
[`0e26917`](https://github.com/pumasi-ai/pumasi-sign/commit/0e26917) — and
`service/wrangler.jsonc` binds `../frontend/dist` as the worker's own `ASSETS`
directory, so the two ship as one artefact and an unmoved front end is an
unmoved worker. `GET /api/health` answered `200` at **05:20:33 UTC**, naming
itself `pumasi-sign`. The product is
up, running the old code.
**Re-measured by a second seat at 2026-09-01 05:50:00 UTC, before this page was
published, so none of it rests on an earlier seat's word.** The served root still
loads `/assets/index-CnoFAC2c.js`; `/api/health` still answers `200`; and each
chunk this section reads out is still the byte-for-byte artefact named below —
`ExternalSignView-CmDSqiPb.js` **5 250** bytes, `SignView-BM1dkPaZ.js` **46 980**,
`LandingView-C5khdw3s.js` **10 046**. The deployment has not moved.
### 1 · The settings pencil deletes the message you wrote to your signers
**What a sender loses.** The send form gives you a box for a covering note to
the people signing — *Please sign by Friday.*, *This replaces the draft I sent
Tuesday.* — and `durable.ts` returns it to every recipient on the token view, so
it is often the only explanation they get for what they are being asked to sign.
Elsewhere on the same screen there is a pencil for the expiration date and the
reminder settings. **Opening it, changing nothing, and pressing save deletes the
note.** The dialog then reports *Envelope settings updated.* — that string is in
the served chunk, beside the request that causes the loss — and closes. Nothing
warns, nothing asks, and nothing on the screen afterwards says the note is gone.
**Both halves measured on the live host, 2026-09-01 05:22:14 UTC.** The client half
is in the chunk a sender's browser actually runs — and it is worth seeing the
two dialogs side by side, because they call the same route:
```console
$ curl -s https://sign.pumasi.ai/assets/EnvelopeDetailView-C4VlFBtA.js \
| grep -o 'patch(`/submissions/\${e}`,{[^}]*}'
patch(`/submissions/${e}`,{title:t,message:n||null}
patch(`/submissions/${e}`,{expires_at:t,reminders_enabled:U.value,reminder_interval_days:dt.value}
```
The first is the *correct details* dialog, which is about the message. The
second is the settings pencil, which is not — three fields, no `message`. The
server half is the deployed commit's own source, read at `0e26917` rather than
at `main`:
```js
// service/src/durable.ts:1209-1211 at 0e26917 — the tree serving sign.pumasi.ai
`UPDATE submissions SET title = ?, message = ?, updated_at = ? WHERE id = ?`,
String(body.title ?? sub.title).slice(0, 200),
body.message != null ? String(body.message).slice(0, 2000) : null,
```
The title has a rule for the absent case. **The message has none**, so a request
that never mentions it is treated as a request to erase it.
**Merged, and not deployed.**
[`9659e69`](https://github.com/pumasi-ai/pumasi-sign/commit/9659e69) is in
`main` and tells *absent* (keep) from *present-and-null* (clear) — `durable.ts`
now reads `body.message !== undefined ? … : (sub.message ?? null)` at line 1326.
**This page does not claim that repair has shipped**, and neither does its own
note:
[*Pumasi Sign stops deleting the message you wrote to your signers*](https://github.com/pumasi-ai/pumasi/blob/main/releases/2026-09-01-pumasi-sign-message-survives-settings.md),
a can-hurt release whose 7-day veto window closes **2026-09-08**.
**That date is [`DECISIONS.md` **Q-037**](https://github.com/pumasi-ai/pumasi/blob/main/DECISIONS.md)'s
own, reported here and not set here** — this card sets no deadline on any
steward entry and has no standing to.
**One thing the repair cannot do, and it is why this belongs on the card rather
than in a changelog: messages already deleted are gone.** That is the release
note's own statement, in the sender's words, and the deployed tree corroborates
it as far as a reading of the tree can: the `UPDATE` above overwrites the column
in place, and the `corrected` audit row written immediately after it
(`durable.ts:1214` at `0e26917`) is called with no `details_json` at all, so no
prior value is recorded anywhere the service can read back. What backups a
particular Cloudflare account keeps is not something this page can measure, and
it does not claim to.
### 2 · An expiration date on the live service does nothing
The send wizard asks for a deadline, refuses one in the past, shows it back, and
states in two places — `SendView.vue:1332` and `EnvelopeDetailView.vue:1104`
— that *without* an expiration date the envelope stays open until completed or
voided. (The refusal is `:min="todayIso"` on that field, `SendView.vue:1300`.) The plain reading is that *with* one it does not. On the deployed build
the date is **stored and otherwise ignored**, and the two routes differ in a way
worth separating rather than blurring: the send form's `INSERT INTO submissions`
(`durable.ts:1062` at `0e26917`) does write `expires_at`, while the settings
pencil's `PATCH` never touches it. So the date you set at send time is kept and
never acted on, and the date you set afterwards is not even kept. Nothing ever
expires either way.
**Measured 2026-09-01 05:22:14 UTC, on the deployed tree and on the chunks a
recipient's browser actually loads.** At `0e26917`, `service/wrangler.jsonc` has
**no `crons` key**, `service/src/worker.ts` has **no `scheduled` export**, and
the `PATCH` route the pencil calls contains **no `expires_at` write**. Nothing
sweeps; no envelope ever reaches the `expired` status. That shows through to the front end: the served
`ExternalSignView-CmDSqiPb.js` (`200`, 5 250 bytes), which is what an emailed
signing link opens, carries **four** closed-envelope cases and no expired one —
*already signed*, *complete*, *voided*, *declined* — so a past-due envelope
still reports `open`, still shows its landing page, and still mails the signer a
verification code — `6-digit`, which is that same chunk's own word for it, three
times.
**Where it does stop, and why that is the point rather than a mitigation.**
After the code, the shared signing view refuses: the served
`SignView-BM1dkPaZ.js` (`200`, 46 980 bytes) computes
`r=n!=null&&new Date(n).getTime()<=Date.now()` from `expires_at` and blocks with
*This envelope reached its expiration date and can no longer be signed.* **That
check is client-side only**, and the deployed source's own comment beside it
(`SignView.vue:480` at `0e26917`) says *the server rejects `/complete` the same
way* — which at that commit it does not. So the deadline is enforced against
the party using the app and not against the party addressing the API directly.
This card does not tell you a past-due envelope is unsignable on the live
service; it tells you the service is not what stops it.
**Merged, and not deployed.**
[`2471a29`](https://github.com/pumasi-ai/pumasi-sign/commit/2471a29) adds the
hourly cron trigger and the `scheduled` sweep, joins `expired` to `isTerminal()`
so the guards already in the code refuse it, and starts saving what the pencil
sends.
[*Pumasi Sign now keeps the expiration date it asks you for*](https://github.com/pumasi-ai/pumasi/blob/main/releases/2026-09-01-pumasi-sign-expiration-dates-bind.md)
carries a 7-day window closing **2026-09-08** — again
[`DECISIONS.md` **Q-035**](https://github.com/pumasi-ai/pumasi/blob/main/DECISIONS.md)'s
own date, reported — and its own second paragraph reads *It is merged and it is
**not deployed**.*
### Why both are still here, and what this page will not do about it
**Nobody owns deployment.** That is
[`DECISIONS.md` **Q-012**](https://github.com/pumasi-ai/pumasi/blob/main/DECISIONS.md),
open — and explicitly **outside** CHARTER Part 0's proceed-on-default rule, so
unlike nearly everything else in this project an agent may not proceed on it.
**It is not this product's problem alone**: as of 2026-09-01 the same entry also
holds the repair for a `booking.pumasi.ai` page that shows a booker no times at
all, measured on that host and written up on the
[Pumasi Booking](/products/pumasi-booking/) card. One open question, two
products, and a user meeting a defect on each.
**Q-028** counted the repairs already stacked in the undeployed bundle at
`0e26917`, and **each of these two entries places itself in that queue in its own
words** rather than leaving this card to do the arithmetic. Q-035: *"Q-028
records that two earlier repairs already wait in the same undeployed bundle;
this is the third."* Q-037: *"Q-028 counted three repairs already waiting in that
undeployed bundle and this is the fourth."* So the expiration repair is the
**third** and the message repair the **fourth**. **This card sets no deadline
on any of those entries, names no deployer, and takes no position on their
defaults.** It reports their state, which is all a catalog page is for.
**The ordering is the part that generalises.** The expiration repair is what
makes that pencil start working — which would have driven *more* senders into
it, and every use of it still wiping the message. The two repairs were published
eighty-three minutes apart, land in the same bundle, and wait together behind one
open question about who carries a merge to a user — an entry raised well before
either of them.
## Run it
```bash
git clone https://github.com/pumasi-ai/pumasi-sign
cd pumasi-sign
cd service && npm install && npm test
npx wrangler dev
```
It starts a local Cloudflare Worker with SQLite Durable Objects and pure-core PDF stamping. Open the local port in your browser to create templates, place fields, and collect signatures.
## What it solves
E-signature is bought once and then paid for forever, by the seat, with the
envelope ceiling written where nobody reads it. What the incumbents actually
charge, read from their own pricing pages on **2026-08-31** and recorded with
their sources in `pumasi-sign`
[`roadmap/MARKET.md` §1](https://github.com/pumasi-ai/pumasi-sign/blob/main/roadmap/MARKET.md):
| Plan | Price as shown | Limit as shown |
| :--- | :--- | :--- |
| [DocuSign](https://ecom.docusign.com/plans-and-pricing/esignature) Personal | $11/month (annual, billed monthly; $132/yr) | 5 envelopes per month |
| DocuSign Standard | $30/user/month (annual; $360/yr per user) | 100 envelopes/user/year |
| DocuSign Business Pro | $45/user/month (annual; $540/yr per user) | 100 envelopes/user/year |
| [SignWell](https://www.signwell.com/pricing/) Free | $0 | 3 documents/month, 1 sender |
| SignWell Light | $12/sender/month, or $10 billed annually | Unlimited documents |
| SignWell Business | $36/month for 3 senders, or $30 billed annually; extra senders $15/mo | Unlimited documents |
Prices move, and the date is part of the claim: if you find different numbers on
those two pages, they are newer than these. What the pages establish is narrow
and worth stating exactly — both vendors meter **senders**, and DocuSign's two
mainstream business plans state **100 envelopes per user per year** at $30 and
$45 per user per month. Neither page offers a self-hosted or source-available
option. Nothing here should be restated as "DocuSign costs X" without the plan
name attached.
**An earlier version of this page asserted that these platforms "charge $25 to
$65 per user monthly", with no citation.** Against the pages above on this
date, that range is wrong at both ends. This project has published and then
retracted an uncited competitor number once already (`pumasi-booking`
`0d1674d`); the table replaces the sentence rather than repairing it.
Pumasi Sign provides:
- **Deterministic Coordinate Stamping**: Places signatures, initials, dates, names, text fields, and checkmarks at normalized coordinates directly onto PDF pages.
- **Tamper-Evident Audit Certificates**: Every executed document automatically appends a cryptographic certificate logging the original and completed SHA-256 hashes, signer IP addresses, user agents, and ISO timestamps.
- **Public Zero-Login Recipient Flow**: External counterparties sign securely via tokenized links with optional 6-digit email verification codes without creating an account.
- **Office 365 Cloud Document Conversion**: Native conversion for Word, PowerPoint, and Excel files via cloud rendering APIs.
- **Multi-Tenant Design Customization**: Organizations can customize their logo, company title, and primary brand colors across all recipient-facing signing portals.
**There is no meter behind any of that**, and for a plain reason rather than a
generous one: the deployed service contains no quota, plan, billing or
subscription code at all
([`VALUE.md` §1](https://github.com/pumasi-ai/pumasi-sign/blob/main/roadmap/VALUE.md)).
There is nothing to lift when you run it yourself — see the next section for
what that sentence is currently missing.
## About the licence, and what this page will not say
This card's summary line used to end **"Apache-2.0."** That is not a claim this
page can make today. `pumasi-sign` is a **public** repository with **no
`LICENSE` file**:
```bash
gh api repos/pumasi-ai/pumasi-sign/contents/LICENSE # 404 Not Found
gh api repos/pumasi-ai/pumasi-tunnel/contents/LICENSE # 200 — 10 273 bytes
```
A public repository with no licence grants no rights at all: you may read the
code, and you have no permission to run, modify or redistribute it. A sibling
product carries the file — `pumasi-tunnel`, Apache License 2.0, as does this
website's own repository — so this reads as an omission rather than a position
taken.
**What changed on 2026-09-01 is not the licence. It is who is being told.**
Until that morning this was an internal question about an undeployed page.
At **01:02:16 UTC** the product's own landing page went live carrying
`Apache-2.0` in three separate claims — the hero strip, the stage banner, and a
comparison-table row headed *License & Source Code* whose neighbouring columns
read *Proprietary Closed Source*. That row's entire purpose is to invite a
reader to choose this product **because** its terms differ from the
incumbents', and the terms it names do not exist. Q-021's own framing — *not
yet public, which is the whole reason this is a question and not an incident* —
is overtaken by that deploy. **This card reports the claim; it does not repeat
it**, and one surface saying something untrue is a mistake that two surfaces
would make a pattern.
**A note for anyone checking this themselves, because the obvious command was
lying until recently and this page said so.** Through 2026-08-31,
`gh repo view --json licenseInfo` returned `null` for *every* repository in
this organisation, including `pumasi-tunnel` and `pumasi-web`, which
demonstrably do carry an Apache-2.0 `LICENSE` — so a `null` there was not
evidence of absence, it was no evidence at all. **Re-checked by this card at
2026-09-01 05:26:39 UTC, that is no longer true**: GitHub's detection has caught
up and now reports `{"key":"apache-2.0"}` for both of those repositories, and
`null` for `pumasi-sign`.
The conclusion is unchanged and the reasoning is worth keeping anyway. That
`null` is the evidence cited in `pumasi-sign`'s own `STAGE.md` §2.3 and in
Q-021, and on the day it was cited it would have read identically for a
correctly licensed repository — a test that cannot fail is not a check.
It happens to be corroborated now, which is luck rather than method. **The
question the file answers is still the one to ask**: `gh api
repos/pumasi-ai/pumasi-sign/contents/LICENSE` → `404`, above, re-run for this
card at 2026-09-01 05:22:52 UTC.
**Which of those it is, is not this page's call.** It is open as
[`pumasi/DECISIONS.md`](https://github.com/pumasi-ai/pumasi/blob/main/DECISIONS.md)
**Q-021**, whose named default is to add the Apache-2.0 file and honour the
claim, and whose named alternative is to remove the claim instead. That entry
records that the project's usual proceed-on-the-default rule is deliberately
**not** taken here, because publishing a licence is an outward grant that third
parties may then rely on — the one kind of file edit that is not really
reversible.
So this page takes the move that prejudges neither answer: it stops stating a
licence as a fact, and states the situation instead. When Q-021 lands, this
section becomes one sentence.
## Inside the Product
The screenshots below are of the deployed application at
[**sign.pumasi.ai**](https://sign.pumasi.ai), which answers `GET /api/health`
with `200 {"status":"ok","service":"pumasi-sign", …}`.
**You can go and try it.** An earlier version of this page told you not to,
citing a report that sign-up and sign-in were both broken. That report —
[#9](https://github.com/pumasi-ai/pumasi-sign/issues/9) — was **closed `not
planned` on 2026-08-31 16:04 UTC**, and closed on evidence rather than on an
inability to reproduce: the worker that serves this host cannot emit a `403`
anywhere in `service/src/`, its `establishSession`
(`service/src/durable.ts:655`) has no domain gate and creates an account for
any verified email address, and the reporter's exact wording occurs once in the
whole fleet — in a different product.
**The defect this page carried at the top for two days is closed, and it is
worth a line rather than a silent deletion.**
[#7](https://github.com/pumasi-ai/pumasi-sign/issues/7), `priority: high`: a
person who signed out saw one button, *Sign in again*, and pressing it handed
them `{"error":"Endpoint not found"}` rendered raw as a document. It was
**closed 2026-09-01T00:59:12Z**, and — the part that matters, because closing
an issue serves nobody by itself — the repair **reached users** in the deploy
at **2026-09-01 01:02:16 UTC** — three minutes after the tracker said so, not
before. Alongside it,
[#8](https://github.com/pumasi-ai/pumasi-sign/issues/8), the app root having no
product page in production, was **closed 2026-09-01T00:59:11Z** and made true
by the same deploy.
**Verified on the live host rather than on the tracker**, 2026-09-01 02:40 UTC:
```console
$ curl -s https://sign.pumasi.ai/ | grep -o '/assets/index-[^"]*\.js'
/assets/index-CnoFAC2c.js
$ curl -s -o /dev/null -w '%{http_code} %{content_type}\n' \
'https://sign.pumasi.ai/login?next=%2F'
200 text/html
```
The served `SignedOutView-C2J9s3yp.js` builds that button's target by calling
the main bundle's exported helper with `/`, and the helper is
``function ml(e){return`/login?next=`+encodeURIComponent(e)}``. Decisively, the
helper that built the broken URL is **gone from the shipped JavaScript**:
`grep -c '/api/auth/login?next=' index-CnoFAC2c.js` returns **`0`**.
**One thing not to over-read, because the obvious check still looks alarming.**
`GET /api/auth/login?next=%2F` on that host **still answers `404`** — and that
is now correct behaviour rather than a defect. Nothing targets it any more. A
route that never existed on the worker returning `404` is a server doing its
job; the defect was a button pointing at it, and the button no longer does.
**What has not changed is the thing underneath both issues: nobody owns
deployment.** That is **Q-012**, open, exactly as on the sibling
[Pumasi Booking](/products/pumasi-booking/) card. This deploy was not announced
in any queue and matches no release note; it had to be identified from the
artefact, which `STAGE.md` §2.2 does by chunk fingerprint, landing on
[`0e26917`](https://github.com/pumasi-ai/pumasi-sign/commit/0e26917) — built
from a working tree five seconds *before* that commit's own timestamp. **And
`main` has moved past it by nine commits since** — `git rev-list --count
0e26917..f0d1912` against a freshly fetched `origin/main`, run by this card on
2026-09-01 — of which **two change `service/src/durable.ts`**, the file that
answers this host:
[`2471a29`](https://github.com/pumasi-ai/pumasi-sign/commit/2471a29) and
[`9659e69`](https://github.com/pumasi-ai/pumasi-sign/commit/9659e69). Those are the two repairs the section *Two defects are
live on the hosted service* measures, and the reason this paragraph is not a
piece of housekeeping: the repository is ahead of the deployment by two defects
a user is meeting today, and nothing carries one tree to the other. **Someone
deployed once; the question of who owes you the next one is still open.**
The sign-in repair is written up in
[a release note](https://github.com/pumasi-ai/pumasi/blob/main/releases/2026-08-31-pumasi-sign-sign-in-again.md)
whose own first line reads *"It is merged and it is **not deployed**"* — a
can-hurt release under
[`DECISIONS.md` **Q-027**](https://github.com/pumasi-ai/pumasi/blob/main/DECISIONS.md),
veto window to 2026-09-07, which the steward has yet to confirm. That note is
written in the present tense and describes the branch on the day it was
published; the deployment has since overtaken it. **Read a release note as a
claim about the repository and check the deployment separately** — and note
what the window now means: seven days to veto a change users already have.
What is queued next is a question for
[`roadmap/BACKLOG.md`](https://github.com/pumasi-ai/pumasi-sign/blob/main/roadmap/BACKLOG.md),
and **this page quotes no rank from it.** That file was reordered three times on
2026-08-31 alone; a rank in prose is the same kind of cache as a test count, and
the one this page used to publish was spent before you read it. Read the file.
See *Before you use it* at the top of this page for what is still worth knowing
before you rely on this — **as of 2026-09-01 that is two live defects in the
deployed worker and the licence claim, no longer the front door.** The local
`wrangler dev` route above is unaffected by any of it, and neither defect is in
the `main` you would clone.
### 1. Document Dashboard & Action Queue
Manage incoming signature requests, active contracts, and completed envelopes in one centralized view:
### 2. Multi-Signer Send & Preparation Wizard
Upload agreements, assign signers, configure signing orders, and place drag-and-drop fields:
### 3. Front-End Design & Branding Customizer
Customize organization logos, brand accent colors, and recipient welcome banners with live real-time preview:
### 4. Frictionless Recipient Verification
External signers receive secure tokenized links with 6-digit email verification codes—no account creation required:
## Cloudflare Edge Native
Pumasi Sign is built to run at the edge with zero dedicated container overhead:
- **Pure JavaScript / WebAssembly PDF Engine**: PDF parsing and stamping execute inside Cloudflare V8 isolates with zero C++ or heavy OS binary dependencies.
- **Transactional SQLite Storage**: Envelopes, signers, templates, and document blobs are stored in transactional Cloudflare Durable Objects.
- **Custom Domain Deployment**: Deployed globally at `sign.pumasi.ai`, which answered `200` on `/api/health` when this card was written (2026-09-01 02:40 UTC). Since **2026-09-01 01:02:16 UTC** that host also serves the product's own landing page at `/` ([#8](https://github.com/pumasi-ai/pumasi-sign/issues/8), closed), so this catalog card is no longer the only public surface this product has. The live bundle is still behind `main`, and `alpha`'s exit gate above still reads **NOT MET** — for what that landing page says, no longer for its absence.
**One thing this section cannot tell you yet, and says so rather than
implying otherwise.** `sign.pumasi.ai` is served by the Cloudflare Worker in
`service/`, not by the FastAPI application in `backend/` — verified by the
shape of its own error bodies, and open as `pumasi/DECISIONS.md` **Q-018**
(*which implementation is Pumasi Sign?*). **This page previously added that CI does not gate
`service/`. That is no longer true, and the correction is not a softening.**
Since [`ef851d6`](https://github.com/pumasi-ai/pumasi-sign/commit/ef851d6) —
committed as *"a job for the tree users actually meet"* —
`.github/workflows/ci.yaml` runs a fourth job that builds the worker and runs
its suite, with a step that asserts the suite **actually ran** rather than
trusting exit `0`. **What that job runs changed in kind this week, not in
degree.** Until [`3d01198`](https://github.com/pumasi-ai/pumasi-sign/commit/3d01198)
— *"the deployed tree's front door, recorded"* — every case under
`service/src/test/` exercised one pure function, the PDF stamper, and nothing
that answers a request. That commit is the first in this repository's history
to **construct the Durable Object that serves `sign.pumasi.ai` and drive it
through its own `fetch()`**: schema initialisation, `establishSession`, the
session cookie's shape, single-use codes, and the `404` an unknown route is
given. The cross-family review that approved it
([`reviews/20260831-160155-code-gemini.md`](https://github.com/pumasi-ai/pumasi-sign/blob/main/reviews/20260831-160155-code-gemini.md),
`VERDICT: APPROVE`) ran the suite rather than reading it.
**No test count is quoted here.** `cd service && npm test` prints the current
totals; a number copied into prose is a cache with no way to invalidate it —
the rule the [Pumasi Booking](/products/pumasi-booking/) card states about its
own suite, and this page carried the stale number that proves it. **And none
of this is an upgrade announcement.** The coverage reached the worker's front
door while issue #7 was live *at* that front door in production; the new cases
characterise what the deployed tree does, they do not repair it.
So "CI is green" is now a broader claim than it was and still not a statement
about what you would meet at that domain — and run
[33420378497](https://github.com/pumasi-ai/pumasi-sign/actions/runs/33420378497)
shows exactly how. At `ef851d6` it is green on **all four** jobs — `backend`,
`frontend`, `service`, `e2e` — while the *Sign in again* button on this
product's own signed-out page was returning `404` in production, measured from
this card at 18:49 UTC that same day and not repaired for users until the
deploy at **2026-09-01 01:02:16 UTC**. **Four green jobs sat above a live
entry-path defect for the better part of a day**, and that is the argument
rather than the anecdote. The `e2e` job is the one to sit with: it is green
**because** `frontend/playwright.config.ts` drives `backend/` — locally a
`uvicorn` process, in CI a container built from the root `Dockerfile`, and both
are `backend/`, the one tree in which `GET /api/auth/login` exists. Its
Playwright specs exercise a sign-in path that works, on a server no user
reaches, and would keep passing however long the defect stayed live
(`STAGE.md` §2.1).
---
# Pumasi Tunnel
URL: https://pumasi.ai/products/pumasi-tunnel/
Markdown: https://pumasi.ai/products/pumasi-tunnel.md
Updated: 2026-09-01
Localhost tunnels over one outbound connection: HTTP by subdomain, raw TCP for RDP and databases, zero-install from stock ssh. Alpha: a public relay runs on pumasi.link, http only. Apache-2.0.
## Where this actually is
`Alpha` — the current stage in the product's own
[`STAGE.md`](https://github.com/pumasi-ai/pumasi-tunnel/blob/main/roadmap/STAGE.md),
which is the file this page is not allowed to run ahead of. Its last evaluation
is at [`9e2de66`](https://github.com/pumasi-ai/pumasi-tunnel/commit/9e2de66);
`main` has moved on to
[`9cc9e65`](https://github.com/pumasi-ai/pumasi-tunnel/commit/9cc9e65) since,
and where this page reads the tree past that evaluation it says so. The stage
is the same at both. Its gates, as that file writes them:
| Stage | Criteria | Status |
| :--- | :--- | :--- |
| **0. Candidate** | Scored by 3 model families (40/60) and selected by steward | **COMPLETE** |
| **1. Alpha** | Pure-core suite passes 100%; both public landing surfaces live | **COMPLETE 2026-08-31**, re-measured at `9e2de66` — the run counts are in `STAGE.md` §2 and this page does not repeat them |
| **2. Beta** | Real end-to-end users complete workflows without engineer intervention | **IN PROGRESS** — §4 |
| **3. Launched** | Production hardening, cross-model regression, 7-day veto window | PENDING |
Read that table exactly as it is written. **`Alpha`'s exit gate is met and
`Beta` work has started — and the stage is still `alpha`.** `STAGE.md` puts it
in those words: *"the `beta` label is not claimed."* This page will not claim
it either.
**And read row 1 with the qualification its own file attaches to it**, because
this page quotes that table and must not quote it cleaner than it is. The gate
is `MET` and *qualified*: every figure behind it was taken on one machine by the
seat that wrote the file, and a green suite says the change broke nothing, not
that it is right — `STAGE.md` §2 says both in more words. An earlier version of
this page quoted a failure rate for that suite. It no longer does: the two
ordering defects behind that rate are closed on `main` — the TCP announce
before bind at
[`1d9505c`](https://github.com/pumasi-ai/pumasi-tunnel/commit/1d9505c), the
HTTP announce before serve at
[`fd523e8`](https://github.com/pumasi-ai/pumasi-tunnel/commit/fd523e8) — and
`pumasi/DECISIONS.md` **Q-024**, which asks whether `MET` may be read that way
at all, is still open. Until it is answered **no stage-promotion announcement
is published off that gate**, and nothing public quotes its figure. Nothing on
this page is a promotion; the product is `alpha` and is not asking to move.
Three verified facts hold it back, each one an entry in
[`BACKLOG.md`](https://github.com/pumasi-ai/pumasi-tunnel/blob/main/roadmap/BACKLOG.md)
rather than an opinion — and **two of the three are now fixed on `main` and
on `main` only**, which this page says in the same breath each time because
the difference is the whole point:
1. **Every tunnel the public relay opens is handed an address that does not
answer.** `PublicURL` returned `https://.pumasi.link` unconditionally,
the console printed it, and nothing listens on 443. The unconditional
`https://` is **fixed on `main`** at
[`83fd9f7`](https://github.com/pumasi-ai/pumasi-tunnel/commit/83fd9f7) and
**not deployed to `pumasi.link`**, which still announced it at 19:12 UTC on
2026-09-01. The certificate half is not built. The next section is about
nothing else.
2. **A name belongs to nobody — true of `pumasi.link`, false on `main` since
[`4489fbe`](https://github.com/pumasi-ai/pumasi-tunnel/commit/4489fbe).**
The relay this page used to describe computed `Tunnel.Reserved` from the
shape of a request and read it nowhere; any anonymous agent could take any
free name, including one somebody was using between reconnects. That is
still exactly what `pumasi.link` serves: its status view carries no
`"reserved"` key, which dates the running binary before the change. On
`main`, across `4489fbe` ·
[`c12d11a`](https://github.com/pumasi-ai/pumasi-tunnel/commit/c12d11a) ·
[`20e9d57`](https://github.com/pumasi-ai/pumasi-tunnel/commit/20e9d57)
(`spec/0004`, slice 1), `--subdomain myapi --token <16+ characters>`
**claims** the name — and with `--tcp --tcp-port P`, that port — for whoever
holds the token, holds both across a disconnect, and refuses them to every
other caller including one presenting no token. `Reserved` is now set from
the reservation record and read by the status view. The relay still has
**no auth flag**: a token proves *continuity*, not identity, and decides
which name you may have, not whether you are let in.
3. **Nothing survives a restart — true of `pumasi.link`, false on `main` since
[`9cc9e65`](https://github.com/pumasi-ai/pumasi-tunnel/commit/9cc9e65).**
The subdomain registry and the TCP port pool were, and on the running relay
are, in-memory maps: a relay restart drops every name, every reserved port
and every live tunnel. On `main` (`spec/0004` slice 2, specified at
[`9dd067a`](https://github.com/pumasi-ai/pumasi-tunnel/commit/9dd067a)
before any of its code existed) the relay takes a twelfth flag,
`-reservations `: one JSON document holding every claimed name and
port, written whole to a temp file, fsynced, renamed, then the directory
fsynced, with a lock on a sibling file so two relays cannot share it
(`core/reservationstore.go`). The frozen case that says so builds a
**second relay over the same file** and checks the stranger is refused and
the owner is given both back —
[`relay/reservation_test.go:640`](https://github.com/pumasi-ai/pumasi-tunnel/blob/main/relay/reservation_test.go),
`TestAReservationOutlivesTheRelay`, which was specified and absent from the
tree until this commit. **Read the commit's own limit with it:** this
removes the *loss* a restart used to cause; it does not make one shorter. A
live TCP connection cannot outlive the process at either end; the agent's
reconnect gets the same address back. And with `-reservations` empty, which
is the default, the relay is the old relay in every respect.
**Both of those merges are behind the same undeployed restart as the scheme
fix.** `pumasi.link` runs a build older than `83fd9f7`; who may restart it is
`pumasi/DECISIONS.md` **Q-014**, open; `STAGE.md`'s own table of what `main`
does against what `pumasi.link` serves reads **no** in the deployed column for
both facts. Q-014's stated retirement condition is *durable registry and port
reservations* — the thing `9cc9e65` builds. Whether that retires the entry is
the steward's reading, not this page's; until a deploy happens the answer for
any user of `pumasi.link` is unchanged.
**One more thing about `9cc9e65` that a reader depending on it should know.**
Its commit carries two spec-round review transcripts and no code-round one, and
no `Reviewed-By` trailer for the code: a 1 089-line change to `core/` and
`relay/` merged without a cross-family code review. Below `launched` the
charter makes that review advisory, so the merge is in order — but the
evidence that it is *correct* is the frozen cases it was written against, not a
second family having read it.
Two more gate the label from the commons'
[`PRODUCT-RULES.md`](https://github.com/pumasi-ai/pumasi/blob/main/PRODUCT-RULES.md)
(v1.0, on `pumasi` `main` since
[`23bbc64`](https://github.com/pumasi-ai/pumasi/commit/23bbc64)): **PR-1**, a
user-visible version number, binds always, and this product has **none
anywhere** — no version file, no `/version`, nothing on the console, which is
why the running binary's age is inferred from a missing JSON key rather than
read; **PR-2**, an in-app feedback path, binds at the `beta` promotion and is
unbuilt. `9cc9e65` touches `core/` and `relay/` only and changes neither.
## There is a public relay, and this page used to deny it
An earlier version of this page said, in its second paragraph, **"There is no
hosted relay."** That was false, and it was the expensive kind of false: it
told visitors not to try the one thing this product does that its competitors
charge for. What that sentence got right was the domain, and only the domain.
Every claim below is one command you can run yourself.
**There is a public relay and it is on `pumasi.link`. `tunnel.pumasi.ai` does
not resolve and never did.** The apex serves the relay console, the ssh ingress
answers on port 2222, and `/_pumasi/status` returns the live tunnel list:
```bash
curl -sS -o /dev/null -w '%{http_code}\n' http://pumasi.link/_pumasi/status # 200
host tunnel.pumasi.ai # NXDOMAIN
```
Checked 2026-09-01 19:12 UTC, that status endpoint reported one tunnel open —
`sshsteward`, `pumasi.link:20000` → local port 22, opened 2026-08-31 06:18:13
UTC, **132 847 seconds** (36 h 54 m) unbroken. That is the relay carrying real
traffic, not a demo, and it is the strongest evidence this product has. It is
also the tunnel Q-014 is about: the remote-access route to the host the relay
runs on.
**And the `https://.pumasi.link` address that same relay still prints to
every user does not work. Nothing is listening on port 443.** Both halves of
that sentence were re-checked against the live host at **2026-09-01 19:12 UTC**,
one command each:
```bash
curl -sS http://pumasi.link/_pumasi/status
# {"base_domain":"pumasi.link", … "url":"https://sshsteward.pumasi.link", …}
# — and no "reserved" key on the tunnel, which every build since 4489fbe emits
curl -sS -o /dev/null -w '%{http_code}\n' https://pumasi.link/
# curl: (7) Failed to connect to pumasi.link port 443 after 49 ms
```
The relay announces `https://`; port 443 refuses. Use the `http://` address it
also serves.
**The corrections are merged and they are not what you will meet.** Say both,
because they are different facts:
| | State |
| :--- | :--- |
| `pumasi.link` **today** | Still announces `https://`. Port 443 refused, 19:12 UTC 2026-09-01. No name is owned; nothing survives a restart |
| `pumasi-tunnel` `main` since [`83fd9f7`](https://github.com/pumasi-ai/pumasi-tunnel/commit/83fd9f7) | Takes `-public-scheme`, **defaults to `http`** — the truth about what the binary serves. An unknown scheme stops the relay rather than being coerced |
| `main` since [`4489fbe`](https://github.com/pumasi-ai/pumasi-tunnel/commit/4489fbe) | A name and its port belong to a `--token` holder and are held across a disconnect |
| `main` since [`9cc9e65`](https://github.com/pumasi-ai/pumasi-tunnel/commit/9cc9e65) | With `-reservations `, that claim outlives a relay restart. Off by default |
`Registry.PublicURL` no longer hard-codes a scheme (`core/route.go:311`); the
CLI's first line, the console link and the zero-install ssh banner all read the
one string, so they cannot fork again. **The merge is not the deployment.**
`pumasi.link` runs an older build and will until someone restarts it — and who
may restart that relay is open as `pumasi/DECISIONS.md` **Q-014**, because its
one live tunnel is the remote-access route to the host it runs on. The scheme
fix has a release note, `Q-020` in
[`DECISIONS.md`](https://github.com/pumasi-ai/pumasi/blob/main/DECISIONS.md),
whose own status row records the same thing. The two later merges have none
yet; `pumasi/releases/` carries one tunnel note, for `83fd9f7`.
So: if you build from `main` and run your own relay, you get the truth by
default, a name you can hold, and — with one flag — a name that survives your
own restarts. If you use `pumasi.link`, **treat every `https://` URL it hands
you as `http://`, treat every name as borrowed, and expect a restart to cost it**
until it is redeployed. TLS termination is deliberately outside the relay
either way (see *Architecture* below), and outside it there is at present
nothing.
**Nobody has promised this relay will be up.** One process, one host, no
durable state on the build that is running, no status page and no support
commitment — `Launched` is `PENDING` and production hardening is what that
gate means. If a tunnel mattering to you goes away with the relay, that is the
documented behaviour, not an incident. The relay you run yourself is the same
binary from the same repository, and that remains the supported way to depend
on it.
## What a token buys on `main`, and what it does not
Because *"a name that is yours"* invites three readings the code does not
support, and `spec/0004` §3 and §8 spell each one out:
- **Continuity, not identity.** There are no accounts. A token narrows which
name an accepted agent may have; `AllowAll` still accepts everyone. A
stranger who claims your name before you do has it — trust is on first use.
- **A bearer secret on a plaintext wire.** Until there is TLS in front of the
relay, the token travels readable and replayable between agent and relay.
The relay stores a `sha256` of it, never the token, and refuses anything
under 16 characters rather than downgrading it to anonymous.
- **The zero-install path cannot use it.** A stock `ssh -R` client has nowhere
to put a token, so an ssh tunnel can be *refused* a name somebody else has
claimed and can never claim or reclaim one. The command this page leads with
gets you a tunnel, not a stable name.
- **A lost token is a lost name.** No recovery path, because recovery needs an
identity to recover to. With `-reservations`, a claim nobody has used for
30 days is swept at the next load; the file caps at 10 000 claims and refuses
a *new* name at the cap, never an existing owner; a corrupt file starts the
relay empty, logs at `ERROR` and is moved aside rather than overwritten
(`spec/0004` §14).
None of that is true of `pumasi.link` today. It is what you get from a relay
you build at `9cc9e65` or later.
## Run it
Two binaries, one Go module, no dependencies outside the standard library and
`golang.org/x/crypto`.
```bash
git clone https://github.com/pumasi-ai/pumasi-tunnel
cd pumasi-tunnel && go test ./...
go build ./cmd/pumasi-relay ./cmd/pumasi-tunnel
```
**Against the public relay**, with no binary at all, from any machine with a
stock `ssh` client — the fastest way to see whether this is useful to you:
```bash
ssh -R 80:localhost:3000 -p 2222 pumasi.link
```
No download, no account, and it works from a machine you are not allowed to
install software on. **The relay on `pumasi.link` prints an `https://…` URL;
open the `http://` one instead**, for the reason above — the build running there
predates the fix. A relay you build from `main` today prints `http://` unless
you pass `-public-scheme=https`.
**Your own relay** — the public side. It accepts agents on one port and
visitors on another. The last flag is what makes a claim survive your own
restarts; leave it off and you have the relay `pumasi.link` runs:
```bash
./pumasi-relay -domain example.test -agent-addr :7000 -http-addr :8000 \
-ssh-addr :2222 -tcp-low 20000 -tcp-high 20100 \
-reservations /var/lib/pumasi-relay/reservations.json
```
**The agent** — on the machine holding the thing you want reachable:
```bash
# an HTTP app, published at .example.test
./pumasi-tunnel --relay relay.example:7000 8080
# ask for a particular name
./pumasi-tunnel --relay relay.example:7000 --subdomain myapi 8080
# hold that name: 16+ characters, and nobody else may have it while you are away
./pumasi-tunnel --relay relay.example:7000 --subdomain myapi --token "$(cat token)" 8080
# raw TCP: RDP, SSH, PostgreSQL. --tcp-port keeps the address across reconnects
./pumasi-tunnel --relay relay.example:7000 --tcp --tcp-port 20001 3389
```
## What works today, and what does not
Written against the code tree at
[`9cc9e65`](https://github.com/pumasi-ai/pumasi-tunnel/commit/9cc9e65) and the
running relay, not against the plan. Where the two columns of the truth differ,
the row says so.
| | State |
|---|---|
| Multiplexed transport — many streams over one outbound connection | **Built** (`mux/`, `core/frame.go`) |
| HTTP routing by subdomain, with a reserved-name list | **Built** (`core/route.go`, `core/subdomain.go`) |
| Raw TCP port pool, with a port that survives reconnects | **Built** (`relay/tcp.go`, `core/portpool.go`) |
| Zero-install ingress from a stock `ssh -R` client | **Built** (`relay/sshingress.go`) — and since `4489fbe` it can be refused a claimed name and cannot claim one |
| Relay console at the relay's own apex | **Built** (`relay/dashboard.go`, one embedded file) |
| **Public relay anyone can use** | **Running** at `pumasi.link` — `http` only, **no uptime promise**, on a build older than every row below |
| **`https://` on the address the relay prints** | **Not served.** Port 443 refused. The scheme half is merged (`83fd9f7`) and undeployed; the certificate half is not built |
| Ownership of a subdomain name and its port | **Built on `main`** (`4489fbe`, `core/reservation.go`) — **not on `pumasi.link`** |
| A claim that survives a relay restart | **Built on `main`** (`9cc9e65`, `core/reservationstore.go`, `-reservations`, off by default) — **not on `pumasi.link`**. A live connection never survives one |
| Announce only what is bound and served | **Fixed on `main`** (`1d9505c` TCP, `fd523e8` HTTP) — **not on `pumasi.link`** |
| A version number, anywhere | **Not built** — `PRODUCT-RULES.md` PR-1 |
| Local request inspector on `127.0.0.1:4040` | **Not built.** No code; `Beta` criterion |
| Wildcard TLS / ACME certificate management | **Not built, and deliberately out of the relay** — see below |
### One known weakness in the part that is built
The multiplexer's flow control is per-stream buffering, not a credit window. A
reader that stops reading stalls its own stream and, once the read loop blocks,
the connection behind it. That is honest backpressure rather than unbounded
memory, **but one stalled stream can hold up its siblings.** A credit window is
the fix and is deferred; the code says so at
[`mux/session.go`](https://github.com/pumasi-ai/pumasi-tunnel/blob/main/mux/session.go)
rather than leaving it to be discovered under load.
A second one this page used to carry is closed on `main` and open on the host:
the relay wrote the auth response carrying a tunnel's public TCP address
**before** it bound the listener, so the address was announced before anything
answered on it. Since `1d9505c` the bind comes first and a bind failure is the
answer to the handshake; since `fd523e8` the mux session exists before the URL
leaves. Both are frozen cases that fail without the fix. `pumasi.link` has
neither.
## Why the incumbents cost what they cost
The comparison that motivated building this. **Every competitor cell below is
read from that vendor's own page on 2026-08-31** and recorded, with its source
URL and fetch date, in `pumasi-tunnel`
[`roadmap/MARKET.md` §1](https://github.com/pumasi-ai/pumasi-tunnel/blob/main/roadmap/MARKET.md).
Where a vendor's page does not print something, the cell says *not printed*
rather than guessing — and the comparators are that file's three
([ngrok](https://ngrok.com/pricing), [Pinggy](https://pinggy.io/#pricing),
[LocalXpose](https://localxpose.io/pricing)), not a set chosen to flatter.
| | ngrok | Pinggy | LocalXpose | **Pumasi Tunnel** |
| :--- | :--- | :--- | :--- | :--- |
| **Entry price** | Free $0; Hobbyist **$10/mo**; Pay-as-you-go **$20/mo** + usage | Free $0; Pro **$3.00** (from Pinggy's own comparison page) | Starter $0; **PRO $8/mo** ($96/yr) | **$0.** `pumasi.link` is free; self-run, you pay for the host |
| **Account to start** | yes | **no**, on the free tier | yes | **no** |
| **Client to start** | own agent binary | **the OS `ssh` client** | own binary (CLI + GUI) | **stock `ssh`**, or one static binary |
| **Raw TCP on the free path** | with **credit-card verification**; a *reserved* address from $10/mo | **included** | **not included** — from $8/mo | **✅ included.** `pumasi.link` serves ports 20000–20099 |
| **Free-tier session ceiling** | **none printed** on the pricing page | **60 minutes** | **"Time limits"** | **✅ none** — nothing in the code expires a session |
| **Stable hostname** | free domain is ngrok-branded; custom at **$0.01/active hour** on PAYG | random on free; custom sold on Pro | excluded from Starter | free, on any relay — **held for a token holder on `main` since `4489fbe`, held for nobody on `pumasi.link`** |
| **Interstitial warning page** | not printed | not printed | **printed on Starter** | **✅ none** — the relay proxies, it does not inject |
| **HTTPS on the public URL** | ✅ | ✅ | ✅ | ❌ **`http` only** — 443 refused on `pumasi.link`. The *scheme* half is merged (`83fd9f7`, undeployed); the certificate half is not built |
| **Self-hostable relay** | not offered publicly | on-premise on **Enterprise** | not offered publicly | **✅ Apache-2.0, same repository** |
| **Local request inspector** | port 4040 | web dashboard | — | ❌ **not built** (`Beta` criterion) |
| **Uptime commitment** | paid SLA | none on free | not printed | ❌ **none, stated** — one host |
**What that table establishes, stated no wider than the citations allow.** Two
things are together free here and together free nowhere above: **raw TCP and a
session that does not end.** Pinggy gives free TCP and times you out at 60
minutes; LocalXpose sells both from $8/month; ngrok wants a card on file for
free TCP and $10/month for a reserved address. Nothing here is a claim about
reliability, performance, support or security posture — none of which was
measured — and nothing should be restated as "ngrok costs $10" without the plan
name attached.
The unmetered and no-timeout rows are true for a reason worth stating plainly:
they are not a generous tier, they are the absence of the code that would
enforce a tier. Nothing in this repository counts bytes or clocks a session, so
there is nothing to lift when you self-host.
### Where this comparison goes against us
A table that only flatters its own product is copy, not evidence.
`MARKET.md` §4 records three counts against, and they belong on this page too:
- **They have TLS and we do not.** All three sell `https://` URLs as the
ordinary case. `pumasi.link` has never listened on 443. A webhook sender that
requires `https://` can use all three of them and none of us.
- **They have accounts and ownership; we have neither on the relay you can
reach.** A paid stable hostname is only a wedge if ours is *owned*. On
`pumasi.link` it is not: `AllowAll` is the only authenticator and every name
is unclaimed, so "free stable name" there means "free unclaimed name", which
is a weaker product, not a cheaper one. On `main` a token holds a name — and
the section above says the three ways that is still less than an account.
- **One relay, one host.** Every vendor above runs an edge. This runs on one
$5–6/month machine in Chicago. Nothing above is an availability claim.
**The one that will decide it for many readers:** if your use is a webhook
sender that requires an `https://` destination, this cannot serve you today, on
the public relay or on your own, until a certificate sits in front of a relay
started with `-public-scheme=https`.
## Architecture
A single outbound connection from your machine to the relay, carrying every
inbound visitor request back down it as a separate stream. No port forwarding
and no inbound firewall rule.
- **Core (`core/`)** — pure: the wire frame protocol, host routing, subdomain
validation, the TCP port pool, the reservation set and, since `9cc9e65`, the
file it can be written to. No network I/O, so it is unit-testable on its own.
- **Mux (`mux/`)** — the I/O shell that moves those frames. A hand-written
frame protocol over a plain connection; **not QUIC, and not Yamux.** The
split from core is deliberate: core decides what bytes mean, `mux` moves them.
- **Relay (`relay/`)** — HTTP host router, raw TCP port allocator, SSH ingress
gateway, and the embedded console. One static binary, droppable on a host.
- **Agent (`agent/`)** — holds the outbound connection and forwards frames to
the local port.
**TLS is deliberately not terminated in the relay.** Run it behind a TLS
listener or a reverse proxy holding the certificate; keeping certificate
handling out means an operator can choose ACME, a purchased certificate, or
none at all on a private network. The relay entrypoint says exactly this at
[`cmd/pumasi-relay/main.go`](https://github.com/pumasi-ai/pumasi-tunnel/blob/main/cmd/pumasi-relay/main.go).
It is a design decision, not a missing feature. The defect was never that the
relay declines to terminate TLS — it was that it **announced** a scheme it
cannot see and does not serve. On `main` that is fixed: the operator states the
scheme with `-public-scheme` and the relay repeats it rather than guessing. On
`pumasi.link` it is not yet deployed, so nothing is standing in that place and
the relay still says otherwise.
**No database.** Routing is in-memory for the lifetime of a session, and a live
tunnel is a connection, which nothing persists. What `main` persists since
`9cc9e65` — only when `-reservations` names a file — is the *claim*: name,
port, a hash of the token and a last-seen time, one JSON document rewritten
whole on every change. The public relay does not run that build, so on
`pumasi.link` there is still no reservation that survives a relay restart.
---
# Why does sending a 500KB PDF cost $45 a month? The DocuSign tax and pure-edge stamping
URL: https://pumasi.ai/blog/the-docusign-tax-and-pure-edge-stamping/
Markdown: https://pumasi.ai/blog/the-docusign-tax-and-pure-edge-stamping.md
Published: 2026-08-30
DocuSign's own page prices Business Pro at $45/user/mo and meters 100 envelopes/user/yr. How pure TypeScript stamping and Cloudflare Durable Objects make contract execution an unmetered commodity.
Sending an agreement and collecting a signed PDF is computationally trivial: place vector ink or typed text at designated coordinates, compute a cryptographic digest, and store the resulting 500KB file.
Yet incumbents have turned this basic computer science primitive into one of the most aggressive tollbooths in enterprise software.
---
## 1. The Incumbent Business Model: Artificial Scarcity
DocuSign does not sell compute or storage. It sells **artificial envelope scarcity**.
```
┌─────────────────────────────────────────────────────────┐
│ THE $7,200/YEAR DOCUSIGN TOLLBOOTH │
│ 20 Employees · Standard plan · annual billing │
│ Figures read from DocuSign's own page, 2026-08-31 │
└───────────────────────────┬─────────────────────────────┘
│
┌───────────────────────────────────┼───────────────────────────────────┐
▼ ▼ ▼
┌───────────────────────┐ ┌───────────────────────┐ ┌───────────────────────┐
│ Per-Seat Tax │ │ Envelope Metering │ │ Above Business Pro │
│ $30 – $45 / user / mo │ │ 100 envelopes / user │ │ "Enhanced Plans" │
│ Standard · Bus. Pro │ │ / year, both plans │ │ price not published — │
│ ($7,200–$10,800 / yr) │ │ Personal: 5 / month │ │ "contact sales" │
└───────────────────────┘ └───────────────────────┘ └───────────────────────┘
```
### What Businesses Actually Pay
Let us look at published pricing vs. the real invoices small-to-medium businesses face:
| Provider | Published Tier (Per User) | Monthly Allowance | Gated Features | Annual Cost (20 Users) |
| :--- | :--- | :--- | :--- | :--- |
| **DocuSign** ([Pricing](https://ecom.docusign.com/plans-and-pricing/esignature), read 2026-08-31) | **$30 – $45** / user / mo (Standard, Business Pro; annual billing) | **100 envelopes / user / yr**, as shown on both plans | Reusable templates, signer attachments, SSO gated to Enterprise | **$7,200 – $10,800** / yr |
| **Pumasi Sign** ([pumasi.ai](https://pumasi.ai/products/pumasi-sign/)) | **$0.00 (Unmetered)** | **Unlimited Envelopes** | **All features included · Custom Branding.** Licence: the repository carries no `LICENSE` file yet — see the product page | **$0.00 / yr** |
**On the sourcing of that table, because it has been corrected twice.** The
DocuSign row was re-read from the vendor's own pricing page on **2026-08-31**
and matches `pumasi-sign`
[`roadmap/MARKET.md` §1](https://github.com/pumasi-ai/pumasi-sign/blob/main/roadmap/MARKET.md);
it previously read "$25 – $40", which was wrong at both ends.
**This table used to carry an Adobe Sign row and a PandaDoc row. They have been
removed rather than restated.** They held this post's original figures, which
nobody here had read from either vendor. Neither vendor appears in any product
repository's `MARKET.md`, so there was no owned source to check them against,
and on **2026-08-31** both vendors' own pricing pages refused to serve us a
price: `adobe.com/sign/pricing.html` returned no response body over repeated
requests, and `pandadoc.com/pricing/` answered `HTTP 429` behind a JavaScript
bot challenge. An unread number is not a weaker citation than a read one; it is
not a citation. The two annual columns derived from those rows are gone with
them, because arithmetic on an unverified figure reads as more precise than its
input, not less.
The measured reason to distrust the dropped rows is the row beside them: the
DocuSign figures of exactly that provenance were wrong at **both** ends when
someone finally opened the page. Prices move, and the date is part of the
claim.
When a growing business hires 5 new team members on the Standard plan, their
e-signature bill increases by $150 per month — even if those employees send one
offer letter a quarter.
---
## 2. Why Incumbents Claim It Must Be Expensive
Incumbents justify these fees with two claims:
1. *"Legal compliance is complex and requires specialized proprietary infrastructure."*
2. *"Document rendering and PDF manipulation require heavy server compute."*
Both claims are historically outdated.
### The Legal Reality: ESIGN and eIDAS
Under the US **Electronic Signatures in Global and National Commerce Act** ([15 U.S.C. § 7001](https://www.law.cornell.edu/uscode/text/15/7001)) and the European Union's **eIDAS Regulation** ([Regulation (EU) No 910/2014](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv:OJ.L_.2014.257.01.0073.01.ENG)), an electronic signature is legally binding if four requirements are satisfied:
1. **Intent to Sign**: Demonstrable physical or digital action affirming agreement.
2. **Consent to Electronic Records**: Notice and affirmative acceptance to do business electronically.
3. **Association of Signature with Record**: The signature data must be deterministically stamped and tethered to the exact document bytes.
4. **Tamper-Evident Retention**: An audit certificate recording timestamps, IP addresses, user agents, and cryptographic digests proving the document was not altered post-execution.
None of these requirements require a $45/user/month per-seat subscription. They require standard cryptography (`SHA-256`) and deterministic coordinate geometry.
---
## 3. The Technical Breakthrough: Pure Edge PDF Stamping
Legacy e-signature architectures run heavy virtual machines executing Python or headless LibreOffice instances to flatten and rasterize PDFs. This creates massive operational overhead and cold starts.
In **Pumasi Sign**, document stamping is implemented as a **pure TypeScript / WebAssembly engine** running entirely inside Cloudflare V8 worker isolates:
```
┌────────────────────────────────────────────────────────────────────────────────────────┐
│ PUMASI SIGN: PURE EDGE ARCHITECTURE │
├────────────────────────────────────────────────────────────────────────────────────────┤
│ │
│ [ Client Browser ] │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────────────────────────────────────────────────┐ │
│ │ Cloudflare Edge Worker (sign.pumasi.ai) │ │
│ │ │ │
│ │ 1. Normalized Coordinate Geometry: │ │
│ │ (x_page, y_page) = (x_rel · PageWidth_pt, (1 - y_rel) · PageHeight_pt) │ │
│ │ │ │
│ │ 2. In-Memory Vector Stamping (pdf-lib / V8 Isolate): │ │
│ │ • Embeds high-res PNG / SVG vector ink directly │ │
│ │ • Appends Cryptographic Signature Certificate Page │ │
│ │ │ │
│ │ 3. SHA-256 Cryptographic Audit Proof: │ │
│ │ • Hash_original = SHA256(Raw_Upload_Bytes) │ │
│ │ • Hash_completed = SHA256(Stamped_Output_Bytes) │ │
│ │ │ │
│ │ 4. Transactional SQLite Storage (Durable Objects): │ │
│ │ • Envelope state, multi-signer tokens, audit logs, binary PDF blobs │ │
│ └──────────────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ [ Tamper-Evident Executed PDF with Audit Trail (Instant Download) ] │
│ │
└────────────────────────────────────────────────────────────────────────────────────────┘
```
### The Math: Normalized Coordinates Across Dynamic Viewports
Different devices render PDF pages at different scale factors. Mobile phones, Retina displays, and 4K monitors have distinct CSS pixel densities.
Pumasi Sign avoids coordinate drift by computing all field placements in **normalized unit intervals** `[0.0, 1.0]` relative to the page's intrinsic PDF points (`72 points per inch`):
$$\text{PDF}_x = x_{\text{norm}} \times \text{PageWidth}_{\text{points}}$$
$$\text{PDF}_y = (1.0 - y_{\text{norm}} - h_{\text{norm}}) \times \text{PageHeight}_{\text{points}}$$
Because the coordinate translation is a pure mathematical projection, the resulting stamped vector signature aligns with sub-millimeter precision regardless of whether the document was signed on an iPhone or an ultrawide desktop.
---
## 4. Architectural Comparison: Legacy SaaS vs. Cloudflare Edge
| Architectural Layer | Legacy Incumbent Stack | Pumasi Sign Edge Stack |
| :--- | :--- | :--- |
| **Runtime Environment** | Dedicated Kubernetes clusters with Node/Python/LibreOffice | Cloudflare V8 Worker Isolates (<5ms cold start) |
| **PDF Manipulation** | Forked background C++ processes & rasterizers | In-isolate TypeScript vector stamping (`pdf-lib`) |
| **State & Storage** | AWS RDS PostgreSQL + S3 Buckets (high egress cost) | Embedded SQLite in Cloudflare Durable Objects + Cloudflare R2 |
| **Multi-Tenancy** | Complex organization schemas with gated features | Instant workspace provisioning with customizable branding |
| **Operational Cost** | High fixed monthly server & database infrastructure | Fractional token & edge invocation cost ($0 at scale) |
---
## 5. Software as an Unmetered Commons
When the infrastructure cost of executing an agreement drops to near zero, the business model must change.
Pumasi Sign has no envelope meters, no per-seat paywalls, and no gated
features. It is **not yet licensed**: as of **2026-08-31** the repository
carries no `LICENSE` file on its default branch — checked with
`gh api repos/pumasi-ai/pumasi-sign/contents/LICENSE`, which returns `404`, and
neither its `package.json` nor its README declares one. Read the source and run
it, but until that file lands nobody here has granted you a licence to it:
- Run it locally or self-host on your own Cloudflare account: `git clone https://github.com/pumasi-ai/pumasi-sign && npx wrangler deploy`.
- Use the public commons deployment at [**https://sign.pumasi.ai**](https://sign.pumasi.ai) with your own custom branding.
Contracts and agreements should record trust between counterparties—not pay a tax to a software tollbooth.
---
# The per-seat tax on hiring hourly workers
URL: https://pumasi.ai/blog/the-per-seat-tax/
Markdown: https://pumasi.ai/blog/the-per-seat-tax.md
Published: 2026-08-29
Updated: 2026-08-29
Shift scheduling is billed per employee, so the bill rises with every hire whether or not scheduling changed. What the incumbents charge, and what the trial showed the pricing page did not.
Staff shift scheduling is sold per employee per month. That sounds unremarkable
until you notice what it means for the businesses that need it most: a
restaurant that hires four people for the summer pays more for scheduling
software in July, having changed nothing about how it schedules.
The bill is indexed to headcount. The work is not.
## What it costs today
**When I Work** publishes $2.50 per user per month for Essentials, $5 for Pro,
and $8 for Premium, with API access, webhooks and SAML/SSO gated to the top
tier — the SSO tax, applied to a rota tool
([wheniwork.com/pricing](https://wheniwork.com/pricing), checked 2026-08-29).
**Deputy** publishes $5 for Lite, $6.50 for Core and $9 for Pro per user per
month, plus paid add-ons: HR at $2, Messaging+ at $1.95, Analytics+ at $1.50,
all per user per month, over a $30 monthly minimum. The whole structure was
rearranged in October 2025
([deputy.com/pricing](https://www.deputy.com/pricing);
[RosterElf's 2026 review](https://www.rosterelf.com/reviews/deputy);
[ITQlick on Deputy's hidden costs](https://www.itqlick.com/deputy/pricing)).
For a thirty-person restaurant on Deputy Core with HR and Messaging+, that is a
little over $310 a month to answer the question *who is working Thursday*.
| Platform | Base Pricing (Per User) | Gated Add-ons & Surcharges | Monthly Bill (30 Seats) | Annual Bill |
| :--- | :--- | :--- | :--- | :--- |
| **When I Work** | $2.50 – $8.00 / user / mo | SAML/SSO & API gated to Premium | $75.00 – $240.00 / mo | $900 – $2,880 / yr |
| **Deputy** | $5.00 – $9.00 / user / mo | +$2.00 HR, +$1.95 Messaging, +$1.50 Analytics | $313.50 / mo | $3,762 / yr |
| **Homebase** | $24.95 – $99.95 / location | +$3.00/user over limit + Payroll fees | $99.95 – $199.95 / mo | $1,200 – $2,400 / yr |
| **Pumasi Commons** | **$0.00 (Unmetered)** | **Zero per-seat tax · Free Forever · Apache-2.0** | **$0.00 / mo** | **$0.00 / yr** |
## The public page and the trial disagree
Here is the part worth the trial fee.
Pumasi's evidence for a candidate is not allowed to rest on an incumbent's
marketing pages. A candidate whose incumbent has not been toured **signed in**
is marked *provisional* and cannot hold a settled score. On 2026-08-29 the
steward provisioned a fourteen-day When I Work trial and toured it: sixty-five
screenshots, signup through to admin.
The in-app plan picker did not match the public pricing page. Inside the trial
there are **two** plans, not three — $2.50 per user per month for a single
location and $5.00 for multiple locations — each bundling scheduling, time
tracking and attendance, and messaging together.
And one-click **auto-scheduling is included at $2.50**, against the reasonable
assumption, formed from the outside, that the clever feature would be the thing
behind the paywall.
It is not. The paywall is **location count**.
That correction matters more than it looks. It moves the incumbent's real moat
from "we have the good algorithm" to "we charge you for growing," which is a
much weaker position to defend and a much clearer thing to build against. It
also did not move the candidate's score by a single point — the demand and the
resentment were already scored correctly. The tour bought *accuracy*, not a
different answer.
## The resentment is the pricing model itself
The complaint volume is not about features. It is about the meter.
There is an entire content genre of *"alternatives that don't charge per
employee"*
([one example](https://www.deelo.ai/blog/deputy-alternatives-small-business-2026)),
which is what a market looks like when the pricing model, rather than the
product, is what people want to escape.
Meanwhile the open-source field is dead or mislabelled. Staffjoy, the one
venture-backed open-source attempt, shut down and deprecated its repository in
September 2019 ([github.com/Staffjoy/v2](https://github.com/Staffjoy/v2)). The
"best open-source scheduling" roundups are reduced to listing TimeTrex — an
open-core payroll suite, not a rota tool — and OptaPlanner, a constraint solver,
which is a library and not a product
([SelectHub](https://www.selecthub.com/employee-scheduling/open-source-employee-scheduling-software/),
[People Managing People](https://peoplemanagingpeople.com/tools/best-open-source-employee-scheduling-software/)).
So: proven demand, a public per-seat price, documented resentment aimed squarely
at the meter, and no living open-source alternative. That is close to the
definition of what this commons exists to copy, and it is why staff shift
scheduling currently sits at the top of the
[public backlog](https://github.com/pumasi-ai/pumasi-product-hunt) with a settled
score of 45 out of 50.
## What the copy would have to get right
The tour was clear about where the product actually lives, and it is not the
scheduling algorithm.
The heartbeat is **draft → Publish & Notify**. The scheduler is a week grid by
person; edits accumulate as drafts with a change count; publishing notifies every
affected employee, and republishing notifies them again. Everything else in the
product orbits that moment.
A first version without integrations can still hit it: publish a read-only page
plus an ICS feed, and treat *"what changed since the last publish"* as a
first-class object rather than a diff computed at send time.
Underneath, approvals turn out to be one state machine reused three times —
shift requests, time-off requests, and open-shift claims. Pure, cheap, and
central to daily use. Attendance and timesheets are a genuinely separate second
product bundled into the price, and a first version should say so and leave them
out.
None of that is hard. It is just nobody's job, which is the whole problem this
commons exists to fix.
---
*Figures checked 2026-08-29 against the linked sources and one signed-in trial.
Prices move; the date is part of the claim. Pumasi studies incumbent behaviour,
never expression — no incompatibly licensed code is read while a competing
implementation is being written.*
---
# The six scheduling traps that catch AI coders (and how multi-model review caught them)
URL: https://pumasi.ai/blog/the-six-scheduling-traps-that-catch-ai-coders/
Markdown: https://pumasi.ai/blog/the-six-scheduling-traps-that-catch-ai-coders.md
Published: 2026-08-29
Scheduling looks simple until you hit timezones, DST boundaries, and concurrency. Here are the six subtle failure modes caught during the construction of Pumasi Booking.
Ask any modern LLM to write a meeting scheduler, and it will give you a clean, plausible-looking TypeScript function in five seconds. It will define `getAvailableSlots()`, iterate over start and end hours, and return an array of ISO 8601 strings.
And in production, that function will quietly double-book your calendar, drop an hour during daylight saving time, or lock out attendees across international timezones.
When we built [`@pumasi/booking-core`](https://github.com/pumasi-ai/pumasi-booking/tree/main/core), we didn't rely on a single model's confidence. We used **heterogeneous cross-family review** (Claude, Gemini, and Grok reviewing each other's work) backed by frozen acceptance suites.
Here are the six subtle traps that were caught and fixed along the way.
---
## 1. The Spring-Forward Gap: Two Hours, Not Three
When a timezone springs forward (e.g. 02:00 skips directly to 03:00):
* A naive loop generating slots between 01:00 and 04:00 will generate three 60-minute slots: `01:00-02:00`, `02:00-03:00`, and `03:00-04:00`.
* But in local wall-clock time, **02:00 to 03:00 does not exist.** The interval between 01:00 and 04:00 is only **two absolute hours long**.
Generating a slot during the missing hour means offering a time that physically cannot occur. In `@pumasi/booking-core`, invalid local times are skipped loudly with explicit diagnostics rather than silently shifted to the next valid hour.
---
## 2. The Fall-Back Ambiguity: Both Occurrences Must Be Bookable
In autumn, wall clocks repeat an hour (e.g. 01:00 to 02:00 happens twice).
* A 3-hour window spanning the repeated hour contains **four elapsed hours**, not three.
* Naive code often deduplicates slots based on string matching (e.g., matching `"01:00"`), which silently deletes the second valid hour from availability.
The engine represents time in unambiguous UTC instants paired with the owner's IANA timezone, ensuring both occurrences in the transition window can be booked independently.
---
## 3. Daily Booking Caps Must Count on the Owner's Local Date
If an organizer sets a limit of *"maximum 3 bookings per day"*:
* Suppose a booker in Tokyo (UTC+9) schedules a meeting with an organizer in San Francisco (UTC-7).
* In Tokyo, the meeting is on Tuesday morning. In San Francisco, it is still Monday afternoon.
Which day's cap does the meeting consume?
**It must count toward the owner's local date.** If the cap evaluates in UTC or the requester's timezone, an organizer can receive 6 meetings on a Monday because the requests straddled midnight in other parts of the world.
---
## 4. The Cancellation-Replay Trap
During early specification review, an adversary model identified three clauses that were jointly impossible to satisfy:
1. *Replaying an idempotency key returns the original booking result.*
2. *A user can cancel a booking, releasing the slot back to the public pool.*
3. *A third party can subsequently book the released interval.*
If Party B books the released slot, and Party A then resends their original booking request with their original idempotency key, what happens?
* If the server returns the original success result, it falsely claims Party A holds a slot that Party B now occupies.
* If the server rejects the replay, it violates idempotency.
The resolution: idempotency keys bind strictly to an active, non-canceled booking lifecycle. Replaying an idempotency key for a cancelled or superseded reservation returns a distinct `RESERVATION_SUPERSEDED` state, preventing ghost confirmation states.
---
## 5. Vacuous Acceptance Tests (Tests That Cannot Fail)
During review under [`lessons/L-006`](https://github.com/pumasi-ai/pumasi/blob/main/lessons/L-006-tests-that-cannot-fail.md), we discovered an acceptance test designed to check concurrency conflicts.
The test spawned two parallel booking requests and asserted:
```typescript
if (responseA.status === 200 && responseB.status === 200) {
assert.fail("Both bookings succeeded concurrently");
}
```
If the test environment ran sequentially (one request completed before the second began), `responseB` failed normally with a standard slot conflict, the `if` condition evaluated to `false`, and the test passed — **without ever actually asserting that the database exclusion constraint fired.**
The fix: acceptance tests must assert both the positive assertion on winner *and* the specific error code (`CONCURRENCY_CONFLICT` / `EXCLUSION_VIOLATION`) on the loser, ensuring no test can pass vacuously.
---
## 6. Double-Booking Prevention Belongs Inside the Database
Many SaaS booking engines attempt to prevent double-booking in application code:
```typescript
// DANGEROUS: Classic Check-Then-Act Race Condition
const isBusy = await db.checkOverlap(timeSlot);
if (!isBusy) {
await db.insertBooking(timeSlot);
}
```
Under high concurrency, two simultaneous requests will both pass `checkOverlap()` before either executes `insertBooking()`.
In Pumasi Booking, concurrency guarantees are enforced **inside the database engine**:
* **PostgreSQL Build**: Enforced with a `btree_gist` temporal exclusion constraint (`EXCLUDE USING gist (organizer_id WITH =, booked_range WITH &&)`).
* **Cloudflare Workers / SQLite Build**: Enforced with atomic `BEFORE INSERT` and `BEFORE UPDATE` SQL triggers raising `ABORT`.
Application code can crash, restart, or scale across ten distributed instances; the database write lock guarantees that two overlapping bookings can never commit simultaneously.
---
## Why Multi-Model Review Matters
Every single one of these six traps was caught not by proofreading, but by having **competing LLM architectures attack each other's designs** before implementation.
When an AI writes code, it is confident even when it is wrong. Putting heterogeneous reviewers and frozen acceptance tests between the prompt and the `main` branch is how you turn generative AI into reliable open-source infrastructure.
---
# Why we show the seams: building in the open before the product is stable
URL: https://pumasi.ai/blog/why-we-show-the-seams-building-an-unstable-product-in-the-open/
Markdown: https://pumasi.ai/blog/why-we-show-the-seams-building-an-unstable-product-in-the-open.md
Published: 2026-08-29
Why we publish the open debts, list the limitations at the top of the page, and test on the pure engine first. Written at seed stage; Pumasi Booking is beta now, and a dated note says so.
Most software projects wait until they feel polished before opening their doors. They scrub their issue trackers, draft aspirational marketing copy, and quietly paper over edge cases. When something breaks, it is treated as a surprise.
We are taking the opposite approach with **Pumasi Booking**.
The product is in **seed stage**, under active construction, and not yet stable. If you deploy it expecting a mature, five-year-old enterprise SaaS replacement today, you will find edges that are still being sanded down.
Instead of hiding those seams, we put them at the very top of the page. Here is why.
> **Update, 2026-08-31.** The stage sentence above was true the day this was
> published and is no longer. Pumasi Booking's
> [`STAGE.md`](https://github.com/pumasi-ai/pumasi-booking/blob/main/roadmap/STAGE.md)
> has said **`beta`** since 2026-08-29 — strangers can rely on it, the known
> gaps are listed, data survives — and it is re-justified at each release
> evaluation rather than left to drift. The argument below is unchanged; only
> the label moved. The current stage, and the limitations that come with it,
> are on the [product page](/products/pumasi-booking/), which is the surface
> that tracks the roadmap. This post is left as it was written rather than
> quietly edited, because a dated argument that gets retconned is worth less
> than one that carries its own correction.
---
## 1. The limitation comes before the feature list
Every product page in the Pumasi catalog follows a strict rule: **the first thing you read is what the software cannot do yet.**
For Pumasi Booking, the top of the page does not boast about AI-native workflows or frictionless booking. It states plainly:
> *Limitation: no lawyer has reviewed its privacy pack, and no standard contractual clauses cover its US transfer position — the legal pages it serves say so on their face.*
If you are evaluating software for your organization, your first question is not *"what is the happy path?"* — it is *"will this break my compliance, drop a customer meeting, or corrupt data under concurrency?"* An honest project answers that question before you spend twenty minutes setting it up.
---
## 2. A debt register is better than a marketing promise
In [`governance/DEBT.md`](https://github.com/pumasi-ai/pumasi/blob/main/governance/DEBT.md), we track every single operational and architectural rule we are running below right now:
* **D-105**: The lawful basis is written in `service/src/legal.ts`, but an international transfer mechanism and a formal review by legal counsel remain open.
* **D-108**: Telemetry egress is currently disabled in code (`PUMASI_REPORTING` is read into config and read by nothing), meaning our multi-environment verification matrix is currently one machine wide.
* **D-104**: Multi-model reviewer availability fluctuates, and we report the exact live count rather than asserting that three families are always active.
A project that runs below its own rules quietly is worse than one with no rules at all, because it sells a guarantee it is not providing. Publishing debt is how we keep ourselves honest while the software matures.
---
## 3. The core engine is pure, testable, and separable
While the full service layer (HTTP, auth, sessions, SQLite/PostgreSQL connectors) is being hardened, the computational core underneath it — [`@pumasi/booking-core`](https://github.com/pumasi-ai/pumasi-booking/tree/main/core) — is already rock solid.
Availability calculation and slot allocation is implemented as a **pure mathematical function**:
* **No clock**: Time is an explicit parameter, not an ambient system call.
* **No I/O**: No network requests or database queries happen inside slot computation.
* **No mutable state**: Same inputs yield byte-identical outputs across any runtime.
Because of this boundary, you don't have to trust our full web stack to use the engine. You can extract the engine alone with full Git history in one command:
```bash
git subtree split --prefix=core -b engine-only
```
You get a pure TypeScript availability calculator with frozen acceptance tests covering spring-forward DST transitions, cross-timezone boundaries, and buffer interactions — free to embed into your own backend.
---
## 4. How to help during the seed phase
If you want to try Pumasi Booking today:
1. **Run the pure test suite**: Clone the repo and run `npm test`. Check whether the acceptance cases in `core/spec/acceptance/cases.json` hold for your timezone and locale.
2. **Test local self-hosting**: Spin up `docker compose up` and test connecting your Google or Microsoft calendar in testing mode.
3. **File structural bugs**: If you find an edge case where a timezone transition or booking buffer produces an invalid slot, file an issue. In our process, a bug report isn't a support ticket — it becomes a permanent, numbered acceptance case in our test matrix.
We are building a commons meant to last decades. Starting with radical honesty about what is not yet finished is the only foundation that makes "built once, well, to serve everyone forever" credible.
---