@event4u/agent-config 16.2.0 → 16.4.0

package/dist/agent-src/commands/pr/create.md

@@ -101,7 +101,7 @@ Run, in order:
 | Gate | Overlapping open PR touches same files? | Action |
 |---|---|---|
 | exit `0`, prints `branch is current` | — | Proceed to Step 2 |
-| exit `1` | No | **Merge the base in** — `git fetch origin && git merge origin/{resolved-base} --no-edit` — then run the regeneration set below, then proceed. No need to ask; state that you did it. |
+| exit `1` | No | **Bring the base in** per `git.update_strategy` ([`branch-update`](../../../../skills/git-workflow/references/branch-update.md)). `merge` (default): `git fetch origin && git merge origin/{resolved-base} --no-edit` — no need to ask; state that you did it. `rebase`: ask first unless `git-history-discipline` already authorises the rewrite (see `branch-update` for the three cases), never fall back to a merge, and on an already-pushed branch run `branch-update`'s pre-rewrite stop and push with its `--force-with-lease` form. Then run the regeneration set below, then proceed. |
 | exit `1` | **Yes** | STOP — surface the overlapping PR number, ask: stack on top of it / wait for it to land / proceed-anyway-and-accept-conflicts / cancel |
 | exit `0`, prints `NOT VERIFIED` | — | The base could not be reached, so freshness is **unknown** — not confirmed. Re-run once; if it persists, say the check did not run rather than reporting a pass. A base that `ls-remote` cannot resolve (deleted or renamed after the PR opened, or a fork base) lands here too. |
 | warns `could not ask the forge` | — | The **default** base was checked and an open PR against a different base was **not** ruled out. Say so; do not report it as a clean freshness pass. |
@@ -137,8 +137,22 @@ a generated-file conflict never is.
 
 The gate above is not creation-only. **Every subsequent push** to a branch with
 an open PR (a CI fix, a review response, a follow-up commit) re-runs the same
-sequence first: `check_branch_freshness` → on exit `1`, merge
-`origin/{resolved-base}` in → regenerate the derived files → verify → push.
+sequence first: `check_branch_freshness` → on exit `1`, bring
+`origin/{resolved-base}` in per `git.update_strategy` (merge by default; under
+`rebase` a rebase that is asked for, never a merge, and `sync_pr_branch` refuses
+a behind branch with exit 3)
+→ regenerate the derived files → verify → push (after a rebase:
+`git push --force-with-lease=refs/heads/<b>:<sha> <remote> HEAD:refs/heads/<b>`,
+never a plain push). A rebase runs only through § The rebase sequence in
+[`branch-update`](../../../../skills/git-workflow/references/branch-update.md):
+the ref the branch publishes is resolved from `@{push}` or the pull request's
+head repository — never `@{u}`, and an unresolved target means no rewrite — its
+SHA is pinned once after the fetch, must already be in `HEAD`, and is the lease
+unchanged — so a collaborator's push lands either before the pin and halts the
+stop, or after it and fails the lease, and is never overwritten.
+Its steps 1–3 rebase and report, then stop: the regenerate → verify above runs
+on the rebased tree, and only then does its step 4 publish, re-running step 1
+with the `SAVE` and `EXPECTED` step 3 printed.
 A PR that sits open while its base advances goes stale silently; keeping the
 base merged **at every touch** means it stays `mergeStateStatus: CLEAN` instead
 of accumulating conflicts for the moment the user wants to merge. If the gate
@@ -160,9 +174,13 @@ runner; the hook never merges, because a merge inside `pre-push` rewrites the
 tree at the moment you believe your work is finished.
 
 **The resolution is executable now, not just described.**
-`./scripts-run src/scripts/sync_pr_branch` resolves the base from the open PR
-(so a stacked or release-line PR is measured against what it actually merges
-into), fetches, and merges it in when the branch is behind. The base is a
+`agent-config git:convention sync --base origin/<base>`, `<base>` being the
+`baseRefName` of the branch's `OPEN` pull request (`gh pr view --json
+state,baseRefName`; a closed or merged one does not count, and without an open
+one the base is the default branch), fetches and merges that
+base in when the branch is behind, so a stacked or release-line PR is measured
+against what it actually merges into. It never asks the forge itself: without
+`--base` the target is the default branch, which is right only for a PR into it. The base is a
 **set**: when the PR targets something other than the default branch, whether
 the default branch joins the set is a per-target policy read from the *target's
 own commit*, never from this branch — see `src/scripts/_lib/branch_convergence.ts`.
@@ -255,9 +273,9 @@ Run `/create-pr:description-only` Steps 1–4 to generate the PR title and body.
 This handles: Jira ticket extraction, diff analysis, commit messages, **PR template filling**.
 
 The generation honors the cached content flags from step 1 (§4f):
-`detail_level` sets the Description tier (default `min`), `api_examples`
-adds a grounded JSON block for API-endpoint changes, and `screenshots`
-(capability-gated) adds frontend screenshots. Critical-info callouts
+`detail_level` sets the Description tier (default `min`) and `screenshots`
+(capability-gated) adds frontend screenshots; a grounded JSON block for
+API-endpoint changes is always added (`/create-pr:description-only` § 4.3). Critical-info callouts
 (breaking changes / migrations / security / rollback) appear at every tier.
 
 **CRITICAL**: The PR body MUST use the project's PR template (`.github/pull_request_template.md`).
@@ -321,18 +339,15 @@ user request.
 - **Head branch**: EXACT output of `git branch --show-current` from step 1.
 - **Base branch**: default branch (`main` / `master`).
 
-**Behavior change vs. legacy:** with `verbosity.routine_confirmations:
-false` (default), `/create-pr` creates the PR as draft silently. Override
-per-invocation with `:ready` / `:final` / `:draft`. Restore the prompt
-by flipping `routine_confirmations: true`. See
-[`docs/customization.md` § Verbosity](../../docs/customization.md#verbosity).
+`/create-pr` creates the PR as draft silently — draft-or-ready is a routine
+confirmation with one obvious answer, so it is never asked. Override
+per-invocation with `:ready` / `:final` / `:draft`.
 
 Resolve `"draft"` (first match wins):
 
 1. `:ready` / `:final` arg → `false`.
 2. `:draft` arg → `true`.
-3. `routine_confirmations: true` → ask `1. draft / 2. ready`.
-4. Default → `true` (silent draft).
+3. Default → `true` (silent draft).
 
 #### 3a. Tool selection — single-call mandate
 
@@ -382,7 +397,7 @@ gh pr view {number} --json isDraft --jq '.isDraft'
 # returns true → gh pr ready {number}
 ```
 
-**Silent-draft postscript** (rule 4) → see step 4b.
+**Silent-draft postscript** (rule 3) → see step 4b.
 
 ### 4. After creation
 
@@ -420,14 +435,10 @@ Run this strip-pass **after PR creation and after every body PATCH**:
    the line entirely when nothing was stripped — silence is the
    expected path, not "no footers found").
 
-#### 4b. Show the PR URL (verbosity-gated)
+#### 4b. Show the PR URL
 
-Per `verbosity.post_action_reports` (default `minimal`):
-
-- `off` → nothing.
-- `minimal` → `→ #N opened: <url>`. Append `→ created as draft — run
-  \`gh pr ready N\` to flip` when silent-draft (rule 4); omit on ready.
-- `full` → multi-line: PR number, URL, draft state, base/head, ready-reminder.
+`→ #N opened: <url>`. Append `→ created as draft — run \`gh pr ready N\` to
+flip` when silent-draft (rule 3); omit on ready.
 
 #### 4c. Status claims — verified facts only (MANDATORY)
 
@@ -498,7 +509,8 @@ turns on `gh pr checks` every minute is the tool-loop
    untracked-`dist/` cases). When local and CI disagree, CI is authoritative.
 3. **Fix, then re-verify locally** with the narrowest command that proves the
    target green.
-4. **Bounded at N=3 per failing target** ([`autonomous-execution`](../rules/autonomous-execution.md)).
+4. **Bounded by the `execution.fix_loop_max` budget (default 10) and its
+   ladder, per failing target** ([`autonomous-execution`](../rules/autonomous-execution.md)).
    Same failure signature twice → the hypothesis is wrong; change approach
    rather than spending the third attempt on a near-identical retry.
 5. **The push stays gated — and a fix-the-CI instruction IS the gate being
@@ -571,19 +583,15 @@ an actual Jira API call succeeded** — never announce "skipped".
 
 #### 4f. Settings short-circuit — single read per run
 
-`verbosity.routine_confirmations`, `verbosity.post_action_reports`,
-`commands.create_pr.preview_description`, `commands.create_pr.detail_level`,
-`commands.create_pr.api_examples`, `commands.create_pr.screenshots`,
-`commands.create_pr.ui_paths`, and `commands.create_pr.api_paths` are read
-**once** at the top of the run and cached for the whole `/create-pr`
+`commands.create_pr.preview_description`, `commands.create_pr.detail_level`
+and `commands.create_pr.screenshots` are read **once** at the top of the run and cached for the whole `/create-pr`
 invocation. Do **not** re-read `.agent-settings.yml` in Step 2 or 4b / 4e —
 every branch resolves from the cached values from step 1. The content flags
-(`detail_level`, `api_examples`, `screenshots`, `ui_paths`, `api_paths`) are
-consumed by the `/create-pr:description-only` generation step (Step 2); the
+(`detail_level`, `screenshots`) are consumed by the `/create-pr:description-only` generation step (Step 2); the
 confirmation/report flags by steps 3–4.
 
-When all three resolve to their silent defaults (`false` / `minimal` /
-`false`), steps 4b + 4e collapse to the single `→ #N opened: <url>` line
+When `preview_description` resolves to its silent default (`false`), steps
+4b + 4e collapse to the single `→ #N opened: <url>` line
 from 4b and a silent 4e. No extra file reads, no "checking settings…"
 narration, no confirmation prompts. Step 4c is never collapsed — status
 claims always carry evidence.

package/dist/agent-src/commands/pr/merge.md

@@ -2,7 +2,7 @@
 model_tier: medium
 name: git-pr-merge
 disable-model-invocation: true
-argument-hint: "[all|<pr-number>] [--no-merge]"
+argument-hint: "[all|<pr-number>] [--merge|--no-merge]"
 pack: git
 intent: "Prepare an open PR to mergeable — sync the base in, resolve conflicts semantically, drive required checks green — then merge what the invocation named"
 routes_to: [git-workflow, github-ci]
@@ -35,6 +35,9 @@ AN EXPLICIT `/pr:merge` INVOCATION IS THE THIS-TURN CONFIRMATION, AND IT
 REACHES EXACTLY THE PRs § 1's MANIFEST SNAPSHOTTED FROM IT. IT NEVER REACHES
 A PR THAT ARRIVED LATER, A HEAD THE MANIFEST DID NOT RECORD, OR ANY OTHER
 HARD-FLOOR ACTION. `--no-merge` STILL STOPS BEFORE § 9.
+ADR-282: AN OWNER AUTO-MERGE INSTRUCTION (`--merge`, OR THE OWNER'S OWN WORDS IN
+THE SESSION) IS THE SAME CONFIRMATION FOR A `routine` PR. A `needs-council` PR
+MERGES ONLY ON TWO CONVERGENT CLEARING SEATS (§ 9a) — OTHERWISE THE OWNER DECIDES.
 ```
 
 **The invocation is the authorization, and nothing else is.** `pr-merge` is
@@ -76,7 +79,8 @@ merged (§ 5).
 | `/pr:merge <N>` | exactly PR N | yes | yes — PR N |
 | `/pr:merge` | ONE PR: green first, then infrastructure/tooling before content, then smallest diff (`changedFiles`, then additions+deletions), tiebreak ascending number | yes | yes — the one PR it selected |
 | `/pr:merge all` | the whole open-PR list, under § 6's cutoff | yes | yes — the manifest, in queue order |
-| `… --no-merge` | as above | yes | **never**, explicitly. This is the form [`/roadmap:process-full`](../../../product-basic/roadmap/process-full/command.md) calls for its delivery loop. |
+| `… --merge` | as above | yes | yes, through § 9a's danger gate — the form [`/roadmap:process-full`](../../../product-basic/roadmap/process-full/command.md) calls when the owner gave an auto-merge instruction (ADR-282) |
+| `… --no-merge` | as above | yes | **never**, explicitly. This is the form [`/roadmap:process-full`](../../../product-basic/roadmap/process-full/command.md) calls for its delivery loop without an auto-merge instruction. |
 
 **Bare invocation** (`/pr:merge` with no argument) is a **documented default
 flow**, not a menu: it runs the auto-selection in row 2 and says which PR it
@@ -132,14 +136,94 @@ says what happens to it instead.
 
 ## 2. Sync with the base
 
+Check the PR out, read the strategy against its base, then let one script do
+the update, so the branch-convergence policy (the base SET a non-default target
+carries) is read on every path. `show` takes the same `--base` as `sync` and
+runs after the checkout: without `--base` both read the default branch, and a PR
+into any other base would be judged against the wrong commit. `--key
+update_strategy` limits `show`'s exit to the strategy, so a `commit_format` or
+`branch_pattern` the PR head breaks does not stop the update.
+
 ```bash
 git fetch origin
 gh pr checkout <N>
-git merge origin/<base> --no-edit
+agent-config git:convention show --key update_strategy --base origin/<base>   # value, source, state
+agent-config git:convention sync --base origin/<base>
 ```
 
-Merge the base **into** the branch. Never rebase a branch that is already
-pushed ([`git-history-discipline`](../../../../rules/git-history-discipline.md)).
+A `git.update_strategy` whose state is `malformed`, `invalid`, `discarded` or
+`unresolvable` is not a strategy — `show` exits `1` on it and the script
+refuses it with exit 4, or with exit 1 when the target itself cannot be
+resolved — so stop on this PR and report the line `show` printed. A
+candidate in such a state (this checkout's uncommitted value) is a warning
+`show` prints with exit `0`; the script never reads it, so it does not stop
+the PR.
+The one narrowing: a base the server names whose commit could not be fetched is
+the `unverified` warning below (exit `0`, nothing merged); origin unreachable at
+the ref lookup is exit `1`. Otherwise
+the strategy decides what the script does — under `merge` it merges the base
+set in, under `rebase` it only checks, because a
+`Merge branch '<base>' into …` commit is what that setting excludes and the
+`/pr:merge` sentence authorises merging the named PRs, not rewriting their
+branches ([`git-history-discipline`](../../../../rules/git-history-discipline.md)).
+Read its exit and its line together:
+
+- exit `0` with a `✅` line → the PR is current with its base, or under `merge`
+  the base was merged in cleanly; go on to § 3.
+- exit `0` with a `⚠️` line reading `unverified` (the base commit or origin could not be fetched)
+  or `BYPASSED` (the convergence policy is disabled at the target) → **not
+  checked**: nothing is known about freshness. Stop on this PR and report the
+  line; it is never read as current.
+- exit `1` → a conflict report goes to § 3; a base that could not be resolved
+  (a `--base` the server does not know, no origin, origin unreachable) stops
+  this PR.
+- exit `3` → behind under a strategy other than `merge`. This run never
+  rebases a PR it did not author — the rebase is the author's, or a separate
+  request under
+  [`branch-update`](../../../../skills/git-workflow/references/branch-update.md).
+  What happens to the PR is an owner decision (recorded
+  2026-10-07), and it turns on one forge setting — whether the base requires an
+  up-to-date branch before merging:
+
+  ```bash
+  gh api repos/{owner}/{repo}/branches/<base>/protection \
+    --jq .required_status_checks.strict 2>&1; echo "exit=$?"
+  gh api repos/{owner}/{repo}/rules/branches/<base> \
+    --jq '.[] | select(.type == "required_status_checks") | .parameters.strict_required_status_checks_policy'; echo "exit=$?"
+  ```
+
+  Each read has three outcomes, told apart by the exit code and the message:
+
+  | Read | Absent | Value | Failed |
+  |---|---|---|---|
+  | classic protection | non-zero exit **and** the output contains `(HTTP 404)` (`Branch not protected`); or exit `0` with `null` — the branch is protected but requires no status checks | exit `0`: `true` or `false` | any other non-zero exit, or output that is not `true` / `false` / `null` |
+  | rulesets | exit `0` with empty output (no rule requiring status checks) | exit `0`: one or more lines, each `true` or `false` | non-zero exit, or a line that is not `true` / `false` |
+
+  A `404` from the classic endpoint is not a failed read: it is what a branch
+  protected only by rulesets, or not protected at all, returns; nor is `null`
+  from a `200`, which is a protected branch with no required status checks.
+  The rulesets read prints one line per ruleset on the base that requires
+  status checks, so a base covered by several prints several lines: **any**
+  `true` line reads as `true`; all lines `false` reads as `false`. Either reading
+  `true` means the forge requires an up-to-date branch; both absent or `false`
+  means it does not; a **failed** read is treated as required. A base
+  protected by rulesets alone is decided by the rulesets read.
+  - **The forge does not require an up-to-date branch**, and the PR is green
+    and conflict-free → it goes on to § 3–§ 9 and is merged behind its base;
+    the summary row says so (`merged behind <base>; the forge does not require
+    an up-to-date branch`). Its checks never ran against the current base, and
+    the summary is where that stays visible.
+  - **The forge requires an up-to-date branch** → disposition
+    `blocked-external`, the row naming that setting as the reason.
+  - **The line reads `TARGET_POLICY_STALE`** → the PR is current with its
+    non-default target and that target is itself behind its default branch:
+    `blocked-external`, reason "the target's update", whatever the forge
+    setting. A PR also behind its target gets the ordinary behind line instead,
+    with the target's lag as a note.
+- exit `4` → the strategy could not be read (the line names the reason code
+  and the file); nothing was checked or merged. Stop on this PR and report it.
+- any other exit → the check could not run (internal error); stop on this PR
+  and report the script's message.
 
 ## 3. Resolve conflicts by class, never by taste
 
@@ -281,6 +365,15 @@ After each merge the base has moved, so the next PR is re-synced against the
 NEW base — that is the loop, and it is why pre-greening several PRs ahead of
 their merges is wasted work.
 
+**Under a strategy other than `merge`**, every PR after the first is behind the
+base the previous merge moved, and this run rebases none of them. Where the
+forge does not require an up-to-date branch, a green, conflict-free PR that is
+behind still merges (§ 2, exit `3`) — three green branches merge without three
+sequential rebases — and each such row says it merged behind its base. Where
+the forge requires an up-to-date branch, the first merge leaves every remaining
+PR `blocked-external`, and the summary names that setting rather than leaving
+the reader to find it.
+
 **Under `--no-merge` that loop does not turn**, and the paragraph above is
 written for the form that does. Nothing merges, so the base does not advance,
 no PR leaves the open list, and the run is a **preparation sweep**: it syncs,
@@ -379,12 +472,41 @@ NO ROLLBACK, ONLY COMPENSATION, AND COMPENSATION IS A SEPARATELY AUTHORIZED
 HUMAN DECISION. STOP, EMIT THE MERGE SHAs AND THE REASON, HAND OVER.
 ```
 
+## 9a. Danger gate — before every merge (ADR-282)
+
+Once required checks are green on the manifest head and the PR is mergeable:
+
+```bash
+./scripts-run src/scripts/classify_merge_risk <N>
+```
+
+The last line is the verdict; each trigger names the rule it comes from. An
+unreadable diff is `needs-council` — the gate fails closed.
+
+- **`routine`** → merge in § 9. No review step.
+- **`needs-council`** → the AI council reviews the diff with a **neutral**
+  prompt (scope, diff, the triggers, two questions: *does any of the six
+  dangerous-action predicates of the authority-routing council record
+  (`agents/evidence/council/authority-routing-20261007.md` § 4) apply?* and *is
+  an owner review unnecessary?* — never an expected answer, per
+  `evaluator-independence`). A council may resolve doubt but cannot waive
+  danger: a seat finding that a predicate applies is a "dangerous" seat. Record the prompt and both
+  verdicts under `agents/evidence/`. **Both seats: not dangerous, owner review
+  unnecessary → merge.** Dangerous, split, degraded quorum, or council
+  unavailable → do not merge; record the PR `unauthorized` and hand it to the
+  owner with the seats' reasons.
+
+A `needs-council` clearance only clears the merge. Deploy, release and every
+other Hard-Floor action keep their own confirmation.
+
 ## 9. Merge, and the summary
 
 ```bash
-gh pr merge <N> --<detected-method> --delete-branch
+gh pr merge <N> --<detected-method> --delete-branch --match-head-commit <manifest-head-sha>
 ```
 
+`--match-head-commit` makes the forge refuse a head the manifest did not record.
+
 Detect the method once, at invocation, and reuse it for the whole queue:
 
 ```bash
@@ -409,8 +531,11 @@ run, so it does not exist until one has happened): one row per PR with queue
 position, the `base_ref@base_sha` it was prepared against — without it a
 "prepared" row records nothing checkable, since mergeability is a fact about a
 base and not about a queue —
-conflict classes hit, CI iterations used, disposition, and any edits dropped in
-conflict resolution. The disposition set is closed:
+conflict classes hit, CI iterations used, disposition **with its reason** —
+`merged behind <base>` where § 2 merged a PR its forge let through behind,
+`requires an up-to-date branch` or `TARGET_POLICY_STALE` for a behind PR left
+blocked — and any edits dropped in conflict resolution. Every PR the run saw
+gets a row; none is summarised away. The disposition set is closed:
 
 `merged <sha>` · `superseded-closed` · `blocked-external` · `twice-exhausted` ·
 `unauthorized` · `arrived-after-cutoff`
@@ -430,7 +555,9 @@ ends this run prepared and unmerged.
   `--no-merge` is the explicit way to say stop before § 9.
 - **Never widen, patch, or rebuild-around the git guard.** Verification of the
   authorization window is read-only.
-- **Never rebase a pushed branch**; the base is merged in.
+- **The base comes in per `git.update_strategy`**: under `merge` it is merged
+  in; under `rebase` this command never rebases — a behind PR is reported
+  (exit 3) and the rewrite stays the author's, under `git-history-discipline`.
 - **Never hand-merge a generated artefact**; regenerate it.
 - **Never resolve a conflict outside the four classes**; halt instead.
 - **Never call CI green off a local run**; re-verify on the pushed head.

package/dist/agent-src/commands/prepare-for-review.md

@@ -73,6 +73,15 @@ git checkout {child-branch}
 git merge {parent-branch} --no-edit
 ```
 
+- **Under `git.update_strategy: rebase`** do not merge the chain: a merge
+  commit on a feature branch is what that setting excludes, and this command
+  must not leave one behind to be pushed later. Check the target branch back
+  out, report which branches are behind their parent, and finish without error
+  — the review then runs against `git merge-base HEAD origin/<parent-branch>`
+  (the remote ref step 4 fetched; a local branch may be missing or stale), the
+  target's direct parent in the chain, so parent PRs stay out of it. Updating the
+  chain is a rebase the user asks for
+  ([`branch-update`](../../../skills/git-workflow/references/branch-update.md)).
 - If a **merge conflict** occurs at any point:
   - Run `git merge --abort`
   - Abort the entire process immediately
@@ -87,18 +96,11 @@ Once all merges succeed:
 git checkout {head-branch-of-target-PR}
 ```
 
-### 7. Report (verbosity-gated)
+### 7. Report
 
-Read `verbosity.post_action_reports` from `.agent-settings.yml` (default
-`minimal`).
-
-- `off` → emit nothing on success; surface warnings/errors only.
-- `minimal` (default) → one line:
-  `→ {branch} ready · {N} branches merged · {warnings or "clean"}`.
-- `full` → multi-line block listing:
-  - Which branch chain was processed (in order)
-  - That the target branch is now checked out and up to date
-  - Any warnings (e.g. branch was already up to date)
+One line on success:
+`→ {branch} ready · {N} branches merged · {warnings or "clean"}`.
+Warnings and errors are always surfaced.
 
 ## Rules
 

package/dist/agent-src/commands/project/analyze.md

@@ -129,15 +129,8 @@ LEGACY CHECK (indicators):
 ═══════════════════════════════════════════════
 ```
 
-Per `verbosity.routine_confirmations` (default `false`):
-
-- `false` → continue to Phase 2 silently (user invoked `/project-analyze`
-  for the full pass; "continue" is dominant).
-- `true` → ask:
-  ```
-  > 1. Continue with Phase 2 — architecture analysis
-  > 2. Stop here — keep the overview only
-  ```
+Continue to Phase 2 silently — the user invoked `/project-analyze` for the
+full pass, so "continue" is dominant and asking is a routine confirmation.
 
 ### 2. Architecture mapping
 
@@ -249,15 +242,8 @@ BUSINESS DOMAINS:
 ═══════════════════════════════════════════════
 ```
 
-Per `verbosity.routine_confirmations` (default `false`):
-
-- `false` → create domain analysis files silently (user invoked
-  `/project-analyze`; "yes, create" is dominant).
-- `true` → ask:
-  ```
-  > 1. Yes — create domain analysis files
-  > 2. Skip — continue with next phase
-  ```
+Create the domain analysis files silently — the user invoked
+`/project-analyze`, so "yes, create" is dominant.
 
 For each confirmed domain, create `agents/evidence/analysis/domains/{domain}.md` using the template
 from the `project-analyzer` skill.
@@ -286,14 +272,7 @@ SERVICE MAP:
 ═══════════════════════════════════════════════
 ```
 
-Per `verbosity.routine_confirmations` (default `false`):
-
-- `false` → create API + service analysis files silently.
-- `true` → ask:
-  ```
-  > 1. Yes — create API and service analysis files
-  > 2. Skip — continue with next phase
-  ```
+Create the API + service analysis files silently.
 
 Create:
 - `agents/evidence/analysis/api/endpoints-v1.md`
@@ -315,15 +294,8 @@ Write all remaining analysis files that haven't been created yet:
 - `agents/evidence/analysis/modules/{module}.md` — one per module
 - `agents/evidence/analysis/testing/test-map.md` — test suites, coverage, strategy
 
-Per `verbosity.routine_confirmations` (default `false`):
-
-- `false` → create all listed files silently (per-file picker is pure
-  noise once the user invoked `/project-analyze`).
-- `true` → for each file, ask:
-  ```
-  > 1. Create — {filename}
-  > 2. Skip
-  ```
+Create all listed files silently — a per-file picker is pure noise once the
+user invoked `/project-analyze`.
 
 ### 8. Gap analysis & action plan
 

package/dist/agent-src/commands/refine-ticket.md

@@ -28,7 +28,7 @@ packs:
 Accept one of four input paths:
 
 1. **Explicit key** — `/refine-ticket PROJ-123`
-2. **Branch detection** — no arg → `git branch --show-current` + regex `[A-Z]+-[0-9]+`
+2. **Branch detection** — no arg → `agent-config git:convention ticket` on the current branch ([`commit-subject`](../../../skills/git-workflow/references/commit-subject.md) § Reading the ticket)
 3. **Pasted text** — markdown block under the command
 4. **URL** — `/refine-ticket https://…/browse/PROJ-123`
 

package/dist/agent-src/commands/review/changes.md

@@ -39,10 +39,14 @@ to make sure the current branch is up to date with its base chain:
   - If exactly one open PR is found → invoke `/prepare-for-review`
     with that PR number. It will update `main`, fetch and merge the
     full branch chain into the current branch, and leave the current
-    branch checked out.
+    branch checked out — under `git.update_strategy: rebase` it merges
+    nothing and reports the behind branches instead.
   - If no open PR is found → fall back to a minimal local update:
     `git fetch origin main` and `git merge origin/main --no-edit` on
-    the current branch. Abort on conflict and report.
+    the current branch. Abort on conflict and report. Under
+    `git.update_strategy: rebase` skip the merge: `git fetch origin main`
+    only, review the diff against `git merge-base HEAD origin/main`, and say
+    the branch is behind.
   - If multiple PRs are found → ask the user which PR to use before
     proceeding.
 - If `/prepare-for-review` aborts (merge conflict, network error,
@@ -324,23 +328,12 @@ before re-review, hand off to
 generate→run→revise→re-run loop gated by a numeric threshold, then a judge
 confirms. Surface it as a single follow-up line; do not auto-invoke.
 
-### 7. Quality tools (verbosity-gated)
+### 7. Quality tools
 
-Per `verbosity.routine_confirmations` (default `false`):
-
-- `false` (default) → emit `→ run /quality-fix to format + lint` as a
-  single follow-up line; do not auto-invoke. User runs explicitly.
-- `true` → ask:
-  ```
-  > 1. Yes — run quality tools (formatter, static analyzer, linters)
-  > 2. No — review done
-  ```
-  If yes, hand off to the project's quality workflow (e.g.
-  `/quality-fix` or the equivalent configured command). The quality and
-  test runners are resolved per-stack via the
-  [`toolchain-resolver`](../../contexts/execution/toolchain-resolver.md), so
-  the hand-off adapts to PHP / JS-TS / Python / Go / Rust rather than
-  assuming one stack.
+Emit `→ run /quality-fix to format + lint` as a single follow-up line; do not
+auto-invoke and do not ask. The user runs it explicitly; its quality and test
+runners are resolved per-stack via the
+[`toolchain-resolver`](../../contexts/execution/toolchain-resolver.md).
 
 ## Backward compatibility
 
@@ -354,7 +347,9 @@ Per `verbosity.routine_confirmations` (default `false`):
   quality tools hand-off
 - The new step 1 (`/prepare-for-review`) is **best-effort**: if no
   open PR exists for the current branch, it falls back to a plain
-  `git fetch && git merge origin/main`. Existing invocations that
+  `git fetch origin main` and, under the default `git.update_strategy:
+  merge`, `git merge origin/main --no-edit`; under `rebase` it merges
+  nothing and reports the branch as behind. Existing invocations that
   ran on a fully detached or pre-PR branch keep working
 
 ## Use this command when

package/dist/agent-src/commands/roadmap/create.md

@@ -417,7 +417,7 @@ Declared by `produces_roadmap: true` in the frontmatter and enforced by
 `lint_roadmap_producers`: a producer that does not end here reds CI.
 
 Read `planning.closure_pass` (missing = `true`). When active, run
-[`/challenge-me closure`](../../../meta/challenge-me/closure/command.md) on the
+`/challenge-me closure` on the
 roadmap this command just produced, before handing back:
 
 ```bash

package/dist/agent-src/commands/roadmap/materialize.md

@@ -83,7 +83,7 @@ Declared by `produces_roadmap: true` in the frontmatter and enforced by
 `lint_roadmap_producers`: a producer that does not end here reds CI.
 
 Read `planning.closure_pass` (missing = `true`). When active, run
-[`/challenge-me closure`](../../../meta/challenge-me/closure/command.md) on the
+`/challenge-me closure` on the
 roadmap this command just produced, before handing back:
 
 ```bash

package/dist/agent-src/commands/roadmap/next.md

@@ -280,7 +280,16 @@ was for a conflict whose entire existence is a remote fact. That is the friction
 this clause removes; the floor it keeps is the *unnamed* push.
 
 **Before every push to the open PR**, bring the branch up to its base with
-`./scripts-run src/scripts/sync_pr_branch` and regenerate afterwards. Measured on
+`agent-config git:convention sync --base origin/<base>` (`<base>` is the
+`baseRefName` of the branch's `OPEN` pull request, read with `gh pr view --json
+state,baseRefName`; without an open one, and without `--base`, the target is the default branch) and regenerate afterwards (under
+`git.update_strategy: rebase` it refuses a behind branch with exit 3 — rebase on request instead, per
+[`branch-update`](../../../../skills/git-workflow/references/branch-update.md); an exit 3
+reading `TARGET_POLICY_STALE` means the branch is current with its non-default
+target and the target is itself behind its default branch — that is the target's update, reported, never a rebase of this
+branch; on exit 4 the
+strategy could not be read, the line names the reason code and the file, nothing
+was merged, and the run stops before the push until that file is fixed). Measured on
 this run: the base moved three times, the push was rejected twice for it, and the
 PR reached `CONFLICTING` in between. Verify the result afterwards with
 `./scripts-run src/scripts/check_pr_ci_current` — a green local gate says nothing