This session hardened the daily Litify GCLID propagation automation against the failure mode from the previous run, where shell/process launch failed and the automation stopped before useful closeout.
Created a shared resilience scaffold under /Users/samaguiar/.codex/automations/_shared/resilient-runner/:
README.md: common automation status model, fallback order, stop-before-write rules, and required output contract.AUTOMATION_INSTRUCTION_TEMPLATE.md: reusable startup block for recurring automations.ADOPTION.md: broader plan for updating other automations that currently depend on one local shell, path, CLI, or LaunchAgent lane.Created daily GCLID-specific hardening files under /Users/samaguiar/.codex/automations/daily-litify-gclid-propagation/:
RUNBOOK.md: first-read order, execution surface order, preflight requirements, command order, write boundaries, and closeout contract.PROMPT_PATCH.md: replacement prompt language that treats stale worktrees, missing shells, missing CLIs, broken aliases, and unavailable LaunchAgents as preflight blockers rather than unstructured quits.worktrees/README.md: worktree selection and naming guidance so the job is not tied to one of Sam's Macs.last-blocker-report.md: current blocker report with the exact process-launch error and next safe restart condition.Updated /Users/samaguiar/.codex/automations/daily-litify-gclid-propagation/memory.md with the hardening summary and current run time.
The requested resilience documentation and instruction patch were created, but shell execution remains unavailable in this session. Because command execution still fails before filesystem inspection, I could not create a real git worktree, inspect the repo, validate Salesforce, or test the daily job. No live-system writes were attempted.
A future command-capable run can load the new shared contract first, then update the actual recurring automation prompt with the wording in PROMPT_PATCH.md. After shell/process launch works, the next agent can create or validate a clean worktree, validate LITIFY_ORG, and run the daily dry-run/apply flow using the new runbook. For other automations, the practical next pass is to add the shared startup block from AUTOMATION_INSTRUCTION_TEMPLATE.md to each brittle recurring job and define that job's write preflight and read-only fallback lanes.
The blocker appears to be the automation runner's process-launch layer, not the GCLID script itself. The new files are intentionally outside the repo so they can be read before repo access is assumed. A new agent should start by confirming a simple command can run, then read the shared resilient-runner README and the daily GCLID runbook before touching Litify or Salesforce. The core safety boundary remains: validate LITIFY_ORG before writes, never overwrite nonblank GCLID fields, and use blocked-before-write with a Knowledge Base closeout when write preflight cannot be satisfied.
Importance: High. Status: pending because the actual automation prompt still needs to be updated in the scheduler once the automation update surface or a working runner is available.