fix(watch): re-accept agentforce-generate after v0.9 upstream release

[askalf]

Second verse, same as the first — but a bigger delta this time.

What

Re-accepts agentforce-adlc:agentforce-generate with the hash of the v0.9 bytes (bddf5715…). ~2 hours after #65's re-acceptance, Salesforce shipped v0.9 (pin f7630726 → 1df4ca2f) and the exact-bytes acceptance lapsed again — the 2026-07-17 dispatch went red.

Delta review (hand-read in full)

• SKILL.md: description gains 'optimize', version 0.8 → 0.9, new 'Optimize an Agent' workflow section — notably including a STOP for user approval step before applying changes.
• 4 new reference docs (334 lines total, all read): optimization patterns for wiring action outputs, extracting deterministic logic, fixing reference syntax, and escalation-action wiring. Hotel-booking/customer-service examples. No exfil shapes, no secrets, no instruction-override content beyond the pre-existing reviewed fixtures.

Verification

• Scan of the v0.9 tree → identical single finding (instruction-override, the pre-existing fixture prose).
• New hash computed via the watch's own scan + skillHash path.

Note for the morning

This vendor is actively shipping (2 releases in one day). Exact-bytes acceptance means each release lapses the acceptance until re-review — by design, but worth a think about per-file acceptance granularity (issue to follow).

[sprayberry-reviewer]

Automated review from the Sprayberry Labs fleet code reviewer (sprayberry-reviewer).

No blocking issues found — approving.

What I checked

Single file changed: support/watch-accepted.json, one entry updated:

-    "hash": "551ada69fa206d78846aa758f14a603028a09925816d9cb9a7bb01bb30a8d348",
+    "hash": "bddf57157b63206f7c5ac2ea68321a71b316d7b259ffa9041eb3aa8ac762a833",
     "class": "security-testing fixtures",
-    "note": "...re-accepted 2026-07-16...",
-    "reviewed": "2026-07-16"
+    "note": "...re-accepted 2026-07-17 after a second upstream drift this week: v0.9...",
+    "reviewed": "2026-07-17"

Hash format — new value is 64 hex characters, correct for SHA-256. ✓

Structural correctness — the watch-accepted.json format is key → { hash, class, note, reviewed }. All four fields are present and typed correctly; class ("security-testing fixtures") is unchanged; note and reviewed are updated to match the v0.9 re-acceptance. All other 12 entries are untouched. ✓

Acceptance mechanism (support/marketplace-watch.mjs) — the watch script does:

const a = accepted[s.name];
if (a && a.hash === skillHash(r.skill)) acceptedRows.push({ ... });
else flaggedRows.push({ ... });

Updating the hash to the v0.9 bytes is exactly the correct operation to keep the nightly watch green for this skill after the upstream release. Any further drift will re-flag as designed. ✓

Scope — no logic changes anywhere; this is purely an acceptance-list bump following the same pattern as PR #65 (v0.8 re-acceptance the prior day). ✓

What's good — the PR description is thorough: it documents the hand-read delta (4 new reference docs, 334 lines), names the specific class of content found ("optimization workflow, STOP-for-approval steps, hotel-booking/customer-service examples"), notes the single pre-existing fixture finding, and flags the operational observation about per-release drift as a follow-up. The paper trail is exactly what an acceptance record should have.