Review-queue nav slices render auto-derived columns without the verdict field — declare `highlightFields` on `ats_employer` and `ats_job`

[claude]

Found while delivering #3 (card 08). Object files (src/objects/) are outside that card's scope, so filed.

What was measured

platform.nav.ts defines both review queues as filters slices on the bare data surface (/_console/apps/ats/ats_employer/data?filter[verification_status]=pending, /_console/apps/ats/ats_job/data?filter[status]=pending_review). The data surface (objectui ObjectDataPage) does NOT read the object's authored default list; it derives its columns from highlightFields when the object declares them, else the first business fields. Measured columns today:

• Employers Pending: Employer Name · Short Name · Logo · Industry · Company Size · City — no verification_status, no verification_docs, no owner.
• Jobs Pending: Job Title · Employer · Employer Organization · Department · Description · Requirements — two rich-text columns, no status, no published_at.

Screenshots: docs/evidence/issue-3/04-platform-employers-pending-nav-slice.png and 05-platform-jobs-pending-nav-slice.png on the #3 branch. Authoring ats_employer.all / ats_job.all with the right columns (done in #3) did not change the slice, as expected.

Proposed fix

Declare highlightFields on the two objects (spec 17: the key compactLayout was renamed to highlightFields in 11.7.0; ADR-0085 semantic role) so every derived surface — the review-queue slices, related lists, the record highlights panel — leads with the fields a reviewer needs:

• ats_employer: name, industry, city, verification_status, service_tier, owner
• ats_job: title, employer, status, city, employment_type, published_at

This keeps the nav slice as the single owner of each queue (no second, drifting pending_* list view) while fixing what it shows.

---

Generated by Claude Code

[os-sam]

A third instance, from the PM review of #36: the seeker's My Profile entry is also a filters slice ({ user: '{current_user_id}' } on ats_candidate), so it renders the same auto-derived columns for the same reason.

So highlightFields is owed on three objects, not two: ats_employer, ats_job, and ats_candidate.

Audited from the built artifact — those three are exactly the filters-slice entries among the app's 21 nav items; the other eighteen either name a view or land on a declared primary list, so they are unaffected.

Suggested for the third: ats_candidate: full_name, current_title, city, seeking_status, experience_years, profile_visibility.

⚠️ One caution for whoever takes this: profile_visibility is enforced nowhere (#13). Putting it in highlightFields makes it visible to anyone who can already read the row, which is fine, but it must not be mistaken for making it effective.

---

Generated by Claude Code

[claude]

os-dev-report

{
  "issue": 33,
  "status": "done",
  "branch": "claude/issue-33-highlight-fields",
  "pr": "https://github.com/objectstack-ai/ats/pull/71",
  "premise_still_valid": true,
  "summary": "Declared highlightFields (ADR-0085, spec 17) on ats_employer, ats_job and ats_candidate — three objects, not the two in the title: the card's comment records that the seeker's My Profile entry is a filters slice on ats_candidate for the same reason, and closing #33 with only two would have silently dropped the third. Re-audited on this branch: those three are the only filters entries in the app's navigation. The declaration is NOT a no-op — measured in a real boot, all three slices changed, as did the employer/job/candidate record headers and the employer's Jobs related list. One deviation from the proposal, justified in the PR: ats_job takes work_mode where the card proposed published_at, because the job_status_transitions state machine only reaches published THROUGH pending_review, so published_at is null on every row the Jobs Pending queue can ever contain (measured 0 of 6 pending, 0 of the 12 draft/pending_review/rejected rows) — it would have been a permanently empty column in the one surface the card exists to repair. Everything else in the proposal measured out and is used as written, in the proposed order; every field name was confirmed against the object first, because defaultColumnsFromObject filters the curated array through objectDef.fields and a misspelling would silently shrink the column set without failing any gate. Assignee was empty on arrival and was left empty.",
  "tests": "GATES on the committed tree, exit codes captured before any pipe (cmd > log 2>&1; EXIT=$?): pnpm validate VALIDATE_EXIT=0 | pnpm lint LINT_EXIT=0 (objectstack lint --i18n-strict) | pnpm typecheck TYPECHECK_EXIT=0 | npx objectstack build BUILD_EXIT=0. validate and lint report the same 3 pre-existing approval-staffing suggestions that 62e496d reports; no new diagnostic, no new translatable string (declarations reference existing field keys whose labels already ship in en and zh-CN). ARTIFACT: dist/objectstack.json carries highlightFields on ats_candidate, ats_employer, ats_job (plus pre-existing ats_inquiry); it carried only ats_inquiry at base. BROWSER, the actual acceptance: booted twice in the same container on the same recipe (OS_PLATFORM_OWNER_EMAIL=admin@objectos.ai npx objectstack dev --fresh --database-driver memory -p 4511 --log-level info), once on 62e496d for the before and once on this branch for the after, each after 'demo seed enabled: NODE_ENV=development' and '[Seeder] Seed loading complete {inserted:818, errored:0}'. memory driver because #39 empties the Employers Pending queue on sqlite. The before was reproduced, not quoted from docs/evidence/issue-3, and matches those shots exactly. Platform slices reached by clicking the nav entry. Employers Pending (2 records): 'Employer Name / Short Name / Logo / Industry / Company Size / City' -> 'Employer Name / Industry / City / Verification / Service Tier / Primary Contact'. Jobs Pending (6 records): 'Job Title / Employer / Employer Organization / Department / Description / Requirements' -> 'Job Title / Employer / Status / City / Employment Type / Work Mode'. Seeker My Profile (1 record, candidate01@mail.example): 'Full Name / Account / Photo / Phone / Email / City' -> 'Full Name / Current Title / City / Seeking Status / Years of Experience / Profile Visibility'. OTHER SURFACES: employer record header 'Primary Contact / Industry' -> 'Industry / City / Verification / Service Tier / Primary Contact' (improvement). Employer record Jobs related list 'Job Title / Employment Type / Work Mode / Salary Period / Min. Education / Status' -> 'Job Title / Status / City / Employment Type / Work Mode' (improvement; Employer is in the set but correctly suppressed on its own parent's related list). Job record header 'Employer / Employer Organization' -> 'Employer / Status / City / Employment Type / Work Mode' — MIXED, reported not buried: two badges truncate to 'Pendi…' and 'Full-ti…' at five strip items, and Status now shows twice (strip plus the state-machine stage bar below it); dropping status would clear it and undo the card, so it is kept and the cost is stated. Candidate record header 'Phone / Email' -> 'Current Title / City / Seeking Status / Years of Experience / Profile Visibility' — a real removal; both remain on the Details tab as live tel:/mailto: links, net better in our reading but stated as a trade-off. NON-REGRESSION: authored views are untouched and each rendered set is identical to the array in src/views — ats_employer.all (columns), ats_job.all (platformColumns), ats_job.published (seekerColumns), ats_inquiry.inbox. No ablation artifact: this is a metadata declaration with no gate or guard to mutate. The equivalent proof is the two-boot before/after on the same recipe plus the authored-view non-regression, all in docs/evidence/issue-33/ (14 shots, README naming persona, URL and content). Port 4511 probed free before the first boot and confirmed free after teardown; both servers launched with setsid and killed by recorded pgid (29201, 31961), never by process name — the three parallel agents on 3779/3801/4363 were verified still running afterwards.",
  "mcp_calls": "0 — every GitHub read and write went through the repo-scoped REST channel (curl); the channel was probed first and returned 200, so no MCP call was needed, including the duplicate search",
  "open_questions": [],
  "out_of_scope_findings": [
    "filed as #67: Field.user columns render the raw user id in every grid — ats_employer.owner shows usr_ats_pixelforge_admin instead of a name, on the derived slice AND on the authored ats_employer.all view this branch does not touch, so it predates this card. owner_id resolves to a display name and the ats_job.employer lookup resolves to the employer name in the same grids, so it is specifically the app-authored user field. Whether the repair belongs here or upstream in objectui's user-field cell renderer is left open. Unassigned, unlabelled for triage.",
    "not filed, reported here only: the objectui i18n string for this setting says the detail header 'takes the first 4' of highlightFields; measured, the record header renders all six minus the name field (five items on all three objects). A doc-string/behaviour mismatch in objectui, not in this repo, and too thin to open a card against a sibling repo from inside this one — flagging it for PM to route if wanted."
  ]
}

---

Generated by Claude Code