P3D Pack 1 Phase 4B — Discovery Prompt rev6 Patch Report

Date: 2026-05-11 Author: Opus 4.7 Directive: gpt-directive-opus-p3d-pack1-phase4b-discovery-prompt-rev6-detect-col-fix-2026-05-11.md

---

1. Status flags

phase4b_discovery_prompt_rev6_status=PATCHED
detect_col_return_code_fixed=true
set_e_graceful_degradation_safe=true
scope=DETECT_COL_FIX_ONLY
no_structural_change=true
no_legal_alignment_change=true
requires_GPT_User_review_before_dispatch=true

2. Single change

detect_col return code: return 1 → return 0

Before (rev5):

detect_col() {
  ...
  echo ""
  return 1  # BUG: set -e aborts on VAR=$(detect_col ...) when no column found
}

After (rev6):

detect_col() {
  ...
  echo ""
  return 0  # FIXED: empty string signals "not found", exit 0 prevents set -e abort
}

Added comment: # NOT return 1 — set -e would abort on VAR=$(detect_col ...) if return 1

3. Why this matters

set -euo pipefail is active for script safety (catch real errors). But VAR=$(func) inherits the function's exit code. If detect_col returns 1 for a missing optional column, bash treats it as an error and aborts the entire script — destroying the graceful degradation model.

With return 0, the caller checks [ -n "$VAR" ] to distinguish "found" (non-empty) from "not found" (empty). All existing callers already use this pattern.

4. Verification: other set -e interactions are safe

Pattern	Safe under set -e?	Why
col_exists in if col_exists ...	✅	bash doesn't trigger set -e on if conditions
col_exists inside detect_col for loop	✅	inside if, not bare command
run_query with || echo "FAILED"	✅	|| is set -e exception; right side runs, returns 0
detect_col in VAR=$(detect_col ...)	✅ after fix	return 0 always
heredoc passed to run_query	✅	stdin passthrough, psql reads heredoc, || echo catches failure

5. Confirmation

phase4b_discovery_prompt=REV6_READY_FOR_GPT_REVIEW
next_action=GPT_REVIEW_DISCOVERY_PROMPT_REV6