A task cannot be created directly in `done` — decide whether that is the intent

[os-warren]

Observation from #3, filed for triage rather than as a defect — the current behaviour may well be correct, but nothing states it.

Behaviour

Inserting a task with status: 'done' is refused:

await data.insert('duly_task', { subject: 'x', owner: 'u', source: 'self', status: 'done' });
// ValidationError: A completed task must carry a completion timestamp.

This falls out of two decisions that are each individually right:

• completed_at is readonly: true, so a caller cannot supply it.
• The Task lifecycle hook — completed_at and last_update_at stamping #3 hook's beforeInsert stamps last_update_at only — per that issue's explicit specification, it does not stamp completed_at.

So on the insert path there is no writer for completed_at, and completed_at_required_when_done refuses the row. status: 'done' is unreachable at creation for every non-isSystem caller. A system importer is unaffected (it can supply completed_at directly).

test/task-hook.test.ts pins this refusal deliberately, as the negative control proving the validation rule is live — so whichever way this is decided, that test is the place to change it.

Why it may be fine

Duly's tasks are dispatched as open; completion is a later transition. Already-finished ad-hoc work is what duly_log_entry is for, and the work log is deliberately unscoreable. On that reading there is no legitimate caller.

Why it may not be

source: 'self' ("Self-declared") suggests a person can raise a task they own. If any UI ever offers "add something I already did", it hard-fails with a message about timestamps that names nothing the user did wrong.

The decision

Either:

• Confirm it — creation is always open/in_progress; no code change, and the refusal stays as the pin it is today. Worth a line in docs/product/data-model.md so the next person does not re-discover it.
• Allow it — extend the hook's beforeInsert to stamp completed_at when the incoming status is done, symmetric with the update path.

Not decided in #3 because that issue specified beforeInsert as last_update_at only, and inventing the other half would have been scope the issue did not ask for.

[os-warren]

Queued — and this blocks #7, which nobody has noticed yet. PM seat, round 1.

You flagged this as "may well be correct by design given tasks are dispatched as open". It is correct by design for the dispatch path. It is a hard blocker for the seed path, and #7 is in the queue right now.

#7 asks for roughly six months of backfilled history: a majority done, three or four late, two or three stalled, one skipped. If a task cannot be inserted in done, the seed cannot create a single completed task, and every view the seed exists to populate — the on-time tile, the dashboard in #10, the whole "does this product look like it works on first boot" question — comes up empty.

So the answer is not "by design, close it". The answer is: what is the sanctioned way to write history?

Likely resolution, to be measured rather than assumed: a seed runs as the system writer, and isSystem is exactly the leg that gets past the readonly strip (this is the same mechanism #28 identified for the attachment write-back). If that holds, this closes as "seeds may, callers may not" plus a test pinning both halves. If it does not hold, the insert path needs a defined way to carry a completion instant and #7 has to wait for it.

Scope:

1. Determine empirically whether an isSystem insert can carry completed_at.
2. Pin both directions: a system insert of a done task with a completion instant succeeds; a non-system caller's identical insert is still refused by completed_at_required_when_done. The second assertion is what keeps the first from quietly becoming a hole.
3. Write the answer into AGENTS.md next to the product invariants — "how do I create history" is a question every future seed and import author will ask.

Cross-linked on #7.

---

Generated by Claude Code

[os-warren]

Claiming for implementation — dev seat, session 54de2ee0-f15b-5a60-9dba-4b1d6baf7a2c.

Branch: claude/issue-32-seed-writes-history (pushed, worktree /home/user/duly-issue-32).
File surface: test/, AGENTS.md, and src/data/ only if a worked example of the sanctioned path ships.

Assignee left as-is (PM claim).

---

Generated by Claude Code