You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 74602fe
Browse filesBrowse the repository at this point in the historyBrowse files
description: Cursor Cloud environment setup and run notes for T3 Code (Cursor-specific; not for other editors/CI)
3
+
alwaysApply: true
4
+
---
5
+
6
+
# Cursor Cloud specific instructions
7
+
8
+
These notes apply only to Cursor Cloud agents (kept out of the shared `AGENTS.md` since T3 Code is
9
+
developed in many places). They cover the pre-provisioned VM environment and non-obvious run caveats.
10
+
11
+
## Toolchain
12
+
13
+
Pre-installed and wired into login shells (`~/.bashrc`/`~/.profile`): Node 24 (via nvm), the global
14
+
`vp` (Vite+) CLI, and its bundled pnpm. `vp` is the package manager + task runner for this repo
15
+
(`vp i`, `vp check`, `vp run typecheck`, `vp test`, `vp run --filter <pkg> <script>`).
16
+
17
+
- Node gotcha: the base image also ships an older Node on `/exec-daemon` that wins on `PATH` in
18
+
non-login shells. Run commands in a login shell (`bash -lc '...'`) or prepend
19
+
`$HOME/.nvm/versions/node/v24.13.1/bin` so Node 24 (`engines.node: ^24.13.1`) is used.
20
+
- `vp check` also runs the formatter (not just lint); markdown edits must be formatter-clean. Run
21
+
`vp check --fix` before committing.
22
+
23
+
## Running the web app
24
+
25
+
- `npm run dev` (from repo root) starts contracts (watch), web (Vite, port 5733), and the server
26
+
(`node --watch`, port 13773) together, auto-wiring `VITE_HTTP_URL`/`VITE_WS_URL`. Use
27
+
`npm run dev:server` / `npm run dev:web` for one side. If base ports are taken it auto-offsets to
28
+
the next free pair, so read the actual ports from stdout. Avoid production `build`/`start` in dev.
29
+
- Auth/pairing: the server is unauthenticated by default and prints a pairing URL to stdout on startup
30
+
(e.g. `http://localhost:5733/pair#token=XXXX`). Open that URL in the browser to pair before the web
31
+
UI can talk to the server. Server state (SQLite, auth, projects) lives under `~/.t3`
32
+
(`T3CODE_HOME`); multiple `npm run dev` instances bind different ports but share that same DB.
33
+
- Agent providers are external CLIs (`codex`, `claude`, `cursor-agent`, `opencode`) probed on `PATH`.
34
+
Without one installed the UI loads but no agent can run. Claude Code
35
+
(`npm i -g @anthropic-ai/claude-code`) works headlessly using `ANTHROPIC_API_KEY` from the
36
+
environment (the server forwards `process.env` to the child; no interactive `claude auth login`
37
+
needed). Provider probing runs at startup and refreshes roughly every 5 minutes — restart the dev
38
+
server to pick up a newly installed provider CLI immediately.
39
+
40
+
## Android native builds (apps/mobile)
41
+
42
+
The Android toolchain is pre-installed and wired into login shells: OpenJDK 17
43
+
(`JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64`; the base image's default `java` is 21, so builds must
44
+
use `JAVA_HOME`), and the Android SDK at `$HOME/Android/Sdk` (`ANDROID_HOME`/`ANDROID_SDK_ROOT`) with
45
+
platform-tools, `platforms;android-36`, `build-tools;36.0.0`, `ndk;27.1.12297006`, and `cmake;3.22.1`.
46
+
Gradle auto-downloads any additional pinned SDK packages on demand.
47
+
48
+
- Generate the native project first: from `apps/mobile`,
Copy file name to clipboardExpand all lines: .macroscope/check-run-agents/effect-service-conventions.md
+9Lines changed: 9 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -43,6 +43,15 @@ Review changed TypeScript and directly affected call sites for the conventions b
43
43
- Keep implementation-specific names when an abstract port module contains one of several possible implementations, for example `makeCloudflaredRelayClient` and `layerCloudflared` in `RelayClient.ts`.
44
44
-`infra/relay/src/db.ts` is an intentional exception: an inline `Layer.succeed(RelayDb, db)` is acceptable without generic `make`/`layer` exports.
45
45
46
+
## Dependency acquisition and runtime boundaries
47
+
48
+
- Production service construction must acquire Effect service dependencies from the environment with `yield* Foo.Foo`, and its `make`/`layer` types must expose those requirements. Flag factories or constructors that accept `Foo["Service"]` (or a plain object whose methods return `Effect`) when that value is an implementation dependency owned by the service. Passing service instances explicitly is acceptable in tests and integration harnesses; passing pure configuration, immutable domain values, or deliberate callback strategies is not service injection.
49
+
- Do not hide dependencies in module globals, closures over singleton services, or `Layer.succeed` implementations that call runtime-backed or imperative APIs. Trace helpers used by a supposedly synchronous layer far enough to verify that asynchronous services are represented in the Effect environment.
50
+
-`ManagedRuntime.make`, `runPromise`, and `runPromiseExit` belong at explicit application/framework boundaries such as React, native callback, CLI, or HTTP adapters. Flag their use in domain services, repositories, persistence implementations, and service constructors. A clearly named imperative adapter may bridge an Effect service into a Promise API, but it must not become a dependency of another Effect service.
51
+
- Do not create per-feature managed runtimes or Atom runtimes to smuggle the same owned resource into multiple consumers. Compose the resource once in an application-owned layer/runtime and provide its context to integration runtimes.
52
+
- When acquisition can fail but a caller must retain fallback behavior, keep the failure typed in Effect rather than bypassing the layer through an imperative runtime. Model unavailability in service operations or with an explicit optional-service layer so downstream recovery remains visible and testable.
53
+
- During review, search touched code and affected call sites for service-instance parameters, `Layer.succeed`, `ManagedRuntime.make`, and `.runPromise`/`.runPromiseExit`. Verify that each occurrence is a legitimate test seam, pure value injection, or application boundary—not fake dependency injection or a hidden runtime.
54
+
46
55
## Errors and predicates
47
56
48
57
- Define service failures with `Schema.TaggedErrorClass` and structured attributes. Derive `message` from those attributes rather than storing an unstructured message as the only data.
0 commit comments