23 lines
1.5 KiB
Markdown
23 lines
1.5 KiB
Markdown
# diagnosis-eval-demo-gatekeeper-closure Evidence
|
|
|
|
## Code And Artifact Evidence
|
|
|
|
- Gatekeeper rule metadata lives in `src/main/resources/gatekeeper/gatekeeper-rules.json`.
|
|
- `ExecutorGatekeeperService` loads the local catalog, uses configured threshold parameters, and emits `rule_set_version` plus enabled rule metadata.
|
|
- `VerifierInputHook` and `ChatService` preserve Gatekeeper audit metadata in fallback/default paths.
|
|
- `DiagnosisTraceEvaluator` can optionally validate expected Gatekeeper rule set version.
|
|
- `mvp/eval/cases/diagnosis-cases.json` now includes narrow-scope and no-evidence matrix cases.
|
|
- `mvp/eval/reports/baseline-report.json` and `.md` were regenerated for the expanded fixed matrix.
|
|
- `mvp/demo/evidence-pipeline-scenarios.md` documents 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_result` structure.
|
|
|
|
## 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`.
|