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

### Summary

Rotation batch 4/4 (files 15–19 of 20, wrapping to index 0 next run) covered five specs: `replace-label-spec.md`, `safe-output-outcome-evaluation.md`, `safe-outputs-scratchpad-removal.md`, `security-architecture-spec-summary.md`, and `security-architecture-spec-validation.md`. No critical gaps found, but several REASONS-canvas weaknesses and one hard deadline (2026-09-21 scratchpad removal) need action this cycle.

### Priority Work Queue

- **P0** — Scratchpad removal deadline (2026-09-21) is 5 days out; verify zero remaining references before deletion (`safe-outputs-scratchpad-removal.md`).
- **P1** — Close two partially-evidenced compliance gaps in `security-architecture-spec-validation.md` (§12): Sandbox Isolation runtime probe (tracked issue ``#48686``) and Threat Detection capability evidence (T-TD-002..007).
- **P1** — Extend `safe-output-outcome-evaluation.md` implementation beyond the initial 5 priority types; confirm `pkg/cli/outcome_eval.go` covers `replace_label` (added as type ``#30``, appears last / lowest priority in the current ordering).
- **P2** — Tighten `replace-label-spec.md` Norms/Safeguards cross-references between error categories (§7.1) and the compliance test suite (§9) so RL-04x requirements have explicit test IDs.
- **P2** — Refresh `security-architecture-spec-summary.md` "Spec Maintenance Tasks" table with a new row once the two P1 gaps above are closed, keeping the maintenance log current.

### SPDD Checklist

- [ ] `/spdd-sync`: In `specs/safe-outputs-scratchpad-removal.md`, run `grep -r "scratchpad/safe-outputs-specification.md" docs/ .github/` and record the result inline; if zero matches, schedule deletion of `scratchpad/safe-outputs-specification.md` on/before 2026-09-21. Done when the checklist item is checked off with the grep output recorded.
- [ ] `/spdd-generate`: In `pkg/workflow/security_architecture_sg_formal_test.go`, add a runtime probe test for sandbox host/socket visibility to close T-SI gap referenced in `specs/security-architecture-spec-validation.md` §8c and issue ``#48686``. Done when a new `TestFormalSI0xx_*` test exists and the validation doc §12 row for Sandbox Isolation is updated to EVIDENCED.
- [ ] `/spdd-generate`: In `pkg/workflow/` (detection job tests), add capability-assertion tests for T-TD-002 (prompt injection) through T-TD-007 (workflow failure on detection) referenced in `specs/security-architecture-spec-validation.md` §12. Done when new tests exist and the Threat Detection row moves from PARTIALLY EVIDENCED to EVIDENCED.
- [ ] `/spdd-generate`: In `pkg/cli/outcome_eval.go`, verify and, if missing, implement outcome evaluation logic for `replace_label` per `specs/safe-output-outcome-evaluation.md` §30. Done when a corresponding evaluator function and OTel attribute emission exist and are covered by a unit test.
- [ ] `/spdd-analysis`: In `specs/replace-label-spec.md` §7 (Error Handling) and §9 (Compliance Testing), cross-reference each RL-0xx requirement to a named compliance test ID. Done when every RL-0xx bullet in §7 has an adjacent `(see T-RL-0xx)` annotation or equivalent mapping table.
- [ ] `/spdd-reasons-canvas`: In `specs/safe-output-outcome-evaluation.md` Norms section, add an explicit Safeguards subsection covering what happens when `403`/`429` retry budgets are exhausted (currently only "SHOULD reschedule" is stated, no MUST fallback). Done when a new "Safeguards" or expanded Norms bullet defines the terminal behavior after retry exhaustion.
- [ ] `/spdd-sync`: In `specs/security-architecture-spec-summary.md` "Spec Maintenance Tasks" table, add a new row once the Sandbox Isolation and Threat Detection gaps (P1 above) are closed, linking to the updated validation doc sections. Done when the table has a new ✅ Done row citing the closed gaps.
- [ ] `/spdd-sync`: In `specs/security-architecture-spec-validation.md` §12, update the Gap Summary paragraph after each of the two P1 fixes lands, changing status from PARTIALLY EVIDENCED to EVIDENCED. Done when both rows in the compliance test matrix show ✅ EVIDENCED with a citation to the new test names.

### Per-Spec Findings

specs/replace-label-spec.md — Analysis, REASONS Canvas, Generate

**Analysis**: Well-structured Candidate Recommendation (v1.0.0) defining the `replace-label` safe-output type via a single atomic REST `PUT .../labels` call. Goals (atomicity, eliminating round-trip vs. separate remove/add) are clear. Risk: partial-success handling (§7.4, RL-057) depends on post-call verification logic that must stay in sync with the REST interface section — if the label array format from GitHub changes, both sections need coordinated updates.

**REASONS Canvas**:
- Requirements: Strong (RL-0xx numbered, testable).
- Entities: Clear (label_to_add/label_to_remove, target modes).
- Approach: Well-defined 8-stage processing model.
- Structure: Good TOC and section numbering.
- Operations: REST call and retry policy well specified.
- Norms: RFC 2119 language used consistently.
- Safeguards: Error categories table (§7.1) exists but lacks explicit mapping to compliance test IDs in §9 — weakest link found.

**Generate**: Add RL-0xx→test-ID mapping table near §9; target file `specs/replace-label-spec.md` §9, no code changes required this cycle.

specs/safe-output-outcome-evaluation.md — Analysis, REASONS Canvas, Generate

**Analysis**: Comprehensive evaluation spec covering 30 safe-output types plus derived metrics and implementation priority. Ambiguity: "Implementation Priority" lists only 5 types as the starting set; unclear whether the remaining 25 (including `replace_label`, the newest type) have been implemented in `pkg/cli/outcome_eval.go`. This is a Generate-stage gap, not a spec-writing gap.

**REASONS Canvas**:
- Requirements: MUST/SHOULD norms clearly stated for API failure handling.
- Entities: Outcome categories (accepted/rejected/ignored/pending/lifecycle/lifecycle_close) well enumerated.
- Approach: Bot-aware provenance model is thoughtful and explicit about limitations.
- Structure: Numbered sections per safe-output type, consistent format.
- Operations: Derived Metrics table maps each metric to Go/JS owner files — good traceability.
- Norms: Present but retry-exhaustion terminal behavior underspecified (see Safeguards).
- Safeguards: Weak — no explicit MUST for what happens after rate-limit/5xx retries are exhausted; currently only says workers "SHOULD reschedule," leaving terminal-state ambiguity.

**Generate**: Verify `pkg/cli/outcome_eval.go` implements evaluators for all 30 types, prioritizing `replace_label` (newest, currently unranked in Implementation Priority list).

specs/safe-outputs-scratchpad-removal.md — Analysis, REASONS Canvas, Generate, Sync

**Analysis**: Short, single-purpose deprecation checklist. Hard deadline 2026-09-21 (5 days from this run) to remove `scratchpad/safe-outputs-specification.md` in favor of the canonical doc-site spec. Risk: if the grep verification step is skipped, stale links could break after deletion.

**REASONS Canvas**: Minimal document by design (a checklist, not a full spec) — Requirements and Operations are the only relevant categories and both are clear. No Entities/Approach/Structure/Norms/Safeguards sections expected or needed here.

**Generate**: Run the verification grep, record the result, and if clean, schedule the file deletion on/before 2026-09-21.

**Sync**: After deletion, sync-check `docs/` navigation and `.github/` workflow references one more time to confirm no dangling links remain.

specs/security-architecture-spec-summary.md — Analysis, REASONS Canvas, Sync

**Analysis**: A well-maintained rolling summary/index document (v1.0.1) with an actively updated "Spec Maintenance Tasks" table showing a healthy audit trail of completed work through 2026-08-01. No urgent issues; this is a strong example of Sync-stage discipline other specs should follow.

**REASONS Canvas**: All seven categories present and healthy via cross-references to the full spec and validation doc. Only mild gap: the maintenance table doesn't yet have a row for the two P1 gaps identified in the validation doc's §12 analysis this cycle — expected, since those fixes are still pending.

**Sync**: Add a new maintenance-table row once the Sandbox Isolation and Threat Detection gaps close (see P1 items above).

specs/security-architecture-spec-validation.md — Analysis, REASONS Canvas, Generate, Sync

**Analysis**: Detailed validation report cross-checking the main security architecture spec against implementation evidence. §12 Compliance Test Matrix Gap Analysis is the most actionable section: 2 of 9 test categories are PARTIALLY EVIDENCED (Sandbox Isolation, Threat Detection), and 1 (Companion MCP Access-Control) is deferred to companion scratchpad specs. Risk: the sandbox-runtime probe gap has been open since at least the tracked issue ``#48686`` reference — should be prioritized before it goes stale.

**REASONS Canvas**:
- Requirements: Strong — each finding traces to a normative requirement ID (PM-xx, RS-xx, TD-xx).
- Entities: Test ID taxonomy (T-IS, T-OI, T-NI, T-PM, T-SI, T-TD, T-CS, T-RS, T-GH) is clear and consistent.
- Approach: Gap analysis table is a good practice worth replicating in other validation docs.
- Structure: Long document but well-sectioned with clear headers.
- Operations: Re-validation Triggers section defines when to re-run — good operational discipline.
- Norms: Escalation section defines failure handling.
- Safeguards: The Companion MCP Access-Control gap (T-GH-047 to T-GH-060) is explicitly deferred but has no committed follow-up date — weakest safeguard found this cycle.

**Generate**: Add the two missing test suites (Sandbox Isolation runtime probe, Threat Detection capability assertions) as detailed in the SPDD Checklist above.

**Sync**: After each new test lands, update §12's status column and the Gap Summary narrative; also propagate a completion note into `security-architecture-spec-summary.md`'s maintenance table.

### Sync Follow-ups

- After the two §12 compliance gaps close, sync `security-architecture-spec-validation.md` (status column) and `security-architecture-spec-summary.md` (maintenance table) in the same PR to keep them from drifting apart again.
- After `replace_label` outcome-evaluation logic is confirmed/implemented, sync `safe-output-outcome-evaluation.md`'s "Implementation Priority" list to explicitly include or exclude it with rationale.
- After the scratchpad file is deleted (on/before 2026-09-21), sync any doc-site navigation entries and `.github/workflows/*.md` references that may still point to the old path.
- Set a committed follow-up date for the Companion MCP Access-Control deferral (T-GH-047 to T-GH-060) in `security-architecture-spec-validation.md`, since it currently has no target date.

### Context

**Files reviewed this run** (rotation batch, indices 15–19 of 20, 0-indexed):
- `specs/replace-label-spec.md`
- `specs/safe-output-outcome-evaluation.md`
- `specs/safe-outputs-scratchpad-removal.md`
- `specs/security-architecture-spec-summary.md`
- `specs/security-architecture-spec-validation.md`

**Rotation state**: `last_index` advanced from 14 → 19; next run wraps to index 0 (`scratchpad/github-mcp-access-control-specification.md`). Full file list (20 total) tracked in `/tmp/gh-aw/cache-memory/spdd-daily/rotation.json`.

**Run**: workflow-run-id `35118226719`, triggered by `pelikhan`, 2026-09-16.

> Generated by [📋 Daily SPDD Spec Planner](https://github.com/github/gh-aw/actions/runs/35118226719) · copilot · auto · 37 AIC · ⌖ 7.56 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 19, 2026, 7:59 AM UTC-08:00

Start with the SPDD Checklist and the five named specs, then run the scratchpad grep before choosing a work item. Read the relevant sections and entry points, including pkg/workflow/security_architecture_sg_formal_test.go, pkg/cli/outcome_eval.go, and the listed test areas. Done means each selected checklist item has its stated test, documentation update, or recorded verification, with linked status tables kept in sync.

Written by the indexing model from the issue text.