[Bug] Deleted Workboard task IDs can be reused

[IndelibleVivi]

First, thank you for publishing Workhall. The separation between Workboard, Devlog, Promise, Cockpit, and Lessons is unusually thoughtful, and the repository has been very useful to study against another local-first coordination workflow.

I noticed a possible public-identity issue in the v5 Workboard lifecycle.

Reproduction

1. Initialize a fresh schema-v5 Workhall database.
2. Create one Workboard task. It receives WT#000001.
3. Cancel or close that task, which deletes its registry row.
4. Create another Workboard task.
5. The new and unrelated task receives WT#000001 again.

Cause

next_public_id() derives the next number from the currently existing record_registry rows. Since task close and cancellation physically delete the task and its registry entry, deleting the highest-numbered task allows that public ID to be issued again.

Impact

A stale WT# reference retained in a chat, external tool, bookmark, source pointer, or another durable surface may later resolve to an unrelated live task.

depends_on also stores bare WT# strings, so reusing a task identity can make dependency references ambiguous or eventually point at a different task.

Expected behavior

A public task ID should not be reused within the lifetime of one Workhall database, even when the active task card itself is deliberately removed.

Possible minimal fixes

• Maintain a persistent per-record-type sequence independent of currently existing rows; or
• Preserve a minimal identity tombstone after task deletion.

A regression test covering create → delete → create would make the intended identity contract explicit.

I may be missing an intentional ephemeral-ID rule, but even under an ephemeral task-card lifecycle, non-reuse seems important for references held outside Workhall.

[LuluaneS]

Thanks for the clear report! We’ve confirmed this behavior.

Workboard cards are intentionally ephemeral, but their public IDs should not be reused. We’re preparing a small fix that preserves the existing close/cancel behavior while making ID allocation independent of which records still exist.

We’ll include regression coverage for create–delete–create and initialization on existing databases. Thanks for highlighting the impact on stale references and dependencies.

[IndelibleVivi]

Thank you for confirming — that sounds exactly right. Keeping the cards ephemeral while decoupling public ID allocation preserves the clean v5 lifecycle. I’m especially glad the regression coverage will include initialization on existing databases. Looking forward to the fix!