3.3 KiB
id, type, title, domain, repo, status, owner, topic_slug, created, updated
| id | type | title | domain | repo | status | owner | topic_slug | created | updated |
|---|---|---|---|---|---|---|---|---|---|
| RREG-WP-0016 | workplan | Native Candidate Generation Recovery | capabilities | repo-scoping | active | codex | foerster-capabilities | 2026-05-15 | 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
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
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
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.