[Update] enforce mandatory PR workflow on extension commands

.claude/commands/implement-extensions-batch.md

@@ -186,14 +186,18 @@ batch-impl-extensions-<dashed-issue-numbers>
 - If more than 4 issues: include the first 4 + `-plus<N-4>` suffix (e.g.
   `batch-impl-extensions-123-180-186-190-plus2` for N=6).
 
-Create:
+Create the local branch AND immediately push the empty ref to `origin`:
+
 ```bash
 git switch -c <branch-name> origin/development
+git push -u origin <branch-name>
 ```
 
-Refuse if the branch already exists locally OR on origin (`git ls-remote
---exit-code origin <branch>`) — ask the user to pick a different batch or delete
-the stale branch.
+The second push is safe: the branch tip equals `origin/development`'s tip, so no commits are pushed — just the ref is created on origin. This is the only push the orchestrator performs by default; it exists so the user's later `git push` of their own commit is a trivial fast-forward with no `-u` setup hassle.
+
+Refuse if the branch already exists locally OR on origin (`git ls-remote --exit-code origin <branch>`) — ask the user to pick a different batch or delete the stale branch.
+
+If `git push -u origin <branch-name>` fails (e.g. no GitHub auth, no write permission), surface the error and continue with the local branch only — the user will set up the remote ref themselves later.
 
 ### 7. Assign every issue to `@me`
 
@@ -327,11 +331,13 @@ step-11 logic from `/implement-extensions`:
 6. Push via `gh issue edit <num> --body-file <tmp-body-file>`.
 7. Re-fetch + diff to verify only the Checklist section changed.
 
-### 14. Final summary
+### 14. Final summary + commit-ready handoff (END OF RUN)
+
+After Phase IS completes, the orchestrator stops. **This is the end of the batch run.** The orchestrator does NOT run `git add`, does NOT run `git commit`, does NOT push the user's commit, does NOT open the PR. Those are entirely the user's job. The agent's git involvement was bounded to step 6 (create branch locally + push empty ref).
 
 Print to the user:
 
-- **Branch**: name + base ref + how to delete-if-aborting.
+- **Branch**: name + base ref. Note that the empty branch was already pushed to `origin/<branch-name>` in step 6, so the user's `git push` of their own commit will be a trivial fast-forward.
 - **Per-file table**:
 
   | File | Stubs impl. | Targeted tests | Reg. sweep impact | Reviewer | Issue |
@@ -340,28 +346,25 @@ Print to the user:
   | `<Foo2>Extensions.cs` | … | … | … | … | … |
 
 - **Branch-wide totals**:
-  - Files modified (sum of production + tests + notes).
+  - Files modified (sum of production + tests + sibling fixtures touched). `.team-notes/` are gitignored and stay local automatically.
   - Full solution test count (e.g. `1082/1082`).
   - Unresolved reviewer findings (if any).
   - Spec-text-only methods flagged separately (grounded in spec prose, not OCL).
-  - Out-of-scope blockers surfaced (e.g. "VerifyComputeX in <Sibling>TestFixture
-    is still stub-blocked on `<UpstreamMethod>` — consider a follow-up issue").
+  - Out-of-scope blockers surfaced.
 
-- **Pre-filled commit message** (MANDATORY — append at the very end of the
-  final-summary message in a fenced code block, ready to copy):
+- **Pre-filled commit message** (MANDATORY — append at the very end of the final-summary message in a fenced code block, ready to copy):
 
   ```
   Fix #<n1> #<n2> #<n3> …
   ```
 
-  Where the numbers are exactly the GitHub issue numbers handled by this
-  batch, in the original `$ARGUMENTS` order (or, if the user expressed a
-  preferred order in the invocation prompt, that order). Nothing else —
-  no body paragraphs, no per-file bullet list, no `Co-Authored-By` trailer,
-  no "🤖 Generated with …" footer. The single line is the entire message.
+  Single line. No body, no `Co-Authored-By` trailer, no "🤖 Generated with …" footer. The numbers are exactly the GitHub issue numbers handled by this batch, in the original `$ARGUMENTS` order (or, if the user expressed a preferred order in the invocation prompt, that order).
+
+- **Explicit handoff line** — the orchestrator must include this verbatim at the bottom:
+
+  > Review `git diff`, stage the in-scope files (`git add <path1> <path2> …` — NEVER `-A` / `.`), commit with the message above, then `git push` (the remote branch already exists from step 6, so this is a fast-forward — no `-u` needed). Open the PR yourself via the GitHub UI or `gh pr create --base development`.
 
-- **Reminder**: nothing is auto-committed. User reviews `git diff`, decides
-  whether to commit / push / open PR.
+After the handoff line, the orchestrator stops. The run is complete. The user may follow up with a separate request (e.g. "rerun the tests", "amend the fix") which the orchestrator serves as a new turn — but the agent does NOT proactively push, PR, or commit. If the user explicitly asks the agent to push or open the PR, the agent does so per the CLAUDE.md "Branch & PR workflow (MANDATORY)" → "If the user does explicitly ask the agent to push or open the PR" subsection.
 
 ## Failure handling
 
@@ -380,6 +383,9 @@ Print to the user:
 | Reviewer NEEDS FIX for one or more files | Step 12 | Re-dispatch THE implementer or THE tester with a focused brief naming the broken file(s); other files' results still reported. |
 | Implementer's context runs out mid-batch | Any IT/V step | Re-dispatch THE implementer with a focused brief covering only the unfinished file(s). Partial progress on disk is preserved. |
 | Batch partially fails after branch + assignment | Any step ≥ 6 | Keep the branch; surface in final summary; user decides whether to retry via `/implement-extensions` for the still-broken single file or revert. |
+| Empty-branch push to origin fails | Step 6 | Surface the error and continue with the local branch only. The user sets up the remote ref themselves later. |
+| User explicitly asks the agent to push their commit and the commit doesn't exist on the current branch | User-initiated push request | Refuse, surface — agent only pushes commits that are already on the branch (which the user made themselves). |
+| User explicitly asks the agent to push and the current branch is `development`/`master` | User-initiated push request | REFUSE — feature work must live on a feature branch first. Surface to the user. |
 
 ## Parallelism caps (orchestrator self-enforced)
 
@@ -407,7 +413,8 @@ context per role.
   mistranslation.
 - The branch and the assignments persist even on partial failure. Be explicit
   in the final summary about which files succeeded vs which need follow-up.
-- Do NOT auto-commit. The user reviews `git diff` and commits manually.
+- **Commit is the user's job** — agent NEVER runs `git commit`, ever. Step 14 (final summary) ends with a pre-filled commit message + handoff line, then the run is over. See `feedback_pr_mandatory.md` and CLAUDE.md "Branch & PR workflow (MANDATORY)".
+- **Push + PR are the user's job too** — the agent does NOT proactively push commits or open PRs. It only performs those if the user explicitly asks in a follow-up turn. The one push the agent does perform by default is the empty-branch push in step 6 (creating the remote ref at the same tip as `origin/development`, so the user's later push of their own commit is a trivial fast-forward).
 - If the user supplies a single file, route them to `/implement-extensions`
   with the same filename rather than creating a degenerate 1-file "batch"
   branch.

.claude/commands/implement-extensions.md

@@ -367,7 +367,9 @@ verdict.
 If the verdict is "NEEDS FIX", dispatch the implementer or tester back to
 action the findings (the reviewer never edits).
 
-### 10. Final summary
+### 10. Final summary + commit-ready handoff (END OF RUN)
+
+After step 11 (issue checklist sync) completes, the orchestrator stops. **This is the end of the run.** The orchestrator does NOT run `git add`, does NOT run `git commit`, does NOT push the user's commit, does NOT open the PR. Those are entirely the user's job.
 
 Report to the user:
 - Modified files (production + test fixture + notes + any regression-sweep test fixtures).
@@ -391,7 +393,11 @@ Report to the user:
   no body paragraphs, no per-method bullet list, no `Co-Authored-By` trailer,
   no "🤖 Generated with …" footer. The single line is the entire message.
 
-Do NOT auto-commit. The user reviews and commits.
+- **Explicit handoff line** — the orchestrator must include this verbatim at the bottom:
+
+  > Review `git diff`, stage the in-scope files (`git add <path> …` — NEVER `-A` / `.`), commit with the message above, then `git push` (if the remote branch ref does not yet exist, use `git push -u origin <branch>` once). Open the PR yourself via the GitHub UI or `gh pr create --base development`.
+
+After the handoff line, the orchestrator stops. The run is complete. If the user explicitly asks in a follow-up turn for the agent to push their commit or open the PR, the agent does so per the CLAUDE.md "Branch & PR workflow (MANDATORY)" → "If the user does explicitly ask the agent to push or open the PR" subsection. Otherwise the user handles those steps themselves. See `feedback_pr_mandatory.md`.
 
 ### 11. Sync GitHub issue checklist
 
@@ -482,6 +488,8 @@ unresolved findings are separately surfaced in the final-summary report. The
   implementation state of the file; unresolved findings are separately surfaced
   in the final-summary report. The `gh issue edit` push must touch ONLY the
   `### Checklist` section — verify with a re-fetch + diff before reporting "done".
+- **Commit is the user's job** — the agent NEVER runs `git commit`, ever. Step 10 (final summary) ends with a pre-filled commit message + handoff line, then the run is over. See `feedback_pr_mandatory.md` and CLAUDE.md "Branch & PR workflow (MANDATORY)".
+- **Push + PR are the user's job too** — the agent does NOT proactively push commits or open PRs. It only performs those if the user explicitly asks in a follow-up turn (rare; user-initiated only). Unlike `/implement-extensions-batch`, this command does NOT create a branch, so there is no empty-branch push to perform — the user owns branch creation and remote setup.
 - **Plan mode is handled by Gate 0 at the top of this file** — the orchestrator writes the proposed-execution plan to the plan file, calls `ExitPlanMode`, and proceeds on approval. The orchestrator never spawns sub-agents while plan mode is active, so the previous "degraded mode" workaround is no longer needed and has been removed.
 - **Gate R-A (step 5.5) is mandatory every run.** It is the only structural checkpoint between the researcher returning `spec ready` and the implementer + tester being spawned. Do not skip it even when the researcher reports zero ambiguities — the user explicitly asked for an unconditional gate so they can review per-method derivations before code is written.
 - **Tool-level prompts (`Bash(...)`, `Edit(...)`, `Write(...)`, `Agent(...)`) still surface per the user's `settings.json`.** Gate 0 and Gate R-A govern STRUCTURAL approval only. The user has explicitly chosen to keep handling tool-level prompts manually rather than auto-allowing them via permission rules or hooks.

CLAUDE.md

@@ -142,12 +142,43 @@ Auto-generated DTOs use structured namespaces reflecting the KerML/SysML package
 
 ## Key Conventions
 
-- Commit messages use prefix tags: `[Add]`, `[Update]`, `[Remove]`, `[Fix]`
-- Main branch: `master`. Development branch: `development`
+- Commit messages use prefix tags: `[Add]`, `[Update]`, `[Remove]`, `[Fix]` — except for issue-fixing commits produced by `/implement-extensions` and `/implement-extensions-batch`, which use the canonical short form `Fix #<n>` (single issue) or `Fix #<n1> #<n2> …` (batch) so GitHub auto-closes the issues on merge.
+- Main branch: `master`. Development branch: `development`. **All feature work targets `development`** via PR; `master` is downstream only.
 - CI: GitHub Actions (`CodeQuality.yml`) — builds, tests, and runs SonarQube analysis
 - License: Apache 2.0 (code), LGPL v3.0 (metamodel files)
 - To add a new metaclass: update the UML XMI source files, then run the code generators — do not manually create AutoGen files
 
+## Branch & PR workflow (MANDATORY)
+
+Direct pushes to `development` or `master` are forbidden. All work lives on a feature branch.
+
+**Agent boundaries are strict and minimal**:
+
+1. The agent **must NOT auto-commit, EVER.** `git commit` is the user's responsibility — no exceptions, no asking, no "for convenience". The user reviews `git diff` and commits manually.
+2. The agent **must NOT push commits, open PRs, or merge by default.** Push + PR + merge are the user's job too. The agent only performs push/PR if the user explicitly asks for them in-conversation; otherwise it stays out of git remote operations entirely.
+3. **When the agent creates a branch** (typically inside `/implement-extensions-batch` step 6), it must:
+   - create it locally with `git switch -c <branch> origin/development`, AND
+   - **immediately push the empty branch to `origin`** with `git push -u origin <branch>`, so the remote ref exists at the same commit as `origin/development` and the user's later push of the actual commit becomes a trivial fast-forward.
+   This is the only push the agent performs by default. It is safe because the branch tip equals `origin/development`'s tip — no new commits, no force flags, no risk of overwriting.
+4. **At the end of any task that creates a branch**, the agent stops with a final summary that includes:
+   - the in-scope files modified, the test counts, the reviewer verdict, etc.,
+   - a **pre-filled commit message** (`Fix #<n>` for single-issue runs, `Fix #<n1> #<n2> …` for batches — single line, no body, no `Co-Authored-By` trailer, no "🤖 Generated with …" footer),
+   - a handoff line telling the user how to stage + commit + push the resulting commit themselves. Example:
+     > Review `git diff`, stage the in-scope files (`git add <path> …` — NEVER `-A` / `.`), commit with the message above, then `git push` (the remote branch already exists, so this is a fast-forward — no `-u` needed). Open the PR yourself via the GitHub UI or `gh pr create --base development`.
+   - This is the end of the agent's involvement. **The agent does NOT proceed to push the commit, does NOT open the PR**, unless the user explicitly asks. Typical case: the user handles both.
+
+**If the user does explicitly ask the agent to push or open the PR** (rare; user-initiated only):
+- The agent verifies: current branch is not `development`/`master`, `git log -1` matches the canonical `Fix #<n>…` form, `git status --porcelain` is empty.
+- Then `git push origin <branch>` — NEVER `--force`, NEVER `--force-with-lease`, NEVER `--no-verify`.
+- Then `gh pr create --base development --head <branch> --title "Fix #<n>…" --body-file <pr-body-tmp>` — NEVER `--base master`, NEVER `--draft` unless the user asked.
+
+**Failure modes**:
+- `git push -u origin <branch>` (step 3) fails because the branch already exists on origin → abort, surface to user, do not force.
+- Branch creation requested but the current branch is `development` or `master` AND the user asked for in-place work → REFUSE. Feature work must live on a feature branch first.
+- If the user asks the agent to push a commit and that commit was made by the agent (somehow), refuse and surface the policy violation. The agent's commits are forbidden by construction; if one exists, it is a bug that needs human review.
+
+**Why this split**: the user is the reviewer of record. The commit is the review and the push is the delivery — both are the user's calls. The agent's git involvement is bounded to: (a) create the branch locally + push the empty ref (so the user's push later is frictionless), and (b) leave the rest alone. This was tightened after two failures: first the agent auto-pushed branches to `development` directly, then over-corrected by auto-committing on the user's behalf.
+
 ## Quality rules
 
 - Prefer comparing 'Count' to 0 rather than using 'Any()', both for clarity and for performance