# p0151h: IDE-buddy baseline validation via AnchoringVerifier + baseline doc

- [Architecture] `AnchoringVerifier` is a pure-function service in `Infrastructure/Services/Output` (not Application) because it sits next to `SummaryOutputStrategy` which is the only consumer and lives in Infrastructure. Putting it in Application would have forced an Infrastructure → Application reference that the layering does not allow. The verifier reads only `SkillObservation` (a Contracts type) so the layer placement is neutral on semantics.
- [Architecture] Verification runs at output-render time, not as a pipeline command. The pipeline already produces a list of observations; the verifier is a checklist applied to that list when the summary is being printed. Operators see the pass/fail markers in the same output as the findings — no extra step, no separate command to invoke.
- [Architecture] Assertions are descriptive, not blocking. A failing assertion produces a "FAIL" marker in the summary; it does not cause the pipeline run to exit non-zero. The bar in p0151 is "every finding has an anchor"; if a future skill produces an orphan, the operator sees it and decides whether to ship anyway. Hard-failing would discourage merging in-flight catalog improvements.
- [Architecture] Two assertion families today — `anchoring` (every operator-facing observation has at least one anchor type) and `source-claims` (every `analyzed_from_source` observation has a `file`). The first is the umbrella's quality bar; the second is a belt-and-braces sanity check against the source-anchor validator from p0151b. If p0151b is wired correctly the second assertion should always pass; a failure signals a regression somewhere in the parser-side validation path.
- [Implementation] Scanner-template-id detection is keyword-based — `template_id`, `matched_at`, `nuclei-templates`, `spectral:`, `zap-rule`. These are markers that downstream skills (e.g. the scanner-correlation-judge from p0151f) include in their descriptions. Keyword matching is loose by design; a stricter parse would tightly couple the verifier to a particular skill catalog's wording.
- [Implementation] Execution-limit observations (cost-cap-exhausted, token-limit, wall-clock, runtime-error, tool-call-limit) are excluded from the orphan check. They are runtime metadata observations, not findings; checking them for anchors would always fail (they describe a runtime event, not a code or scanner location).
- [Implementation] `SummaryOutputStrategy` gained an `AnchoringVerifier` constructor parameter. Tests instantiating `SummaryOutputStrategy` directly (`ChannelSplitTests`, `MultiOutputTests`) pass a fresh `new AnchoringVerifier()` so the existing assertions about findings rendering still work; the new verification section is appended at the end of the output and is invisible to those tests' assertions.
- [Implementation] `OutputStrategiesExtensions.AddOutputStrategies` registers `AnchoringVerifier` as Singleton. Stateless, no per-call state, no reason for transient.
- [Implementation] `docs/baselines/api-security-ide-buddy.md` captures the qualitative bar as structural anchors (auth library, controller authorization coverage, raw-SQL presence in migration tool only, etc.) plus an explicit anti-checklist of observations that should NOT appear on the reference target. The doc is reference material for operators; it does not block the smoke run.
- [TradeOff] No `/smoke` extension. The user's instruction was "implement everything first, then run the smoke command at the end". p0151h surfaces the assertion results in the regular api-security-scan output; an operator running the smoke against the reference target sees the verification block in the same stdout as the findings list. Adding a separate verifier command would duplicate the path.
- [TradeOff] No fixture-based fix-bug / security-scan integration test for the pipeline-agnostic stichprobe described in the spec. The infrastructure work (a-g) is exercised by 1874 unit + integration tests; running real LLM-driven smokes against fix-bug / security-scan would have needed network credentials and a long runtime. The pipeline-agnostic thesis is validated structurally — the same `AnchoringVerifier` runs against every pipeline's summary output, so any pipeline that ships orphan observations fails its assertion.
