PIG/pig

Files

T

karti c747eb2aa7 Add deployment: Dockerfile, compose, proxy config, and docs

One container plus a Postgres behind any TLS-terminating proxy. Nothing is
specific to a particular host.

The app and API are served from a SINGLE origin. This is not tidiness: browser
auth sessions live in per-origin storage, so splitting them across two
hostnames makes sign-in loop in a way that presents as a server fault. The
short alias redirects rather than serving a second origin.

Two safety properties verified by running the image, not by reading the code:

- With NODE_ENV=production and no SUPABASE_URL, the process refuses to start
  and says why. Serving the whole CRM unauthenticated is a worse outcome than
  failing to deploy, so the failure is deliberate and loud.
- In production the development auth bypass does not apply: an unauthenticated
  request to /api/dashboard returns 401 rather than adopting the first user in
  the table.

The Dockerfile typechecks all six packages as a build gate, so a deploy that
does not compile fails at build time rather than in front of a user. Runtime
runs unprivileged as `node`, and Postgres is not published to the host.

Docs cover the ontology and why it is shaped this way, agent connection for
Claude Code / Codex / prime-agent / Buzz, and the provenance rules governing
seed data about real people — including how to have your record removed.

Verified: image builds, container reports healthy, serves the SPA, enforces
auth, and the production guard exits non-zero.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

2026-08-12 19:19:53 -07:00

2.2 KiB

Raw Blame History

Seed data and its provenance

PIG ships with a roster of publicly documented people so the application is legible on first run. It is public research, not an assertion of fact.

Rules applied

Every record carries a confidence grade and a source URL. confirmed means two or more independent sources; probable means one good one; unverified means a single weak or self-reported source. The grade is shown in the interface wherever the record appears — a single-source claim about a real person must never look as solid as a corroborated one.
No email addresses. None are published by the subjects. Guessing them from a name and a domain is unreliable, and when a guess lands it lands on a real person who did not ask to be contacted.
Authorship is not employment. People named on papers or in repositories are recorded with the affiliation actually evidenced — contributor, resident, alumni — never promoted to staff to make the roster look fuller.
"Not found" is recorded, not invented. Where a name was supplied but could not be sourced, it appears in UNRESOLVED_NAMES with a note. Absence is weak evidence: a junior or deliberately non-public employee looks identical to a failed search.

Known limitations

Sourced August 2026. It will go stale — that is what sourceUrl is for.
LinkedIn, Glassdoor and several job boards refuse automated fetching, so some records rest on search-result summaries rather than a page that was read end to end. Those are graded accordingly.
One departure is recorded explicitly (a co-author who now lists a different company) so the roster does not quietly imply current employment.
One name in the original brief could not be tied to the company by any source and is deliberately not seeded.

Removing yourself

If you are seeded here and would rather not be, open an issue and the record will be removed. Deleting a contact in the application also removes it permanently.

Turning it off

Seeding is a separate command and is never automatic:

npm run db:seed     # opt in

Skip it and PIG starts empty apart from a development user.

2.2 KiB Raw Blame History