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

### Summary

Daily SPDD review of 5 rotated spec files (index 10–14 of 20, wrapping into the fixture-compliance batch): `specs/github-mcp-access-control-compliance/README.md`, `specs/intent-attribution-agent-governance.md`, `specs/intent-attribution-compliance/README.md`, `specs/otel-observability-spec.md`, `specs/replace-label-compliance/README.md`. All five are healthy and internally consistent (formal predicate models, fixture tables, coverage maps). The main gaps are: (1) a stated but unexecuted maintenance split for the largest spec, (2) a manual-only sync guard script that isn't wired into CI, (3) an escalation norm without a corresponding automated check, and (4) no compliance-level self-declaration recorded for the OTel spec's own tooling. No P0 correctness defects were found.

### Priority Work Queue

- **P0**: None — no correctness or safety defects found in this batch.
- **P1**: Wire the `github-mcp-access-control-compliance` pinned-spec drift guard into CI; implement the intent-attribution "sync warning → compliance failure" escalation check; begin the non-normative maintenance split of `intent-attribution-agent-governance.md`.
- **P2**: Add a fixture-inventory sync test cross-reference for `intent-attribution-compliance`; record explicit OTel conformance-class/compliance-level claims for the CLI reporting code; add a `replace-label` "Adding New Fixtures" cross-check script.

### SPDD Checklist

- [ ] `/spdd-generate`: Add a GitHub Actions step (e.g. new job or existing `lint`/`test` job) in `.github/workflows/` that runs the drift check in `specs/github-mcp-access-control-compliance/README.md` (`PINNED` vs `git log` tip of `scratchpad/github-mcp-access-control-specification.md`) so the "manual/local-only" caveat can be removed. Done when CI fails on pin drift and the README caveat is deleted.
- [ ] `/spdd-sync`: Update `specs/github-mcp-access-control-compliance/README.md` to reference the new CI job by name once added, replacing the "No CI workflow currently invokes this script" note. Done when the doc accurately reflects automation status.
- [ ] `/spdd-generate`: Implement the "3+ consecutive CI runs" sync-warning escalation described in `specs/intent-attribution-agent-governance.md` (Sync Notes) as an automated check comparing `.github/intent-policy.json` keys against `.github/objective-mapping.json` keys, opening/updating a tracking issue on escalation. Done when a script/workflow exists and a unit test exercises the 3-run threshold.
- [ ] `/spdd-generate`: Execute the "Non-normative maintenance split proposal" in `specs/intent-attribution-agent-governance.md` by extracting the "Current implementation" + runtime enforcement map into `specs/intent-attribution-agent-governance-implementation.md`, preserving heading anchors referenced from `specs/intent-attribution-compliance/`. Done when the new file exists and all cross-links resolve.
- [ ] `/spdd-sync`: After the split, update `specs/intent-attribution-compliance/README.md` links (currently pointing at `../intent-attribution-agent-governance.md`) to confirm anchors still resolve post-split. Done when a manual link check passes with no 404 anchors.
- [ ] `/spdd-analysis`: Clarify in `specs/intent-attribution-compliance/README.md` why only 3 required fixtures exist versus the 12-row Behavioral Coverage Map (9 fixture-backed + edge cases) — the "Required scenarios" table lists 3 but the coverage map implies broader test surface. Done when a short note distinguishes "minimum conformance fixtures" from "full test coverage."
- [ ] `/spdd-generate`: Add an automated fixture-count consistency test for `specs/intent-attribution-compliance/` mirroring `TestFormal_FixtureCountConsistency` in the GitHub MCP access-control suite, in `pkg/intent/compliance_fixtures_formal_test.go`. Done when the test fails if YAML fixture count diverges from the documented table.
- [ ] `/spdd-analysis`: Review `specs/otel-observability-spec.md` §2.3 Compliance Levels and record which level(s) the current gh-aw compiler/runtime actually claims (no explicit claim exists in-repo today). Done when a short compliance statement is added to `docs/` or the spec itself.
- [ ] `/spdd-reasons-canvas`: Assess **Safeguards** in `specs/otel-observability-spec.md` §2.4 Extension Conformance — confirm there's a validator step rejecting extension attributes that reuse standard OTel names with incompatible types. Done when either a validator check is found and cited, or a gap issue is filed.
- [ ] `/spdd-generate`: Add a CI or pre-commit script validating `specs/replace-label-compliance/README.md`'s "Adding New Fixtures" step 5 (fixture registered in both the table and referenced from `specs/replace-label-spec.md` §9) to prevent silent fixture/spec drift. Done when the script runs in CI and fails on an unregistered fixture.
- [ ] `/spdd-sync`: Re-verify the "Coverage parity check (2026-08-05)" note in `specs/replace-label-compliance/README.md` is still current by re-running `go test ./pkg/workflow/... -run TestFormalTransition` and `-run TestFormal` and updating the date if parity holds. Done when the date is refreshed or a discrepancy is filed.

### Per-Spec Findings

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

**Analysis**: Defines a 6-predicate (P1–P6) formal access-control model with a clear evaluation order and 12 fixture files mapped 1:1 to test functions. Well-scoped and internally consistent.

**REASONS gaps**:
- *Operations*: The drift-check script is explicitly "manual/local-only" — no CI enforcement, so the pinned spec commit can silently diverge from the live scratchpad spec.
- *Safeguards*: Good — explicit fail-safe behavior for unrecognized `MinIntegrity` config (deny-all) and blocked-user precedence over integrity checks are both documented and tested.
- *Norms*: Denial-code table (§Error Code Reference) is clear and RFC-2119-adjacent in spirit, though the file doesn't itself use MUST/SHOULD language — it inherits normative language from the linked scratchpad spec.

specs/intent-attribution-agent-governance.md (1445 lines)

**Analysis**: Large, mature spec covering intent resolution, policy compilation, enforcement, evidence, and phased rollout (7 implementation phases, 2 release gates). Formal model (F1–F7) is precise and testable.

**REASONS gaps**:
- *Structure*: The file itself flags its own size/complexity risk via the "Non-normative maintenance split proposal" (line ~140) — this is a self-identified but unexecuted structural debt item.
- *Operations*: The "Sync Notes" escalation norm (3+ consecutive CI runs → compliance failure) is written as a MUST but no corresponding automated check was found in this pass — this is an executable norm without an implementation, which risks the norm becoming aspirational-only.
- *Safeguards*: Fail-closed behavior is well-specified (safest policy on ambiguous/unlinked attribution, no stale cached policy reuse) and is the strongest section of the spec.

specs/intent-attribution-compliance/README.md

**Analysis**: Compact companion to the governance spec; defines 3 required fixtures plus a 12-row behavioral coverage map extending well beyond the minimum 3.

**REASONS gaps**:
- *Requirements*: Minimum fixture set (3) vs. documented coverage map (12 predicates/edge cases) creates an implicit expectation gap — unclear if the 3 "required" fixtures are a floor or the full conformance bar.
- *Entities*: The `Resolve(a)` formal function and `PolicyCompiler` boundary (Structure section) are clearly typed, which is a strength.
- *Operations*: No automated fixture-count consistency test was confirmed to exist for this directory (unlike the GitHub MCP access-control compliance directory, which has `TestFormal_FixtureCountConsistency`).

specs/otel-observability-spec.md (1028 lines)

**Analysis**: Comprehensive OTel spec with conformance classes, 3-tier compliance levels, and detailed trace/span/context-propagation model (sections 4–10+).

**REASONS gaps**:
- *Norms*: §2.3 requires an implementation to explicitly claim a compliance level to make any conformance assertion — no such claim was found recorded elsewhere in the repo during this pass, meaning gh-aw's own OTel implementation status is presently undeclared.
- *Safeguards*: §2.4 Extension Conformance sets MUST-NOT rules for extension attributes (no reuse of standard names with incompatible types) but this pass did not confirm an automated validator enforcing this at compile time.
- *Approach*: Section numbering and RFC-2119 discipline are exemplary and should be used as the template for tightening other specs (e.g., intent-attribution).

specs/replace-label-compliance/README.md

**Analysis**: Tight, well-organized compliance doc for the `replace-label` safe-output type with 15 core predicates (P1–P15) plus 9 transition-specific predicates (Q1–Q9) and explicit blocklist-before-allowlist security ordering.

**REASONS gaps**:
- *Operations*: The "Coverage parity check (2026-08-05)" note is a point-in-time manual verification with no recurring automation — it can silently go stale as new predicates are added.
- *Safeguards*: Blocklist-before-allowlist ordering (P3/P4/P11) is the standout safeguard in this batch — clearly modeled, tested, and documented as a security boundary.
- *Structure*: The "Adding New Fixtures" process (5 manual steps) has no automated guard ensuring fixtures registered in the README table are also referenced from `specs/replace-label-spec.md` §9, risking drift between the two documents.

### Sync Follow-ups

- After the intent-attribution maintenance split lands, re-run `/spdd-sync` to confirm `specs/intent-attribution-compliance/README.md` anchors and the coverage-map spec references still resolve.
- Once the GitHub MCP access-control drift-check CI job is added, sync `specs/github-mcp-access-control-compliance/README.md` to drop the "manual/local-only" language.
- After adding the objective-mapping/intent-policy escalation check, sync the "Sync Notes" section in `specs/intent-attribution-agent-governance.md` to reference the new automated enforcement instead of describing it only as a norm.
- Re-run the replace-label coverage parity check and refresh its dated note in `specs/replace-label-compliance/README.md` on the next full `go test ./pkg/workflow/...` pass.
- No sync action needed yet for `specs/otel-observability-spec.md` beyond recording a compliance-level claim; revisit once that claim is added.

### Context

**Files reviewed** (rotation index 10–14 of 20, `last_index` advanced 9 → 14):
- `specs/github-mcp-access-control-compliance/README.md`
- `specs/intent-attribution-agent-governance.md`
- `specs/intent-attribution-compliance/README.md`
- `specs/otel-observability-spec.md`
- `specs/replace-label-compliance/README.md`

**Rotation state**: persisted to `/tmp/gh-aw/cache-memory/spdd-daily/rotation.json`; next run continues from index 15 (`specs/replace-label-spec.md`).

**Run URL**: https://github.com/github/gh-aw/actions/runs/34991315442

> Generated by [📋 Daily SPDD Spec Planner](https://github.com/github/gh-aw/actions/runs/34991315442) · copilot · auto · 29.8 AIC · ⌖ 6.43 AIC · ⊞ 7.4K · [◷](https://github.com/search?q=repo%3Agithub%2Fgh-aw+is%3Aissue+%22gh-aw-workflow-call-id%3A+github%2Fgh-aw%2Fdaily-spdd-spec-planner%22&type=issues)
> - [x] expires on Sep 18, 2026, 7:57 AM UTC-08:00

This is a multi-part plan spanning the listed specs, .github/workflows/, pkg/intent/compliance_fixtures_formal_test.go, and pkg/workflow tests. Start by selecting one checklist item and reading its named specification, existing tests, and related workflow; the issue defines completion for each item, including CI failures, resolved links, threshold tests, or refreshed parity checks. For the replace-label parity item, run the stated go test commands first.

Written by the indexing model from the issue text.