[richlander]

Summary

Adds docs/design/annotated-type-map-api-family.md, the focused owner for
planning step 4. Planning step 4 registers the API shape-fact family and routes
Finding Diff Any's API census settlement through a family contribution request.

Finding Diff Any's settlement depends on code internal to
ILInspector.Metadata: the census key grammar, the Member key function, and
API-equality extraction. DotnetInspector.Sections cannot see that code, so
the design splits the work at that boundary:

• Producer, in ILInspector.Metadata: returns one side's API shape facts
  for one Type, keyed by Finding Diff Any Member key. It selects Members by
  key, not name, so asking for one overload extracts only that overload.
• Settlement seam, in ILInspector.Metadata: a public delegate beside the
  existing Body reader seam.
• In DotnetInspector.Sections: the family registration, its adapter, and
  a settler that forms a family contribution request over the pair. The
  settler settles that request with SettleContributions and compares the two
  sides with the complete API comparison.

There is one producer and one comparison. Without the seam, Finding Diff Any
settles inline through the same producer.

Amendments

• Planning Focus: an acquired Type authority is bound to one
  registration, so a pair request now carries one Type focus authority per
  side.
• Generation: settles the open points carried from PR Implement Annotated Type Map contribution content and family results #10940:
  • A missing result fails through typed result access
    (InspectionQueryException).
  • Every family on one side holds the same key set, and correspondence
    enforces it.
  • A Member the surface does not admit is NoApplicableInput.
• Generation adoption: planning step 4 now comes before generation slice
  2. Slice 2's fact comparison needs fact-stream content that the map's
  adoption step 3 has not yet defined.

Validation

npx markdownlint-cli passes on all three changed documents.

Tracked by #10215, under theme #10169.

🤖 Generated with Claude Code

[richlander]

Round 1 reconciliation (head dadd791d0)

The reviewer was Claude opus, standing in for GPT-6 Sol, because this harness
advertises no GPT models. The result is not clean: one blocking finding,
which I accepted, and five observations. The fixes for all six go into the
round 2 candidate.

• B1 (accepted). The new owner changed Finding Diff Any's API settlement
  without amending finding-diff-any.md. The round 2 candidate makes these
  changes:
  • It amends finding-diff-any.md#api-census-settlement. That section now
    says this owner's adoption step 2 moves projection selection from Member
    names to FindingDiffAnyMemberState.Key, adds a settlement seam beside the
    Body reader, and replaces the name-selection gate. The name rule stands
    until then.
  • The new owner now declares that amendment in its status section and in
    its Consumed contracts table.
• Observation 1 (taken). "Computes nothing outside the Type" is now
  "projects nothing outside the Type". The document also names the
  extractor's image-wide JSExport scan and its Type-definition walk as shared
  with today's inline settlement and unchanged.
• Observation 2 (taken). The non-null AnnotatedTypeMapApiMemberFacts
  projection is now written as a target state of adoption step 3.
• Observation 3 (taken). The unreachable "generated code owns" case is
  dropped from both the producer text and the Key selection gate. The API
  census covers only the Type's own row and Members.
• Observation 4 (taken). The planning owner now says the plan retains each
  side's focus. Its failure contract now rejects a focus-authority count other
  than one per side, and a pair whose authorities name different Types.
  Adoption step 3 names the per-side focus and equal-key-set correspondence
  as implementation work.
• Observation 5 (taken). A Type admitted on neither side is Unchanged,
  matching how two empty projections settle inline.

I recorded a disposition for each of the four points carried from PR #10940.
All four are resolved in the design; implementing them is pending.

🤖 Generated with Claude Code

[richlander]

Round 2 reconciliation (head 64cba4f27)

CLEAN. Reviewer: Claude opus, standing in for GPT-6 Sol because this harness advertises no GPT models.

The round 1 finding (B1) and all five round 1 observations are resolved. The four points carried over from PR #10940 are resolved in the design; their implementation belongs to adoption step 3.

Two non-blocking observations carry forward:

1. Producer failure and one key set per side. A family whose producer fails holds no Member entries. Once a second family shares a side (planning step 5), the equal-key-set rule would make that failure throw a contract exception. Before step 5, the design must say either that a failed family emits Failed entries for every key, or that failure is exempt from the equal-key-set rule.
2. Facts that belong to the Type itself. An uncertain fact the Type itself owns rather than a Member, such as an enum's value__ or a MethodImpl row, makes the whole Type the projection. This already follows from the owner rules. Step 2 can state it in one sentence.

🤖 Generated with Claude Code

[richlander]

Held for PR #10956

The maintainer settled what the map is for: it holds the Type's coordinate plus
the Members its request implicates, so Count counts the implicated Members. A
request naming no analysis returns only the coordinate. PR #10956 amends the
map owner to say this.

Once PR #10956 merges, this PR gets a round 3 with two changes:

• With no key set, the producer returns only the Type's own entry.
• When the Type owns an uncertain difference, Finding Diff Any's settlement
  passes every census Member key explicitly, instead of asking for the whole
  Type.

I removed review-clean because the round 2 result no longer stands.

🤖 Generated with Claude Code