You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: .tickets/dso-2dxt.md
+6-1Lines changed: 6 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,12 +1,13 @@
1
1
---
2
2
id: dso-2dxt
3
-
status: open
3
+
status: in_progress
4
4
deps: []
5
5
links: []
6
6
created: 2026-03-21T20:32:23Z
7
7
type: task
8
8
priority: 2
9
9
assignee: Joe Oakhart
10
+
parent: w22-ns6l
10
11
---
11
12
# bug LINK/UNLINK same-second timestamp ordering causes unlink to be ignored
12
13
@@ -19,3 +20,7 @@ assignee: Joe Oakhart
19
20
<!-- sync: unsynced -->
20
21
21
22
Discovered in test-ticket-dependency-e2e.sh (dso-ofdp). When ticket-graph.py writes a LINK event and ticket-link.sh writes an UNLINK event in the same Unix second (int(time.time())), the filename sort order is {timestamp}-{uuid}-LINK.json vs {timestamp}-{uuid}-UNLINK.json. Since UUIDs are random, the UNLINK can sort before the LINK alphabetically, causing the event replay in _is_duplicate_link and _find_direct_blockers to treat the link as still active. Fix: use millisecond timestamps or add a tie-breaker suffix to guarantee UNLINK always sorts after LINK in the same second.
23
+
24
+
**2026-03-22T00:35:13Z**
25
+
26
+
Classification: behavioral, Score: 2 (BASIC). Root cause: event filename sort key used only the full basename, so when LINK and UNLINK events share the same Unix-second timestamp but have different random UUID segments, alphabetical UUID sort could place UNLINK before LINK. Fix: changed sort key to (timestamp_only, event_type_order, full_name) in both _is_duplicate_link and _get_link_info — ensures LINK always replays before UNLINK at same second. Added Test 9 to test-ticket-link.sh to reproduce the bug deterministically using crafted filenames with controlled UUID ordering.
# debug-everything validation prompts use soft "Do NOT fix" language instead of hard-stop READ-ONLY ENFORCEMENT
13
+
14
+
## Bug
15
+
16
+
The following debug-everything validation sub-agent prompts use soft "Do NOT fix" imperative language instead of the hard-stop READ-ONLY ENFORCEMENT section pattern fixed in w20-w7pm:
Each validation/diagnostic prompt should have a dedicated ## READ-ONLY ENFORCEMENT section that explicitly names the Edit tool, Write tool, and file-modifying Bash commands as PROHIBITED — matching the pattern implemented in w20-w7pm for validate-work prompts.
Copy file name to clipboardExpand all lines: .tickets/w21-3w8y.md
+10-1Lines changed: 10 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,6 @@
1
1
---
2
2
id: w21-3w8y
3
-
status: open
3
+
status: closed
4
4
deps: []
5
5
links: []
6
6
created: 2026-03-20T18:57:23Z
@@ -35,3 +35,12 @@ Children are added to `deps`, causing the epic to self-block. `sprint-list-epics
35
35
36
36
-`plugins/dso/skills/preplanning/` — likely where `tk dep` is called to wire children as blockers
37
37
-`plugins/dso/scripts/sprint-list-epics.sh` — could also filter out self-child deps when computing blocked status
38
+
39
+
## Notes
40
+
41
+
<!-- note-id: s4dz9l0o -->
42
+
<!-- timestamp: 2026-03-22T01:05:02Z -->
43
+
<!-- origin: agent -->
44
+
<!-- sync: unsynced -->
45
+
46
+
CLOSE REASON: Fixed: sprint-list-epics.sh now filters child deps from blocked computation via external_deps; tk index stores parent field in _tk_build_full_index and _update_ticket_index; preplanning/SKILL.md guardrail added against tk dep epic-id story-id. Committed in df51136.
0 commit comments