Motir

The "claim" surfaced by motir run 6.14.5 (2026-06-15). Subtask 6.14.5 ("Tree UI — a public viewer EXPANDS a private epic in the tree → the 'this epic is not public' placeholder") is premised on a public-facing, hierarchical, expandable work-item TREE view for public projects. That surface does not exist, so 6.14.5 has no host and is now blocked_by this item.

What is actually shipped (rung-2 evidence)

• The public project (/p/[identifier]) has FOUR flat tabs: Overview, Board (status columns), Work items (a flat, cursor-paginated LIST — app/(public)/_components/PublicWorkItemList.tsx, subtask 6.12.4), Roadmap (status columns). None is an expandable epic tree.
• 6.14.4's shipped architecture (its test, tests/publicProjects/epicPrivacyEnforcement.test.ts lines 22–27): "the ONLY surface a non-member can reach on a public project is publicProjectsService … the internal workItemsService tree / detail / ready / search reads are workspace-scoped — a cross-org non-member 404s there and a member bypasses." Confirmed in lib/services/projectAccessService.ts (the authed resolveInputs 404s a cross-workspace actor; only resolveInputsForPublicRead crosses the org boundary, and only for the flat public surface).
• So the childrenHidden marker (6.14.4) is transmitted ONLY on the flat public list rows + board cards; the authed WorkItemTreeRowDto never carries it, and a non-member cannot reach the authed tree anyway. A member bypasses enforcement and sees children (no placeholder). The "tree-expand placeholder" (design 6.14.1 panel 2) therefore has no surface.

What this subtask would build (IF chosen)

A public, read-only, expandable hierarchical tree of work items for a public project (epics → children), over the 6.12.4 public projection + the 6.14.4 enforcement, so a public/non-member viewer can expand an epic — and a PRIVATE epic shows the 6.14.1 tree-expand placeholder instead of children. This is the surface 6.14.5 (tree placeholder) + 6.14.6 (detail child-panel) + 6.14.9 (e2e tree-expand) all assume. (Natural domain is public-projects / Story 6.12; parented under 6.14 because that is where the conflict surfaced — re-parent if preferred.)

Open question — Yue decides, not the planner

The mirror products this story cites (GitLab confidential issues, Canny public roadmaps — design/epic-privacy/design-notes.md) present public views as FLAT lists / columns, NOT expandable epic trees (rung 1). So the alternative to building this surface is to re-scope 6.14.5 to the flat public surface: render design 6.14.1 panel 1 ("Not public" badge + "Contents hidden") + panel 6b (the badge on board / roadmap cards) on the existing PublicWorkItemList rows + PublicWorkItemCard, where the marker actually lands, and drop the tree-expand placeholder (panel 2). Under that path THIS subtask is closed won't-build and 6.14.5 / 6.14.6 / 6.14.8 / 6.14.9 + the 6.14.1 design are reframed to the flat surface.

The decision is Yue's: motir run THIS item to build the public tree, OR tell me to reframe 6.14.5 (+ siblings + design) to the flat public surface.

Context refs

• app/(public)/_components/PublicWorkItemList.tsx, PublicWorkItemCard.tsx, app/(public)/p/[identifier]/{items,board,roadmap}/page.tsx — the shipped flat public surfaces.
• lib/services/projectAccessService.ts, lib/services/publicProjectsService.ts, lib/mappers/publicProjectsMappers.ts (childrenHidden), lib/dto/publicProjects.ts.
• tests/publicProjects/epicPrivacyEnforcement.test.ts (the architecture note, lines 22–27).
• design/epic-privacy/design-notes.md (panels 1 / 2 / 6b + the rung-1 mirror citations).
• Blocks: 6.14.5 (MOTIR-435); related: 6.14.6 (MOTIR-436), 6.14.9 (MOTIR-439).