DEV Community: Younes Ben Tlili

Don't Start With RAG: Lessons From Building an Automotive AI Pipeline

Younes Ben Tlili — Sun, 16 Aug 2026 18:03:12 +0000

When building an AI product, it's tempting to start with the fashionable pieces.

Vector database.

RAG.

Agents.

Multimodal models.

Then connect everything to an LLM and hope the final prompt makes sense of it.

While building the automotive AI pipeline behind Inspecly, we ended up taking almost the opposite approach.

The first question wasn't:

Which LLM should we use?

It was:

What information do we actually have, how reliable is it, and which system should process it?

That distinction changed the architecture.

The input is messy by default

A driver rarely describes a vehicle problem like a mechanic.

They might say:

"My car makes a strange noise when I start it."

But a request can also contain:

a written description,
a voice message,
vehicle photos,
an OBD scan,
vehicle metadata,
or only some of these.

These inputs do not have the same reliability.

An OBD code is structured information.

A photo is visual evidence.

A voice message represents what the driver observed.

Vehicle metadata may require exact lookup.

Treating all of them as equivalent pieces of text would be a mistake.

So before asking an LLM to reason about the problem, we normalize the available evidence.

Conceptually:

{ "vehicle": { "make": "...", "model": "...", "vin": "optional" }, "description": "The engine loses power when accelerating.", "voice_transcription": null, "obd_codes": ["..."], "images": [...] }

This object doesn't contain a diagnosis.

It describes what we actually know.

Why not send everything to one multimodal LLM?

You absolutely could.

Description + images + OBD + vehicle information → one model → final answer.

It is very attractive for a prototype.

It's also difficult to control.

Consider these inputs:

OBD code
→ deterministic lookup

Photo
→ visual analysis

Voice
→ transcription

Vehicle information
→ exact lookup/API

Unknown technical information
→ tool-based retrieval

Safety constraint
→ explicit business rule

These are fundamentally different operations.

Putting everything into one giant prompt hides those differences.

It also becomes much harder to answer:

Where did this conclusion come from?

That's a serious problem once the system moves beyond a demo.

Structured data comes first

One design decision became particularly important for us:

If reliable structured information already exists, use it directly.

For example, when an OBD diagnostic trouble code is available, we first query our curated OBD database.

A record can contain information such as:

{ "code": "...", "explanation": "...", "possible_causes": [], "possible_actions": [], "validation_status": "reviewed" }

Why retrieve semantically similar paragraphs from documents when the system can perform an exact lookup against validated fields?

This is an important distinction.

Structured data and RAG solve different problems.

Structured data is excellent for:

exact identifiers,
validated fields,
controlled records,
deterministic queries.

RAG becomes useful when knowledge primarily lives inside documents.

What if the structured knowledge is missing?

That's where agents become useful.

Our internal database cannot contain every code, every manufacturer-specific interpretation and every vehicle configuration.

When structured knowledge is missing, a tool-using agent can search for additional information.

But there is an important rule:

Retrieved information should not silently become equivalent to validated information.

Instead, preserve provenance.

For example:

{ "code": "...", "source_type": "tool_agent", "sources": [], "validation_status": "unverified" }

The final system should know whether a piece of information came from:

a reviewed internal database,
an external technical source,
a tool-using agent,
image analysis,
or the driver themselves.

The model doesn't only need context.

It needs context with provenance.

Images are evidence, not diagnosis

Vision models are another useful component.

A photo might reveal:

a dashboard warning light,
visible body damage,
tyre wear,
a fluid trace,
a damaged component. But a photograph almost never tells the whole story.

The output should therefore look closer to:

{ "observation": "Possible fluid trace", "confidence": "medium", "limitations": [ "The source is not visible" ], "requires_physical_inspection": true }

rather than:

Your vehicle has an oil leak.

That difference matters.

AI systems often sound more certain than the evidence actually allows.

Voice is just another source of context

Voice is valuable because describing a mechanical problem through a form can be difficult.

The message gets transcribed, then becomes another input to the evidence layer.

But again:

"The engine is overheating."

is not necessarily a confirmed technical fact.

It's something reported by the driver.

That distinction should survive the entire pipeline.

The next step: a structured evidence layer

Today, multiple processing paths can eventually contribute information to the generation context.

As the number of sources increases, simple concatenation becomes harder to control.

You eventually need something closer to:

{
  "reported_symptoms": [],
  "obd_findings": [],
  "visual_findings": [],
  "retrieved_information": [],
  "missing_information": [],
  "conflicts": [],
  "safety_flags": []
}

The final LLM can then generate from this normalized evidence instead of receiving an unstructured wall of text.

This makes several things easier:

provenance,
conflict detection,
confidence handling,
evaluation,
safety rules,
debugging.

It also makes the architecture much easier to evolve.

So where is RAG?

We aren't starting with a large automotive RAG pipeline.

And that's deliberate.

Adding PDFs to a vector database isn't the difficult part.

The difficult part is knowing whether a retrieved procedure applies to the correct:

manufacturer,
model,
year,
engine,
transmission,
vehicle version,
document revision.

A perfectly retrieved technical procedure for the wrong engine generation can still be completely wrong for the vehicle in front of you.

So our current priority is:

Validated structured data
↓
Explicit rules / APIs
↓
Tool-based retrieval when needed
↓
LLM generation

RAG becomes much more valuable when we have a controlled corpus of manufacturer manuals and validated technical documentation.

Eventually, the source router could look roughly like:

Validated structured record
Explicit safety/business rule
Vehicle-specific API
Retrieved validated documentation
Tool-agent fallback
Model hypothesis

This isn't a universal hierarchy.

The broader point is more important:

A generated or retrieved paragraph should not silently override a reviewed fact.

Two audiences, same evidence

Another interesting problem is that the same evidence needs different outputs.

A driver needs:

simple language,
uncertainty explained clearly,
the next useful action.

A garage needs:

vehicle context,
reported symptoms,
OBD information,
technical observations,
missing information,
potential directions to investigate.

We don't need two independent AI analyses.

We need two representations of the same evidence.

That distinction has become an important part of the product architecture.

What I'm learning from building this

The quality of an AI response doesn't start with the final prompt.

It starts much earlier:

Input collection
↓
Normalization
↓
Source routing
↓
Evidence + provenance
↓
Conflict / uncertainty handling
↓
Generation

A better model can improve generation.

It cannot fix an architecture where every source is mixed into one untraceable context.

My current takeaway is simple:

Use deterministic systems where knowledge is deterministic.

Use agents where flexibility is useful.

Use RAG when document retrieval is actually the problem.

And preserve uncertainty instead of asking the LLM to hide it behind a confident answer.

I wrote a more detailed version of this architecture — including the current pipeline, future evidence layer and planned RAG architecture — here:

Original deep dive:
https://younes.hashnode.dev/inside-inspecly-s-automotive-ai-pipeline-from-driver-symptoms-to-actionable-garage-requests

I'm also building AI DevList, where I curate useful resources about agents, LLM engineering, MCP, RAG, evals and production AI — with a short explanation of why each resource matters.

https://aidevlist.io/

I'm curious how other teams handle this:

Do you start from the LLM and build outward, or from the evidence and build inward?

I Built AI DevList Because Finding AI Content Is No Longer the Problem

Younes Ben Tlili — Sun, 16 Aug 2026 17:47:49 +0000

There is no shortage of AI content.

Actually, we probably have the opposite problem.

Every day there is:

a new agent framework,
a new MCP server,
another RAG approach,
another benchmark,
another model release,
another “production-ready” architecture,
another GitHub repository trendi ng for 48 hours.

As an engineer, I don't struggle to find AI content anymore.

I struggle to decide:

What is actually worth my time?

That's why I built AI DevList.

👉 https://aidevlist.io/

Not another AI news newsletter

I don't want AI DevList to become a summary of everything that happened in AI during the week.

There are already excellent newsletters doing that.

The focus is much narrower:

resources that are useful for people actually building AI systems.

The main topics are:

Agentic AI
LLM Engineering
MCP
RAG
Evals
Tools & Frameworks
Research
Open Source
Production AI

The goal is not to publish 50 links.

If an issue contains 10–15 genuinely useful resources, that's enough.

Curation alone isn't enough

When I first announced the project, someone gave me a very good piece of feedback:

Curating content is useful, but the real value comes from adding context.

I agree.

So every resource selected for AI DevList now has two parts.

1. What is it?

A short, neutral description of the resource.

No marketing rewrite.

No exaggerated claims.

2. Why we picked it

This is the important part.

For example:

Why we picked it
Stateless MCP isn't just a protocol detail. It changes how remote MCP servers can be deployed and scaled, removing part of the session-management complexity that infrastructure teams previously had to handle.

Or:

Why we picked it
Adding a SKILL.md file doesn't guarantee that an agent will reliably discover or follow it. This benchmark is interesting because it evaluates the complete model + harness + skill combination rather than treating skills as static prompt files.

That's much closer to what I personally want when someone recommends a technical article to me.

Don't only tell me what it says.

Tell me why I should care as an engineer.

My current curation workflow

The workflow is deliberately simple.

Discover resources
↓
Filter obvious noise
↓
Read / inspect the source
↓
Check technical relevance
↓
Categorize
↓
Write a short description
↓
Add "Why we picked it"
↓
Human review
↓
Publish

AI helps with discovery and preparation.

It does not decide what gets published.

That's an important distinction for me.

I don't want to build an automatically generated newsletter that summarizes whatever happens to rank highly that week.

The final selection remains editorial.

What makes a resource worth selecting?

I'm currently using a few simple questions.

Is it technically credible?

Primary sources, engineering blogs, research papers and serious open-source work get priority.

Does it solve a real engineering problem?

Observability, reliability, security, evaluations, context management, orchestration, infrastructure, cost...

Not just demos.

Can someone apply something from it?

Even research becomes much more interesting when it changes how we think about architecture or implementation.

Is it saying something new?

Ten articles repeating the same product announcement don't deserve ten slots.

Is it worth 10 minutes of someone's time?

This may actually be the most important criterion.

Attention is expensive.

The first issue

I'm currently preparing AI DevList #001, which will be published on August 23.

Some of the topics I'm reviewing include:

emerging behavior in multi-agent systems,
MCP architecture and security,
testing agent skills,
malicious skill files,
agent observability,
authorization for autonomous workflows,
production evaluation patterns.

I'm intentionally keeping the first issue relatively small.

I'd rather publish 12 strong resources than 40 average ones.

This is also an experiment

AI DevList is a small project.

The application itself is intentionally boring:

Next.js
PostgreSQL
Docker
GitLab CI/CD

The interesting problem isn't the software.

It's whether consistent technical curation can become useful enough that engineers return every week.

Over the next few months, I want to learn:

Which topics engineers actually click on?
Do people prefer research or practical engineering articles?
Are MCP resources still disproportionately interesting?
How much context is enough before curation becomes commentary?
Can a small, focused technical publication build a meaningful engineering audience?

I have added click analytics from the beginning so I can answer some of those questions with data instead of intuition.

If you're building AI systems

You can subscribe here:

👉 https://aidevlist.io/

The first issue comes out on August 23.

And if you publish a technical article, paper, open-source project or tool that you think AI engineers should see, there is also a submission page:

👉 https://aidevlist.io/submit

I'm especially interested in feedback from engineers:

What would make a curated AI engineering weekly genuinely useful enough for you to read every week?

QualityHub v1.2.0 — Your CI now posts quality reports directly on your MRs

Younes Ben Tlili — Wed, 25 Feb 2026 23:56:08 +0000

In my last article, I showed how qualityhub analyze gives you a risk score and go/no-go decision after every test run.
At the end, I mentioned this was coming:

Auto-commenting on MRs — qualityhub analyze --comment posts directly on your GitLab MR or GitHub PR

It's shipped. Here's what it looks like.

The problem with markdown reports
v1.1.0 already had --format markdown. You could generate a quality report and... do whatever you wanted with it. Most people saved it to a file and manually copied it somewhere.
That's one step too many.
The whole point of catching regressions is to surface them at the moment a developer is making a decision — when they're reviewing a merge request. Not buried in a CI log. Not in a separate tool. Right there, on the MR.

What v1.2.0 does
One flag. That's it.

qualityhub analyze --comment

Your CI runs, parses the test results, calculates the risk score, and posts this directly on your GitLab MR or GitHub PR:

The comment is automatically updated on every pipeline run. No duplicate comments piling up on your MR.

Setup: GitLab CI

quality-check:
  stage: test
  script:
    - npm test -- --coverage
    - npx qualityhub-cli parse jest ./coverage
    - npx qualityhub-cli analyze --comment
  cache:
    paths:
      - .qualityhub/   # history persists between runs → regression detection works
  only:
    - merge_requests

Set GITLAB_TOKEN as a CI/CD variable (needs api scope). Everything else — project ID, MR number — is auto-detected from GitLab's environment variables. No extra config.

Setup: GitHub Actions

- name: Run tests
  run: npm test -- --coverage

- name: QualityHub analysis
  run: |
    npx qualityhub-cli parse jest ./coverage
    npx qualityhub-cli analyze --comment
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

GITHUB_TOKEN is already available in every GitHub Actions workflow. Nothing to configure.

All the options
For teams with specific setups:

# Self-hosted GitLab
qualityhub analyze --comment \
  --api-url https://gitlab.yourcompany.com \
  --token $GITLAB_TOKEN

# Explicit project + MR (outside CI)
qualityhub analyze --comment \
  --provider gitlab \
  --token $GITLAB_TOKEN \
  --project-id 123 \
  --mr-id 42

# GitHub
qualityhub analyze --comment \
  --provider github \
  --token $GITHUB_TOKEN \
  --project-id owner/repo \
  --mr-id 42

Why this matters
When a comment appears directly on the MR, it changes the dynamic of code review.
Instead of "tests passed, let's merge", reviewers now see:

The exact risk score
Whether coverage went up or down vs the previous run
Any new test failures introduced by this branch
A clear PROCEED / CAUTION / BLOCK decision

The context is there at the moment the decision is made. Not one click away. Not in another tab. On the MR.
This is what I was trying to build when I started QualityHub: quality intelligence at the right moment.

Try it

npm install -g qualityhub-cli

# Parse your test results
qualityhub parse jest ./coverage

# Post on your MR
qualityhub analyze --comment

GitHub: ybentlili/qualityhub-cli
npm: qualityhub-cli
MIT licensed. If this is useful, a ⭐ on GitHub goes a long way.

Part 3 of building QualityHub in public. Part 1 — Part 2

I built a CLI that tells you if your release is safe to deploy — in 2 seconds

Younes Ben Tlili — Tue, 17 Feb 2026 22:53:38 +0000

Every team has the same moment before deploying:

"Tests passed... coverage looks okay... should we ship it?"

Someone eyeballs the numbers, checks if anything looks off, and says "yeah, let's go." No real process. No history. No way to catch a slow regression creeping in over weeks.
I got tired of that. So I built

qualityhub analyze

What it does
You run your tests. Then:

npx qualityhub-cli parse jest ./coverage
npx qualityhub-cli analyze

You get this:

🔍 QualityHub Analysis
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
   Project:  my-app@2.3.1
   Branch:   main

   📊 Tests
      ❌ 243/250 passed (97.2%)
      ❌ 4 failed
      ⏭️  3 skipped
      ⏱️  Duration: 12.7s

   📈 Coverage
      Lines:      █████████████████░░░ 87.3%  ▼ -3.2%
      Branches:   ████████████████░░░░ 82.2%
      Functions:  ██████████████████░░ 91.3%

   🚨 Issues Detected
      🟡 4 tests failed (97.2% pass rate)
      🎲 2 flaky tests detected
      📉 Coverage dropped 3.2% since last run
      🆕 2 new test failures since last run
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
   🎯 Risk Score:  ⚠️ 72/100 (MEDIUM RISK)
   📋 Decision:    ⚠️  CAUTION — Review issues before deploying
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

A risk score from 0 to 100. A clear decision: PROCEED, CAUTION, or BLOCK. In 2 seconds.

The problem I was solving
At my previous job, we had 20 projects across 5 teams. Quality tracking was done in Excel files. Every sprint, someone would manually collect metrics from each team — test pass rates, coverage percentages, SonarQube results — paste them into a spreadsheet, and email it around.
Nobody caught the slow regressions. Coverage would drop 0.5% per sprint, and after 6 months you'd realize you went from 85% to 70% without anyone noticing.
I wanted something that:

Runs in CI, not in someone's inbox
Compares every run with the previous one automatically
Catches what humans miss: slow drifts, new failures, build slowdowns
Gives a clear answer, not a dashboard you have to interpret

How the scoring works
The risk score starts at 100 and gets penalized:
Test results (40 points max)
Every failed test costs points. 2% failure rate? Small penalty. 10% failure rate? You're blocked.
Coverage (30 points max)
Below 80% line coverage? Penalty. Below 50%? Critical.
Regressions (15 points max)
This is where it gets interesting. The CLI stores history locally in .qualityhub/history.json. On every run, it compares with the last one:

Coverage dropped 3%? Flagged.
2 new test failures? Flagged.
Build time increased 20%? Flagged.

Issue severity (15 points max)
Critical issues (security vulnerabilities, quality gate failures) cost more than warnings.
The final score maps to a decision:

85-100: PROCEED ✅
65-84: CAUTION ⚠️
40-64: HIGH RISK 🔶
0-39: BLOCK 🛑

No server needed
This is the part I'm most proud of. Everything runs locally:

History is stored in .qualityhub/history.json
No account to create
No SaaS to connect
No API keys

Install and run:

npm install -g qualityhub-cli
qualityhub parse jest ./coverage
qualityhub analyze

That's it. Value in 30 seconds.

CI/CD integration
The CLI exits with code 1 when the decision is BLOCK. So you can use it as a quality gate:

# .gitlab-ci.yml
quality-check:
  stage: test
  script:
    - npm test -- --coverage
    - npx qualityhub-cli parse jest ./coverage
    - npx qualityhub-cli analyze
  cache:
    paths:
      - .qualityhub/

The cache persists the history between pipeline runs, so regression detection works across commits.

Markdown reports for merge requests
You can also generate a Markdown report to post on your MR:

qualityhub analyze --format markdown --output report.md

What's next
I'm working on:

Auto-commenting on MRs — qualityhub analyze --comment posts directly on your GitLab MR or GitHub PR
More parsers — pytest, XCTest, Go test
AI-powered insights — Using LLMs to explain why your quality is changing and what to fix first

Try it

npm install -g qualityhub-cli

# Or test with example data:
git clone https://github.com/ybentlili/qualityhub-cli
cd qualityhub-cli
npm install && npm run build && npm link
qualityhub parse jest ./examples/jest
qualityhub analyze

GitHub: ybentlili/qualityhub-cli
npm: qualityhub-cli
It's MIT licensed. Stars, feedback, and contributions are welcome.
If you've ever looked at a CI pipeline and thought "I think we can ship this" — this is for you.

I Built QualityHub: AI-Powered Quality Intelligence for Your Releases

Younes Ben Tlili — Sun, 01 Feb 2026 11:10:45 +0000

🎯 The Problem

As a developer , I faced this question every day:

"Can we ship this release to production?"

We had test results, coverage metrics, SonarQube reports... but no single source of truth to answer this simple question.

So I built QualityHub - an AI-powered platform that analyzes your quality metrics and gives you instant go/no-go decisions.

🚀 What is QualityHub?

QualityHub is an open-source quality intelligence platform that:

📊 Aggregates test results from any framework (Jest, JUnit, JaCoCo...)
🤖 Analyzes quality metrics with AI
✅ Decides if you can ship to production
📈 Tracks trends over time in a beautiful dashboard

The Stack

Backend: TypeScript + Express + PostgreSQL + Redis
Frontend: Next.js 14 + Tailwind CSS
CLI: TypeScript with parsers for Jest, JaCoCo, JUnit
Deployment: Docker Compose (self-hostable)
License: MIT

💡 How It Works

1. Universal Format: `qa-result.json`

Instead of forcing you to use specific tools, QualityHub uses an open standard format:

{
  "version": "1.0.0",
  "project": {
    "name": "my-app",
    "version": "2.3.1",
    "commit": "a3f4d2c",
    "branch": "main",
    "timestamp": "2026-01-31T14:30:00Z"
  },
  "quality": {
    "tests": {
      "total": 1247,
      "passed": 1245,
      "failed": 2,
      "skipped": 0,
      "duration_ms": 45230,
      "flaky_tests": ["UserAuthTest.testTimeout"]
    },
    "coverage": {
      "lines": 87.3,
      "branches": 82.1,
      "functions": 91.2
    }
  }
}

This format works with any test framework.

2. CLI Parsers

The CLI automatically converts your test results:

# Jest (JavaScript/TypeScript)
qualityhub parse jest ./coverage

# JaCoCo (Java)
qualityhub parse jacoco ./target/site/jacoco/jacoco.xml

# JUnit (Java/Kotlin/Python)
qualityhub parse junit ./build/test-results/test

3. Risk Analysis Engine

The backend analyzes your results and calculates a Risk Score (0-100):

// Risk factors analyzed:
- Test pass rate
- Code coverage (lines, branches, functions)
- Flaky tests
- Coverage trends
- Code quality metrics (if available)

Output:

{
  "risk_score": 85,
  "status": "SAFE",
  "decision": "PROCEED",
  "reasoning": "Test pass rate: 99.8%. Coverage: 87.3%. No critical issues.",
  "recommendations": []
}

4. Beautiful Dashboard


![ ](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/zx8uj4p9okks9a4ohq7h.png)

Track metrics over time, see trends, and make informed decisions.

🔧 Quick Start

Self-Hosted (5 minutes)

# Clone repo
git clone https://github.com/ybentlili/qualityhub.git
cd qualityhub

# Start everything with Docker
docker-compose up -d

# ✅ Backend: http://localhost:8080
# ✅ Frontend: http://localhost:3000

Use the CLI

# Install
npm install -g qualityhub-cli

# Initialize
qualityhub init

# Parse your test results
qualityhub parse jest ./coverage

# Push to QualityHub
qualityhub push qa-result.json

Done! Your metrics appear in the dashboard instantly.

🎨 Why I Built This

The Pain Points

Fragmented Tools: Jest for tests, JaCoCo for coverage, SonarQube for quality... each tool has its own UI and format.
No Single Answer: "Can we ship?" required checking 5 different tools and making a gut decision.
No History: Hard to track quality trends over time.
Manual Process: No automation, no CI/CD integration.

The Solution

QualityHub aggregates everything into one dashboard and uses AI to make the decision for you.

🏗️ Architecture

┌─────────────┐
│     CLI     │ ← Parse test results
└──────┬──────┘
       │ POST /api/v1/results
       ↓
┌─────────────────────────────┐
│     Backend (API)           │
│  • Express + TypeScript     │
│  • PostgreSQL + Redis       │
│  • Risk Analysis Engine     │
└──────────────┬──────────────┘
               │
               ↓
┌─────────────────────────────┐
│   Frontend (Dashboard)      │
│  • Next.js 14               │
│  • Real-time metrics        │
└─────────────────────────────┘

📊 Technical Deep Dive

1. The Parser Architecture

Each parser extends a base class:

export abstract class BaseParser {
  abstract parse(filePath: string): Promise;

  protected buildBaseResult(adapterName: string) {
    return {
      version: '1.0.0',
      project: {
        name: this.projectInfo.name,
        commit: process.env.GIT_COMMIT || 'unknown',
        // Auto-detect CI/CD environment
        timestamp: new Date().toISOString(),
      },
      metadata: {
        ci_provider: this.detectCIProvider(),
        adapters: [adapterName],
      },
    };
  }
}

This makes adding new parsers trivial. Want pytest support? Extend BaseParser and implement parse().

2. Risk Scoring Algorithm (MVP)

The current version uses rule-based scoring:

let score = 100;

// Test failures
if (tests.failed > 0) {
  score -= tests.failed * 5;
}

// Coverage thresholds
if (coverage.lines < 70) {
  score -= 15;
}

// Flaky tests
if (flakyTests.length > 0) {
  score -= flakyTests.length * 3;
}

// Ensure 0-100 range
score = Math.max(0, Math.min(100, score));

Future: Replace with AI-powered analysis (Claude API) for contextual insights.

3. Database Schema

Simple and efficient:

CREATE TABLE projects (
    id UUID PRIMARY KEY,
    name VARCHAR(255) UNIQUE NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

CREATE TABLE qa_results (
    id UUID PRIMARY KEY,
    project_id UUID REFERENCES projects(id),
    version VARCHAR(50),
    commit VARCHAR(255),
    branch VARCHAR(255),
    timestamp TIMESTAMP,
    metrics JSONB,  -- Flexible JSON storage
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

CREATE TABLE risk_analyses (
    id UUID PRIMARY KEY,
    qa_result_id UUID REFERENCES qa_results(id),
    risk_score INTEGER,
    status VARCHAR(50),
    reasoning TEXT,
    risks JSONB,
    recommendations JSONB,
    decision VARCHAR(50)
);

JSONB allows flexible metric storage without schema migrations.

🚀 What's Next?

v1.1 (Planned)

🤖 AI-Powered Analysis with Claude API
📊 Trend Detection (coverage dropping over time)
🔔 Slack/Email Notifications
🔌 GitHub App (comments on PRs)

v1.2 (Future)

📈 Advanced Analytics (benchmarking, predictions)
🔐 SSO & RBAC for enterprise
🌍 Multi-language support
🎨 Custom dashboards

💡 Lessons Learned

1. Open Standards Win

Making qa-result.json an open standard was key. Now anyone can build parsers or integrations.

2. Developer Experience Matters

The CLI must be dead simple:

qualityhub parse jest ./coverage  # Just works

No config files, no setup, just works.

3. Self-Hosting is a Feature

Many companies can't send their metrics to external SaaS. Docker Compose makes self-hosting trivial.

🤝 Contributing

QualityHub is 100% open-source (MIT License).

Want to contribute?

🧪 Add parsers (pytest, XCTest, Rust...)
🎨 Improve the dashboard
🐛 Fix bugs
📚 Write docs

Check out: Contributing Guide

🔗 Links

GitHub: ybentlili/qualityhub
CLI: qualityhub-cli
npm: qualityhub-cli

🎯 Try It Now

# Self-host in 5 minutes
git clone https://github.com/ybentlili/qualityhub.git
cd qualityhub
docker-compose up -d

# Or just the CLI
npm install -g qualityhub-cli
qualityhub parse jest ./coverage

💬 What do you think?

Would you use this? What features would you like to see?

Drop a ⭐ on GitHub if you find this useful!

Built with ❤️ in TypeScript