{"owner":"kortix-ai","repo":"suna","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md"],"files":{"AGENTS.md":"# Kortix project\n\n## Linear tracking\n\nCapability-page work uses Team `Jay`, project `customize`, and the milestone that\nmatches the active phase. Search before creating issues. Move the active issue to\n`In Progress` before editing. Mark it `Done` only after the change is merged,\ndeployed to dev, and verified there.\n\n## What \"ownership\" means\n\nThe words \"can you own this?\", \"are you on it?\", and \"can you take care of this?\"\nall mean the same thing: you are 100% responsible. The person who handed it to\nyou must be able to walk completely away, come back a week later, and find it\ndone properly — because you cared about every edge and corner.\n\n- it's not done if it's not implemented\n- it's not done if the implementation is ugly\n- it's not done if it's not documented\n- it's not done if users can't discover it\n- it's not done if you can't market it\n\nOwning something means owning it end to end. The whole arc from \"we have a\nproblem\" to \"nobody has to think about this again.\" Not just the code change in\nthe middle, the whole thing. If someone hands you something and still has to\ntrack whether it actually got solved, you didn't own it.\n\nHere's what that actually looks like in practice.\n\n**Start with the problem, not the solution.** A lot of the time you'll already\nhave a fix in your head before you've understood what's broken. \"We need to move\nfrom X to Y\" isn't a problem, that's a solution you've pre-committed to. The real\nproblem is probably \"it's slow\", \"it's flaky\", \"it breaks for this customer\".\nName that first. Then ask what else could solve it, what the tradeoffs are, and\nwhich option actually wins.\n\n**Then pressure-test it before you build:**\n\n- **Edge cases.** Which exist, which matter, which we can safely ignore.\n- **Failures.** Networks fail, that's a given. Retry? How many times, for how\n  long?\n- **Data.** How much, does it need migrating or cleaning, how do you get real\n  data to test against, and what are you assuming about its shape that you\n  haven't actually verified?\n- **Testing.** How will you know it's correct? Are automated tests enough or do\n  you need to poke at it by hand? Is the result something you can see in a\n  screenshot or a video?\n- **The bigger picture.** How does this get announced, how does it fit the\n  roadmap, can you even picture it shipped? If something there bothers you, push\n  back. Ask.\n\n**Then actually do it**, with precision, care, urgency and calm all at once. No\nhalf-assing. The bar before you merge: am I proud of this? Would I put it in\nfront of Steve Jobs and walk him through what I built, the constraints, the\ntradeoffs?\n\n**And then prove it works.** Not \"the tests pass\", prove it. In 99% of cases you\ncan confirm it yourself: run it, ask an agent to walk through the scenarios, poke\nat the data before and after, take a screenshot, make a demo. Are you actually\nsure it solves the problem you started with?\n\n**Then make sure it lands in production and works in production**, which is not\nthe same as merged. Did it deploy? Did the deploy quietly fail? Is there a flag\nto flip, and does the flag work? Can you use the thing in prod right now and\nconfirm it's really there?\n\n**And then close the loop with everyone it touches:**\n\n- **The team.** If it's a new feature, a new convention, or a tricky thing people\n  should know about, tell them. Don't underestimate peripheral vision. You\n  knowing that someone changed Z yesterday can save someone else three hours of\n  debugging tomorrow when a bug report about Z comes in.\n- **Customers.** Whoever reported it, whoever's blocked, let them know it's\n  fixed.\n- **The world.** If it's worth announcing, announce it.\n- **Future you.** Are there follow-ups? Should you check the logs in a week to\n  make sure it's still healthy?\n\nBut that's how we build a product in a small team. We don't have PMs, we don't\nhave a QA department. We're small, but we're great, and we can do all of that.\n\nAnd it's always okay to ask for help, it's okay to ask questions, it's okay to\nredo things and triple-check. What's not okay is to quietly assume someone else\nwill catch the parts you didn't think about.\n\n### The bar: autonomy, agency, ownership\n\nThis is what I require from the agent I work with. In my own words:\n\nEither you are performing or you are not. Either you are taking on high\nownership, are high agency and pushing without me having to micromanage you, or\nyou are not.\n\nEspecially in today's age you are limited by great talent more than ever. Because\nwe can all AGI Max, you have a single chokepoint on good judgement.\n\nEvery person that comes on the team has to have the capability to truly own\nsomething. If you have built products, you develop ownership because you owned\nsomething — whether it worked out or not — for a prolonged amount of time. You\ndevelop true agency.\n\nI hire you because I expect that if I am able to walk out of the room after\ngiving you a high level thing and come back, it's going to be done good, ideally\nbetter than I would've done it.\n\nMost people are shit at their jobs, some are decent/good, but only people who are\nexceptional should be at Kortix.\n\nBeing exceptional on paper is simple — it's a combination of Ownership, Agency\nand actual Merit/Skill. It's hard, because you have to not only be very smart but\nalso crazy driven to push like a motherfucker and want to feel every edge and\ncorner to make sure the output is good.\n\n## Learnings: incident rules live in the `learnings` skill\n\n`.claude/skills/learnings/SKILL.md` is the append-only register of rules paid\nfor with real downtime — each with the incident that taught it and the\nautomation that enforces it. Load it before writing or reviewing a DB\nmigration, touching deploy/release workflows, planning a promote, or responding\nto a prod incident. After resolving ANY incident or near-miss, append its rule\nthere in the same session — an incident that leaves no learning behind is not\nfinished.\n\n## How to communicate: precise, technically accurate, no fluff\n\nWrite every response — chat, PR text, commit messages, code comments, docs — in\nthe spirit of **ASD-STE100 (Simplified Technical English)**. The goal is maximum\ntechnical precision with zero filler. Apply these rules:\n\n- **State facts, not vibes.** Every claim is specific and verifiable: name the\n  file, function, route, flag, SHA, status code, or number. No \"should work\",\n  \"probably\", \"a bunch of\", \"various\", \"seems fine\" — say what is true and how you\n  know, or say you do not know it yet.\n- **One idea per sentence.** Keep sentences short (aim ≤ 20 words) and each one\n  carries a single instruction or fact. Split compound thoughts instead of\n  chaining clauses.\n- **Active voice, present tense, direct.** \"The gate rejects the request\",\n  not \"the request may end up being rejected\". Give the instruction; do not\n  soften it.\n- **One term per concept.** Use the same word for the same thing every time —\n  do not alternate \"session\"/\"run\"/\"task\" for one concept. Match the codebase's\n  existing names exactly (`session_id`, not \"session ID / run id\").\n- **No filler, no hedging, no praise.** Cut \"basically\", \"just\", \"simply\",\n  \"I think\", \"great question\", \"as we know\", and marketing adjectives. Lead with\n  the answer; drop the throat-clearing.\n- **Quantify.** Prefer exact values over adjectives: \"up to ~9 min\", \"returns\n  `402`\", \"3 of 7 flows\", not \"slow\", \"an error\", \"most\".\n- **Show the evidence.** When you assert a behavior, cite the command you ran and\n  the real output. Distinguish verified fact from assumption explicitly.\n- **Structure over prose.** Use numbered/bulleted lists for steps, findings, and\n  status. Reserve paragraphs for genuine explanation, and keep them tight.\n- **Say the unknown plainly.** If something is unverified, blocked, or risky,\n  state it in one line — what, why, and what would resolve it — instead of\n  burying or omitting it.\n\nThis standard governs how you talk. It does not override the technical rules\nbelow; it is how you report on them.\n\n## First, at session start: where do you work?\n\nBefore starting any non-trivial change, **ask the user which environment to work\nin** — don't assume. Three choices:\n\n1. **A new isolated worktree** (`pnpm worktree`) — the default for any feature,\n   bugfix, refactor, or experiment beyond a one-line edit. Own branch, own port\n   block, own `node_modules`, own tunnel; runs in parallel without touching the\n   primary web/API stack. By default it reuses the primary checkout's standard\n   local Supabase DB for fast setup and consistent auth. Provision non-blocking with\n   `pnpm worktree create --name <feat> --yes --no-start`, then do all edits/runs\n   under the sibling checkout `../suna-<feat>`. If the change needs database\n   migrations, destructive data work, schema drift, or independent auth/storage\n   state, opt into the full isolated data plane with\n   `pnpm worktree create --name <feat> --db --yes --no-start`. See the\n   **worktree** skill.\n2. **Straight in this primary checkout** via `pnpm dev` (web `3000` / api `8008`)\n   — on `main` or whatever branch is already checked out here. Simplest; fine\n   for small or quick iterative work where isolation isn't needed.\n3. **An existing worktree** — list them with `git worktree list` and work in the\n   one the user names.\n\nCarve-outs where you don't need to ask — just proceed: read-only\ninvestigation/questions, and trivial single-file typo/comment fixes on the\ncurrent branch.\n\n## Default delivery: PR, merge to main, then prove it on dev\n\nUnless the user explicitly asks for a different delivery path, complete every\nnon-trivial change through this full lifecycle:\n\n1. Work on a dedicated branch in an isolated worktree and keep the commit scoped\n   to that change.\n2. Run the relevant local unit, type, integration, and end-to-end checks with\n   real inputs and outputs.\n3. Push the branch, open a PR against `main`, wait for required checks, and merge\n   it. Do not leave finished work only on a branch or stop after opening the PR.\n4. Follow the resulting **Deploy Dev** workflow through completion. Confirm the\n   deployed artifact contains the merged SHA; a successful `/health` response\n   alone is not deployment proof. If a newer push cancels or supersedes the run,\n   verify its path filters still rebuild every affected artifact. Manually\n   dispatch the workflow when necessary to avoid a skipped component.\n5. Re-run the user-visible behavior against `https://dev.kortix.com` and/or\n   `https://dev-api.kortix.com`. Prefer the real Kortix CLI configured for the\n   dev API for CLI/project/session flows, and direct authenticated HTTP calls for\n   API contracts. For web behavior, drive the deployed UI and assert its network\n   request plus visible result.\n\nLocal verification and dev verification are both required. A local pass does\nnot replace the deployed check, and a dev smoke test does not replace focused\nlocal tests. Record the PR, merge SHA, deploy run, deployed SHA evidence, and\nexact dev command or interaction in the final response.\n\n## Architecture: `@kortix/sdk` is the source of truth\n\n`@kortix/sdk` is the **single source of truth** for everything that talks to the\nKortix backend — projects, accounts, sessions, files, secrets, triggers, the\nsession runtime, OpenCode REST compatibility, SSE streaming, model state,\nand auth-token plumbing. The apps\n(`apps/web`, `apps/whitelabel-demo`, `apps/mobile`) are **thin consumers**. Treat\nthese as standing rules whenever you touch the data/runtime layer:\n\n> **Editing `packages/sdk` itself? Read `packages/sdk/PROGRESS.md` (current state,\n> claim your task) and `packages/sdk/AGENTS.md` (the rules) first.** It is a\n> **published npm package** with its own hard rules that have no analogue\n> elsewhere in this repo: **TDD is mandatory** (failing test first — invoke the\n> `tdd` skill — and every turn ends with the gates run, the real output pasted,\n> and an explicit shippable YES/NO/NOT YET); exported names (including *types*)\n> are a public API contract and renaming one is a breaking change; the `version`\n> field is inert and must never be bumped by hand; adding an export requires\n> three synchronized edits; and the framework-free core is enforced by a static\n> import-graph tripwire.\n\n- **Logic lives in the SDK, never in a host.** No raw `fetch` to the Kortix API,\n  no `@opencode-ai/sdk` imports, no transport / runtime / data-state code written\n  in app code. New data or runtime behavior is added to the SDK and exposed\n  through its public surface — not hand-rolled or duplicated in a host. If you\n  need something the SDK doesn't expose, add it to the SDK.\n- **One client per host.** Create it once via `createKortix({ backendUrl,\n  getToken })` and read everything through `@kortix/sdk` + `@kortix/sdk/react`.\n  Auth is just `getToken` — an API key / PAT for programmatic use, or a Supabase\n  JWT for the logged-in web app. Hosts never instantiate a second client.\n- **A whole session is one hook.** `useSession(projectId, sessionId)` owns the\n  entire runtime lifecycle — `/start`, the sandbox switch, the live SSE stream,\n  readiness seeding, immutable runtime identity, the native conversation id,\n  and message sync. Hosts don't\n  hand-roll the mount, drive a server-store \"switch\", or mount a separate event\n  provider.\n- **Session-scoped + provider-agnostic.** The public API is session-scoped\n  (`kortix.session(pid, sid).health() / .previewUrl() / .restart() / …`).\n  The sandbox provider is a server-side concern. Every session uses the\n  OpenCode REST runtime. Host code must not implement a second transport.\n- **`apps/web` data modules are shims.** Files such as\n  `apps/web/src/stores/server-store`, `lib/projects-client`, and\n  `hooks/opencode/use-*` are thin re-exports (`export * from '@kortix/sdk/...'`).\n  Keep them as shims; put the real logic in the SDK. When a merge conflict lands\n  on one of these, **keep the shim (`--ours`) and port any new host-side logic\n  into the SDK** — do not revert to a host-local implementation.\n- **Docs are the spec.** `apps/web/content/docs/sdk/*` and\n  `packages/sdk/README.md` describe the intended surface. Keep them current with\n  the SDK, and flag legacy/deprecated surfaces in-doc rather than documenting them\n  as current.\n\n## You CAN run and verify everything end-to-end. Do it.\n\nThis repo ships a **complete, runnable local stack with live cloud sandboxes**.\nDo not claim you \"can't verify from here\" or hand back unverified work — you\nhave everything needed to run the app, hit the real API, provision real\nDaytona sandboxes, drive the real UI in a browser, and assert behavior. Use it.\n\n### Required verification standard — real inputs, real outputs\n\nFor every behavior change, assume **100% autonomy** to verify the user-visible\ncontract before handing the work back. Do not stop at typechecks, unit tests, or\nmocked internals when a real surface exists.\n\n- **API changes:** exercise the actual HTTP route with real request payloads\n  (`curl`, `bun fetch`, or the `ke2e` runner against a running API). Assert the\n  status code and exact response fields that prove the behavior. For writes,\n  also assert the persisted/read-back state or resulting repo/file output.\n- **CLI changes:** run the real CLI command as a process from bash, with the\n  same flags and stdin a user or agent would use. Assert exit code, stdout,\n  stderr, and any files/API calls/commits it should create. Do not rely only on\n  importing command functions.\n- **Web changes:** drive the real page in Chromium/Playwright/chrome-devtools.\n  Click/type/toggle the actual controls, intercept or observe the network\n  request, and assert the visible UI state plus the outgoing payload. Screenshots\n  are useful evidence, but assertions on DOM and network data are required.\n- **Cross-surface features:** verify each exposed surface independently. If the\n  same feature ships on API + CLI + web + mobile, each gets its own black-box\n  assertion for the inputs users can make and the outputs they receive.\n- **Default/negative paths count:** when changing defaults or removing implicit\n  behavior, assert both the new default and the explicit opt-in/alternate path.\n- **No silent gaps:** if a surface cannot be fully exercised in the current\n  turn, say exactly which input/output remains unverified and why. Otherwise\n  keep going until the real surface is verified.\n- **Final response format:** when work is finished, answer per the **How to\n  communicate** standard at the top of this file — numbered/bulleted, no fluff.\n  Include exactly what changed, what was verified (with the command + output),\n  what remains unverified or risky, and what the user should test next. Do not\n  bury the actionable testing path in a paragraph.\n\n### The stack (already wired)\n\n- **Web** — Next.js dev server on `http://localhost:3000`.\n- **API** — Bun server on `http://localhost:8008/v1` (`/health` returns JSON).\n- **Supabase** — local, on `http://127.0.0.1:54321` (Docker).\n- **Sandboxes** — REAL cloud sandboxes on the enabled provider (Daytona,\n  Platinum, or E2B; credentials in `apps/api/.env` / `.env.local`). Each project\n  session gets its own sandbox; `session_id == sandbox_id`. The sandbox daemon is\n  reached through `http://localhost:8008/v1/p/<external_id>/8000/...`.\n  OpenCode REST uses the compatibility proxy.\n- **Tunnel** — `scripts/dev-local.sh` (`pnpm dev`) auto-starts a cloudflared\n  quick tunnel so cloud sandboxes can call back to the local API (`KORTIX_URL`).\n\nBring it up with `pnpm dev` from `suna/` (it loads `apps/api/.env` +\n`apps/web/.env`, starts Supabase, the API, the web app, and the tunnel). Check\nwhat's already running before starting a duplicate: `curl -s\nlocalhost:8008/v1/health`, `lsof -iTCP:3000 -sTCP:LISTEN`.\n\n> **Secrets are dotenvx-encrypted (mandatory).** `apps/api/.env` (+ `.env.dev`)\n> are committed as ciphertext (`KEY=encrypted:…`); keys live in Dotenv Armor.\n> **Never write a plaintext secret into a tracked file or commit** — add/change\n> values only via `dotenvx set KEY value -f apps/api/.env` (then commit), read\n> with `dotenvx get`, and machine-local overrides go in the gitignored\n> `apps/api/.env.local`. If the user pastes a key, store it with `dotenvx set`,\n> never paste it raw. A pre-commit hook + GitHub push protection enforce this —\n> don't bypass them. Full procedure: the **dotenvx-secrets** skill.\n\n### Authenticating to the live API (for scripts/tests)\n\nMint a real JWT against local Supabase, then call the API with it:\n\n1. `SUPABASE_SERVICE_ROLE_KEY` lives in `apps/api/.env`; the anon key\n   (`NEXT_PUBLIC_SUPABASE_ANON_KEY`) in `apps/web/.env`.\n2. Create a confirmed user: `POST 127.0.0.1:54321/auth/v1/admin/users`\n   (`apikey` + `Authorization: Bearer <service_role>`, body\n   `{email,password,email_confirm:true}`).\n3. Password-grant for the token: `POST\n   127.0.0.1:54321/auth/v1/token?grant_type=password` (`apikey: <anon>`).\n4. Call the API: `Authorization: Bearer <access_token>` against\n   `localhost:8008/v1` (e.g. `/accounts`, `/projects/provision`,\n   `/projects/:id/sessions`, `/p/<ext>/8000/...`).\n\nSee `tests/e2e/helpers/auth.ts` for the exact calls.\n\n### One local testing system\n\n- `pnpm test` is the only repository-level test command. It runs local REST and\n  CLI flows, SDK tests, runner unit tests, route coverage, and worktree tests\n  concurrently.\n- `pnpm test -- --id ACC-4` runs one flow. `--domain access` runs one domain.\n- `pnpm test -- --sdk-only` runs only `packages/sdk` tests.\n- `pnpm test -- --browser-only` runs Playwright browser journeys. It starts the\n  deterministic local stack.\n- Local browser runs use two Playwright workers. CI browser shards use one.\n- `pnpm test -- --packages-only` runs every app/package test and publish check.\n- `pnpm test -- --full` adds browser journeys and every app/package test. It\n  starts the deterministic local stack.\n- `pnpm test -- --target-smoke` verifies the deployed staging API and gateway\n  SHA, then runs the tagged Playwright staging smoke. Release CI supplies the\n  staging credentials and `RELEASE_SOURCE_SHA`.\n- `pnpm test -- --target-full` verifies the same deployed SHA, then runs every\n  configured staging REST, CLI, and Playwright journey. The production release\n  gate uses this command and fails on any excluded API flow.\n- Browser and full modes reuse only a running API that proves the deterministic\n  test profile. Stop an ordinary development stack before either command.\n- Every root run writes lane and total timings to\n  `tests/test-results/local/benchmark-<timestamp>.json`.\n- GitHub Actions runs core, browser, and package modes in three disposable warm\n  sandboxes through `.github/workflows/tests.yml`. The slowest lane defines the\n  gate duration. Set `provider` to `platinum`, `daytona`, or `auto`. Auto tries\n  Platinum first. It uses Daytona only when Platinum infrastructure throws. A\n  non-zero test exit does not trigger fallback.\n- Platinum warm restore readiness is capped at 2 minutes. A missing marker or\n  unreachable guest after that cap triggers Daytona in `auto` mode. Cold\n  template creation retains its separate 45-minute budget.\n- Both providers fetch and verify the exact SHA, upload `tests/test-results`,\n  and delete the sandbox. The sandbox worker is infrastructure only. Do not add\n  CI-only test logic.\n- Release tests run `pnpm test -- --target-full` against deployed staging. They block\n  production when API or gateway health reports a SHA other than\n  `RELEASE_SOURCE_SHA`, when any API flow is excluded, or when a configured\n  Playwright journey fails.\n- The `preview` label creates one full self-host preview in a persistent warm\n  Platinum sandbox. `auto` uses Daytona only for a Platinum infrastructure\n  failure. The preview has its own PostgreSQL, Supabase, API, gateway, frontend,\n  Mailpit, and HTTPS origin.\n- Preview CI runs `pnpm test -- --target-full` against that origin. The sticky\n  pull request comment links the origin and its `/_tests/` HTML report.\n- A preview head change deletes the sandbox and removes the stale `preview`\n  label. Unlabel, close, and scheduled reconciliation also delete the sandbox.\n- Preview warm images contain dependencies and Docker layers only. They never\n  contain a database or runtime secret.\n- Preview Mailpit handles authentication and invite email. The dedicated\n  preview GitHub App runs the managed repository and CLI push flows. OAuth\n  initiation is the only allowed preview browser exclusion.\n\n### Product flow source of truth\n\n- `tests/spec/end-to-end.md` contains the natural-language contract and stable\n  flow IDs.\n- `tests/src/flows/*.flow.ts` implements the contracts through HTTP and real CLI\n  processes. Do not import API handlers.\n- Write each `ctx.step()` as a complete action and observable result. Cover\n  setup, authentication, action, read-back proof, negative paths, and cleanup.\n- Keep every flow's `meta.routes` synchronized with\n  `tests/spec/routes.generated.json`. Regenerate the manifest with\n  `bun run apps/api/scripts/dump-routes.ts` after route changes.\n- The local profile uses local Supabase, PostgreSQL, API, gateway, and bare Git\n  repositories. It excludes Stripe, cloud sandboxes, managed GitHub repositories,\n  and external email delivery explicitly.\n- Use Playwright only for browser-visible behavior. API-only assertions belong\n  in REST flows. SDK tests remain in `packages/sdk`.\n- Do not add another cross-cutting test harness, Makefile lane, contract suite,\n  Testcontainers suite, load suite, mutation suite, visual suite, accessibility\n  suite, or ad hoc smoke script under `tests/`.\n- Read `tests/README.md` and the repository `testing` skill before changing the\n  test system.\n\n### Release topology — dev, staging, prod\n\n- **`main` = dev trunk.** It is the repo default branch and deploys to\n  `dev.kortix.com` / `dev-api.kortix.com`. Direct pushes are allowed; breaking or\n  incomplete development can live here while it is being shaken out.\n- **`staging` = release-candidate branch.** Nothing should land on staging unless\n  it is intended to be production-ready. Human/code changes enter staging by PR:\n  `main` -> `staging` for the full dev candidate, or a targeted branch ->\n  `staging` for a selective release candidate. Staging deploys to\n  `staging.kortix.com` / `staging-api.kortix.com` and must use the staging data\n  plane, not dev or prod.\n- Staging deploys must apply pending DB migrations against `STAGING_DATABASE_URL`\n  before the staging EKS rollout. If that secret is missing or points at dev/prod,\n  treat the deploy as broken; staging must never fall back to dev, KE2E, or prod DBs.\n- **`prod` = production.** Production moves only through **Promote to Production**,\n  which uses `staging` as the source, opens a reviewed release PR into `prod`,\n  publishes the release artifacts, and rolls production after merge.\n- If a staging runtime check points at `dev.kortix.com` or\n  `dev-api.kortix.com`, treat that as a broken staging setup, not a passing\n  staging gate.\n\n### Driving the real UI (chrome-devtools MCP)\n\n- Routes are auth-gated (`/dashboard`, `/projects/*` → redirect to `/auth`\n  unauthenticated); sign in first (seed a user as above, then log in via the\n  `/auth` form, or inject the Supabase session).\n- The MCP uses a dedicated Chrome profile at\n  `~/.cache/chrome-devtools-mcp/chrome-profile` (separate from your normal\n  browser). If launch fails with \"browser is already running for … profile\",\n  kill the orphaned Chrome using that profile and remove\n  `chrome-profile/Singleton{Lock,Cookie,Socket}`, then retry.\n- Next.js dev compiles routes on first hit — first navigation to a cold route\n  can take 30–60s; warm it with `curl` or use a generous navigation timeout.\n\n### Frontend type/lint gate\n\n- `apps/web` `tsc --noEmit` is clean apart from ~15 known `@types/bun`\n  `test.each` errors in 3 test files (`app/(system)/api/og/template/template-url.test.ts`,\n  `features/file-viewer/preview-fit.test.tsx`,\n  `features/session/action-panel/easy/easy-panel-logic.test.ts`).\n  The old ~1500 `TS2786` / `IntrinsicAttributes` noise from a React 19↔18\n  types mismatch (two copies of `@types/react` in one program — `packages/sdk`\n  had its own) is gone as of the Next 16 upgrade. If `TS2786` appears again,\n  treat it as a genuine duplicate-`@types/react` regression and investigate —\n  do not wave it through.\n- `npx eslint <files>` should be clean of errors. `eslint .` across the whole\n  app currently reports ~455 warnings, mostly `react-hooks/*` React Compiler\n  rules pending a dedicated audit — expected until that audit lands.\n\n### Frontend design standard — Jay/Kortix bar\n\nWhen touching any visual surface in `apps/web`, treat brand fit as a release\ngate, not polish:\n\n- Read `.claude/skills/kortix-design-system/SKILL.md` first and compose existing\n  primitives from `@/components/ui/*` before inventing local chrome.\n- Match the current Jay Suthar / Kortix product aesthetic: calm neutral surfaces,\n  dense-but-legible UI, black/white plus one earned accent, token-driven spacing,\n  and no decorative color, glow, or one-off rounded boxes.\n- Use recent product surfaces as references before editing: `/design-system`,\n  `apps/web/src/features/co-worker/project-layout/project-home.tsx`,\n  `apps/web/src/components/ui/wallpaper-background.tsx`, and the account/IAM\n  screens called out by the design-system skill.\n- Verify visual work in the browser and include the exact lint/typecheck commands\n  you ran in the PR. If it does not look native beside Jay-authored UI, keep\n  iterating before shipping.\n"}}