generated from coulomb/repo-seed
110 lines
4.2 KiB
Markdown
110 lines
4.2 KiB
Markdown
---
|
|
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"
|
|
state_hub_workstream_id: "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
|
|
|
|
```task
|
|
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
|
|
|
|
```task
|
|
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
|
|
|
|
```task
|
|
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.
|