---
id: RREG-WP-0002
type: workplan
title: "Repository Ability Registry — Production Hardening"
domain: capabilities
repo: repo-registry
status: done
owner: codex
topic_slug: foerster-capabilities
created: "2026-04-26"
updated: "2026-04-26"
state_hub_workstream_id: "4218d2bb-33e8-4f98-94ba-38b4ac21502d"
---

# RREG-WP-0002 — Production Hardening

## Goal

Improve trust, search quality, update safety, and operational readiness after MVP
closure. Core invariant remains: observed facts are deterministic; interpreted claims
are reviewable; approved registry truth is explicit.

## P0: Update Safety and Change Review

```task
id: RREG-WP-0002-T01
status: done
priority: high
state_hub_task_id: "a27142a6-c160-4453-ab59-50a7db92f9c4"
```

Analysis-run diff model for facts/chunks/candidates/approved entries. API endpoint to
compare two runs. UI review view for changed/added/removed/weakened claims. Review
decisions that record change acceptance/rejection. Tests proving approved profiles
remain stable until changes are approved.

Candidate endpoints:
- `GET /repos/{id}/analysis-runs/{base}/diff/{target}`
- `POST /repos/{id}/analysis-runs/{target}/changes/approve`

## P1: Search Quality and Semantic Retrieval

```task
id: RREG-WP-0002-T02
status: done
priority: medium
state_hub_task_id: "0e7cce78-13ab-4aa2-8d25-ae50ff8ccd74"
```

Embedding abstraction for approved entries and content chunks. Local/offline fake
provider for tests. Optional pgvector path without breaking SQLite dev mode. Hybrid
ranking combining text match, filters, confidence, and vector score. Existing text
search behavior must remain stable.

## P1: Discovery UI

```task
id: RREG-WP-0002-T03
status: done
priority: medium
state_hub_task_id: "aee945eb-ea25-49f7-b755-4ec451c1d05a"
```

Repository comparison screen. Capability-gap input and report screen. Export action
from repository profile. Clear empty states for repos without approved profiles.
Acceptance: user can compare approved repos, enter desired capabilities, and export
without raw API calls.

## P1: Fixture Breadth and Regression Confidence

```task
id: RREG-WP-0002-T04
status: done
priority: medium
state_hub_task_id: "d1df6453-3bca-4524-85d1-9b3f3f275b45"
```

E2E tests for: README-only repos, Python CLI repos, JavaScript/TypeScript packages,
repos with weak or misleading docs, negative cases for unsupported/empty repos.
Acceptance: conservative candidate extraction when docs are weak; misleading docs
do not become approved truth without review.

## P2: Operational Readiness

```task
id: RREG-WP-0002-T05
status: done
priority: low
state_hub_task_id: "44b10491-f1f2-4e2e-9a8e-e8bd59cbf892"
```

Structured logging around ingestion, analysis, LLM extraction, and review actions.
Configuration documentation. Basic health details for DB and checkout root. Backup/
restore guidance for SQLite deployments. Migration strategy notes for PostgreSQL.

## P2: API Contract Stability

```task
id: RREG-WP-0002-T06
status: done
priority: low
state_hub_task_id: "271a4fc4-d966-40ef-bc6f-a5fd1c445a16"
```

Versioned API path or explicit compatibility policy. Golden OpenAPI snapshot test or
schema-diff check. More response examples for discovery and change-review endpoints.
Error response schema for common 400/404 cases. Acceptance: breaking changes are
deliberate and visible in tests; agent-facing endpoints have stable models.

## Schema migration guard for vocabulary_ref (EP-CAP-003)

```task
id: RREG-WP-0002-T07
status: done
priority: medium
state_hub_task_id: "6f06d8bb-0ed9-47f1-8b3e-40f725e6ece6"
```

Audit the `ApprovedAbility` and `ApprovedCapability` (and `ApprovedFeature`) name
fields to ensure no constraints would make adding a future nullable `vocabulary_ref`
column a painful migration. Specifically verify:

- No CHECK constraints that assume name is the sole identity of an ability/capability
- No unique indexes on name alone (name + vocabulary_ref will be the future key)
- No foreign keys from other tables pointing at name as a natural key
- `ReviewDecision` records reference row IDs, not name strings

This is a guard task, not an implementation task — no new columns needed now. The
goal is to confirm the v0.1 schema leaves the door open. Document the finding in
a short ADR note or inline comment.

Context: EP-CAP-003 (Custodian State Hub, capabilities domain) — capability names
are free-text in v0.1 but will eventually need anchoring to a named vocabulary
version as terminology standardises from local ontology toward domain standard and
commodity specification. EP-CAP-002 documents the related constraint that SBOM
evidence can only corroborate or contradict capability claims, never generate them;
the confidence scoring model will need named evidence factors when SBOM
cross-referencing is added.