---
id: document-mappings-task-denorm-invariant
name: Document mappings.task denormalization sync strategy
status: completed
depends_on: []
scope: narrow
risk: medium
impact: component
level: implementation
---

## Description

The `mappings` table has both `taskId` (FK → tasks.id) and `task` (denormalized display name). No mechanism keeps them in sync. If `taskId` points to a task whose `slug` or `name` changes, `mappings.task` becomes stale. When `taskId` is SET NULL (task deleted), what happens to `task`?

The review recommends documenting the invariant: "`mappings.task` is set to `tasks.slug` at insert time and is **not** automatically updated when the task's slug changes. When `taskId` is SET NULL (task deleted), `task` should also be SET NULL. This is a cache, not a source of truth." Alternatively, remove the denormalized column and use a VIEW that joins.

## Acceptance Criteria

- [ ] `coordination.md` documents the invariant for `mappings.task`: it is a cache of `tasks.slug`, set at insert time, not auto-updated
- [ ] The behavior when `taskId` is SET NULL is documented: `task` should also be SET NULL (application-level or trigger)
- [ ] If keeping the column: add a note that stale `task` values are acceptable (cache semantics)
- [ ] If removing the column: replace with a VIEW definition and update coordination.md
- [ ] `tasks.md:209` reference to `mappings.task` is updated to be consistent

## References

- docs/reviews/storage-architecture-review-2026-04-21.md#C06
- docs/architecture/storage/coordination.md:22
- docs/architecture/storage/tasks.md:209

## Notes

> To be filled by implementation agent

## Summary

> To be filled on completion