@event4u/agent-config 1.20.0 → 1.22.0

package/.agent-src/rules/onboarding-gate.md

@@ -2,126 +2,18 @@
 type: "auto"
 tier: "1"
 description: "First turn of a conversation on a project — check onboarding.onboarded in .agent-settings.yml; when false, prompt the user to run /onboard before executing any other request"
-alwaysApply: false
 source: package
+triggers:
+  - phrase: "first turn"
+  - keyword: "onboarding"
+  - path_prefix: ".agent-settings.yml"
+routes_to:
+  - "command:onboard"
 ---
 
 # Onboarding Gate
 
-> **Enforced by:** [`scripts/onboarding_gate_hook.py`](../../scripts/onboarding_gate_hook.py)
-> on Augment + Claude Code (`SessionStart`). The hook refreshes
-> `agents/state/onboarding-gate.json` from `.agent-settings.yml`; the
-> prose below is the spec the hook implements and the fallback for
-> platforms without a hook surface.
+**Iron Law.** First turn of a project: if `onboarding.onboarded` is false, prompt `/onboard` before executing any other request.
 
-Forces a one-time `/onboard` run for each developer on each project. This
-replaces the previously scattered "ask once" patterns across `user_name`,
-`personal.ide`, `personal.rtk_installed`, and cost profile confirmation.
-
-## When to activate
-
-Read `onboarding.onboarded` from `.agent-settings.yml` **once per
-conversation**, on the very first agent turn.
-
-- Key missing entirely → **legacy project**. Treat as onboarded, do
-  nothing. Do not write the key.
-- `true` → do nothing. Rule is inert for the rest of the conversation.
-- `false` → gate is active for this conversation (see below).
-
-Cache the result for the whole conversation. Do not re-read on every turn.
-
-## Gate behavior when `onboarded: false`
-
-On the **first** turn of the conversation, before executing the user's
-request, emit this prompt and stop:
-
-```
-> 👋 First-run setup hasn't been completed for this project.
->
-> Run /onboard once (≈2 minutes) to capture:
-> • your name, IDE, and rtk status
-> • cost profile + learning loop confirmation
->
-> 1. Run /onboard now
-> 2. Skip — mark as onboarded and continue with the request
-> 3. Snooze — continue just this turn; ask again next conversation
-```
-
-- `1` → invoke `/onboard`. Resume the user's original request afterwards.
-- `2` → set `onboarding.onboarded: true` in `.agent-settings.yml` (touch
-  only that field; preserve comments and order). Then execute the
-  original request.
-- `3` → proceed with the original request. Do not ask again in this
-  conversation. Do not write the file.
-
-Free-text replies (`"mach weiter"`, `"just do it"`) count as `3`.
-
-## Exceptions — do NOT block
-
-Skip the gate when the user's request already is an onboarding or
-settings operation, so we don't prompt users mid-setup:
-
-- `/onboard`, `/set-cost-profile`, `/mode`
-- The user explicitly asks about `.agent-settings.yml` or onboarding
-- Incident / break-glass signals (`hotfix`, `break-glass`, `"prod is
-  down"`). The gate waits for normal operations to resume.
-
-## Non-blocking for legacy projects
-
-If `.agent-settings.yml` exists but has no `onboarding` section at all,
-treat as onboarded. Only `onboarded: false` (explicit) triggers the
-gate. This protects projects that were set up before this rule shipped.
-
-## What this rule does NOT do
-
-- Write `onboarded: true` automatically. Only `/onboard` (step 6) and
-  the user's explicit `2` choice do that.
-- Re-prompt across turns in the same conversation. One prompt per
-  conversation, max.
-- Replace normal settings edits. Mid-life changes are ad-hoc (edit the
-  file directly or ask the agent, which follows
-  [`layered-settings`](../../docs/guidelines/agent-infra/layered-settings.md#section-aware-merge-rules));
-  this rule is a one-time gate.
-- Run on every agent turn. First turn only.
-
-## Interactions
-
-- `ask-when-uncertain` — the gate uses its numbered-options iron law;
-  one question per turn.
-- `language-and-tone` — prompt is translated to the user's language at
-  runtime; `.md` source stays English.
-- `scope-control` — option `2` writes exactly one key; no side effects.
-- `role-mode-adherence` — gate runs BEFORE the mode marker is emitted.
-
-## Copilot fallback
-
-GitHub Copilot has no `SessionStart` hook surface, so
-`scripts/onboarding_gate_hook.py` cannot run structurally and
-`agents/state/onboarding-gate.json` is not refreshed for the agent.
-On the first turn of a Copilot conversation:
-
-1. Read `onboarding.onboarded` from `.agent-settings.yml` directly
-   (one read per conversation, then cache as the prose above
-   describes).
-2. Optionally refresh the state file manually so other tooling sees
-   the same value the hook would have written:
-
-   ```bash
-   python3 scripts/onboarding_gate_hook.py < /dev/null
-   ```
-
-   The script reads `.agent-settings.yml`, atomically writes
-   `agents/state/onboarding-gate.json`, and exits 0 — same payload
-   the Augment / Claude / Cursor / Cline / Windsurf / Gemini hook
-   would have produced.
-3. Apply the gate behavior from "Gate behavior when `onboarded:
-   false`" above. The cooperative path is the spec; the hook is the
-   cache.
-
-## See also
-
-- [`/onboard`](../commands/onboard.md) — the command this gate invokes
-- [`layered-settings`](../../docs/guidelines/agent-infra/layered-settings.md) — merge rules for mid-life edits
-- [`agent-settings` template](../templates/agent-settings.md) — `onboarding.onboarded` reference
-- [`rule-type-governance`](rule-type-governance.md) — why this is `always`
-- [`hardening-pattern`](../../agents/contexts/hardening-pattern.md) — Tier 1 mechanical-rule contract
+Body migrated to `command:onboard` (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/package-ci-checks.md

@@ -1,46 +1,19 @@
 ---
 type: "auto"
 tier: "mechanical-already"
-alwaysApply: false
 description: "Before pushing to remote or creating a PR in the agent-config package — run all CI checks locally first"
 source: package
-load_context:
-  - .agent-src.uncompressed/contexts/communication/rules-auto/package-ci-checks-mechanics.md
+triggers:
+  - phrase: "task ci"
+  - phrase: "before push"
+  - phrase: "before pr"
+routes_to:
+  - "skill:lint-skills"
 ---
 
-# Package CI Checks
+# Package Ci Checks
 
-## When this applies
+**Iron Law.** Run `task ci` locally and confirm green before pushing or opening a PR in this package.
 
-Before **any** push to remote or PR creation in the **agent-config** package.
-This rule is specific to this package — it does NOT apply to consumer projects.
-
-## The Iron Law
-
-```
-NEVER push without running ALL CI checks locally first.
-```
-
-Every CI pipeline failure is preventable by running these checks before pushing.
-
-## Required checks — see mechanics
-
-Five checks must pass locally before push, in this order:
-
-1. **Sync** — `compress.sh --check` and `--check-hashes`.
-2. **Consistency** — `check_compression.py`, `check_references.py`, `check_portability.py`.
-3. **Linter** — `skill_linter.py --all`, 0 FAIL required.
-4. **Tests** — `pytest tests/`.
-5. **README** — `readme_linter.py`.
-
-The full command snippets, common-failure notes per step, the quick
-chained one-liner, and the post-edit workflow ("after editing
-skills/rules", "after editing `scripts/compress.py`") all live in
-[`contexts/communication/rules-auto/package-ci-checks-mechanics.md`](../contexts/communication/rules-auto/package-ci-checks-mechanics.md).
-Pull it whenever pre-push verification is needed.
-
-## Do NOT
-
-- Do NOT push "to see if CI passes" — that wastes pipeline minutes
-- Do NOT skip hash checks because "I only changed one file"
-- Do NOT assume tests pass because linter passes — they check different things
+Body migrated to `skill:lint-skills` (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/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.