Products
What the Pumasi commons has actually built, what each product replaces, and — stated first — what each one cannot do yet.
Everything the commons has built is below, and nothing it has not. There are no
coming-soon cards and no roadmap entries on this page: a product gets a card
when there is something you can run, and each card states what it cannot do yet
before it states what it does.
The licence differs by product, and this page will not average them. A
licence is an outward grant a stranger may rely on, so it is quoted from the
repository that would have to honour it rather than asserted for the set.
pumasi-tunnel carries an Apache-2.0 LICENSE file. pumasi-booking and
pumasi-sign carry none on their default branch — gh api repos/pumasi-ai/<repo>/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,
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,
ranked by a scored rubric, and the reasoning stays on the record.
beta
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.
Instead of Calendly, Cal.com
Not yet: the public booking page on booking.pumasi.ai shows no times to book, and a stranger meets that before anything else on this card. Measured first-hand 2026-09-01: GET https://booking.pumasi.ai/yunyoungmok/abc answered 200, 45 407 bytes, at 05:21:07 UTC, carrying 24 slots in its own #slots-data — and the render() in those very bytes builds a button for each one and appends none. times is cleared (times.textContent='') and queried (times.querySelectorAll) and never appended to; the five appendChild calls on that page all belong to other elements. Driven in headless Chrome at 05:21:26 UTC in America/Chicago: day cells 1 and 2 render as available, the heading reads Tuesday, September 1, #times.children.length is 0, and nothing is thrown — zero pageerror, zero console errors. So a day the calendar offers is a day with an empty list under it, silently, and a booking page that cannot show a time cannot take a booking. It was filed from the live product at 2026-09-01 00:36:56 UTC, repaired at d7bd490, and not deployed: /version answered {"version":"0.2.0","commit":"2453adc"} at 05:20:31 UTC and the repair is not in that build. That is pumasi/DECISIONS.md Q-038, whose own row records a window closing 2026-09-08. Separately, nobody has yet measured a reminder, follow-up or webhook actually being delivered on booking.pumasi.ai. The repaired timer deployed 2026-09-01 00:40:44 UTC, so the code is on the worker — but delivery is unverified, and an organisation that has booked nothing since then may have no alarm armed at all. When a queue does drain, work overdue since 2026-08-28 is sent late rather than skipped. The repository is still ahead of the deployment and nothing carries one to the other. And the subprocessor register that host serves is short by one party. Re-measured by this card 2026-09-01 05:20:31 UTC: /version answers 2453adc, /subprocessors (200, 34 663 bytes) names five parties and no sixth, and that build sends Zoom the booker's name and email address on any booking for an event type whose location is Zoom (service/src/app.ts:3524 and :3528 at 2453adc). main names Zoom Video Communications, Inc. since c000feb; the deployment does not, and nothing carries the correction across — pumasi/DECISIONS.md Q-012 and Q-036, both open, and neither this page's to answer. Beware the obvious check: grep -ic zoom on that page returns 4, and all four are page presentation — three the pf-shot-zoom-hint class (two stylesheet rules and one class= on a screenshot caption) and one style="cursor:zoom-in;" on a preview image; grep -io "zoom video" is the test, and at 05:20:31 UTC it returned nothing. Separately, 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.
alpha
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.
Instead of DocuSign, SignWell
Not yet: two defects are live on sign.pumasi.ai as this is written, both repaired in main and neither deployed. Re-measured on the live hosts and the deployed tree 2026-09-01 05:20:32–05:22:52 UTC, at this seat's own clock rather than carried from an earlier one; the served root still loads /assets/index-CnoFAC2c.js, the fingerprint STAGE.md §2.2 maps to the deployed tree 0e26917, and wrangler.jsonc ships the worker and frontend/dist as one artefact. (1) The correct expiration & reminders pencil silently deletes the covering note you wrote to your signers. The served EnvelopeDetailView-C4VlFBtA.js PATCHes exactly three fields — expires_at, reminders_enabled, reminder_interval_days — never message, then reports Envelope settings updated.; at 0e26917 durable.ts:1211 writes NULL to message on any body that omits it. Messages already deleted are gone — the release note says so in the sender's own words, and the deployed tree stores no prior value to read back: the UPDATE overwrites the column and the corrected audit row at durable.ts:1214 carries no details_json. Repaired at 9659e69, release note — Q-037, and the window that entry's own row records closes 2026-09-08. (2) An expiration date does nothing. The served ExternalSignView-CmDSqiPb.js carries four closed-envelope cases and no expired one, and at 0e26917 there is no crons key, no scheduled export and no expires_at write on that route — so nothing expires, and the only refusal is client-side, in SignView-BM1dkPaZ.js, beside a source comment (SignView.vue:480 at 0e26917) claiming the server rejects /complete the same way when at that commit it does not. Repaired at 2471a29, release note — Q-035, and the window that entry's own row records closes 2026-09-08. Both are merged and undeployed, and this page does not claim either has shipped: nobody owns deployment — pumasi/DECISIONS.md Q-012, open, and outside CHARTER Part 0's proceed-on-default rule. Separately, this product's own front page went live on 2026-09-01 and it tells a stranger, three times, that the code is under Apache-2.0 — and the repository grants no licence at all. Measured on the served landing chunk /assets/LandingView-C5khdw3s.js (200, 10 046 bytes, re-fetched 2026-09-01 05:22:14 UTC): Apache-2.0 appears in the hero strip, in the stage banner, and in a comparison-table row headed License & Source Code whose neighbouring columns both read Proprietary Closed Source — a row that invites a reader to choose this product because of terms that do not exist. Against that, gh api repos/pumasi-ai/pumasi-sign/contents/LICENSE returned 404 at 2026-09-01 05:22:52 UTC — the contents API, which is the check that answers whether the file exists, rather than the licenseInfo field, which has been wrong about this organisation before, and 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. Which way that resolves is the steward's, open as pumasi/DECISIONS.md Q-021, and this page states no licence until it lands — it reports the deployed page's claim rather than repeating it. The entry-path defect this card warned about for two days is gone. Issue #7 — sign in again handed the user a page of raw JSON — was closed 2026-09-01T00:59:12Z, and the repair reached users in the deploy at 2026-09-01 01:02:16 UTC; verified on the live host rather than on the tracker, the button now builds /login?next=%2F, which answers 200 text/html. And the audit certificates verify document integrity, signer identity and UTC timestamps under the ESIGN Act and eIDAS, but Qualified Electronic Signatures (QES) requiring national hardware smartcards are not included.
alpha
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.
Instead of Ngrok, Pinggy, LocalXpose
Not yet: there is a public relay — on pumasi.link — but it serves http only, and the relay running there still announces https://<name>.pumasi.link addresses with nothing listening on port 443 (checked 2026-09-01 19:12 UTC). The fix is merged and undeployed: since 83fd9f7 main takes -public-scheme and defaults to http, but pumasi.link runs an older build — deploying it needs pumasi/DECISIONS.md Q-014, which is open. tunnel.pumasi.ai does not resolve at all. One relay, one host, and nobody has promised it will be up. On pumasi.link a name still belongs to nobody and a restart still drops every name, every port and every live tunnel. Both are fixed on main and in the same merged-and-undeployed state as the scheme: a name and its port belong to a token holder since 4489fbe, and a reservation outlives a relay restart since 9cc9e65 — when the operator passes -reservations <path>, which is off by default. Even deployed, no live connection survives a restart; what survives is the address the reconnect gets back. The local request inspector on port 4040 and wildcard TLS are Beta criteria with no implementation in the repository today.
