feat(compose): CreateMessageRequest cannot send linkedInTargets or linkedInLinkAsFirstComment

[Adron]

Found during PR #71, recorded during the 2026-09-13 tracker reconciliation.

The gap

The web's message-create body sends two LinkedIn fields the macOS client does not model:

• linkedInTargets — which LinkedIn destination(s) to publish to (personal profile vs one or more company pages)
• linkedInLinkAsFirstComment — post the link as the first comment instead of in the body, the standard LinkedIn reach tactic

CreateMessageRequest (Packages/InterlinedKit/Sources/InterlinedKit/DTOs/MessageDTO.swift) models neither. It carries crossPostToLinkedIn: Bool? — a yes/no with no destination choice.

What that means today

A user with a personal profile and one or more assigned company pages has no way to choose from macOS. The server applies its default. Per /help/organizations, an assigned member's default destination is the company page — so "cross-post to LinkedIn" can publish somewhere the user did not intend and cannot redirect.

PR #67 already fixed the display half of this confusion: LinkedInTargetDTO.kind had the wrong taxonomy (personal/org instead of the real personal/orgPage/personalPage), which made the composer's "Posting as …" line name a personal profile while the server published to a company page. The line is now correct — but it is still only a readout, not a control.

Why it was not built in PR #71

It needs the Integrations/Organizations projection to exist — the composer has to know which targets are available before it can offer them. #47 (Integrations) and the org-LinkedIn work in PR #67 are the supply side. Half-building a picker over an incomplete target list was the worse option.

Dependencies

Sequence after #47. PR #67 already ships LinkedInPostingTargets.defaultDestination and the org-LinkedIn routes, so much of the domain supply exists; what is missing is the personal-side inventory and the composer control.

Acceptance

• The composer offers the real destination list, defaulting to what the server would choose anyway.
• linkedInLinkAsFirstComment is a visible toggle.
• Both ride the create body; a scheduled post carries them too.
• The "Posting as …" line reflects the chosen destination, not the inferred default.

[Adron]

Blocked — the supply side is empty, and that is the whole dependency

This issue says to sequence after #47. #47 shipped as PR #93, so here is where that leaves things.

Probed 2026-09-15

GET /api/linkedin/posting-targets → 200 {"targets":[],"orgScopeMissing":false}

Empty. The test account has no LinkedIn identity linked and no assigned company pages, so the populated targets[] row shape has never been observed.

Note orgScopeMissing — an undocumented boolean this issue does not mention. It presumably means the connection lacks the organization scope needed to post to a company page, which is a real UI state (the picker would need to say so rather than showing an empty list), but that reading is inference, not evidence.

Why PR #93 did not build the picker

It deliberately deferred LinkedIn posting-target editing for this reason and said so. Building a destination picker over an empty array means inventing the row shape, and this repo has three shipped defects from exactly that (G21 link metadata, G25 org members, and the list-schema contract in #85).

The composer's readout is already correct — PR #67 fixed LinkedInTargetDTO.kind's taxonomy (personal/orgPage/personalPage). It is still a readout, not a control, exactly as this issue describes.

What we need from you

One of:

1. Link LinkedIn on the .env test account and, ideally, assign it a company page. Then GET /api/linkedin/posting-targets returns real rows and this becomes buildable in one pass.
2. Paste a populated targets[] payload here from an account that has one — including at least one orgPage entry, since the personal-only case would not exercise the choice this feature exists for.
3. Confirm what orgScopeMissing: true looks like in practice, and whether the web surfaces it as a reconnect prompt.

Also still unconfirmed

This issue's other half — linkedInLinkAsFirstComment on CreateMessageRequest — is a plain boolean and could be added blind. It is not worth shipping alone: a toggle for "post the link as the first comment" next to a destination picker that does not exist is half a feature, and the two ride the same create body. They should land together.