Sync Linear app actors as service accounts

[VVill-ga]

Linear returns OAuth applications and agents installed into a workspace as users with app=true. Select that field too, and report such users with ACCOUNT_TYPE_SERVICE.

API described here, no good linear docs my 🤖 could find.
https://studio.apollographql.com/public/Linear-API/variant/current/schema/reference/objects/User#app

[github-actions]

Superseded — see the current review report for commit 56d05ddaeaa9

Connector PR Review: Sync Linear app actors as service accounts

Blocking Issues: 0 | Suggestions: 0 | Threads Resolved: 0
Criteria: Criteria status: loaded .claude/skills/ci-review.md from trusted base 5f2728c9609a.
Review mode: full
View review run

Review Summary

The PR adds app to the GetUsers GraphQL selection (pkg/linear/client.go:174) and a matching App bool field (pkg/linear/models.go:48). Linear users with app=true now get WithAccountType(ACCOUNT_TYPE_SERVICE) (pkg/connector/user.go:70-72), and a table-driven test covers both cases. I scanned the full PR diff for security and correctness issues.

• Only one place builds user resources: userResource is called only from List (pkg/connector/user.go:119), so every synced user now gets a consistent account type.
• The SDK helper is available: WithAccountType exists in the vendored baton-sdk v0.36.0, and no dependency changes were needed.
• Repo-local criteria: I applied the trusted criteria. R12 is the relevant rule: non-human identities are modeled as user resources with the service account type, which this change does correctly.
• Nothing breaks: resource IDs, type IDs, entitlements and the parent hierarchy are unchanged, so B1–B9 and BP don't apply. Adding a trait option counts as a safe change under B9.
• No other rule triggers: the change adds no new logging, error paths, spans, provisioning code or endpoints (app is a new field on an existing query), so sections A, B, C, F, S and B10 don't apply.
• JSON safety (J1–J3): app is a non-null boolean in Linear's schema, so a plain bool is fine.
• Docs: the resource types in docs/connector.mdx are unchanged, so that file doesn't need an update. README.md was updated.

Security Issues

None found.

Correctness Issues

None found.

Suggestions

None.

[github-actions]

Connector PR Review: Sync Linear app actors as service accounts

Blocking Issues: 0 | Suggestions: 0 | Threads Resolved: 0
Criteria: Criteria status: loaded .claude/skills/ci-review.md from trusted base 5f2728c9609a.
Review mode: full
View review run

Review Summary

The PR adds app to the GetUsers GraphQL selection (pkg/linear/client.go:174) and a matching App bool field (pkg/linear/models.go:48). Linear users with app=true now get WithAccountType(ACCOUNT_TYPE_SERVICE) (pkg/connector/user.go:70-72), and a table-driven test covers both cases. I scanned the full PR diff for security and correctness issues.

• Only one place builds user resources: userResource is called only from List (pkg/connector/user.go:119), so every synced user now gets a consistent account type.
• The SDK helper is available: WithAccountType exists in the vendored baton-sdk v0.36.0, and no dependency changes were needed.
• Repo-local criteria: I applied the trusted criteria. R12 is the relevant rule: non-human identities are modeled as user resources with the service account type, which this change does correctly.
• Nothing breaks: resource IDs, type IDs, entitlements and the parent hierarchy are unchanged, so B1–B9 and BP don't apply. Adding a trait option counts as a safe change under B9.
• No other rule triggers: the change adds no new logging, error paths, spans, provisioning code or endpoints (app is a new field on an existing query), so sections A, B, C, F, S and B10 don't apply.
• JSON safety (J1–J3): app is a non-null boolean in Linear's schema, so a plain bool is fine.
• Docs: the resource types in docs/connector.mdx are unchanged, so that file doesn't need an update. README.md was updated.

Security Issues

None found.

Correctness Issues

None found.

Suggestions

None.

---

Reviewed commit: 56d05ddaeaa9

[github-actions]

No blocking issues found — see the full review report

[linear-code]

CXH-2696