coulomb/repo-scoping
Archived
2
0
Fork 0
generated from coulomb/repo-seed
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Constrain provider vocabulary candidate promotion

Browse Source
This commit is contained in:
Bernd Worsch
2026-05-15 17:29:07 +02:00
parent d44d50f623
commit 324fbb3745
3 changed files with 61 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -32,7 +32,7 @@ This workplan is deliberately about generation quality, not acceptance policy.
```task
id: RREG-WP-0016-T01
status: todo
status: done
priority: high
state_hub_task_id: "0e65e301-aba6-4720-a4bd-481eebf1b63f"
```
@@ -48,6 +48,16 @@ Acceptance criteria:
- 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