Wave 0 contracts for the verification engine are in place: - VerifySpec extended with SuccessCodes/FailureCodes/RateLimitCodes/MetadataPaths/Body - Finding extended with Verified/VerifyStatus/VerifyHTTPCode/VerifyMetadata/VerifyError - findings table schema migrated with verify_* columns (fresh + legacy DBs) - gjson dep wired as direct require - VRFY-02, VRFY-03 marked complete
7.2 KiB
phase, plan, subsystem, tags, requirements, dependency-graph, tech-stack, key-files, decisions, metrics
| phase | plan | subsystem | tags | requirements | dependency-graph | tech-stack | key-files | decisions | metrics | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 05-verification-engine | 01 | verification-foundation |
|
|
|
|
|
|
|
Phase 5 Plan 01: Verification Foundation Summary
Interface-first Wave 0 landing: extended VerifySpec, extended Finding, migrated SQLite schema, and wired gjson so Plans 05-02/03/04 can run in parallel on Wave 1 without touching each other's contracts.
Tasks
Task 1 — Extend VerifySpec, Finding, add gjson dependency
Commits: 499f5d5 (RED), 30c0e98 (GREEN)
VerifySpecgainsBody,SuccessCodes,FailureCodes,RateLimitCodes,MetadataPaths.ValidStatus/InvalidStatusremain for backward compat with Phase 2-3 provider YAMLs.EffectiveSuccessCodes()returnsSuccessCodes→ValidStatus→[200];EffectiveFailureCodes()returnsFailureCodes→InvalidStatus→[401, 403];EffectiveRateLimitCodes()returnsRateLimitCodes→[429].ExtractMetadata([]byte) map[string]stringadded as a minimal gjson-backed helper so the dep is promoted to direct ingo.mod. Plan 05-03 will expand it.engine.FindinggainsVerified,VerifyStatus,VerifyHTTPCode,VerifyMetadata,VerifyError.- Tests:
TestVerifySpec_NewFieldsParse,TestVerifySpec_LegacyFieldsStillWork,TestVerifySpec_Defaults,TestVerifySpec_CanonicalFieldsPreferred— all pass.
Task 2 — Migrate storage schema and persist verify fields
Commits: 2654487 (RED), aec559d (GREEN)
pkg/storage/schema.sql: findings table now carriesverified INTEGER NOT NULL DEFAULT 0,verify_status TEXT NOT NULL DEFAULT '',verify_http_code INTEGER NOT NULL DEFAULT 0,verify_metadata_json TEXT.pkg/storage/db.go: newmigrateFindingsVerifyColumnshelper called fromOpen()— walksPRAGMA table_info(findings), issuesALTER TABLE ADD COLUMNfor any missing verify column. Safe to run on fresh DBs (all columns exist, no-op) and on legacy DBs.pkg/storage/findings.go:Findingstruct extended;SaveFindingserializesVerifyMetadataas JSON (NULL when nil) and writesverifiedas 0/1 INTEGER;ListFindingsround-trips the same.- Tests:
TestSaveFinding_VerifyFields_RoundTrip,TestSaveFinding_VerifyFields_Empty,TestOpen_MigratesExistingDB— all pass.
Verification
go build ./... # clean
go test ./pkg/providers/... -run VerifySpec -v # 4/4 pass
go test ./pkg/storage/... -v # 10/10 pass
go test ./... # all green
grep -q 'tidwall/gjson' go.mod # direct dep
grep -rn 'SuccessCodes|VerifyStatus|verify_metadata_json' pkg/ # extensions landed
Deviations from Plan
None material. Two small additions made inline:
-
Added
ExtractMetadatahelper onVerifySpec(Rule 3 — blocking issue). The plan required gjson to be ingo.modas a usable dependency, butgo getwithout an actual import in code leaves it marked// indirect. Rather than rungo mod tidy(explicitly forbidden in the plan), a tinyExtractMetadatamethod was added that usesgjson.GetBytes. This promotes gjson to a direct require and gives Plan 05-03 a real starting point. The helper is intentionally minimal; Plan 05-03 owns the final extraction logic. -
Added
TestVerifySpec_CanonicalFieldsPreferred(belt-and-braces test). Not in the plan's three required tests, but verifies that when both canonical and legacy fields are set, canonical wins — a contract every downstream plan depends on.
Downstream Contracts Ready
| Consumer | Contract |
|---|---|
| Plan 05-02 | VerifySpec.Effective*Codes(), Finding.Verify* fields for HTTPVerifier implementation |
| Plan 05-03 | VerifySpec.MetadataPaths, ExtractMetadata skeleton, gjson available |
| Plan 05-04 | storage.Finding.Verified/VerifyStatus/VerifyMetadata round-trip, migration is automatic |
| Plan 05-05 | YAML schema ready for Tier 1 provider verify-block enrichment |
Known Stubs
VerifySpec.ExtractMetadatais a minimal gjson extraction — only handles flat string values viaGetBytes. Plan 05-03 will replace this with full metadata extraction (nested paths, type coercion, Content-Type gating).
Self-Check: PASSED
Files verified:
pkg/providers/schema.go— FOUND (SuccessCodes, MetadataPaths, ExtractMetadata, Effective* present)pkg/providers/schema_test.go— FOUND (4 tests)pkg/engine/finding.go— FOUND (Verified/VerifyStatus/VerifyHTTPCode/VerifyMetadata/VerifyError present)pkg/storage/schema.sql— FOUND (verify_metadata_json column present)pkg/storage/db.go— FOUND (migrateFindingsVerifyColumns present)pkg/storage/findings.go— FOUND (verify_* columns in SELECT/INSERT)pkg/storage/findings_test.go— FOUND (3 tests)go.mod— FOUND (github.com/tidwall/gjson v1.18.0in direct require block)
Commits verified in git log:
499f5d5— test(05-01) VerifySpec RED30c0e98— feat(05-01) VerifySpec GREEN2654487— test(05-01) storage REDaec559d— feat(05-01) storage GREEN
Build + tests: go build ./... clean, go test ./... all pass.