Service Registry

The Service Registry connects VigilQA to your backend service repositories so the CoverageGap agent can prioritise gaps based on what actually changed in your codebase — not just what exists in the KB.

How it works

When a registered service reports changed files or symbols, VigilQA injects that change context into the CoverageGap agent's prompt. The agent then weights gaps by impact: scenarios that touch changed services are surfaced first, and the output includes an affected_service field so you know which service triggered the gap.

Approved coverage gap suggestions are automatically written as KB increment YAML files, ready to trigger a new generation pipeline run.

Source modes

Each service in the registry can use one of three source modes:

Mode	How changes are detected	Best for
git	VigilQA polls the git remote for new commits on the tracked branch	Teams where VigilQA can reach the git remote directly
webhook	Your CI/CD pipeline POSTs a change report to POST /api/coverage/ingest after each push	Teams where VigilQA is on a private network or git credentials can't be shared
manifest	CI writes a YAML/JSON drop file at a configured path; VigilQA reads it on each check cycle	Fully air-gapped environments with no HTTP connectivity between CI and VigilQA

service_registry.yaml schema

Create ai/knowledge_base/<product>/service_registry.yaml (or edit it from Knowledge Base → Backend Services in the dashboard).

check_interval_hours: 6   # 0 = manual-only

services:
  - name: auth-service
    description: Authentication and session management
    source_mode: webhook    # git | webhook | manifest
    domains: [web, api]     # which test domains care about this service

  - name: products-api
    description: Product catalog and inventory API
    source_mode: git
    repo_path: /path/to/products-api   # local clone path (git mode only)
    branch: main
    auto_fetch: true                    # run git fetch before diff check
    auth:
      type: pat                         # none | pat | ssh
      env_var: PRODUCTS_API_PAT         # PAT read from this env var at runtime
    domains: [api, contract]

  - name: frontend
    description: React frontend
    source_mode: manifest
    manifest_path: /data/ci-drops/frontend-changes.yaml
    domains: [web, visual]

Webhook mode — CI setup

In webhook mode, your CI pipeline sends a change report to VigilQA after each push. Authenticate with a runner token (the same token type used by the remote runner).

# Example: curl from GitHub Actions / GitLab CI
curl -s -X POST https://app.sentinelflux.in/api/coverage/ingest \
  -H "Authorization: Bearer $SENTINELFLUX_RUNNER_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "service": "auth-service",
    "commit_sha": "'$GITHUB_SHA'",
    "changed_files": ["src/auth/login.py", "src/auth/session.py"],
    "changed_symbols": [
      {"file": "src/auth/login.py", "type": "function", "name": "validate_credentials"},
      {"file": "src/auth/session.py", "type": "class", "name": "SessionManager"}
    ],
    "diff_summary": "Add rate limiting to login endpoint"
  }'

Manifest mode — drop file format

In manifest mode, CI writes a file at the configured manifest_path. VigilQA reads and deduplicates on commit_sha.

# YAML format (JSON also accepted)
commit_sha: abc123def456
changed_files:
  - src/products/catalog.py
  - src/products/search.py
changed_symbols:
  - file: src/products/catalog.py
    type: function
    name: get_product_by_sku
diff_summary: "Add SKU-based product lookup"

Managing services from the dashboard

The Knowledge Base → Backend Services card shows each registered service with its last-checked timestamp and status. From there you can:

• Add or remove services without editing YAML directly
• Trigger a manual check for one service (Check Now) or all services (Check All)
• See which domains are watching each service