mirror of
https://github.com/twentyhq/twenty.git
synced 2026-09-16 16:06:17 -04:00
c-async-csv-export
9
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 martmull
|
330cf9c39d |
Publish Twenty app skills as a portable Agent Skills collection (skills.sh) (#25913)
Closes #22892. Publishes the Twenty app skills as a harness-agnostic Agent Skills collection installable with the open `skills` CLI. ```bash npx skills add twentyhq/twenty/packages/twenty-agent-skills --list npx skills add twentyhq/twenty/packages/twenty-agent-skills --skill create-app ``` Works in Claude Code, Codex, Cursor, Pi, and anything else the CLI supports. ## How it is built One canonical source, two generated distributions, validated on both ends: ``` packages/twenty-agent-skills/ skills/ canonical SKILL.md x5 ─┐ references/ canonical docs ─┤ │ validate-source.js (is the source correct?) ▼ build.js │ rewrites ../../references/ links to skill-relative, │ copies the transitive closure of referenced docs ▼ dist/skills/ portable skills ─┬─ validate-distribution.js (does dist match the source?) dist/.codex-plugin/ Codex plugin ─┘ │ ▼ verify-install.js (does what the CLI installed match dist, file for file?) ``` Each installed skill directory is self-contained: no monorepo paths, no sibling-skill or Codex-wrapper dependencies. The five skills: `create-app`, `develop-app`, `manage-app`, `publish-app`, and the optional `use-twenty-mcp`. ## What changed here **Single source of truth.** `references/concepts/operating-rules.md` is the only copy of the operating rules. `AGENTS.md` and every SKILL.md link to it and keep only their own additions; `assertOperatingRulesSingleSource` fails the build if any of them restates a rule headline, copies a sentence from a rule body, or drops the pointer. **Real install verification.** `verify-install.js` discovers every installed copy of a skill (`.claude/skills`, `.agents/skills`, symlinks included) and diffs it against `dist/` in both directions, then re-runs the self-containment and frontmatter assertions on the installed tree. CI installs each skill into Codex and Claude Code separately, then the whole collection, and verifies each one. A `main`-only job exercises the two remote URL forms, which can only resolve once merged. **Content regenerated against current `main`.** The previous attempt (#23011) carried July content (`yarn twenty dev --once`, no standalone-page layouts, a stale validator expectation). **Self-hosted is first class.** `references/use-twenty-mcp/setup.md` is now multi-harness MCP setup with user-supplied workspace URLs, custom domains and localhost as first-class targets. Validation fails if `create-app` stops presenting self-hosted as supported, or if MCP setup starts requiring a `twenty.com` workspace. **Telling the two skill families apart.** The repo also ships `syncable-entity-*` skills, which are internal guides for changing Twenty's own server code. Their descriptions now open with "Contributing to the Twenty codebase itself (twentyhq/twenty server internals), not for building apps on top of Twenty", `SKILLS.md` at the repo root maps every skill family and who it is for, and the README and quick-start point at the app skills with the package-scoped command. **Cursor cleanup** (from #25946, approved and merged into this branch, so both land together): `.cursor` is gone entirely — 16 `.mdc` rules, the background-agent config, the `CLAUDE.md` pointer, a gitignore entry and a `.cursorrules` editor association for a file that does not exist. The six `syncable-entity-*` skills moved to `.claude/skills/` next to `qa-scout`. That changes the bare-repo listing (`.claude/skills` is default-scanned, `.cursor/skills` was not), which is what the description prefix above is for. The package-scoped listing is unaffected and still returns exactly the five app skills, asserted by `agent-skills-validate`. **One package, not two** (#25970): `twenty-codex-plugin` used to hold a hand-synced copy; it was folded into this package so both distributions build from one source. **Review follow-ups:** `verify:install` is an nx target rather than a raw node invocation; `CANONICAL_SKILL_NAMES` has a single definition; the `scripts/` tree is ESM. ## Verified - `validate-source` → `build` → `validate-distribution` pass, plus 72 unit tests. - Real `skills` CLI: all five skills install into Claude Code and Codex, individually and together, each installed tree matching `dist/` file for file in both directions. - Self-hosted scaffold-and-develop smoke test against a local server: scaffolded an app, added an object with `yarn twenty dev:add`, synced with `yarn twenty apply`, confirmed `objectMetadata`, `navigationMenuItem` and the physical workspace table landed. Recorded in `SMOKE-TEST.md`. ## Known, not addressed here `create-twenty-app` still calls `yarn twenty dev --once` internally while the skills direct agents to `yarn twenty apply`. The skill content is consistent; the scaffolder's internals lag. Worth a separate issue. |
||
|
Thomas des Francs
|
d168df965e |
Simplify page layout manifest authoring (#25513)
## Summary Vertical-list widgets can now omit `position` and use array order, with an optional top-level `heightBehavior`. For example, `heightBehavior: 'TAB_VIEWPORT'` makes a widget fill the tab without repeating the tab mode or an index. Existing Canvas tabs, explicit widget indices, and nested height settings keep their behavior. SDK validation warns about deprecated shapes and explains the replacement; it does not rewrite manifests. Shared validation also checks the new height setting and viewport ordering before installation. Existing apps keep their published SDK syntax. This PR updates the local SDK fixture and current API documentation; app migrations can follow after the SDK is published. Stack 3/4, following the CI prerequisite and runtime height support. The final PR migrates eligible stored Canvas tabs. Review and merge order: 1. [App CI repairs](https://github.com/twentyhq/twenty/pull/25531) 2. [Widget height behavior](https://github.com/twentyhq/twenty/pull/25512) 3. [Manifest authoring](https://github.com/twentyhq/twenty/pull/25513) 4. [Existing Canvas data migration](https://github.com/twentyhq/twenty/pull/25511) <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/25513?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. --> |
||
|
Raphaël Bosi
|
196d676bbc |
Align twenty-ui with SDK package versions (#25758)
`twenty-ui` uses an independent `1.0.0-alpha.2` version while the SDK packages use `2.40.0`. Align UI with the SDK packages and add the shared `set-local-version` target. New apps pin `twenty-ui`, `twenty-sdk`, and `twenty-client-sdk` to the scaffolder's version. The local-registry E2E workflow publishes UI alongside the SDK packages and checks all three dependency versions. Source docs and Codex plugin references describe the same policy, with a validator regression test that catches independent UI version guidance. This replaces the separate-alpha version pins from #25738 while preserving its explicit inclusion of the MIT `LICENSE` in the npm package. Plugin checklist rows touched: R3 (front component guidance) and R5 (app concepts reference). Companion: https://github.com/twentyhq/twenty-infra/pull/934 adds UI to SDK publishing, automatic version bumps, and release notes. Land both changes before the next version bump or SDK publication. Validation: 11 scaffolding tests and 35 plugin tests passed; plugin validation and direct typechecks for `twenty-ui` and `create-twenty-app` passed. An npm pack dry run confirmed the MIT `LICENSE` is included. The full registry/server E2E workflow was not run locally. |
||
|
Dhananjay Maurya
|
5e7cbb4a46 |
fix: republish twenty-ui as MIT (1.0.0-alpha.2) to resolve stale AGPL artifacts (#25738)
Fixes #25722. ## Problem #23564 (merged 2026-07-30) relicensed the app-development packages to MIT, but npm still serves builds that predate the relicensing: - twenty-ui@1.0.0-alpha.0 (latest) and 1.0.0-alpha.1 (alpha tag, both published 2026-06-24): AGPL-3.0 on the registry, old root LICENSE in the tarball. - twenty-shared@0.41.0-canary (published 2025-01-24): AGPL-3.0. Meanwhile twenty-sdk, twenty-client-sdk, and create-twenty-app (all published after 2026-07-30) are correctly MIT. The repo itself is already correct (license: MIT plus per-package MIT LICENSE). In practice, create-twenty-app scaffolds apps pinning "twenty-ui": "1.0.0-alpha.1" and the generated front component imports from twenty-ui/data-display and twenty-ui/icon — the exact scenario #23564 was written to prevent. ## What this PR does - Bumps packages/twenty-ui/package.json 1.0.0-alpha.1 to 1.0.0-alpha.2 so the next publish ships the post-#23564 package.json (license: MIT) and MIT LICENSE. - Adds LICENSE explicitly to twenty-ui files so the MIT text is always in the tarball (verified: npm pack --dry-run lists package/LICENSE, 1.1 kB MIT, license=MIT). - Points the create-twenty-app scaffold template at 1.0.0-alpha.2. - Syncs English docs (front-components.mdx, project-structure.mdx), codex-plugin references, and the cross-doc-contracts.js validator. ## Why twenty-shared is intentionally untouched packages/twenty-shared/package.json is private:true with no version — it is only consumed via workspace:* (bundled at build time; twenty-sdk and twenty-client-sdk list it under devDependencies, never via the registry) and the scaffold template does not depend on it. There is nothing to republish; republishing would mean making an internal package public again. Instead, a maintainer should run npm deprecate on twenty-shared@0.41.0-canary pointing at this issue. The in-repo state (license: MIT plus MIT LICENSE) is already correct. ## Maintainer follow-up needed (cannot be done in a PR) 1. Publish 1.0.0-alpha.2 from packages/twenty-ui, then promote it to latest (currently latest still points at the stale 1.0.0-alpha.0; alpha points at 1.0.0-alpha.1). 2. npm deprecate the stale artifacts: twenty-ui@1.0.0-alpha.0, twenty-ui@1.0.0-alpha.1, and twenty-shared@0.41.0-canary. 3. Confirm npm view twenty-ui@1.0.0-alpha.2 license returns MIT and package/LICENSE in the tarball is the MIT text. ## Verification done - npm view confirms both published twenty-ui versions are AGPL-3.0 and predate #23564; repo is MIT. - npm pack --dry-run on the bumped package includes package/LICENSE (MIT) with license=MIT. - No test pins the old version (only the template literal, docs, and validator — all updated); twenty-apps examples use caret ranges that resolve forward to alpha.2 automatically, and root yarn.lock uses workspace:*, so no lockfile churn is needed. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/25738?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. --> |
||
|
Corentin Deniaud
|
942d1ceb44 |
Remove legacy grid position from page layout widgets (#24876)
## Context `gridPosition` predates the layout-mode-aware `position` field. New page layout widget writes already have enough information to use `position`, but removing the legacy column and read field in one release is unsafe because existing widgets still have a null `position`. This change moves write paths to `position` while keeping a temporary read fallback until those rows are backfilled. ## What changed - Update page layout creation, duplication, validation, rendering, fixtures, seeds, app examples, and documentation to use the discriminated `position` model. - Remove `gridPosition` from GraphQL mutation inputs, OpenAPI write schemas, application manifests, and SDK authoring types. - Keep `gridPosition` as a deprecated response field during the migration window. - Read `position` first and fall back to `gridPosition` only when the canonical grid position is absent. - Add a slow upgrade command focused on backfilling missing `position` values. ## Rollout and safety The schema change and data migration are intentionally separate: 1. The application can write only `position` while still reading rows that contain only `gridPosition`. 2. The slow command backfills only rows where `position IS NULL`, preserving every existing canonical position. 3. The backfill derives the new shape from the tab layout mode: grid coordinates for `GRID`, deterministic indices after existing widgets for `VERTICAL_LIST`, and the canvas discriminator for `CANVAS`. The legacy response field and database column are not removed in this release. They can be removed in a later release after the slow migration has completed across deployed workspaces. ## Breaking change **Write consumers must migrate from `gridPosition` to `position`:** **- GraphQL mutations can no longer send `gridPosition`.** **- App manifests using `gridPosition` must be rebuilt and republished with `position`. Older manifests will have that field ignored and receive a layout-mode-specific default position.** Read consumers remain compatible during this rollout. `gridPosition` is still queryable as a deprecated nullable field, and canonical `position` always takes precedence when both values exist. ## Expected impact - Existing widgets continue rendering before the slow migration runs. - New and updated widgets no longer depend on the legacy column. - After the slow migration, widgets use the layout-mode-aware canonical representation and the legacy read fallback should no longer be exercised. |
||
|
Félix Malfait
|
8896d8e565 |
docs(codex-plugin): use apply and plan commands (#24512)
## Summary - replace deprecated `twenty dev --once` examples with the bounded `twenty apply` command - document `twenty plan` as the read-only preview path - update the cross-document contract validator - add a failing fixture for reintroducing the deprecated guidance ## Validation - `npx nx run twenty-codex-plugin:validate --skip-nx-cache` - `npx nx run twenty-codex-plugin:test --skip-nx-cache` — 32 passed Audit source: https://github.com/twentyhq/core-team-issues/issues/2784 <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/24512?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. --> |
||
|
Abdullah.
|
15f571837e |
fix: bump js-yaml pins 4.2.0 -> 4.3.0 (Dependabot) (#23178)
## Summary Bumps all nine scoped **js-yaml resolutions 4.2.0 -> 4.3.0** and lifts the caret copy, clearing Dependabot alert [1768](https://github.com/twentyhq/twenty/security/dependabot/1768): **GHSA-52cp-r559-cp3m / CVE-2026-59869** (high) - YAML merge-key chains force quadratic CPU consumption, vulnerable `>= 4.0.0, < 4.3.0`, fixed **4.3.0**. Follow-up to the merge-key DoS fixed in 4.2.0 (GHSA-h67p-54hq-rp68). ## Why the pins move (not drop) Checked upstream first: all seven 4.1.1 exact-pinners are unchanged at latest (`@mintlify/cli@4.0.1331`, `@mintlify/common@1.0.1037`, `@mintlify/prebuild@1.0.1185`, `@mintlify/previewing@4.0.1254`, `@mintlify/scraping@4.0.902`, `@mintlify/validation@0.1.795`, `@verdaccio/config@8.1.2` - every one still pins `js-yaml 4.1.1` exact). front-matter and @istanbuljs/load-nyc-config remain EOL on `^3.13.1`. So no parent upgrade carries 4.3.0; the existing scoped pins just move up, plus a recursive `yarn up` for the cosmiconfig caret consumers. The `//resolutions` doc entry is updated with the new advisory and drop condition (`>=4.3.0`). ## Verification - Single `js-yaml 4.3.0` entry remains in the lockfile (no 4.2.0, no 3.x). - `yarn install --immutable` passes. - front-matter patch intact (`loader = parser.load`); docs front-matter parses cleanly on 4.3.0. - `mintlify validate` reports only pre-existing ChartIcon MDX import warnings from #23091 (content, unrelated - zero `.mdx` files in this diff). - 4.3.0 published 2026-06-26, clears the 3-day age gate. |
||
|
Raphaël Bosi
|
0dc6272da5 |
Remove twenty-ui reexport from the SDK and use twenty-ui directly (#22326)
## What & why Removes the `twenty-sdk/ui` reexport. Apps now use Twenty UI by installing [`twenty-ui@1.0.0-alpha.1`](https://www.npmjs.com/package/twenty-ui/v/1.0.0-alpha.1) from npm and importing its subpaths directly. The reexport re-exported types that didn't resolve, forcing typecheck workarounds. ## Changes - **twenty-sdk**: delete `src/ui/index.ts`, drop the `./ui` export, remove it from the browser vite build, and rewire the CLI manifest-mock to `twenty-ui` (`.css` falls through to the empty-CSS loader). `twenty-ui` stays a devDependency for the CLI fixture tests. - **Renderer + create-twenty-app template**: import from `twenty-ui` subpaths; the template pins `twenty-ui@1.0.0-alpha.1`. - **Docs**: new "Using Twenty UI components" section (install + subpath imports + `useTheme()` for theme tokens), codex references, and the cross-doc-contract validator. The `twenty-for-twenty` / `twenty-slack` example apps are intentionally left on `twenty-sdk/ui`: they consume the published SDK (which still ships `./ui`), and `twenty-ui@1.0.0-alpha.1` requires react 19 + a `monaco-editor` peer the react-18 apps can't satisfy. They migrate once the SDK is republished. |
||
|
|
1642be86f5 |
Bonapara/twenty codex plugin (#20857)
@martmull v2.0 ;) --------- Co-authored-by: martmull <martmull@hotmail.fr> Co-authored-by: bosiraphael <raphael.bosi@gmail.com> |
