@event4u/agent-config 1.15.0 → 1.17.0

package/.agent-src/contexts/communication/rules-auto/review-routing-awareness-mechanics.md

@@ -0,0 +1,65 @@
+# Review Routing Awareness — mechanics
+
+Memory-lookup snippet, "do NOT overreach" guardrails, and anti-pattern
+catalog for the
+[`review-routing-awareness`](../../../rules/review-routing-awareness.md)
+rule. The four required-behavior steps and the "when this rule applies"
+trigger live in the rule; this file is the lookup material for the
+fallback path and the failure-mode list.
+
+## Memory-lookup fallback
+
+If neither `.github/ownership-map.yml` (or `agents/ownership-map.yml`)
+nor `.github/historical-bug-patterns.yml` (or
+`agents/historical-bug-patterns.yml`) exists, fall back to the
+engineering-memory layer via
+[`memory-access`](../../../../docs/guidelines/agent-infra/memory-access.md):
+
+```python
+from scripts.memory_lookup import retrieve
+extra = retrieve(
+    types=["ownership", "historical-patterns"],
+    keys=<changed file paths>,
+    limit=5,
+)
+```
+
+Curated memory (`agents/memory/ownership.yml`,
+`agents/memory/historical-patterns.yml`) carries the same schema as the
+project-local YAMLs and is merged into the routing output alongside
+them. If both memory and project YAMLs are absent, skip the rule and
+rely on [`reviewer-awareness`](../../../rules/reviewer-awareness.md)
+defaults. **Do not invent owners or patterns** from context.
+
+## Surface findings — worked examples
+
+When producing a review plan, include:
+
+- **Owner-mapped roles** — explicitly preferred over generic roles. If
+  the ownership map says `app/Billing/**` is owned by `finance-engineering
+  + security`, use those, not "backend + security".
+- **Historical-pattern warnings** — list every matched pattern with a
+  short label and the required control, e.g. _"Pattern: N+1 on tenant
+  listings → add an eager-load regression test"_.
+- **Confidence note** — if the ownership map is stale (last updated > 6
+  months ago per the `updated` field), say so. Ownership maps rot.
+
+## Do NOT overreach
+
+- **Never rename paths** or add ownership entries as a side effect of a
+  code change. Ownership map edits are a separate, explicit task.
+- **Never mark a change safe** only because no pattern matched. Pattern
+  absence means "no known hit", not "no risk".
+- **Never copy historical-pattern names into the diff** as code comments
+  or commit messages — they are routing metadata, not commentary.
+
+## Anti-patterns — reject them
+
+- Suggesting owners "because this looks like billing code" without
+  consulting the ownership map when one exists.
+- Inventing historical patterns from general knowledge — patterns must
+  come from the project's own registry.
+- Downgrading a matched high-severity pattern because "the author said
+  it's fine" — the pattern was registered because it bit before.
+- Treating an out-of-date map as absent. Flag staleness; do not silently
+  skip.

package/.agent-src/contexts/communication/rules-auto/roadmap-progress-sync-mechanics.md

@@ -0,0 +1,78 @@
+# Roadmap Progress Sync — mechanics
+
+Mechanics, triggers, and failure-mode catalog for the
+[`roadmap-progress-sync`](../../../rules/roadmap-progress-sync.md)
+rule. The Iron Laws and status semantics live in the rule; this
+file holds the lookup material the rule pulls when a trigger fires.
+
+## How to regenerate
+
+```bash
+./agent-config roadmap:progress
+```
+
+The `./agent-config` wrapper is written into the project root by the
+package installer and delegates to the master CLI inside
+`node_modules/@event4u/agent-config/` or `vendor/event4u/agent-config/`.
+No global tooling required.
+
+## Triggers
+
+| Edit | Must run, same response |
+|---|---|
+| **Create a new roadmap file** | regenerate dashboard |
+| **Rename or delete a roadmap file** | regenerate dashboard |
+| Mark step `[x]`, `[~]`, `[-]`, or unmark back to `[ ]` | regenerate dashboard |
+| Add, rename, or remove a phase | regenerate dashboard |
+| **Last `[ ]` flips** — roadmap reaches `count_open == 0` | `git mv` → `archive/` (or `skipped/`) **then** regenerate dashboard |
+| Move roadmap between `roadmaps/` ↔ `archive/` ↔ `skipped/` | regenerate dashboard |
+
+**Batching rule:** if you edit multiple checkboxes in one response, a
+**single** regeneration at the end of that response is enough — but
+the response must not end without it. If one of those edits closes a
+roadmap, archive it first, then run the single regen.
+
+## Pre-send self-check — MANDATORY
+
+Before sending any reply that touched `agents/roadmaps/`, run this
+silent gate:
+
+1. Did this turn create, rename, delete, or move a roadmap file? → regen MUST be in the reply.
+2. Did this turn flip any checkbox in a roadmap file? → regen MUST be in the reply.
+3. Did the regen output (`✅ Wrote agents/roadmaps-progress.md · …`) actually appear this turn? → if no, run it now before sending.
+4. **Autonomous roadmap execution gate** — did this turn complete a roadmap step (code saved + verification passed) without flipping its checkbox? → flip `[x]` (or `[~]` if multi-turn) and regen before sending.
+5. **Trackable-roadmap gate** — did this turn create or substantially edit a roadmap file? → does it now contain at least one `- [ ]` per non-intro phase, **or** carry `status: draft` in frontmatter? → if neither, add the checklist or the draft flag before sending.
+
+Any "yes" + no regen run = rule violation. Rerun before sending.
+
+## Failure modes
+
+- **Created the roadmap, marked Phase 1 done across multiple turns,
+  never regenerated** — dashboard silently lies "this roadmap does
+  not exist" to the next reader. Canonical failure of this rule;
+  the rule was hardened in response to it.
+- **Regenerated yesterday, edited today, "I'll regen at session
+  end"** — session ends from a crash, regen never lands.
+- **Closed a roadmap (last `[ ]` → `[x]`) and regenerated before
+  `git mv`** — the closed roadmap reappears in "Open roadmaps".
+- **Edited the dashboard by hand to "fix it quickly"** — next regen
+  overwrites the manual edit; no audit trail of why.
+- **Autonomous run, four steps shipped across four turns, dashboard
+  flat the whole time, single regen at the end** — user lost
+  progress visibility for the entire run. Each completed step must
+  flip its checkbox in the reply that ships it.
+- **Decision-only roadmap shipped without checkboxes** — file
+  contains decisions / ICE / block-sequencing but zero `- [ ]`,
+  dashboard shows `0/0` or omits it. Pair with a `## Phase N`
+  section or mark `status: draft` (CI catches this now).
+- **Headings off-canon (`### P0 #N`, `## Block A`, `### Sequencing
+  — Phase 1`)** — `PHASE_RE` skips them, roadmap invisible to the
+  dashboard. Rename to `## Phase <id>` or mark `status: draft`.
+
+## Do NOT
+
+- Do NOT edit `agents/roadmaps-progress.md` by hand — always regenerate.
+- Do NOT defer the regen to "next commit" or "before push" — same response.
+- Do NOT rely on CI (`--check` mode) as the first line of defence — CI is last-line, not real-time.
+- Do NOT skip the regen because "only one checkbox changed" — the dashboard aggregates counts and phase percentages that shift on single edits.
+- Do NOT leave a 100%-complete roadmap in `agents/roadmaps/` "for review" — `git mv` to archive **before** regenerating, otherwise it reappears in "Open roadmaps".

package/.agent-src/contexts/communication/rules-auto/skill-quality-mechanics.md

@@ -0,0 +1,62 @@
+# Skill quality — mechanics
+
+Description-triggering recipe, merge-preservation invariants, and
+compression-preservation invariants for the
+[`skill-quality`](../../../rules/skill-quality.md) rule. The minimum
+sharpness table, required sections, frontmatter contract, the
+skill-independence Iron Law, and the refactor-safety NEVER list live
+in the rule; this file is the lookup material when authoring or
+refactoring a skill.
+
+## Description Triggering
+
+Claude routes skills by reading the frontmatter `description`. Polite, generic,
+or hedged descriptions cause **undertriggering** — the skill never loads when it
+should, and the user never learns it exists.
+
+Make descriptions "pushy" — explicit about when to fire:
+
+- Start with a concrete verb phrase: `Use when ...`, `Creates ...`, `Reviews ...`.
+- Name 2+ concrete triggers — domains, symptoms, file types, user phrasing.
+- End with: `... even if they don't explicitly ask for \`<skill-name>\`.`
+- Avoid hedges: `may help with`, `can be useful for`, `covers various`.
+- **Keep it ≤ 200 characters.** `scripts/skill_linter.py` warns at
+  `description_too_long` above this. If the pushy tail pushes you over, cut
+  adjectives, drop the second example phrasing, or collapse a list — do
+  **not** drop the trigger vocabulary or the `even if ...` tail.
+
+Source: [`skills/skill-creator` in `anthropics/skills`](https://github.com/anthropics/skills/blob/main/skills/skill-creator/SKILL.md).
+
+**Litmus test:** Read the description cold, without the skill's body. If you
+cannot name at least two phrasings a user would realistically type that should
+route to this skill, the description is too polite. Rewrite it.
+
+## Merge Preservation
+
+When merging or refactoring skills, the merged result MUST preserve:
+
+1. **Strongest validation** from each source skill
+2. **Strongest example** (good/bad contrast) from each source
+3. **Strongest anti-pattern** from each source
+4. **All concrete decision criteria** that differ between sources
+
+A merge is invalid if:
+- Validation got weaker than the strongest source
+- Examples were lost without replacement
+- Anti-pattern coverage decreased
+- The merged skill became a generic umbrella doc
+
+## Compression Preservation
+
+When compressing a skill, the compressed version MUST preserve:
+
+- Trigger quality (description + When to use)
+- All procedure steps that contain decisions
+- All concrete validation checks
+- All gotchas and anti-patterns
+- Strongest example (at minimum one good/bad contrast)
+
+Compression may remove:
+- Verbose explanations
+- Redundant examples (keep the strongest)
+- Commentary that doesn't affect execution

package/.agent-src/contexts/communication/rules-auto/slash-command-routing-policy-mechanics.md

@@ -0,0 +1,55 @@
+# Slash-command routing — cluster mechanics
+
+Lookup table for the `slash-command-routing-policy` rule. Lists the
+locked clusters and their sub-commands so the rule itself can stay at
+its current LOC while still reflecting the full surface. Source of
+truth for the cluster names is
+[`docs/contracts/command-clusters.md`](../../../../docs/contracts/command-clusters.md);
+this file mirrors that contract for runtime lookup. Linter:
+`scripts/check_cluster_patterns.py` (verifies dispatcher shape).
+
+## Locked clusters and sub-commands
+
+| Cluster | Phase | Sub-commands | Replaces |
+|---|:-:|---|---|
+| `/fix` | 1 | `ci` · `pr` · `pr-bots` · `pr-developers` · `portability` · `refs` · `seeder` | `/fix-ci` · `/fix-pr-comments` · `/fix-pr-bot-comments` · `/fix-pr-developer-comments` · `/fix-portability` · `/fix-references` · `/fix-seeder` |
+| `/optimize` | 1 | `agents` · `augmentignore` · `rtk` · `skills` | `/optimize-agents` · `/optimize-augmentignore` · `/optimize-rtk-filters` · `/optimize-skills` |
+| `/feature` | 1 | `explore` · `plan` · `refactor` · `roadmap` | `/feature-explore` · `/feature-plan` · `/feature-refactor` · `/feature-roadmap` |
+| `/chat-history` | 2 | `show` · `resume` · `clear` · `checkpoint` | `/chat-history` (legacy status) · `/chat-history-resume` · `/chat-history-clear` · `/chat-history-checkpoint` |
+| `/agents` | 2 | `audit` · `cleanup` · `prepare` | `/agents-audit` · `/agents-cleanup` · `/agents-prepare` |
+| `/memory` | 2 | `add` · `load` · `promote` · `propose` | `/memory-add` · `/memory-full` · `/memory-promote` · `/propose-memory` |
+| `/roadmap` | 2 | `create` · `execute` | `/roadmap-create` · `/roadmap-execute` |
+| `/module` | 2 | `create` · `explore` | `/module-create` · `/module-explore` |
+| `/tests` | 2 | `create` · `execute` | `/tests-create` · `/tests-execute` |
+| `/context` | 2 | `create` · `refactor` | `/context-create` · `/context-refactor` |
+| `/override` | 2 | `create` · `manage` | `/override-create` · `/override-manage` |
+| `/copilot-agents` | 2 | `init` · `optimize` | `/copilot-agents-init` · `/copilot-agents-optimize` |
+| `/judge` | 2 | `solo` · `on-diff` · `steps` | `/judge` (legacy standalone) · `/do-and-judge` · `/do-in-steps` |
+| `/commit` | 2 | flag: `--in-chunks` | `/commit-in-chunks` |
+| `/create-pr` | 2 | flag: `--description-only` | `/create-pr-description` |
+
+## Routing semantics
+
+1. The user types `/<cluster> [<sub>] [args]`.
+2. Match the cluster against the table above. If the leading token is
+   a dispatcher cluster, route to the dispatcher's `commands/<cluster>.md`
+   and let the dispatcher's "Dispatch" section pick the sub-command.
+3. If the leading token is a flag-cluster (`/commit`, `/create-pr`),
+   the cluster file is the entry point itself; flags absorb the
+   former helper command.
+4. **Legacy atomic shims** (`/fix-ci`, `/agents-audit`, …) keep working
+   for one release cycle. They emit a deprecation warning and forward
+   to the cluster invocation. New invocations should always use the
+   cluster form.
+5. If a sub-command is unknown, the dispatcher prints the menu — never
+   guess.
+
+## Removal cycle
+
+| Cycle | Active form | Shim form |
+|---|---|---|
+| `1.15.x` / `1.16.x` | Phase 1 cluster commands | Phase 1 atomic shims |
+| `1.17.0` | Phase 1 + Phase 2 cluster commands | Phase 2 atomic shims (Phase 1 atomics removed) |
+| next minor after `1.17.x` | Cluster commands only | — (Phase 2 atomics removed) |
+
+Consumers see the canonical surface as the cluster form throughout.

package/.agent-src/contexts/communication/rules-auto/ui-audit-gate-mechanics.md

@@ -0,0 +1,53 @@
+# UI-audit gate — mechanics
+
+Findings-shape spec, failure-mode catalog, and cloud-surface
+adaptation for the
+[`ui-audit-gate`](../../../rules/ui-audit-gate.md) rule. The Iron
+Law, the activation triggers, the allow-list, and the action sequence
+when the gate fires live in the rule; this file is the lookup
+material when an agent has to verify what counts as findings or
+recognise a failure mode.
+
+## What "audit findings" means
+
+`state.ui_audit` is a non-empty dict carrying at least one of:
+
+- `components_found` — `{path, name, kind, similarity?}` inventory
+  entries from [`existing-ui-audit`](../../../skills/existing-ui-audit/SKILL.md).
+- `greenfield: true` plus `greenfield_decision` ∈
+  `{scaffold, bare, external_reference}`.
+- Legacy `components` alias — back-compat for the same shape.
+
+`null`, `{}`, or a dict without those keys is **not** findings;
+emit `@agent-directive: existing-ui-audit` instead of writing code.
+
+## Failure modes
+
+- Writing the component first and "thinking about reuse later".
+- Citing a similar-looking component from memory without verifying
+  it via the audit.
+- Treating `state.ui_audit = {}` as "audit ran, found nothing" —
+  empty dict is rejected on purpose; an audit that finds nothing
+  must record either ≥1 `components_found` or the greenfield branch.
+- Bypassing the gate for "just one tile".
+
+## Interactions
+
+- [`improve-before-implement`](../../../rules/improve-before-implement.md) — runs
+  first when the request is ambiguous; this rule is the next gate.
+- [`ask-when-uncertain`](../../../rules/ask-when-uncertain.md) — "just build it"
+  does **not** drop the audit; acknowledge, run audit, continue.
+- [`directives/ui/audit.py`](../../../templates/scripts/work_engine/directives/ui/audit.py)
+  — code-layer twin; this rule covers the cases where the engine
+  is not in the loop.
+- [`existing-ui-audit`](../../../skills/existing-ui-audit/SKILL.md) — the
+  skill that produces the findings.
+
+## Cloud Behavior
+
+On cloud surfaces the engine is not shipped, so `state.ui_audit`
+does not exist. The Iron Law still applies: take the visible
+inventory of files in conversation context as the audit, and
+surface a one-line audit summary in the reply before writing the
+component. The gate is satisfied by an explicit summary, not by
+silently skipping.

package/.agent-src/contexts/communication/rules-auto/user-interaction-mechanics.md

@@ -0,0 +1,77 @@
+# User Interaction — mechanics
+
+Format examples, common failure modes, progress indicators, and
+summary patterns for the [`user-interaction`](../../../rules/user-interaction.md)
+rule. Iron Law 1 (single-source recommendation) and Iron Law 2
+(pre-send self-check) live in the rule; this file is the lookup
+material for the format details.
+
+## Common failure modes — known, named, no excuses
+
+- **End-of-turn menu skipped.** Reply answers the question fine, then ends with `> 1. Foo > 2. Bar > 3. Stop` and no `Empfehlung:`. Iron Law 1 was violated — these are numbered options, position is irrelevant.
+- **"Genuinely no preference" hedge.** Pick anyway. The agent has more context than the user on the trade-off; refusing to pick dumps the work back. Pick the safest option, name the flip-condition.
+- **"User knows the project better" hedge.** Same failure mode, different costume. The user asked for an opinion by virtue of accepting the options block; deliver it.
+- **Multi-block reply with one recommendation.** Two options blocks but only one `Empfehlung:` line — the second block is unguarded. Rule 5 of Iron Law 2 closes this.
+
+## Examples
+
+**Binary choice:**
+
+```
+> 1. Interactive — ask before each comment
+> 2. Automatic — handle all independently
+
+**Recommendation: 1 — Interactive** — the comments touch security-sensitive code,
+so a wrong auto-fix is more expensive than approving each one. Caveat: flip to 2
+if the comments turn out to be pure formatting.
+```
+
+**Multiple choice with skip:**
+
+```
+> 1. Fix the code
+> 2. Fix the test
+> 3. Skip
+
+**Recommendation: 1 — Fix the code** — the test asserts the documented behaviour;
+the production code drifted from the contract. Caveat: pick 2 only if the contract
+itself is wrong.
+```
+
+**Confirmation with context:**
+
+```
+> Found PR #1399 on branch `chore/refactor-agent-setup-2`.
+>
+> 1. Yes, that's the right PR
+> 2. No, different PR — I'll provide the URL
+
+**Recommendation: 1 — Yes** — the branch name matches the PR title exactly.
+Caveat: flip to 2 if the PR was reopened from a different branch.
+```
+
+## When NOT to use numbered options
+
+- **Open-ended questions** where the answer is free text (e.g., "What should the class be named?").
+- **Simple yes/no** can use numbered options OR accept "ja"/"nein" directly.
+  Even for yes/no, prefer numbered options if there's additional context to show.
+
+## Progress Indicators
+
+When processing multiple items (e.g., review comments, test failures), show progress:
+
+```
+**Comment 3/7** — `filename.php:42`
+```
+
+## Summaries
+
+After completing a batch of actions, provide a summary table:
+
+```
+| # | File | Action |
+|---|---|---|
+| 1 | `file.php` | Fixed null check |
+| 2 | `test.php` | Updated assertion |
+| 3 | `config.php` | Skipped (intentional) |
+```

package/.agent-src/contexts/execution/autonomy-detection.md

@@ -0,0 +1,54 @@
+# Autonomy Detection — Logic
+
+Loaded by the [`autonomous-execution`](../../rules/autonomous-execution.md)
+rule when deciding whether a user message in `auto` mode flips standing
+autonomy on (or off). Anchor phrases and worked cases live in
+[`autonomy-examples.md`](autonomy-examples.md).
+
+## Recognize intent, not literal substring
+
+In `auto` mode, the rule flips to `on` for the rest of the conversation
+when the user expresses **"stop asking on trivial steps, just work"**.
+The LLM recognizes the **intent**, not a literal substring, and
+understands the semantic equivalent in either language.
+
+## Litmus test — standing permission vs single-decision delegation
+
+| Question | Outcome |
+|---|---|
+| Would a reasonable reader interpret the message as **standing permission to skip trivial workflow questions**? | Yes → flip. |
+| Is it a **single-decision delegation** ("you decide for this step", "for this one let me know what you'd pick")? | Handle that step autonomously, do **not** flip standing mode. |
+
+The flip is sticky for the rest of the conversation; single-decision
+delegation is one-shot.
+
+## Speech-act check — meta-instruction or content?
+
+Before flipping, verify the phrase is **addressed to the agent as
+guidance about how to work**, not a literal substring inside an
+unrelated instruction. The same words can be content, data, quote,
+copy, code, or subject matter — none of those flip.
+
+Do **not** flip when the phrase is:
+
+- **Content / copy** — "Put the slogan 'just do it' on the landing page."
+- **Quote / reference** — "Nike's tagline is 'just do it' — write a blog post about it."
+- **Subject of a request** — "Write docs about the 'work autonomously' modes."
+- **Code / data** — string literals, test fixtures, translations, JSON.
+- **About a third party** — "My colleague works autonomously."
+- **A question or hypothetical** — "Should I set `don't ask` as the default?"
+
+## Heuristic — strip and read
+
+Strip quotes, code blocks, and embedded content. Read what's **left**.
+If the remainder is still a directive to the agent about its own
+working style → flip. Otherwise → don't.
+
+## Opt-out is symmetric
+
+The reverse intent ("ask me again", "stop being autonomous") flips
+back to `off`. The same litmus test and speech-act check apply —
+"ask me first" inside a quote, code, or third-party reference does
+not flip.
+
+In doubt → keep current mode. No speculative flips.

package/.agent-src/contexts/execution/autonomy-examples.md

@@ -0,0 +1,90 @@
+# Autonomy Examples — Anchors, Trivial Cases, Failure Modes
+
+Loaded by the [`autonomous-execution`](../../rules/autonomous-execution.md)
+rule when concrete examples sharpen a decision. The detection algorithm
+lives in [`autonomy-detection.md`](autonomy-detection.md); the setting
+semantics live in [`autonomy-mechanics.md`](autonomy-mechanics.md).
+
+## Opt-in anchors — flip `auto` → `on`
+
+Multilingual phrases that, when spoken **as a meta-instruction to the
+agent** (per the speech-act check in [`autonomy-detection.md`](autonomy-detection.md)),
+flip standing autonomy on:
+
+- DE: "arbeite selbstständig" · "frag nicht jedes Mal" · "tue es einfach"
+- EN: "work autonomously" · "don't ask" · "just do it"
+
+Illustrative, not exhaustive — recognition is intent-based, not
+substring-based.
+
+## Opt-out anchors — flip back to `off`
+
+Reverse-trigger phrases (same speech-act check applies):
+
+- DE: "frag mich wieder" · "frag mich erst" · "stop autonomous mode"
+- EN: "ask me first" · "ask me again" · "stop being autonomous"
+
+## Speech-act check — patterns that DO NOT flip
+
+The same words can appear in many forms. None of these flip standing
+autonomy:
+
+- **Content / copy** — "Put the slogan 'just do it' on the landing page."
+- **Quote / reference** — "Nike's tagline is 'just do it' — write a blog post about it."
+- **Subject of a request** — "Write docs about the 'work autonomously' modes."
+- **Code / data** — string literals, test fixtures, translations, JSON.
+- **About a third party** — "My colleague works autonomously."
+- **A question or hypothetical** — "Should I set `don't ask` as the default?"
+
+Counter-examples — meta-questions, self-descriptions, or one-shot
+delegations also do **not** flip:
+
+- "Why don't you ask that yourself?"
+- "I'm working autonomously right now."
+- "Can you decide that yourself?"
+
+## Trivial — JUST ACT (in `on` or `auto`-after-opt-in)
+
+Eight worked cases. In `personal.autonomy: off`, ask these. In `on`
+or `auto`-after-opt-in, act on them.
+
+- "Should I start with Step 2 or Step 3?" — pick the obvious next step
+  on the roadmap and proceed; if blocked, name the blocker, otherwise go.
+- "Should we commit now or after the next change?" — answered by the
+  commit-default in [`commit-policy`](../../rules/commit-policy.md), no need to ask.
+- "How should I split the commits?" — never asked; either you are
+  invoked via `/commit-in-chunks` (split and commit) or you are not
+  (don't commit at all).
+- "Should I run the linter / tests now or after the change?" — run
+  what [`verify-before-complete`](../../rules/verify-before-complete.md)
+  requires; don't ask.
+- "I found 3 follow-up issues — fix all or stop?" — if they are within
+  the stated task scope and minimal-safe-diff allows, fix them; if they
+  expand scope, stop and surface them as a list.
+- "Filename should be `X.md` or `Y.md`?" when one matches the
+  surrounding convention — pick the convention-matching one.
+- "Do you want a verification table or paragraph?" — pick whichever
+  fits the conversation style; format is not a decision worth a turn.
+- "Show me a diff before regenerating output from a tracked source?"
+  — compression, code-gen, formatter passes, lock-file rebuilds — run
+  it and report the result. Reversibility comes from the source, not
+  from per-file confirmation. See [`non-destructive-by-default`](../../rules/non-destructive-by-default.md#not-in-scope--deterministic-regeneration)
+  § Not in scope.
+
+## Failure modes — autonomy side
+
+Wrong-behavior patterns this rule prevents:
+
+- Asking "Step 2 or Step 3?" when the roadmap orders them.
+- "Should I run the CI checks?" — `verify-before-complete` decides; act.
+- "Do we want to commit this?" — no, by default. Don't ask.
+- Numbered-options block whose only choice differences are sequencing
+  ("do A then B" vs "do B then A") with no real trade-off.
+- Asking after the user already issued a standing autonomy directive
+  earlier in the conversation (cache the opt-in for `auto`).
+
+For Hard-Floor failure modes (treating autonomy as cover for a
+floor-crossing action, reading a roadmap step as deploy authorization,
+refusing task-aligned WIP deletions, committing bulk-deletion / infra
+diffs without surfacing them) see
+[`non-destructive-by-default`](../../rules/non-destructive-by-default.md#failure-modes).

package/.agent-src/contexts/execution/autonomy-mechanics.md

@@ -0,0 +1,29 @@
+# Autonomy Mechanics — Settings and Platform Behavior
+
+Loaded by the [`autonomous-execution`](../../rules/autonomous-execution.md)
+rule when settings semantics or platform-specific defaults are
+relevant. Detection logic lives in [`autonomy-detection.md`](autonomy-detection.md).
+
+## `personal.autonomy` setting
+
+| Value | Behavior |
+|---|---|
+| `on` | Suppress trivial questions. Act on the obvious next step. Still ask on blocking / critical decisions, and ALWAYS ask on Hard-Floor triggers. |
+| `off` | Ask trivial questions too. Use this if you want the agent to check in on each workflow step. |
+| `auto` (default) | Same as `off` by default. Flips to `on` for the rest of the conversation as soon as the user expresses the intent "stop asking, just work". See [detection logic](autonomy-detection.md) — match by **intent**, not exact string. The flip never lifts the Hard Floor. |
+
+The value is read once on the first turn (per
+[`layered-settings`](../../../docs/guidelines/agent-infra/layered-settings.md#section-aware-merge-rules))
+and cached. Missing key → treat as `on`.
+
+## Cloud platforms — settings degrade to `on`
+
+Setting reads degrade gracefully on cloud platforms (no
+`.agent-settings.yml` available). Treat as `personal.autonomy: on` —
+the user had to deliberately ship a custom skill bundle to a cloud
+agent and is unlikely to want trivial-question friction.
+
+The Hard Floor still applies on every surface, including cloud. There
+is no "cloud override" for production-branch merges, deploys, pushes,
+prod data/infra, or whimsical bulk deletions — see
+[`non-destructive-by-default`](../../rules/non-destructive-by-default.md#cloud-behavior).

package/.agent-src/contexts/execution/verification-mechanics.md

@@ -0,0 +1,80 @@
+# Verification Mechanics
+
+Loaded by [`verify-before-complete`](../../rules/verify-before-complete.md).
+Holds the decision logic and lookup tables behind the Iron Law: when
+to run which verification command, the per-task-type evidence table,
+confidence gating, and the break-glass reduction during live
+incidents.
+
+**Size budget:** ≤ 4,000 chars. Tracked under Phase 6 of
+`road-to-pr-34-followups`.
+
+## When to run what — timing matters
+
+**Quality tools (PHPStan, Rector, ECS) run ONCE at the very end** — not after every edit.
+Do NOT run quality checks between tasks if you have more work to do.
+Only run the full quality pipeline when you are about to finish all work in the current conversation.
+
+**Tests: as targeted as possible, as little as necessary.**
+
+- During work: run ONLY the specific test class or test case affected by the change.
+  Use `--filter=ClassName` or `--filter=test_name` — NEVER the full suite mid-work.
+- Only run tests when you genuinely need to verify behavior (not "just to be safe").
+- Full test suite: ONCE at the very end, before quality tools.
+
+**The sequence at the end:**
+
+1. All code changes are done
+2. Run tests — targeted first (`--filter`), full suite only if targeted passes
+3. Run quality pipeline (PHPStan → Rector → ECS → PHPStan)
+4. Fix any issues from step 2-3
+5. ONLY THEN claim completion or suggest commit/push/PR
+
+## Minimum verification per task type
+
+| Task | Required evidence |
+|---|---|
+| Code change | Tests + PHPStan |
+| New feature | Tests + PHPStan + smoke test |
+| Bug fix | Regression test + full suite |
+| Refactoring | Full suite + PHPStan + Rector |
+| Config/migration | Relevant tests or command output |
+| API endpoint | curl/HTTP response output |
+| Documentation only | No verification needed |
+
+**Never accept** as proof: "should work", "looks correct", "logic is sound".
+No captured output = not verified.
+
+## Confidence gating
+
+State confidence explicitly before claiming completion on non-trivial work.
+
+- **High** — runtime path read end-to-end, relevant tests inspected or run,
+  no hidden side-effects (queues/events/observers) unaccounted for.
+- **Medium** — main path verified but one gap remains; list the gap in the
+  completion message.
+- **Low** — broad implementation NOT allowed; switch to analysis, narrow
+  the scope, or ask the user before proceeding.
+
+For high-risk areas (auth, tenancy, migrations, queues, dependencies,
+external APIs, data exposure), "high" requires tests AND a cross-layer
+read — not inference from a single file.
+
+## Break-glass reduction
+
+During a live production incident the verification gate is **narrowed**,
+never skipped. Break-glass requires explicit user invocation (e.g.
+`break-glass: true`, "this is a hotfix"). Never enter it unilaterally.
+
+Minimum evidence:
+
+- **Targeted test(s)** covering the exact regression — zero tests is not
+  acceptable.
+- **Smoke check** of the fixed path (curl, manual trigger, log tail) with
+  output captured in the message.
+- **Explicit list of skipped validations** and a **follow-up commitment**
+  (ticket or PR line) to run them within 24h.
+
+Completion wording: _"hotfix applied, full verification deferred per
+break-glass"_ — never _"done"_ or _"verified"_. The normal gate resumes
+on the follow-up PR.