1a. GetExecutionSteps (~200 lines, >90% identical)

• pkg/workflow/antigravity_engine.go:155 — func (e *AntigravityEngine) GetExecutionSteps(workflowData *WorkflowData, logFile string) []GitHubActionStep
• pkg/workflow/gemini_engine.go:157 — func (e *GeminiEngine) GetExecutionSteps(...)

Same firewall block, same non-firewall command template, same env-map construction, same filtering tail. The command template is byte-identical apart from the injected command literal.

1b. GetRequiredSecretNames (byte-for-byte apart from one literal) — confirmed by direct read

• pkg/workflow/antigravity_engine.go:50 (secrets := []string{"ANTIGRAVITY_API_KEY"})
• pkg/workflow/gemini_engine.go:50 (secrets := []string{"GEMINI_API_KEY"})

Both then run the identical collectCommonMCPSecrets(...) append and the same hasGitHubTool -> GITHUB_MCP_SERVER_TOKEN branch.

1c. Settings-step generators (~95% identical)

• pkg/workflow/antigravity_tools.go:130 — generateAntigravitySettingsStep
• pkg/workflow/gemini_tools.go:125 — generateGeminiSettingsStep

Same tools-core plumbing, same JSON config shape, same jq-merge shell script; differ only in .antigravity/.gemini dir and GH_AW_*_BASE_CONFIG env name.

1d. RenderMCPConfig + surrounding engine methods (identical bodies)

• pkg/workflow/antigravity_mcp.go:13 and pkg/workflow/gemini_mcp.go:13, both delegating to renderDefaultJSONMCPConfig(...). The GetPreBundleSteps, GetDeclaredOutputFiles, GetAgentManifestFiles/PathPrefixes, and GetSecretValidationStep pairs are all clone-per-engine.

1e. ⚠️ Already-diverged clone (latent bug) — computeToolsCore

• pkg/workflow/antigravity_tools.go:43 computeAntigravityToolsCore
• pkg/workflow/gemini_tools.go:44 computeGeminiToolsCore

Same output contract, but the copies have drifted: Antigravity factored the bash logic into appendBashTools (with "wildcard anywhere wins" semantics) while Gemini still inlines an earlier loop with different discard-on-wildcard behavior. This is a real behavioral inconsistency between two engines that should behave identically.

2a. Poutine output rendering copied verbatim

• pkg/cli/poutine.go:275 parseAndDisplayPoutineOutput vs pkg/cli/poutine.go:385 parseAndDisplayPoutineOutputForDirectory

Identical JSON preamble plus a ~60-line per-finding rendering loop (severity defaulting, startLine := max(1, lineNum-2) context window, console.CompilerError construction). Only per-file-filter vs group-by-file differs.
→ Extract renderPoutineFindings(output, findings, fileLines) used by both.

2b. Scattered "read file -> context lines -> CompilerError" helper (3+ files)

• pkg/cli/poutine.go:337 & :480, pkg/cli/runner_guard.go:226, pkg/cli/zizmor.go:259

The read-source -> split-lines -> build context-around-lineNum -> emit console.CompilerError block is duplicated. Additionally the path-traversal guard (filepath.Clean -> Abs -> Rel -> reject ..) is copied nearly verbatim between poutine.go:420 and runner_guard.go:182.
→ Extract extractContextLines(fileLines, lineNum) and validateFileWithinRoot(gitRoot, filePath).

2c. Firewall timeline row renderers (~95% identical)

• pkg/cli/gateway_logs_timeline_render.go:218 renderFirewallNetworkAllowedRow vs :241 renderFirewallNetworkBlockedRow — differ only in event-kind constant and initial status value.
  → Unify into renderFirewallNetworkRow(evt, kind, defaultStatus).

2d. TSV renderers share skeleton + identical insights footer

• pkg/cli/logs_format_tsv.go:31 renderLogsTSV vs :115 renderLogsTSVVerbose — same row-normalization loop and identical # insights: observability block; verbose is a column super-set.
  → Drive both from one column-descriptor list; factor the shared footer.

2e. Org report header block repeated across three commands (weakest of the CLI set)

• deploy_org.go:38 renderOrgDeployReport, update_org.go:152 renderOrgPreviewReport, upgrade_org.go:116 renderOrgUpgradeReport — share the applying/dry-run header idiom; per-item bodies legitimately differ.
  → Extract renderOrgReportHeader(...); keep item bodies distinct.

2f. Two byte-size formatters (confirmed both wrap scaleBinaryBytes)

• pkg/console/progress_shared.go:6 formatBytes vs pkg/console/format.go:21 FormatFileSize — differ only cosmetically (space/precision/unit-list).
  → Collapse into one formatter with a small style option.

2g. Two compact-number formatters in one file

• pkg/console/render.go:674 FormatNumber (k/M/B, "0" for zero) vs :727 FormatTokens (K/M, "-" for zero) — same concept, divergent conventions producing inconsistent UI output.
  → Unify onto one parameterized helper (suffix case + zero placeholder + precision).

2h. Near-duplicate cron handlers

• pkg/parser/schedule_fuzzy_scatter.go: handleDaily(297)/handleDailyWeekdays(287), handleHourly(322)/handleHourlyWeekdays(307) — each pair >80% identical, differing only in the cron day field (* * * vs * * 1-5).
  → Parameterize each pair with a dayField string argument.

2i. Redundant shadowing wrapper

• pkg/parser/schema_suggestions.go:231 FindClosestMatches only adds two log lines around stringutil.FindClosestMatches (same name/signature/doc copied verbatim from pkg/stringutil/fuzzy_match.go:19).
  → Have callers use stringutil.FindClosestMatches directly, or keep only if the logging is required.

Minor twin (Priority 3): pkg/workflow/add_labels.go:18 parseAddLabelsConfig vs remove_labels.go:18 parseRemoveLabelsConfig are identical except the "add-labels"/"remove-labels" literal — candidate for a generic parseAllowBlockLabelConfig[T].