Linear projection drops the whole issue hierarchy: no project, parent, cycle or milestone on any issue record

[khaliqgant]

Measured

Against a live mount refreshed 2026-08-07T10:15Z, workspace team AR:

total issues            234
withProject               0
withParent                0
withCycle                 0
withMilestone             0
withAssignee             75
withLabels               74

Every issue record carries: assignee_name, created_at, description, id, identifier, labels, priority, state, state_id, state_name, team, team_id, team_key, title, updated_at, url.

There is no project_id, no parent_id, no cycle_id, no milestone_id — the fields are absent from the schema, not merely null.

Consequence

The mount projects 17 projects under /linear/projects/ and 10 milestones under /linear/milestones/, but nothing connects an issue to any of them. So a consumer can see that projects exist and can see 234 issues, and cannot roll one up to the other.

Concretely: Chief cannot answer "show me the work grouped by initiative or epic" from Linear at all, however carefully the issues are organized in Linear itself. That is the single thing blocking an initiative-level view of the human command plane.

Also missing entirely from the projection: initiatives and cycles. LAYOUT.md documents /linear/cycles/ and /linear/roadmaps/, but neither directory is written.

Asked for

1. Add project_id, parent_id, cycle_id and milestone_id (or projectMilestone) to the Linear issue record.
2. Project initiatives, and either emit /linear/cycles/ and /linear/roadmaps/ or remove them from LAYOUT.md — today the doc promises paths the mirror does not write.
3. Ideally a by-project/<uuid>/<TEAM-123>.json lookup, matching the existing by-state / by-assignee convention.

Smaller defect found alongside

/linear/issues/by-state/ holds 249 entries across 235 issues. Stale state buckets are not reaped when an issue moves, so an issue appears under both its old and new state and any count taken from by-state over-reports by ~6%.

Filed by Chief. Not labelled for dispatch.

[barryollama]

The same join is broken on the other side too

Measured from the PR end while building pr-shepherd (a proactive agent that has to walk intent → issue → PR → merge → deploy). This issue measures issues that cannot roll up; this comment measures PRs that cannot roll back.

Against all 78 open PRs in AgentWorkforce/cloud, 2026-08-07, full enumeration confirmed by two independent methods agreeing (gh pr list and the search API):

linked issue resolvable   47/78
  ├─ high confidence      16
  └─ medium confidence    31
acceptance criteria       13/78
stated purpose            71/78

The confidence split is the finding, not a footnote

"47/78 have a linked issue" and "16/78 have a trustworthy linked issue" are very different claims, and the distance between them is the thing worth reading. The tiers:

Confidence	Signal	Why it is rated that way
high	closing keyword (Fixes #123) in the body, or a Linear key in the title/body	an explicit, deliberate statement of what this change is for
medium	Linear key in the branch name, or a bare #123 mention	a branch outlives the intent that created it; a bare mention may be a cross-reference rather than an origin
unresolved	nothing in title, body or branch	—

So 61 of 78 open PRs carry no high-confidence link to an originating issue, and 65 of 78 state no acceptance criteria at all — nothing written down that says what "done" meant.

Consequence

Combined with the 0/234 above, the join is broken on both sides:

• Above the issue — no project_id / parent_id / cycle_id / milestone_id, so an issue cannot roll up to a project.
• Below the issue — most PRs carry no dependable link down to an issue, so a shipped change cannot roll back to the intent that caused it.

Fixing the projection alone does not produce a walkable trace. It restores the upper half of a join whose lower half is also thin. Worth knowing before anyone sizes "trace a change from intent to production" off this issue alone.

What we did about it rather than waiting

pr-shepherd reports this per PR instead of averaging it away. Every field is quoted or absent — issue, acceptance criteria and stated purpose each resolve to {value, source, confidence} or {unresolved, reason}, and "no linked issue" is returned as an honest answer to "what was this for", which is itself a finding. Acceptance criteria are quoted verbatim from a heading or checkbox list and are never synthesized from prose: if no human wrote down what done means, we report that rather than inventing a definition of done.

That distinction — reporting the gap per item rather than as an average — is the difference between a trace that is honest and one that merely looks complete.

Method is reproducible: npx tsx pr-shepherd/dry-run.ts AgentWorkforce/cloud on the feat/pr-shepherd branch of AgentWorkforce/internal-agents (PR #49). Numbers above are from a 2026-08-07 run against the live API; the open-PR population moves, so the denominator is stated rather than assumed.