generated from coulomb/repo-seed
101 lines
6.6 KiB
JSON
101 lines
6.6 KiB
JSON
{
|
|
"schema_version": "quality-criteria-registry/v1",
|
|
"criteria_version": "repo-scoping-quality-criteria/v1",
|
|
"status": "active",
|
|
"updated_at": "2026-05-15",
|
|
"criteria": [
|
|
{
|
|
"id": "RREG-QC-001",
|
|
"title": "Source Role Supports The Claim",
|
|
"category": "source-role-quality",
|
|
"severity": "medium",
|
|
"applies_to": ["ability", "capability", "feature", "evidence"],
|
|
"description": "Candidate claims need evidence whose source role can support the abstraction. Intent docs, implementation source, API surfaces, and product documentation carry stronger claim support than fixtures, schema examples, tests, agent instructions, generated scope text, dependency manifests, or incidental vocabulary.",
|
|
"deterministic_action": "requires_review",
|
|
"deterministic_action_when": "All supporting refs are weak source roles such as fixture, schema-example, generated-scope, dependency, test-vocabulary, or agent-guidance.",
|
|
"reviewer_guidance": "Check whether any cited source actually expresses product intent or implementation behavior for the candidate, not merely matching words.",
|
|
"agentic_guidance": "Do not approve when evidence only proves scanner vocabulary, test coverage, examples, or dependency presence.",
|
|
"examples": [
|
|
"Provider names in tests can prove scanner coverage but not a native provider-routing capability.",
|
|
"A FastAPI route in source can support an API feature when it belongs under the right capability."
|
|
]
|
|
},
|
|
{
|
|
"id": "RREG-QC-002",
|
|
"title": "Native Utility Is Repo-Owned",
|
|
"category": "native-utility",
|
|
"severity": "high",
|
|
"applies_to": ["ability", "capability"],
|
|
"description": "Owned, facade, and adapter claims require explicit product evidence. Dependency, tooling, configuration, fixture, schema-example, and mention-only contexts are not native repository capabilities.",
|
|
"deterministic_action": "downgraded",
|
|
"deterministic_action_when": "The candidate is supported primarily by dependency, configuration, tooling, fixture, schema-example, or mention-only evidence.",
|
|
"reviewer_guidance": "Decide whether the repository exposes this utility as its own behavior or merely uses, tests, configures, or mentions another system.",
|
|
"agentic_guidance": "Approve only when product intent and implementation evidence show the repo owns the user-facing utility.",
|
|
"examples": [
|
|
"Using llm-connect as extraction infrastructure does not make repo-scoping an LLM router.",
|
|
"A repository that exposes a scope context API owns that context API capability."
|
|
]
|
|
},
|
|
{
|
|
"id": "RREG-QC-003",
|
|
"title": "Feature Fits Parent Capability",
|
|
"category": "hierarchy-fit",
|
|
"severity": "high",
|
|
"applies_to": ["feature"],
|
|
"description": "Features must support the parent capability they are nested under. API, CLI, UI, storage, and backend features should not be attached to unrelated capabilities just because evidence was discovered nearby.",
|
|
"deterministic_action": "requires_review",
|
|
"deterministic_action_when": "Feature type, name, or source refs conflict with the parent capability class or native-utility claim.",
|
|
"reviewer_guidance": "Move or relink features to the capability they actually support before approval.",
|
|
"agentic_guidance": "Prefer relinking or proposing hierarchy edits over approving a mismatched parent-child relationship.",
|
|
"examples": [
|
|
"HTTP API and CLI surfaces should not be nested below provider-routing when they describe repo-scoping registry operations."
|
|
]
|
|
},
|
|
{
|
|
"id": "RREG-QC-004",
|
|
"title": "Evidence Supports The Abstraction",
|
|
"category": "evidence-sufficiency",
|
|
"severity": "high",
|
|
"applies_to": ["ability", "capability", "feature", "evidence"],
|
|
"description": "Evidence must support the actual abstraction claimed by the candidate, not just share vocabulary with it. Claims need enough source refs to justify the level of abstraction.",
|
|
"deterministic_action": "requires_review",
|
|
"deterministic_action_when": "Source refs are absent, too vague, or only vocabulary matches for the candidate name.",
|
|
"reviewer_guidance": "Trace each source ref to the claim. Reject or rewrite candidates whose evidence only supports a narrower or different behavior.",
|
|
"agentic_guidance": "Name the exact evidence inspected and explain how it supports or fails to support the claim.",
|
|
"examples": [
|
|
"A provider registry constant can support scanner fixture detection, not necessarily provider routing as product behavior."
|
|
]
|
|
},
|
|
{
|
|
"id": "RREG-QC-005",
|
|
"title": "Generated Scope Is Not Primary Proof",
|
|
"category": "circularity",
|
|
"severity": "critical",
|
|
"applies_to": ["ability", "capability", "feature", "evidence"],
|
|
"description": "Generated SCOPE.md text cannot be primary evidence for rebuilding the same characteristic model. It may be comparison context, bootstrap context, or a generated output under review.",
|
|
"deterministic_action": "rejected",
|
|
"deterministic_action_when": "A candidate is supported only or primarily by generated SCOPE.md content from the same scoping process.",
|
|
"reviewer_guidance": "Use source, docs, tests, and product intent instead of accepting circular evidence.",
|
|
"agentic_guidance": "Treat circular generated-scope evidence as a blocker unless independent evidence supports the same claim.",
|
|
"examples": [
|
|
"Do not use repo-scoping's generated SCOPE.md as the main proof for repo-scoping's own ability tree."
|
|
]
|
|
},
|
|
{
|
|
"id": "RREG-QC-006",
|
|
"title": "Fixtures And Schemas Do Not Become Product Claims",
|
|
"category": "fixture-contamination",
|
|
"severity": "high",
|
|
"applies_to": ["ability", "capability", "feature", "evidence"],
|
|
"description": "Tests, fixtures, schemas, examples, and expectation files can prove scanner behavior or API contract examples, but they should not become native product capability claims unless backed by product or implementation evidence.",
|
|
"deterministic_action": "downgraded",
|
|
"deterministic_action_when": "The claim is primarily supported by tests, fixtures, schemas, examples, expectation files, or sample vocabulary.",
|
|
"reviewer_guidance": "Keep scanner/test coverage facts separate from repository capability truth.",
|
|
"agentic_guidance": "Reject or downgrade candidates that turn examples and fixtures into owned utility.",
|
|
"examples": [
|
|
"Schema examples mentioning model providers should not create native model-provider capabilities."
|
|
]
|
|
}
|
|
]
|
|
}
|