Problem
Task IDs are currently sequential integers from a counter in config.yml. This creates two issues for multi-agent/multi-branch workflows:
Branch ID collisions
Two agents on separate branches both create TSK-3 → merge conflict, potential data loss. The counter in config.yml and the task filenames (3.yml) will collide.
No retry idempotency
If an agent's tsk move call times out and it retries, there's no way to detect the duplicate. The activity log gets a double entry.
Proposed solution
Immutable UUIDs as internal keys
- Each task gets a UUID at creation time (stored in the YAML)
TSK-N remains the friendly display label (no UX change)
- File storage keyed by UUID instead of integer ID
- Merges become conflict-free — two branches can't create the same UUID
Monotonic event IDs on activity entries
- Each activity log entry gets a unique, monotonically increasing event ID
- Enables deduplication on retry ("already applied")
- Makes it possible to detect missing events after merges
Design considerations
- Backward compatibility: existing
TSK-N references should keep working
- The
config.yml counter can remain for generating friendly labels, but shouldn't be the source of truth for identity
- UUIDs could be short (nanoid-style) to keep filenames readable
Context
This becomes important as tsk positions toward multi-agent workflows where agents work on parallel branches and merge results. Single-branch usage (most current users) is unaffected.
Problem
Task IDs are currently sequential integers from a counter in
config.yml. This creates two issues for multi-agent/multi-branch workflows:Branch ID collisions
Two agents on separate branches both create
TSK-3→ merge conflict, potential data loss. The counter inconfig.ymland the task filenames (3.yml) will collide.No retry idempotency
If an agent's
tsk movecall times out and it retries, there's no way to detect the duplicate. The activity log gets a double entry.Proposed solution
Immutable UUIDs as internal keys
TSK-Nremains the friendly display label (no UX change)Monotonic event IDs on activity entries
Design considerations
TSK-Nreferences should keep workingconfig.ymlcounter can remain for generating friendly labels, but shouldn't be the source of truth for identityContext
This becomes important as tsk positions toward multi-agent workflows where agents work on parallel branches and merge results. Single-branch usage (most current users) is unaffected.