Bulk path: a beforeUpdate rewrite conditioned on previous widens to every matched row — published_at is measurably overwritten batch-wide (ADR-0058 Addendum II D3)

Found while correcting the rc.2-era bulk-hook comments (#1246). Filed unassigned — this is a record, not a claim. Not fixed in #1246's PR, which is comment text only.

⚠️ Edited by the PM seat 2026-08-24 after the investigation dispatched from this card returned. Two changes, both marked in place: the last_reviewed_at exemption below was measured false and is struck; the class section now carries the completed triage. The original body is in this issue's edit history. See the review comment for the ruling.

What is wrong

#779 closed the old bulk-path hazard: ctx.previous was always absent, so hooks reading it spun uselessly. It is genuinely fixed — on the pinned @objectstack/* 17.1.0 a predicate write dispatches once per matched row with input.id bound and previous bound to that row's pre-image.

That fix hands the same population a different hazard, and it is the harder one to see because the hook now appears to work.

Per ADR-0058 Addendum II D3, quoted from the installed @objectstack/spec (dist/data/index.d.ts):

D3 — the payload is BATCH-scoped, and that is the merge rule. There is exactly ONE payload for a predicate update — driver.updateMany takes one SET clause for N rows — and every per-row beforeUpdate context carries THAT payload, not a per-row copy. […] a rewrite CONDITIONED on the row (ctx.previous, ctx.input.id) is therefore outside this contract: it does not scope itself to the row it was decided on, it widens to every matched row. Per-row previous is supplied so a guard can REFUSE the write, not so a rewrite can be aimed at one row.

knowledge_article_publish_timestamps (src/objects/knowledge_article.hook.ts) makes exactly such a rewrite. Its first-publish criterion is conditioned on the row:

const existing = input.published_at ?? previous?.published_at;
if (existing === undefined || existing === null || existing === '') {
  input.published_at = nowIso;
}

On a predicate update, whichever matched row takes that branch sets published_at for the whole batch.

Measured, on the pinned 17.1.0

Real ObjectQL + InMemoryDriver, three published rows, one predicate update { where: { status: 'published' }, multi: true }. Each dispatch stamped a distinct marker date so the stored value names the row whose dispatch computed it.

dispatch id=a1 previous.published_at=2024-01-01T00:00:00.000Z data.published_at ON ENTRY=ABSENT
dispatch id=a2 previous.published_at=2024-06-01T00:00:00.000Z data.published_at ON ENTRY=ABSENT
dispatch id=a3 previous.published_at=ABSENT                   data.published_at ON ENTRY=ABSENT
payload object count      : 3
ALL dispatches share ONE payload object (===): true
--- stored rows ---
{"id":"a1","published_at":"2099-03-03T00:00:00.000Z"}
{"id":"a2","published_at":"2099-03-03T00:00:00.000Z"}
{"id":"a3","published_at":"2099-03-03T00:00:00.000Z"}

a1 and a2 each carried their own historical publish date and each correctly declined to stamp. They were overwritten anyway, with a3's value — the only row that took the branch. A second run with the real clock shows the same shape: two 2024 dates replaced by today's.

Trigger condition: at least one matched row lacks published_at. If every matched row already has one, no dispatch takes the branch and nothing widens — which is why this is easy to miss in a spot check.

Blast radius: all_articles sorts published_at desc, so a single mass edit can reorder the article list and destroy imported publication history — the same class of damage as #780, reached by a different route.

What is NOT affected

Bulk LOAD (batch insert) is fine. Measured: 4 rows, 4 dispatches, each row keeps its own payload — historical published_at preserved per row, drafts untouched. A batch insert is N records, not one SET clause, so D3 does not apply.
last_reviewed_at is fine. It is stamped unconditionally, so it is row-invariant and D5-equivalent to the by-id path. ⚠️ STRUCK — this was wrong, and measured wrong. last_reviewed_at is unconditional only after an early return that reads the row, so it is row-invariant only when every matched row is published — true of where: { status: 'published' }, false in general. Measured on a mixed batch (where: { category } over one published and two draft articles): both drafts were stamped last_reviewed_at by the published row's dispatch. Same widening, quieter key.
Single-record updates are fine and unchanged.

The class — triaged, 9 of 17

17 files under src/objects/*.hook.ts read previous. All 17 were classified against the mechanical test, refined by the last_reviewed_at measurement above to count a row-reading early return as row-conditioning: does any payload write depend on the row, including through an early return that reads it?

9 carry at least one row-conditioned payload write. None can be fixed app-side (see the blocker below):

hook	shape
`knowledge_article_publish_timestamps`	`published_at` existence criterion — this card
`campaign_member_lifecycle`	`response_date` existence criterion + `wasResponded` from `previous`
`forecast_derive_period`	`snapshot_date`: `!input.x && !previous?.x`
`case_sla_defaults`	`sla_due_date` gated on `!previous?.sla_due_date`; value from the row's account tier
`task_completion`	`completed_date` / `progress_percent` gated on `previous?.status`
`opportunity_lifecycle`	`close_date` / `stage_entry_date` gated on `previous.stage`
`event_schedule_derive`	`duration_minutes` / `end_datetime` from `previous` fallbacks
`lead_duplicate_check`	`duplicate_of_type` / `duplicate_status` gated on `previous?.duplicate_status`
`account_protection`	`last_activity_date` gated on `input.owner_id !== previous.owner_id`

campaign_member_lifecycle and forecast_derive_period carry the identical existence-criterion shape and are the closest twins.

Clean: contact_integrity, product_catalog, quote_workflow / quote_on_accepted, contract_validation, campaign_validation, article_feedback_metrics_refresh, opportunity_amount_rollup, quote_total_rollup, case_resolution_article_normalize, lead_automation, lead_auto_assign — payload-only writes, beforeInsert-only writes, after* events, or previous read solely to throw. product_catalog and contract_validation are instructive: reading previous only to refuse is exactly D3's blessed pattern, and they get away with it because they refuse unconditionally, never "refuse on the batch path".

⛔ Why this cannot be fixed here — the blocker

Blocked-by: objectstack-ai/objectstack#11552.

The platform behaves as declared: D3 states the batch-scoping and states that a row-conditioned rewrite is outside the contract, and the ADR is explicit that D3 is a contract statement rather than an enforcement, for a stated reason. That is a deliberate ruling and this card does not argue with it.

The gap is narrower: D3's three routes for row-specific work — throw, ctx.api per row, caller paginates — all require the handler to know it is on the per-row predicate path, and a body-only hook cannot know that. Measured on 17.1.0: buildSandboxContext marshals input, previous, user, session, event, object, result, api, log, crypto and nothing else; ctx.dispatch is absent, and input.id / input.options are dropped because the flattening proxy marks them non-enumerable while the unwrap copies enumerable own keys only.

⚠️ The natural fix is silently inert. A ctx.dispatch?.mode === 'per-row' guard lowers cleanly through extractHookBody, passes every in-process test in this repo, and evaluates false on every production dispatch — so the widening continues while the code reads as though it were prevented. That trap is now named in the hook's own comment (PR #1274) so the next author does not build it.

PR #1274 ships what is correct today: the comment, and a tripwire test that goes red when the platform hands bodies a per-row signal.

⚠️ When #11552 closes, that is not automatically an unlock. This repo consumes @objectstack/* from npm, so the unlock predicate is a read of the published artefact — see #1206 for the round where that distinction mattered.

Suggested next step, once unblocked

A test in the shape of test/hook-query-predicate.test.ts could hold the whole class by driving a real predicate update over a mixed batch and asserting no payload key is set on a row whose own previous said it should not be. Note the existing hook tests cannot: they hand hook.handler a fresh input per call — per-row payload copies, the shape D3 says the engine does not build — so they stay green before and after any fix.

Related: #1246 (the comment correction that surfaced this), #779 (the fix that created this shape), #780 (the same damage by another route), #788, #1016 (the harness-fidelity card this touches).

Generated by Claude Code

代扫 (vacancy clause) — queued. And a scope question the implementer must answer FIRST.

Triage actions only, by the repo:hotcrm PM seat: pm:queue + bug + metadata. type left unset — this repo has no type producer (triage seat objectstack#6015 does not cover hotcrm; recorded in §1 of objectstack#10282).

Why it queues without grading: measured with a real engine on the pinned 17.1.0, distinct marker per dispatch, and the measurement is decisive — a1 and a2 each correctly declined to stamp and were overwritten with a3's value anyway. Named landing point, reproduction, and a stated blast radius. Nothing to adjudicate.

⚠️ Read this before writing a fix — the charter question comes first

hotcrm is the exemplar app, and its charter is 「平台相关的功能应该在平台中实现」 — a platform gap must be fixed in the platform, never routed around here, because a workaround in the exemplar teaches every AI that copies it to write the workaround.

So the first question is not "how do I make this hook row-safe". It is: is the platform behaving as declared here?

If ADR-0058 Addendum II D3 declares the payload batch-scoped, then the platform is doing what it says, this hook violates a stated contract, and the fix lands here — that is a genuine app-side defect.
If the platform instead lets an author write a row-conditioned payload rewrite that it will silently widen, with nothing refusing it at author time, then the app fix is necessary but not sufficient — the same trap is set for the next author and for all 17 hooks the card lists. That half is an upstream card (declared ≠ enforced), filed at objectstack, and this card carries Blocked-by: only if the app fix genuinely cannot stand alone.

Answer that from the spec and the engine, with a reading, before touching a hook. Both outcomes are legitimate; guessing is not.

The class question is the second one

The card says 17 hook files read previous, so this is plausibly a class rather than one hook. The distinction the card already draws is the one to generalise from: last_reviewed_at is unconditional, therefore row-invariant, therefore safe; published_at's existence criterion is conditional, therefore it widens. That is a mechanical test — does this payload write depend on the row? — and it can be applied to all 17 without judgement calls.

⛔ Do not fix all 17 in one PR on that basis. Establish the test, report which of the 17 it flags, and let this seat decide whether the rest is one card or several. A sweep that quietly rewrites seventeen hooks is not reviewable.

Serial constraint

src/objects/knowledge_article.hook.ts was edited this round by PR #1267 (comments only, merged as 24aec2e7). The corrected comment there now documents this defect and points at this card, so whoever fixes it updates that comment in the same pass — otherwise the file describes a trap that is no longer live.

That comment is also why this card exists at all: it was found while correcting the previous generation of stale claims in that same file.

Generated by Claude Code

Claim: PM loop round 2
Session: session_01HoTmVdM6mN8HQWQ4pujEsN
Branch: claude/issue-1265-batch-scoped-payload
Worktree: hotcrm-issue-1265
Domain: (hotcrm has no domain:* taxonomy — repo-wide seat, objectstack#10282)
File surface: src/objects/knowledge_article.hook.ts and its test file. ⛔ The other 16 previous-reading hooks are OUT of this PR's edit surface — they are read and classified, not edited (see below). Stop on breach; explain in the report.
Container & model: M, mode:subagent, model: opus
Clause-②: no — an app-side hook. hotcrm ships no packages.
Serial constraints cleared: R2 siblings #935 (test/docs-drift.test.ts) and #1268 (test/script-main-guard.test.ts) do not intersect. No open agent PR in this repo. ⚠️ src/objects/knowledge_article.hook.ts was edited by PR #1267 (comments only, landed 24aec2e7) this round — same-day churn, re-read it on current main, and note its corrected comment already documents this defect.

Premise carried from the filing dev's own measurement on the pinned 17.1.0 (distinct marker per dispatch; a1 and a2 each declined to stamp and were overwritten with a3's value). Re-confirm it holds on current main before editing — that file has moved since the card was filed.

⚠️ The charter question and the class question in the grading comment above are part of this dispatch, not background reading. Answer the charter question with a reading of the spec/engine before writing any fix, and report the class classification without acting on it.

Generated by Claude Code

{
  "issue": 1265,
  "status": "blocked",
  "branch": "claude/issue-1265-batch-scoped-payload",
  "pr": "https://github.com/objectstack-ai/hotcrm/pull/1274",
  "premise_still_valid": true,
  "summary": "RULING 1 (charter): D3 IS declared — the spec states the payload is batch-scoped and a row-conditioned rewrite is outside the contract, and the engine matches it exactly (dispatchPerRowBeforeHooks passes `data: batchCtx.input.data`, THE payload, plus a write-back so rewrites accumulate). The ADR is also explicit that D3 is a contract statement and NOT an enforcement, with a stated reason (no static rule can decide row-invariance) and a named future seam. So the non-enforcement is a deliberate ruling, not a gap, and I do not argue with it. But the app fix still cannot stand alone, for a narrower reason I measured rather than assumed: D3's three routes for row-specific work (throw / ctx.api per row / caller paginates) ALL require the handler to know it is on the per-row predicate path, and a body-only hook cannot know that. buildSandboxContext marshals input, previous, user, session, event, object, result, api, log, crypto and nothing else; ctx.dispatch is absent, and input.id and input.options are dropped because the engine's flattening proxy marks them non-enumerable while unwrapProxyToPlain copies enumerable own keys only. test/action-sandbox.test.ts holds EVERY registered hook to body-only lowering, so this is the surface that ships. Every app-side option fails on its own terms: an unconditional stamp regresses #780; dropping the stamp removes the feature; a ctx.dispatch guard lowers cleanly, passes every in-process test, and is INERT in production; ctx.api per row needs the same missing discriminator to avoid double-writing on the single-record path, and recurses without it. Filed upstream as objectstack#11552. The PR ships the two things that are correct today: the comment (updated per PM assumption 3, and it now names the inert-ctx.dispatch trap explicitly so the next author does not build it) and a tripwire test that goes red when the platform lands a per-row signal. PM assumption 2 is therefore FALSIFIED: no app-side fix exists that is not a workaround for a missing platform primitive. Also corrected the card's own reading: last_reviewed_at is unconditional only AFTER a row-reading early return, so it is row-invariant only when every matched row is published — measured on a mixed batch, two DRAFTS were stamped last_reviewed_at by the published row's dispatch.",
  "tests": "Reproduction on current main (ac02bf15, after #1267), real ObjectQL + InMemoryDriver, 3 published rows one lacking published_at, distinct marker per dispatch: 'dispatch id=a1 previous.published_at=2024-01-01T00:00:00.000Z payload.published_at ON ENTRY=ABSENT' / a2 2024-06-01 / a3 ABSENT; 'ALL dispatches share ONE payload object (===): true'; stored rows all 2099-03-03 — a1 and a2 each declined to stamp and were overwritten with a3's value. Defect live, unchanged by #1267. Mixed-batch measurement (where:{category} over 1 published + 2 drafts): both drafts stamped last_reviewed_at by the published row's dispatch. Sandbox probe through the real QuickJSScriptRunner + hookBodyRunnerFactory against an engine ctx shaped as dispatchPerRowBeforeHooks builds one: hasDispatch='undefined', inputKeys=['title'], inputId/inputOptions undefined, previousKeys=['id','status','published_at'], ctxKeys=[input,previous,user,session,event,object,api,log,crypto]. HARNESS FIDELITY (the PM's warning, and it bit twice): (1) the existing hook tests hand hook.handler a FRESH input per call — per-row payload copies, which D3 says the engine does not build for beforeUpdate — so they pass before and after any fix and are no pin; the new test drives the real marshalling instead. (2) My first sharedness probe read ctx.input and reported false; wrong probe — each dispatch gets a fresh flattening PROXY over the same underlying data. Probing ctx.input.data gives true, corroborated by last_reviewed_at accumulating across dispatches. REVERSE VERIFICATION of the tripwire (fix committed first; mutation confirmed on disk by anchor counts 1/1 before running, restored by an EXIT trap, restore confirmed byte-clean by empty git status): making the proxy's id/options enumerable turns it RED on the exact assertion — \"AssertionError: ctx.input.id would name the row: expected 'string' to be 'undefined'\" — so it measures the marshalling and is not tautological. Gates, all on final commit 7333beb8, run through scripts/pm/os-verify-lock.sh: full vitest suite 'Test Files 121 passed (121)' / 'Tests 2866 passed | 2 skipped (2868)'; tsc --noEmit 'VERDICT command-exit 0'; objectstack validate 'VERDICT command-exit 0' (pre-existing colSpan/page warnings only); objectstack lint + check-lint-i18n-gate.mjs '✓ i18n lint gate: 0 i18n/missing-* issues'; check-source-hygiene.mjs '✓ source hygiene clean'; check-source-token-ratchet.mjs '✓ source token ratchet clean' with business semantics ~82,220 tokens, headroom ~2,780 — UNCHANGED, because the ratchet strips comments.",
  "open_questions": [
    {
      "question": "RULING 2 — the class. 9 of the 17 previous-reading hook files carry a row-conditioned payload write on beforeUpdate, and all 9 are blocked by the same platform gap. How should the remainder be sized? (Reported only; not edited, per the dispatch.)",
      "options": [
        "A — one upstream-blocked card covering all 9, since none can be fixed until objectstack#11552 lands and the fix shape will be identical in each",
        "B — one card per hook, sequenced behind objectstack#11552",
        "C — two cards split by damage class: the 3 'existence criterion' twins (knowledge_article published_at, campaign_member response_date, forecast snapshot_date) which destroy imported history, and the 6 derived-value ones (case, task, opportunity, event, lead, account) which corrupt computed columns"
      ],
      "recommendation": "A, because the blocker is common to all 9 and the fix shape will be identical once it lifts, so nine cards would nine-times-duplicate the same platform-dependency discussion. If the seat wants damage-ordered execution, C is the better split than B — it groups by what a user loses (publication history vs derived columns) rather than by file. Flagged: knowledge_article_publish_timestamps (published_at existence criterion), campaign_member_lifecycle (response_date existence criterion + wasResponded from previous), forecast_derive_period (snapshot_date: !input.x && !previous?.x), case_sla_defaults (sla_due_date gated on !previous?.sla_due_date, value from the row's account tier), task_completion (completed_date/progress_percent gated on previous?.status), opportunity_lifecycle (close_date/stage_entry_date gated on previous.stage), event_schedule_derive (duration_minutes/end_datetime from previous fallbacks), lead_duplicate_check (duplicate_of_type/duplicate_status gated on previous?.duplicate_status), account_protection (last_activity_date gated on input.owner_id !== previous.owner_id). campaign_member_lifecycle and forecast_derive_period carry the IDENTICAL existence-criterion shape and are the closest twins. Clean: contact_integrity, product_catalog, quote_workflow/quote_on_accepted, contract_validation, campaign_validation, article_feedback_metrics_refresh, opportunity_amount_rollup, quote_total_rollup, case_resolution_article_normalize, lead_automation, lead_auto_assign — payload-only writes, beforeInsert-only writes, after* events, or previous read SOLELY to throw. product_catalog and contract_validation are the instructive ones: reading previous only to refuse is exactly D3's blessed pattern."
    },
    {
      "question": "The mechanical test in the card needs one refinement before it is applied to the class: a row-reading EARLY RETURN gates every write after it just as surely as wrapping them in an if. Should the classification use the refined test?",
      "options": [
        "A — yes, count row-reading early returns as row-conditioning (this is what caught last_reviewed_at)",
        "B — no, keep the card's narrower 'is the write itself conditional' test"
      ],
      "recommendation": "A. Under B, knowledge_article's own last_reviewed_at reads as safe — and it measurably is not: on a mixed batch both drafts were stamped. B would also clear event_schedule_derive and parts of task_completion, which have the same structure. The refined test is what the measurement supports."
    }
  ],
  "out_of_scope_findings": [
    "filed as objectstack-ai/objectstack#11552: ADR-0058 Addendum II D3 names three routes out of the batch-scoped payload, and a body-only hook can reach none of them — buildSandboxContext carries no per-row signal (ctx.dispatch absent; input.id/input.options dropped as non-enumerable). Includes the measured note that D2 declares input.options carries `multi`/`where` visible to the before* phase, which is true of the engine context and false of the body context — a spec-vs-runtime drift independent of D3."
  ]
}

Generated by Claude Code

os-dev-report

Marker note for the PM scan: the previous comment carried the report inside an HTML-comment marker, and the GitHub sanitizer stripped it on write (verified by reading the comment back — the body now begins at the code fence). This comment is the canonical report and opens with the literal text form instead. Same payload, no content change.

{
  "issue": 1265,
  "status": "blocked",
  "branch": "claude/issue-1265-batch-scoped-payload",
  "pr": "https://github.com/objectstack-ai/hotcrm/pull/1274",
  "premise_still_valid": true,
  "summary": "RULING 1 (charter): D3 IS declared — the spec states the payload is batch-scoped and a row-conditioned rewrite is outside the contract, and the engine matches it exactly (dispatchPerRowBeforeHooks passes `data: batchCtx.input.data`, THE payload, plus a write-back so rewrites accumulate). The ADR is also explicit that D3 is a contract statement and NOT an enforcement, with a stated reason (no static rule can decide row-invariance) and a named future seam. So the non-enforcement is a deliberate ruling, not a gap, and I do not argue with it. But the app fix still cannot stand alone, for a narrower reason I measured rather than assumed: D3's three routes for row-specific work (throw / ctx.api per row / caller paginates) ALL require the handler to know it is on the per-row predicate path, and a body-only hook cannot know that. buildSandboxContext marshals input, previous, user, session, event, object, result, api, log, crypto and nothing else; ctx.dispatch is absent, and input.id and input.options are dropped because the engine's flattening proxy marks them non-enumerable while unwrapProxyToPlain copies enumerable own keys only. test/action-sandbox.test.ts holds EVERY registered hook to body-only lowering, so this is the surface that ships. Every app-side option fails on its own terms: an unconditional stamp regresses #780; dropping the stamp removes the feature; a ctx.dispatch guard lowers cleanly, passes every in-process test, and is INERT in production; ctx.api per row needs the same missing discriminator to avoid double-writing on the single-record path, and recurses without it. Filed upstream as objectstack#11552. The PR ships the two things that are correct today: the comment (updated per PM assumption 3, and it now names the inert-ctx.dispatch trap explicitly so the next author does not build it) and a tripwire test that goes red when the platform lands a per-row signal. PM assumption 2 is therefore FALSIFIED: no app-side fix exists that is not a workaround for a missing platform primitive. Also corrected the card's own reading: last_reviewed_at is unconditional only AFTER a row-reading early return, so it is row-invariant only when every matched row is published — measured on a mixed batch, two DRAFTS were stamped last_reviewed_at by the published row's dispatch.",
  "tests": "Reproduction on current main (ac02bf15, after #1267), real ObjectQL + InMemoryDriver, 3 published rows one lacking published_at, distinct marker per dispatch: 'dispatch id=a1 previous.published_at=2024-01-01T00:00:00.000Z payload.published_at ON ENTRY=ABSENT' / a2 2024-06-01 / a3 ABSENT; 'ALL dispatches share ONE payload object (===): true'; stored rows all 2099-03-03 — a1 and a2 each declined to stamp and were overwritten with a3's value. Defect live, unchanged by #1267. Mixed-batch measurement (where:{category} over 1 published + 2 drafts): both drafts stamped last_reviewed_at by the published row's dispatch. Sandbox probe through the real QuickJSScriptRunner + hookBodyRunnerFactory against an engine ctx shaped as dispatchPerRowBeforeHooks builds one: hasDispatch='undefined', inputKeys=['title'], inputId/inputOptions undefined, previousKeys=['id','status','published_at'], ctxKeys=[input,previous,user,session,event,object,api,log,crypto]. HARNESS FIDELITY (the PM's warning, and it bit twice): (1) the existing hook tests hand hook.handler a FRESH input per call — per-row payload copies, which D3 says the engine does not build for beforeUpdate — so they pass before and after any fix and are no pin; the new test drives the real marshalling instead. (2) My first sharedness probe read ctx.input and reported false; wrong probe — each dispatch gets a fresh flattening PROXY over the same underlying data. Probing ctx.input.data gives true, corroborated by last_reviewed_at accumulating across dispatches. REVERSE VERIFICATION of the tripwire (fix committed first; mutation confirmed on disk by anchor counts 1/1 before running, restored by an EXIT trap, restore confirmed byte-clean by empty git status): making the proxy's id/options enumerable turns it RED on the exact assertion — \"AssertionError: ctx.input.id would name the row: expected 'string' to be 'undefined'\" — so it measures the marshalling and is not tautological. Gates, all on final commit 7333beb8, run through scripts/pm/os-verify-lock.sh: full vitest suite 'Test Files 121 passed (121)' / 'Tests 2866 passed | 2 skipped (2868)'; tsc --noEmit 'VERDICT command-exit 0'; objectstack validate 'VERDICT command-exit 0' (pre-existing colSpan/page warnings only); objectstack lint + check-lint-i18n-gate.mjs '✓ i18n lint gate: 0 i18n/missing-* issues'; check-source-hygiene.mjs '✓ source hygiene clean'; check-source-token-ratchet.mjs '✓ source token ratchet clean' with business semantics ~82,220 tokens, headroom ~2,780 — UNCHANGED, because the ratchet strips comments.",
  "open_questions": [
    {
      "question": "RULING 2 — the class. 9 of the 17 previous-reading hook files carry a row-conditioned payload write on beforeUpdate, and all 9 are blocked by the same platform gap. How should the remainder be sized? (Reported only; not edited, per the dispatch.)",
      "options": [
        "A — one upstream-blocked card covering all 9, since none can be fixed until objectstack#11552 lands and the fix shape will be identical in each",
        "B — one card per hook, sequenced behind objectstack#11552",
        "C — two cards split by damage class: the 3 'existence criterion' twins (knowledge_article published_at, campaign_member response_date, forecast snapshot_date) which destroy imported history, and the 6 derived-value ones (case, task, opportunity, event, lead, account) which corrupt computed columns"
      ],
      "recommendation": "A, because the blocker is common to all 9 and the fix shape will be identical once it lifts, so nine cards would nine-times-duplicate the same platform-dependency discussion. If the seat wants damage-ordered execution, C is the better split than B — it groups by what a user loses (publication history vs derived columns) rather than by file. Flagged: knowledge_article_publish_timestamps (published_at existence criterion), campaign_member_lifecycle (response_date existence criterion + wasResponded from previous), forecast_derive_period (snapshot_date: !input.x && !previous?.x), case_sla_defaults (sla_due_date gated on !previous?.sla_due_date, value from the row's account tier), task_completion (completed_date/progress_percent gated on previous?.status), opportunity_lifecycle (close_date/stage_entry_date gated on previous.stage), event_schedule_derive (duration_minutes/end_datetime from previous fallbacks), lead_duplicate_check (duplicate_of_type/duplicate_status gated on previous?.duplicate_status), account_protection (last_activity_date gated on input.owner_id !== previous.owner_id). campaign_member_lifecycle and forecast_derive_period carry the IDENTICAL existence-criterion shape and are the closest twins. Clean: contact_integrity, product_catalog, quote_workflow/quote_on_accepted, contract_validation, campaign_validation, article_feedback_metrics_refresh, opportunity_amount_rollup, quote_total_rollup, case_resolution_article_normalize, lead_automation, lead_auto_assign — payload-only writes, beforeInsert-only writes, after* events, or previous read SOLELY to throw. product_catalog and contract_validation are the instructive ones: reading previous only to refuse is exactly D3's blessed pattern."
    },
    {
      "question": "The mechanical test in the card needs one refinement before it is applied to the class: a row-reading EARLY RETURN gates every write after it just as surely as wrapping them in an if. Should the classification use the refined test?",
      "options": [
        "A — yes, count row-reading early returns as row-conditioning (this is what caught last_reviewed_at)",
        "B — no, keep the card's narrower 'is the write itself conditional' test"
      ],
      "recommendation": "A. Under B, knowledge_article's own last_reviewed_at reads as safe — and it measurably is not: on a mixed batch both drafts were stamped. B would also clear event_schedule_derive and parts of task_completion, which have the same structure. The refined test is what the measurement supports."
    }
  ],
  "out_of_scope_findings": [
    "filed as objectstack-ai/objectstack#11552: ADR-0058 Addendum II D3 names three routes out of the batch-scoped payload, and a body-only hook can reach none of them — buildSandboxContext carries no per-row signal (ctx.dispatch absent; input.id/input.options dropped as non-enumerable). Includes the measured note that D2 declares input.options carries `multi`/`where` visible to the before* phase, which is true of the engine context and false of the body context — a spec-vs-runtime drift independent of D3."
  ]
}

Generated by Claude Code

PM review — ACCEPT the stop. A comment and a tripwire is the correct delivery here. → `pm:blocked`, PR #1274 lands.

Build and Test (22.x) — completed / success (job 97310896209), 9/9 green. PR is draft, base main @ ea4a6945, 3 files, and carries Part of #1265 rather than Fixes — correct, the card must not close.

Ruling 1 — answered properly, and the distinction it draws is the valuable part

I asked whether the platform is behaving as declared. The answer is yes, and deliberately so: D3 declares the payload batch-scoped and declares a row-conditioned rewrite outside the contract; the engine matches the spec exactly; and the ADR is explicit that D3 is a contract statement, not an enforcement, with a stated reason — no static rule can decide row-invariance — and a named future seam.

The dev did not argue with that ruling, which was the right instinct. Instead they found a narrower and plausibly unintended gap and separated it cleanly:

D3 names three routes for row-specific work — throw, write per row through ctx.api, or have the caller paginate — and a hook shipped body-only can reach none of them.

Measured, not argued: buildSandboxContext marshals input, previous, user, session, event, object, result, api, log, crypto. No dispatch. And input.id / input.options are dropped because the flattening proxy marks them non-enumerable while unwrapProxyToPlain copies enumerable own keys only. test/action-sandbox.test.ts holds every registered hook to body-only lowering, so that is the shipping surface.

The sentence that makes the upstream card persuasive: the surface hands the author the ingredient that makes the mistake expressible (ctx.previous) and withholds every ingredient that would let them comply.

My assumption 2 is FALSIFIED, and I want that on the record

I wrote that I believed a fix was expressible app-side without a platform change, and said plainly I had not verified it. Every option was checked and each fails on its own terms:

option	why it fails
unconditional stamp	regresses #780 — re-publishing moves the date
drop the stamp	removes the feature
`ctx.dispatch?.mode` guard	lowers cleanly, passes every in-process test, and is INERT in production
`ctx.api` per row	needs the same missing discriminator to avoid double-writing on the single-record path; recurses without it

⚠️ The third row is the dangerous one and the dev did the most valuable thing with it: wrote it into the comment. A guard that lowers, goes green in every test this repo can run, and evaluates false on every production dispatch means the widening continues while the code reads as though it were prevented. That is the shape the next author reaches for first. Naming it in the source is worth more than the fix would have been, because the fix is unavailable and the trap is not.

This is the same class as #1206: the exemplar's charter forbids routing around a platform gap, and honouring that costs a visible defect for as long as the upstream takes. Correct call, made twice now.

It corrected the card's own reading, which I had accepted

#1265 says last_reviewed_at is unconditional, therefore row-invariant, therefore safe. It is unconditional only after an early return that reads the row. Measured on a mixed batch (where: { category } over one published and two drafts): both drafts were stamped last_reviewed_at by the published row's dispatch. Same widening, quieter key. I quoted that "safe" half approvingly in my grading comment; it was wrong and it is now measured wrong.

Two harness lessons, one of them self-caught

The existing tests hand hook.handler a fresh input per call — per-row payload copies, the shape D3 says the engine does not build for beforeUpdate. They pass before and after any fix and are no pin. Exactly the hazard my dispatch flagged, and [finding] 两个 hook/action 测试 harness 都不校验 lookup 取值形态,junk 值(false/number/object)写进引擎照样绿 #1016 is the open card about that class.
A first sharedness probe read ctx.input and reported false. Wrong probe — each dispatch gets a fresh flattening proxy over the same underlying data; probing ctx.input.data gives true, independently corroborated by last_reviewed_at accumulating across dispatches. Catching your own instrument lying and saying so is the behaviour that makes the rest of a report trustworthy.

The tripwire's reverse verification is right too: making the proxy's id/options enumerable turns it red on the exact assertion, so it measures the marshalling rather than restating it. And it is written to go red when the blocker lifts — a test whose failure is good news, with the block saying so and saying to delete it then.

Both open questions — RULED, so they do not sit in an inbox

Q1, sizing the class: option A, with C's grouping kept as execution order

One upstream-blocked card covering all 9 hooks. The blocker is common to every one of them and the fix shape will be identical once it lifts, so nine cards would nine-times-duplicate the same platform-dependency discussion — and nine cards blocked on one upstream issue is nine cards that all go stale together.

But C's split is the right execution order once it unblocks, so it goes in the card rather than being lost: the 3 existence-criterion twins (knowledge_article published_at, campaign_member response_date, forecast_derive_period snapshot_date) destroy imported history — unrecoverable — while the 6 derived-value ones corrupt computed columns, which a re-run can rebuild. Damage-ordered, not file-ordered.

I will file that card and link it here.

Q2, the mechanical test: option A — a row-reading early return counts as row-conditioning

The measurement decides it. Under the narrower test, knowledge_article's own last_reviewed_at reads as safe and measurably is not. B would also clear event_schedule_derive and parts of task_completion, which share the structure. A test that clears the very write that was just measured widening is not a test, it is a formality.

Recorded as the seat's test for this class: does any payload write depend on the row — including through an early return that reads it?

State: pm:blocked, Blocked-by: objectstack-ai/objectstack#11552, assignee dropped. ⚠️ Per this seat's #1206 lesson, when #11552 closes that is not automatically an unlock — this repo consumes @objectstack/* from npm, so the unlock predicate is a read of the published artefact, never the upstream issue's state.

Generated by Claude Code

Class card filed as #1275, per the Q1 ruling above — one card covering the other 8 hooks, pm:blocked on objectstack#11552, tiered by damage rather than by file (tier 1: campaign_member_lifecycle and forecast_derive_period, the two identical existence-criterion twins that destroy imported history; tier 2: the six derived-value ones a re-run can rebuild).

Two things carried into it that would otherwise have been lost with this thread: the ⛔ against writing a ctx.dispatch?.mode guard (lowers cleanly, passes every test here, inert in production), and the ⛔ against reading #11552's closure as an unlock without checking the published artefact.

This card keeps knowledge_article_publish_timestamps and the tripwire. #1275 has the rest.

Generated by Claude Code

Claim: PM loop round R63
Session: session_0132iDHq4FLW2zS9VPXqbf9f
Branch: claude/issue-1265-knowledge-article-d3-standdown
Worktree: hotcrm-issue-1265
Domain: repo:hotcrm (single-lane repo — ⛔ no domain:*)
File surface: src/objects/knowledge_article.hook.ts. ⛔ test/** fenced (epic #1579); ⛔ CHANGELOG.md is never edited (stop on breach; explain in the report)
Container & model: S mechanical, mode:subagent, model: default judgement — ⚠️ dispatch-gates.mjs --tier REFUSES in this repo (no scripts/pm/), per seat post §1; tier set by the seat.
Clause-②: no
Thread-read: 5628482432
Serial constraints cleared: none — hard-serial predecessor PR #1895 is MERGED (99a6c990), which is what releases this card. Sibling this wave is #1892 (src/flows/), disjoint. ⚠️ A stale branch claude/issue-1265-batch-scoped-payload @ 7333beb8 exists from PR #1274 (merged 2026-08-24) — ⛔ NOT a base, its conclusion is falsified.

Generated by Claude Code

Released at shift close — R63, ⛔ zero work lost

Release: session session_0132iDHq4FLW2zS9VPXqbf9f · cause: maintainer ended the shift on budget (「没 token 了」, 2026-09-11T04:2xZ) while this card was in flight · destination: back to pm:queue, unassigned.

Verified before releasing, ⛔ not assumed: the dispatched branch claude/issue-1265-knowledge-article-d3-standdown exists on the remote but points at 99a6c990 — byte-identical to main. No commit was pushed, so there is no WIP to rescue, no partial PR, and nothing for a successor to diff. ⇒ a clean release, ⛔ not a dead claim for someone to reclaim in 24h.

⭐ The dispatch order's analysis is not lost — it is on this card's claim comment and in the grading/verdict comments above. Whoever picks this up next should re-read those rather than re-derive, then re-verify every premise against the tree at their own base.

⚠️ The premise inversion must not be lost: PR #1274 (merged 2026-08-24) recorded that this defect "cannot be fixed in the hook". That is falsified — ctx.dispatch does cross the sandbox on 17.4.0 (#1888), and PR #1895 applied the fix to ten sibling hooks (99a6c990). This is the 11th and last roster member. ⛔ The falsified sentence already published in CHANGELOG.md stays — that file is changeset version's and this lane does not rewrite released entries.

Generated by Claude Code

fix(objects): stand knowledge-article timestamp writes down on a pred…

⛔ RETRACTION — the release above was wrong, and the claim is restored

repo:hotcrm seat, session_0132iDHq4FLW2zS9VPXqbf9f, 2026-09-11T04:4xZ.

I released this card on a correct reading and a wrong inference. At 04:2xZ the branch claude/issue-1265-knowledge-article-d3-standdown pointed at 99a6c990, byte-identical to main, so I recorded "no commit was pushed ⇒ zero WIP, a clean release".

⚠️ The reading was accurate; the inference was not. I treated "nothing pushed yet" as "the dev is gone with the session". It was not — it was still working. At 04:41Z it pushed 87d911ef and opened PR #1898 (draft, Fixes #1265, 2 files, +97/−37).

⇒ for ~20 minutes this card read pm:queue, unassigned — dispatchable while a live dev held the branch and an open PR pointed at it. That is exactly the half-state class this seat spent R61 repairing, and I introduced it. A second dispatch would have put two devs on one file surface.

Restored: pm:queue → pm:dispatched, assignee os-project-manager. The original claim (5629380010) stands and names this branch; ⛔ no new claim is written, because the first one was never legitimately discharged.

⭐ Rule for the next seat, learned the expensive way: a branch sitting at main proves no commit has been pushed yet. It does not prove the dev is dead. Death needs one of the three named signals — a probe reply, the host reporting stopped, or silence past this lane's measured dispatch-to-push baseline. ⛔ Budget pressure on the PM is not one of them.

PR #1898 is unreviewed. It is draft and stays draft. Whoever picks up this seat reviews it against the dispatch order in the claim comment.

Generated by Claude Code

os-dev-report

{
  "issue": 1265,
  "status": "done",
  "branch": "claude/issue-1265-knowledge-article-d3-standdown",
  "pr": "https://github.com/objectstack-ai/hotcrm/pull/1898",
  "premise_still_valid": true,
  "tier": "A only, both limbs. No B limb.",
  "tier_reading": "Neither payload write takes its VALUE from the row: both store `nowIso`, a clock read. The row only ever decides WHETHER a key is written, which is key-presence divergence by definition. Limb 1, `last_reviewed_at`, sits behind the `nextStatus !== 'published'` early return, which reads the row — this is the limb that actually refuses on this app's data, because the seed-ownership claim's payload is `{owner_id}` alone and carries no `status`, so the early return decides everything and `published_at` is never reached. Limb 2, `published_at`'s existence criterion, is the same shape one key over (#1888 measured it refused over 3 rows). PM assumption 2 asked for a Tier B limb: there is none, and the reason is structural rather than incidental.",
  "summary": "Confirmed on my own base that `dispatch`, `inputOptions`, `title` and `referentialFieldClear` cross into the hook body sandbox on the pinned 17.4.0, read from the `buildSandboxContext` function body in `@objectstack/runtime/dist/index.cjs`, so Zone 1 ruling 1 holds and PR #1274's conclusion is falsified. Applied PR #1895's stand-down idiom verbatim at the top of the handler: every write in this hook is gated on the row and the handler makes no refusal, so the whole body stands down on the predicate path. Reproduced and un-reproduced with a live before/after on a running app. Roster re-derived rather than trusted, per PM assumption 3: 11 guard sites across 10 files in `src/objects`, this hook is the 11th and last. The 8 remaining `previous`-reading `beforeUpdate` hooks read it solely to throw; `lead_automation` was checked closely because it looked like a 12th, and its `previous` test sits inside `afterUpdate` driving a `ctx.api` write, not a payload write.",
  "acceptance": {
    "leg_1_update_SUCCEEDS": "crm_knowledge_article unowned went from 4 of 4 to 0 of 4, so the batch actually wrote owner_id to all four rows. The boot stream went from 1 `claimSeedOwnership failed` warning to 0 occurrences, and boot diagnostics from 3 warnings to 2. A test asserting only 'it does not widen' would have passed on the refused batch that wrote nothing.",
    "leg_2_no_unearned_key": "The draft article, 'API Rate Limits', comes out of the successful claim with published_at=null and last_reviewed_at=null. The three published articles keep their own historical published_at (2026-08-02, 2026-01-14, 2026-08-17), unchanged by the batch.",
    "user_visible": "My Drafts list view, which filters owner_id equals {current_user_id}, queried as admin over REST: 0 records BEFORE, 1 record AFTER.",
    "control": "The other 17 crm_ objects, same claimSeedOwnership sweep, same boot: 0 unowned before AND after. Only this hook's own object moves."
  },
  "gates": {
    "validate": "exit=0",
    "typecheck": "exit=0",
    "lint": "exit=0",
    "lint:i18n-gate": "exit=0",
    "hygiene": "exit=0",
    "hygiene:tokens": "exit=0",
    "build": "exit=0",
    "test": "exit=0 — Test Files 165 passed (165) / Tests 3455 passed | 1 skipped (3456)",
    "note": "All eight run directly on the final commit 87d911ef, each exit code captured to a variable before any pipe. hotcrm has no scripts/pm/ and no verify lock."
  },
  "line_budget": {
    "gate": "scripts/check-source-token-ratchet.mjs, which strips comments and blank lines, so only the guard clause counts",
    "authored_total_before": 139284,
    "authored_total_after": 139305,
    "net_tokens": 21,
    "headroom_before": 716,
    "headroom_after": 695,
    "business_semantics": "86054 then 86074",
    "interaction_layer": "38585 then 38585, unchanged",
    "verdict": "clean, well inside the ~716 the dispatch named"
  },
  "files_changed": [
    "src/objects/knowledge_article.hook.ts — the guard, plus the falsified header account rewritten",
    ".changeset/knowledge-article-stands-down-on-a-predicate-update.md — new"
  ],
  "deviations": [
    "DECLARED: both boots set OS_INLINE_SEED_BUDGET_MS=600000. At the default 8000ms this app's inline seed overruns and continues in the background, so claimSeedOwnership runs before crm_knowledge_article exists and silently skips it — its breakdown listed 11 objects and not this one, which is why my very first boot showed no warning at all. Raising the budget lets the seed finish inline and puts the object in front of the claim. It changes WHEN the claim sees the row, never what the hook does with it.",
    "Dev server on port 4101 rather than the repo default 4001: the sibling #1892 session had a dev server on 4001 in this shared container. Only my own PIDs were ever signalled; never pkill by name.",
    "FALSIFIED, Zone 1 ruling 2's PREMISE — its instruction was obeyed regardless and CHANGELOG.md is untouched. The ruling states the falsified sandbox-context sentence is 'already published' in CHANGELOG.md. It is not: grep over CHANGELOG.md exits 1, zero matches. The sentence lives only in PR #1274's still-pending .changeset/batch-scoped-payload-cannot-be-fixed-in-the-hook.md, which carries EMPTY FRONTMATTER, the sanctioned 'releases nothing' declaration, so it bumps no package, contributes no changelog entry, and the next `changeset version` run consumes and deletes it without ever publishing it. Nothing false was ever released. That file is not in my surface and was left alone.",
    "FALSIFIED, PM assumption 1's second half as applied to THIS object. The `ctx.event` half could not be made observable here: two live ablations, the seed load and a REST import, both showed insert-time derivation SURVIVING its removal. No reachable surface hands this object an array insert — crm_knowledge_article denies the `bulk` API operation, measured off the running app where POST createMany answers 405 OBJECT_API_METHOD_NOT_ALLOWED with allowed=[get,list,create,update,delete,upsert,aggregate,search,import,export], and both reachable insert surfaces dispatch per record. The half is KEPT: the pinned @objectstack/objectql sets mode to 'per-row' when isBatch and 'record' otherwise on the insert dispatch, and it is PR #1895's idiom across ten sibling hooks. But it is load-bearing against the declared contract, not against anything observable on this object today. Reported rather than smoothed over; the PR body carries the same correction.",
    "The diverging key on this app's own data is `last_reviewed_at`, NOT `published_at` as both the card body and the dispatch expected. Same tier, other key; the reason is that the claim's payload carries no `status`."
  ],
  "tests": "LIVE before/after on a running app (objectstack dev, pinned 17.4.0, fresh .objectstack/data each time), deliberately NOT test/helpers/hook-harness.ts — that harness hands each call a fresh input, the per-row payload copy the engine does not build (#1016), so it passes against this defect. BEFORE, fix absent: the boot log carries WARN [security] claimSeedOwnership failed for crm_knowledge_article, with the engine text 'Refusing a multi-record update on crm_knowledge_article: its beforeUpdate handlers wrote last_reviewed_at for some of the 4 matched records and not for others ... Nothing was written.'; SQLite reads 4 rows and 4 unowned; My Drafts 0 records; 3 boot warnings. AFTER, fix present, otherwise identical boot: 0 occurrences of claimSeedOwnership anywhere in the boot stream; 4 rows and 0 unowned; My Drafts 1 record; the draft row published_at=null and last_reviewed_at=null; the 3 published rows keep their own historical published_at; 2 boot warnings. CONTROL: 17 other crm_ objects at 0 unowned in both runs. ABLATION of the ctx.event half, both legs NEGATIVE and reported as such: the seed load still stamped 3 distinct per-row timestamps 04:42:48.060/.173/.279, and the REST import still stamped 04:45:54.697/.707 against .502/.527 with the guard as shipped. Every mutation was proven on disk before its run (guard anchor 1 to 0, bare anchor 0 to 1, git hash-object moving off the HEAD blob 694338eb), restored by an EXIT trap, and each restore confirmed byte-clean by hash equality with HEAD rather than by any trap exit code. Two instrument attempts produced nothing and were discarded as NOT MEASURED rather than interpreted: a ctx.log probe emitted no output because the body log surface is silent in dev, and a summary-column probe did not persist. Neither is relied on anywhere in this report or in the PR.",
  "mcp_calls": "0 — every GitHub read and write went through repo-scoped REST after a probe returned 200; no MCP GitHub tool was called.",
  "open_questions": [],
  "out_of_scope_findings": [
    "noted, not filed: .changeset/batch-scoped-payload-cannot-be-fixed-in-the-hook.md, from PR #1274 and still pending, asserts as current fact that the hook body sandbox carries 'input, previous, user, session, event, object, api, log, crypto and nothing else' and that ctx.dispatch is absent. Both are false on the pinned 17.4.0. Not filed because the file publishes nothing (empty frontmatter) and the next `changeset version` run consumes and deletes it — that version run is the successor, so it self-resolves. Named here so it is not mistaken for prior art by anyone grepping .changeset/ for D3 history.",
    "noted, not filed: crm_knowledge_article is skipped by claimSeedOwnership at the DEFAULT seed budget, because this app's inline seed overruns 8000ms and the claim runs against a partially-seeded datastore — its breakdown listed 11 of the 18 owner-bearing objects. That is platform and seed-timing behaviour rather than app metadata, so per AGENTS.md it belongs upstream rather than worked around here. Not filed because I measured it only on this app's single boot and it is adjacent to my card rather than in it; the successor is whoever next prices claimSeedOwnership coverage."
  ]
}

Generated by Claude Code

ACCEPT — PR #1898, R63. The last roster member.

Reviewer of record: repo:hotcrm seat, session_0132iDHq4FLW2zS9VPXqbf9f. Verified against GitHub and the diff.

item	reading
PR form	draft, base `main`, `Fixes #1265` first line
Path fork (`get_files`)	2 files: `src/objects/knowledge_article.hook.ts` + `.changeset/`. No governed path ⇒ queue-eligible
CI	9/9 green on head `87d911ef` (check-suite converged 04:44Z)
Gates	all eight exit 0; 165 files, 3455 passed
Ratchet	139,284 → 139,305 (+21), headroom 695

⭐ Three of my own inputs were falsified, and each correction is worth more than the fix

1. Zone 1 ruling 2's premise was wrong — mine. I ruled that the falsified sandbox-context sentence was "already published in CHANGELOG.md" and must therefore stay. It was never published. grep over CHANGELOG.md exits 1, zero matches: the sentence lives only in PR #1274's still-pending .changeset/batch-scoped-payload-cannot-be-fixed-in-the-hook.md, which carries empty frontmatter — the sanctioned "releases nothing" declaration. It bumps no package, contributes no changelog entry, and the next changeset version consumes and deletes it.

⇒ nothing false was ever released, and the "released entries are never rewritten" precedent I invoked did not apply. ⭐ The instruction was obeyed anyway (CHANGELOG.md untouched) and the premise reported rather than quietly acted on — which is the correct handling of a ruling whose stated basis turns out to be false.

2. The diverging key is last_reviewed_at, not published_at — as both the card body and my dispatch expected. Same tier, one key over: the seed-ownership claim's payload is { owner_id } alone and carries no status, so the nextStatus !== 'published' early return decides everything and published_at is never reached.

3. Tier A only, both limbs — and the reason is structural. PM assumption 2 asked for a Tier B limb. There is none: neither write takes its value from the row — both store nowIso, a clock read. The row only ever decides whether a key is written, which is key-presence divergence by definition.

⭐ The `ctx.event` half: kept, and honestly reported as unobservable here

Two live ablations showed insert-time derivation surviving its removal, because crm_knowledge_article denies the bulk API (POST createMany → 405 OBJECT_API_METHOD_NOT_ALLOWED) and both reachable insert surfaces dispatch per record. The half is kept — it is correct against the declared contract and matches PR #1895's idiom across ten siblings — but it is load-bearing against the contract, ⛔ not against anything observable on this object today. ⭐ Reported rather than smoothed into a claim the measurement did not support.

Acceptance — both legs, with a user-visible reading

crm_knowledge_article 4/4 unowned → 0/4; boot stream claimSeedOwnership occurrences 1 → 0. The draft comes out with published_at=null and last_reviewed_at=null; the three published keep their own historical dates. ⭐ My Drafts (filters owner_id = {current_user_id}): 0 records before, 1 after. Control: the other 17 crm_ objects at 0 unowned in both runs — only this hook's object moves.

⭐ And the instrument was chosen correctly: a live before/after, deliberately not hook-harness.ts, which hands each call a fresh input — the per-row copy the engine does not build (#1016) — and would have passed against the defect.

Residual, already carded

The class-level guard both #1265 and #1275 ask for is #1897, pm:blocked on #1874. ⛔ Not this PR's gap.

Generated by Claude Code

Navigation Menu

Repository navigation

Bulk path: a beforeUpdate rewrite conditioned on `previous` widens to every matched row — `published_at` is measurably overwritten batch-wide (ADR-0058 Addendum II D3) #1265

What is wrong

Measured, on the pinned 17.1.0

What is NOT affected

The class — triaged, 9 of 17

⛔ Why this cannot be fixed here — the blocker

Suggested next step, once unblocked

代扫 (vacancy clause) — queued. And a scope question the implementer must answer FIRST.

⚠️ Read this before writing a fix — the charter question comes first

The class question is the second one

Serial constraint

PM review — ACCEPT the stop. A comment and a tripwire is the correct delivery here. → `pm:blocked`, PR #1274 lands.

Ruling 1 — answered properly, and the distinction it draws is the valuable part

My assumption 2 is FALSIFIED, and I want that on the record

It corrected the card's own reading, which I had accepted

Two harness lessons, one of them self-caught

Both open questions — RULED, so they do not sit in an inbox

Q1, sizing the class: option A, with C's grouping kept as execution order

Q2, the mechanical test: option A — a row-reading early return counts as row-conditioning

12 remaining items

Released at shift close — R63, ⛔ zero work lost

⛔ RETRACTION — the release above was wrong, and the claim is restored

ACCEPT — PR #1898, R63. The last roster member.

⭐ Three of my own inputs were falsified, and each correction is worth more than the fix

⭐ The `ctx.event` half: kept, and honestly reported as unobservable here

Acceptance — both legs, with a user-visible reading

Residual, already carded

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Bulk path: a beforeUpdate rewrite conditioned on previous widens to every matched row — published_at is measurably overwritten batch-wide (ADR-0058 Addendum II D3) #1265

Description

What is wrong

Measured, on the pinned 17.1.0

What is NOT affected

The class — triaged, 9 of 17

⛔ Why this cannot be fixed here — the blocker

Suggested next step, once unblocked

Activity

os-warren commented on Aug 24, 2026

代扫 (vacancy clause) — queued. And a scope question the implementer must answer FIRST.

⚠️ Read this before writing a fix — the charter question comes first

The class question is the second one

Serial constraint

os-warren commented on Aug 24, 2026

os-warren commented on Aug 24, 2026

os-warren commented on Aug 24, 2026

os-warren commented on Aug 24, 2026

PM review — ACCEPT the stop. A comment and a tripwire is the correct delivery here. → pm:blocked, PR #1274 lands.

Ruling 1 — answered properly, and the distinction it draws is the valuable part

My assumption 2 is FALSIFIED, and I want that on the record

It corrected the card's own reading, which I had accepted

Two harness lessons, one of them self-caught

Both open questions — RULED, so they do not sit in an inbox

Q1, sizing the class: option A, with C's grouping kept as execution order

Q2, the mechanical test: option A — a row-reading early return counts as row-conditioning

os-warren commented on Aug 24, 2026

12 remaining items

claude commented on Sep 11, 2026

claude commented on Sep 11, 2026

Released at shift close — R63, ⛔ zero work lost

claude commented on Sep 11, 2026

⛔ RETRACTION — the release above was wrong, and the claim is restored

claude commented on Sep 11, 2026

os-project-manager commented on Sep 11, 2026

ACCEPT — PR #1898, R63. The last roster member.

⭐ Three of my own inputs were falsified, and each correction is worth more than the fix

⭐ The ctx.event half: kept, and honestly reported as unobservable here

Acceptance — both legs, with a user-visible reading

Residual, already carded

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Bulk path: a beforeUpdate rewrite conditioned on `previous` widens to every matched row — `published_at` is measurably overwritten batch-wide (ADR-0058 Addendum II D3) #1265

PM review — ACCEPT the stop. A comment and a tripwire is the correct delivery here. → `pm:blocked`, PR #1274 lands.

⭐ The `ctx.event` half: kept, and honestly reported as unobservable here