repo-scoping/workplans/RREG-WP-0016-native-candidate-generation-recovery.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-0016	workplan	Native Candidate Generation Recovery	capabilities	repo-scoping	active	codex	foerster-capabilities	2026-05-15	2026-05-15	088c5674-8edb-447b-8fb5-2a7a34d85ba1

Native Candidate Generation Recovery

WP0014 fixed the acceptance boundary: deterministic rules no longer promote bad candidates into approved registry truth. WP0015 fixed the self-assessment input set so repo-scoping no longer analyzes runtime checkouts as if they were native source.

The clean post-WP0015 challenger still fails the golden profile. It produces one candidate capability, Route LLM Requests Across Providers, and nests native API/CLI surfaces below that false provider-routing capability. Quality gates now flag this correctly (RREG-QC-002, RREG-QC-003) and the approved map remains empty, but candidate generation still needs to recover the repo's real native capabilities.

This workplan is deliberately about generation quality, not acceptance policy.

T01: Separate Provider Vocabulary From Native Capability Seeds

id: RREG-WP-0016-T01
status: todo
priority: high
state_hub_task_id: "0e65e301-aba6-4720-a4bd-481eebf1b63f"

Update deterministic candidate generation so LLM-provider facts and credential configuration are never enough to create the parent capability for a repository unless supported by owned product intent/source.

Acceptance criteria:

• Provider vocabulary can remain evidence or a low-level observed fact.
• Provider vocabulary does not become the dominant parent capability for repo-scoping's own self-assessment.
• Existing llm-connect-like fixtures that truly model provider adapters remain explainable through source-role metadata.

T02: Generate Native Repo-Scoping Candidate Families

id: RREG-WP-0016-T02
status: todo
priority: high
state_hub_task_id: "3db9742c-43fd-48ec-bcb7-13034f8c3f2e"

Use intent, docs, source, tests, and schema files to generate repo-scoping's expected native candidate families instead of a single provider-routing bucket.

Initial expected families:

• repository registration and metadata import
• deterministic repository scanning and observed facts
• provenance-aware content indexing
• reviewable candidate characteristic generation
• candidate review/edit/reject/merge/relink/approval workflow
• approved profile search, comparison, export, and gap exploration
• SCOPE.md generation, diffing, validation, and write flows
• dependency graph and impact exploration
• scope context API for downstream agents

Acceptance criteria:

• Clean self-assessment matches at least a meaningful subset of the golden expected capabilities.
• API and CLI features attach under native workflow candidates, not provider routing.
• Candidate source refs cite repo-owned docs/source/tests instead of schema examples or dependency vocabulary alone.

T03: Re-Run Clean Self-Assessment And Compare

id: RREG-WP-0016-T03
status: todo
priority: high
state_hub_task_id: "9ae662c0-3858-4c7d-b06e-26e1c8da7921"

After generator improvements, rerun the clean deterministic self-assessment and compare it to the golden profile and the post-WP0015 rejected challenger.

Acceptance criteria:

• The forbidden provider-routing candidate is absent or isolated as rejected / requires-review evidence rather than a native capability.
• The comparison report shows matched expected capabilities.
• Remaining gaps are captured as generator follow-up, golden-profile update, or human review notes.