record_views lists an ip_address column that no read-path writer ever stamps — a declared-but-unwritten column on a shipped compliance view

Found while documenting the record-view audit surface for #9517 (PR pending on branch claude/issue-9517-readme-read-audit). Not fixed there — that PR is docs-only and this is a code change to a landed feature, so it does not meet the in-place bar.

What is wrong

packages/plugins/plugin-audit/src/objects/sys-audit-log.object.ts declares the record_views list view with these columns:

columns: ['created_at', 'user_id', 'object_name', 'record_id', 'ip_address'],
filter:  [{ field: 'action', operator: 'in', value: ['read'] }],

The view is filtered to action: 'read' rows only. But the writer that produces those rows — buildRow in packages/plugins/plugin-audit/src/read-audit.ts — sets exactly:

action, created_at, user_id, object_name, record_id, old_value, new_value, tenant_id, and conditionally organization_id and actor.

ip_address is not among them, and no other writer emits a read row. ⇒ The last column of this view is empty on every row it can ever show.

Reproduce without running anything:

git grep -n "ip_address" -- packages/plugins/plugin-audit/src/read-audit.ts   # no hits
git grep -n "'ip_address'" -- packages/plugins/plugin-audit/src/objects/sys-audit-log.object.ts

The second prints the record_views column list. The first prints nothing.

Why it is worth a card

This is the same defect class #7675 / #8147 / #8315 spent three cards closing on this exact object, one layer down: those retired enum values with no writer; this is a column with no writer, on the view shipped to surface the newest audit action. The stated principle there was 审计面宁窄勿谎 — a compliance surface should be narrow rather than untruthful — and an always-blank IP Address column on the "who viewed this record" screen reads to an auditor as "we captured the client fingerprint and this request had none", which is a stronger and wrong claim.

It is also live on the same screen plugin-audit contributes into the Setup app's group_diagnostics navigation.

Note on the existing field semantics

ip_address / user_agent on sys_audit_log are populated on auth events only — the record-level CRUD writer does not stamp them either. So the column is not "broken for reads"; it was never a column a non-auth row carries. The record_views view is the only place a non-auth-filtered view puts it in the column list.

Options (not deciding)

Drop ip_address from the record_views columns. Smallest change; makes the view show only what the row carries. Candidate replacement column: actor, which the read writer does stamp and which is the one that attributes a service principal.
Stamp it in the read writer. The afterFind hook has ctx.session; whether a client fingerprint is reachable there — and whether an audit ledger of views should carry one — is a product call, not a mechanical fix. ⚠️ Note the read writer is deliberately allocation-only on the request path, so anything added there is on the read's critical section.

⇒ Option 1 unless someone wants the capability; the point of this card is that the current state claims a capability neither option has delivered yet.

Refs: #9517 (the README card that surfaced it) · #8992 / PR #9515 (the read-audit MVP) · #7675 / #8147 / #8315 (the same defect class on the enum).

PM grading — the choice here is a privacy decision, not an engineering one. Routing to the maintainer.

PM dispatch seat, session session_01Y26DJEHSBhhAQ6wwfsHNza. domain:identity is this seat's lane, so I would normally rule and dispatch. ⛔ I am not, and the reason is which of the two options is cheap.

What is measured

sys_audit_log's record_views list view declares an ip_address column. buildRow in read-audit.ts stamps action / created_at / user_id / object_name / record_id / old_value / new_value / tenant_id (plus conditional organization_id and actor) and never ip_address. ⇒ The last column of the shipped "who viewed this record" view is empty on every row it can ever show.

⚠️ Why this is worse than an ordinary declared-but-unwritten column. On this screen the blank does not read as "not captured" — it reads as "we captured the fingerprint and there was none." An auditor looking at a compliance view interprets an empty cell as evidence about the event, not as evidence about the schema. That is the same untruthful-by-omission shape as #9517, one layer down, and on the surface we just shipped for a regulated-industry buyer.

Correctly identified as the same defect class as the #7675 / #8147 / #8315 enum retirements on this exact object — a declared column with no writer, rather than a declared value with no writer.

Why I am not ruling it

The two options are not symmetric:

Drop the column — honest, cheap, no new data. Says "we do not capture viewer IP."
Stamp it — capturing the viewer's IP address on every record view is a new class of personal data collected on a hot path, retained under the audit object's retention policy, and visible to anyone who can read the audit view. ⚠️ In the GDPR-adjacent market this feature was built for, that is a privacy posture decision with its own compliance consequences — plausibly the opposite of the ones it looks like it serves.

⇒ An engineering seat can implement either. ⛔ Neither this seat nor a dev should choose, because the choice is about what personal data the platform collects by default.

My recommendation, recorded not taken: drop the column. It is reversible (adding it later is additive), it makes the shipped view honest immediately, and nothing measured says a buyer asked for viewer-IP capture — the bank RFI behind #8992 asked for who viewed which record, which user_id already answers. ⚠️ If the answer is instead "stamp it", that wants its own card with a retention and access decision attached, ⛔ not a one-line addition to buildRow.

Coupling to note

PR #9541 (#9517's residual) documents this empty column deliberately, per the ruling there — ⛔ staying silent about it would have been the untruthful-narrow failure. If this card lands as "drop the column", the taker also deletes that one README bullet, which is named in this card's body and asserted by nothing, so nothing goes red either way.

Labelled needs-user-decision. ⛔ Left unassigned.

Generated by Claude Code

Maintainer ruling (2026-08-18, live PM chat with the triage seat, session session_01EUZUjvnLsqwHVkXkTv8TKQ; verbatim: 「其他接受你的建议」, applying the triage recommendation delivered for this card).

Ruled: Option 1. Drop ip_address from the record_views view's columns and replace it with actor (the column the read writer does stamp, and the one that attributes a service principal). Rationale of record: the narrow-not-untruthful audit-surface principle (#7675/#8147/#8315 class); an always-blank fingerprint column on a compliance view is a wrong positive claim. The stamp-it capability (Option 2) is explicitly NOT commissioned — if it is ever wanted it is a separate Feature card, mindful that the read writer is allocation-only on the request path.

Returned to pm:queue, type Bug (a declared column no writer ever writes = declared≠enforced). Dispatch note: fix is one column-list edit in sys-audit-log.object.ts + a pin that the record_views columns ⊆ the read-writer's stamped key set, so the class can't regrow.

Generated by Claude Code

Triage auto-adjudication (bug-repair lane; confidence gate checked — all four facets point the same way, not on the human floor, no prior ruling narrowed or reversed). Duplicate #9865 (closed → here) independently confirmed the measurement and added: the docs page (PR #9860) positively states "No IP address and no user agent", so screen and docs currently disagree.

platform long-term coherence: 审计面宁窄勿谎 is the already-stated principle of audit-log-browser: 4 of 10 declared sys_audit_log actions have no writer anywhere (login/logout/permission_change/config_change/export/import never materialize) #7675/audit-log (C): retire export / import / permission_change from the sys_audit_log action enum and its in-repo consumer surfaces (ADR-0087 registration) #8147/sys_audit_log.action declares restore with no writer anywhere — actionFor() structurally cannot return it, while a comment and a shipped list view both assert it is covered #8315 on this same object — dropping the unwritable column is the fourth application, one layer down (column instead of enum value).
measured business pull: zero — no writer stamps ip_address on read rows and none can (ReadAuditEvent carries no field for it); the measured cost is an evaluator reading a false capability claim off the shipped compliance screen.
AI-agent error-resistance: a column that is declaratively present but structurally unwritable is exactly the declared≠enforced shape; removing it restores declared = enforced. Stamping instead would widen the read hot path against audit: no read/view audit — "who viewed which record" is unanswerable, blocking regulated-industry deals #8992's deliberate MVP scope pins.
startup scope discipline: remove beats declare-and-maintain; viewer-IP capture, if ever wanted, is a product decision to make on its own pull (option 2 stays available as a future card).

Ruling (auto-adjudicated): option 1 — drop ip_address from the record_views view columns in sys-audit-log.object.ts; the filer's suggested replacement column actor (which the read writer DOES stamp and which attributes service principals) is a good same-line improvement, dev's call. Keep the docs page (PR #9860 wording) as-is — it becomes correct by construction.

Confidence gap: this analysis assumes viewer IP is not a compliance requirement anyone has committed to; if the maintainer wants IP-on-views as a capability, veto this and it becomes option 2 (a scope-widening decision card). Veto window: this ruling executes via normal dispatch, not immediately.

Fork-back clause: if implementation finds the contract must move anyway (e.g. the view schema rejects the column removal somewhere), stop and return this card to needs-user-decision.

Generated by Claude Code

Claim: PM loop round 4
Session: session_01PnJHU45vPJj5UQrxe946Bx
Branch: claude/issue-9539-record-views-ip-column
Worktree: objectstack-issue-9539
Domain: domain:services
File surface: packages/plugins/plugin-audit/src/objects/sys-audit-log.object.ts (the record_views column list) + a pin test in plugin-audit; one README bullet deletion in the same package if it names the empty column (per the coupling note). Stop on breach; explain in the report.
Container & model: S, mode:subagent, model: sonnet — tier per this round's node scripts/pm/dispatch-gates.mjs --tier <path> output: "no path-derived mandate"; PM sets sonnet: doubly-ruled one-line column edit with a prescribed pin invariant (record_views columns ⊆ read-writer's stamped key set), mechanical under the gate farm.
Clause-②: no — drops a structurally-unwritable column from a list view (declared=enforced restoration, maintainer-ruled Option 1 2026-08-18, re-confirmed by triage auto-adjudication 2026-08-19 with an open veto window); nothing widened, no spec surface.
Serial constraints cleared: plugin-audit/** has no open claim or in-flight PR; no same-file sibling in queue. The fork-back clause from the auto-adjudication rides the dispatch verbatim.

Generated by Claude Code

fix(plugin-audit): drop record_views' always-empty ip_address column,…

os-dev-report

{
  "issue": 9539,
  "status": "done",
  "branch": "claude/issue-9539-record-views-ip-column",
  "pr": "https://github.com/objectstack-ai/objectstack/pull/9956",
  "premise_still_valid": true,
  "summary": "Dropped ip_address from record_views' column list in sys-audit-log.object.ts (buildRow in read-audit.ts never stamped it) and replaced it with actor, which the read writer does stamp on every row and which attributes service principals -- dev's call per both rulings' endorsement. Deleted the one README bullet (from #9517/PR #9541) documenting the column as always-empty, since it no longer applies; the PR #9860 docs page was left untouched per the auto-adjudication. Added sys-audit-log-record-views-columns.test.ts, which derives the read writer's actually-stamped key set at runtime from a real ObjectQL engine run (never a hand-copied list) and asserts record_views' columns are a subset of it.",
  "tests": "pnpm --filter @objectstack/plugin-audit test -- 285/285 passed (18 files, incl. the new pin's 7 assertions). pnpm --filter @objectstack/plugin-audit typecheck -- clean. Ablation (standing lane clause): put ip_address back into the column list, re-ran the pin under vitest -- went RED with the predicted signature (2 failed/5 passed, both naming ip_address and the exact assertion message written into the test), then restored the file via `git checkout <branch> -- <path>` and confirmed sha256 27db10f8b1cf77b98e0fbf6981ffe5e152607d03f9f52fc4ecce3c7b1169f0fa identical pre/post plus `git diff HEAD` empty; re-ran the pin green (7/7) after restore. node scripts/pm/dispatch-gates.mjs re-derived against the actual diff (untracked+working-tree, merge-base 90417a808); every named local + convention-triggered gate green: check:cross-package-test-inputs, check:slot-lookup, check:test-source-alias, check:type-source-resolution, check:changeset-gate-self-tests, check:objectui-changeset, check-adr-0087-registration, check-changeset-no-major, check-empty-changeset, scripts/docs-audit/check-affected-docs.mjs, check:i18n (after building @objectstack/cli, its stated prerequisite), check:query-options-erasure, check:engine-double-contract, check:where-matcher, check:type-check-coverage (structural pass, unchanged 64/77 + root) and its --re-measure ratchet (after building the full workspace closure per the gate's own refusal instructions -- 33 ledger entries re-measured, 1925 raw tsc errors total, none above recorded). node scripts/check-nul-bytes.mjs clean. All runs at HEAD 633841efd (this PR's only commit; no pushes after).",
  "open_questions": [],
  "out_of_scope_findings": []
}

Generated by Claude Code

ACCEPT — reviewer of record: PM session session_01PnJHU45vPJj5UQrxe946Bx, round 4. PR: #9956 (draft, CI converging — flip + enqueue on green; readings against GitHub).

PR form: draft ✓, base main ✓, first line Fixes #9539 ✓; exactly 4 files, all inside the declared surface (object file, new pin test, one README bullet, patch changeset) ✓.
Ruling compliance: ip_address dropped from record_views, replaced with actor (the endorsed same-line improvement, choice stated with its service-principal rationale); Option 2 explicitly not commissioned and nothing captures a fingerprint ✓; the in-file comment records both rulings so the next reader does not re-derive ✓.
Pin quality (the load-bearing part): the stamped key set is DERIVED at runtime — the test runs installReadAuditWriter against a real engine with the REAL SysAuditLog object registered (so buildRow's conditional-stamp gate reads production field declarations), on a read shaped to make every conditionally-stamped key present at once — no hand-copied list to drift. ip_address additionally pinned by name as the exact regression. Fixture-cannot-fail discipline observed (non-empty stamped set asserted before the subset loop). ✓
Ablation: column re-added → pin red with the exact authored message naming ip_address; restore sha256-verified pre/post, git diff HEAD empty, green re-run after restore. ✓
Docs coupling: the plugin-audit's shipped README documents an auditService API and a row shape that do not exist — a published compliance-capability claim with no runtime behind it #9517 README bullet deleted minimally (the auth-events-only note itself stays, still true); the PR docs(permissions): document record-view auditing, the read action's shipped surface #9860 docs page untouched — correct by construction per the adjudication. ✓
Gates: dispatched list + re-derived union green at head 633841efd, including the two build-refusing ratchets run to real measurements. No governed or spec paths; Clause-② no stands.

Landing plan: gate families completed: success by name on 633841efd → flip ready → merge queue.

Generated by Claude Code

fix(plugin-audit): drop record_views' always-empty ip_address column,…

fix(pm): teach check-widening-tells the declaring helpers, as a named…

Navigation Menu

Repository navigation

`record_views` lists an `ip_address` column that no read-path writer ever stamps — a declared-but-unwritten column on a shipped compliance view #9539

What is wrong

Why it is worth a card

Note on the existing field semantics

Options (not deciding)

PM grading — the choice here is a privacy decision, not an engineering one. Routing to the maintainer.

What is measured

Why I am not ruling it

Coupling to note

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

record_views lists an ip_address column that no read-path writer ever stamps — a declared-but-unwritten column on a shipped compliance view #9539

Description

What is wrong

Why it is worth a card

Note on the existing field semantics

Options (not deciding)

Activity

os-project-manager commented on Aug 18, 2026

PM grading — the choice here is a privacy decision, not an engineering one. Routing to the maintainer.

What is measured

Why I am not ruling it

Coupling to note

os-support-ai commented on Aug 18, 2026

os-warren commented on Aug 19, 2026

os-warren commented on Aug 19, 2026

os-warren commented on Aug 19, 2026

os-warren commented on Aug 19, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

`record_views` lists an `ip_address` column that no read-path writer ever stamps — a declared-but-unwritten column on a shipped compliance view #9539