[spdd] Daily spec work plan - 2026-08-01

[github-actions]

Summary

Daily SPDD rotation reviewed 5 specs/fixtures (index 10–14 of 18): specs/intent-attribution-compliance/README.md, specs/otel-observability-spec.md, specs/replace-label-compliance/README.md, specs/replace-label-spec.md, specs/safe-output-outcome-evaluation.md. No critical safety gaps found; several REASONS-canvas weaknesses and sync-drift risks identified, mainly in fixture coverage completeness and cross-spec traceability.

Priority Work Queue

• P0: None — no safety-critical ambiguity found this cycle.
• P1: Intent-attribution compliance fixtures referenced in README are not yet materialized as YAML files; replace-label fixture set exists but its Behavioral Coverage Map (P1–P15) needs a matching entry check against pkg/workflow/replace_label_formal_test.go.
• P2: Tighten cross-links between safe-output-outcome-evaluation.md outcome categories and otel-observability-spec.md §13 Outcome Evaluation section; clarify norms language for bot/actor provenance edge cases.

SPDD Checklist

• /spdd-generate: Create the 3 missing intent-attribution fixture files (explicit-intent-wins.yaml, ambiguous-root-closing-issues.yaml, unlinked-pr-fail-closed.yaml) in specs/intent-attribution-compliance/ per the README's "Minimum fixture set for conformance claims" — done when all 3 files exist and pass a schema check.
• /spdd-sync: Verify pkg/workflow/replace_label_formal_test.go implements all 18 predicates/edge cases listed in specs/replace-label-compliance/README.md's Behavioral Coverage Map (P1–P15 + 3 edge cases) — done when a diff of test function names vs. table shows 1:1 coverage or gaps are filed.
• /spdd-analysis: Review specs/otel-observability-spec.md §13 "Outcome Evaluation" (line 700) for consistency with the full outcome taxonomy in specs/safe-output-outcome-evaluation.md — done when discrepancies (if any) are listed in a follow-up note.
• /spdd-generate: Add a Sync Follow-ups-style cross-reference table in specs/safe-output-outcome-evaluation.md mapping each of the 30 safe-output type sections (lines 155–672) to their corresponding compliance test files, mirroring the pattern used in specs/replace-label-compliance/README.md — done when each of the 30 sections links to a test file or is marked "not-started".
• /spdd-reasons-canvas: Strengthen "Safeguards" section in specs/otel-observability-spec.md §15 "Security and Privacy" (line 756) by adding explicit guidance on OTLP header/credential redaction for direct-export mode — done when a normative MUST/MUST NOT clause is added covering credential leakage in span attributes.
• /spdd-analysis: Clarify ambiguous language in specs/safe-output-outcome-evaluation.md Provenance Limits (line 29) around "actor-visible, non-bot activity" for human_* fields when GitHub Apps post on behalf of a human (e.g., via API with app token) — done when an explicit resolution rule is added to the Norms section.
• /spdd-generate: Document the 9.2 Test Requirements section of specs/replace-label-spec.md (line 534) against actual test IDs (T-RL-020–T-RL-025) to confirm none are orphaned or missing from rl-001–rl-003 fixture files — done when a checklist confirms full ID coverage or files a gap.
• /spdd-sync: Update specs/intent-attribution-agent-governance.md Attribution-Resolution Order section to reference the (to-be-created) fixture filenames explicitly by path, so spec and fixtures stay linked — done when the spec's §RFC 2119 Norms section cites the fixture file paths.

Per-Spec Findings

specs/intent-attribution-compliance/README.md — REASONS Canvas

• Requirements: Clear — 3 required scenarios with expected results and spec references.
• Entities: Weak — no formal entity/schema definition for "attribution metadata" shape; relies on prose only.
• Approach: Adequate — fixture-driven testing pattern is stated.
• Structure: Missing — no fixture files exist yet (only a table describing them); directory has just this README.
• Operations: Not specified — no processing pipeline/order described (unlike replace-label-compliance).
• Norms: Present via cross-reference to parent spec's §RFC 2119 Norms.
• Safeguards: Fail-closed behavior for unlinked PRs is documented — good baseline safeguard.

Risk: This is the thinnest fixture doc reviewed (26 lines) and has zero backing test files — highest gap density this cycle.

specs/replace-label-compliance/README.md — REASONS Canvas

• Requirements: Strong — RL-001/002/003 with explicit test ID cross-references (T-RL-020–025).
• Entities: Strong — full YAML fixture schema documented with field types.
• Approach: Strong — SMT-style predicate model (P1–P15) with formal preconditions/postconditions.
• Structure: Strong — concrete fixture files named and mapped to Go test functions.
• Operations: Strong — explicit evaluation order (blocked → allowlist → gates → staged/execute).
• Norms: Implicit via predicate naming, not restated as RFC 2119 keywords in this doc (delegates to main spec).
• Safeguards: Strong — blocklist-before-allowlist ordering explicitly called out as a "security boundary."

Risk: Low. This is the most mature fixture doc reviewed; main follow-up is confirming test-to-table parity (P1 task above).

specs/otel-observability-spec.md — REASONS Canvas (partial read, 19 sections)

• Requirements: Strong — formal W3C-style spec with numbered conformance classes (§2).
• Entities: Strong — Resource/Instrumentation Identity (§8), Trace Model (§9) well defined.
• Approach: Strong — compatibility-first versioning stance explicitly stated (no breaking changes without migration alias).
• Structure: Strong — 19-section TOC, Compliance Testing (§17) present.
• Operations: Adequate — Runtime Environment/Export (§6), Context Propagation (§7) covered.
• Norms: Strong — explicit MUST/MUST NOT language in Status section.
• Safeguards: Present (§15 Security and Privacy) but not fully reviewed this cycle for credential-redaction specificity in OTLP headers — flagged as P2 task above.

Risk: Medium — outcome evaluation (§13) is only ~28 lines within a 966-line spec; likely thin relative to the dedicated 960-line safe-output-outcome-evaluation.md, suggesting duplication/drift risk (P2 task).

specs/replace-label-spec.md — REASONS Canvas (partial read, sections 1–7 headers)

• Requirements: Strong — 6 numbered design goals (§1.3) each with MUST-level language.
• Entities: Strong — Configuration Schema (§4.1) and Message Schema (§4.2) both present.
• Approach: Strong — 8-stage Processing Model (§5.1–5.8) fully enumerated.
• Structure: Strong — REST Interface (§6) with explicit API call and execution semantics.
• Operations: Strong — Error Handling (§7) covers categories, REST failure, rate-limit retry, and partial-success handling.
• Norms: Strong — Conformance Classes and Requirements Notation (§2.1–2.2) formally defined.
• Safeguards: Strong — dedicated §8 Security Considerations with 6 named subsections (allowlist, cross-repo, staged mode as security control).

Risk: Low — well-formed spec; main gap is confirming §9.2 Test Requirements fully enumerate T-RL IDs against fixtures (P1 task above).

specs/safe-output-outcome-evaluation.md — REASONS Canvas (partial read, sections 1–90 of 960 lines)

• Requirements: Strong — 4 explicit MUST/MUST NOT norms for 404/5xx/rate-limit handling.
• Entities: Strong — Outcome Categories table (6 states) and Common OTel Attributes table (11 attributes) well defined.
• Approach: Strong — "Same as a repository observer would check" principle gives clear evaluation philosophy.
• Structure: Very strong — 30 per-type sections (one per safe-output type) plus Derived Metrics, Implementation Priority, Conformance, Formal Model.
• Operations: Adequate — Current Default Acceptance Map documents implemented/partial/not-started status per type but doesn't state a remediation timeline for partial/not-started rows.
• Norms: Strong — Provenance Limits section explicitly disclaims inferring hidden AI assistance.
• Safeguards: Adequate — bot-aware but "not provenance-perfect" stance is honest but leaves an ambiguity: GitHub App-authored actions on behalf of a human aren't explicitly resolved (flagged as task above).

Risk: Medium — largest spec reviewed (960 lines) covering 30 safe-output types; highest surface area for silent drift between this file's acceptance map and actual evaluator code in pkg/cli/outcome_eval*.go.

Sync Follow-ups

• After creating the 3 intent-attribution fixture YAML files, update specs/intent-attribution-agent-governance.md to cite them by path (currently only the compliance README lists them).
• After confirming replace-label test coverage parity, note the confirmation date in specs/replace-label-compliance/README.md's Behavioral Coverage Map or file a gap issue for any missing predicate test.
• After reconciling otel-observability-spec.md §13 with safe-output-outcome-evaluation.md, add a one-line "See also" cross-reference in both files' Change Log sections to prevent future divergence.
• Schedule a follow-up rotation pass on specs/safe-output-outcome-evaluation.md remaining ~870 lines (30 per-type sections were only header-scanned, not content-reviewed) to check each type's evaluator status against pkg/cli/outcome_eval*.go.

Context

Files reviewed this run (rotation index 10–14 of 18):

• specs/intent-attribution-compliance/README.md
• specs/otel-observability-spec.md
• specs/replace-label-compliance/README.md
• specs/replace-label-spec.md
• specs/safe-output-outcome-evaluation.md

Rotation state persisted to /tmp/gh-aw/cache-memory/spdd-daily/rotation.json (last_index: 14, total_files: 18). Next run continues from files 15–18 then wraps to 1.

Workflow run: https://github.com/github/gh-aw/actions/runs/30707554991

Generated by 📋 Daily SPDD Spec Planner · auto · 33.1 AIC · ⌖ 8.26 AIC · ⊞ 6.9K · ◷

• expires on Aug 4, 2026, 8:17 AM UTC-08:00