@event4u/agent-config 1.20.0 → 1.21.0

package/.agent-src/rules/php-coding.md

@@ -2,63 +2,18 @@
 type: "auto"
 tier: "3"
 description: "Writing or reviewing PHP code — strict types, naming, comparisons, early returns, Eloquent conventions"
-alwaysApply: false
 source: package
+triggers:
+  - file_pattern: "*.php"
+  - keyword: "phpstan"
+  - keyword: "ecs"
+routes_to:
+  - "guideline:php/php-coding-patterns"
 ---
 
-# PHP Coding Rules
+# Php Coding
 
-- Use `declare(strict_types=1)` in every **new** PHP file. Not required when modifying existing files that don't have it.
-- If the project has a `Math` helper class, use it for ALL business calculations. Never use native PHP arithmetic operators (`+`, `-`, `*`, `/`) for business calculations. Search for the `Math` class in the project.
-- Never use `var_dump()`, `print_r()`, or `dd()` — they are disallowed by PHPStan config. Exception: legacy projects where these are already used and no alternative is feasible.
-- Never use `float` for money — use `decimal` or the `Math` helper.
-- Always use `===` / `!==` (strict comparison), Yoda style: `null === $var`.
-- Early return over nested if/else.
-- No one-liner if statements.
-- Single quotes for strings without interpolation. `sprintf()` for complex strings.
-- Variables: `camelCase`. Array keys: `snake_case`. Constants: `UPPER_SNAKE_CASE`.
-- Typed properties, parameters, and return types — always.
-- Constructor property promotion where it makes sense.
+**Iron Law.** PHP: strict types, named comparisons, early returns, Eloquent conventions — full pattern library in the guideline.
 
-## Eloquent Models — Attribute Access
-
-Read `eloquent.access_style` from `.agent-settings.yml` to determine the preferred style.
-Default: `getters_setters`. See the `eloquent` skill for the full reference table and examples.
-
-- **`getters_setters`** (strict): Every attribute has a typed getter + fluent setter. Inside the model: `getAttribute('column_name')`/`setAttribute('column_name', $value)`. Outside: always getters/setters. If a getter doesn't exist yet, create it first.
-- **`get_attribute`**: Use `getAttribute('column_name')`/`setAttribute('column_name', $value)` everywhere, no getters/setters needed.
-- **`magic_properties`**: Laravel default `$model->column_name` everywhere.
-
-### Relationship Getters
-
-- Every relationship MUST have a typed getter method **above** the relationship method.
-- **Inside the getter:** use `$this->getAttribute('relationship_name')`, NEVER `$this->relationship_name`.
-- **Outside the model:** ALWAYS use the getter (`$model->getEquipment()`), NEVER access the magic property (`$model->equipment`).
-- Use `instanceof` checks instead of `null ===` when checking relationship results.
-
-## Eloquent Models — Observers over `booted()`
-
-- Do NOT use `booted()` / `boot()` for model lifecycle hooks (saving, saved, deleted, etc.).
-- Use a dedicated **Observer** class registered via `#[ObservedBy]` attribute.
-- This keeps models slim and lifecycle logic testable and discoverable.
-
-## PHPStan
-
-- Always fix the root cause. Do NOT add entries to `phpstan-baseline.neon`.
-- Adding `ignoreErrors` to `phpstan.neon` is allowed for **structural toolchain limitations** (e.g., Pest runtime bindings). NOT for individual code issues. **If unsure → ask the user.**
-- If a fix is truly impossible (confirmed false positive), use an inline ignore as last resort:
-  ```php
-  // @phpstan-ignore-next-line — false positive: reason here
-  ```
-
-## Testing
-
-- Always write tests in **Pest**, not PHPUnit class syntax — unless the user explicitly asks for PHPUnit.
-- Pest tests in `tests/Unit/` automatically use `UnitTestCase` as the base class (configured in `tests/Pest.php`).
-
-## PHPDoc
-
-- Only add PHPDoc when type hints are insufficient (e.g. generic arrays: `@param array<int, MyObject> $items`).
-- Do NOT add PHPDoc that just repeats the method signature.
-- One docblock per method — never split into multiple `/** */` blocks.
-- Tag order: `@param` → `@return` → `@throws`.
+Body migrated to `guideline:php/php-coding-patterns` (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/preservation-guard.md

@@ -4,6 +4,15 @@ tier: "2b"
 alwaysApply: false
 description: "When merging, refactoring, compressing, or restructuring skills, rules, commands, or guidelines — prevent quality loss"
 source: package
+triggers:
+  - intent: "merge skill"
+  - intent: "compress rule"
+  - intent: "refactor artifact"
+  - keyword: "Iron Law"
+validator_ignore:
+  - type: "substring"
+    pattern: ".agent-src.uncompressed/"
+    reason: "Rule references the authoring tree as the operand of compression/preservation."
 ---
 
 # Preservation Guard

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