One-click completion with undo, and skip-with-reason

[os-warren]

Fixes#4

One-click completion, undo, and skip-with-reason — plus bulk complete and bulk skip on the list views.

The route question, answered plainly

The instruction for this round was: before writing a handler, find out whether the platform has a declarative action that sets a field value. I looked, and the answer is different for the two halves of this card.

Bulk — yes, and it is used. A list view's bulkActionDefs with operation: 'update' and a static patchis the platform's "set these fields on every selected record". No action, no handler, no code:

{name: 'duly_task_bulk_complete',operation: 'update',patch: {status: 'done'},visible: P`record.status == "open" || record.status == "in_progress"`}

It is also the better write: a data-plane update running under the caller's own permissions, hooks and validations firing normally — strictly safer than N dispatches through an action handler's ctx.engine, which is system-elevated and RLS-bypassing by design.

Row — no.ActionType is url | form | flow | script | api | modal. There is no update_record type, no action effect, no patch key on ActionSchema. The two near-misses and why neither is it:

• type: 'api' + method: 'PATCH' + bodyExtra is a declarative HTTP call, not a declarative field write. It requires hand-writing the platform's own data-API path into app metadata — /api/v1/data/duly_task/${ctx.recordId}. Nothing binds that string to objectName, nothing checks it at author time, and it pins the transport: with projectResolution: 'required' only the /environments/:environmentId/ scoped route exists, so the app breaks on that host with no diagnostic. For AI-authored metadata it is the worst available shape — parses green, 404s at the click. The spec's own worked example of this route is itself wrong (it omits the /data segment), which is filed separately.
• type: 'flow' + an update_record node is genuinely declarative, but it is one flow per button to assign one string, plus a flow-run record per tick, on the one surface where validate currently misses bare predicates (objectstack#14089).

So: declarative for bulk, handlers for the rows, and the gap filed upstream as objectstack-ai/objectstack#14092 — with #14093 for the wrong doc example. The full argument lives in the src/actions/task.handlers.ts header so the next author does not have to re-derive it.

The real cost of that gap

Not the one-line write — the authorization. ctx.engine is system-elevated and RLS/FLS-bypassing, and visible is a UI hide, not authorization. So each handler re-establishes what the declarative bulk path gets for free. The obvious guard does not work: the dispatcher loads ctx.record under the caller's scope, swallows a failed load to {}, then stamps record.id = recordId on unconditionally — so ctx.record.id is present even when the caller cannot read the row. The check keys on status (required: true, so every stored row has one) instead. That is the part of #14092 that matters.

What it does

	complete	undo	skip
payload	{ status: 'done' }	{ status: 'in_progress' }	{ status: 'skipped', skip_reason }
from	open, in_progress	done	open, in_progress
dialog	none	none	the reason, and only the reason

completed_at and last_update_at are never sent — they stay the lifecycle hook's (#3). No confirmation on complete or undo, no percentage, no evidence gate. undoable: true gives complete the platform's own toast-level Undo for the mistake noticed immediately; duly_task_undo covers the one noticed after the toast is gone. Both exist because the toast is transient and the promise ("an accidental tick costs one click") is not.

cancelled is deliberately not completable: re-completing a cancelled task would put it back into on-time rates that had correctly forgotten it.

Gates

All four green on f116421, the branch head:

✓ Validation passed (332ms) # pnpm validate — 5 Actions
(tsc --noEmit, silent) # pnpm typecheck
Test Files 6 passed (6) # pnpm test
Tests 210 passed (210)
✓ Build complete (498ms) # pnpm build → dist/objectstack.json (73.0 KB)

Two ablations, because the interesting failures are silent

1 — the trap with no author-time gate. Removed registerTaskActionHandlers(ql) from register-handlers.ts (mutation confirmed on disk: the call count went 1 → 0 and the mutated function body was printed before anything was read):

=== pnpm validate under the ablation ===
VALIDATE_EXIT=0
✓ Validation passed (287ms)
=== pnpm test under the ablation ===
TEST_EXIT=1 17 failed
FAIL test/task-actions.test.ts > registration > every declared handler-backed action has a handler registered under duly_task
FAIL test/task-actions.test.ts > registration > dispatches for real — the wiring end to end, not just the registry

Confirmed: an unregistered handler ships green. The test is the only gate, so it dispatches through the engine's own executeAction rather than inspecting a registry.

2 — the bare predicate. Mutated duly_task_undo's visible to bare status == "done" (confirmed on disk: qualified 0, bare 1, with the three predicate lines printed). validaterejects it —

✗ Author-time rules failed (1 issue)
• stack · action 'duly_task_undo' visible: bare reference `status` — … Write `record.status`.
rule: expression-invalid

— and the suite catches it independently. So the action surface really is gated (unlike flows, objectstack#14089); both legs restored via trap … EXIT INT TERM and the clean tree verified after each.

Tests — test/task-actions.test.ts, 35 cases on a real booted engine

Against the app's own config with the in-memory driver, because two claims here are about the pipeline, not the handler: the registration, and "sends {status:'done'} and nothing else, and the record comes back with completed_at set". dispatch() mirrors the platform dispatcher's context construction — including the swallow-then-stamp detail above, so subject: 'unreadable' reproduces a caller who cannot read the row.

Refusals are asserted by envelope (code + status), never by the bare fact that something threw. And the object's own rule is pinned separately from the handler's early check, so the two cannot drift into one guard doing all the work:

expect(caught.code).toBe('VALIDATION_FAILED');
expect(caught.message).toBe('Say why the task was skipped.');

One measured hazard is pinned in both directions. A predicate update carries one payload for all N rows, so the completed_at the hook stamps for a genuinely-transitioning row is written to the whole batch — verified: bulk-completing a selection containing an already-done row moves that row's completion instant. The bulk defs' visible predicate is what makes such a selection unreachable, which is why it is load-bearing rather than decoration. Filed as #39 for a server-side guard, since the client predicate is not the authority.

Scope notes

• src/views/task.view.ts — Kanban, gantt and timeline lenses over the same task data #12 owns this file in a later round, so the edit is one shared bulkActions const plus a one-line bulkActionDefs: on each of the four multi-select grids. Not on calendar: no multi-select gesture to hang a selection bar on. No rowActions override either — the actions' own locations are the contract, and an allow-list here would be a second place to maintain that could silently exclude Kanban, gantt and timeline lenses over the same task data #12's.
• test/catalog-instantiate.test.ts — not in the declared file surface, but this PR makes three of its assertions false: they iterated the whole dulyActions array to claim it held only object-less, headless actions, which was true only while catalog was the only feature. Two are narrowed to the catalog actions; the third — the declaration↔handler bijection, the valuable one — is widened to cover object-bound actions rather than dropped.
• No objectstack.config.ts edit. Barrel only.
• No requiredPermissions on the new actions. dulyPermissionSets is empty, so naming a capability nothing grants would either hide the buttons from everyone or be inert. Queued as The three task row actions are ungated by requiredPermissions too — same gap as the catalog actions #40, a sub-issue of Gate the catalog actions with requiredPermissions — duly_catalog_apply is currently ungated #30, behind the same Security model — positions, permission sets, sharing rules #8 dependency as its parent.

Filed

objectstack#14092	no declarative row-action field write, while bulk has one — the platform gap this card was told to look for
objectstack#14093	ActionSchema.method's worked example points at a route the router does not mount
duly#39	bulk status write re-stamps completed_at on an already-done row in the batch
duly#40	the three task actions need the same requiredPermissions gate as the catalog actions (sub-issue of #30)

Generated by Claude Code

---

Generated by Claude Code

[os-warren]

Fixes#4

One-click completion, undo, and skip-with-reason — plus bulk complete and bulk skip on the list views.

The route question, answered plainly

The instruction for this round was: before writing a handler, find out whether the platform has a declarative action that sets a field value. I looked, and the answer is different for the two halves of this card.

Bulk — yes, and it is used. A list view's bulkActionDefs with operation: 'update' and a static patchis the platform's "set these fields on every selected record". No action, no handler, no code:

{name: 'duly_task_bulk_complete',operation: 'update',patch: {status: 'done'},visible: P`record.status == "open" || record.status == "in_progress"`}

It is also the better write: a data-plane update running under the caller's own permissions, hooks and validations firing normally — strictly safer than N dispatches through an action handler's ctx.engine, which is system-elevated and RLS-bypassing by design.

Row — no.ActionType is url | form | flow | script | api | modal. There is no update_record type, no action effect, no patch key on ActionSchema. The two near-misses and why neither is it:

• type: 'api' + method: 'PATCH' + bodyExtra is a declarative HTTP call, not a declarative field write. It requires hand-writing the platform's own data-API path into app metadata — /api/v1/data/duly_task/${ctx.recordId}. Nothing binds that string to objectName, nothing checks it at author time, and it pins the transport: with projectResolution: 'required' only the /environments/:environmentId/ scoped route exists, so the app breaks on that host with no diagnostic. For AI-authored metadata it is the worst available shape — parses green, 404s at the click. The spec's own worked example of this route is itself wrong (it omits the /data segment), which is filed separately.
• type: 'flow' + an update_record node is genuinely declarative, but it is one flow per button to assign one string, plus a flow-run record per tick, on the one surface where validate currently misses bare predicates (objectstack#14089).

So: declarative for bulk, handlers for the rows, and the gap filed upstream as objectstack-ai/objectstack#14092 — with #14093 for the wrong doc example. The full argument lives in the src/actions/task.handlers.ts header so the next author does not have to re-derive it.

The real cost of that gap

Not the one-line write — the authorization. ctx.engine is system-elevated and RLS/FLS-bypassing, and visible is a UI hide, not authorization. So each handler re-establishes what the declarative bulk path gets for free. The obvious guard does not work: the dispatcher loads ctx.record under the caller's scope, swallows a failed load to {}, then stamps record.id = recordId on unconditionally — so ctx.record.id is present even when the caller cannot read the row. The check keys on status (required: true, so every stored row has one) instead. That is the part of #14092 that matters.

What it does

	complete	undo	skip
payload	{ status: 'done' }	{ status: 'in_progress' }	{ status: 'skipped', skip_reason }
from	open, in_progress	done	open, in_progress
dialog	none	none	the reason, and only the reason

completed_at and last_update_at are never sent — they stay the lifecycle hook's (#3). No confirmation on complete or undo, no percentage, no evidence gate. undoable: true gives complete the platform's own toast-level Undo for the mistake noticed immediately; duly_task_undo covers the one noticed after the toast is gone. Both exist because the toast is transient and the promise ("an accidental tick costs one click") is not.

cancelled is deliberately not completable: re-completing a cancelled task would put it back into on-time rates that had correctly forgotten it.

Gates

All four green on f116421, the branch head:

✓ Validation passed (332ms) # pnpm validate — 5 Actions
(tsc --noEmit, silent) # pnpm typecheck
Test Files 6 passed (6) # pnpm test
Tests 210 passed (210)
✓ Build complete (498ms) # pnpm build → dist/objectstack.json (73.0 KB)

Two ablations, because the interesting failures are silent

1 — the trap with no author-time gate. Removed registerTaskActionHandlers(ql) from register-handlers.ts (mutation confirmed on disk: the call count went 1 → 0 and the mutated function body was printed before anything was read):

=== pnpm validate under the ablation ===
VALIDATE_EXIT=0
✓ Validation passed (287ms)
=== pnpm test under the ablation ===
TEST_EXIT=1 17 failed
FAIL test/task-actions.test.ts > registration > every declared handler-backed action has a handler registered under duly_task
FAIL test/task-actions.test.ts > registration > dispatches for real — the wiring end to end, not just the registry

Confirmed: an unregistered handler ships green. The test is the only gate, so it dispatches through the engine's own executeAction rather than inspecting a registry.

2 — the bare predicate. Mutated duly_task_undo's visible to bare status == "done" (confirmed on disk: qualified 0, bare 1, with the three predicate lines printed). validaterejects it —

✗ Author-time rules failed (1 issue)
• stack · action 'duly_task_undo' visible: bare reference `status` — … Write `record.status`.
rule: expression-invalid

— and the suite catches it independently. So the action surface really is gated (unlike flows, objectstack#14089); both legs restored via trap … EXIT INT TERM and the clean tree verified after each.

Tests — test/task-actions.test.ts, 35 cases on a real booted engine

Against the app's own config with the in-memory driver, because two claims here are about the pipeline, not the handler: the registration, and "sends {status:'done'} and nothing else, and the record comes back with completed_at set". dispatch() mirrors the platform dispatcher's context construction — including the swallow-then-stamp detail above, so subject: 'unreadable' reproduces a caller who cannot read the row.

Refusals are asserted by envelope (code + status), never by the bare fact that something threw. And the object's own rule is pinned separately from the handler's early check, so the two cannot drift into one guard doing all the work:

expect(caught.code).toBe('VALIDATION_FAILED');
expect(caught.message).toBe('Say why the task was skipped.');

One measured hazard is pinned in both directions. A predicate update carries one payload for all N rows, so the completed_at the hook stamps for a genuinely-transitioning row is written to the whole batch — verified: bulk-completing a selection containing an already-done row moves that row's completion instant. The bulk defs' visible predicate is what makes such a selection unreachable, which is why it is load-bearing rather than decoration. Filed as #39 for a server-side guard, since the client predicate is not the authority.

Scope notes

• src/views/task.view.ts — Kanban, gantt and timeline lenses over the same task data #12 owns this file in a later round, so the edit is one shared bulkActions const plus a one-line bulkActionDefs: on each of the four multi-select grids. Not on calendar: no multi-select gesture to hang a selection bar on. No rowActions override either — the actions' own locations are the contract, and an allow-list here would be a second place to maintain that could silently exclude Kanban, gantt and timeline lenses over the same task data #12's.
• test/catalog-instantiate.test.ts — not in the declared file surface, but this PR makes three of its assertions false: they iterated the whole dulyActions array to claim it held only object-less, headless actions, which was true only while catalog was the only feature. Two are narrowed to the catalog actions; the third — the declaration↔handler bijection, the valuable one — is widened to cover object-bound actions rather than dropped.
• No objectstack.config.ts edit. Barrel only.
• No requiredPermissions on the new actions. dulyPermissionSets is empty, so naming a capability nothing grants would either hide the buttons from everyone or be inert. Queued as The three task row actions are ungated by requiredPermissions too — same gap as the catalog actions #40, a sub-issue of Gate the catalog actions with requiredPermissions — duly_catalog_apply is currently ungated #30, behind the same Security model — positions, permission sets, sharing rules #8 dependency as its parent.

Filed

objectstack#14092	no declarative row-action field write, while bulk has one — the platform gap this card was told to look for
objectstack#14093	ActionSchema.method's worked example points at a route the router does not mount
duly#39	bulk status write re-stamps completed_at on an already-done row in the batch
duly#40	the three task actions need the same requiredPermissions gate as the catalog actions (sub-issue of #30)

Generated by Claude Code

---

Generated by Claude Code

[os-warren]

Fixes#4

One-click completion, undo, and skip-with-reason — plus bulk complete and bulk skip on the list views.

The route question, answered plainly

The instruction for this round was: before writing a handler, find out whether the platform has a declarative action that sets a field value. I looked, and the answer is different for the two halves of this card.

Bulk — yes, and it is used. A list view's bulkActionDefs with operation: 'update' and a static patchis the platform's "set these fields on every selected record". No action, no handler, no code:

{name: 'duly_task_bulk_complete',operation: 'update',patch: {status: 'done'},visible: P`record.status == "open" || record.status == "in_progress"`}

It is also the better write: a data-plane update running under the caller's own permissions, hooks and validations firing normally — strictly safer than N dispatches through an action handler's ctx.engine, which is system-elevated and RLS-bypassing by design.

Row — no.ActionType is url | form | flow | script | api | modal. There is no update_record type, no action effect, no patch key on ActionSchema. The two near-misses and why neither is it:

• type: 'api' + method: 'PATCH' + bodyExtra is a declarative HTTP call, not a declarative field write. It requires hand-writing the platform's own data-API path into app metadata — /api/v1/data/duly_task/${ctx.recordId}. Nothing binds that string to objectName, nothing checks it at author time, and it pins the transport: with projectResolution: 'required' only the /environments/:environmentId/ scoped route exists, so the app breaks on that host with no diagnostic. For AI-authored metadata it is the worst available shape — parses green, 404s at the click. The spec's own worked example of this route is itself wrong (it omits the /data segment), which is filed separately.
• type: 'flow' + an update_record node is genuinely declarative, but it is one flow per button to assign one string, plus a flow-run record per tick, on the one surface where validate currently misses bare predicates (objectstack#14089).

So: declarative for bulk, handlers for the rows, and the gap filed upstream as objectstack-ai/objectstack#14092 — with #14093 for the wrong doc example. The full argument lives in the src/actions/task.handlers.ts header so the next author does not have to re-derive it.

The real cost of that gap

Not the one-line write — the authorization. ctx.engine is system-elevated and RLS/FLS-bypassing, and visible is a UI hide, not authorization. So each handler re-establishes what the declarative bulk path gets for free. The obvious guard does not work: the dispatcher loads ctx.record under the caller's scope, swallows a failed load to {}, then stamps record.id = recordId on unconditionally — so ctx.record.id is present even when the caller cannot read the row. The check keys on status (required: true, so every stored row has one) instead. That is the part of #14092 that matters.

What it does

	complete	undo	skip
payload	{ status: 'done' }	{ status: 'in_progress' }	{ status: 'skipped', skip_reason }
from	open, in_progress	done	open, in_progress
dialog	none	none	the reason, and only the reason

completed_at and last_update_at are never sent — they stay the lifecycle hook's (#3). No confirmation on complete or undo, no percentage, no evidence gate. undoable: true gives complete the platform's own toast-level Undo for the mistake noticed immediately; duly_task_undo covers the one noticed after the toast is gone. Both exist because the toast is transient and the promise ("an accidental tick costs one click") is not.

cancelled is deliberately not completable: re-completing a cancelled task would put it back into on-time rates that had correctly forgotten it.

Gates

All four green on f116421, the branch head:

✓ Validation passed (332ms) # pnpm validate — 5 Actions
(tsc --noEmit, silent) # pnpm typecheck
Test Files 6 passed (6) # pnpm test
Tests 210 passed (210)
✓ Build complete (498ms) # pnpm build → dist/objectstack.json (73.0 KB)

Two ablations, because the interesting failures are silent

1 — the trap with no author-time gate. Removed registerTaskActionHandlers(ql) from register-handlers.ts (mutation confirmed on disk: the call count went 1 → 0 and the mutated function body was printed before anything was read):

=== pnpm validate under the ablation ===
VALIDATE_EXIT=0
✓ Validation passed (287ms)
=== pnpm test under the ablation ===
TEST_EXIT=1 17 failed
FAIL test/task-actions.test.ts > registration > every declared handler-backed action has a handler registered under duly_task
FAIL test/task-actions.test.ts > registration > dispatches for real — the wiring end to end, not just the registry

Confirmed: an unregistered handler ships green. The test is the only gate, so it dispatches through the engine's own executeAction rather than inspecting a registry.

2 — the bare predicate. Mutated duly_task_undo's visible to bare status == "done" (confirmed on disk: qualified 0, bare 1, with the three predicate lines printed). validaterejects it —

✗ Author-time rules failed (1 issue)
• stack · action 'duly_task_undo' visible: bare reference `status` — … Write `record.status`.
rule: expression-invalid

— and the suite catches it independently. So the action surface really is gated (unlike flows, objectstack#14089); both legs restored via trap … EXIT INT TERM and the clean tree verified after each.

Tests — test/task-actions.test.ts, 35 cases on a real booted engine

Against the app's own config with the in-memory driver, because two claims here are about the pipeline, not the handler: the registration, and "sends {status:'done'} and nothing else, and the record comes back with completed_at set". dispatch() mirrors the platform dispatcher's context construction — including the swallow-then-stamp detail above, so subject: 'unreadable' reproduces a caller who cannot read the row.

Refusals are asserted by envelope (code + status), never by the bare fact that something threw. And the object's own rule is pinned separately from the handler's early check, so the two cannot drift into one guard doing all the work:

expect(caught.code).toBe('VALIDATION_FAILED');
expect(caught.message).toBe('Say why the task was skipped.');

One measured hazard is pinned in both directions. A predicate update carries one payload for all N rows, so the completed_at the hook stamps for a genuinely-transitioning row is written to the whole batch — verified: bulk-completing a selection containing an already-done row moves that row's completion instant. The bulk defs' visible predicate is what makes such a selection unreachable, which is why it is load-bearing rather than decoration. Filed as #39 for a server-side guard, since the client predicate is not the authority.

Scope notes

• src/views/task.view.ts — Kanban, gantt and timeline lenses over the same task data #12 owns this file in a later round, so the edit is one shared bulkActions const plus a one-line bulkActionDefs: on each of the four multi-select grids. Not on calendar: no multi-select gesture to hang a selection bar on. No rowActions override either — the actions' own locations are the contract, and an allow-list here would be a second place to maintain that could silently exclude Kanban, gantt and timeline lenses over the same task data #12's.
• test/catalog-instantiate.test.ts — not in the declared file surface, but this PR makes three of its assertions false: they iterated the whole dulyActions array to claim it held only object-less, headless actions, which was true only while catalog was the only feature. Two are narrowed to the catalog actions; the third — the declaration↔handler bijection, the valuable one — is widened to cover object-bound actions rather than dropped.
• No objectstack.config.ts edit. Barrel only.
• No requiredPermissions on the new actions. dulyPermissionSets is empty, so naming a capability nothing grants would either hide the buttons from everyone or be inert. Queued as The three task row actions are ungated by requiredPermissions too — same gap as the catalog actions #40, a sub-issue of Gate the catalog actions with requiredPermissions — duly_catalog_apply is currently ungated #30, behind the same Security model — positions, permission sets, sharing rules #8 dependency as its parent.

Filed

objectstack#14092	no declarative row-action field write, while bulk has one — the platform gap this card was told to look for
objectstack#14093	ActionSchema.method's worked example points at a route the router does not mount
duly#39	bulk status write re-stamps completed_at on an already-done row in the batch
duly#40	the three task actions need the same requiredPermissions gate as the catalog actions (sub-issue of #30)

Generated by Claude Code

---

Generated by Claude Code

[os-warren]

Fixes#4

One-click completion, undo, and skip-with-reason — plus bulk complete and bulk skip on the list views.

The route question, answered plainly

The instruction for this round was: before writing a handler, find out whether the platform has a declarative action that sets a field value. I looked, and the answer is different for the two halves of this card.

Bulk — yes, and it is used. A list view's bulkActionDefs with operation: 'update' and a static patchis the platform's "set these fields on every selected record". No action, no handler, no code:

{name: 'duly_task_bulk_complete',operation: 'update',patch: {status: 'done'},visible: P`record.status == "open" || record.status == "in_progress"`}

It is also the better write: a data-plane update running under the caller's own permissions, hooks and validations firing normally — strictly safer than N dispatches through an action handler's ctx.engine, which is system-elevated and RLS-bypassing by design.

Row — no.ActionType is url | form | flow | script | api | modal. There is no update_record type, no action effect, no patch key on ActionSchema. The two near-misses and why neither is it:

• type: 'api' + method: 'PATCH' + bodyExtra is a declarative HTTP call, not a declarative field write. It requires hand-writing the platform's own data-API path into app metadata — /api/v1/data/duly_task/${ctx.recordId}. Nothing binds that string to objectName, nothing checks it at author time, and it pins the transport: with projectResolution: 'required' only the /environments/:environmentId/ scoped route exists, so the app breaks on that host with no diagnostic. For AI-authored metadata it is the worst available shape — parses green, 404s at the click. The spec's own worked example of this route is itself wrong (it omits the /data segment), which is filed separately.
• type: 'flow' + an update_record node is genuinely declarative, but it is one flow per button to assign one string, plus a flow-run record per tick, on the one surface where validate currently misses bare predicates (objectstack#14089).

So: declarative for bulk, handlers for the rows, and the gap filed upstream as objectstack-ai/objectstack#14092 — with #14093 for the wrong doc example. The full argument lives in the src/actions/task.handlers.ts header so the next author does not have to re-derive it.

The real cost of that gap

Not the one-line write — the authorization. ctx.engine is system-elevated and RLS/FLS-bypassing, and visible is a UI hide, not authorization. So each handler re-establishes what the declarative bulk path gets for free. The obvious guard does not work: the dispatcher loads ctx.record under the caller's scope, swallows a failed load to {}, then stamps record.id = recordId on unconditionally — so ctx.record.id is present even when the caller cannot read the row. The check keys on status (required: true, so every stored row has one) instead. That is the part of #14092 that matters.

What it does

	complete	undo	skip
payload	{ status: 'done' }	{ status: 'in_progress' }	{ status: 'skipped', skip_reason }
from	open, in_progress	done	open, in_progress
dialog	none	none	the reason, and only the reason

completed_at and last_update_at are never sent — they stay the lifecycle hook's (#3). No confirmation on complete or undo, no percentage, no evidence gate. undoable: true gives complete the platform's own toast-level Undo for the mistake noticed immediately; duly_task_undo covers the one noticed after the toast is gone. Both exist because the toast is transient and the promise ("an accidental tick costs one click") is not.

cancelled is deliberately not completable: re-completing a cancelled task would put it back into on-time rates that had correctly forgotten it.

Gates

All four green on f116421, the branch head:

✓ Validation passed (332ms) # pnpm validate — 5 Actions
(tsc --noEmit, silent) # pnpm typecheck
Test Files 6 passed (6) # pnpm test
Tests 210 passed (210)
✓ Build complete (498ms) # pnpm build → dist/objectstack.json (73.0 KB)

Two ablations, because the interesting failures are silent

1 — the trap with no author-time gate. Removed registerTaskActionHandlers(ql) from register-handlers.ts (mutation confirmed on disk: the call count went 1 → 0 and the mutated function body was printed before anything was read):

=== pnpm validate under the ablation ===
VALIDATE_EXIT=0
✓ Validation passed (287ms)
=== pnpm test under the ablation ===
TEST_EXIT=1 17 failed
FAIL test/task-actions.test.ts > registration > every declared handler-backed action has a handler registered under duly_task
FAIL test/task-actions.test.ts > registration > dispatches for real — the wiring end to end, not just the registry

Confirmed: an unregistered handler ships green. The test is the only gate, so it dispatches through the engine's own executeAction rather than inspecting a registry.

2 — the bare predicate. Mutated duly_task_undo's visible to bare status == "done" (confirmed on disk: qualified 0, bare 1, with the three predicate lines printed). validaterejects it —

✗ Author-time rules failed (1 issue)
• stack · action 'duly_task_undo' visible: bare reference `status` — … Write `record.status`.
rule: expression-invalid

— and the suite catches it independently. So the action surface really is gated (unlike flows, objectstack#14089); both legs restored via trap … EXIT INT TERM and the clean tree verified after each.

Tests — test/task-actions.test.ts, 35 cases on a real booted engine

Against the app's own config with the in-memory driver, because two claims here are about the pipeline, not the handler: the registration, and "sends {status:'done'} and nothing else, and the record comes back with completed_at set". dispatch() mirrors the platform dispatcher's context construction — including the swallow-then-stamp detail above, so subject: 'unreadable' reproduces a caller who cannot read the row.

Refusals are asserted by envelope (code + status), never by the bare fact that something threw. And the object's own rule is pinned separately from the handler's early check, so the two cannot drift into one guard doing all the work:

expect(caught.code).toBe('VALIDATION_FAILED');
expect(caught.message).toBe('Say why the task was skipped.');

One measured hazard is pinned in both directions. A predicate update carries one payload for all N rows, so the completed_at the hook stamps for a genuinely-transitioning row is written to the whole batch — verified: bulk-completing a selection containing an already-done row moves that row's completion instant. The bulk defs' visible predicate is what makes such a selection unreachable, which is why it is load-bearing rather than decoration. Filed as #39 for a server-side guard, since the client predicate is not the authority.

Scope notes

• src/views/task.view.ts — Kanban, gantt and timeline lenses over the same task data #12 owns this file in a later round, so the edit is one shared bulkActions const plus a one-line bulkActionDefs: on each of the four multi-select grids. Not on calendar: no multi-select gesture to hang a selection bar on. No rowActions override either — the actions' own locations are the contract, and an allow-list here would be a second place to maintain that could silently exclude Kanban, gantt and timeline lenses over the same task data #12's.
• test/catalog-instantiate.test.ts — not in the declared file surface, but this PR makes three of its assertions false: they iterated the whole dulyActions array to claim it held only object-less, headless actions, which was true only while catalog was the only feature. Two are narrowed to the catalog actions; the third — the declaration↔handler bijection, the valuable one — is widened to cover object-bound actions rather than dropped.
• No objectstack.config.ts edit. Barrel only.
• No requiredPermissions on the new actions. dulyPermissionSets is empty, so naming a capability nothing grants would either hide the buttons from everyone or be inert. Queued as The three task row actions are ungated by requiredPermissions too — same gap as the catalog actions #40, a sub-issue of Gate the catalog actions with requiredPermissions — duly_catalog_apply is currently ungated #30, behind the same Security model — positions, permission sets, sharing rules #8 dependency as its parent.

Filed

objectstack#14092	no declarative row-action field write, while bulk has one — the platform gap this card was told to look for
objectstack#14093	ActionSchema.method's worked example points at a route the router does not mount
duly#39	bulk status write re-stamps completed_at on an already-done row in the batch
duly#40	the three task actions need the same requiredPermissions gate as the catalog actions (sub-issue of #30)

Generated by Claude Code

---

Generated by Claude Code

[os-warren]

Fixes#4

One-click completion, undo, and skip-with-reason — plus bulk complete and bulk skip on the list views.

The route question, answered plainly

The instruction for this round was: before writing a handler, find out whether the platform has a declarative action that sets a field value. I looked, and the answer is different for the two halves of this card.

Bulk — yes, and it is used. A list view's bulkActionDefs with operation: 'update' and a static patchis the platform's "set these fields on every selected record". No action, no handler, no code:

{name: 'duly_task_bulk_complete',operation: 'update',patch: {status: 'done'},visible: P`record.status == "open" || record.status == "in_progress"`}

It is also the better write: a data-plane update running under the caller's own permissions, hooks and validations firing normally — strictly safer than N dispatches through an action handler's ctx.engine, which is system-elevated and RLS-bypassing by design.

Row — no.ActionType is url | form | flow | script | api | modal. There is no update_record type, no action effect, no patch key on ActionSchema. The two near-misses and why neither is it:

• type: 'api' + method: 'PATCH' + bodyExtra is a declarative HTTP call, not a declarative field write. It requires hand-writing the platform's own data-API path into app metadata — /api/v1/data/duly_task/${ctx.recordId}. Nothing binds that string to objectName, nothing checks it at author time, and it pins the transport: with projectResolution: 'required' only the /environments/:environmentId/ scoped route exists, so the app breaks on that host with no diagnostic. For AI-authored metadata it is the worst available shape — parses green, 404s at the click. The spec's own worked example of this route is itself wrong (it omits the /data segment), which is filed separately.
• type: 'flow' + an update_record node is genuinely declarative, but it is one flow per button to assign one string, plus a flow-run record per tick, on the one surface where validate currently misses bare predicates (objectstack#14089).

So: declarative for bulk, handlers for the rows, and the gap filed upstream as objectstack-ai/objectstack#14092 — with #14093 for the wrong doc example. The full argument lives in the src/actions/task.handlers.ts header so the next author does not have to re-derive it.

The real cost of that gap

Not the one-line write — the authorization. ctx.engine is system-elevated and RLS/FLS-bypassing, and visible is a UI hide, not authorization. So each handler re-establishes what the declarative bulk path gets for free. The obvious guard does not work: the dispatcher loads ctx.record under the caller's scope, swallows a failed load to {}, then stamps record.id = recordId on unconditionally — so ctx.record.id is present even when the caller cannot read the row. The check keys on status (required: true, so every stored row has one) instead. That is the part of #14092 that matters.

What it does

	complete	undo	skip
payload	{ status: 'done' }	{ status: 'in_progress' }	{ status: 'skipped', skip_reason }
from	open, in_progress	done	open, in_progress
dialog	none	none	the reason, and only the reason

completed_at and last_update_at are never sent — they stay the lifecycle hook's (#3). No confirmation on complete or undo, no percentage, no evidence gate. undoable: true gives complete the platform's own toast-level Undo for the mistake noticed immediately; duly_task_undo covers the one noticed after the toast is gone. Both exist because the toast is transient and the promise ("an accidental tick costs one click") is not.

cancelled is deliberately not completable: re-completing a cancelled task would put it back into on-time rates that had correctly forgotten it.

Gates

All four green on f116421, the branch head:

✓ Validation passed (332ms) # pnpm validate — 5 Actions
(tsc --noEmit, silent) # pnpm typecheck
Test Files 6 passed (6) # pnpm test
Tests 210 passed (210)
✓ Build complete (498ms) # pnpm build → dist/objectstack.json (73.0 KB)

Two ablations, because the interesting failures are silent

1 — the trap with no author-time gate. Removed registerTaskActionHandlers(ql) from register-handlers.ts (mutation confirmed on disk: the call count went 1 → 0 and the mutated function body was printed before anything was read):

=== pnpm validate under the ablation ===
VALIDATE_EXIT=0
✓ Validation passed (287ms)
=== pnpm test under the ablation ===
TEST_EXIT=1 17 failed
FAIL test/task-actions.test.ts > registration > every declared handler-backed action has a handler registered under duly_task
FAIL test/task-actions.test.ts > registration > dispatches for real — the wiring end to end, not just the registry

Confirmed: an unregistered handler ships green. The test is the only gate, so it dispatches through the engine's own executeAction rather than inspecting a registry.

2 — the bare predicate. Mutated duly_task_undo's visible to bare status == "done" (confirmed on disk: qualified 0, bare 1, with the three predicate lines printed). validaterejects it —

✗ Author-time rules failed (1 issue)
• stack · action 'duly_task_undo' visible: bare reference `status` — … Write `record.status`.
rule: expression-invalid

— and the suite catches it independently. So the action surface really is gated (unlike flows, objectstack#14089); both legs restored via trap … EXIT INT TERM and the clean tree verified after each.

Tests — test/task-actions.test.ts, 35 cases on a real booted engine

Against the app's own config with the in-memory driver, because two claims here are about the pipeline, not the handler: the registration, and "sends {status:'done'} and nothing else, and the record comes back with completed_at set". dispatch() mirrors the platform dispatcher's context construction — including the swallow-then-stamp detail above, so subject: 'unreadable' reproduces a caller who cannot read the row.

Refusals are asserted by envelope (code + status), never by the bare fact that something threw. And the object's own rule is pinned separately from the handler's early check, so the two cannot drift into one guard doing all the work:

expect(caught.code).toBe('VALIDATION_FAILED');
expect(caught.message).toBe('Say why the task was skipped.');

One measured hazard is pinned in both directions. A predicate update carries one payload for all N rows, so the completed_at the hook stamps for a genuinely-transitioning row is written to the whole batch — verified: bulk-completing a selection containing an already-done row moves that row's completion instant. The bulk defs' visible predicate is what makes such a selection unreachable, which is why it is load-bearing rather than decoration. Filed as #39 for a server-side guard, since the client predicate is not the authority.

Scope notes

• src/views/task.view.ts — Kanban, gantt and timeline lenses over the same task data #12 owns this file in a later round, so the edit is one shared bulkActions const plus a one-line bulkActionDefs: on each of the four multi-select grids. Not on calendar: no multi-select gesture to hang a selection bar on. No rowActions override either — the actions' own locations are the contract, and an allow-list here would be a second place to maintain that could silently exclude Kanban, gantt and timeline lenses over the same task data #12's.
• test/catalog-instantiate.test.ts — not in the declared file surface, but this PR makes three of its assertions false: they iterated the whole dulyActions array to claim it held only object-less, headless actions, which was true only while catalog was the only feature. Two are narrowed to the catalog actions; the third — the declaration↔handler bijection, the valuable one — is widened to cover object-bound actions rather than dropped.
• No objectstack.config.ts edit. Barrel only.
• No requiredPermissions on the new actions. dulyPermissionSets is empty, so naming a capability nothing grants would either hide the buttons from everyone or be inert. Queued as The three task row actions are ungated by requiredPermissions too — same gap as the catalog actions #40, a sub-issue of Gate the catalog actions with requiredPermissions — duly_catalog_apply is currently ungated #30, behind the same Security model — positions, permission sets, sharing rules #8 dependency as its parent.

Filed

objectstack#14092	no declarative row-action field write, while bulk has one — the platform gap this card was told to look for
objectstack#14093	ActionSchema.method's worked example points at a route the router does not mount
duly#39	bulk status write re-stamps completed_at on an already-done row in the batch
duly#40	the three task actions need the same requiredPermissions gate as the catalog actions (sub-issue of #30)

Generated by Claude Code

---

Generated by Claude Code

[os-warren]

Fixes#4

One-click completion, undo, and skip-with-reason — plus bulk complete and bulk skip on the list views.

The route question, answered plainly

The instruction for this round was: before writing a handler, find out whether the platform has a declarative action that sets a field value. I looked, and the answer is different for the two halves of this card.

Bulk — yes, and it is used. A list view's bulkActionDefs with operation: 'update' and a static patchis the platform's "set these fields on every selected record". No action, no handler, no code:

{name: 'duly_task_bulk_complete',operation: 'update',patch: {status: 'done'},visible: P`record.status == "open" || record.status == "in_progress"`}

It is also the better write: a data-plane update running under the caller's own permissions, hooks and validations firing normally — strictly safer than N dispatches through an action handler's ctx.engine, which is system-elevated and RLS-bypassing by design.

Row — no.ActionType is url | form | flow | script | api | modal. There is no update_record type, no action effect, no patch key on ActionSchema. The two near-misses and why neither is it:

• type: 'api' + method: 'PATCH' + bodyExtra is a declarative HTTP call, not a declarative field write. It requires hand-writing the platform's own data-API path into app metadata — /api/v1/data/duly_task/${ctx.recordId}. Nothing binds that string to objectName, nothing checks it at author time, and it pins the transport: with projectResolution: 'required' only the /environments/:environmentId/ scoped route exists, so the app breaks on that host with no diagnostic. For AI-authored metadata it is the worst available shape — parses green, 404s at the click. The spec's own worked example of this route is itself wrong (it omits the /data segment), which is filed separately.
• type: 'flow' + an update_record node is genuinely declarative, but it is one flow per button to assign one string, plus a flow-run record per tick, on the one surface where validate currently misses bare predicates (objectstack#14089).

So: declarative for bulk, handlers for the rows, and the gap filed upstream as objectstack-ai/objectstack#14092 — with #14093 for the wrong doc example. The full argument lives in the src/actions/task.handlers.ts header so the next author does not have to re-derive it.

The real cost of that gap

Not the one-line write — the authorization. ctx.engine is system-elevated and RLS/FLS-bypassing, and visible is a UI hide, not authorization. So each handler re-establishes what the declarative bulk path gets for free. The obvious guard does not work: the dispatcher loads ctx.record under the caller's scope, swallows a failed load to {}, then stamps record.id = recordId on unconditionally — so ctx.record.id is present even when the caller cannot read the row. The check keys on status (required: true, so every stored row has one) instead. That is the part of #14092 that matters.

What it does

	complete	undo	skip
payload	{ status: 'done' }	{ status: 'in_progress' }	{ status: 'skipped', skip_reason }
from	open, in_progress	done	open, in_progress
dialog	none	none	the reason, and only the reason

completed_at and last_update_at are never sent — they stay the lifecycle hook's (#3). No confirmation on complete or undo, no percentage, no evidence gate. undoable: true gives complete the platform's own toast-level Undo for the mistake noticed immediately; duly_task_undo covers the one noticed after the toast is gone. Both exist because the toast is transient and the promise ("an accidental tick costs one click") is not.

cancelled is deliberately not completable: re-completing a cancelled task would put it back into on-time rates that had correctly forgotten it.

Gates

All four green on f116421, the branch head:

✓ Validation passed (332ms) # pnpm validate — 5 Actions
(tsc --noEmit, silent) # pnpm typecheck
Test Files 6 passed (6) # pnpm test
Tests 210 passed (210)
✓ Build complete (498ms) # pnpm build → dist/objectstack.json (73.0 KB)

Two ablations, because the interesting failures are silent

1 — the trap with no author-time gate. Removed registerTaskActionHandlers(ql) from register-handlers.ts (mutation confirmed on disk: the call count went 1 → 0 and the mutated function body was printed before anything was read):

=== pnpm validate under the ablation ===
VALIDATE_EXIT=0
✓ Validation passed (287ms)
=== pnpm test under the ablation ===
TEST_EXIT=1 17 failed
FAIL test/task-actions.test.ts > registration > every declared handler-backed action has a handler registered under duly_task
FAIL test/task-actions.test.ts > registration > dispatches for real — the wiring end to end, not just the registry

Confirmed: an unregistered handler ships green. The test is the only gate, so it dispatches through the engine's own executeAction rather than inspecting a registry.

2 — the bare predicate. Mutated duly_task_undo's visible to bare status == "done" (confirmed on disk: qualified 0, bare 1, with the three predicate lines printed). validaterejects it —

✗ Author-time rules failed (1 issue)
• stack · action 'duly_task_undo' visible: bare reference `status` — … Write `record.status`.
rule: expression-invalid

— and the suite catches it independently. So the action surface really is gated (unlike flows, objectstack#14089); both legs restored via trap … EXIT INT TERM and the clean tree verified after each.

Tests — test/task-actions.test.ts, 35 cases on a real booted engine

Against the app's own config with the in-memory driver, because two claims here are about the pipeline, not the handler: the registration, and "sends {status:'done'} and nothing else, and the record comes back with completed_at set". dispatch() mirrors the platform dispatcher's context construction — including the swallow-then-stamp detail above, so subject: 'unreadable' reproduces a caller who cannot read the row.

Refusals are asserted by envelope (code + status), never by the bare fact that something threw. And the object's own rule is pinned separately from the handler's early check, so the two cannot drift into one guard doing all the work:

expect(caught.code).toBe('VALIDATION_FAILED');
expect(caught.message).toBe('Say why the task was skipped.');

One measured hazard is pinned in both directions. A predicate update carries one payload for all N rows, so the completed_at the hook stamps for a genuinely-transitioning row is written to the whole batch — verified: bulk-completing a selection containing an already-done row moves that row's completion instant. The bulk defs' visible predicate is what makes such a selection unreachable, which is why it is load-bearing rather than decoration. Filed as #39 for a server-side guard, since the client predicate is not the authority.

Scope notes

• src/views/task.view.ts — Kanban, gantt and timeline lenses over the same task data #12 owns this file in a later round, so the edit is one shared bulkActions const plus a one-line bulkActionDefs: on each of the four multi-select grids. Not on calendar: no multi-select gesture to hang a selection bar on. No rowActions override either — the actions' own locations are the contract, and an allow-list here would be a second place to maintain that could silently exclude Kanban, gantt and timeline lenses over the same task data #12's.
• test/catalog-instantiate.test.ts — not in the declared file surface, but this PR makes three of its assertions false: they iterated the whole dulyActions array to claim it held only object-less, headless actions, which was true only while catalog was the only feature. Two are narrowed to the catalog actions; the third — the declaration↔handler bijection, the valuable one — is widened to cover object-bound actions rather than dropped.
• No objectstack.config.ts edit. Barrel only.
• No requiredPermissions on the new actions. dulyPermissionSets is empty, so naming a capability nothing grants would either hide the buttons from everyone or be inert. Queued as The three task row actions are ungated by requiredPermissions too — same gap as the catalog actions #40, a sub-issue of Gate the catalog actions with requiredPermissions — duly_catalog_apply is currently ungated #30, behind the same Security model — positions, permission sets, sharing rules #8 dependency as its parent.

Filed

objectstack#14092	no declarative row-action field write, while bulk has one — the platform gap this card was told to look for
objectstack#14093	ActionSchema.method's worked example points at a route the router does not mount
duly#39	bulk status write re-stamps completed_at on an already-done row in the batch
duly#40	the three task actions need the same requiredPermissions gate as the catalog actions (sub-issue of #30)

Generated by Claude Code

---

Generated by Claude Code

[os-warren]

Fixes#4

One-click completion, undo, and skip-with-reason — plus bulk complete and bulk skip on the list views.

The route question, answered plainly

The instruction for this round was: before writing a handler, find out whether the platform has a declarative action that sets a field value. I looked, and the answer is different for the two halves of this card.

Bulk — yes, and it is used. A list view's bulkActionDefs with operation: 'update' and a static patchis the platform's "set these fields on every selected record". No action, no handler, no code:

{name: 'duly_task_bulk_complete',operation: 'update',patch: {status: 'done'},visible: P`record.status == "open" || record.status == "in_progress"`}

It is also the better write: a data-plane update running under the caller's own permissions, hooks and validations firing normally — strictly safer than N dispatches through an action handler's ctx.engine, which is system-elevated and RLS-bypassing by design.

Row — no.ActionType is url | form | flow | script | api | modal. There is no update_record type, no action effect, no patch key on ActionSchema. The two near-misses and why neither is it:

• type: 'api' + method: 'PATCH' + bodyExtra is a declarative HTTP call, not a declarative field write. It requires hand-writing the platform's own data-API path into app metadata — /api/v1/data/duly_task/${ctx.recordId}. Nothing binds that string to objectName, nothing checks it at author time, and it pins the transport: with projectResolution: 'required' only the /environments/:environmentId/ scoped route exists, so the app breaks on that host with no diagnostic. For AI-authored metadata it is the worst available shape — parses green, 404s at the click. The spec's own worked example of this route is itself wrong (it omits the /data segment), which is filed separately.
• type: 'flow' + an update_record node is genuinely declarative, but it is one flow per button to assign one string, plus a flow-run record per tick, on the one surface where validate currently misses bare predicates (objectstack#14089).

So: declarative for bulk, handlers for the rows, and the gap filed upstream as objectstack-ai/objectstack#14092 — with #14093 for the wrong doc example. The full argument lives in the src/actions/task.handlers.ts header so the next author does not have to re-derive it.

The real cost of that gap

Not the one-line write — the authorization. ctx.engine is system-elevated and RLS/FLS-bypassing, and visible is a UI hide, not authorization. So each handler re-establishes what the declarative bulk path gets for free. The obvious guard does not work: the dispatcher loads ctx.record under the caller's scope, swallows a failed load to {}, then stamps record.id = recordId on unconditionally — so ctx.record.id is present even when the caller cannot read the row. The check keys on status (required: true, so every stored row has one) instead. That is the part of #14092 that matters.

What it does

	complete	undo	skip
payload	{ status: 'done' }	{ status: 'in_progress' }	{ status: 'skipped', skip_reason }
from	open, in_progress	done	open, in_progress
dialog	none	none	the reason, and only the reason

completed_at and last_update_at are never sent — they stay the lifecycle hook's (#3). No confirmation on complete or undo, no percentage, no evidence gate. undoable: true gives complete the platform's own toast-level Undo for the mistake noticed immediately; duly_task_undo covers the one noticed after the toast is gone. Both exist because the toast is transient and the promise ("an accidental tick costs one click") is not.

cancelled is deliberately not completable: re-completing a cancelled task would put it back into on-time rates that had correctly forgotten it.

Gates

All four green on f116421, the branch head:

✓ Validation passed (332ms) # pnpm validate — 5 Actions
(tsc --noEmit, silent) # pnpm typecheck
Test Files 6 passed (6) # pnpm test
Tests 210 passed (210)
✓ Build complete (498ms) # pnpm build → dist/objectstack.json (73.0 KB)

Two ablations, because the interesting failures are silent

1 — the trap with no author-time gate. Removed registerTaskActionHandlers(ql) from register-handlers.ts (mutation confirmed on disk: the call count went 1 → 0 and the mutated function body was printed before anything was read):

=== pnpm validate under the ablation ===
VALIDATE_EXIT=0
✓ Validation passed (287ms)
=== pnpm test under the ablation ===
TEST_EXIT=1 17 failed
FAIL test/task-actions.test.ts > registration > every declared handler-backed action has a handler registered under duly_task
FAIL test/task-actions.test.ts > registration > dispatches for real — the wiring end to end, not just the registry

Confirmed: an unregistered handler ships green. The test is the only gate, so it dispatches through the engine's own executeAction rather than inspecting a registry.

2 — the bare predicate. Mutated duly_task_undo's visible to bare status == "done" (confirmed on disk: qualified 0, bare 1, with the three predicate lines printed). validaterejects it —

✗ Author-time rules failed (1 issue)
• stack · action 'duly_task_undo' visible: bare reference `status` — … Write `record.status`.
rule: expression-invalid

— and the suite catches it independently. So the action surface really is gated (unlike flows, objectstack#14089); both legs restored via trap … EXIT INT TERM and the clean tree verified after each.

Tests — test/task-actions.test.ts, 35 cases on a real booted engine

Against the app's own config with the in-memory driver, because two claims here are about the pipeline, not the handler: the registration, and "sends {status:'done'} and nothing else, and the record comes back with completed_at set". dispatch() mirrors the platform dispatcher's context construction — including the swallow-then-stamp detail above, so subject: 'unreadable' reproduces a caller who cannot read the row.

Refusals are asserted by envelope (code + status), never by the bare fact that something threw. And the object's own rule is pinned separately from the handler's early check, so the two cannot drift into one guard doing all the work:

expect(caught.code).toBe('VALIDATION_FAILED');
expect(caught.message).toBe('Say why the task was skipped.');

One measured hazard is pinned in both directions. A predicate update carries one payload for all N rows, so the completed_at the hook stamps for a genuinely-transitioning row is written to the whole batch — verified: bulk-completing a selection containing an already-done row moves that row's completion instant. The bulk defs' visible predicate is what makes such a selection unreachable, which is why it is load-bearing rather than decoration. Filed as #39 for a server-side guard, since the client predicate is not the authority.

Scope notes

• src/views/task.view.ts — Kanban, gantt and timeline lenses over the same task data #12 owns this file in a later round, so the edit is one shared bulkActions const plus a one-line bulkActionDefs: on each of the four multi-select grids. Not on calendar: no multi-select gesture to hang a selection bar on. No rowActions override either — the actions' own locations are the contract, and an allow-list here would be a second place to maintain that could silently exclude Kanban, gantt and timeline lenses over the same task data #12's.
• test/catalog-instantiate.test.ts — not in the declared file surface, but this PR makes three of its assertions false: they iterated the whole dulyActions array to claim it held only object-less, headless actions, which was true only while catalog was the only feature. Two are narrowed to the catalog actions; the third — the declaration↔handler bijection, the valuable one — is widened to cover object-bound actions rather than dropped.
• No objectstack.config.ts edit. Barrel only.
• No requiredPermissions on the new actions. dulyPermissionSets is empty, so naming a capability nothing grants would either hide the buttons from everyone or be inert. Queued as The three task row actions are ungated by requiredPermissions too — same gap as the catalog actions #40, a sub-issue of Gate the catalog actions with requiredPermissions — duly_catalog_apply is currently ungated #30, behind the same Security model — positions, permission sets, sharing rules #8 dependency as its parent.

Filed

objectstack#14092	no declarative row-action field write, while bulk has one — the platform gap this card was told to look for
objectstack#14093	ActionSchema.method's worked example points at a route the router does not mount
duly#39	bulk status write re-stamps completed_at on an already-done row in the batch
duly#40	the three task actions need the same requiredPermissions gate as the catalog actions (sub-issue of #30)

Generated by Claude Code

---

Generated by Claude Code

[os-warren]

Fixes#4

One-click completion, undo, and skip-with-reason — plus bulk complete and bulk skip on the list views.

The route question, answered plainly

The instruction for this round was: before writing a handler, find out whether the platform has a declarative action that sets a field value. I looked, and the answer is different for the two halves of this card.

Bulk — yes, and it is used. A list view's bulkActionDefs with operation: 'update' and a static patchis the platform's "set these fields on every selected record". No action, no handler, no code:

{name: 'duly_task_bulk_complete',operation: 'update',patch: {status: 'done'},visible: P`record.status == "open" || record.status == "in_progress"`}

It is also the better write: a data-plane update running under the caller's own permissions, hooks and validations firing normally — strictly safer than N dispatches through an action handler's ctx.engine, which is system-elevated and RLS-bypassing by design.

Row — no.ActionType is url | form | flow | script | api | modal. There is no update_record type, no action effect, no patch key on ActionSchema. The two near-misses and why neither is it:

• type: 'api' + method: 'PATCH' + bodyExtra is a declarative HTTP call, not a declarative field write. It requires hand-writing the platform's own data-API path into app metadata — /api/v1/data/duly_task/${ctx.recordId}. Nothing binds that string to objectName, nothing checks it at author time, and it pins the transport: with projectResolution: 'required' only the /environments/:environmentId/ scoped route exists, so the app breaks on that host with no diagnostic. For AI-authored metadata it is the worst available shape — parses green, 404s at the click. The spec's own worked example of this route is itself wrong (it omits the /data segment), which is filed separately.
• type: 'flow' + an update_record node is genuinely declarative, but it is one flow per button to assign one string, plus a flow-run record per tick, on the one surface where validate currently misses bare predicates (objectstack#14089).

So: declarative for bulk, handlers for the rows, and the gap filed upstream as objectstack-ai/objectstack#14092 — with #14093 for the wrong doc example. The full argument lives in the src/actions/task.handlers.ts header so the next author does not have to re-derive it.

The real cost of that gap

Not the one-line write — the authorization. ctx.engine is system-elevated and RLS/FLS-bypassing, and visible is a UI hide, not authorization. So each handler re-establishes what the declarative bulk path gets for free. The obvious guard does not work: the dispatcher loads ctx.record under the caller's scope, swallows a failed load to {}, then stamps record.id = recordId on unconditionally — so ctx.record.id is present even when the caller cannot read the row. The check keys on status (required: true, so every stored row has one) instead. That is the part of #14092 that matters.

What it does

	complete	undo	skip
payload	{ status: 'done' }	{ status: 'in_progress' }	{ status: 'skipped', skip_reason }
from	open, in_progress	done	open, in_progress
dialog	none	none	the reason, and only the reason

completed_at and last_update_at are never sent — they stay the lifecycle hook's (#3). No confirmation on complete or undo, no percentage, no evidence gate. undoable: true gives complete the platform's own toast-level Undo for the mistake noticed immediately; duly_task_undo covers the one noticed after the toast is gone. Both exist because the toast is transient and the promise ("an accidental tick costs one click") is not.

cancelled is deliberately not completable: re-completing a cancelled task would put it back into on-time rates that had correctly forgotten it.

Gates

All four green on f116421, the branch head:

✓ Validation passed (332ms) # pnpm validate — 5 Actions
(tsc --noEmit, silent) # pnpm typecheck
Test Files 6 passed (6) # pnpm test
Tests 210 passed (210)
✓ Build complete (498ms) # pnpm build → dist/objectstack.json (73.0 KB)

Two ablations, because the interesting failures are silent

1 — the trap with no author-time gate. Removed registerTaskActionHandlers(ql) from register-handlers.ts (mutation confirmed on disk: the call count went 1 → 0 and the mutated function body was printed before anything was read):

=== pnpm validate under the ablation ===
VALIDATE_EXIT=0
✓ Validation passed (287ms)
=== pnpm test under the ablation ===
TEST_EXIT=1 17 failed
FAIL test/task-actions.test.ts > registration > every declared handler-backed action has a handler registered under duly_task
FAIL test/task-actions.test.ts > registration > dispatches for real — the wiring end to end, not just the registry

Confirmed: an unregistered handler ships green. The test is the only gate, so it dispatches through the engine's own executeAction rather than inspecting a registry.

2 — the bare predicate. Mutated duly_task_undo's visible to bare status == "done" (confirmed on disk: qualified 0, bare 1, with the three predicate lines printed). validaterejects it —

✗ Author-time rules failed (1 issue)
• stack · action 'duly_task_undo' visible: bare reference `status` — … Write `record.status`.
rule: expression-invalid

— and the suite catches it independently. So the action surface really is gated (unlike flows, objectstack#14089); both legs restored via trap … EXIT INT TERM and the clean tree verified after each.

Tests — test/task-actions.test.ts, 35 cases on a real booted engine

Against the app's own config with the in-memory driver, because two claims here are about the pipeline, not the handler: the registration, and "sends {status:'done'} and nothing else, and the record comes back with completed_at set". dispatch() mirrors the platform dispatcher's context construction — including the swallow-then-stamp detail above, so subject: 'unreadable' reproduces a caller who cannot read the row.

Refusals are asserted by envelope (code + status), never by the bare fact that something threw. And the object's own rule is pinned separately from the handler's early check, so the two cannot drift into one guard doing all the work:

expect(caught.code).toBe('VALIDATION_FAILED');
expect(caught.message).toBe('Say why the task was skipped.');

One measured hazard is pinned in both directions. A predicate update carries one payload for all N rows, so the completed_at the hook stamps for a genuinely-transitioning row is written to the whole batch — verified: bulk-completing a selection containing an already-done row moves that row's completion instant. The bulk defs' visible predicate is what makes such a selection unreachable, which is why it is load-bearing rather than decoration. Filed as #39 for a server-side guard, since the client predicate is not the authority.

Scope notes

• src/views/task.view.ts — Kanban, gantt and timeline lenses over the same task data #12 owns this file in a later round, so the edit is one shared bulkActions const plus a one-line bulkActionDefs: on each of the four multi-select grids. Not on calendar: no multi-select gesture to hang a selection bar on. No rowActions override either — the actions' own locations are the contract, and an allow-list here would be a second place to maintain that could silently exclude Kanban, gantt and timeline lenses over the same task data #12's.
• test/catalog-instantiate.test.ts — not in the declared file surface, but this PR makes three of its assertions false: they iterated the whole dulyActions array to claim it held only object-less, headless actions, which was true only while catalog was the only feature. Two are narrowed to the catalog actions; the third — the declaration↔handler bijection, the valuable one — is widened to cover object-bound actions rather than dropped.
• No objectstack.config.ts edit. Barrel only.
• No requiredPermissions on the new actions. dulyPermissionSets is empty, so naming a capability nothing grants would either hide the buttons from everyone or be inert. Queued as The three task row actions are ungated by requiredPermissions too — same gap as the catalog actions #40, a sub-issue of Gate the catalog actions with requiredPermissions — duly_catalog_apply is currently ungated #30, behind the same Security model — positions, permission sets, sharing rules #8 dependency as its parent.

Filed

objectstack#14092	no declarative row-action field write, while bulk has one — the platform gap this card was told to look for
objectstack#14093	ActionSchema.method's worked example points at a route the router does not mount
duly#39	bulk status write re-stamps completed_at on an already-done row in the batch
duly#40	the three task actions need the same requiredPermissions gate as the catalog actions (sub-issue of #30)

Generated by Claude Code

---

Generated by Claude Code