Connect and set up

Code analysis and development plans

How Yavaren reads your repositories and data sources, reviews them, plans each feature, and applies what you approve.

Yavaren learns how your code is built before it writes any of it, and shows you what it learned.

Your repositories are analysed as soon as you add them

When you create a project, or add a repository to one, Yavaren analyses each repository at once, on your own runner. The analysis only reads: nothing is written to the repository and no code agent runs. It finds:

• how the code is built: its architecture (for example clean / onion, layered, vertical slices, a front-end application), its projects, frameworks and libraries;
• the design patterns it uses and the files that show them: dependency injection, repositories, mediator with commands and queries, validation, mapping, logging, error handling, React hooks and state, and more;
• its conventions and your team's rules: naming, nullability, the rules written in CONTRIBUTING, coding guidelines, AI-assistant instruction files, decision records, .editorconfig, linters and analyzers;
• how it is tested, built and deployed: test frameworks and style, the CI pipeline and its commands, containers, charts, infrastructure as code;
• what it already offers: endpoints, data entities, screens, commands and events, and the data stores it uses;
• Yavaren's review: improvement opportunities, best practices not followed, potential issues and security gaps (for example credentials in the repository, SQL built from strings, certificate checks switched off, unsafe deserialisation). A secret's value is never shown: only where it is.

Data repositories get the same reading. A dbt project, a Databricks bundle with PySpark or Delta pipelines, a Snowflake repository (schemachange migrations, Snowpark, the Snowflake CLI) and a SQL repository (Flyway, Liquibase, a SQL Server database project) are analysed like application code: SQL counts as code; the analysis finds the layers (staging, intermediate and marts, or bronze, silver and gold), how models and migrations are named, the folder materializations, the dbt data tests, unit tests and contracts (or pytest with a local Spark session, Snowpark's local testing, pgTAP, tSQLt), and it says which data stack suits it. Its review adds data points: credentials in profiles.yml, databricks.yml or Flyway settings, SQL built from strings for spark.sql() / session.sql(), GRANT ALL or grants to PUBLIC, DROP and TRUNCATE in migrations, tables named directly instead of ref() / source(), models outside staging reading sources, incremental models without a unique key, marts without a column list, models without a test, and whole DataFrames pulled to the driver. profiles.yml and connection settings are read only for what says how the project is built (the adapter type, target and folder names), never for a value. Stories in a data repository then say in their draft pull request which tests could not run because they need the database or warehouse; those run in your own CI.

Open it under Projects › Code analysis: first across the whole project (sizes, languages, frameworks shared by every repository, differences such as different test frameworks, review points by severity), then per repository. Choose Analyse again whenever the code has changed a lot. Without an engineer on the project the analysis waits until one is assigned.

Which commit, and when. Each repository says Analysed at commit abc1234 on the date the runner read it, and keeps the latest five analyses (commit, date, files and review points by severity) under Earlier analyses. An analysis older than 30 days (your administrator may change this) shows Out of date — analyse again; stories still use it until you do, and nothing is re-run by itself. When Yavaren analyses a repository again by itself (for example the project was edited) and the repository is still at the commit already analysed, it is not read again: the analysis you have is kept and marked as checked. Analyse again always reads the whole repository.

Your project's domain and what it has delivered

As soon as a project's tracker is connected (and whenever it changes), Yavaren reads every epic, feature and story of the last five years in it — titles, types, states, dates, labels, areas and parents, never comments — on your runner, with the tracker connection's own token. From it Yavaren learns:

• the domain: what the project is about (for example loan servicing), in the project's own words (a glossary);
• its functional areas: from your epics and features (or area paths, components, milestones or labels), each delivered, in progress or planned, with examples of what was delivered;
• year by year: what was completed and raised each year, the typical time from raised to done, the highlights, and whether delivery is growing or slowing;
• the open backlog by area;
• where each area lives in the code: each area is related to the endpoints, entities, screens, messages and tables of the analysed repositories and data sources. Yavaren also says which delivered areas it could not find in the code, which planned areas already have code, and which parts of the code no tracker history speaks of.

It is under Projects › Code analysis › Domain and delivery history. Choose Read the tracker again (and how many years) at any time. Every feature is then planned, and every story built, knowing the domain: using its words, staying consistent with what was delivered, and building on the code that carries it.

Which part of the tracker is read. The analysis reads the project's own project in the tracker. It says so at the top: Read from Azure DevOps Boards, project …. By default that is the tracker connection's project. When one tracker connection serves several of your projects (one Azure DevOps organisation with a Salesforce and a Servicing project, say), set each project's own in Projects › Actions › Edit › Project in the tracker (or Choose from … to pick it from the list your token can see). Optionally narrow it to an area path (Azure DevOps), a component (Jira) or a label (GitHub, GitLab) when one tracker project holds several teams' work. Saving reads the tracker again from there; an analysis read from somewhere else is marked Read from elsewhere until then. The project's own project in the tracker is also where its stories are read from and its proposed stories are created.

From Work to the result. On Work, each analysis says what it is (Domain from the tracker, Repository main, Data source) and, once it is done, links straight to it: See the domain analysis or See the code analysis opens the project's analysis on Projects. The same link is in the job's Details.

Data sources

Connect the databases and data platforms the code uses (Connections: PostgreSQL, SQL Server, MySQL, Oracle, Amazon Redshift, Snowflake, Databricks or Google BigQuery, with a login that may only see the structure — each connection's help says which privileges, for example REFERENCES in Snowflake or BROWSE in Databricks), then Projects › Code analysis › Connect the data source, for the whole project or one repository. Yavaren reads the database's structure only — tables, columns, keys, indexes and estimated row counts — on your runner, through the database's own catalog. It never reads a row. Its review of the data model points out, for example, tables without a primary key, foreign keys without an index, columns that look like plain-text passwords, and sensitive personal data in clear columns. On a warehouse (Redshift, Snowflake, Databricks, BigQuery) keys are only informational and there are no indexes, so it asks instead about very large tables that are not clustered, partitioned or sorted. If part of the structure cannot be read (for example the keys, without the privilege), the analysis says so and uses the rest.

You choose what is applied

Each review point has an Apply box. Every security gap and every high or medium point is applied unless you clear it; save your choice per repository and per data source. Applied points reach every story built in that repository: they are fixed in the files a story changes, and never repeated in new code. The story is also told how the code is built (architecture, patterns, conventions, rules, the files to model new code on) and the tables of the data sources it uses.

The development plan of a feature

When Yavaren splits a feature into stories, it also writes its development plan: how each story will be built (the approach, the files to change, each acceptance criterion with its change and its test, the risks, the existing file it is modelled on), from its analysis of the code and the data. The plan is attached to the feature (yavaren-development-plan-<feature>.md), summarised in a comment, and the feature is tagged dev-plan-review.

• Approve it under Work › Development plans (choosing which review points are applied), or add the tag dev-plan-approved to the feature.
• Ask for changes there, or reply on the feature with a comment that starts Plan feedback <code> (the code is in Yavaren's comment). Yavaren plans again and posts the new round; the stories stay as they are. Only a person of your organisation who may decide counts.

Stories approved before their plan wait for it and start as soon as it is approved (an admin can switch this off for the organisation or a project). Then each story is built exactly as planned, with the approved points.

A brand-new codebase

When a feature needs a codebase that does not exist yet (for example a separate service), the plan proposes it, with a blueprint taken from the codebase it should be built like: the same structure, frameworks, patterns, rules, tests, CI and deployment, without that codebase's gaps. Its first story sets it up. Once the plan is approved, an admin either lets Yavaren create the empty repository (with the repository connection of the codebase it follows, on your runner; Yavaren never touches a repository that already holds code), or names a repository they created. It is then added to the project and its stories start.

On-prem and cloud

Everything works the same on Yavaren cloud, on-prem (connected or air-gapped) and hybrid: the analysis, the reading of data sources and the creation of a repository all run on your own runners against your own hosts; only the bounded results (never code, never rows, never a secret) are kept.