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: done
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.

Implementation note 2026-05-15: narrowed deterministic LLM-provider capability promotion to facts classified as utility-facade or utility-adapter; generic owned implementation vocabulary such as scanner constants, normalization tables, and API schemas now remains observed fact material. Added regression coverage proving owned provider vocabulary does not create Route LLM Requests Across Providers while adapter-like provider fixtures still can. A throwaway self-assessment preview moved repo-scoping from regression to needs_review: the forbidden provider-routing candidate disappeared and the remaining generated candidate is Expose Repository Interface.

T02: Generate Native Repo-Scoping Candidate Families

id: RREG-WP-0016-T02
status: done
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.

Implementation note 2026-05-15: added repo-scoping native capability seeds derived from owned path clusters across docs, tests, source, and API/CLI interfaces. The generator now emits the nine expected repo-scoping candidate families instead of a single generic interface bucket. A throwaway self-assessment preview reached candidate_improvement: all golden expected capabilities matched, the provider-routing forbidden capability stayed absent, and no misplaced API/CLI features were reported.

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.