tix-tracker 0.12.0

A terminal issue tracker: markdown + YAML frontmatter issues with a kanban TUI and CLI
Documentation 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67

# Parent issues

An issue can have **one** parent. That makes a decomposition tree — *this is part
of that* — and it is deliberately **not** a dependency edge. "Must happen before"
is a [`--type blocks` relationship](relationships.md); "part of" is a parent. Using
a parent to mean ordering is the mistake this distinction exists to prevent.

```bash
tix create --title "Refactor store" --parent 3        # a child of #3
tix edit 7 --parent 3                                 # set or change
tix edit 7 --parent ""                                # clear it
tix parent show 3                                     # one issue's hierarchy
tix parent children 3                                 # its direct children
tix parent list                                       # the whole board
tix search "parent:3"                                 # the same set, filtered
```

```
$ tix parent show 3
Parent of #3
  parent: none
  children: 2
  completed: 1/2 (direct children only)
Children
  #7 Refactor store
  #9 Add a parser
```

**One parent, never a list.** `parent:` holds one canonical issue id. Two parents
are not expressible, not merely rejected. Numbers remain input aliases:

```yaml
# A1B2C3D4 is the parent's id; #3 is only how people address it.
parent: A1B2C3D4
```

`tix create --parent 3`, `tix edit 7 --parent 3`, and
`tix search "parent:3"` all resolve `#3` through the project alias index. An
ambiguous number is refused rather than guessed, while the canonical id still
selects one issue.

**What is refused.** An issue cannot be its own parent, and a parent change that
would close a cycle is refused. A refused change writes **nothing** — no file, no
number, no history entry — and the reason is the same text whichever surface you
asked on (CLI, TUI or MCP).

**Rollups count direct children only.** `3/2` over a subtree and `3/2` over direct
children are different numbers wearing the same clothes, so the completion line
always names the population: `(direct children only)`.

**Deleting a parent keeps its children.** The reference survives, and `tix lint`
reports it as `unresolved_parent` naming the child and the missing target, so it can
be repaired:

```
$ tix delete 3 --yes
  #7 Refactor store  - keeps `parent: A1B2C3D4`
$ tix lint
error[E-tix-lint]: invalid unresolved_parent value 'A1B2C3D4'
  --> herbert-maschke/2026-09-29-refactor-store.md:8:9
   |
 8 | parent: A1B2C3D4
   |         ^^^^^^^^ 7's parent A1B2C3D4 no longer exists (the reference is kept so it can be repaired)
```

Cascading a delete is never what happens: silently destroying a subtree because one
node went away is not a thing this tool does.