# 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 a single number. Two parents are not
expressible, not merely rejected.
**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: 3`
$ tix lint
error[E-tix-lint]: invalid unresolved_parent value '3'
--> herbert-maschke/2026-09-29-refactor-store.md:8:9
|
```
Cascading a delete is never what happens: silently destroying a subtree because one
node went away is not a thing this tool does.