Say which schema carries the fields we do not have yet

Say which schema carries the fields we do not have yet

The section listing `type`, `sub_issues_summary` and `issue_dependencies_summary`
said "the current schema", meaning GitHub's. It reads as ours, and ours has
none of them -- there is no column and no migration. A reader following the doc
would build a renderer against fields that return nothing.

Deploy story

What this commit did to the running system — joined from the forge receipt chain, the part a commit page elsewhere cannot show.

Not deployed through the forge lane

No push, promotion, build, or deploy receipt references this commit (receipts are scanned over a bounded recent window). Changes shipped by full node replacement carry their proof in the release gate receipt instead.

Changed files

modified docs/2026-08-20-linear-design-github-shape.md

Diff

1 file changed, +8 -4


## What GitHub gives us that Linear's model does not

Worth stating, because the constraint is not only subtractive. The current
schema also carries:
Worth stating, because the constraint is not only subtractive. GitHub's own
schema carries these, and **ours does not yet** -- they are fields to grow
into, not fields to render today. Read the distinction carefully: an earlier
draft of this section said "the current schema", which was read as ours and
is not true of it.

- **`type`** — an issue type (bug, feature, task) with a colour, enabled per
  org. Circle's issue has no equivalent.

  parent/child issues.
- **`issue_dependencies_summary`** — blocking relationships.

These are real GitHub fields, so they are all fair game, and Circle has no
vocabulary for any of them. The progress arc in `issue_status/1` already fills
These are real GitHub fields, so they are all fair game once we store them,
and no competing tracker has vocabulary for any of them. Until a migration
adds them, a page that renders them is rendering nothing. The progress arc in `issue_status/1` already fills
from a number, which makes it the obvious renderer for
`sub_issues_summary.percent_completed` — a Linear-derived control displaying a
GitHub-native fact, which is exactly the shape this whole document is arguing

88	88
89	89		`## What GitHub gives us that Linear's model does not`
90	90
91		-	`Worth stating, because the constraint is not only subtractive. The current`
92		-	`schema also carries:`
	91	+	`Worth stating, because the constraint is not only subtractive. GitHub's own`
	92	+	`schema carries these, and ours does not yet -- they are fields to grow`
	93	+	`into, not fields to render today. Read the distinction carefully: an earlier`
	94	+	`draft of this section said "the current schema", which was read as ours and`
	95	+	`is not true of it.`
93	96
94	97		- `type` — an issue type (bug, feature, task) with a colour, enabled per
95	98		`org. Circle's issue has no equivalent.`

97	100		`parent/child issues.`
98	101		- `issue_dependencies_summary` — blocking relationships.
99	102
100		-	`These are real GitHub fields, so they are all fair game, and Circle has no`
101		-	vocabulary for any of them. The progress arc in `issue_status/1` already fills
	103	+	`These are real GitHub fields, so they are all fair game once we store them,`
	104	+	`and no competing tracker has vocabulary for any of them. Until a migration`
	105	+	adds them, a page that renders them is rendering nothing. The progress arc in `issue_status/1` already fills
102	106		`from a number, which makes it the obvious renderer for`
103	107		`sub_issues_summary.percent_completed` — a Linear-derived control displaying a
104	108		`GitHub-native fact, which is exactly the shape this whole document is arguing`