Skip to content

fix(agent-runtime): route structural-review skill via canonical 'evidence' kind (GT-535)#184

Merged
beyondnetPeru merged 1 commit into
developfrom
fix/gt-535-evidence-kind
Jul 14, 2026
Merged

fix(agent-runtime): route structural-review skill via canonical 'evidence' kind (GT-535)#184
beyondnetPeru merged 1 commit into
developfrom
fix/gt-535-evidence-kind

Conversation

@beyondnetPeru

Copy link
Copy Markdown
Contributor

Problem

An agentic review flagged that the GT-535 skill code-quality-structural-review (default-skills.ts:88) declared evaluationKinds: ['code-quality'], but buildEvaluationContext only forwards kinds present in its KNOWN_KINDS allowlist — and 'code-quality' is not a member of the core-domain EvaluationKind union at all. It is a quality-signal dimension (the tag StructuralReviewProvider puts on the Evidence it emits: SUPPORTED_DIMENSIONS = {'code-quality','structure','maintainability'}).

Result: the declared kind was silently filtered out and the EvaluationContext fell back to ['gate']. The skill was declared but never routed as the quality-signal evaluation it is — so the GT-535 StructuralReviewProvider (which emits probabilistic Evidence for the Quality Gate) was unreachable through the runtime path.

Investigation

  • Canonical set — EvaluationKind union (evaluation-context.ts:24): gate | artifact | evidence | architecture | blueprint | topology | checkpoint | deployment | rule | compliance | design | phase-artifacts. No code-quality.
  • The KNOWN_KINDS allowlist in context-mapper.ts had also drifted — it was additionally missing the canonical design and phase-artifacts.
  • The structural Evidence reaches the Core via EvaluationContext.qualitySignals and is folded unconditionally (foldQualitySignals), tagged with the code-quality dimension — confirming code-quality is 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.

  • default-skills.tsevaluationKinds: ['code-quality']['evidence'], with a note that code-quality stays where it belongs: the emitted Evidence's dimension.
  • context-mapper.ts — sync KNOWN_KINDS to the full canonical union (add design, phase-artifacts) + maintenance comment, so the same "declared-but-dropped" class can't recur.
  • structural-review.spec.ts — routing guard: the skill forwards evidence through buildEvaluationContext (not the gate fallback), and a dimension-shaped kind still collapses to ['gate'].

Scope

Kind routing only. GT-535's concrete IStructuralReviewer LLM adapter is a separate follow-on; this makes the wiring correct for when it lands.

Verification

  • agent-runtime jest: 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

…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>
@github-actions

Copy link
Copy Markdown

📊 Bilingual Coverage Impact

PR Changes

  • Paired EN/ES files modified: 2
  • New EN files needing ES translation: 0

Repository Coverage

Metric Value
Total EN files 545
Total ES files 508
Paired files 0
Coverage 0%

Good: All EN changes have ES counterparts.


Generated by GitHub Actions

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 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'],

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge 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 👍 / 👎.

@beyondnetPeru beyondnetPeru merged commit d4fc4ad into develop Jul 14, 2026
15 checks passed
@beyondnetPeru beyondnetPeru deleted the fix/gt-535-evidence-kind branch July 14, 2026 02:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant