Gsd Reapply Patches

Multi-select workaround:

• Codex has no multiSelect. Use sequential single-selects, or present a numbered freeform list asking the user to enter comma-separated numbers.

Execute mode fallback:

• When request_user_input is rejected (Execute mode), present a plain-text numbered list and pick a reasonable default.

C. Task() → spawn_agent Mapping

GSD workflows use Task(...) (Claude Code syntax). Translate to Codex collaboration tools:

Direct mapping:

• Task(subagent_type="X", prompt="Y") → spawn_agent(agent_type="X", message="Y")
• Task(model="...") → omit (Codex uses per-role config, not inline model selection)
• fork_context: false by default — GSD agents load their own context via <files_to_read> blocks

Parallel fan-out:

• Spawn multiple agents → collect agent IDs → wait(ids) for all to complete

Result parsing:

• Look for structured markers in agent output: CHECKPOINT, PLAN COMPLETE, SUMMARY, etc.
• close_agent(id) after collecting results from each agent </codex_skill_adapter>

Step 1: Detect backed-up patches

Check for local patches directory:

# Global install (path templated at install time)
PATCHES_DIR=./.codex/gsd-local-patches
# Local install fallback
if [ ! -d "$PATCHES_DIR" ]; then
  PATCHES_DIR=./.codex/gsd-local-patches
fi

Read backup-meta.json from the patches directory.

If no patches found:

No local patches found. Nothing to reapply.

Local patches are automatically saved when you run $gsd-update
after modifying any GSD workflow, command, or agent files.

Exit.

Step 2: Show patch summary

## Local Patches to Reapply

**Backed up from:** v{from_version}
**Current version:** {read VERSION file}
**Files modified:** {count}

| # | File | Status |
|---|------|--------|
| 1 | {file_path} | Pending |
| 2 | {file_path} | Pending |

Step 3: Merge each file

For each file in backup-meta.json:

1. Read the backed-up version (user's modified copy from gsd-local-patches/)

2. Read the newly installed version (current file after update)

3. Compare and merge:

   • If the new file is identical to the backed-up file: skip (modification was incorporated upstream)
   • If the new file differs: identify the user's modifications and apply them to the new version

   Merge strategy:

   • Read both versions fully
   • Identify sections the user added or modified (look for additions, not just differences from path replacement)
   • Apply user's additions/modifications to the new version
   • If a section the user modified was also changed upstream: flag as conflict, show both versions, ask user which to keep

4. Write merged result to the installed location

5. Report status:

   • Merged — user modifications applied cleanly
   • Skipped — modification already in upstream
   • Conflict — user chose resolution

Step 4: Update manifest

After reapplying, regenerate the file manifest so future updates correctly detect these as user modifications:

# The manifest will be regenerated on next $gsd-update
# For now, just note which files were modified

Step 5: Cleanup option

Ask user:

• "Keep patch backups for reference?" → preserve gsd-local-patches/
• "Clean up patch backups?" → remove gsd-local-patches/ directory

Step 6: Report

## Patches Reapplied

| # | File | Status |
|---|------|--------|
| 1 | {file_path} | ✓ Merged |
| 2 | {file_path} | ○ Skipped (already upstream) |
| 3 | {file_path} | ⚠ Conflict resolved |

{count} file(s) updated. Your local modifications are active again.

<success_criteria>

• All backed-up patches processed
• User modifications merged into new version
• Conflicts resolved with user input
• Status reported for each file </success_criteria>