1.5 KiB
1.5 KiB
diagnosis-eval-demo-gatekeeper-closure Evidence
Code And Artifact Evidence
- Gatekeeper rule metadata lives in
src/main/resources/gatekeeper/gatekeeper-rules.json. ExecutorGatekeeperServiceloads the local catalog, uses configured threshold parameters, and emitsrule_set_versionplus enabled rule metadata.VerifierInputHookandChatServicepreserve Gatekeeper audit metadata in fallback/default paths.DiagnosisTraceEvaluatorcan optionally validate expected Gatekeeper rule set version.mvp/eval/cases/diagnosis-cases.jsonnow includes narrow-scope and no-evidence matrix cases.mvp/eval/reports/baseline-report.jsonand.mdwere regenerated for the expanded fixed matrix.mvp/demo/evidence-pipeline-scenarios.mddocuments live vs fixture-backed demo scenarios.
Decisions
- Keep this phase internal: no public API, no DB schema, no Planner output change.
- Keep Gatekeeper deterministic Java validation; the catalog is metadata/config only.
- Treat live demo as compatibility evidence and fixture-backed eval as deterministic regression evidence.
- Persist audit under the existing
self_evaluation.verifier_evaluation.gatekeeper_resultstructure.
Runtime Finding
The first Maven E2E startup found a real integration issue: ExecutorGatekeeperService had multiple public constructors without an annotated constructor, so Spring could not instantiate the service. The fix was to annotate the production constructor with @Autowired.