Python

Install the sixty agent in this Python 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?" If yes, use sixty.agent,
sixty.generation and sixty.tool around custom orchestration, and call
sixty.instrument_openai(client) or sixty.instrument_anthropic(client) for
those SDKs. Never record prompts, outputs, tool arguments or tool results.

1. Add sixty-sh to this project's runtime dependencies — the same place the
   web framework is declared (pyproject.toml, requirements.txt, Pipfile), not
   a dev or test group. It runs in production; that is the entire point. It
   has no dependencies of its own.

2. Call sixty.init() once, as early in process startup as you can get it, and
   before any database connection is opened. Put it at the top of the module
   the deployed process actually starts — wsgi.py, asgi.py, main.py, manage.py
   for a management command — not inside a function that runs per request.

3. Wrap the application so requests become operations. Work out which of these
   this project is; do exactly one:

   a. Flask — call instrument_flask(app) from "sixty.instrument.flask" after
      the app and its routes exist. It wraps app.wsgi_app and names operations
      by the matched url_rule.

   b. Django — put "sixty.instrument.django.SixtyMiddleware" FIRST in the
      MIDDLEWARE list, so the span covers the rest of the middleware rather
      than sitting inside it. Operations are named by the route as written in
      urls.py.

   c. FastAPI, Starlette, Litestar, Quart, or anything else ASGI — wrap with
      SixtyASGIMiddleware from "sixty.instrument.asgi".

   d. Any other WSGI application — wrap the WSGI callable with SixtyMiddleware
      from "sixty.instrument.wsgi".

4. Mark the functions worth measuring. This step is what turns "this endpoint
   got slow" into "this function started issuing 14 queries", and skipping it
   leaves the feed with routes and queries and nothing in between:

   - Put @sixty.trace on the functions that do the work — the service layer,
     the repository, whatever this project calls the code between the view and
     the database. Not on view functions the middleware already covers.
   - Or, for a module of them, call sixty.instrument_module(sys.modules[__name__])
     at the bottom of the file; it wraps every public function that module
     defines and leaves imported ones alone.
   - Leave anything called hundreds of thousands of times a second alone. A
     span costs a couple of microseconds, which is nothing next to a request
     and everything next to a tight inner loop.

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 call init() at import time in a module that is also imported by test
  collection or by a build step. Without a key it is inert, but a flush thread
  started in a test runner is a surprise nobody asked for.
- Do NOT wrap generators or async generators with @sixty.trace. Their work
  happens between next() calls, so the measurement would be of constructing an
  object. Wrap whatever drains them.
- Do NOT add any analytics, user id, session id, or cookie to what is
  reported. The agent is deliberately anonymous and must stay that way.
- Queries are instrumented through psycopg (2 and 3) automatically. If this
  project talks to its database some other way, tell me rather than wiring
  something up — measuring it may need work in the agent.

If this service runs under gunicorn, uwsgi or any pre-fork server, note how
many workers it runs: each one reports independently and the collector merges
them, which is correct, but it is worth knowing when you read the numbers.

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.