[spdd] Daily spec work plan - 2026-07-31

[github-actions]

Summary

Daily SPDD review covered 5 specs (rotation index 5–9 of 18): specs/awf-config-sources-spec.md, specs/compiler-threat-detection-spec.md, specs/forecast-compliance-fixtures/README.md, specs/github-mcp-access-control-compliance/README.md, and specs/intent-attribution-agent-governance.md. No critical gaps block usage, but several drift-tracking, safeguard, and sync mechanisms are documented as requirements without corresponding automation in the repo, and one fixtures README references a spec version-history section that should be spot-checked for staleness.

Priority Work Queue

• P0: None found this cycle.
• P1: Verify the scheduled schema-consistency workflow actually implements the AWF config drift procedure (Section 7) and CR-06 SLA escalation template from specs/awf-config-sources-spec.md; verify CTR-016/018/019/020/021 sync references in specs/compiler-threat-detection-spec.md still match current pkg/workflow/ behavior.
• P2: Tighten operational language in specs/intent-attribution-agent-governance.md Sync Notes (no hard migration deadline is defined) and add missing-fixture entries in specs/forecast-compliance-fixtures/README.md / specs/github-mcp-access-control-compliance/README.md if new compliance test IDs have been added since last review.

SPDD Checklist

• /spdd-sync — Confirm .github/workflows/schema-consistency-checker.md (or its .lock.yml) implements the full AWF config drift detection procedure (Section 7) and the CR-06a escalation-owner assignment logic from specs/awf-config-sources-spec.md; update the spec's implementation-reference link if the workflow path changed.
• /spdd-generate — Add or verify a scheduled/CI check comparing docs/awf-config.schema.json top-level properties against the CLI mapping table in docs/awf-config-spec.md, per CR-04 in specs/awf-config-sources-spec.md; target: schema-consistency workflow or a new pkg/workflow/ drift test.
• /spdd-analysis — Re-validate the "Mapping Audit (2026-07-27)" section (line ~305) of specs/compiler-threat-detection-spec.md against current pkg/workflow/ CTR rule implementations to confirm no new drift since that audit date.
• /spdd-reasons-canvas — Strengthen Safeguards in specs/awf-config-sources-spec.md Section 8: the "last-known validated local snapshot" fallback is described narratively but has no named storage location or retention policy; add explicit snapshot path/TTL guidance.
• /spdd-reasons-canvas — Strengthen Norms in specs/intent-attribution-agent-governance.md Sync Notes: "fully migrate" is defined but no repository-level deadline or enforcement trigger exists; consider adding a norm for when drift warnings escalate to compliance failures.
• /spdd-generate — Add a new fixture to specs/forecast-compliance-fixtures/README.md covering a run with conclusion: "cancelled" (currently only success/failure/zero-ET/high-ET are documented) to close a gap in Bernoulli sampling coverage; target file: new run_summary_cancelled.json fixture + README table update.
• /spdd-sync — Cross-check the Behavioral Coverage Map in specs/github-mcp-access-control-compliance/README.md against pkg/workflow/github_mcp_access_control_formal_test.go to confirm all listed TestFormal_* functions still exist and no new predicates were added without corresponding fixture/table rows.
• /spdd-analysis — Review specs/compiler-threat-detection-spec.md Section 6 (Daily Optimizer Maintenance Protocol) for whether "Optimizer Failure Safeguards" (line ~235) is exercised by any existing test; if untested, flag as a coverage gap for the next implementation cycle.
• /spdd-generate — Document the apiProxy.targets.copilot.* config-only fields (Section 5 known-drift table in specs/awf-config-sources-spec.md) with explicit test references in pkg/workflow/, matching the pattern used for other DriftRecord field mappings.

Per-Spec Findings

specs/awf-config-sources-spec.md — Working Draft v0.1.0

• Requirements: Well-specified drift categories (missing_in_ghaw, missing_in_schema, spec_mismatch) with formal DriftRecord JSON schema (Section 3.1). CR-01 through CR-06a are clear MUST/SHOULD statements.
• Entities: DriftRecord is well-modeled with field reference table mapping to pkg/workflow/awf_config_drift_formal_test.go.
• Approach: Drift detection procedure (Section 7) is concrete with an example CLI script (Section 7.3), but the script is illustrative only — no confirmation it runs in CI as written.
• Structure: Document is logically ordered (purpose → sources → data model → checks → conformance → procedure → safeguards).
• Operations: Section 7.4 references schema-consistency-checker.md as the tracked workflow but doesn't confirm the workflow covers all of Section 7.2's steps — this is the P1 sync item above.
• Norms: CR-06 defines a clear 5-business-day SLA with escalation; CR-06a defines owner-assignment logic via git log heuristics — reasonably concrete but relies on manual interpretation during escalation.
• Safeguards: Section 8 covers source-unavailability handling (stale snapshot fallback, degraded-mode marking) but lacks a named snapshot storage path — flagged above.

specs/compiler-threat-detection-spec.md — v1.0.18 (2026-07-27)

• Requirements: Extensive rule catalog (CTR-001 onward) with a maintained Spec-to-Implementation Sync table (Section 2) mapping each version to minimum binary version and lock-file compatibility notes — a strong practice worth replicating in other specs.
• Entities: Rule model (Section 4) defines Rule ID, Threat Class, Detection Condition, Compiler Action, Evidence, Implementation Mapping — complete and testable.
• Approach: Daily Optimizer Maintenance Protocol (Section 6) defines daily inputs/decision procedure/output requirements/false-positive handling — mature process.
• Structure: Numbered heading anomaly: Section "4.3.1 Deprecation Policy" appears under top-level Section 5 (line 172) instead of Section 5.3 — a numbering drift worth a quick doc fix.
• Operations: Section 7.3 "Sync Protocol for CTR Rule and Manifest Updates" exists; confirm it's actually followed given the frequent version bumps (18 versions since 1.0.0).
• Norms: Change log shows near-weekly revisions (1.0.14 → 1.0.18 within one month) — cadence suggests active drift risk; recommend the P1 mapping-audit re-validation above.
• Safeguards: Section 6.6 "Optimizer Failure Safeguards" and Section 6.4 "False-Positive Handling" are documented but coverage-test status is unconfirmed — flagged above.

specs/forecast-compliance-fixtures/README.md

• Requirements: Fixture purpose is clear — bootstrapping Section 12 compliance tests of the Forecast Specification.
• Entities: RunSummary schema fields are cross-referenced to Go struct fields (pkg/cli/logs_models.go) — good traceability.
• Approach: Test IDs (T-FC-022, T-FC-031–040, T-ET-006) are enumerated per fixture; missing a "cancelled" run scenario noted above.
• Structure: Short, single-purpose README; adequate.
• Operations: go test commands for full suite, Monte Carlo subset, and race-detector runs are all documented and runnable as-is.
• Norms: "Adding New Fixtures" gives a 3-step contribution process — good norm for future edits.
• Safeguards: None documented (fixture READMEs are typically low-risk); no gap flagged.

specs/github-mcp-access-control-compliance/README.md

• Requirements: Formal model (P1–P6 guard predicates) is precisely defined with evaluation order and a full Behavioral Coverage Map linking each predicate to its test function — excellent traceability.
• Entities: AccessRequest, ToolConfig, Decision are formally typed; error-code reference table (−32001 to −32006) is complete.
• Approach: Fixture schema (YAML) is well-specified with required keys (fixture_id, spec_refs, input, expected).
• Structure: Logical flow from formal model → coverage map → fixture files → schema → error codes → usage.
• Operations: go test -run "TestFormal_" commands are concrete and runnable.
• Norms: "Adding New Fixtures" 5-step process is clear and specific (unlike the vaguer processes in other specs).
• Safeguards: P6_IntegrityMet fail-safe behavior for unrecognized MinIntegrity config (denies all requests) is a strong safeguard already documented — no gap.

specs/intent-attribution-agent-governance.md — large spec, 1421 lines

• Requirements: RFC 2119 norms cover attribution-resolution order, ambiguous-root handling, fail-closed behavior, and compliance fixtures (lines 36–83) — comprehensive but dense.
• Entities: Core model (Intent, Attribution, Policy, Outcome, Evidence — lines 155–237) is well-separated into distinct entity sections.
• Approach: Seven-phase implementation roadmap (Phase 1–7, lines 1195–1312) gives a clear staged approach from "current foundation" to "broader intent relationships."
• Structure: Very long single-file spec (1421 lines); consider whether Sections on OpenTelemetry/Metrics/CLI (lines 1047–1195) should be split into a companion doc for maintainability — not urgent.
• Operations: Enforcement section (line 876) and Authorizer.AuthorizeTool Implementation Audit (line 930) suggest active enforcement code exists; policy compilation (line 806) and decision provenance (line 835) are documented but not independently verified in this pass.
• Norms: Sync Notes (lines 115–130) define "fully migrate" precisely but explicitly avoid a mandatory completion deadline — flagged as a P2 norms-tightening item above.
• Safeguards: Fail-closed requirement is explicit and strong: policy resolution failures MUST fail to the safest policy, and stale cached decisions MUST NOT be silently reused (lines 84–103) — well-specified, no gap found.

Sync Follow-ups

• After confirming the schema-consistency workflow implementation against specs/awf-config-sources-spec.md Section 7, update the spec's Section 7.4 implementation-reference link if the workflow path or coverage has changed.
• After the CTR mapping-audit re-validation, add a new dated subsection under specs/compiler-threat-detection-spec.md Section 7.2 (following the existing "Mapping Audit (2026-07-27)" pattern) documenting the outcome, and bump the spec version/change-log per Section 2's sync table requirement.
• If new compliance test IDs are added to pkg/cli/forecast_montecarlo_test.go or pkg/workflow/github_mcp_access_control_formal_test.go, update the corresponding fixture README tables in the same PR to keep spec/test traceability intact.
• If .github/intent-policy.json migration progresses in any repository, update the Sync Notes section of specs/intent-attribution-agent-governance.md to reflect actual migration status rather than the current aspirational framing.

Context

Files reviewed this run (rotation index 5–9 of 18 total spec files):

• specs/awf-config-sources-spec.md
• specs/compiler-threat-detection-spec.md
• specs/forecast-compliance-fixtures/README.md
• specs/github-mcp-access-control-compliance/README.md
• specs/intent-attribution-agent-governance.md

Rotation state: persisted to /tmp/gh-aw/cache-memory/spdd-daily/rotation.json with last_index: 9, total_files: 18. Next run should continue from specs/otel-observability-spec.md onward.

Run: §30646948984

Generated by 📋 Daily SPDD Spec Planner · auto · 34.3 AIC · ⌖ 5.67 AIC · ⊞ 6.9K · ◷

• expires on Aug 3, 2026, 8:31 AM UTC-08:00