Syncanix with NestJS

NestJS declares routes with decorators and composes prefixes globally. Discovery reads both — the @Controller prefix and setGlobalPrefix — even when they live in different files.

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:

// main.ts
app.setGlobalPrefix('api');

// orders.controller.ts
@Controller('orders')
export class OrdersController {
  @Get(':id')                       // → GET /api/orders/:id
  @Post(':id/refund')               // → POST /api/orders/:id/refund
}

The extractor combines the @Controller(’orders’)-style controller prefix with setGlobalPrefix from main.ts — a cross-file composition — so each handler decorator is catalogued under its full production 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