OpenSpec: add-project-overview-family-relationships (a family holder is one overview row with relationships [], so its members, legs and siblings cannot be seen from it) #36

Lane: openRepoProject-1

This is the governing issue for a new OpenSpec change, add-project-overview-family-relationships.

Origin. Brett Heap assigned it with "start report E's candidate 3" (2026-10-22T17:39:41Z). That gives lane openRepoProject-1 the third candidate of its 2026-10-20 work survey: a proposal for family traversal and relationships. It is one of the extensions the ratified add-project-overview change lists as Out of Scope, each to get its own proposal (OQ-27; openspec/changes/add-project-overview/proposal.md:558-571 at 15504f1).

Refs #6, the record of the packet, and #10, the overview change's governing issue.

Problem

project overview comes from change add-project-overview, ratified and being realized as feature 005. It shows a family.yaml holder as exactly one row of kind family-holder, and that row's relationships is always []:

• it never reads the members list;
• it never visits declared siblings, pinned member copies or mounted legs.

Sources: ideation/brainstorm/project-maintenance-project-discovery.md:276-290 at da33d92, and the overview proposal's comparison row "Recursion into family members" (proposal.md:802).

So from the overview a person cannot see, for a family:

• which members it declares;
• which of them are present, missing or out of place;
• which other rows in the report belong to it.

The packet sets two limits on this work:

• Its boundary. The packet defers family relationships with the same boundary as the remote and bench extensions: opt-in probes, bounded time, explicit unknown values, and no mutation (project-maintenance-project-discovery.md:1062-1064).
• No cleanup permission. The synthesis says that family grouping, when added, never grants permission to clean a sibling (project-maintenance-synthesis-inspect-and-retire.md:34-37).

project already reads family.yaml in other commands. The proposal records where and how.

Intended scope (for the proposal to settle)

First, an observation record:

• what project and the packet say about families today;
• the decisions Brett Heap would need to make for a family-relationships extension of project overview.

Spec deltas are held until two things settle, so that they are written once:

• feature 005's clarify answers (the A1 amendment, OpenSpec: amend add-project-overview with Brett Heap's answers to feature 005's clarify questions (A1) #34);
• OpenSpec: add-project-overview-remote-merge-status (opt-in exact-head GitHub pull-request evidence in project overview --remote) #29's overview blocks.

Out of scope:

• any change to clean's eligibility, since family grouping grants no cleanup permission;
• bench, container and park integrations, which are their own extension;
• remote queries (OpenSpec: add-project-overview-remote-merge-status (a branch merged on GitHub by squash or after its upstream was deleted is shown as unmerged with no explanation) #25, OpenSpec: add-project-overview-remote-merge-status (opt-in exact-head GitHub pull-request evidence in project overview --remote) #29).