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

[github-actions]

Summary

This daily SPDD plan covers 5 specification files from the specs/ directory (rotation index 15–19 of 29). The batch spans: specs/aw-harness.md (aspirational engine implementation), specs/awf-config-sources-spec.md (canonical config source authority), specs/compiler-threat-detection-spec.md (CTR rule catalog), specs/forecast-compliance-fixtures/README.md (Monte Carlo test fixture docs), and specs/github-mcp-access-control-compliance/README.md (MCP access control fixture stubs).

Key findings: (1) aw-harness.md is aspirational with a flagged unimplemented core — aw_harness.cjs is missing from actions/setup/js/. (2) awf-config-sources-spec.md has strong conformance rules but no SPDD Norms on SLA escalation ownership. (3) compiler-threat-detection-spec.md has good rule coverage through CTR-021 but the deprecation policy section has a numbering error (§4.3.1 is nested inside §5.3). (4) Forecast compliance fixture README references fixtures that exist but lacks sync notes on fixture-to-spec test mapping maintenance. (5) MCP access-control compliance fixtures exist but test runner coverage for integrity-level (T-GH-051/T-GH-052) and blocked-user (T-GH-071/T-GH-072) fixture IDs is not validated against the spec fixture IDs.

---

Priority Work Queue

Priority	Task	Spec	Stage
P0	Resolve aw-harness.md aspirational status — aw_harness.cjs is absent from actions/setup/js/	specs/aw-harness.md	/spdd-generate
P0	Fix deprecation policy section numbering (§4.3.1 inside §5.3) in compiler threat spec	specs/compiler-threat-detection-spec.md	/spdd-analysis
P1	Add SPDD Norms to awf-config-sources-spec.md for SLA escalation ownership and re-evaluation windows	specs/awf-config-sources-spec.md	/spdd-reasons-canvas
P1	Map fixture IDs (T-GH-051, T-GH-052, T-GH-071, T-GH-072) to actual test functions in pkg/workflow/tools_validation_test.go	specs/github-mcp-access-control-compliance/README.md	/spdd-sync
P1	Add Sync Follow-ups note to forecast-compliance-fixtures/README.md describing who owns fixture/spec drift	specs/forecast-compliance-fixtures/README.md	/spdd-sync
P2	Add Operations section to aw-harness.md — harness invocation order, extension loading sequence, teardown steps	specs/aw-harness.md	/spdd-reasons-canvas
P2	Clarify AW Harness Safeguards section: when to fall back to exit code 1 vs 2 on provider env var absence	specs/aw-harness.md	/spdd-reasons-canvas

---

SPDD Checklist

• [/spdd-analysis] specs/compiler-threat-detection-spec.md — Fix section numbering: move deprecation policy §4.3.1 out of §5.3 and into its own §5.4 or renumber as §5.3.1. Done when TOC links and numbering are consistent throughout the document.
• [/spdd-generate] specs/aw-harness.md — Open a tracking issue or task for implementing aw_harness.cjs at actions/setup/js/aw_harness.cjs per §10.8 work items. Done when a GitHub issue exists linking to the spec §10.8 implementation items.
• [/spdd-reasons-canvas / Norms] specs/awf-config-sources-spec.md §6.4.1 — Strengthen the SLA escalation owner assignment norm: add a fallback rule for when no git log attribution is available on config-only fields (e.g., apiProxy.auth.*). Done when CR-06a contains an explicit tertiary fallback and a re-evaluation trigger.
• [/spdd-reasons-canvas / Safeguards] specs/aw-harness.md §5.3 — Add a missing-provider-env safeguard: specify that the harness MUST exit with code 2 (not 1) when a required provider env var is absent at startup, before any session creation. Done when exit code table and §11 Security Considerations include this case.
• [/spdd-reasons-canvas / Operations] specs/aw-harness.md — Add an Extension loading order section: define the deterministic order in which the six Pi extensions (cost-tracker, steering, repair, observability, model-resolution, provider) are registered, and whether order affects correctness. Done when a new §8.x defines load order and idempotency guarantees.
• [/spdd-sync] specs/github-mcp-access-control-compliance/README.md — Add a sync note mapping each fixture ID (T-GH-011 through T-GH-083) to the corresponding test function name in pkg/workflow/tools_validation_test.go. Done when the README table includes a "Test Function" column with at least the 9 listed test cases.
• [/spdd-sync] specs/forecast-compliance-fixtures/README.md — Add a "Spec Sync" section that states which specification section each fixture validates and who owns fixture updates when the spec changes. Done when the README includes a maintainer note and spec cross-links per fixture.
• [/spdd-analysis / Requirements] specs/awf-config-sources-spec.md — Verify coverage of apiProxy.targets.openai.authHeader and apiProxy.targets.anthropic.authHeader in pkg/workflow/ and actions/setup/ (these were listed as known drift in §4). Done when a grep confirms or denies coverage and result is documented as a comment on this issue.

---

Per-Spec Findings

specs/aw-harness.md — Aspirational spec, implementation pending

SPDD Stage: /spdd-analysis + /spdd-reasons-canvas

Goals

Define aw_harness.cjs as a Pi SDK-based execution engine for engine: aw workflows. Covers entry-point contract, extensions, model resolution, and observability.

Risks

• CRITICAL: aw_harness.cjs is absent from actions/setup/js/. The spec explicitly flags this in §1 with a warning box. Any workflow using engine: aw will fail at runtime.
• No implementation timeline or blocking criteria defined in §10.8.
• Exit code table (§5.3) does not cover missing-provider-env condition (only 0, 1, 2 for generic error/invocation); provider env absence is a distinct startup failure class.

REASONS Canvas

Section	Gap
Requirements	Exit code 2 scope too broad — does not distinguish config parse failure from missing env var
Entities	Pi extension load order not specified — six extensions listed but registration sequence and idempotency undefined
Approach	§10.8 implementation work items listed but no owner or milestone
Structure	§4.1 ASCII diagram references cost-tracker and steering extensions; §8 defines only 4 named extensions (missing model-resolution as a separate extension)
Operations	No harness teardown sequence defined; what happens to open Pi spans on exit code 1?
Norms	No norm for when engine: aw becomes non-aspirational (graduation criteria absent)
Safeguards	§11 Security Considerations is sparse — no sandboxing norm for Pi session teardown on timeout

specs/awf-config-sources-spec.md — Strong conformance rules, weak Norms

SPDD Stage: /spdd-reasons-canvas

Goals

Establish canonical AWF config sources in gh-aw-firewall that gh-aw agents must consult. Defines drift detection procedure, DriftRecord entity, and SLA enforcement.

Risks

• CR-06a escalation owner determination relies on git log which may return no result for config-only fields that have never been implemented.
• §7 Safeguards describes degraded-mode behavior but does not define how many consecutive failed runs trigger a tracking issue.

REASONS Canvas

Section	Gap
Norms	CR-06a tertiary fallback (when no git log result and no on-call list defined) is unspecified
Safeguards	"more than one consecutive scheduled run" is ambiguous — does it mean 2 runs? calendar-day gap?
Entities	DriftRecord schema lacks a source_ref field for identifying which canonical source file produced the record
Sync	No note on who owns updating §4 (known drift table) when new fields are added to gh-aw-firewall

specs/compiler-threat-detection-spec.md — Comprehensive, section numbering error

SPDD Stage: /spdd-analysis

Goals

Normative CTR rule catalog for compiler threat detection (CTR-001 through CTR-021). Defines rule model, lifecycle, daily optimizer protocol, and compliance test IDs.

Risks

• §4.3.1 Deprecation Policy appears as a child of §5.3 Rule Lifecycle Requirements — section numbering is wrong; should be §5.4 or §5.3.1. This causes TOC anchor confusion.
• §6.4 False-Positive Handling SLA (10 business days) has no tracking mechanism linked — the daily optimizer must track suppression age, but no schema for suppression tracking is defined.

REASONS Canvas

Section	Gap
Structure	§4.3.1 Deprecation Policy is misplaced inside §5.3 — fix numbering
Operations	No suppression tracking entity schema defined; daily optimizer must emit SLA_BREACH entries but no structured format is specified
Norms	§6.4.3 SLA (10 days) has no escalation path defined when the owner is unreachable
Sync	§7.3 Sync Protocol requires same-PR updates but no CI check enforces the 4-artifact sync rule

specs/forecast-compliance-fixtures/README.md — Fixtures present, sync ownership missing

SPDD Stage: /spdd-sync

Goals

Document Monte Carlo compliance test fixtures for T-FC-031 through T-FC-040. All 4 fixture files (run_summary_minimal.json, run_summary_zero_et.json, run_summary_failed.json, run_summary_high_et.json) are present and used in tests.

Gaps

• No "Spec Sync" section: who updates fixtures when pkg/cli/forecast_montecarlo_test.go or the forecast-specification.md changes?
• Fixture table lists fixtures and test IDs but no cross-link to the actual spec section numbers in forecast-specification.md.

specs/github-mcp-access-control-compliance/README.md — Fixture stubs exist, test coverage unverified

SPDD Stage: /spdd-sync

Goals

Document compliance test fixtures for MCP access control (T-GH-11 through T-GH-83). All 9 YAML fixture files are present.

Gaps

• README says tests are "located in (or will be added to)" pkg/workflow/tools_validation_test.go — the "or will be added" hedge indicates T-add ${{ github.server_url }} as allowed substitution #51, T-Test coverage improvement august 14 metrics #52, T-Tweak: gh aw status improvements #71, T-Limitation: codex cannot write GITHUB_STEP_SUMMARY #72 (integrity-level and blocked-user fixture IDs) may not have corresponding test functions. Searching the test file shows blocked-user test cases by name, but no test using the fixture YAML files directly.
• Fixture README table has no "Test Function" column mapping fixture to concrete Go test name.
• combined-filter-allow.yaml (T-GH-081/T-GH-082/T-Proposal: Add gemini as agentic engine #83) is not referenced anywhere in tools_validation_test.go by fixture ID.

---

Sync Follow-ups

1. specs/aw-harness.md ↔ actions/setup/js/: When aw_harness.cjs is created, spec §5–§10 must be reviewed for accuracy against the implementation. Add a sync note in §10.8 requiring a spec audit PR when the file first lands.
2. specs/compiler-threat-detection-spec.md §7.3 ↔ CI: The "4-artifact sync rule" (rule catalog, mapping row, test ID, lock file) described in §7.3 has no CI enforcement. Track as a maintenance task: add a CI lint step that warns when a CTR-* rule row in §5.1 lacks a corresponding entry in §7.1 or §8.1.
3. specs/awf-config-sources-spec.md §4 ↔ gh-aw-firewall: The known drift table in §4 should be programmatically regenerated from the drift detection workflow output, not maintained by hand. Add a sync note that §4 is example-only and the authoritative drift state lives in the workflow run outputs.
4. specs/github-mcp-access-control-compliance/ ↔ scratchpad/github-mcp-access-control-specification.md: Fixture error codes in the README must stay in sync with §11.1 of the parent specification. Add a sync header to each fixture YAML noting the spec section it tests.

---

Context

• Files reviewed (rotation 15–19 of 29):
  • specs/aw-harness.md
  • 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
• Next rotation starts at index: 20
• Run: §29034253407

References:

• §29034253407

Generated by 📋 Daily SPDD Spec Planner · 64 AIC · ⌖ 9.09 AIC · ⊞ 4.8K · ◷

• expires on Jul 12, 2026, 8:52 AM UTC-08:00

[github-actions]

This issue was automatically closed because it expired on 2026-07-12T16:52:58.315Z.

Closed by Workflow