feat(agent-harness): reuse authorized invitations with durable replay

[iscekic]

No new behavior — this change prepares invitation handling without changing the existing invitation flow or adding approval controls.

---

Summary

executeHarnessInvitation and reconcileHarnessInvitation add authorized backend execution and permanent kilo.invite replay, using InvocationSchema for immutable arguments and CanonicalResultSchema for stored responses.
One transaction commits the invitation, audit, queue entry, and agent_harness_invitation_results record containing the operation identity, fingerprint, invitation reference, and canonical result.
Matching retries recover that result; changed arguments return CONFLICT, and reconciliation returns null without a new effect when no result exists.

Files

• apps/web/src/lib/agent-harness/invitation.ts — adds server-derived actor/context, immutable recipient/role, normalized identifiers, a harness-only 64 KiB limit, and rejection of personal conversations or caller-selected authority. Execution calls the shared backend operation without a coding sandbox. User-before-thread locks serialize admission even without an operation record; both calls recheck current account, organization, membership, context, and grant authority under locks. Both calls check grant expiry after waiting for its lock. Replay survives invitation expiry, acceptance, revocation, deletion, and later billing expiry; invalid canonical results fail without replacement. Accepted work survives client sign-out; output includes only invitationId and emailQueued: true, not an invitation link or a delivery claim.
• apps/web/src/lib/agent-harness/invitation.test.ts — adds pure validation and mapping cases plus PostgreSQL cases for replay, reconciliation, atomic writes, current authority, transaction-local reads, and progress with occupied connections. Race cases exercise duplicate admission, role revocation, retirement, and account deletion in both orders; rollback cases cover queue and result failures.

inviteOrganizationMember extracts the complete authorized invitation operation and accepts a caller-owned transaction, so the harness and organizations.members.invite use the same rules.
Billing/trial checks, management-role and owner restrictions, single sign-on (SSO), audit records, queueing, and existing error mappings stay intact.
Legacy callers keep their input, response, middleware ordering, and duplicate-request conflicts; they need no operation identity and create no replay record.

Files

• apps/web/src/lib/organizations/member-invitation.ts — adds the server-only operation and reuses the supplied transaction or opens one for the invitation, audit, and queue writes. It preserves pending-invitation and existing-member conflicts, child-organization refusal, SSO errors, and owner-only grants. The response remains { acceptInviteUrl, invitationId, emailStatus: 'pending' }; email delivery retries and cron processing do not change.
• apps/web/src/routers/organizations/organization-members-router.ts — delegates invite to the shared operation while retaining InviteMemberSchema and billing middleware. The compatibility comment retains old web/native callers until those clients retire.
• apps/web/src/routers/organizations/organization-members-router.test.ts — adds compatibility coverage for recipient case, seven-day expiry, the response and queue payload, absent replay records, duplicate-request conflicts without extra effects, authorization-before-validation, and SSO/trial failures.

ensureOrganizationAccess, requireActiveSubscriptionOrTrial, and getMostRecentSeatPurchase accept an optional DrizzleTransaction so invitation checks use the same connection and transaction-local data.
getOrganizationEntitlementClassification propagates that transaction through organization and seat reads, avoiding another pool checkout during execution and reconciliation.
Callers that omit the transaction retain the primary-database default, role priority and inheritance, admin elevation telemetry, entitlement classification, ordering, and errors.

Files

• apps/web/src/routers/organizations/utils.ts — uses the supplied transaction for direct and inherited membership queries, with the existing primary database as the default.
• apps/web/src/lib/organizations/trial-middleware.ts — passes the optional transaction through trial classification and organization/seat lookups; existing compute entitlement calls retain their default.
• apps/web/src/lib/organizations/organization-seats.ts — adds transaction-based lookup without changing newest-created ordering or the null result when no purchase exists.

Tests: 2 files changed — invitation.test.ts added (1,170 lines); organization-members-router.test.ts expanded (195 added lines).
Generated: 0 files changed.

---

Verification

No manual verification ran for this level. Runtime verification remains pending at the completed stack tip; this level does not activate the complete runtime.

Visual Changes

Visual Changes: N/A

Reviewer Notes

• Scope: level 16 only, covering the authorized invitation operation and permanent replay without activating the complete runtime or adding approval controls.
• The implementer reports all six permitted checks passed through run-checks.sh: formatting, lint, format verification, pure tests, test discovery, and diff validation.
• No approved isolated local PostgreSQL inputs exist, so database execution, including transaction races and legacy-router behavior, remains pending in continuous integration (CI).
• Repository-wide type, build, lint, test, and format checks also remain pending in CI.

Human steps

• This level requires no human setup before merge or after merge; it adds no environment value, secret, migration, or flag.
• No human verification step is delegated. The orchestrator must verify the completed stack before human-ready; product PRs remain unmerged.

Notes

Runtime verification remains pending at the completed stack tip. Local checks passed 24 pure cases; 52 PostgreSQL cases await CI. Test discovery does not prove transaction behavior or live effects.

Stacked PRs — merge bottom to top. Each level shows only its own diff.

Runtime verification (E2E, user advocacy, simplify) runs on the tip PR over every level.
Every level keeps its own checks, its own bot review, and its own threads; each one is answered on its own PR.
Each level is its own deliverable: it builds and passes its own checks alone.
A finding on a level is repaired on that level, then carried upward with stack.sh forward.

1. shared-agent-harness-3bb0 — chore(agent-harness): register workspaces and enforce CI boundaries #5632
2. shared-agent-harness-3bb0-s2 — feat(agent-harness): define portable domain and snapshots #5637
3. shared-agent-harness-3bb0-s3 — feat(agent-harness): define commands tools and permission policy #5639
4. shared-agent-harness-3bb0-s4 — feat(agent-harness): share client state and cursor recovery #5643
5. shared-agent-harness-3bb0-s5 — feat(agent-harness): persist command intents and execution receipts #5647
6. shared-agent-harness-3bb0-s6 — feat(db): add harness ingress grants and retirement fences #5655
7. shared-agent-harness-3bb0-s7 — feat(agent-harness): deliver legacy history and project durable text #5659
8. shared-agent-harness-3bb0-s8 — feat(agent-harness): authorize durable grants and registered clients #5662
9. shared-agent-harness-3bb0-s9 — feat(agent-harness): fence retirement and retry payload cleanup #5667
10. shared-agent-harness-3bb0-s10 — feat(agent-harness): persist authoritative state in SQLite #5675
11. shared-agent-harness-3bb0-s11 — feat(agent-harness): admit durable runs and revisioned commands #5678
12. shared-agent-harness-3bb0-s12 — feat(agent-harness): recover queued runs and stream checkpointed steps #5688
13. shared-agent-harness-3bb0-s13 — feat(agent-harness): resolve interactions and dispatch tools sequentially #5693
14. shared-agent-harness-3bb0-s14 — feat(agent-harness): fence designated client tool execution #5697
15. shared-agent-harness-3bb0-s15 — feat(agent-harness): synchronize durable snapshots and legacy history #5701
16. shared-agent-harness-3bb0-s16 — feat(agent-harness): reuse authorized invitations with durable replay #5704 ← this PR
17. shared-agent-harness-3bb0-s17 — feat(integrations): bound repository transport for harness reads #5710
18. shared-agent-harness-3bb0-s18 — feat(integrations): expose bounded authorized repository reads #5714
19. shared-agent-harness-3bb0-s19 — feat(agent-harness): expose named authorized resource reads #5718 (tip)

[kilo-code-bot]

Code Review Summary

Status: No Issues Found | Recommendation: Merge

Files Reviewed (8 files)

• apps/web/src/lib/agent-harness/invitation.ts
• apps/web/src/lib/agent-harness/invitation.test.ts
• apps/web/src/lib/organizations/member-invitation.ts
• apps/web/src/lib/organizations/organization-seats.ts
• apps/web/src/lib/organizations/trial-middleware.ts
• apps/web/src/routers/organizations/organization-members-router.ts
• apps/web/src/routers/organizations/organization-members-router.test.ts
• apps/web/src/routers/organizations/utils.ts

---

_{Reviewed by grok-4.6 · Input: 195.1K · Output: 23.5K · Cached: 961.7K}

_{Review guidance: REVIEW.md from base branch shared-agent-harness-3bb0-s15}