---
id: define-sync-field-split
name: Define sync vs runtime field split for tasks
status: completed
depends_on: []
scope: narrow
risk: high
impact: phase
level: implementation
---

## Description

The task sync does a full upsert, but the Authority Model says runtime status mutations go through `hub.task.updateStatus`. If sync blindly writes frontmatter `status`, it can clobber runtime state. Example: Agent sets `task.status = 'in-progress'` via hub operation, then decomposer edits the task file (still has `status: pending`), then sync runs and overwrites `in-progress` back to `pending`.

Define the sync field split explicitly in `tasks.md`: sync upserts **authored fields** (slug, name, path, scope, risk, impact, level, priority, tags, assignee, due, body, fileCreatedAt, fileModifiedAt, depends_on) and must **not overwrite runtime-managed fields** (status, startedAt, completedAt). Runtime fields are only mutated via `hub.task.*` operations.

## Acceptance Criteria

- [ ] `tasks.md` has an explicit "Field Authority Split" section listing authored fields vs runtime-managed fields
- [ ] The sync flow specification is updated: upsert uses `ON CONFLICT DO UPDATE SET` only for authored fields
- [ ] Runtime fields (status, startedAt, completedAt) are explicitly excluded from the sync upsert
- [ ] The Authority Model table in tasks.md is updated to include the field-level split
- [ ] A warning is added: "Sync must never write `status`, `startedAt`, or `completedAt` — these are owned by hub operations"

## References

- docs/reviews/storage-architecture-review-2026-04-21.md#C07
- docs/architecture/storage/tasks.md:296-325

## Notes

> To be filled by implementation agent

## Summary

> To be filled on completion