Field.user columns render the raw user id in every grid — ats_employer.owner shows usr_ats_*, not a name

[os-sam]

Fixes #67.

ats_employer gains a stored owner_name mirror of the primary contact's sys_user.name, stamped
on write by a new ats_employer_stamp hook, and the reviewer's grid slot (highlightFields, the
authored ats_employer.all columns) names the mirror instead of the pointer. The owner pointer is
untouched and stays authoritative — the F1 approval still notifies record.owner.

Read this first: the card's only comment argues against this approach

The triage comment on #67 calls the mirror "the wrong fix twice over" — denormalising past a
visibility rule, and going stale — and explicitly declines to dispatch, saying the choice belongs to
the maintainer. This PR was dispatched on a decision taken off-card, with two premises attached, and
those premises were re-measured here before any code was touched. The first objection does not
survive the measurement; the second is real and is bounded in code. Both are set out below so the
merge decision is made against the evidence, not against my summary of it.

The two premises, re-measured on a booted server

Both drivers, demo seed complete (818 rows, errored: 0), counts read from the top-level
records / total with hasMore == false and records.length == total asserted first. Full
numbers and method: docs/evidence/issue-67/README.md.

1. No platform persona can read an employer-staff sys_user row — CONFIRMED, and stronger than
stated.

Persona	sys_user readable	of the 30 employer-staff rows
admin@platform.example	1 of 113	0
ops@platform.example	1 of 113	0
admin@objectos.ai (platform owner)	113 of 113	30

Each platform persona reads exactly its own row. The premise as dispatched said 83 of 113; that was
the card's triage measurement on 54cd69c. The refusal to expand ats_employer.owner is therefore
correct, and this PR does not widen any read.

That drift is not cosmetic and it is wider than this card — every Field.user column in the app now
renders a bare id to a platform persona, including ats_candidate.user, which the triage measured
expanding correctly. Measured and filed separately as #82.

2. The name is already in this audience's hands — CONFIRMED, for the platform audience only.

Persona	ats_employer_member readable	rows carrying a name
platform administrator	30 of 30	30
platform operations	30 of 30	30
job seeker	403 PERMISSION_DENIED	—

ats_employer_member.display_name reads Margaret Ellison · admin for all 12 contacts, to both
platform personas, on both drivers. For that audience the mirror restates a fact they hold, which is
what disposes of the "denormalising past the boundary" objection. For the job seeker it does not
— and that is the first defect the WIP had.

What I changed in the WIP, and why

The branch started at ec15479, a commit whose own message says nothing in it was verified. Three
things were wrong; the design bound (name only, no e-mail, no phone; pointer stays authoritative)
held up and is kept.

1. The mirror was readable to job seekers. src/security/permission-sets.ts

Field-level security in this repo is a deny-list, so a new field is readable to every persona that
can read the object. Measured on the WIP as saved, as candidate01@mail.example:

seeker reads 9 verified employers
owner_name = "Margaret Ellison", "Walter Brandt", …      <- all 12 contact names
GET /api/v1/data/ats_employer_member -> 403 PERMISSION_DENIED

The seeker holds no ats_employer_member row, so for them the name was new information — a
rendering repair for 2 reviewers would have disclosed 12 contact names to 80 seeker accounts, which
the pointer it replaces never did (they read it as an opaque usr_ats_*, and it stays that way).
Sealed in JobSeekerSet the way verification_note is. After the seal, measured on both drivers:

platform admin / ops   owner_name readable        (this is the card)
employer admin         owner_name readable, own employer only, 1 row
recruiter              owner_name readable, own employer only, 1 row
job seeker             owner_name absent, 0 of 9 rows; owner pointer unchanged

2. input.owner ?? prev.owner resurrected a removed contact. src/hooks/stamp.hook.ts

?? treats an explicit owner: null as absent, so clearing the primary contact left the previous
person's name in the reviewer's column. Measured on the WIP: PATCH {"owner": null} gave
owner = null, owner_name = "Walter Brandt". Now the handler reads previous only when the
payload omits owner entirely, and clears the mirror when the pointer is cleared — an insert with
no contact writes nothing rather than an explicit null. Measured after the fix: both null.

3. The e-mail fallback lookup was dead code resting on a false premise.

The WIP tried findOne({ id }) then findOne({ email }), commented "seeds address users by their
external id (email)". Two measurements say otherwise: the engine refuses a Field.user value that
is not an existing sys_user id —

PATCH {"owner":"admin@harborline.example"} -> 400 VALIDATION_FAILED / reference_not_found
PATCH {"owner":"usr_nope_missing"}         -> 400 VALIDATION_FAILED / reference_not_found

— and the seeder resolves its externalId reference before hooks run, which is why the neighbouring
member stamp, whose lookup has only ever been by id, titles all 30 seeded rows with real names from
a seed that addresses users by e-mail. One lookup now, by id. This also closes the path the field's
own bound forbids: with the e-mail branch, an unresolvable reference could have left a work e-mail
address in a column that is supposed to carry a name and nothing else.

The residual the triage comment named second is real and unchanged: a later rename of the sys_user
row does not reach back into this column. It is the identical residual
ats_employer_member.display_name has carried since #22, it is stated in the field's own comment,
and a reassignment is not affected — re-pointing owner re-derives the name (measured).

The projected values, cross-checked against an independent source

Never against the column itself. ats_employer_member.display_name is a different column, stamped
by a different handler, from a different row, seeded independently; both the name and the pointer
are compared, so a right name on the wrong contact would fail.

Employer	owner_name	member display_name	pointer
Bluewater Hospitality Group	Nicolas Aubert	Nicolas Aubert · admin	same
Brightmarket Retail Group	Stephen Quill	Stephen Quill · admin	same
Cedarbrook Care Network	Helen Mwangi	Helen Mwangi · admin	same
Harborline Manufacturing	Walter Brandt	Walter Brandt · admin	same
Ironbridge Construction	Frank Delaney	Frank Delaney · admin	same
Lumenvale Academy	Ruth Calloway	Ruth Calloway · admin	same
Meridian Clinics	Samir Khoury	Samir Khoury · admin	same
Orbit Consulting Partners	Victoria Lang	Victoria Lang · admin	same
Pixelforge Studios	Zoe Hamilton	Zoe Hamilton · admin	same
Quillstone Robotics	Margaret Ellison	Margaret Ellison · admin	same
Summitridge Financial	Alan Pemberton	Alan Pemberton · admin	same
Swiftroute Logistics	Paula Reyes	Paula Reyes · admin	same

12 of 12 on both the name and the pointer — memory and sqlite, first boot and second boot of one
persistent file.

#43 — the stamp is not re-derived by a payload that does not name its source

Write	Measured, both drivers
PATCH {}	0 of 12 stamps moved
PATCH { city } with the value it already holds	0 of 12
PATCH { verification_note } — the reviewer's own write	0 of 12
PATCH { owner_name: "HACKED VALUE" }	re-derived from owner; 0 of 12 rows changed
PATCH { owner: another user }	1 of 12, to Victoria Lang
PATCH { owner: null }	owner = null, owner_name = null
second boot of one sqlite file	12 of 12 triples identical to boot 1; 12 distinct values

The second boot is the one that matters: it is the boot that runs plugin-security's
claimSeedOwnership (multi: true, one SET clause for every matched row) and the seed's re-boot
upsert — [Seeder] Seed loading complete {"inserted":0,"updated":7,"skipped":811,"errored":0}. The
guard returns before computing anything because that payload names owner_id, not owner. Twelve
distinct values after it is the check that no single value was broadcast across the twelve rows.

Browser evidence — admin@platform.example, real Chromium

The review queue, reached by clicking the Employers Pending nav entry. 2 records, zero
usr_ats_* strings on screen:

The authored ats_employer.all view. 12 records, all 12 contact names, zero usr_ats_* on screen:

Two more shots are linked rather than embedded — GitHub's body sanitizer destroyed the third and
fourth image embeds on both of the previous writes of this description, in two different ways, and a
link carries no ! for it to eat:

• The same queue after the second boot of a persistent sqlite database
  — the boot that runs claimSeedOwnership. Names intact, 2 records.
• The employer record page
  — where the honest limits show.

Two things in that record shot are deliberate. The header strip truncates the sixth value to
Zoe Ha… — the shell's layout at 5+ items, the same thing docs/evidence/issue-33/README.md
recorded as Pendi… / Full-ti…; filed as #84. And the Details tab still reads
PRIMARY CONTACT usr_ats_pixelforge_admin: that is the owner pointer, kept, editable, and the
thing the approval flow notifies. owner_name is deliberately in no form section — a derived value
should not be offered as a text box, even one the hook re-derives.

Deliberate non-changes

• searchable is not set on owner_name. Search is a second, wider surface; the reviewer's
  queue is a slice they read.
• readonly is not set. The sibling mirror ats_employer_member.display_name does not set it
  either, and the anti-tamper property is measured: writing the column re-derives it. readonly on
  a value stamped through ctx.input is unmeasured in this repo and would be a second behaviour to
  verify for no gain here.
• No other Field.user column is mirrored. The argument that makes this one defensible —
  the audience already holds the fact — is not available for ats_candidate.user or
  ats_interview.interviewers. See Every Field.user column reads as a bare id to a platform persona: the readable sys_user set is now the caller's own row (1 of 113, was 83) #82.

Gates

$ pnpm validate
  → Validating against ObjectStack Protocol...
  → Running author-time rules (42)...
  → Checking capability providers (#3366)...
  → Checking package docs (ADR-0046)...
  ✓ Validation passed (516ms)
exit 0   (3 pre-existing approver-routing warnings, unchanged by this branch)

$ pnpm lint
  ✓ 7 assertions — the comparator still reports drift, orphans and gaps
  bundle keys (src/translations/en.ts)    514
  source labels collected                 514   (489 os i18n extract + 25 view-nested)
  compared, key present on both sides     514
  ✓ every bundle key restates the label its metadata declares
exit 0   (512 -> 514: `owner_name` label + help, en verbatim from the source, zh-CN translated)

$ pnpm typecheck
> tsc --noEmit
exit 0

Exit codes captured before any pipe. Seed shape unchanged: 818 rows, funnel
88 / 46 / 28 / 14 / 9, ats_employer 12, ats_employer_member 30, ats_candidate 80 — on both
drivers and both sqlite boots.

Out of scope, measured here and filed unassigned: #82 (every Field.user column reads as a bare id
to a platform persona), #83 (a platform administrator cannot create an ats_employer: HTTP 500), #84
(header strip truncation). No changeset: this repository has no changeset mechanism and CI runs only
the three gates above.

[os-sam]

评审:全部断言在我自己的两次 boot 上重测通过,批准合并

(GitHub 不允许同一身份 approve 自己的 PR —— 所有 agent 共用一个账号,所以这条以 review comment 形式落。它就是 PM 的合并决定。)

我没有采信 PR 里的任何一个数字。下面每一行都是我在 eab4ca0 上自己跑出来的:一个 worktree、一个 sqlite 持久文件、两次 boot、一个真实 Chromium。

三道门(我自己跑的,不是 CI 的结论)

pnpm validate    exit 0    12 Objects  148 Fields   (3 条既有的审批路由告警,与本分支无关)
pnpm lint        exit 0    自检 7 条断言;bundle 514 / source 514 / compared 514
pnpm typecheck   exit 0

投影值:我换了一个比 PR 更靠外的参照物

PR 拿 ats_employer_member.display_name 做交叉验证。我没有用它 —— 我直接解析 src/data/demo-en/pack.ts,从 pack.employers[i].name 和 pack.staff[i].admin 两个数组 zip 出期望映射,这条路径完全不经过运行时,也不经过任何一个 hook:

12 of 12 与 pack 解析出的期望一致;0 mismatched

密封:我试了四个逃逸面,PR 只测了列表读

求职者 candidate01@mail.example:

面	结果
列表读(9 行)	owner_name 键在 0 / 9 行上出现;owner 指针 9 行照常可读
$select=id,name,owner_name	HTTP 200,返回键里没有 owner_name,无泄漏
$filter=owner_name eq 'Zoe Hamilton'	HTTP 400
$orderby=owner_name asc	HTTP 403
$search=Hamilton	HTTP 403
GET ats_employer_member	HTTP 403

投影、过滤、排序、搜索四条侧信道都没有把这个名字漏出去。密封是真的密封,不只是列表不返回。

防篡改与 #43

写入	我测到的
PATCH { owner_name: "HACKED VALUE" }(平台管理员)	回落成 Zoe Hamilton,篡改未存活
PATCH { owner_name }(雇主管理员改自己那一行)	HTTP 200,值仍是 Margaret Ellison
PATCH {} / PATCH { city } 原值 / PATCH { verification_note }	0 / 12 行的 (owner_name, owner) 发生变化;12 个仍然互不相同
PATCH { owner: null }	owner = null,owner_name = null
PATCH { owner: usr_ats_orbit_admin }	owner_name = Victoria Lang
同一 sqlite 文件的第二次 boot	12 / 12 三元组与 boot 1 完全相同

第二次 boot 的种子行:{"inserted":0,"updated":8,"skipped":810,"errored":0}。PR 写的是 updated: 7 —— 多出来的那 1 是我自己在 boot 1 里改过 Pixelforge 的 verification_note,不是 PR 的数字对不上。

我专门去找的那个洞:它不存在

守卫是 if (!inserting && ...) return,插入路径不做清理。所以我去试了「payload 里显式写 owner: null,同时植入 owner_name」—— 如果 defaultValue: 'current_user' 是在 hook 之后才解析的,这个值就会原样落库:

POST { name, industry, owner: null, owner_name: "PLANTED NAME" }
  -> HTTP 201   owner = usr_ats_0_owner   owner_name = "Dev Admin"
  植入值存活: False

defaultValue 在 beforeInsert hook 之前就已经解析好了,所以每一条可达的写路径都会重新推导。不设 readonly 在今天不花任何代价。

顺带说一句:PR 里「readonly 在本仓库未经测量」这个理由是对的,别被 #55 里我给 days_to_offer 加的 readonly: true 误导 —— 那一列是被跨对象的 api.object(...).update() 写的,不是通过自己对象 hook 的 ctx.input,不构成这里需要的先例。

浏览器,第二次 boot,admin@platform.example

审核队列(verification_status=pending),屏幕上 usr_ats_* 出现 0 次:Primary Contact Name 列读作 Samir Khoury / Zoe Hamilton,2 records。ats_employer.all 全量视图同样 0 次 usr_ats_*,12 个名字全部渲染。求职者的岗位列表里一个名字都没有。

两点更正,都不阻塞

1. 「seeded independently」这个说法偏强。 ats_employer_member.display_name 和 sys_user.name 在 src/data/shared/build.ts 里出自同一个 pack.staff[i].admin 字符串(:349 与 :222)。这个交叉验证仍然是有意义的 —— 两个值在运行时走的是不同路径(一个是种子字面量,一个是 hook 查回来的),而且指针的比对能抓住「名字对、联系人错」—— 但真正独立的是路径,不是种子。以后这么写更准确。我自己那条 pack 解析也是同一个根,所以我并没有比它更强。

2. 这一列的寿命绑在 #82 上。 之所以要镜像,是因为平台人格读不到雇主员工的 sys_user 行(我这次测到的是 1 / 113)。#39 的三搬一留搬的是 ats_offer / ats_interview / ats_employer,搬不到 sys_user —— 展开的目标行还在墙里,所以 #39 落地也不会让这一列变多余,两者不冲突。但如果 #82 将来以放宽 sys_user 的方式收口,这一列就退化成一个带陈旧风险的纯冗余,那时候应该回来删掉它。请在 #82 结案时回看这条。

另:POST ats_employer 以平台管理员身份仍然是 HTTP 500 ERR_SYSTEM_WRITE_ORGANIZATION_REQUIRED(#83)。在这条分支上复现,在 main 上同样复现,不是本 PR 引入的。

设计边界(只镜像姓名、不碰邮箱电话、指针保持权威、不设 searchable)我认同,而且密封那一步把它从「绕过可见性规则」变成了「对已经握有这个事实的受众复述一遍」。合并。

---

Generated by Claude Code