Task lifecycle hook — completed_at and last_update_at stamping

[os-warren]

Fixes#3

Two server-owned timestamps on duly_task, written by one hook registered in dulyHooks.

What it does

beforeInsert — stamps last_update_at. A brand-new task has just been touched, by definition.

beforeUpdate

• transition intodone → completed_at = now
• transition out ofdone → completed_at = null
• last_update_at = now only when status, note or skip_reasonactually changed against the pre-image

Everything keys off ctx.previous, so these are transitions rather than states. That is what stops a whole-record form re-submitting status: 'done' from overwriting the original completion instant on every save, and what makes "re-saving with no changes" a no-op.

The stagnation signal

last_update_at feeds the "Not moving" view — status in (open, in_progress) AND last_update_at < {14_days_ago}. A hook that stamped on every update would let one bulk re-owner, a business-unit backfill or an import silently reset the clock across the whole table. Nothing errors; the numbers just quietly improve and the signal goes quiet exactly when it matters.

So the touch list is exactly status, note, skip_reason. owner, business_unit, assignment, duty, due_date, visible_from, period_key, source and subject are deliberately excluded, and three of them are asserted directly:

✓ does NOT advance on an administrative write (business_unit)
✓ does NOT advance on a re-owner
✓ does NOT advance on a re-date
✓ does NOT advance on a re-save with no changes

A context with no pre-image — the whole-operation dispatch of an unscoped predicate write, i.e. the bulk write this hook most needs to survive — stamps nothing at all.

Three platform assumptions, verified rather than assumed

All three held. Measured against a real booted engine, not read off the docs:

Assumption	Verdict
beforeUpdate can see the previous field values	True. The engine binds hookContext.previous from a pre-read of the row before dispatching the beforeUpdate chain, and throws recordNotFoundError if that read comes back empty — so on the by-id path it is always present. Pinned by a probe hook in the suite.
A beforeUpdate stamp lands ahead of validation	True. Order is beforeUpdate → validateRecord → readonly strip → evaluateValidationRules. A write carrying only { status: 'done' } therefore commits.
readonly stripping blocks caller values while the hook's write passes	True, with one edge — see #31. The strip drops a readonly key only when its value is still exactly what the caller supplied, so a hook-derived value replaces a caller-supplied one.

Tests

test/task-hook.test.ts boots a real ObjectQL engine (in-memory driver) with this app's own objectstack.config.ts as the bundle. The handler runs only because AppPlugin found it in the real config, so the suite cannot pass on dead metadata.

Two things worth flagging to a reviewer:

The suite is pinned away from the build artifact. Left at its default, createStandaloneStack resolves dist/objectstack.json under the working directory, and when a local pnpm build has left one there the kernel loads its metadata — objects and hooks — from that file instead of from the config. The suite then reports on the last build rather than on src/, and behaves differently in CI (where pnpm test runs before pnpm build) than on a developer's machine. This is not hypothetical: it is what made the registration ablation come back green. The artifactPath sentinel in beforeAll is what closes it.

A negative control guards the completion assertions.completed_at_required_when_done is asserted to still refuse an insert of a done task, so if that rule ever goes quiet the completion tests stop proving anything.

Both ablations were run to confirm the assertions can fail:

• stamping last_update_at unconditionally (the classic wrong hook) → 5 failed, including the business_unit assertion
• removing the entry from dulyHooks → 11 failed, the registration and every positive behaviour test

Not in this PR

The attachment clause is not implemented — filed as #28. #3 asks for last_update_at to advance on "an attachment", but attachments are sys_attachment rows carrying parent_object/parent_id, so adding one is an insert on that object and no duly_task write happens at all. It needs a second hook on sys_attachment, an isSystem write-back to get past the readonly strip, and answers to product questions #3 did not settle (does removing an attachment count? does an importer's?).

Also filed: #31 (reopening fails to clear completed_at when the caller also sends completed_at: null — an upstream Object.is limitation in the readonly strip, deliberately not worked around here) and #32 (a task cannot be created directly in done — needs a product decision).

Gates

All four green at 864ba78:

pnpm validate ✓ Validation passed (237ms)
pnpm typecheck exit 0
pnpm test Test Files 2 passed (2) · Tests 27 passed (27)
pnpm build ✓ Build complete · dist/objectstack.json (53.3 KB)

The handler is written as one self-contained function so objectstack build lowers it to a metadata body rather than falling back to the legacy bundled runtime module — a fallback that only warns. The lowered body was executed against the real QuickJS sandbox to confirm it behaves identically there, since that is the surface a served artifact runs.

src/objects/task.object.ts was not touched.

---

Generated by Claude Code

[os-warren]

Fixes#3

Two server-owned timestamps on duly_task, written by one hook registered in dulyHooks.

What it does

beforeInsert — stamps last_update_at. A brand-new task has just been touched, by definition.

beforeUpdate

• transition intodone → completed_at = now
• transition out ofdone → completed_at = null
• last_update_at = now only when status, note or skip_reasonactually changed against the pre-image

Everything keys off ctx.previous, so these are transitions rather than states. That is what stops a whole-record form re-submitting status: 'done' from overwriting the original completion instant on every save, and what makes "re-saving with no changes" a no-op.

The stagnation signal

last_update_at feeds the "Not moving" view — status in (open, in_progress) AND last_update_at < {14_days_ago}. A hook that stamped on every update would let one bulk re-owner, a business-unit backfill or an import silently reset the clock across the whole table. Nothing errors; the numbers just quietly improve and the signal goes quiet exactly when it matters.

So the touch list is exactly status, note, skip_reason. owner, business_unit, assignment, duty, due_date, visible_from, period_key, source and subject are deliberately excluded, and three of them are asserted directly:

✓ does NOT advance on an administrative write (business_unit)
✓ does NOT advance on a re-owner
✓ does NOT advance on a re-date
✓ does NOT advance on a re-save with no changes

A context with no pre-image — the whole-operation dispatch of an unscoped predicate write, i.e. the bulk write this hook most needs to survive — stamps nothing at all.

Three platform assumptions, verified rather than assumed

All three held. Measured against a real booted engine, not read off the docs:

Assumption	Verdict
beforeUpdate can see the previous field values	True. The engine binds hookContext.previous from a pre-read of the row before dispatching the beforeUpdate chain, and throws recordNotFoundError if that read comes back empty — so on the by-id path it is always present. Pinned by a probe hook in the suite.
A beforeUpdate stamp lands ahead of validation	True. Order is beforeUpdate → validateRecord → readonly strip → evaluateValidationRules. A write carrying only { status: 'done' } therefore commits.
readonly stripping blocks caller values while the hook's write passes	True, with one edge — see #31. The strip drops a readonly key only when its value is still exactly what the caller supplied, so a hook-derived value replaces a caller-supplied one.

Tests

test/task-hook.test.ts boots a real ObjectQL engine (in-memory driver) with this app's own objectstack.config.ts as the bundle. The handler runs only because AppPlugin found it in the real config, so the suite cannot pass on dead metadata.

Two things worth flagging to a reviewer:

The suite is pinned away from the build artifact. Left at its default, createStandaloneStack resolves dist/objectstack.json under the working directory, and when a local pnpm build has left one there the kernel loads its metadata — objects and hooks — from that file instead of from the config. The suite then reports on the last build rather than on src/, and behaves differently in CI (where pnpm test runs before pnpm build) than on a developer's machine. This is not hypothetical: it is what made the registration ablation come back green. The artifactPath sentinel in beforeAll is what closes it.

A negative control guards the completion assertions.completed_at_required_when_done is asserted to still refuse an insert of a done task, so if that rule ever goes quiet the completion tests stop proving anything.

Both ablations were run to confirm the assertions can fail:

• stamping last_update_at unconditionally (the classic wrong hook) → 5 failed, including the business_unit assertion
• removing the entry from dulyHooks → 11 failed, the registration and every positive behaviour test

Not in this PR

The attachment clause is not implemented — filed as #28. #3 asks for last_update_at to advance on "an attachment", but attachments are sys_attachment rows carrying parent_object/parent_id, so adding one is an insert on that object and no duly_task write happens at all. It needs a second hook on sys_attachment, an isSystem write-back to get past the readonly strip, and answers to product questions #3 did not settle (does removing an attachment count? does an importer's?).

Also filed: #31 (reopening fails to clear completed_at when the caller also sends completed_at: null — an upstream Object.is limitation in the readonly strip, deliberately not worked around here) and #32 (a task cannot be created directly in done — needs a product decision).

Gates

All four green at 864ba78:

pnpm validate ✓ Validation passed (237ms)
pnpm typecheck exit 0
pnpm test Test Files 2 passed (2) · Tests 27 passed (27)
pnpm build ✓ Build complete · dist/objectstack.json (53.3 KB)

The handler is written as one self-contained function so objectstack build lowers it to a metadata body rather than falling back to the legacy bundled runtime module — a fallback that only warns. The lowered body was executed against the real QuickJS sandbox to confirm it behaves identically there, since that is the surface a served artifact runs.

src/objects/task.object.ts was not touched.

---

Generated by Claude Code

[os-warren]

Fixes#3

Two server-owned timestamps on duly_task, written by one hook registered in dulyHooks.

What it does

beforeInsert — stamps last_update_at. A brand-new task has just been touched, by definition.

beforeUpdate

• transition intodone → completed_at = now
• transition out ofdone → completed_at = null
• last_update_at = now only when status, note or skip_reasonactually changed against the pre-image

Everything keys off ctx.previous, so these are transitions rather than states. That is what stops a whole-record form re-submitting status: 'done' from overwriting the original completion instant on every save, and what makes "re-saving with no changes" a no-op.

The stagnation signal

last_update_at feeds the "Not moving" view — status in (open, in_progress) AND last_update_at < {14_days_ago}. A hook that stamped on every update would let one bulk re-owner, a business-unit backfill or an import silently reset the clock across the whole table. Nothing errors; the numbers just quietly improve and the signal goes quiet exactly when it matters.

So the touch list is exactly status, note, skip_reason. owner, business_unit, assignment, duty, due_date, visible_from, period_key, source and subject are deliberately excluded, and three of them are asserted directly:

✓ does NOT advance on an administrative write (business_unit)
✓ does NOT advance on a re-owner
✓ does NOT advance on a re-date
✓ does NOT advance on a re-save with no changes

A context with no pre-image — the whole-operation dispatch of an unscoped predicate write, i.e. the bulk write this hook most needs to survive — stamps nothing at all.

Three platform assumptions, verified rather than assumed

All three held. Measured against a real booted engine, not read off the docs:

Assumption	Verdict
beforeUpdate can see the previous field values	True. The engine binds hookContext.previous from a pre-read of the row before dispatching the beforeUpdate chain, and throws recordNotFoundError if that read comes back empty — so on the by-id path it is always present. Pinned by a probe hook in the suite.
A beforeUpdate stamp lands ahead of validation	True. Order is beforeUpdate → validateRecord → readonly strip → evaluateValidationRules. A write carrying only { status: 'done' } therefore commits.
readonly stripping blocks caller values while the hook's write passes	True, with one edge — see #31. The strip drops a readonly key only when its value is still exactly what the caller supplied, so a hook-derived value replaces a caller-supplied one.

Tests

test/task-hook.test.ts boots a real ObjectQL engine (in-memory driver) with this app's own objectstack.config.ts as the bundle. The handler runs only because AppPlugin found it in the real config, so the suite cannot pass on dead metadata.

Two things worth flagging to a reviewer:

The suite is pinned away from the build artifact. Left at its default, createStandaloneStack resolves dist/objectstack.json under the working directory, and when a local pnpm build has left one there the kernel loads its metadata — objects and hooks — from that file instead of from the config. The suite then reports on the last build rather than on src/, and behaves differently in CI (where pnpm test runs before pnpm build) than on a developer's machine. This is not hypothetical: it is what made the registration ablation come back green. The artifactPath sentinel in beforeAll is what closes it.

A negative control guards the completion assertions.completed_at_required_when_done is asserted to still refuse an insert of a done task, so if that rule ever goes quiet the completion tests stop proving anything.

Both ablations were run to confirm the assertions can fail:

• stamping last_update_at unconditionally (the classic wrong hook) → 5 failed, including the business_unit assertion
• removing the entry from dulyHooks → 11 failed, the registration and every positive behaviour test

Not in this PR

The attachment clause is not implemented — filed as #28. #3 asks for last_update_at to advance on "an attachment", but attachments are sys_attachment rows carrying parent_object/parent_id, so adding one is an insert on that object and no duly_task write happens at all. It needs a second hook on sys_attachment, an isSystem write-back to get past the readonly strip, and answers to product questions #3 did not settle (does removing an attachment count? does an importer's?).

Also filed: #31 (reopening fails to clear completed_at when the caller also sends completed_at: null — an upstream Object.is limitation in the readonly strip, deliberately not worked around here) and #32 (a task cannot be created directly in done — needs a product decision).

Gates

All four green at 864ba78:

pnpm validate ✓ Validation passed (237ms)
pnpm typecheck exit 0
pnpm test Test Files 2 passed (2) · Tests 27 passed (27)
pnpm build ✓ Build complete · dist/objectstack.json (53.3 KB)

The handler is written as one self-contained function so objectstack build lowers it to a metadata body rather than falling back to the legacy bundled runtime module — a fallback that only warns. The lowered body was executed against the real QuickJS sandbox to confirm it behaves identically there, since that is the surface a served artifact runs.

src/objects/task.object.ts was not touched.

---

Generated by Claude Code

[os-warren]

Fixes#3

Two server-owned timestamps on duly_task, written by one hook registered in dulyHooks.

What it does

beforeInsert — stamps last_update_at. A brand-new task has just been touched, by definition.

beforeUpdate

• transition intodone → completed_at = now
• transition out ofdone → completed_at = null
• last_update_at = now only when status, note or skip_reasonactually changed against the pre-image

Everything keys off ctx.previous, so these are transitions rather than states. That is what stops a whole-record form re-submitting status: 'done' from overwriting the original completion instant on every save, and what makes "re-saving with no changes" a no-op.

The stagnation signal

last_update_at feeds the "Not moving" view — status in (open, in_progress) AND last_update_at < {14_days_ago}. A hook that stamped on every update would let one bulk re-owner, a business-unit backfill or an import silently reset the clock across the whole table. Nothing errors; the numbers just quietly improve and the signal goes quiet exactly when it matters.

So the touch list is exactly status, note, skip_reason. owner, business_unit, assignment, duty, due_date, visible_from, period_key, source and subject are deliberately excluded, and three of them are asserted directly:

✓ does NOT advance on an administrative write (business_unit)
✓ does NOT advance on a re-owner
✓ does NOT advance on a re-date
✓ does NOT advance on a re-save with no changes

A context with no pre-image — the whole-operation dispatch of an unscoped predicate write, i.e. the bulk write this hook most needs to survive — stamps nothing at all.

Three platform assumptions, verified rather than assumed

All three held. Measured against a real booted engine, not read off the docs:

Assumption	Verdict
beforeUpdate can see the previous field values	True. The engine binds hookContext.previous from a pre-read of the row before dispatching the beforeUpdate chain, and throws recordNotFoundError if that read comes back empty — so on the by-id path it is always present. Pinned by a probe hook in the suite.
A beforeUpdate stamp lands ahead of validation	True. Order is beforeUpdate → validateRecord → readonly strip → evaluateValidationRules. A write carrying only { status: 'done' } therefore commits.
readonly stripping blocks caller values while the hook's write passes	True, with one edge — see #31. The strip drops a readonly key only when its value is still exactly what the caller supplied, so a hook-derived value replaces a caller-supplied one.

Tests

test/task-hook.test.ts boots a real ObjectQL engine (in-memory driver) with this app's own objectstack.config.ts as the bundle. The handler runs only because AppPlugin found it in the real config, so the suite cannot pass on dead metadata.

Two things worth flagging to a reviewer:

The suite is pinned away from the build artifact. Left at its default, createStandaloneStack resolves dist/objectstack.json under the working directory, and when a local pnpm build has left one there the kernel loads its metadata — objects and hooks — from that file instead of from the config. The suite then reports on the last build rather than on src/, and behaves differently in CI (where pnpm test runs before pnpm build) than on a developer's machine. This is not hypothetical: it is what made the registration ablation come back green. The artifactPath sentinel in beforeAll is what closes it.

A negative control guards the completion assertions.completed_at_required_when_done is asserted to still refuse an insert of a done task, so if that rule ever goes quiet the completion tests stop proving anything.

Both ablations were run to confirm the assertions can fail:

• stamping last_update_at unconditionally (the classic wrong hook) → 5 failed, including the business_unit assertion
• removing the entry from dulyHooks → 11 failed, the registration and every positive behaviour test

Not in this PR

The attachment clause is not implemented — filed as #28. #3 asks for last_update_at to advance on "an attachment", but attachments are sys_attachment rows carrying parent_object/parent_id, so adding one is an insert on that object and no duly_task write happens at all. It needs a second hook on sys_attachment, an isSystem write-back to get past the readonly strip, and answers to product questions #3 did not settle (does removing an attachment count? does an importer's?).

Also filed: #31 (reopening fails to clear completed_at when the caller also sends completed_at: null — an upstream Object.is limitation in the readonly strip, deliberately not worked around here) and #32 (a task cannot be created directly in done — needs a product decision).

Gates

All four green at 864ba78:

pnpm validate ✓ Validation passed (237ms)
pnpm typecheck exit 0
pnpm test Test Files 2 passed (2) · Tests 27 passed (27)
pnpm build ✓ Build complete · dist/objectstack.json (53.3 KB)

The handler is written as one self-contained function so objectstack build lowers it to a metadata body rather than falling back to the legacy bundled runtime module — a fallback that only warns. The lowered body was executed against the real QuickJS sandbox to confirm it behaves identically there, since that is the surface a served artifact runs.

src/objects/task.object.ts was not touched.

---

Generated by Claude Code

[os-warren]

Fixes#3

Two server-owned timestamps on duly_task, written by one hook registered in dulyHooks.

What it does

beforeInsert — stamps last_update_at. A brand-new task has just been touched, by definition.

beforeUpdate

• transition intodone → completed_at = now
• transition out ofdone → completed_at = null
• last_update_at = now only when status, note or skip_reasonactually changed against the pre-image

Everything keys off ctx.previous, so these are transitions rather than states. That is what stops a whole-record form re-submitting status: 'done' from overwriting the original completion instant on every save, and what makes "re-saving with no changes" a no-op.

The stagnation signal

last_update_at feeds the "Not moving" view — status in (open, in_progress) AND last_update_at < {14_days_ago}. A hook that stamped on every update would let one bulk re-owner, a business-unit backfill or an import silently reset the clock across the whole table. Nothing errors; the numbers just quietly improve and the signal goes quiet exactly when it matters.

So the touch list is exactly status, note, skip_reason. owner, business_unit, assignment, duty, due_date, visible_from, period_key, source and subject are deliberately excluded, and three of them are asserted directly:

✓ does NOT advance on an administrative write (business_unit)
✓ does NOT advance on a re-owner
✓ does NOT advance on a re-date
✓ does NOT advance on a re-save with no changes

A context with no pre-image — the whole-operation dispatch of an unscoped predicate write, i.e. the bulk write this hook most needs to survive — stamps nothing at all.

Three platform assumptions, verified rather than assumed

All three held. Measured against a real booted engine, not read off the docs:

Assumption	Verdict
beforeUpdate can see the previous field values	True. The engine binds hookContext.previous from a pre-read of the row before dispatching the beforeUpdate chain, and throws recordNotFoundError if that read comes back empty — so on the by-id path it is always present. Pinned by a probe hook in the suite.
A beforeUpdate stamp lands ahead of validation	True. Order is beforeUpdate → validateRecord → readonly strip → evaluateValidationRules. A write carrying only { status: 'done' } therefore commits.
readonly stripping blocks caller values while the hook's write passes	True, with one edge — see #31. The strip drops a readonly key only when its value is still exactly what the caller supplied, so a hook-derived value replaces a caller-supplied one.

Tests

test/task-hook.test.ts boots a real ObjectQL engine (in-memory driver) with this app's own objectstack.config.ts as the bundle. The handler runs only because AppPlugin found it in the real config, so the suite cannot pass on dead metadata.

Two things worth flagging to a reviewer:

The suite is pinned away from the build artifact. Left at its default, createStandaloneStack resolves dist/objectstack.json under the working directory, and when a local pnpm build has left one there the kernel loads its metadata — objects and hooks — from that file instead of from the config. The suite then reports on the last build rather than on src/, and behaves differently in CI (where pnpm test runs before pnpm build) than on a developer's machine. This is not hypothetical: it is what made the registration ablation come back green. The artifactPath sentinel in beforeAll is what closes it.

A negative control guards the completion assertions.completed_at_required_when_done is asserted to still refuse an insert of a done task, so if that rule ever goes quiet the completion tests stop proving anything.

Both ablations were run to confirm the assertions can fail:

• stamping last_update_at unconditionally (the classic wrong hook) → 5 failed, including the business_unit assertion
• removing the entry from dulyHooks → 11 failed, the registration and every positive behaviour test

Not in this PR

The attachment clause is not implemented — filed as #28. #3 asks for last_update_at to advance on "an attachment", but attachments are sys_attachment rows carrying parent_object/parent_id, so adding one is an insert on that object and no duly_task write happens at all. It needs a second hook on sys_attachment, an isSystem write-back to get past the readonly strip, and answers to product questions #3 did not settle (does removing an attachment count? does an importer's?).

Also filed: #31 (reopening fails to clear completed_at when the caller also sends completed_at: null — an upstream Object.is limitation in the readonly strip, deliberately not worked around here) and #32 (a task cannot be created directly in done — needs a product decision).

Gates

All four green at 864ba78:

pnpm validate ✓ Validation passed (237ms)
pnpm typecheck exit 0
pnpm test Test Files 2 passed (2) · Tests 27 passed (27)
pnpm build ✓ Build complete · dist/objectstack.json (53.3 KB)

The handler is written as one self-contained function so objectstack build lowers it to a metadata body rather than falling back to the legacy bundled runtime module — a fallback that only warns. The lowered body was executed against the real QuickJS sandbox to confirm it behaves identically there, since that is the surface a served artifact runs.

src/objects/task.object.ts was not touched.

---

Generated by Claude Code

[os-warren]

Fixes#3

Two server-owned timestamps on duly_task, written by one hook registered in dulyHooks.

What it does

beforeInsert — stamps last_update_at. A brand-new task has just been touched, by definition.

beforeUpdate

• transition intodone → completed_at = now
• transition out ofdone → completed_at = null
• last_update_at = now only when status, note or skip_reasonactually changed against the pre-image

Everything keys off ctx.previous, so these are transitions rather than states. That is what stops a whole-record form re-submitting status: 'done' from overwriting the original completion instant on every save, and what makes "re-saving with no changes" a no-op.

The stagnation signal

last_update_at feeds the "Not moving" view — status in (open, in_progress) AND last_update_at < {14_days_ago}. A hook that stamped on every update would let one bulk re-owner, a business-unit backfill or an import silently reset the clock across the whole table. Nothing errors; the numbers just quietly improve and the signal goes quiet exactly when it matters.

So the touch list is exactly status, note, skip_reason. owner, business_unit, assignment, duty, due_date, visible_from, period_key, source and subject are deliberately excluded, and three of them are asserted directly:

✓ does NOT advance on an administrative write (business_unit)
✓ does NOT advance on a re-owner
✓ does NOT advance on a re-date
✓ does NOT advance on a re-save with no changes

A context with no pre-image — the whole-operation dispatch of an unscoped predicate write, i.e. the bulk write this hook most needs to survive — stamps nothing at all.

Three platform assumptions, verified rather than assumed

All three held. Measured against a real booted engine, not read off the docs:

Assumption	Verdict
beforeUpdate can see the previous field values	True. The engine binds hookContext.previous from a pre-read of the row before dispatching the beforeUpdate chain, and throws recordNotFoundError if that read comes back empty — so on the by-id path it is always present. Pinned by a probe hook in the suite.
A beforeUpdate stamp lands ahead of validation	True. Order is beforeUpdate → validateRecord → readonly strip → evaluateValidationRules. A write carrying only { status: 'done' } therefore commits.
readonly stripping blocks caller values while the hook's write passes	True, with one edge — see #31. The strip drops a readonly key only when its value is still exactly what the caller supplied, so a hook-derived value replaces a caller-supplied one.

Tests

test/task-hook.test.ts boots a real ObjectQL engine (in-memory driver) with this app's own objectstack.config.ts as the bundle. The handler runs only because AppPlugin found it in the real config, so the suite cannot pass on dead metadata.

Two things worth flagging to a reviewer:

The suite is pinned away from the build artifact. Left at its default, createStandaloneStack resolves dist/objectstack.json under the working directory, and when a local pnpm build has left one there the kernel loads its metadata — objects and hooks — from that file instead of from the config. The suite then reports on the last build rather than on src/, and behaves differently in CI (where pnpm test runs before pnpm build) than on a developer's machine. This is not hypothetical: it is what made the registration ablation come back green. The artifactPath sentinel in beforeAll is what closes it.

A negative control guards the completion assertions.completed_at_required_when_done is asserted to still refuse an insert of a done task, so if that rule ever goes quiet the completion tests stop proving anything.

Both ablations were run to confirm the assertions can fail:

• stamping last_update_at unconditionally (the classic wrong hook) → 5 failed, including the business_unit assertion
• removing the entry from dulyHooks → 11 failed, the registration and every positive behaviour test

Not in this PR

The attachment clause is not implemented — filed as #28. #3 asks for last_update_at to advance on "an attachment", but attachments are sys_attachment rows carrying parent_object/parent_id, so adding one is an insert on that object and no duly_task write happens at all. It needs a second hook on sys_attachment, an isSystem write-back to get past the readonly strip, and answers to product questions #3 did not settle (does removing an attachment count? does an importer's?).

Also filed: #31 (reopening fails to clear completed_at when the caller also sends completed_at: null — an upstream Object.is limitation in the readonly strip, deliberately not worked around here) and #32 (a task cannot be created directly in done — needs a product decision).

Gates

All four green at 864ba78:

pnpm validate ✓ Validation passed (237ms)
pnpm typecheck exit 0
pnpm test Test Files 2 passed (2) · Tests 27 passed (27)
pnpm build ✓ Build complete · dist/objectstack.json (53.3 KB)

The handler is written as one self-contained function so objectstack build lowers it to a metadata body rather than falling back to the legacy bundled runtime module — a fallback that only warns. The lowered body was executed against the real QuickJS sandbox to confirm it behaves identically there, since that is the surface a served artifact runs.

src/objects/task.object.ts was not touched.

---

Generated by Claude Code

[os-warren]

Fixes#3

Two server-owned timestamps on duly_task, written by one hook registered in dulyHooks.

What it does

beforeInsert — stamps last_update_at. A brand-new task has just been touched, by definition.

beforeUpdate

• transition intodone → completed_at = now
• transition out ofdone → completed_at = null
• last_update_at = now only when status, note or skip_reasonactually changed against the pre-image

Everything keys off ctx.previous, so these are transitions rather than states. That is what stops a whole-record form re-submitting status: 'done' from overwriting the original completion instant on every save, and what makes "re-saving with no changes" a no-op.

The stagnation signal

last_update_at feeds the "Not moving" view — status in (open, in_progress) AND last_update_at < {14_days_ago}. A hook that stamped on every update would let one bulk re-owner, a business-unit backfill or an import silently reset the clock across the whole table. Nothing errors; the numbers just quietly improve and the signal goes quiet exactly when it matters.

So the touch list is exactly status, note, skip_reason. owner, business_unit, assignment, duty, due_date, visible_from, period_key, source and subject are deliberately excluded, and three of them are asserted directly:

✓ does NOT advance on an administrative write (business_unit)
✓ does NOT advance on a re-owner
✓ does NOT advance on a re-date
✓ does NOT advance on a re-save with no changes

A context with no pre-image — the whole-operation dispatch of an unscoped predicate write, i.e. the bulk write this hook most needs to survive — stamps nothing at all.

Three platform assumptions, verified rather than assumed

All three held. Measured against a real booted engine, not read off the docs:

Assumption	Verdict
beforeUpdate can see the previous field values	True. The engine binds hookContext.previous from a pre-read of the row before dispatching the beforeUpdate chain, and throws recordNotFoundError if that read comes back empty — so on the by-id path it is always present. Pinned by a probe hook in the suite.
A beforeUpdate stamp lands ahead of validation	True. Order is beforeUpdate → validateRecord → readonly strip → evaluateValidationRules. A write carrying only { status: 'done' } therefore commits.
readonly stripping blocks caller values while the hook's write passes	True, with one edge — see #31. The strip drops a readonly key only when its value is still exactly what the caller supplied, so a hook-derived value replaces a caller-supplied one.

Tests

test/task-hook.test.ts boots a real ObjectQL engine (in-memory driver) with this app's own objectstack.config.ts as the bundle. The handler runs only because AppPlugin found it in the real config, so the suite cannot pass on dead metadata.

Two things worth flagging to a reviewer:

The suite is pinned away from the build artifact. Left at its default, createStandaloneStack resolves dist/objectstack.json under the working directory, and when a local pnpm build has left one there the kernel loads its metadata — objects and hooks — from that file instead of from the config. The suite then reports on the last build rather than on src/, and behaves differently in CI (where pnpm test runs before pnpm build) than on a developer's machine. This is not hypothetical: it is what made the registration ablation come back green. The artifactPath sentinel in beforeAll is what closes it.

A negative control guards the completion assertions.completed_at_required_when_done is asserted to still refuse an insert of a done task, so if that rule ever goes quiet the completion tests stop proving anything.

Both ablations were run to confirm the assertions can fail:

• stamping last_update_at unconditionally (the classic wrong hook) → 5 failed, including the business_unit assertion
• removing the entry from dulyHooks → 11 failed, the registration and every positive behaviour test

Not in this PR

The attachment clause is not implemented — filed as #28. #3 asks for last_update_at to advance on "an attachment", but attachments are sys_attachment rows carrying parent_object/parent_id, so adding one is an insert on that object and no duly_task write happens at all. It needs a second hook on sys_attachment, an isSystem write-back to get past the readonly strip, and answers to product questions #3 did not settle (does removing an attachment count? does an importer's?).

Also filed: #31 (reopening fails to clear completed_at when the caller also sends completed_at: null — an upstream Object.is limitation in the readonly strip, deliberately not worked around here) and #32 (a task cannot be created directly in done — needs a product decision).

Gates

All four green at 864ba78:

pnpm validate ✓ Validation passed (237ms)
pnpm typecheck exit 0
pnpm test Test Files 2 passed (2) · Tests 27 passed (27)
pnpm build ✓ Build complete · dist/objectstack.json (53.3 KB)

The handler is written as one self-contained function so objectstack build lowers it to a metadata body rather than falling back to the legacy bundled runtime module — a fallback that only warns. The lowered body was executed against the real QuickJS sandbox to confirm it behaves identically there, since that is the surface a served artifact runs.

src/objects/task.object.ts was not touched.

---

Generated by Claude Code

[os-warren]

Fixes#3

Two server-owned timestamps on duly_task, written by one hook registered in dulyHooks.

What it does

beforeInsert — stamps last_update_at. A brand-new task has just been touched, by definition.

beforeUpdate

• transition intodone → completed_at = now
• transition out ofdone → completed_at = null
• last_update_at = now only when status, note or skip_reasonactually changed against the pre-image

Everything keys off ctx.previous, so these are transitions rather than states. That is what stops a whole-record form re-submitting status: 'done' from overwriting the original completion instant on every save, and what makes "re-saving with no changes" a no-op.

The stagnation signal

last_update_at feeds the "Not moving" view — status in (open, in_progress) AND last_update_at < {14_days_ago}. A hook that stamped on every update would let one bulk re-owner, a business-unit backfill or an import silently reset the clock across the whole table. Nothing errors; the numbers just quietly improve and the signal goes quiet exactly when it matters.

So the touch list is exactly status, note, skip_reason. owner, business_unit, assignment, duty, due_date, visible_from, period_key, source and subject are deliberately excluded, and three of them are asserted directly:

✓ does NOT advance on an administrative write (business_unit)
✓ does NOT advance on a re-owner
✓ does NOT advance on a re-date
✓ does NOT advance on a re-save with no changes

A context with no pre-image — the whole-operation dispatch of an unscoped predicate write, i.e. the bulk write this hook most needs to survive — stamps nothing at all.

Three platform assumptions, verified rather than assumed

All three held. Measured against a real booted engine, not read off the docs:

Assumption	Verdict
beforeUpdate can see the previous field values	True. The engine binds hookContext.previous from a pre-read of the row before dispatching the beforeUpdate chain, and throws recordNotFoundError if that read comes back empty — so on the by-id path it is always present. Pinned by a probe hook in the suite.
A beforeUpdate stamp lands ahead of validation	True. Order is beforeUpdate → validateRecord → readonly strip → evaluateValidationRules. A write carrying only { status: 'done' } therefore commits.
readonly stripping blocks caller values while the hook's write passes	True, with one edge — see #31. The strip drops a readonly key only when its value is still exactly what the caller supplied, so a hook-derived value replaces a caller-supplied one.

Tests

test/task-hook.test.ts boots a real ObjectQL engine (in-memory driver) with this app's own objectstack.config.ts as the bundle. The handler runs only because AppPlugin found it in the real config, so the suite cannot pass on dead metadata.

Two things worth flagging to a reviewer:

The suite is pinned away from the build artifact. Left at its default, createStandaloneStack resolves dist/objectstack.json under the working directory, and when a local pnpm build has left one there the kernel loads its metadata — objects and hooks — from that file instead of from the config. The suite then reports on the last build rather than on src/, and behaves differently in CI (where pnpm test runs before pnpm build) than on a developer's machine. This is not hypothetical: it is what made the registration ablation come back green. The artifactPath sentinel in beforeAll is what closes it.

A negative control guards the completion assertions.completed_at_required_when_done is asserted to still refuse an insert of a done task, so if that rule ever goes quiet the completion tests stop proving anything.

Both ablations were run to confirm the assertions can fail:

• stamping last_update_at unconditionally (the classic wrong hook) → 5 failed, including the business_unit assertion
• removing the entry from dulyHooks → 11 failed, the registration and every positive behaviour test

Not in this PR

The attachment clause is not implemented — filed as #28. #3 asks for last_update_at to advance on "an attachment", but attachments are sys_attachment rows carrying parent_object/parent_id, so adding one is an insert on that object and no duly_task write happens at all. It needs a second hook on sys_attachment, an isSystem write-back to get past the readonly strip, and answers to product questions #3 did not settle (does removing an attachment count? does an importer's?).

Also filed: #31 (reopening fails to clear completed_at when the caller also sends completed_at: null — an upstream Object.is limitation in the readonly strip, deliberately not worked around here) and #32 (a task cannot be created directly in done — needs a product decision).

Gates

All four green at 864ba78:

pnpm validate ✓ Validation passed (237ms)
pnpm typecheck exit 0
pnpm test Test Files 2 passed (2) · Tests 27 passed (27)
pnpm build ✓ Build complete · dist/objectstack.json (53.3 KB)

The handler is written as one self-contained function so objectstack build lowers it to a metadata body rather than falling back to the legacy bundled runtime module — a fallback that only warns. The lowered body was executed against the real QuickJS sandbox to confirm it behaves identically there, since that is the surface a served artifact runs.

src/objects/task.object.ts was not touched.

---

Generated by Claude Code