repo-scoping/workplans/RREG-WP-0002-production-hardening.md

id, type, title, domain, repo, status, owner, topic_slug, created, updated, state_hub_workstream_id

id	type	title	domain	repo	status	owner	topic_slug	created	updated	state_hub_workstream_id
RREG-WP-0002	workplan	Repository Ability Registry — Production Hardening	capabilities	repo-registry	done	codex	foerster-capabilities	2026-04-26	2026-04-26	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

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

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

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

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

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

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)

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.