fix(agent-runtime): route structural-review skill via canonical 'evidence' kind (GT-535)#184
Conversation
…ence' kind (GT-535) The `code-quality-structural-review` skill declared `evaluationKinds: ['code-quality']`, but 'code-quality' is a quality-signal DIMENSION (the tag on the Evidence StructuralReviewProvider emits), NOT a member of the core-domain `EvaluationKind` union. `buildEvaluationContext` filters declared kinds against a KNOWN_KINDS allowlist, so 'code-quality' was silently dropped and the context fell back to `['gate']` — the skill was declared but never routed as the quality-signal evaluation it is, leaving the GT-535 provider unreachable. Fix (map onto an existing supported kind, not forge a phantom one): - default-skills.ts: `evaluationKinds: ['code-quality']` -> `['evidence']`, the canonical kind for declared quality-signal Evidence (ADR-0111 / GT-533). The 'code-quality' dimension stays where it belongs — on the emitted Evidence. - context-mapper.ts: sync the KNOWN_KINDS allowlist to the full canonical `EvaluationKind` union (add 'design', 'phase-artifacts') with a maintenance note, so the same "declared-but-dropped" class can't recur for those kinds. - structural-review.spec.ts: add a routing guard proving the skill forwards 'evidence' through buildEvaluationContext (not the 'gate' fallback), and that a dimension-shaped kind still collapses to ['gate']. Kind routing only; the concrete IStructuralReviewer LLM adapter is a separate follow-on. agent-runtime jest green (17 suites / 121 tests), tsc --noEmit clean. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
📊 Bilingual Coverage ImpactPR Changes
Repository Coverage
✅ Good: All EN changes have ES counterparts. Generated by GitHub Actions |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e35459875b
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| // StructuralReviewProvider stays reachable when the IStructuralReviewer adapter lands. | ||
| kind: 'evaluation', | ||
| evaluationKinds: ['code-quality'], | ||
| evaluationKinds: ['evidence'], |
There was a problem hiding this comment.
Populate qualitySignals before routing structural review
When the default structural_review skill is invoked, this change only sends kinds: ['evidence'] to Core; the runtime path just calls buildEvaluationContext(...) and coreEvaluation.evaluate(...) (agent-runtime.service.ts:269-270), while Core folds only ctx.qualitySignals (evaluation-orchestrator.service.ts:63) and has no evidence evaluator. Because buildEvaluationContext never collects or attaches the StructuralReviewProvider output, the structural-review request still evaluates with no code-quality evidence and never applies the structural gate, so the advertised review remains unreachable for this default skill.
Useful? React with 👍 / 👎.
Problem
An agentic review flagged that the GT-535 skill
code-quality-structural-review(default-skills.ts:88) declaredevaluationKinds: ['code-quality'], butbuildEvaluationContextonly forwards kinds present in itsKNOWN_KINDSallowlist — and'code-quality'is not a member of the core-domainEvaluationKindunion at all. It is a quality-signal dimension (the tagStructuralReviewProviderputs on theEvidenceit emits:SUPPORTED_DIMENSIONS = {'code-quality','structure','maintainability'}).Result: the declared kind was silently filtered out and the
EvaluationContextfell back to['gate']. The skill was declared but never routed as the quality-signal evaluation it is — so the GT-535StructuralReviewProvider(which emits probabilisticEvidencefor the Quality Gate) was unreachable through the runtime path.Investigation
EvaluationKindunion (evaluation-context.ts:24):gate | artifact | evidence | architecture | blueprint | topology | checkpoint | deployment | rule | compliance | design | phase-artifacts. Nocode-quality.KNOWN_KINDSallowlist in context-mapper.ts had also drifted — it was additionally missing the canonicaldesignandphase-artifacts.EvaluationContext.qualitySignalsand is folded unconditionally (foldQualitySignals), tagged with thecode-qualitydimension — confirmingcode-qualityis a dimension, not a kind.Fix — option (b): map onto an existing supported kind
Adding
'code-quality'to the allowlist (option a) would forge a phantom kind the Core can't dispatch. The correct, most-specific canonical kind for declared quality-signal Evidence is'evidence'(ADR-0111 / GT-533), already in the allowlist.evaluationKinds: ['code-quality']→['evidence'], with a note thatcode-qualitystays where it belongs: the emitted Evidence's dimension.KNOWN_KINDSto the full canonical union (adddesign,phase-artifacts) + maintenance comment, so the same "declared-but-dropped" class can't recur.evidencethroughbuildEvaluationContext(not thegatefallback), and a dimension-shaped kind still collapses to['gate'].Scope
Kind routing only. GT-535's concrete
IStructuralReviewerLLM adapter is a separate follow-on; this makes the wiring correct for when it lands.Verification
agent-runtimejest: 17 suites / 121 tests green (run in an isolated worktree on the current develop base).tsc --noEmit: clean.Does not touch
reference/core/control-center/gaps/**.🤖 Generated with Claude Code