Node

Install the @sixty-sh/node agent in this service so its functions, HTTP routes
and database queries report to sixty.

Before editing, inspect whether this service makes LLM or agent calls. If it
does, ask the user: "Do you want LLM monitoring?" Do not enable it without
their answer. Core HTTP, function and database monitoring is installed either
way. If they say yes, also follow the AI wiring in step 3; if no, leave every
AI client and call site untouched.

1. Install @sixty-sh/node as a dependency (not a devDependency — it runs in
   production; that is the entire point).

2. Call init() from "@sixty-sh/node" in the server entry point, BEFORE the
   application imports anything else. It patches the database client at call
   time, so a module that already imported "pg", "mysql2", "postgres" or
   "mongodb" above it is not instrumented. In an ESM entry, imports are
   hoisted above statements — so either put the init in its own module
   imported first, or use --import as in step 4.

   Then check which database client this project actually uses. pg, mysql2,
   postgres.js and mongodb are found and patched by init() with nothing
   further to do — including Mongoose, which drives the mongodb driver.

   PRISMA IS THE EXCEPTION and it is the one worth checking for, because
   getting it wrong is invisible. Prisma does not use pg — it runs queries
   through its own engine, so no patch reaches them — and its extension hook
   returns a NEW client instead of modifying the one it was given. So the
   application has to use the wrapped client:

      import { instrumentPrisma } from "@sixty-sh/node"
      export const prisma = instrumentPrisma(new PrismaClient())

   Replace the project's existing PrismaClient export with that one. Skip this
   and everything still reports except the queries, which is the failure that
   looks like success.

3. If LLM monitoring was requested, instrument only the SDKs the project
   actually uses: instrumentOpenAI(client), instrumentAnthropic(client),
   instrumentAISDK({ generateText, streamText }), or langChainCallbacks().
   For other providers and OpenAI-compatible services such as DeepSeek, wrap
   the call with generation({ provider, model }, () => call()). Never attach
   prompts, generated text, tool arguments or tool results; sixty records
   timing, provider/model, token usage and cost metadata only.

4. Turn on function-level tracing. Work out which of these this project can
   use; do not do both:

   a. It has a build step (Next, Vite, webpack, Rollup, esbuild). Wrap the
      config with withSixty() from "@sixty-sh/node/transform", or add the
      matching bundler plugin from that same module. The transform needs
      @babel/core and unplugin, which are peer dependencies — without them it
      emits nothing and says nothing, so add them if they are not there.

   b. It has no build step — it is started with a plain "node src/server.js"
      or "tsx src/server.ts". Add --import @sixty-sh/node/register to the
      start command, which both installs the transform and calls init() early
      enough that step 2 is already satisfied.

   NEXT.JS, SPECIFICALLY. Use (a) for the transform, and start init() from a
   flag rather than from instrumentation.js:

      // sixty.mjs, beside package.json
      import { init } from "@sixty-sh/node"
      init()

      # the deployed start command
      node --import ./sixty.mjs node_modules/next/dist/bin/next start

   instrumentation.js looks like the right hook and is compiled once per
   runtime. If the app has middleware there is an edge compilation of it, and
   the bundler pulls the agent's node:fs, node:http and node:crypto into a
   bundle that cannot read those schemes — the build fails. A NEXT_RUNTIME
   guard inside register() does not help: it runs at runtime, and the
   bundling already happened.

   Change the command the deployed process actually runs, not only the local
   dev script. A Dockerfile CMD, a Procfile, or a platform start command
   overrides package.json and is the one that matters.

5. Set these environment variables wherever the service is deployed:
      SIXTY_API_KEY  = a secret key starting sixty_sk_ — ask me for it. Do not
                       invent one, and do not commit it.
      SIXTY_SERVICE  = my-app
      SIXTY_ENDPOINT = https://ingest.sixty.sh

   The release identifier is picked up automatically on Vercel, Render,
   Railway, Fly, Heroku and GitHub Actions. If this deploys some other way,
   set SIXTY_RELEASE to the commit SHA — without one, every measurement lands
   in a single nameless bucket and no comparison can ever be made.

Constraints — correctness requirements, not style preferences:

- Do NOT change any application behaviour. This is instrumentation only: no
  refactors, no reordering of business logic, no "while I was in here" fixes.
- Do NOT apply the transform to client bundles. It is for server code; in a
  framework that builds both, restrict it to the server build.
- Do NOT add any analytics library, user id, session id, or cookie to what is
  reported. The agent is deliberately anonymous and must stay that way.
- If a hot function must not be traced, put // @sixty-ignore above it rather
  than turning the transform off for the whole file.

When you are done, tell me which files you changed and what the deployed start
command now is, so I can confirm data is arriving.