invite-audit

name

invite-audit

description

Use when the wizteros invitation set needs checking — the four per-tier baseline links, their expiry, their scope, or whether the 03:00 rotation is still running. Triggers include "audit the invitations", "check the invite links", "are the baseline invites still good", "why is there no bronze link", "did the invite rotation run", "these invites never expire", or a Wizarr invitation grid that looks wrong. Read-only: it reports and never creates, deletes, or edits an invite. Only applies to the wizteros repo.

Invitation audit

Overview

The invitation set has two populations that must never be confused.

Baseline invites are the four multi-use links — one per tier — handed to prospective members. The bridge mints them and rotates them daily at 03:00 (stripe_bridge/baseline.py, driven by _baseline_loop). They are the only invites this skill judges.

Member invites are minted per checkout by the webhook handler, single-use, tied to one buyer. They are listed for context and are none of this skill's business.

Ownership is recorded, not inferred: every code the bridge mints is written to baseline_invites in bridge.db. That table is the sole definition of "ours", which is what makes the rotation safe to run unattended — a member's checkout invite cannot appear in it, so it can never be reaped.

Nothing here mutates. The audit script only reads; rotation happens in the bridge on the NAS. The remedies below are either a bridge deploy or a deliberate click in Wizarr by a human.

Running it

node --env-file=.env .claude/skills/invite-audit/scripts/audit-invites.mjs

Run it from the repo root. Needs WIZARR_BASE_URL and WIZARR_API_KEY, plus SSH key auth to the NAS and sudo -n /usr/local/bin/docker there to read baseline_invites. .env is gitignored, so whether one exists is a property of the working copy: use it when present, otherwise point --env-file at whatever file holds the values.

Exit code is 1 when there are findings, 0 when clean, 2 on a config or connection failure. WZ_NAS_HOST (default crivas@192.168.50.2) points at another NAS.

The bridge-store section is the one that degrades: without it the script cannot tell a baseline from a stray, so it says so and nothing below that line is conclusive. Treat that as "audit did not run", not "audit found nothing".

The rules being checked

Rule	Why
Four tiers always live	bronze, gold, silver, youth each need a redeemable link
Every baseline has an expiry	a leaked link that never expires is redeemable forever
Scope is Meleys alone	tiers.py retires the other servers from signups
Downloads follow the tier	only gold and youth may download
Newest baseline < 26h old	proves the 03:00 rotation is still running

Scope is judged on server_names, never specific_libraries. Wizarr's invitation serializer reports specific_libraries: [] even for a correctly scoped invite, so that field cannot tell a scoped invite from an unscoped one. Do not "fix" an invite because that array looks empty.

Case 1: a tier has no live baseline invite

Dossier. bronze none live, and the other tiers may be fine.

The floor is four, and two generations normally overlap, so a single missing tier means minting failed for that tier specifically — not that rotation is down.

• Scope broke. Check the bridge logs for baseline: skipping <tier> or no libraries resolved. A Plex library rename narrows or empties a tier, and tier_scope_problems then refuses to mint rather than issue an empty invite. This is the same root cause as case 4 in member-triage, and it breaks checkouts too, so fix it there: correct the library name on Plex or update tiers.py, run bun run refresh:libraries and bun run test:bridge, then deploy.
• Wizarr rejected the create. A traceback under baseline: minting <tier> failed. Usually auth or a Wizarr upgrade changing the payload.

Remedy. Fix the cause, then wait for 03:00 or restart the bridge container to get a rotation on the next cycle. Do not hand-create a replacement in Wizarr: it would not be recorded in baseline_invites, so it would show up as a stray forever and never rotate.

Case 2: a baseline invite never expires

Dossier. [NO EXPIRY] against a bridge-minted code.

The rotation always passes expires_in_days, so a bridge-minted invite with a null expiry means someone cleared it by hand in Wizarr, or the invite predates the rotation.

Remedy. Leave it. The next rotation mints a replacement, and this one is reaped once its recorded expires_at passes. Deleting it by hand is safe but pointless — and if you do, the audit will report a missing tier until 03:00.

Case 3: strays — unlimited invites the bridge did not mint

Dossier. A Strays section with codes, usually expires NEVER and naming retired servers.

This is the expected finding on any stack that ran before the rotation existed. The four original baseline invites (1PYO3B8VPQ, F30UFPPXOV, KYJZKJRGVZ, VPWG3JK2PS, minted 2026-07-16) are exactly this: never-expiring, and scoped to Vermithor, Vhagar, Caraxes, and Syrax — servers tiers.py says "must never be granted again". Anyone redeeming one gets access the tier rules forbid.

Remedy. Delete them in the Wizarr UI once the rotation has produced its replacements — confirm four tiers show live first, then delete. The audit will never delete a stray for you, because it cannot prove a stray is not something you created deliberately. That judgment is yours.

Case 4: rotation has stopped

Dossier. Findings say the newest baseline for a tier is older than 26 hours, usually across all four at once.

• Bridge is down or was restarted repeatedly. _baseline_loop deliberately does not rotate at boot — a restart loop would otherwise mint a fresh set every time the container came up — so a bridge that keeps restarting never reaches 03:00.
• The deployed bridge predates the rotation. The audit says the baseline_invites table is absent. GET /version against the NAS, compare with __version__, and deploy.

Remedy. bun run deploy:nas (or the deploy-nas skill), then confirm with GET /version. Netlify does not carry the bridge; the NAS only updates when told.

Case 5: a baseline grants more than Meleys

Dossier. [SCOPE Meleys,Syrax,Vermithor] on a bridge-minted code.

This should be impossible: the rotation derives scope from tiers.resolve_tier_access, which filters to SHARE_SERVER. Seeing it on a bridge-minted invite means either someone edited the invite in Wizarr, or SHARE_SERVER changed without the retired-server comment being revisited.

Remedy. Read tiers.py:9-14 first and decide which is true. If a server is being un-retired that is a tier-rules change with tests behind it, not an invite fix.

Where each remedy happens

Remedy	Where
Fix a tier's library set	tiers.py + Plex library names, then refresh:libraries, test, deploy
Ship the rotation to the NAS	bun run deploy:nas, confirm GET /version
Force a rotation now	restart the bridge container and wait for 03:00, or wait a day
Delete a stray invite	Wizarr UI, by hand, after confirming replacements exist
Change the rotation hour	BASELINE_ROTATE_HOUR in the NAS .env, then rebuild
Change the link lifetime	BASELINE_EXPIRES_DAYS (default 2), same

Reporting back

Lead with whether the four-tier floor currently holds, since that is the only finding a prospective member can actually feel. Then the specific broken invites, then the one remedy and who presses it.

Say plainly when a finding is systemic rather than per-invite: a tier that cannot resolve breaks every future checkout for that tier, not just its baseline link.

If the bridge-store section was unavailable, say so and stop short of conclusions — without it, baseline and stray are indistinguishable.

Red flags

• Never hand-create a "replacement" baseline invite in Wizarr. It will not be in baseline_invites, so it will never rotate and will read as a stray forever.
• Never delete a stray on the audit's say-so alone. It cannot know what you created on purpose.
• Never judge scope by specific_libraries — it is [] on correctly scoped invites.
• A missing expiry on a member invite is not this skill's problem; member invites are governed by INVITE_EXPIRES_DAYS and diagnosed with member-triage.
• Do not lower BASELINE_EXPIRES_DAYS to 1 "so links die sooner". At 1 day the overlap disappears and a link shared minutes before 03:00 dies almost immediately.