To test, go to
https://twenty-applications.twenty.com/settings/applications/6aa2ca76-fdbe-456d-89ab-c622452ef055
## After
<img width="1512" height="697" alt="image"
src="https://github.com/user-attachments/assets/5b17f94e-6e0e-400a-8291-a39ad796e423"
/>
## What
Adds the design spec for the next version of the `twenty-last-contact`
public app, extending it from a single `lastContactAt` date column to
the three-column experience in the app's cover image on the All People
view:
1. **Last contact by** — the team member who last interacted with the
person (`ACTOR` field).
2. **Last contact** — the existing `lastContactAt` field, unchanged.
3. **Last contact item** — the email or meeting that was the last
contact, as a clickable record (`MORPH_RELATION` → message |
calendarEvent).
All three columns always describe the same single most-recent
interaction (atomic "newer wins" update).
This PR contains the **design doc only** —
`docs/superpowers/specs/2026-06-29-last-contact-by-and-item-design.md`.
Implementation follows.
## Why
The app today only answers *when* you last talked to someone. These
fields also answer *who* on your team and *through which* email/meeting,
matching the product vision in the cover.
## Key design decisions
- **`lastContactBy` is an ACTOR**, with the team member resolved from
the interaction's participants (`messageParticipant` /
`calendarEventParticipant` both carry `workspaceMemberId` +
`workspaceMember`).
- **No provider (Gmail/Outlook) logo.** That data lived on
`connectedAccount`, which v2.7
(`drop-connected-account-standard-object`) removed from the
app-queryable workspace schema. Confirmed acceptable; the actor still
shows the member + an email/calendar source.
- **`lastContactItem` is a MORPH_RELATION** following the SDK pattern
used by `attachment` / `noteTarget` / `taskTarget` (shared `morphId`,
one field per target, reverse relation on each target object).
## Reviewer notes
- **Load-bearing open risk** documented in the spec: how to *write* a
morph relation through the app's GraphQL API — no app in the repo writes
morph yet. The plan starts with a spike on this; if morph writes aren't
supported from an app, the fallback is two nullable `RELATION` fields
(`lastContactMessage` / `lastContactCalendarEvent`).
- No code/behavior change yet — safe to merge or hold as the design of
record.
<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/22308?utm_source=github"
target="_blank" rel="noopener noreferrer"
data-no-image-dialog="true"><picture><source
media="(prefers-color-scheme: dark)"
srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source
media="(prefers-color-scheme: light)"
srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img
alt="Review in cubic"
src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a>
<!-- End of auto-generated description by cubic. -->
## Summary
- **SDK (`dev` & `dev --once`)**: After app registration, the CLI now
obtains an `APPLICATION_ACCESS` token via `client_credentials` grant
using the app's own `clientId`/`clientSecret`, and uses that token for
CoreApiClient schema introspection — instead of the user's
`config.accessToken` which returns the full unscoped schema.
- **Config**: `oauthClientSecret` is now persisted alongside
`oauthClientId` in `~/.twenty/config.json` when creating a new app
registration, so subsequent `dev`/`dev --once` runs can obtain fresh app
tokens without re-registration.
- **CI action**: `spawn-twenty-app-dev-test` now outputs a proper
`API_KEY` JWT (signed with the seeded dev workspace secret) instead of
the previous hardcoded `ACCESS` token — giving consumers a real API key
rather than a user session token.
## Motivation
When developing Twenty apps, `yarn twenty dev` was using the CLI user's
OAuth token for GraphQL schema introspection during CoreApiClient
generation. This token (type `ACCESS`) has no `applicationId` claim, so
the server returns the **full workspace schema** — including all objects
— rather than the scoped schema the app should see at runtime (filtered
by `applicationId`).
This caused a discrepancy: the generated CoreApiClient contained fields
the app couldn't actually query at runtime with its `APPLICATION_ACCESS`
token.
By switching to `client_credentials` grant, the SDK now introspects with
the same token type the app will use in production, ensuring the
generated client accurately reflects the app's runtime capabilities.
## Summary
- **Config as source of truth**: `~/.twenty/config.json` is now the
single source of truth for SDK authentication — env var fallbacks have
been removed from the config resolution chain.
- **Test instance support**: `twenty server start --test` spins up a
dedicated Docker instance on port 2021 with its own config
(`config.test.json`), so integration tests don't interfere with the dev
environment.
- **API key auth for marketplace**: Removed `UserAuthGuard` from
`MarketplaceResolver` so API key tokens (workspace-scoped) can call
`installMarketplaceApp`.
- **CI for example apps**: Added monorepo CI workflows for `hello-world`
and `postcard` example apps to catch regressions.
- **Simplified CI**: All `ci-create-app-e2e` and example app workflows
now use a shared `spawn-twenty-app-dev-test` action (Docker-based)
instead of building the server from source. Consolidated auth env vars
to `TWENTY_API_URL` + `TWENTY_API_KEY`.
- **Template publishing fix**: `create-twenty-app` template now
correctly preserves `.github/` and `.gitignore` through npm publish
(stored without leading dot, renamed after copy).
## Test plan
- [x] CI SDK (lint, typecheck, unit, integration, e2e) — all green
- [x] CI Example App Hello World — green
- [x] CI Example App Postcard — green
- [x] CI Create App E2E minimal — green
- [x] CI Front, CI Server, CI Shared — green
martmull
