UDINA BTP

Appearance

AI-Driven Workflow ​

The AI-driven workflow is the heart of the AI-Driven Development Model: agents assist across the entire chain from specification to deployment, while a single source of truth keeps generated code maintainable and reviewable.

Spec-Driven Development ​

The domain drives everything. The flow moves from a written specification to a CDS domain model, then outward to services and UI:

Because SAP CAP is the central abstraction, the domain model is the contract that agents generate against — cds-typer propagates types end to end, so UI code stays aligned with the model.

Agents & Tooling ​

  • Anthropic Claude SDK — called from CAP service handlers for application-level AI features (the AI layer). A thin per-provider adapter is added only if a second provider is introduced.
  • Claude Code — the agentic coding assistant used during development.
  • Scaffolding via CLI facets — agents create projects and features with cds init / cds add, never by hand-writing config, so package.json, tsconfig.json, and mta.yaml stay consistent.
  • Version-matched agent skills — e.g. npx @tanstack/table intent add installs skills matched to the installed library version, keeping generated code on the correct API.
  • Optional: native CAP vector support for in-CAP RAG.

Guardrails ​

  • Single source of truth — the repository's ARCHITECTURE.md holds all binding stack decisions. Agents and developers must not silently deviate; divergences (newer majors, deprecations) are flagged there and bump the file's version.
  • Type safety end to end — cds-typer @cds-models/* types plus TypeScript across frontend and backend catch model/UI drift at compile time.
  • Pinned dependencies & CI audit — exact versions in lockfiles, Renovate/audit gate before merges, with heightened scrutiny for @tanstack/* and @cap-js/* after the May 2026 supply-chain incidents.
  • Facet-based config — hand-rolled config drifts and breaks cds build; facets keep it reproducible.

End-to-End Flow ​

  1. Specify — capture the requirement as a spec.
  2. Model — derive the CDS domain model (Entities, Aggregates, Bounded Contexts).
  3. Serve — expose OData v4 services via CAP; cds-typer regenerates @cds-models/*.
  4. Build UI — generate React/shadcn/ui components wired to the typed API via TanStack Query.
  5. Test & deploy — validate, then deploy to SAP BTP Cloud Foundry.