export declare const GIT_MASTER_COMMIT_WORKFLOW_SECTION = "## PHASE 0: Parallel Context Gathering (MANDATORY FIRST STEP)\n\n<parallel_analysis>\n**Execute ALL of the following commands IN PARALLEL to minimize latency:**\n\n```bash\n# Group 1: Current state\ngit status\ngit diff --staged --stat\ngit diff --stat\n\n# Group 2: History context  \ngit log -30 --oneline\ngit log -30 --pretty=format:\"%s\"\n\n# Group 3: Branch context\ngit branch --show-current\ngit merge-base HEAD main 2>/dev/null || git merge-base HEAD master 2>/dev/null\ngit rev-parse --abbrev-ref @{upstream} 2>/dev/null || echo \"NO_UPSTREAM\"\ngit log --oneline $(git merge-base HEAD main 2>/dev/null || git merge-base HEAD master 2>/dev/null)..HEAD 2>/dev/null\n```\n\n**Capture these data points simultaneously:**\n1. What files changed (staged vs unstaged)\n2. Recent 30 commit messages for style detection\n3. Branch position relative to main/master\n4. Whether branch has upstream tracking\n5. Commits that would go in PR (local only)\n</parallel_analysis>\n\n---\n\n## PHASE 1: Style Detection (BLOCKING - MUST OUTPUT BEFORE PROCEEDING)\n\n<style_detection>\n**THIS PHASE HAS MANDATORY OUTPUT** - You MUST print the analysis result before moving to Phase 2.\n\n### 1.1 Language Profile Detection\n\n```\nCount from git log -30:\n- Dominant language/script patterns: N commits\n- Secondary language/script patterns: M commits\n- Mixed/ambiguous: K commits\n\nDECISION:\n- Preserve the dominant repository language pattern in commit messages\n- If multiple languages are common, follow the nearest recent examples for the same module\n- Never restrict output to specific languages; support any language used by the repo (e.g., Japanese, Korean, English, etc.)\n```\n\n### 1.2 Commit Style Classification\n\n| Style | Pattern | Example | Detection Regex |\n|-------|---------|---------|-----------------|\n| `SEMANTIC` | `type: message` or `type(scope): message` | `feat: add login` | `/^(feat\\|fix\\|chore\\|refactor\\|docs\\|test\\|ci\\|style\\|perf\\|build)(\\(.+\\))?:/` |\n| `PLAIN` | Just description, no prefix | `Add login feature` | No conventional prefix, >3 words |\n| `SENTENCE` | Full sentence style | `Implemented the new login flow` | Complete grammatical sentence |\n| `SHORT` | Minimal keywords | `format`, `lint` | 1-3 words only |\n\n**Detection Algorithm:**\n```\nsemantic_count = commits matching semantic regex\nplain_count = non-semantic commits with >3 words\nshort_count = commits with <=3 words\n\nIF semantic_count >= 15 (50%): STYLE = SEMANTIC\nELSE IF plain_count >= 15: STYLE = PLAIN  \nELSE IF short_count >= 10: STYLE = SHORT\nELSE: STYLE = PLAIN (safe default)\n```\n\n### 1.3 MANDATORY OUTPUT (BLOCKING)\n\n**You MUST output this block before proceeding to Phase 2. NO EXCEPTIONS.**\n\n```\nSTYLE DETECTION RESULT\n======================\nAnalyzed: 30 commits from git log\n\nLanguage profile: [DOMINANT_LANGUAGE_OR_SCRIPT]\n  - Dominant pattern: N (X%)\n  - Secondary pattern: M (Y%)\n\nStyle: [SEMANTIC | PLAIN | SENTENCE | SHORT]\n  - Semantic (feat:, fix:, etc): N (X%)\n  - Plain: M (Y%)\n  - Short: K (Z%)\n\nReference examples from repo:\n  1. \"actual commit message from log\"\n  2. \"actual commit message from log\"\n  3. \"actual commit message from log\"\n\nAll commits will follow: [DOMINANT_LANGUAGE_OR_SCRIPT] + [STYLE]\n```\n\n**IF YOU SKIP THIS OUTPUT, YOUR COMMITS WILL BE WRONG. STOP AND REDO.**\n</style_detection>\n\n---\n\n## PHASE 2: Branch Context Analysis\n\n<branch_analysis>\n### 2.1 Determine Branch State\n\n```\nBRANCH_STATE:\n  current_branch: <name>\n  has_upstream: true | false\n  commits_ahead: N  # Local-only commits\n  merge_base: <hash>\n  \nREWRITE_SAFETY:\n  - If has_upstream AND commits_ahead > 0 AND already pushed:\n    -> WARN before force push\n  - If no upstream OR all commits local:\n    -> Safe for aggressive rewrite (fixup, reset, rebase)\n  - If on main/master:\n    -> NEVER rewrite, only new commits\n```\n\n### 2.2 History Rewrite Strategy Decision\n\n```\nIF current_branch == main OR current_branch == master:\n  -> STRATEGY = NEW_COMMITS_ONLY\n  -> Never fixup, never rebase\n\nELSE IF commits_ahead == 0:\n  -> STRATEGY = NEW_COMMITS_ONLY\n  -> No history to rewrite\n\nELSE IF all commits are local (not pushed):\n  -> STRATEGY = AGGRESSIVE_REWRITE\n  -> Fixup freely, reset if needed, rebase to clean\n\nELSE IF pushed but not merged:\n  -> STRATEGY = CAREFUL_REWRITE  \n  -> Fixup OK but warn about force push\n```\n</branch_analysis>\n\n---\n\n## PHASE 3: Atomic Unit Planning (BLOCKING - MUST OUTPUT BEFORE PROCEEDING)\n\n<atomic_planning>\n**THIS PHASE HAS MANDATORY OUTPUT** - You MUST print the commit plan before moving to Phase 4.\n\n### 3.0 Calculate Minimum Commit Count FIRST\n\n```\nFORMULA: min_commits = ceil(file_count / 3)\n\n 3 files -> min 1 commit\n 5 files -> min 2 commits\n 9 files -> min 3 commits\n15 files -> min 5 commits\n```\n\n**If your planned commit count < min_commits -> WRONG. SPLIT MORE.**\n\n### 3.1 Split by Directory/Module FIRST (Primary Split)\n\n**RULE: Different directories = Different commits (almost always)**\n\n```\nExample: 8 changed files\n  - app/[locale]/page.tsx\n  - app/[locale]/layout.tsx\n  - components/demo/browser-frame.tsx\n  - components/demo/shopify-full-site.tsx\n  - components/pricing/pricing-table.tsx\n  - e2e/navbar.spec.ts\n  - messages/en.json\n  - messages/ko.json\n\nWRONG: 1 commit \"Update landing page\" (LAZY, WRONG)\nWRONG: 2 commits (still too few)\n\nCORRECT: Split by directory/concern:\n  - Commit 1: app/[locale]/page.tsx + layout.tsx (app layer)\n  - Commit 2: components/demo/* (demo components)\n  - Commit 3: components/pricing/* (pricing components)\n  - Commit 4: e2e/* (tests)\n  - Commit 5: messages/* (i18n)\n  = 5 commits from 8 files (CORRECT)\n```\n\n### 3.2 Split by Concern SECOND (Secondary Split)\n\n**Within same directory, split by logical concern:**\n\n```\nExample: components/demo/ has 4 files\n  - browser-frame.tsx (UI frame)\n  - shopify-full-site.tsx (specific demo)\n  - review-dashboard.tsx (NEW - specific demo)\n  - tone-settings.tsx (NEW - specific demo)\n\nOption A (acceptable): 1 commit if ALL tightly coupled\nOption B (preferred): 2 commits\n  - Commit: \"Update existing demo components\" (browser-frame, shopify)\n  - Commit: \"Add new demo components\" (review-dashboard, tone-settings)\n```\n\n### 3.3 NEVER Do This (Anti-Pattern Examples)\n\n```\nWRONG: \"Refactor entire landing page\" - 1 commit with 15 files\nWRONG: \"Update components and tests\" - 1 commit mixing concerns\nWRONG: \"Big update\" - Any commit touching 5+ unrelated files\n\nRIGHT: Multiple focused commits, each 1-4 files max\nRIGHT: Each commit message describes ONE specific change\nRIGHT: A reviewer can understand each commit in 30 seconds\n```\n\n### 3.4 Implementation + Test Pairing (MANDATORY)\n\n```\nRULE: Test files MUST be in same commit as implementation\n\nTest patterns to match:\n- test_*.py <-> *.py\n- *_test.py <-> *.py\n- *.test.ts <-> *.ts\n- *.spec.ts <-> *.ts\n- __tests__/*.ts <-> *.ts\n- tests/*.py <-> src/*.py\n```\n\n### 3.5 MANDATORY JUSTIFICATION (Before Creating Commit Plan)\n\n**NON-NEGOTIABLE: Before finalizing your commit plan, you MUST:**\n\n```\nFOR EACH planned commit with 3+ files:\n  1. List all files in this commit\n  2. Write ONE sentence explaining why they MUST be together\n  3. If you can't write that sentence -> SPLIT\n  \nTEMPLATE:\n\"Commit N contains [files] because [specific reason they are inseparable].\"\n\nVALID reasons:\n  VALID: \"implementation file + its direct test file\"\n  VALID: \"type definition + the only file that uses it\"\n  VALID: \"migration + model change (would break without both)\"\n  \nINVALID reasons (MUST SPLIT instead):\n  INVALID: \"all related to feature X\" (too vague)\n  INVALID: \"part of the same PR\" (not a reason)\n  INVALID: \"they were changed together\" (not a reason)\n  INVALID: \"makes sense to group\" (not a reason)\n```\n\n**OUTPUT THIS JUSTIFICATION in your analysis before executing commits.**\n\n### 3.7 Dependency Ordering\n\n```\nLevel 0: Utilities, constants, type definitions\nLevel 1: Models, schemas, interfaces\nLevel 2: Services, business logic\nLevel 3: API endpoints, controllers\nLevel 4: Configuration, infrastructure\n\nCOMMIT ORDER: Level 0 -> Level 1 -> Level 2 -> Level 3 -> Level 4\n```\n\n### 3.8 Create Commit Groups\n\nFor each logical feature/change:\n```yaml\n- group_id: 1\n  feature: \"Add Shopify discount deletion\"\n  files:\n    - errors/shopify_error.py\n    - types/delete_input.py\n    - mutations/update_contract.py\n    - tests/test_update_contract.py\n  dependency_level: 2\n  target_commit: null | <existing-hash>  # null = new, hash = fixup\n```\n\n### 3.9 MANDATORY OUTPUT (BLOCKING)\n\n**You MUST output this block before proceeding to Phase 4. NO EXCEPTIONS.**\n\n```\nCOMMIT PLAN\n===========\nFiles changed: N\nMinimum commits required: ceil(N/3) = M\nPlanned commits: K\nStatus: K >= M (PASS) | K < M (FAIL - must split more)\n\nCOMMIT 1: [message in detected style]\n  - path/to/file1.py\n  - path/to/file1_test.py\n  Justification: implementation + its test\n\nCOMMIT 2: [message in detected style]\n  - path/to/file2.py\n  Justification: independent utility function\n\nCOMMIT 3: [message in detected style]\n  - config/settings.py\n  - config/constants.py\n  Justification: tightly coupled config changes\n\nExecution order: Commit 1 -> Commit 2 -> Commit 3\n(follows dependency: Level 0 -> Level 1 -> Level 2 -> ...)\n```\n\n**VALIDATION BEFORE EXECUTION:**\n- Each commit has <=4 files (or justified)\n- Each commit message matches detected STYLE + LANGUAGE\n- Test files paired with implementation\n- Different directories = different commits (or justified)\n- Total commits >= min_commits\n\n**IF ANY CHECK FAILS, DO NOT PROCEED. REPLAN.**\n</atomic_planning>\n\n---\n\n## PHASE 4: Commit Strategy Decision\n\n<strategy_decision>\n### 4.1 For Each Commit Group, Decide:\n\n```\nFIXUP if:\n  - Change complements existing commit's intent\n  - Same feature, fixing bugs or adding missing parts\n  - Review feedback incorporation\n  - Target commit exists in local history\n\nNEW COMMIT if:\n  - New feature or capability\n  - Independent logical unit\n  - Different issue/ticket\n  - No suitable target commit exists\n```\n\n### 4.2 History Rebuild Decision (Aggressive Option)\n\n```\nCONSIDER RESET & REBUILD when:\n  - History is messy (many small fixups already)\n  - Commits are not atomic (mixed concerns)\n  - Dependency order is wrong\n  \nRESET WORKFLOW:\n  1. git reset --soft $(git merge-base HEAD main)\n  2. All changes now staged\n  3. Re-commit in proper atomic units\n  4. Clean history from scratch\n  \nONLY IF:\n  - All commits are local (not pushed)\n  - User explicitly allows OR branch is clearly WIP\n```\n\n### 4.3 Final Plan Summary\n\n```yaml\nEXECUTION_PLAN:\n  strategy: FIXUP_THEN_NEW | NEW_ONLY | RESET_REBUILD\n  fixup_commits:\n    - files: [...]\n      target: <hash>\n  new_commits:\n    - files: [...]\n      message: \"...\"\n      level: N\n  requires_force_push: true | false\n```\n</strategy_decision>\n\n---\n\n## PHASE 5: Commit Execution\n\n<execution>\n### 5.1 Register TODO Items\n\nUse TodoWrite to register each commit as a trackable item:\n```\n- [ ] Fixup: <description> -> <target-hash>\n- [ ] New: <description>\n- [ ] Rebase autosquash\n- [ ] Final verification\n```\n\n### 5.2 Fixup Commits (If Any)\n\n```bash\n# Stage files for each fixup\ngit add <files>\ngit commit --fixup=<target-hash>\n\n# Repeat for all fixups...\n\n# Single autosquash rebase at the end\nMERGE_BASE=$(git merge-base HEAD main 2>/dev/null || git merge-base HEAD master)\nGIT_SEQUENCE_EDITOR=: git rebase -i --autosquash $MERGE_BASE\n```\n\n### 5.3 New Commits (After Fixups)\n\nFor each new commit group, in dependency order:\n\n```bash\n# Stage files\ngit add <file1> <file2> ...\n\n# Verify staging\ngit diff --staged --stat\n\n# Commit with detected style\ngit commit -m \"<message-matching-COMMIT_CONFIG>\"\n\n# Verify\ngit log -1 --oneline\n```\n\n### 5.4 Commit Message Generation\n\n**Based on COMMIT_CONFIG from Phase 1:**\n\n```\nIF style == SEMANTIC:\n  -> Use a semantic prefix + repository language message\n  -> Examples:\n     - \"feat: add login feature\"\n     - \"feat: \u30ED\u30B0\u30A4\u30F3\u6A5F\u80FD\u3092\u8FFD\u52A0\"\n     - \"feat: \uB85C\uADF8\uC778 \uAE30\uB2A5 \uCD94\uAC00\"\n\nIF style == PLAIN:\n  -> Use plain repository language message without semantic prefix\n  -> Examples:\n     - \"Add login feature\"\n     - \"\u30ED\u30B0\u30A4\u30F3\u6A5F\u80FD\u3092\u8FFD\u52A0\"\n     - \"\uB85C\uADF8\uC778 \uAE30\uB2A5 \uCD94\uAC00\"\n  \nIF style == SHORT:\n  -> \"format\" / \"type fix\" / \"lint\"\n```\n\n**VALIDATION before each commit:**\n1. Does message match detected style?\n2. Does message use the repository's dominant language/script profile (from Phase 1.1)?\n3. Is it similar to examples from git log?\n\nIf ANY check fails -> REWRITE message.\n```\n</execution>\n\n---\n\n## PHASE 6: Verification & Cleanup\n\n<verification>\n### 6.1 Post-Commit Verification\n\n```bash\n# Check working directory clean\ngit status\n\n# Review new history\ngit log --oneline $(git merge-base HEAD main 2>/dev/null || git merge-base HEAD master)..HEAD\n\n# Verify each commit is atomic\n# (mentally check: can each be reverted independently?)\n```\n\n### 6.2 Force Push Decision\n\n```\nIF fixup was used AND branch has upstream:\n  -> Requires: git push --force-with-lease\n  -> WARN user about force push implications\n  \nIF only new commits:\n  -> Regular: git push\n```\n\n### 6.3 Final Report\n\n```\nCOMMIT SUMMARY:\n  Strategy: <what was done>\n  Commits created: N\n  Fixups merged: M\n  \nHISTORY:\n  <hash1> <message1>\n  <hash2> <message2>\n  ...\n\nNEXT STEPS:\n  - git push [--force-with-lease]\n  - Create PR if ready\n```\n</verification>";