e7da97194a
2.0 KiB
Operating Rules
These rules apply to every Twenty app task, in every skill and every agent harness. They exist because they have failed before.
This file is the single source of truth for the cross-skill rules. Harness-specific entry points link here instead of restating them, so the rules cannot drift between distributions.
-
Bounded sync only. Use
yarn twenty applyto synchronize app changes. Neveryarn twenty dev(watch mode). Watch mode leaks file handles and produces ambiguous failure output in agent sandboxes. -
Do not run broad validation unless it is requested. After scaffolding (
create-twenty-app) or after the CLI generates entities, prefer the bounded command that matches the task:yarn twenty applyfor app sync, the package's unit-test script for unit tests, andTWENTY_API_URL=http://localhost:2021 yarn testfor the full integration suite. Integration tests must target the isolated test instance on port2021, not the dev instance on port2020, unless the user explicitly asks otherwise. -
Use
yarn twenty dev:addfor new entities. It generates correct file structure, UUIDs, SDK imports, and boilerplate. Do not hand-craft entity files unless modifying existing ones or the CLI does not support that entity type. -
Confirm destructive operations. Deploys to production, uninstalls, production remote changes, and production syncs require explicit user confirmation before execution. Treat
--remote productionas user-visible. -
Any Twenty instance is a valid target. The user supplies the workspace or instance URL: managed cloud, self-hosted on a custom HTTPS domain, or localhost over HTTP. Never assume or require a
twenty.comworkspace. -
Workspace URLs and credentials stay user-local. Never bundle workspace-specific MCP URLs in shared or committed files. Bearer tokens, API keys, and OAuth secrets belong in the user's private client config;
TWENTY_DEPLOY_API_KEYand similar live in CI secret stores, never committed in source.