chore(codex): lock Sim project integration routing

Author: andresdjasso

AGENTS.md

@@ -2,6 +2,26 @@
 
 You are a professional software engineer. All code must follow best practices: accurate, readable, clean, and efficient.
 
+## Codex Project Routing
+
+This repository is the Sim project. External workspace access and code changes must stay isolated from unrelated projects.
+
+### Linear and Slack identity checks
+
+- At the start of every new Codex task that needs Linear or Slack, verify the external workspace before reading task content or making changes.
+- For Slack, use the dedicated Sim design connector and call its connection-info tool first. Continue only when it reports workspace `T08CM6ZNYBE` (`sim`) and the allowed channels `#design-todo` (`C08M0HGB125`) and `#design-general` (`C0B6XLJFTM2`). Treat `#design-todo` as primary task intake and `#design-general` as a secondary signal source.
+- For Linear, perform only the minimum read-only identity lookup needed to confirm that the connected workspace/team belongs to Sim. If the connection exposes Tenor, Otherplace, or any workspace that is not clearly Sim, stop all Linear access immediately. Never list, read, create, update, comment on, label, or attach anything in Tenor from this repository.
+- If the Sim Linear connection is unavailable, state that the project connector must be switched or authenticated. Do not use Tenor as a fallback and do not present Slack-derived status as verified Linear status.
+- Before creating or updating a Sim design issue, compare `#design-todo` and actionable `#design-general` signals with existing Sim Design issues by intended outcome and product surface. Consolidate duplicates and preserve all source permalinks.
+- Organize design work in the Sim `Platform`, `Landing`, or `Brand` project. Use `UI Design` or `Brand` for work type and `Code PR`, `Figma`, or `Asset` for delivery when those fields are available.
+
+### Isolated implementation work
+
+- Do not implement a new task in a dirty, detached, shared, or unrelated worktree.
+- Before code changes, inspect `git status` and `git worktree list`. If the task is not already in its own clean worktree, fetch `origin/staging`, create a task-specific branch from `origin/staging`, and add a dedicated worktree under `.worktrees/<issue-id>-<slug>`.
+- Prefer branch names such as `fix/<issue-id>-<slug>`, `improvement/<issue-id>-<slug>`, or `feat/<issue-id>-<slug>` according to the task.
+- Run every agent for that task only inside its dedicated worktree. Never reset, stash, delete, or absorb changes from another worktree to make room.
+
 ## Global Standards
 
 - **Linting / Audit**: `bun run check:api-validation` must pass on PRs. Do not introduce route-local boundary Zod schemas, direct route Zod imports, or ad-hoc client wire types — see "API Contracts" and "API Route Pattern" below