Go

Install the sixty agent in this Go service so its functions, HTTP routes and
database queries report to sixty.

The package is github.com/andana-to/drift/packages/go, imported as "sixty". It
has no dependencies of its own.

1. In main(), before the server starts:

      defer sixty.Init(sixty.Config{}).Shutdown(context.Background())

   The zero Config reads the environment. Shutdown sends the last window, so
   a short-lived process still reports; on a long-lived server it runs at
   exit. If this service already traps signals for graceful shutdown, call
   Shutdown there instead of deferring.

2. Wrap the HTTP handler — sixty.Middleware(handler) — at the outermost level,
   so the span covers the other middleware rather than sitting inside it.
   Anything that speaks net/http works: chi, gorilla/mux, echo, the standard
   library's own mux.

   If this project uses a router that knows its route patterns, add one more
   middleware AFTER routing that calls sixty.SetRoute(r.Context(), pattern) —
   chi.RouteContext(r.Context()).RoutePattern(), or the equivalent. Without
   it, /users/42/orders is templated to /users/:id/orders, which is close and
   occasionally wrong.

3. Measure the database. Replace the sql.Open call with sixty.Open, passing
   the same driver name and DSN:

      db, err := sixty.Open("pgx", dsn)

   If this project builds its pool some other way — a Connector, a pgx pool
   through stdlib, a wrapper library — use sixty.WrapDriver(d) around the
   driver it registers instead. Postgres is what the detector understands;
   another database will report timings and nothing else.

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

      func (s *Store) GetUserOrders(ctx context.Context, id int) (_ []Order, err error) {
          ctx, span := sixty.Start(ctx, "orders.GetUserOrders")
          defer span.Capture(&err)
          ...
      }

   Put it on the service or repository layer — the code between the handler
   and the database — not on handlers the middleware already covers. Name
   operations package.Function, and keep the names stable: the name is the
   identity, and renaming one starts its history over.

   Do NOT put it on functions called hundreds of thousands of times a second.
   A span costs a few hundred nanoseconds, which is nothing next to a request
   and everything next to a tight 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 usually needs nothing: the Go toolchain stamps the
   commit into the binary and the agent reads it back. If this builds with
   -buildvcs=false, or from a source tarball with no repository, 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.
- Thread the context. sixty.Start returns a new ctx and the work must use it,
  or the queries underneath are recorded as belonging to nobody. There is no
  ambient-context version of this and you should not build one: no
  goroutine-local storage, no //go:linkname, no global "current span".
- A goroutine started inside a measured function must be passed that ctx if
  its work should count towards the operation. One that outlives the request
  should NOT be — it would attribute background work to whoever happened to
  start it.
- 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.
- Leave the sql.Rows handling alone. The agent counts rows as the caller
  reads them and closes the span when the rows close, so a query whose rows
  are never closed reports late — which is also a connection leak worth
  fixing on its own terms.

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.