M1: complete the data model and the isolation model

[os-sam]

Lands backlog cards 04 (candidate domain), 05 (transaction domain) and 06 (security), completing M1. These three are the serial bottleneck of the backlog — nothing else could be dispatched in parallel until they landed.

Gates

pnpm validate   ✓  11 Objects · 129 Fields · 5 Positions · 6 Permissions
pnpm lint       ✓  All checks passed — no errors, warnings or suggestions
pnpm typecheck  ✓  tsc --noEmit

The decision this PR settles

DESIGN.md said an employer-side row is visible when the caller is an active ats_employer_member of that row's employer. RLS cannot express that: predicates are canonical CEL comparing a field to a current_user.* placeholder, and cross-object traversal is a compile error (ADR-0055).

Resolved as employer = platform organization. Employer-side objects carry a denormalised employer_org scalar, and the policies read:

employer_org IN (current_user.accessible_org_ids)

accessible_org_ids (ADR-0105 D2) is the caller's whole org access set rather than the single active org, so a recruiter placed at two employers sees both without switching context. A caller with no membership resolves to the empty set, which fails the policy closed — zero rows, never fail-open.

The objects deliberately do not set tenancy: { enabled: true }. That wall is absolute and org-equality based, so it would also hide a job seeker's own application from them — the seeker is not a member of the employer's organization. Business RLS lets the two audiences carry different policies over the same rows, which is exactly the marketplace shape.

Recorded in DESIGN.md §03 with the rejected alternatives and why.

Two gate findings worth reading

security-owd-* — an allowRead grant on a private object without a readScope is owner-only. A recruiter would not have seen an application a colleague created; the pipeline would have been a set of private inboxes rather than a shared board. Fixed with readScope: 'org' (plus writeScope where the set edits). Composition order is the point: OWD sets the baseline, the scope widens it, RLS is the boundary that actually holds.

hook-body/not-lowerable — sharing helper functions across handlers stops the hooks from lowering to metadata-only bodies, so the app would ship a bundled closure instead of pure metadata. That is a change of deployment shape, and this app's whole claim is that it is metadata. Every handler is now self-contained; the repetition is the cheaper side of that trade.

Neither was visible by reading the diff. Both were caught by the gates.

What changed

Candidate domain — ats_candidate (owned by the candidate; contact and salary-expectation fields are the ones §03 masks) and ats_candidate_credential (is_expiring compares against daysFromNow(90) rather than doing date arithmetic, which faults the build).

Transaction domain — ats_application (pipeline spine; unique index on (job, candidate), roll-up interview_count), ats_interview (related list, not inline line items), ats_offer (the employer's own internal approval lives in status), ats_report (polymorphic target rather than four nullable lookups).

Security — 5 positions, 6 permission sets, RLS and FLS per §03, position↔set bindings on kernel:bootstrapped (they cannot be a seed: the seed loader runs before the security bootstrap creates the rows it would reference), and the stamp hooks.

The stamps are load-bearing for security, not convenience: an unstamped row makes its policy drop out, and the pipeline reads as empty. employer and employer_org on an application come from the job, never from the incoming payload — otherwise a caller could file an application into another employer's scope.

Follow-up, not in this PR

Org provisioning on employer onboarding (sys_organization + sys_member) is seeded in M1 and belongs to flow F1; noted in DESIGN.md §03 and on card 11.

🤖 Generated with Claude Code

https://claude.ai/code/session_01PbJ5Cy9KDAzeQHo8bsMadG