@event4u/agent-config 1.19.0 → 1.21.0

package/.agent-src/rules/review-routing-awareness.md

@@ -3,105 +3,17 @@ type: "auto"
 tier: "2a"
 description: "When routing reviewers or flagging risk hotspots — consult ownership-map and historical-bug-patterns before suggesting reviewers or claiming a change is safe"
 source: package
-load_context:
-  - .agent-src.uncompressed/contexts/communication/rules-auto/review-routing-awareness-mechanics.md
+triggers:
+  - keyword: "reviewer"
+  - phrase: "risk hotspot"
+  - phrase: "ownership map"
+routes_to:
+  - "skill:review-routing"
 ---
 
 # Review Routing Awareness
 
-Before suggesting reviewers or declaring a change safe, the agent consults
-two project-local data sources — if they exist — to ground the routing in
-the consumer's actual organizational memory:
+**Iron Law.** Consult ownership-map and historical-bug-patterns before suggesting reviewers or claiming a change is safe.
 
-1. **Ownership map** — which roles/teams own which paths, with per-path
-   risk notes.
-2. **Historical bug patterns** — recurring failure modes or technical debt
-   the project has paid for before.
-
-Both live in the consumer repository (never in package-shipped files) and
-are optional. Absence is not an error — the agent falls back to
-generic, role-based suggestions from [`reviewer-awareness`](reviewer-awareness.md).
-
-## When this rule applies
-
-- The agent is classifying PR risk, suggesting reviewers, writing a PR
-  description, or producing a review plan.
-- The agent is reviewing its own diff before asking for human review.
-- The change modifies more than a trivial amount of code (≥ 1 file
-  outside docs).
-
-## Required behavior
-
-### 1. Check for project data
-
-Look, in order, for:
-
-- `.github/ownership-map.yml` (or `agents/ownership-map.yml`)
-- `.github/historical-bug-patterns.yml` (or
-  `agents/historical-bug-patterns.yml`)
-
-If neither file exists, fall back to the engineering-memory layer.
-Memory-lookup snippet and merge semantics live in
-[`contexts/communication/rules-auto/review-routing-awareness-mechanics.md`](../contexts/communication/rules-auto/review-routing-awareness-mechanics.md)
-§ Memory-lookup fallback. If both memory and project YAMLs are absent,
-skip this rule and rely on
-[`reviewer-awareness`](reviewer-awareness.md) defaults. **Do not
-invent owners or patterns** from context.
-
-### 2. Match the diff
-
-For every changed file, collect:
-
-- **Matching ownership entries** — each yields a role, optional focus
-  note, and optional risk hint.
-- **Matching historical patterns** — each yields a named prior failure
-  mode and the minimum control or test the project expects.
-
-Matching uses glob patterns (see
-[`review-routing-data-format`](../../docs/guidelines/agent-infra/review-routing-data-format.md)
-for the schema).
-
-### 3. Surface findings
-
-When producing a review plan, include owner-mapped roles (preferred
-over generic), historical-pattern warnings (with required control),
-and a staleness note if the ownership map's `updated` field is older
-than 6 months. Worked examples for each in
-[`contexts/communication/rules-auto/review-routing-awareness-mechanics.md`](../contexts/communication/rules-auto/review-routing-awareness-mechanics.md)
-§ Surface findings.
-
-### 4. Do NOT overreach
-
-The "do NOT overreach" guardrails (no path renames as side effects, no
-"safe because no match", no pattern names in diffs/commits) live in
-[`contexts/communication/rules-auto/review-routing-awareness-mechanics.md`](../contexts/communication/rules-auto/review-routing-awareness-mechanics.md)
-§ Do NOT overreach.
-
-## Interaction with other rules
-
-- Feeds [`reviewer-awareness`](reviewer-awareness.md) — this rule
-  **resolves** owners; reviewer-awareness **formats** them.
-- Extends [`verify-before-complete`](verify-before-complete.md) — if a
-  historical pattern demands a regression test, the verification gate
-  requires that test before completion is claimed.
-- Does not override [`minimal-safe-diff`](minimal-safe-diff.md) — a
-  matched pattern is a reason to **add a test**, never a reason to
-  expand scope into unrelated refactors.
-
-## Anti-patterns
-
-The four anti-pattern rejections (invented owners, invented patterns,
-downgrading high-severity hits, treating stale maps as absent) live in
-[`contexts/communication/rules-auto/review-routing-awareness-mechanics.md`](../contexts/communication/rules-auto/review-routing-awareness-mechanics.md)
-§ Anti-patterns.
-
-## See also
-
-- [`reviewer-awareness`](reviewer-awareness.md) — formatting reviewer
-  suggestions.
-- [`review-routing-data-format`](../../docs/guidelines/agent-infra/review-routing-data-format.md)
-  — YAML schemas for ownership-map and historical-bug-patterns.
-- [`review-routing`](../skills/review-routing/SKILL.md) — the skill
-  that produces the merged routing report.
-- [`judge-test-coverage`](../skills/judge-test-coverage/SKILL.md) —
-  consumes the "required test" output from historical patterns.
+Body migrated to `skill:review-routing` (per P4 of `road-to-kernel-and-router.md`).
+Trigger-set above activates this routing under the `balanced` and `full` profiles.

package/.agent-src/rules/reviewer-awareness.md

@@ -3,91 +3,16 @@ type: "auto"
 tier: "2a"
 description: "When suggesting reviewers for a change — anchor the choice in paths and risk, never prestige or seniority; require primary + secondary role for medium/high risk"
 source: package
+triggers:
+  - keyword: "reviewer"
+  - phrase: "suggest reviewers"
+routes_to:
+  - "skill:review-routing"
 ---
 
 # Reviewer Awareness
 
-When a change is medium- or high-risk, the agent suggests reviewer **roles**
-(not individuals) based on what the diff actually touches — not who is
-loudest, most senior, or who "usually reviews this kind of thing".
+**Iron Law.** Anchor reviewer choice in paths and risk, never seniority; medium / high risk requires primary + secondary role.
 
-## When this rule applies
-
-- The agent is asked to suggest reviewers, draft a PR description, or
-  consolidate a review plan.
-- The change is classified medium or high risk by
-  [`review-routing`](../skills/review-routing/SKILL.md), the
-  `pr_risk_review.py` script, or explicit user judgment.
-- For **low-risk** changes, reviewer suggestions are optional and may be
-  omitted.
-
-## Required behavior
-
-1. **Anchor every suggestion in the diff.** Name the path or change that
-   triggered the role — "backend because `app/Services/PaymentGateway.php`
-   changed", not "backend because it's a code change".
-2. **Two roles minimum for medium/high risk** — one **primary** (the
-   domain most at risk) and one **secondary** (cross-cutting sanity:
-   security, infra, domain owner).
-3. **Explain the focus area** for each reviewer — what they should look
-   at, not just that they should look. "security: confirm the new
-   authorization boundary actually denies cross-tenant reads".
-4. **Prefer ownership-mapped owners** when an ownership map exists
-   (see [`review-routing-awareness`](review-routing-awareness.md)). Fall
-   back to generic roles only when no mapping matches.
-5. **Never name individual reviewers** in package-shipped artifacts.
-   The consumer repo's CODEOWNERS or ownership map does the mapping
-   role → person.
-
-## Reviewer roles
-
-The reference set — extend per project, but keep these as the common
-vocabulary:
-
-| Role | Typical focus |
-|---|---|
-| `backend` | business logic, validation, side effects, data integrity |
-| `frontend` | UX, accessibility, client-side state, rendering |
-| `security` | authz, secrets, trust boundaries, data exposure |
-| `infra` / `ops` | rollout, migration safety, observability, retries |
-| `database` | schema changes, indexes, query plans, rollback realism |
-| `domain owner` | business invariants, policy intent, edge-case correctness |
-| `qa` | test coverage, regression scenarios, flake risk |
-
-## Anti-patterns — reject them
-
-- "Reviewers: @alice, @bob" inside a shared package artifact — individuals
-  live in the consumer's CODEOWNERS, not in package output.
-- "Any senior engineer" — prestige is not a review strategy.
-- "Whoever reviewed this last time" — selection by habit, not by
-  current risk.
-- One role for a 🔴 high-risk change — single-reviewer risk, especially
-  when the change crosses an authorization or tenancy boundary.
-- Suggesting reviewers without naming what they should look at — a
-  rubber-stamp invitation.
-
-## Format
-
-When the agent proposes reviewers, use this block:
-
-```
-Suggested reviewers (role-based):
-  • primary:   <role> — focus: <one line, anchored in diff>
-  • secondary: <role> — focus: <one line, anchored in diff>
-  (optional) additional: <role> — focus: …
-```
-
-## Rationale
-
-The right reviewer reduces blind spots more than the loudest reviewer.
-Blind-spot reduction comes from role diversity (different angles on the
-same diff), not from seniority.
-
-## See also
-
-- [`review-routing-awareness`](review-routing-awareness.md) — how
-  ownership maps and historical patterns feed reviewer selection.
-- [`review-routing`](../skills/review-routing/SKILL.md) — the skill that
-  produces the reviewer block.
-- [`requesting-code-review`](../skills/requesting-code-review/SKILL.md) —
-  PR preparation and self-review before asking for reviewers.
+Body migrated to `skill:review-routing` (per P4 of `road-to-kernel-and-router.md`).
+Trigger-set above activates this routing under the `balanced` and `full` profiles.

package/.agent-src/rules/roadmap-progress-sync.md

@@ -2,179 +2,16 @@
 type: "auto"
 tier: "1"
 description: "Any touch to agents/roadmaps/ — create/rename/delete/move, edit checkboxes ([x]/[~]/[-]), add/rename/remove phases — must regenerate dashboard and archive if 0 open items, same response"
-alwaysApply: false
 source: package
-load_context:
-  - .agent-src.uncompressed/contexts/communication/rules-auto/roadmap-progress-sync-mechanics.md
+triggers:
+  - path_prefix: "agents/roadmaps/"
+routes_to:
+  - "guideline:agent-infra/roadmap-progress-mechanics"
 ---
 
-<!-- cloud_safe: degrade -->
-<!-- Authoring discipline applies in cloud; local script + regen are no-ops there. -->
-
 # Roadmap Progress Sync
 
-> **Enforced by:** [`scripts/roadmap_progress_hook.py`](../../scripts/roadmap_progress_hook.py)
-> on Augment + Claude Code (`PostToolUse`). Hook is primary; the prose
-> below is the specification the hook implements and the fallback when
-> the platform has no hook surface.
-
-## Iron Law — dashboard sync
-
-```
-ANY ROADMAP TOUCH → REGENERATE THE DASHBOARD, SAME RESPONSE.
-NO EXCEPTIONS. NO "I'LL DO IT AT THE END". NO BATCHING ACROSS TURNS.
-A ROADMAP NOT IN THE DASHBOARD IS A RULE VIOLATION, NOT AN OVERSIGHT.
-```
-
-**Roadmap touch =** create the file, rename it, delete it, move it
-between `roadmaps/` ↔ `archive/` ↔ `skipped/`, add/rename/remove a
-phase, **OR** flip any checkbox (`[ ]` ↔ `[x]` ↔ `[~]` ↔ `[-]`).
-
-`agents/roadmaps-progress.md` is the read-only dashboard. Every
-unsynced edit makes it lie to the next reader. Created a roadmap
-without regenerating? The dashboard claims it does not exist. Marked
-8 steps `[x]` and forgot the regen? The dashboard says 0 done.
-
-## Iron Law — every active roadmap is trackable
-
-```
-EVERY ACTIVE ROADMAP MUST CONTAIN AT LEAST ONE TRACKABLE CHECKBOX
-(`- [ ]`) PER NON-INTRO PHASE. ROADMAPS WITHOUT EXECUTABLE STEPS
-EITHER GET A CHECKLIST OR THE `status: draft` FLAG.
-CI-ENFORCED: `scripts/check_roadmap_trackable.py` (CANNOT BE DEFERRED).
-```
-
-**Active roadmap =** any file in `agents/roadmaps/` (root, not
-`archive/` or `skipped/`) without `status: draft` frontmatter.
-
-**Trackable checkbox =** an actionable `- [ ]` line under a `## Phase N`
-or `### Phase N` heading (numeric `Phase 1`, roman `Phase II`, or
-letter-track `Phase A1` — matched by the dashboard's `PHASE_RE`).
-Tables of decisions, ICE matrices, ADR captures, and "block
-sequencing" tables are valid **rationale**, but they do not satisfy
-this rule on their own — they must be paired with at least one
-`## Phase N` section whose checkboxes execute the decision.
-Headings such as `## Phase steps`, `### Sequencing — Phase 1 …`,
-`### P0 #1 — …`, or `## Block A` do **not** count — only the
-canonical `Phase <id>` form parsed by the dashboard.
-
-**CI backstop.** `scripts/check_roadmap_trackable.py` (package-shipped,
-wire into the consumer's pre-commit / pre-push / Actions gate) fails
-when an active roadmap has zero canonical `Phase` headings or when
-any parsed phase has zero checkboxes. Last line of defence — real-time
-authoring still flips checkboxes and regenerates the dashboard the
-same response.
-
-## Status — binary `ready` (default) vs `draft`
-
-```yaml
----
-status: draft          # hidden from the dashboard until flipped
----
-```
-
-Two values, no synonyms. Anything else — no frontmatter at all,
-`status: ready`, an unknown value — counts as **ready** and lands
-in the dashboard.
-
-- **Ready** is the implicit default. New roadmaps are created
-  ready unless the user explicitly says draft. Ready roadmaps are
-  listed in the dashboard, count towards open/done totals, and
-  trip the "completed but not archived" warning when they close.
-- **Draft** hides the file from the dashboard entirely (not
-  counted, not listed). Use it while the roadmap is still being
-  authored, while waiting for upstream decisions, or as a
-  capture-only synthesis that has not yet been promoted to
-  executable phases. Flip to ready (or remove the field) the
-  moment the roadmap is ready to track.
-
-**Completion = archival, same response.** When the edit takes a
-roadmap to `count_open == 0` (every item is `[x]`, `[~]`, or `[-]`),
-`git mv` it into `agents/roadmaps/archive/` (or `skipped/` if no `[x]`
-at all) **before** regenerating the dashboard. A 100%-complete
-roadmap left under `agents/roadmaps/` is a rule violation, not an
-optional cleanup. See `roadmap-management` skill for the archive vs
-skipped decision table.
-
-## Agent-authored roadmaps — placement is mandatory
-
-```
-A FILE THE AGENT DROPS INTO agents/roadmaps/ MUST EITHER
-(a) PASS check_roadmap_trackable.py AND LAND IN THE DASHBOARD, OR
-(b) NOT BE IN agents/roadmaps/ AT ALL.
-NO "DECISION MATRIX" / "DESIGN NOTE" SHORTCUT.
-```
-
-When the agent autonomously creates a roadmap, it owns the placement
-in the **same response**:
-
-- **Phase plan** (checkboxes, multi-turn execution) → `agents/roadmaps/<name>.md`, `status: ready` (default), regen dashboard.
-- **Decision matrix / ADR / pattern / lookup** (no `Phase N`, durable rationale) → `agents/contexts/<name>.md`.
-- **Completed work snapshot** → `agents/roadmaps/archive/<name>.md`.
-
-A non-trackable file in `agents/roadmaps/` is a rule violation — the
-trackable CI fails it, the dashboard hides it. The agent that
-created it moves it the same response. If the autonomous run also
-**finishes** the roadmap within the session (every box `[x]`/`[~]`/`[-]`),
-the completion-archival rule above fires too — same response.
-
-## Autonomous execution — checkbox cadence
-
-When executing a roadmap autonomously (multi-turn, no per-step user
-prompt), the user loses progress visibility unless checkboxes flip
-**as work lands**, not in a batch at the end. Iron Law:
-
-```
-EVERY DONE STEP FLIPS [ ] → [x] IN NEXT REPLY THAT ACKNOWLEDGES IT.
-NO "I UPDATE ROADMAP AT END OF PHASE."
-NO "FOUR STEPS DONE, ONE COMMIT, ONE REGEN."
-```
-
-Step counts as completed when:
-
-- Code / docs change for that step has been **written and saved** AND
-- Verification cited in the step (project CI command, targeted test, lint) has
-  **passed in this response or an earlier one** — fresh output, not memory.
-
-Then in the **same reply**: flip the checkbox, regenerate the
-dashboard, commit if commit policy allows.
-
-**Forbidden:** four turns of step work, dashboard flat, single regen at the end.
-**Required:** each turn — implement step, flip `[x]`, regen, commit (if policy allows).
-A reply that lands a verified step without flipping its checkbox is a rule violation.
-
-**In-progress marker:** when a step takes more than one reply,
-mark it `[~]` the moment work starts on it and regenerate. The
-user sees one row move from `[ ]` to `[~]` to `[x]` instead of
-silent rows. `[~]` is treated as open for `count_open` but moves
-the phase percentage forward in the dashboard.
-
-## Mechanics — triggers, regen command, self-check, failures
-
-The triggers table, the regen command (`./agent-config roadmap:progress`),
-the mandatory pre-send self-check, the failure-mode catalog, and the
-`Do NOT` list live in
-[`contexts/communication/rules-auto/roadmap-progress-sync-mechanics.md`](../contexts/communication/rules-auto/roadmap-progress-sync-mechanics.md).
-Pull it whenever a trigger fires — the rule above is the obligation
-surface; the mechanics file is the lookup material.
-
-## Copilot fallback
-
-GitHub Copilot has no `PostToolUse` hook surface, so
-`scripts/roadmap_progress_hook.py` cannot detect roadmap-file writes
-structurally. The dashboard at `agents/roadmaps-progress.md` will
-not regenerate on its own.
-
-The cooperative path: every time a roadmap touch fires (per the
-trigger list in the mechanics context above), the agent regenerates
-the dashboard in the same response — which is the same Iron Law the
-hook enforces, just executed manually:
-
-```bash
-./agent-config roadmap:progress
-```
+**Iron Law.** Any touch to `agents/roadmaps/` regenerates the dashboard in the same response; archive the roadmap when 0 open items remain.
 
-The hook implementation is the specification; on Copilot the agent
-runs the regenerator itself after the same triggers fire. Skipping
-it is a rule violation, not a hook gap — the Iron Law on dashboard
-sync survives the missing hook surface.
+Body migrated to `guideline:agent-infra/roadmap-progress-mechanics` (per P4 of `road-to-kernel-and-router.md`).
+Trigger-set above activates this routing under the `balanced` and `full` profiles.

package/.agent-src/rules/role-mode-adherence.md

@@ -4,13 +4,17 @@ tier: "2a"
 description: "When roles.active_role is set in .agent-settings.yml — closing outputs must match the mode's contract and emit the structured mode marker"
 alwaysApply: false
 source: package
+triggers:
+  - keyword: "active_role"
+  - keyword: "role-mode"
+  - intent: "mode marker"
 ---
 
 # Role Mode Adherence
 
 Auto-activates when `.agent-settings.yml` sets `roles.active_role` to
 one of the six modes defined in
-[`role-contracts`](../../docs/guidelines/agent-infra/role-contracts.md):
+[`role-contracts`](../docs/guidelines/agent-infra/role-contracts.md):
 `developer`, `reviewer`, `tester`, `po`, `incident`, `planner`.
 
 Read `roles.active_role` from `.agent-settings.yml` at session start. Empty / missing → rule is inert; do NOT guess a mode.
@@ -47,7 +51,7 @@ Infer the mode (Phase-3 router does that). Touch `.agent-settings.yml`
 
 ## See also
 
-- [`role-contracts`](../../docs/guidelines/agent-infra/role-contracts.md)
+- [`role-contracts`](../docs/guidelines/agent-infra/role-contracts.md)
 - [`/mode`](../commands/mode.md)
 - [`ask-when-uncertain`](ask-when-uncertain.md)
 - [`scope-control`](scope-control.md)

package/.agent-src/rules/rule-type-governance.md

@@ -2,74 +2,16 @@
 type: "auto"
 tier: "2a"
 description: "Creating or editing rules, or auditing rule types — decides when a rule should be always vs auto"
-alwaysApply: false
 source: package
+triggers:
+  - path_prefix: ".agent-src.uncompressed/rules/"
+routes_to:
+  - "guideline:agent-infra/rule-type-governance"
 ---
 
-# rule-type-governance
+# Rule Type Governance
 
-## `always` = loaded every conversation
+**Iron Law.** Choose `always` vs `auto` per the governance table; over-broad `always` rules degrade the kernel budget.
 
-Use ONLY when the rule applies to virtually every interaction:
-
-- Universal agent behavior (language, tone, interaction style)
-- Safety constraints (scope control, verification before completion)
-- Token/efficiency constraints
-- First-message checks that cannot wait for auto-trigger
-
-## `auto` = loaded on demand by description match
-
-Use for everything else:
-
-- Language-specific rules (PHP, JS, SQL)
-- Tool-specific rules (Docker, Git, quality tools)
-- Workflow-specific rules (commands, skill creation, E2E testing)
-- Domain-specific rules (translations, architecture)
-
-## Decision test
-
-> "Does this rule need to be active when the user asks a simple question, reviews a PR, or discusses architecture?"
-
-- Yes → `always`
-- No → `auto` with a clear trigger description
-
-## Auto description quality
-
-The `description` field IS the trigger. It must describe **when** the rule applies, not **what** it contains.
-
-- ❌  `"PHP coding standards"` — too vague, won't match reliably
-- ✅  `"Writing or reviewing PHP code — strict types, naming, Eloquent conventions"`
-
-## Hard constraint
-
-- Default to `auto`. Justify `always`.
-- If >50% of conversations don't need a rule → it must be `auto`.
-- `optimize-agents` command checks this and suggests changes.
-
-## Hardening tier — required on new or edited rules
-
-Every new rule, and every edited rule whose body changes the trigger
-or the obligation, MUST classify itself against the hardening tiers
-documented in [`rule-trigger-matrix.md`](../../agents/contexts/rule-trigger-matrix.md):
-
-| Tier | Meaning |
-|---|---|
-| `1` | Mechanically enforceable — hook acts, rule body stays minimal. |
-| `2a` | Marker nudge — hook injects signal, agent acts on it. |
-| `2b` | Structured injection / tool-call gate — hook reads/writes state, may deny. |
-| `3` | Soft, judgment-bound — no platform surface; self-check rule. |
-| `safety-floor` | Iron-Law subset, never modified. |
-| `mechanical-already` | Precedent — script enforces, rule body documents. |
-
-Classification surface: the optional `tier:` frontmatter field
-(declared in `scripts/schemas/rule.schema.json`). Recommended for new
-rules; bulk-retrofit of existing rules is tracked separately.
-
-Tier 3 dispositions are recorded centrally in
-[`agents/contexts/tier-3-dispositions.md`](../../agents/contexts/tier-3-dispositions.md)
-with a 6-month re-audit clock. New Tier 3 rules append to that list
-on landing.
-
-The `optimize-agents` command checks the tier alongside `type`/`source`
-and suggests escalations when a rule's trigger matches a hardening
-opportunity that has shipped since the rule was authored.
+Body migrated to `guideline:agent-infra/rule-type-governance` (per P4 of `road-to-kernel-and-router.md`).
+Trigger-set above activates this routing under the `balanced` and `full` profiles.

package/.agent-src/rules/runtime-safety.md

@@ -3,6 +3,11 @@ type: auto
 tier: "2b"
 source: package
 description: "When a skill declares execution metadata — enforce safety constraints for assisted and automated execution types"
+triggers:
+  - keyword: "execution"
+  - keyword: "automated"
+  - keyword: "assisted"
+  - keyword: "handler"
 ---
 
 # Runtime Safety

package/.agent-src/rules/scope-control.md

@@ -5,7 +5,7 @@ description: "Scope control — no unsolicited architectural changes, refactors,
 alwaysApply: true
 source: package
 load_context:
-  - .agent-src.uncompressed/contexts/authority/scope-mechanics.md
+  - ../contexts/authority/scope-mechanics.md
 ---
 
 # Scope Control
@@ -14,73 +14,35 @@ load_context:
 - Do NOT replace existing patterns with alternatives.
 - Do NOT refactor existing code solely to comply with current rules.
 - Do NOT suggest new libraries unless explicitly requested.
-- Existing code should only be modified if directly related to the current change, required for bug fixes, security, or explicitly requested.
-- New or newly modified code MUST follow all coding rules.
-- Stay within the established project structure and conventions.
-- When unsure about the scope, ask the user.
+- Modify existing code only when directly related to the current change, required for bug fixes / security, or explicitly requested.
+- New / modified code MUST follow all coding rules.
+- Stay within established project structure and conventions.
+- When unsure about scope, ask the user.
 
 ## Git operations — permission-gated
 
-The user decides the git shape of the work. Never improvise.
-
-> **Commit specifics:** see the canonical [`commit-policy`](commit-policy.md)
-> rule — narrower than the general "no git ops without permission"
-> below (covers the never-ask-about-committing default and the
-> roadmap-authorized exception).
+The user decides the git shape. Never improvise. Commit specifics: canonical [`commit-policy`](commit-policy.md).
 
 - NEVER commit, push, merge, rebase, or force-push without explicit user permission.
-- NEVER create a new branch, switch to a different branch, or delete a
-  branch without explicit user permission. This includes spike, scratch,
-  throwaway, and worktree branches.
-- NEVER create, close, reopen, or change the target of a pull request
-  without explicit user permission.
-- NEVER push a tag or create a release without explicit user permission.
-- NEVER include version numbers, target releases, deprecation dates,
-  release-tied milestones, or git tags inside roadmaps, plans, tickets,
-  or any other planning artifact. Roadmaps plan **work**; releases and
-  tags are a separate decision the user makes outside the roadmap.
-  Never surface "which release should this ship in?" as an option in
-  numbered choices, ADRs, or roadmap text. If the user wants a release
-  pinned to a milestone, they will say so explicitly.
-- If a task seems to need a separate branch or PR, STOP and **brief
-  the user before asking** — see
-  [`scope-mechanics`](../contexts/authority/scope-mechanics.md)
-  § Brief-before-asking for the required Why / What / How sequence.
+- NEVER create / switch / delete a branch without explicit permission — includes spike, scratch, throwaway, worktree branches.
+- NEVER create, close, reopen, or change the target of a pull request without permission.
+- NEVER push a tag or create a release without permission.
+- NEVER include version numbers, target releases, deprecation dates, release-tied milestones, or git tags in roadmaps, plans, tickets, or any planning artifact. Roadmaps plan **work**; releases / tags are a separate decision outside the roadmap. Never surface "which release should this ship in?" as a numbered choice. User pins by saying so explicitly.
+- Task seems to need a separate branch / PR → STOP and **brief before asking** ([`scope-mechanics § Brief-before-asking`](../contexts/authority/scope-mechanics.md)).
 
-"Explicit permission" means the user said so **in this turn or in a
-standing instruction they have not revoked**. Earlier permission for a
-different operation does not carry over.
+"Explicit permission" = user said so **this turn or in a standing instruction not yet revoked**. Earlier permission for a different operation does not carry over.
 
 ## Production, infrastructure, bulk-destructive — Hard Floor
 
-A subset of the operations above is **never** autonomous and never
-auto-permitted by a standing autonomy directive. Canonical rule:
-[`non-destructive-by-default`](non-destructive-by-default.md). The
-trigger list (production-branch merges, deploys / releases, prod
-data / infra, bulk-destructive ops) and the
-"authorization is this turn, not earlier" clarification live in
-[`scope-mechanics`](../contexts/authority/scope-mechanics.md)
-§ Production, infrastructure, bulk-destructive.
+A subset is **never** autonomous and never auto-permitted by a standing autonomy directive. Canonical: [`non-destructive-by-default`](non-destructive-by-default.md). Trigger list (prod-branch merges, deploys / releases, prod data / infra, bulk-destructive ops) and the "authorization is this turn, not earlier" clarification: [`scope-mechanics § Production, infrastructure, bulk-destructive`](../contexts/authority/scope-mechanics.md).
 
 ## Decline = silence — no re-asking on the same task
 
-After the user **declines** a proposal (branch switch, PR creation,
-tag/release entry, separate worktree, version pinning in a roadmap),
-do **not** raise the same proposal again on the same task. The decline
-stands until the user reopens the topic themselves.
-
-Timing and "is this worth asking?" guidance lives in
-[`scope-mechanics`](../contexts/authority/scope-mechanics.md)
-§ Decline = silence — context.
+After the user **declines** a proposal (branch switch, PR creation, tag/release entry, separate worktree, version pinning), do **not** raise it again on the same task. Decline stands until the user reopens the topic. Timing / "is this worth asking?": [`scope-mechanics § Decline = silence`](../contexts/authority/scope-mechanics.md).
 
 ## Fenced step — user-set review gates
 
-When the user explicitly fences off the next step — *"don't implement
-yet"*, *"plan only"*, *"just write the roadmap, I'll review"*,
-*"review first"*, *"erst Roadmap, ich schau drüber"*, *"nichts
-implementieren"*, *"nur planen"*, *"erstmal nur X, dann ich"* — the
-agent's reply is **the deliverable plus a handoff**, never the
-deliverable plus *"shall we start?"*.
+User explicitly fences off the next step — *"don't implement yet"*, *"plan only"*, *"just write the roadmap, I'll review"*, *"review first"*, *"erst Roadmap, ich schau drüber"*, *"nichts implementieren"*, *"nur planen"*, *"erstmal nur X, dann ich"* — reply is **the deliverable plus a handoff**, never deliverable plus *"shall we start?"*.
 
 ```
 USER FENCED OFF EXECUTION → DELIVER + HAND BACK.
@@ -89,13 +51,6 @@ NO "READY TO IMPLEMENT?" RE-ASK.
 NO "STARTEN WIR MIT PHASE 1?" PIVOT.
 ```
 
-The fence stands until the user reopens the topic themselves, exactly
-like `Decline = silence` above. Permitted follow-up questions on the
-same turn cover **the deliverable** (adjust scope, fix wording, add a
-section), never **its execution**.
+Fence stands until the user reopens, exactly like `Decline = silence`. Permitted follow-up questions cover **the deliverable** (adjust scope, fix wording, add a section), never **its execution**.
 
-For the failure-mode catalog (Option 1 = "start now", re-asking after
-delivery, hand-off-to-execution drift, inferring acceptance from a
-thumbs-up) and the explicit bypass phrases that lift the fence, see
-[`scope-mechanics`](../contexts/authority/scope-mechanics.md)
-§ Fenced step.
+Failure-mode catalog (Option 1 = "start now", re-asking after delivery, hand-off-to-execution drift, inferring acceptance from a thumbs-up) and explicit bypass phrases: [`scope-mechanics § Fenced step`](../contexts/authority/scope-mechanics.md).

package/.agent-src/rules/security-sensitive-stop.md

@@ -4,6 +4,12 @@ tier: "2a"
 alwaysApply: false
 description: "Security-sensitive paths — auth, billing, tenant boundaries, secrets, file uploads, external integrations, webhooks, public endpoints — stop and run threat analysis BEFORE editing"
 source: package
+triggers:
+  - keyword: "auth"
+  - keyword: "billing"
+  - keyword: "tenant"
+  - keyword: "secret"
+  - keyword: "webhook"
 ---
 
 # Security-Sensitive Stop Rule
@@ -43,7 +49,7 @@ STOP writing code. Run the matching analysis skill first:
 | Wide refactor of security-sensitive code | `blast-radius-analyzer` |
 
 **Before running the analysis, consult memory for prior incidents** on
-this surface. Via [`memory-access`](../../docs/guidelines/agent-infra/memory-access.md):
+this surface. Via [`memory-access`](../docs/guidelines/agent-infra/memory-access.md):
 
 ```python
 from scripts.memory_lookup import retrieve