SpaceWorks 0.7.5

[Shaan-Shoukath]

Merges 66 commits from dev. Merging this publishes a release — release.yml fires on main, and VERSION changed, so it will build and push spaceworks-backend / spaceworks-frontend images to ghcr and publish a GitHub Release titled SpaceWorks 0.7.5.

What's in it

Events program (four phases) — cross-makerspace collaborative events with host-waiver acceptance, QR check-in, opt-in attended-events on the maker profile, and registration decoupled from presence (presence is now proven at the door by the staff-scanned QR rather than a self-declared session).

Module-architecture program — operator-facing module groups, one module map per staff tab, payments/accounts/mobile/updates keys, Razorpay behind a provider seam, a superadmin modules console, cloud/full deploy profiles, the account-less identity seam with staff-created walk-in members, four platform login-method switches, maker profiles and a member directory, and staff-side event registration.

Notifications v2 — per-event recipient selection, per-room chat destinations, editable email/chat wording, and object-scoped recipient rules.

Plus scoped PII encryption, custom per-makerspace roles, machine-scoped MANAGE_MACHINES, and an accessibility floor (contrast guard, focus indicators, skip links).

Release mechanics

• VERSION 0.5.1 → 0.7.5
• The OpenAPI document version now tracks VERSION — it had been pinned at 0.1.0 while VERSION climbed to 0.5.1, so every schema consumer was told a version that had never been true. A test now fails if the two drift.
• Release titles are SpaceWorks <version> instead of v<version>. The immutable tag keeps its v<base>-main.<run>.<sha> form.
• CHANGELOG.md gains a 0.7.5 section. Note 0.3.0–0.5.1 were never recorded — generation stopped after 0.2.0 — so that window points at git log instead of inventing entries.

Review

The final commit closes four rounds of codex exec review on the events program. Each round found a defect the previous one missed, all the same shape — money or access in a state transition happening later than the code assumed:

1. A collaborator purging events stranded host-raised charges: a receipt vanished and a pending charge became unpayable.
2. The collaborative registration route bypassed the configured rate limit; the naive fix would have 429'd the only path a member has to repair a missing waiver acceptance.
3. A cancelled registration is reactivated rather than treated as a duplicate, so counting it as a "retry" reopened the bypass on a larger budget.
4. Check-in reported waiver evidence from only one of the two places it can live, so it was structurally false for every host member.

Round 4 returned no actionable defects.

Verification

Backend suite green against the seven known pre-existing failures, each verified by reason rather than name. Tombstone suite 140, vitest 76, tsc -b clean, migration drift clean. New regression tests were each confirmed to fail when the bug they guard is reintroduced.

QA

End-to-end QA signed off by the repository owner (@Shaan-Shoukath). Recorded here as the owner's attestation — it was not performed or observed by the automated review, which covered the test suites, static checks and the build only.

Automated verification for the record: backend suite green against the seven known pre-existing failures (each confirmed by failure reason, not name), tombstone suite 140, vitest 76, tsc -b clean, migration drift clean. Each new regression test was confirmed to fail when the bug it guards is reintroduced.

Known open item — follow-up in progress

A host purging events still deletes visiting members' charges: module_purge._purge removes every host-owned event payment, including one routed to a visitor's own space, so a paid receipt is destroyed and a pending debt silently vanishes.

This predates the PR and is being fixed separately on fix/purge-preserves-visiting-member-payments — no module purge will delete a payment at all, and a subject_label snapshot on Payment keeps a surviving receipt readable.

Correction to an earlier version of this note: it claimed a subject-less pending charge would still be payable. That is false. Payment.save() calls full_clean() unconditionally and Payment.clean() requires the subject row to exist, so every write path — hosted checkout, mobile intent, offline reconciliation, and webhook settlement — fails once the subject is gone. Read paths degrade safely; write paths do not. Making clean() tolerate a missing subject on an otherwise-unchanged existing payment is therefore part of the fix, not an optimisation.

🤖 Generated with Claude Code