Rebuild the shell, add Calendar and Learn, and govern reads

Seven parallel agents and an adversarial verification pass. The three things
worth knowing before reading the diff:

RBAC WAS ALREADY BUILT. docs/build-plan.md marks F2 and F3 outstanding and is
stale — packages/core/src/permissions.ts and lib/mutation.ts shipped long ago.
So this does not rebuild them; it closes the gaps an audit found. The big one
is that reads were entirely ungoverned: every GET was "any authenticated
member", so a junior demand rep and a research contractor could both pull
per-block supplier cost and break-even prices from /api/capacity/margin, and
every contract's negotiated terms. For a company whose margin is the business,
that was the hole that mattered. Adds book:read / economics:read / team:read,
a readGuard middleware, and a `viewer` role below member.

THE BUTTON AND THE 403 DISAGREED — the exact thing F3 said must never happen.
Contracts.tsx never called can() at all, so its save button was always enabled
against a server requiring contract:sign; Capacity.tsx gated commitment
creation on deal:write/demand while the server wanted commitment:write/supply.

POST /api/activities was the one write bypassing executeMutation: no capability
check, and any member could mutate accounts.lastActivityAt as a side effect.
It is now a proper mutation() behind activity:write.

The shell becomes three panes — a collapsible shadcn sidebar with an account
switcher on the Piggy accent, a header with real search, and Piggy docked to
the right, page-aware and persistent across navigation. The phone keeps its
bottom tab bar, which is the thing this product already beat trycompai/crm on,
and gains the sidebar as a sheet.

Calendar is a projection over thirteen dated sources rather than a new table,
because a table would duplicate dates that already live on contracts, deals and
commitments and would drift — and one ledger answering the question is the
whole argument. It surfaces export_authorizations and compliance_artifacts,
which had indexed expires_at columns, schema comments saying they must be
alerted on, and no read endpoint or UI anywhere.

Learn carries two tracks. Concepts are members-only; the platform track can be
opened with a share code by someone with no account. The code mints a scoped
learn-only token and never a Principal — every route here resolves a principal
and then checks capabilities, so a principal-minting code would be one missing
check away from leaking the book. "Only platform-track rows may be code-visible"
is a database CHECK constraint as well as a write-path rule, and a test asserts
a valid learn token still gets 401 on /api/dashboard, /api/accounts and
/api/contracts — the same invariant scripts/deploy.sh refuses to ship without.

CD becomes tag-to-ship. CI publishes an image to the Gitea registry on a
release-* tag and cloud-2 pulls it, so no credential on the shared runner can
execute anything on production — by construction rather than by policy. Both
halves of deploy.sh's original rule survive: nothing on the runner reaches the
host, and a human still decides when it ships. deploy.sh gains a rollback and a
public-origin check, and PIG_IMAGE now reaches compose through `sudo env`,
without which sudo's env_reset silently resolved every release to pig:local.

Tests 141 -> 261.

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

apps/api/test/auth.test.ts

@@ -1,20 +1,13 @@
 import { strict as assert } from 'node:assert';
 import { describe, it } from 'node:test';
-import type { Principal } from '../src/lib/auth';
-import { AuthError, effectivePermissions, requireCapability } from '../src/lib/auth';
-
-function principal(overrides: Partial<Principal> = {}): Principal {
-  return {
-    userId: '00000000-0000-0000-0000-000000000001',
-    email: 'seller@example.com',
-    name: 'Seller',
-    isPlatformAdmin: false,
-    teams: [{ team: 'demand', role: 'member' }],
-    via: 'jwt',
-    scopes: ['read', 'write'],
-    ...overrides,
-  };
-}
+import {
+  AuthError,
+  effectivePermissions,
+  requireAnyTeamCapability,
+  requireCapability,
+  requireReadCapability,
+} from '../src/lib/auth';
+import { onTeam, principal } from './helpers/principal';
 
 describe('capability enforcement', () => {
   it('rejects a role grant from the wrong team', () => {
@@ -24,13 +17,78 @@ describe('capability enforcement', () => {
     );
   });
 
-  it('removes write grants from a read-only API key', () => {
+  it('removes write grants from a read-only API key but keeps its reads', () => {
     const readOnly = principal({ via: 'api_key', scopes: ['read'] });
 
-    assert.deepEqual(effectivePermissions(readOnly), []);
+    // The point of a read-only key. Before read capabilities existed this
+    // resolved to nothing at all, which was right then and would now tell the
+    // front end that a reader may not read.
+    assert.deepEqual(
+      effectivePermissions(readOnly).map((grant) => grant.capability),
+      ['book:read', 'economics:read', 'team:read'],
+    );
     assert.throws(
       () => requireCapability(readOnly, 'deal:write', 'demand'),
       (error: unknown) => error instanceof AuthError && error.code === 'insufficient_scope',
     );
   });
+
+  it('grants no reads to a write-only credential', () => {
+    const writeOnly = principal({ via: 'api_key', scopes: ['write'] });
+
+    assert.throws(
+      () => requireReadCapability(writeOnly, 'economics:read'),
+      (error: unknown) => error instanceof AuthError && error.code === 'insufficient_scope',
+    );
+  });
+
+  it('keeps supplier economics away from research, whatever their rank', () => {
+    const researchAdmin = principal(onTeam('research', 'admin'));
+
+    requireReadCapability(researchAdmin, 'book:read');
+    assert.throws(
+      () => requireReadCapability(researchAdmin, 'economics:read'),
+      (error: unknown) => error instanceof AuthError && error.code === 'insufficient_permission',
+    );
+  });
+
+  it('gives a viewer the book and nothing that writes to it', () => {
+    const viewer = principal(onTeam('demand', 'viewer'));
+
+    requireReadCapability(viewer, 'book:read');
+    requireReadCapability(viewer, 'team:read');
+    for (const capability of ['deal:write', 'activity:write'] as const) {
+      assert.throws(
+        () => requireCapability(viewer, capability, 'demand'),
+        (error: unknown) => error instanceof AuthError && error.code === 'insufficient_permission',
+        `viewer should not hold ${capability}`,
+      );
+    }
+  });
+
+  /**
+   * The bug this pins: `requireCapability(p, 'data:import')` with no team
+   * passed if the principal held it anywhere, so a research-team admin could
+   * rewrite the demand pipeline. The overload no longer accepts a team-scoped
+   * capability without a team; the any-team question has to be asked by name.
+   */
+  it('separates "holds it here" from "holds it somewhere"', () => {
+    const researchAdmin = principal(onTeam('research', 'admin'));
+
+    requireAnyTeamCapability(researchAdmin, 'data:import');
+    assert.throws(
+      () => requireCapability(researchAdmin, 'data:import', 'demand'),
+      (error: unknown) => error instanceof AuthError && error.code === 'insufficient_permission',
+    );
+  });
+
+  it('will not let fact review borrow bulk-import authority', () => {
+    const demandAdmin = principal(onTeam('demand', 'admin'));
+
+    requireCapability(demandAdmin, 'data:import', 'demand');
+    assert.throws(
+      () => requireAnyTeamCapability(demandAdmin, 'fact:review'),
+      (error: unknown) => error instanceof AuthError && error.code === 'insufficient_permission',
+    );
+  });
 });