34 lines
1.8 KiB
Markdown
34 lines
1.8 KiB
Markdown
# Evidence
|
|
|
|
## Existing Context
|
|
|
|
- Existing `chat-verifier-agent` spec still used `source_invocation_ids` and `tool_trace_summary` as the main verifier evidence context.
|
|
- Existing `evidence-trace-hardening` spec already established `tool_invocation.retrieval_details` as the right place for structured tool-specific facts.
|
|
- Prior devflow projects established that runbook/skill content is guidance, not incident evidence.
|
|
|
|
## Code Findings
|
|
|
|
- `VerifierInputHook` previously backfilled plural `source_invocation_ids` from `tool_trace_summary` by tool name.
|
|
- `ExecutorGatekeeperService` previously validated invocation existence and tool name, but not `raw_path` or excerpt authenticity.
|
|
- `ToolInvocationRecorder` persisted retrieval details but did not generate claim-addressable `evidence_refs`.
|
|
- `QueryLogsTools` could fall back to `generic-service` placeholder logs on no-hit.
|
|
|
|
## Implementation Evidence
|
|
|
|
- `ToolInvocationRecorder` now extracts:
|
|
- `$.alerts[i]` for `query_metrics`
|
|
- `$.logs[i]` for `query_logs`
|
|
- `$.evidence_blocks[i]` for `lookup_knowledge`
|
|
- `ExecutorGatekeeperService` now validates:
|
|
- invocation existence
|
|
- tool name
|
|
- raw path presence
|
|
- `retrieval_details.evidence_refs`
|
|
- excerpt similarity/support
|
|
- `VerifierInputHook` only auto-fills a singular `source_invocation_id` when exactly one candidate exists and never invents `raw_path`.
|
|
- `QueryLogsTools` returns HikariCP mock logs for `order-service` and returns empty no-hit results for unrelated services.
|
|
|
|
## Residual Finding
|
|
|
|
The HikariCP negative E2E no longer has generic-service pollution, but the model still issued an extra broad HikariCP query without the service filter and used order-service as context. This is a remaining narrow-scope behavior issue, not a mock evidence pollution issue.
|