Syncanix with Fastify

Fastify encapsulates routes in plugins and mounts them with prefixes. Discovery follows register(plugin, { prefix }) across files, so plugin routes are catalogued at their full paths.

What discovery reads

Discovery is static — it reads your source, not your traffic. It composes full request paths across files, so mounted prefixes are part of every extracted route:

// server.ts
await fastify.register(ordersPlugin, { prefix: '/api' });

// orders.plugin.ts
fastify.get('/orders/:id', getOrder);        // → GET /api/orders/:id
fastify.post('/orders/:id/refund', refund);  // → POST /api/orders/:id/refund

The extractor follows register(plugin, { prefix }) mounts across files — including @fastify/autoload directory-derived prefixes and autoPrefix overrides — so plugin-encapsulated routes carry their full mounted path.

Run discovery

From the repository root, run the init command. It detects the framework automatically, asks for consent before any LLM enrichment, and writes a deterministic catalog:

$ npx syncanix init
✓ detected framework
✓ scanned routes
✓ wrote .syncanix/catalog.json
→ review your capabilities in the dashboard

Review the catalog

The catalog at .syncanix/catalog.json lists every capability discovery found — method, path, and the enriched description your users will see. Review it like code before uploading: it is the contract your chat surface and MCP server expose.

Ship the surface

Once the catalog is uploaded, embed the widget for in-app chat and connect the per-tenant MCP server for Claude, ChatGPT, and Cursor. Every write action stays permission-gated, confirmed, and audited.

Next steps