Session purpose

Execute Sam's Q1-Q5 QA reflection picks from the Wave 2 SF-chain re-enable close-out. All 5 questions had been surfaced via clickable AskUserQuestion in the prior session; this session was the execution turn.

Pending QA items pointer: /Users/samaguiar/Documents/Codex/_qa-queue/2026-04-23.md (Sam triages from there at session start, not from Notion). Per environment-wide rule set 2026-04-23: Notion is STORAGE, not a workflow review surface.

Q1-Q5 resolutions

Q1 — How to verify the SF chain end-to-end

Sam's pick: A (Manual one-shot via Desktop Commander) at top level, then the sub-MC offered three execution paths and Sam picked C (Defer to validator skill task #19).

Action taken: Updated existing task #19 description to incorporate SF chain smoke-testing into the validator's scope. The validator skill, when built, will be the single place where chain-smoke-testing happens. No manual one-shot run this session.

Owner / next step: Task #19 owner builds validator skill; validator's first responsibility is SF chain smoke test against the 4 reconstructed prompts.

Q2 — Guard contract documentation

Sam's pick: A (Create _guards/README.md and link from each consumer SKILL.md).

Action taken:

• Created /Users/samaguiar/Documents/Claude/Scheduled/_guards/README.md with full guard contract: usage syntax, exit-code table (0/1/2), QA-queue write behavior, glob conventions, platform notes (BSD stat -f %m, Linux would need stat -c %Y), --allow-missing semantics, current consumer list, how to add new guards, how to add new consumers with example bash invocation.
• Added a one-line blockquote pointer inside each of the 4 SF consumer SKILL.md PREFLIGHT blocks: weekly-cannibalization-fix, weekly-orphan-fixer, technical-seo-crawl-audit, screaming-frog-ingest.
• Pointer reads: Guard contract (exit codes, --allow-missing semantics, QA-queue write behavior, "next eligible after" timestamp): see /Users/samaguiar/Documents/Claude/Scheduled/_guards/README.md. Do not duplicate the contract here; read it there so all consumers stay in sync.

Owner / next step: Done. Future new guard or new consumer must update README first.

Q3 — Stale-upstream operator clarity

Sam's pick: A (Add next-eligible-after timestamp to stale-upstream block).

Action taken: Edited /Users/samaguiar/Documents/Claude/Scheduled/_guards/staleness-guard.sh to compute NEXT_ELIGIBLE_TS = NEWEST_TS + MAX_AGE_SECS and emit it in both ISO-8601 UTC and local-time formats inside the QA-queue HARD FAIL block. Also added a stderr line on abort. Includes a note that the timestamp assumes the current artifact is the newest the producer will yield; an earlier producer re-run makes the task eligible immediately on the next scheduled tick.

Owner / next step: Done. Behavior is live for the next stale-upstream event.