Social and icons. A 1200x630 card, apple-touch-icon, and maskable PWA icons,
generated from an HTML template by a script so the mark, wordmark and tagline
cannot drift from the product. The apple-touch-icon referenced in index.html
was a 404 until now. Icons are drawn on an opaque plate with inset because iOS
rounds corners and Android may apply a circle — an edge-to-edge mark loses its
ears to that crop. og:image is absolute, which is the single most common
reason a card unfurls blank.
PIG_INVITE_CODE was a lie. Signup validates against the invites table, so
setting the variable only flipped a label in the UI — an operator would set it,
hand the code to a colleague, and watch them be rejected. It is now reconciled
into a real invite row at boot: setting it issues, changing it rotates and
revokes the predecessor, and removing it revokes. Verified all three, plus that
a restart with an unchanged code does not duplicate.
Two bugs found while doing that:
- `uses_remaining` was jsonb, so the SQL decrement could never have worked.
Now integer. The generated migration failed because Postgres has no implicit
jsonb->integer cast, so the USING clause is hand-written.
- Redemption keyed off `redeemedAt`, which would have made every reusable
invite single-use — a confusing way to lock a team out. Availability now
comes from `usesRemaining`, and redemption records who used it most recently
without consuming it.
Sign-in gains a password option alongside the magic link, defaulting to
password since that is the daily path. PIG stores neither; both are handled by
the identity provider and PIG only ever sees the resulting token.
autocomplete is set so password managers and iOS can fill.
Verified: full migration chain applies to a fresh Postgres, the CSP hash for
the inline theme script is unchanged by the rebuild.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
PIG is an agent-native CRM for two-sided AI-compute companies: businesses
that buy GPU capacity from providers and resell it. Their business is the
spread between two pipelines, which is precisely what a generic CRM cannot
represent.
The load-bearing decision is the `allocations` table, joining a
capacity_commitment (what we bought, at a known cost) to a demand_deal
(what we sold, at a known price). Margin, utilisation and idle capacity all
fall out of that one join. Cost is charged against the full commitment
rather than only the hours that sold, because unsold hours are already paid
for and any other treatment flatters a block that is losing money.
Domain decisions worth noting, each grounded in how this market operates:
- Demand stages put `legal` second, not last. Customers do not hand
workloads to an infrastructure provider before paper is executed.
- Supply qualification splits technical from financial diligence, recorded
attributably. Accepting capacity is a two-key decision.
- Capacity carries a time SHAPE (intervals + quantities), not a window.
Commitments ramp and step down; a rectangle reports availability that
does not exist in the month someone wants it.
- SLAs model three distinct shapes: none, a reliability tier plus credits
policy, and a negotiated agreement. Aggregators generally cannot promise
uptime on resold capacity, but negotiate heavyweight paper upstream.
Remedies include fee abatement, which is materially better than a capped
credit and is not expressible as one.
- Export control is a predicate on the allocation edge, evaluated against
the ULTIMATE parent's jurisdiction. Country of incorporation is not a
valid key, so this cannot live as a flag on an account.
- Agent-derived claims land in `facts` with a confidence band and evidence.
Only verified claims self-apply; weaker ones await review.
- The API never calls the agent. It writes to a leased queue, guarded by a
partial unique index on unfinished work.
Verified: typechecks clean, migration generates and applies to Postgres 16
(31 tables, 24 enums, 117 indexes).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
karti