Capture clean self-assessment regression signal

workplans/RREG-WP-0016-native-candidate-generation-recovery.md

@@ -0,0 +1,95 @@
+---
+id: RREG-WP-0016
+type: workplan
+title: "Native Candidate Generation Recovery"
+domain: capabilities
+repo: repo-scoping
+status: active
+owner: codex
+topic_slug: foerster-capabilities
+created: "2026-05-15"
+updated: "2026-05-15"
+---
+
+# 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
+
+```task
+id: RREG-WP-0016-T01
+status: todo
+priority: high
+```
+
+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
+
+```task
+id: RREG-WP-0016-T02
+status: todo
+priority: high
+```
+
+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
+
+```task
+id: RREG-WP-0016-T03
+status: todo
+priority: high
+```
+
+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.