karti
a6167629cc
The monorepo was on npm workspaces. pnpm gives it a content-addressed store shared between the eight packages, a lockfile that records the whole graph rather than a flattened view of it, and — the reason this mattered in practice — `workspace:*`, which makes an internal dependency unambiguous instead of a version range that npm may satisfy from the registry. Mechanics: - `packageManager: pnpm@11.21.0` pins the version; corepack installs it in CI and in the image, so all three environments resolve identically. - The npm `workspaces` array is replaced by `pnpm-workspace.yaml`. pnpm ignores the former, and keeping both would leave two sources of truth. - All six internal dependencies moved to `workspace:*`. - Root scripts use `pnpm -r --if-present` and `pnpm -F <pkg>`. Two findings worth recording, both from running it rather than reading it: `tsx` was a devDependency, but the server runs TypeScript directly in production — the container's command is `pnpm exec tsx apps/api/src/server.ts`. Under npm this was concealed by the runtime stage re-installing tsx by hand after pruning dev dependencies. Under `pnpm install --prod` that sleight of hand stops working and the image simply fails to start. tsx is now declared in `dependencies`, which is what it has always actually been. The first image build failed with ERR_PNPM_ABORTED_REMOVE_MODULES_DIR_NO_TTY. That is not a pnpm bug: it had decided the modules directory was stale and wanted confirmation before deleting it, which a non-interactive build cannot give. The trigger was the host's `node_modules` reaching the build context — there was no `.dockerignore` at all. pnpm's tree is symlinks into a content-addressed store, so copying it into an image produces dangling links and a directory pnpm rightly considers corrupt. Fixed by adding `.dockerignore` and setting `CI=true`, which is required in any non-interactive pnpm build. `esbuild` is denied install scripts via `allowBuilds`. Its platform binary arrives through the optional dependency `@esbuild/linux-x64` and the postinstall only verifies it; confirmed by running the binary directly, which reports 0.25.12. Verified under pnpm: typecheck clean, 150 tests / 0 failures, e2e passes, web builds. The image was built and booted against a real Postgres — health ok, `/api/dashboard` 401 with an issuer configured, `/` and `/capacity` serve the SPA, `/og.png` serves as image/png, and the migrator runs from the pruned runtime stage. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
3.2 KiB
Connecting an agent
PIG is a first-class application for agents. The same MCP server serves every client, so nobody is asked to use a different tool than the one they already work in.
What connects
| Client | How |
|---|---|
| Claude Code | claude mcp add pig -- npx -y @pig/mcp |
| Codex | Add PIG as an MCP server in its config, with the same env vars |
| prime-agent | It is an MCP client; add PIG through /mcp |
| Buzz | Agents reach PIG through the ACP bridge's MCP support |
Setup
Create an API key in PIG under Settings → API keys, then:
export PIG_URL=https://primeintellectgrowth.com
export PIG_API_KEY=pig_...
Scope the key to read unless the agent genuinely needs to write. An agent
acting for you is a separate principal from you: it has its own audit trail
and can be revoked without disturbing your session, and it can never reach
further than you can.
CLI
The pig CLI is the HTTP API surface for scripts and Prime Agent kernels. It
never receives database credentials and has no arbitrary-request, shell, or
filesystem command. Configure it separately from the MCP process:
export PIG_API_URL=https://primeintellectgrowth.com
export PIG_API_KEY=pig_...
pnpm run pig -- me
pnpm run pig -- --json capacity idle --threshold 0.2
pnpm run pig -- --json capacity search --gpu-type H100_80GB --min-gpu-count 8
--api-url and --api-key override the environment for one invocation. In
--json mode success writes one JSON value to stdout, while failures write one
JSON error to stderr and exit non-zero. The key is sent only as a bearer token
and is redacted if an upstream error happens to echo it.
The tools
| Tool | What it answers |
|---|---|
pig_whoami |
Who am I acting for, and which teams am I on? |
pig_my_pipeline |
Where are we? What needs attention? |
pig_capacity_match |
What have we bought that would serve this customer? |
pig_margin_report |
What is each block earning against what it cost? |
pig_idle_capacity |
What are we paying for and not selling? |
pig_inventory_search |
What could we buy to cover demand we cannot serve? |
pig_search |
Find an account |
pig_get_account |
Everything about one account |
pig_log_activity |
Record a call, meeting or note |
pig_capacity_match is the one worth learning. Ask it in plain language:
"A customer wants 128 H100s with InfiniBand for three months, ceiling $2.80 per GPU-hour. What have we got?"
It returns ranked matches, preferring blocks that are sitting idle — those hours are already paid for — and warns explicitly when a match would sell below break-even.
Why the surface is small
Nine tools, each doing one thing. A sprawling tool list measurably degrades
model performance, and anything genuinely niche is reachable through
pig_search or the HTTP API. If you need something that is not here, it is
probably better added as a service method than as a tenth tool.
What it cannot do
The MCP server holds an API key and calls the same HTTP API a browser does. It has no database credentials and no privileged path. There is deliberately no tool that provisions infrastructure, spends money, or emails a customer.