@event4u/agent-config 2.24.0 → 2.26.0

package/.agent-src/skills/rule-refactor/SKILL.md

@@ -0,0 +1,145 @@
+---
+name: rule-refactor
+description: "Use when the rule set is over the Augment budget, when a new rule would breach it, or when asked to audit / merge / prune rules — runs the audit pipeline and proposes a verdict per rule."
+source: package
+domain: process
+---
+
+<!-- cloud_safe: degrade -->
+
+# rule-refactor
+
+## When to use
+
+* `measure_augment_budget --check` fails (utilisation ≥ 0.95)
+* A new rule would push the budget over 0.95 — caught by the budget
+  gate in [`rule-writing`](../rule-writing/SKILL.md)
+* User says "audit rules", "rule cleanup", "rules over budget",
+  "prune rules", "merge rules", "rule system review"
+* Periodic governance pass after a batch of rule additions
+
+Do NOT use this skill for:
+
+* Editing a single rule's content → [`rule-writing`](../rule-writing/SKILL.md)
+* Picking always vs auto for one new rule → [`rule-writing`](../rule-writing/SKILL.md)
+
+## Iron Law
+
+**Threshold-lift is forbidden.** When the budget breaches, the
+content must shrink — not the gate. Loosening `FAIL_THRESHOLD` in
+`scripts/measure_augment_budget.py` to make CI pass is an explicit
+anti-pattern. The only valid budget-growth move is an ADR that
+raises `TOTAL_CAP`.
+
+## Procedure
+
+### 1. Inspect the current budget state
+
+```bash
+python3 scripts/measure_augment_budget.py --json > /tmp/budget-before.json
+python3 scripts/measure_rule_budget.py --json > /tmp/rule-budget-before.json
+```
+
+### 2. Run the audit pipeline
+
+The audit infrastructure already exists — compose it:
+
+```bash
+python3 scripts/audit_auto_rules.py      # → agents/reports/auto-rules-audit.{json,md}
+python3 scripts/audit_overlap.py         # → appends overlap pairs to the MD
+python3 scripts/audit_likelihood.py      # → agents/reports/auto-rules-likelihood.json
+```
+
+Then read `agents/reports/auto-rules-audit.md` end-to-end.
+
+### 3. Categorise every flagged rule
+
+For each rule the audit surfaces (overlap pair, low-likelihood, oversized,
+or the new addition that triggered this skill), assign exactly one verdict:
+
+| Verdict | Test |
+|---|---|
+| **keep** | Iron-Law / always-on safety net, no overlap, fires often |
+| **merge** | ≥ 2 rules same domain, near-identical triggers, overlap ≥ 0.4 |
+| **delete** | Never fires (low-likelihood + no path/keyword hit in 30 days), or fully subsumed by a skill |
+| **move-to-context** | Body is reference material (tables, mechanics, examples) — the obligation is short, the rest is lookup |
+| **promote-to-skill** | Body has numbered steps / a workflow — not a constraint |
+
+### 4. Present the verdict table to the user
+
+One Markdown table, one row per flagged rule, **before** any file
+change. User approves the list. No silent edits.
+
+### 5. Apply approved changes
+
+For each approved verdict:
+
+* **merge** → rewrite the surviving rule to cover both domains;
+  delete the absorbed one; update any `routes_to:` references.
+* **delete** → remove the file from `.agent-src.uncompressed/rules/`
+  and the corresponding `.agent-src/rules/` projection.
+* **move-to-context** → extract the body into
+  `.agent-src.uncompressed/contexts/<area>/<name>.md`, replace the
+  rule body with the obligation + a `load_context:` pointer.
+* **promote-to-skill** → create
+  `.agent-src.uncompressed/skills/<name>/SKILL.md`, replace the rule
+  with an auto-trigger stub that routes to it (or delete the rule
+  entirely if the skill's own trigger suffices).
+
+### 6. Re-validate
+
+```bash
+bash scripts/compress.sh --sync
+python3 scripts/compress.py --generate-tools
+python3 scripts/measure_augment_budget.py --check   # must exit 0
+python3 scripts/skill_linter.py --all               # 0 FAIL
+```
+
+Then run your package's full CI pipeline (see `Taskfile.yml` for the
+canonical sequence) before pushing.
+
+### 7. Record the delta
+
+Append a snapshot to `agents/.augment-budget-history.jsonl`:
+
+```bash
+python3 scripts/measure_augment_budget.py --trend-append
+```
+
+Commit the cleanup as a separate chunk from any rule-add commits so
+the history shows "added X" + "cleaned up Y" as distinct steps.
+
+## Output format
+
+1. Verdict table (approved by user) at the top of the cleanup PR description
+2. Per-verdict commits (one per merge / delete / move / promote group)
+3. Final `measure_augment_budget --check` output showing utilisation < 0.95
+4. Trend snapshot recorded
+
+## Gotchas
+
+* Do NOT raise `FAIL_THRESHOLD` to dodge the audit
+* Do NOT delete a rule that has a `routes_to:` pointer without
+  updating the pointer's source
+* Do NOT merge rules across tier boundaries (e.g. tier-1 always
+  with a tier-3 stub) without surfacing the tier collapse to the user
+* Do NOT skip the trend-append — the history is what tells future
+  agents how the cap was managed
+
+## Do NOT
+
+* Do NOT loosen the budget gate
+* Do NOT touch the cap (`TOTAL_CAP`) without an ADR
+* Do NOT apply changes before user approves the verdict table
+* Do NOT delete the rule-refactor audit reports — they're the
+  artifact reviewers cite
+
+## Cloud Behavior
+
+On cloud surfaces, the audit scripts are not reachable. The skill
+still applies — prose-only:
+
+* Inspect the rule list (frontmatter + descriptions) and propose the
+  verdict table from reading alone.
+* Tell the user to run the audit scripts locally before applying.
+* Do not attempt to call any script.

package/.agent-src/skills/rule-writing/SKILL.md

@@ -129,12 +129,38 @@ the PR or split by responsibility.
 * Run the full CI pipeline locally (see `Taskfile.yml` in this repo for
   the script list) — must exit 0 except for tolerated warnings.
 
+### 5b. Budget-discipline gate — hard stop
+
+After validation, before declaring the rule done, run:
+
+```bash
+python3 scripts/measure_augment_budget.py --check
+```
+
+If utilisation is `≥ 0.95` (or the check exits non-zero), **STOP** and
+invoke [`rule-refactor`](../rule-refactor/SKILL.md). Do NOT:
+
+* Trim the new rule further to "just fit" — if it needs that body to
+  do its job, the rule is right and the rule set around it is wrong.
+* Raise `FAIL_THRESHOLD` in `scripts/measure_augment_budget.py` —
+  threshold-lift is explicitly forbidden (see the
+  [`validation-budget`](../../rules/validation-budget.md) rule and
+  the `rule-refactor` Iron Law).
+* Promote an always-rule to auto to dodge the cap if the rule's
+  semantics require always-on visibility — that breaks the rule, not
+  the budget.
+
+The discipline: budget pressure is the signal that the rule **set**
+needs a cleanup pass, not that the new rule needs to be smaller. The
+`rule-refactor` skill runs the audit and proposes merge / delete /
+move-to-context / promote-to-skill so the new rule earns its space.
+
 ### 6. Governance baseline (when introducing a new linter check)
 
 **Advisory, reviewer-checked — no CI gate.** When the same PR adds a
-new check to `scripts/skill_linter.py` (or strengthens an existing one)
-such that previously-clean rules now warn, the PR body MUST record the
-pre-existing violations on `main` in a Markdown table:
+new check to `scripts/skill_linter.py` (or strengthens an existing
+one) such that previously-clean rules now warn, the PR body MUST
+record the pre-existing violations on `main` in a Markdown table:
 
 ```markdown
 ### Pre-existing baseline (informational)
@@ -144,11 +170,11 @@ pre-existing violations on `main` in a Markdown table:
 | {new_code} | N | (a) genuine fix · (b) accept · (c) check too aggressive |
 ```
 
-Forward-only: the new check applies to **the rule under review** and to
-**future** edits. The baseline table is informational so reviewers can
-distinguish genuine debt from acceptable carry-overs without diffing the
-full lint output. See `agents/analysis/lint-warning-triage.md` for the
-3-bucket reference.
+Forward-only: the new check applies to **the rule under review** and
+to **future** edits. The baseline table is informational so reviewers
+can distinguish genuine debt from acceptable carry-overs without
+diffing the full lint output. See
+`agents/analysis/lint-warning-triage.md` for the 3-bucket reference.
 
 ## Frontmatter shape
 

package/.agent-src/skills/scene-expander/SKILL.md

@@ -3,7 +3,6 @@ name: scene-expander
 description: "Use when expanding a one-line idea into the 12-block Cinematic Scene Blueprint — provider-agnostic, includes optional dialogue + ambient. Triggers 'expand this scene', 'blueprint for X'."
 personas:
   - hollywood-director
-  - pixar-storyboard-artist
 source: package
 domain: product
 ---
@@ -13,9 +12,10 @@ domain: product
 > Expand a one-line idea or script line into the **Cinematic Scene
 > Blueprint** — 12 labeled blocks consumed by
 > [`parse-blueprint.sh`](./scene-blueprint.schema.yaml). Picks
-> `hollywood-director` for live-action and `pixar-storyboard-artist`
-> for animated beats. Output is provider-agnostic — provider tuning
-> is [`motion-choreographer`](../motion-choreographer/SKILL.md).
+> `hollywood-director` for live-action; hands off animated beats to
+> [`pixar-storyteller`](../pixar-storyteller/SKILL.md). Output is
+> provider-agnostic — provider tuning is
+> [`motion-choreographer`](../motion-choreographer/SKILL.md).
 
 ## When to use
 
@@ -38,9 +38,11 @@ Do NOT use when:
 
 1. Read the input line. Classify as **live-action / photoreal** or
    **animated / stylized**.
-2. Live-action → load `hollywood-director` voice. Animated → load
-   `pixar-storyboard-artist`. Hybrid (live-action with VFX) →
-   `hollywood-director`; record VFX intent in ENVIRONMENT.
+2. Live-action → load `hollywood-director` voice. Animated → hand
+   off to [`pixar-storyteller`](../pixar-storyteller/SKILL.md) (its
+   procedure carries the acting / beat-decomposition lens). Hybrid
+   (live-action with VFX) → `hollywood-director`; record VFX intent
+   in ENVIRONMENT.
 3. Check for an existing `character.json` lock under
    `agents/ai-video/<project>/characters/`.
 
@@ -120,3 +122,16 @@ Any "no" → revise that block.
 - Do NOT paraphrase identity tokens when a lock exists.
 - Do NOT mix live-action LENS prescriptions with animated STYLE
   anchors in the same scene — pick one mode.
+
+## Policies
+
+The 12-block Cinematic Scene Blueprint is the policy choke point — every downstream skill (`motion-choreographer`, `video-director`) inherits whatever the blueprint encodes. Before emitting:
+
+- [`agents/policies/media/likeness.md`](../../../agents/policies/media/likeness.md) — when the SUBJECT block names or visually identifies a real person.
+- [`agents/policies/media/public-figures.md`](../../../agents/policies/media/public-figures.md) — when the SUBJECT block is a recognised public figure.
+- [`agents/policies/media/brand-impersonation.md`](../../../agents/policies/media/brand-impersonation.md) — when STYLE / ENVIRONMENT references a recognised brand's visual identity.
+- [`agents/policies/media/style.md`](../../../agents/policies/media/style.md) — when STYLE anchors to a named living artist or studio as the primary signature.
+- [`agents/policies/media/disclosure.md`](../../../agents/policies/media/disclosure.md) — every distributed blueprint output carries the AI-generation disclosure downstream.
+
+Refuse-and-surface at the blueprint layer; do not push policy questions down to the adapter.
+

package/.agent-src/skills/security/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: security
-description: "Use when applying security best practices — authentication, authorization via Policies, CSRF protection, input sanitization, rate limiting, or secure coding."
+description: "Use when applying security best practices — authentication, authorization, CSRF protection, input sanitization, rate limiting, or secure coding — stack-agnostic."
 source: package
 domain: quality
 ---
@@ -13,65 +13,74 @@ Use when implementing authentication, authorization, or any security-sensitive f
 
 Do NOT use when:
 
-* Validation logic only — route to [`laravel-validation`](../laravel-validation/SKILL.md)
-* Full security audit — route to [`security-audit`](../security-audit/SKILL.md)
-* You need a pre-implementation threat model — route to
-  [`threat-modeling`](../threat-modeling/SKILL.md)
-* You need end-to-end authorization analysis — route to
-  [`authz-review`](../authz-review/SKILL.md)
+* Validation logic only — route to the project's validation carve-out ([`laravel-validation`](../laravel-validation/SKILL.md) for Laravel; otherwise the framework-native primitive — Zod / class-validator, Pydantic, struct-tag validators).
+* Full security audit — route to [`security-audit`](../security-audit/SKILL.md).
+* You need a pre-implementation threat model — route to [`threat-modeling`](../threat-modeling/SKILL.md).
+* You need end-to-end authorization analysis — route to [`authz-review`](../authz-review/SKILL.md).
 
-## Procedure: Implement security for a feature
+## Stack-specific carve-outs
+
+The procedure below is stack-agnostic. For framework-specific primitives (Laravel Policies / Gates / FormRequests, Symfony voters, NestJS guards, Next.js middleware), defer to:
+
+| Stack | Carve-out |
+|---|---|
+| Laravel | [`laravel`](../laravel/SKILL.md), [`laravel-validation`](../laravel-validation/SKILL.md), [`laravel-middleware`](../laravel-middleware/SKILL.md) |
+| Symfony | [`symfony-workflow`](../symfony-workflow/SKILL.md) |
+| Next.js / TS | [`nextjs-patterns`](../nextjs-patterns/SKILL.md) |
+
+## Procedure: Implement security for a feature (stack-neutral)
 
 ### Step 0: Inspect
 
-1. Read `agents/authentication.md` for auth flow.
-2. Read `agents/gates.md` for gate/policy patterns.
-3. Check existing policies in `app/Policies/`.
+1. Read the project's auth doc (`agents/authentication.md`, `docs/auth.md`, or framework docs).
+2. Read the project's authorization doc (gates / policies / voters / guards).
+3. Locate existing authorization rules in the project's idiomatic location (Laravel `app/Policies/`, Symfony `src/Security/Voter/`, NestJS `*.guard.ts`).
 
 ### Step 1: Authentication
 
-- Check auth setup: `tymon/jwt-auth` or `laravel/sanctum`.
-- Check `config/auth.php` for guards and providers.
-- Customer identification happens after auth — see `multi-tenancy` skill.
+- Identify the auth mechanism in use (session, JWT, OAuth, API token) — read the framework's auth config (`config/auth.php`, `next-auth.config.ts`, Symfony `security.yaml`, FastAPI dependency).
+- Check guard / strategy / provider configuration.
+- Multi-tenant identification happens **after** authentication — see [`multi-tenancy`](../multi-tenancy/SKILL.md).
 
 ### Step 2: Authorization
 
-1. Create policy in `app/Policies/` if needed.
-2. Use in FormRequest `authorize()` or controller `$this->authorize()`.
-3. Check `agents/gates.md` for non-model gates.
+1. Create / locate the authz rule in the framework's idiomatic primitive (Policy, voter, guard, middleware, route dependency).
+2. Apply it at the request boundary (FormRequest `authorize()`, controller / route-handler dependency, middleware chain).
+3. Cover non-model gates (cross-aggregate rules) — keep them centralised, not scattered across handlers.
 
 ### Step 3: Review for adversarial
 
-For security-sensitive changes, run `adversarial-review` skill.
+For security-sensitive changes, run [`adversarial-review`](../adversarial-review/SKILL.md).
 Focus on: attack surface, trusting user input, authorization gaps.
 
 ## Conventions
 
-→ See guideline `php/security.md` for auth, SQL injection, XSS, CSRF, headers, session, mass assignment.
+→ For PHP / Laravel specifics (auth helpers, mass assignment, Blade escaping, CSRF middleware): see guideline `docs/guidelines/php/security.md`.
+→ For other stacks, follow the framework's hardening guide and the carve-outs above.
 
 ### Validate
 
-- Verify all user input is validated via FormRequest before use.
-- Confirm authorization check exists (Policy or Gate) for every state-changing action.
-- Check that no raw user input reaches SQL, HTML output, or shell commands.
-- Run PHPStan — must pass (catches type-safety issues that enable injection).
+- Verify all user input is validated at the boundary via the framework's primitive — never trust raw request data.
+- Confirm an authorization check exists for every state-changing action.
+- Check that no raw user input reaches SQL, HTML output, shell commands, or template renderers without escaping.
+- Run the project's type-checker — must pass (catches type-safety issues that enable injection).
 
 ## Output format
 
-1. Security-hardened code with auth, validation, and sanitization
-2. Policy class for authorization if needed
+1. Security-hardened code with auth, input validation at the boundary, and output encoding.
+2. Authorization rule (Policy / voter / guard / middleware) co-located with the route.
 
 ## Gotcha
 
 - Validation ensures format, not intent — don't trust input after validation alone.
-- `Gate::authorize()` throws, `Gate::allows()` returns bool — choose based on error handling.
-- Rate limiting: ALL public endpoints, not just login.
+- "Throw" vs "boolean" authz APIs behave differently (`Gate::authorize()` throws vs `Gate::allows()` returns bool in Laravel; `CanActivate` in NestJS throws; FastAPI dependencies throw `HTTPException`). Pick based on how the framework expects failure to surface.
+- Rate-limit ALL public endpoints, not just login.
 - Never log passwords, tokens, or API keys.
 
 ## Do NOT
 
-- Do NOT bypass FormRequest validation in controllers.
-- Do NOT use `$request->all()` for mass assignment — use `$request->validated()`.
+- Do NOT bypass the framework's request-validation primitive inside handlers.
+- Do NOT bulk-bind raw request payloads to ORM entities without an explicit allow-list (`$fillable` / `$guarded`, DTO mapping, Pydantic model).
 - Do NOT store plaintext passwords or secrets in the database.
 - Do NOT expose internal error details in production API responses.
 

package/.agent-src/skills/skill-reviewer/SKILL.md

@@ -193,7 +193,7 @@ Before scoring the 5 Killers, verify structure:
 ```markdown
 | Skill | K1 Desc | K2 Over | K3 Obvious | K4 Gotcha | K5 Size | K6 Pointer | K7 Analysis | Verdict |
 |---|---|---|---|---|---|---|---|---|
-| dto-creator | ❌ | ✅ | ✅ | ⚠️ | ✅ | ✅ | ✅ | Fix description |
+| laravel-dto | ❌ | ✅ | ✅ | ⚠️ | ✅ | ✅ | ✅ | Fix description |
 ```
 
 ## Output format

package/.agent-src/skills/test-driven-development/SKILL.md

@@ -172,7 +172,7 @@ For mock-isolation failure modes (separate concern), see
 
 ## Examples
 
-### PHP / Pest
+### Example A — PHP / Pest
 
 ```php
 // tests/Unit/EmailValidatorTest.php — RED
@@ -203,7 +203,7 @@ final class EmailValidator
 Run the filter again → passes. No additional rules (format, MX, length)
 until a next failing test drives them.
 
-### JS / Vitest
+### Example B — TypeScript / Vitest
 
 ```ts
 // src/retry.test.ts — RED
@@ -270,8 +270,8 @@ wait for their own failing tests.
 
 ## When to hand over to another skill
 
-* Quality tools, PHPStan, ECS, Rector → [`quality-tools`](../quality-tools/SKILL.md)
-* Full Pest conventions, Laravel testing helpers → [`pest-testing`](../pest-testing/SKILL.md)
+* Project type-checker / linter / formatter (PHPStan, ECS, Rector for PHP — tsc / eslint / prettier for TS — ruff / mypy for Python) → [`quality-tools`](../quality-tools/SKILL.md)
+* Full Pest conventions and Laravel test helpers → [`pest-testing`](../pest-testing/SKILL.md)
 * Running tests inside Docker → [`tests-execute`](../tests-execute/SKILL.md)
 * Investigating why a test is failing for non-obvious reasons →
   [`systematic-debugging`](../systematic-debugging/SKILL.md)

package/.agent-src/skills/test-performance/SKILL.md

@@ -3,6 +3,7 @@ name: test-performance
 description: "Use when optimizing test suite performance — database setup, seeder optimization, parallel testing, CI pipeline efficiency, or RefreshDatabase alternatives."
 source: package
 domain: quality
+framework: laravel
 ---
 
 # test-performance
@@ -16,7 +17,7 @@ Use this skill when:
 - Parallel testing needs optimization
 - Seeders need performance analysis
 - CI pipeline test jobs need to be faster
-- Investigating flaky tests caused by DB state
+- Investigating flaky tests caused by database state
 
 ## Procedure: Analyze test performance
 
@@ -56,7 +57,7 @@ Check these areas in order of typical impact:
 | **Migration count** | How many CREATE TABLE statements? | High if >20 |
 | **Schema dump** | Is `database/schema/` used? | High if missing |
 | **Seeder INSERT method** | Individual `save()` vs bulk insert? | Medium |
-| **Truncation** | Per-seeder truncate vs centralized? | Low (but → correctness issues) |
+| **Truncation** | Per-seeder truncate vs centralized? | Low (but causes correctness issues) |
 | **Connection discovery** | Dynamic `getPdo()` probing? | Low |
 | **Parallel worker setup** | Does each worker re-migrate? | High |
 
@@ -77,7 +78,7 @@ php artisan schema:dump --database=api_database
 #### B. Template DB Cloning (high ROI for parallel tests)
 
 Instead of each parallel worker running migrate+seed independently:
-1. Prepare ONE template DB (migrate + seed)
+1. Prepare ONE template database (migrate + seed)
 2. Clone template for each worker via mysqldump
 
 ```bash
@@ -93,7 +94,7 @@ mysqldump template_db | mysql worker_db_test_1
 
 #### C. Skip Migrate+Seed Flag (high ROI for local dev)
 
-Add a config flag to skip DB setup when DB is already prepared:
+Add a config flag to skip database setup when DB is already prepared:
 
 ```php
 // config/testing.php
@@ -159,7 +160,7 @@ Replace dynamic `getPdo()` probing with explicit config:
 ## Gotcha
 
 - Don't use RefreshDatabase when DatabaseTransactions suffices — full refresh is 10x slower.
-- The model forgets that parallel tests share the DB — use unique identifiers in test data.
+- The model forgets that parallel tests share the database — use unique identifiers in test data.
 - Seeder optimization has the highest ROI — a 2s seeder running 100 times = 200s wasted.
 - Don't add indexes to test databases just for test performance — the real fix is better test design.
 

package/.agent-src/skills/verify-completion-evidence/SKILL.md

@@ -50,9 +50,9 @@ mapping before running anything:
 | Claim | Evidence command |
 |---|---|
 | "tests pass" | full or targeted test suite |
-| "no static errors" | PHPStan / TypeScript / mypy on changed scope |
-| "style is clean" | ECS / Prettier / ESLint |
-| "no automated refactor pending" | Rector --dry-run clean |
+| "no static errors" | project's type-checker on changed scope (PHPStan, `tsc --noEmit`, mypy / pyright, `go vet`, `cargo check`) |
+| "style is clean" | project's linter + formatter (ECS / Prettier / ESLint / Ruff / Black / gofmt / rustfmt) |
+| "no automated refactor pending" | project's auto-refactor dry-run if one exists (Rector for PHP — otherwise skip this row) |
 | "endpoint works" | curl / Postman / integration test output |
 | "UI renders" | Playwright snapshot or manual browser check |
 | "bug is fixed" | regression test passes |
@@ -60,8 +60,7 @@ mapping before running anything:
 ### 2. Run the command fresh
 
 * Run against the current working tree, not a cached summary.
-* For PHP projects inside Docker: run inside the container (see
-  [`docker`](../docker/SKILL.md) and [`tests-execute`](../tests-execute/SKILL.md)).
+* If the project runs commands inside a container or VM (Docker, Devcontainer, Vagrant), run them there — not on the host. See [`docker`](../docker/SKILL.md) and [`tests-execute`](../tests-execute/SKILL.md).
 * Use targeted runs during iteration (`--filter=`, `--testNamePattern`).
   Run the full suite only in the final verification pass.
 
@@ -77,40 +76,38 @@ mapping before running anything:
 Ask: *"Does this output actually support what I am about to say?"*
 
 * 248/250 tests passed with 2 skipped → do not say "all green"; name the skips.
-* PHPStan exit 0 but only analyzed one file → do not say "no static
+* Type-checker exit 0 but only analyzed one file → do not say "no static
   errors"; name the scope that was checked.
 * `curl` returned 200 → check the body, not just the status.
 
 ### 5. Only then make the claim
 
-Reference the evidence: *"Tests: 250/250 passed. PHPStan: level 8, 0
-errors on `app/Services/`."* — not *"everything looks good"*.
+Reference the evidence: *"Tests: 250/250 passed. Type-checker: 0 errors
+on the changed scope."* — not *"everything looks good"*.
 
-## The end-of-work sequence (PHP projects)
+## The end-of-work sequence
 
 When all code changes are done and you are ready to report completion:
 
-1. **Targeted tests** — the test(s) covering the changed code pass
-2. **Full test suite** — only after targeted pass is green
-3. **PHPStan** → **Rector --dry-run** → **ECS** → **PHPStan** (second pass
-   catches issues Rector / ECS may have introduced)
-4. Fix any output from steps 1–3 and restart the sequence
-5. Only then: claim completion or suggest `/commit`, push, or PR
+1. **Targeted tests** — the test(s) covering the changed code pass.
+2. **Full test suite** — only after targeted pass is green.
+3. **Static analysis pipeline** — run the project's type-checker → auto-refactor dry-run (if any) → linter / formatter → type-checker (second pass catches issues the refactor / formatter may have introduced).
+4. Fix any output from steps 1–3 and restart the sequence.
+5. Only then: claim completion or suggest `/commit`, push, or PR.
 
-Do not run the full quality pipeline between intermediate edits — it
-burns time and tokens. Use it once, at the end.
+Do not run the full quality pipeline between intermediate edits — it burns time and tokens. Use it once, at the end.
 
-See [`quality-tools`](../quality-tools/SKILL.md) for the exact commands
-per tool.
+→ For the **exact PHP commands** (PHPStan → Rector → ECS → PHPStan): see [`quality-tools`](../quality-tools/SKILL.md).
+→ For TS / JS, Python, Go, Rust pipelines: the project's `Taskfile.yml` / `package.json scripts` / `Makefile` is the source of truth — read it before improvising.
 
 ## Minimum evidence per task type
 
 | Task type | Required evidence |
 |---|---|
-| Code change (logic) | Targeted tests + PHPStan on changed scope |
-| New feature | Tests (new + suite) + PHPStan + smoke check (curl/UI) |
+| Code change (logic) | Targeted tests + project's type-checker on changed scope |
+| New feature | Tests (new + suite) + type-checker + smoke check (curl / UI / integration probe) |
 | Bug fix | Regression test (RED → GREEN) + full suite |
-| Refactoring | Full suite + PHPStan + Rector dry-run |
+| Refactoring | Full suite + type-checker + auto-refactor dry-run if available |
 | Config / env change | Relevant command or service output (not just file diff) |
 | Migration | Migration run output + rollback dry-run + tests |
 | API endpoint | HTTP response body + status + content-type |
@@ -140,7 +137,7 @@ When reporting completion to the user:
 
 * A "no output" result from a linter is not proof it ran — check the
   exit code and the analyzed-file count.
-* Silencing a warning with `@phpstan-ignore-next-line` or `// @ts-expect-error`
+* Silencing a warning with `@phpstan-ignore-next-line`, `// @ts-expect-error`, `# type: ignore`, or `//nolint`
   without a reason code passes the linter but defers the real problem.
 * Running tests with `--stop-on-failure` then reporting "passed" — it
   only ran until the first failure; the green streak after it is
@@ -150,7 +147,7 @@ When reporting completion to the user:
   change is large.
 * Running the test suite on the wrong branch (forgot to switch or
   rebase) — verify `git status` and `git log -1` before the final gate.
-* A previously green PHPStan run in the same conversation is stale as
+* A previously green static-analysis run in the same conversation is stale as
   soon as any edit lands. Run it again.
 
 ## Red flags — STOP and run the gate
@@ -159,7 +156,7 @@ When reporting completion to the user:
   command-output reference in the same message
 * About to suggest `/commit` / push / PR without a verification block
 * Relying on an earlier-in-conversation test run
-* Partial evidence (tests green, PHPStan not run — or vice versa)
+* Partial evidence (tests green, type-checker / linter not run — or vice versa)
 * "The failing test is unrelated, let me skip it" — verify first, then
   decide
 * Reporting a green run by paraphrasing instead of quoting exit code
@@ -177,8 +174,8 @@ When reporting completion to the user:
 
 ## When to hand over to another skill
 
-* Exact PHPStan / Rector / ECS commands → [`quality-tools`](../quality-tools/SKILL.md)
-* Running tests inside Docker → [`tests-execute`](../tests-execute/SKILL.md)
+* Exact PHP quality commands (PHPStan / Rector / ECS) → [`quality-tools`](../quality-tools/SKILL.md)
+* Running tests inside a container / VM → [`tests-execute`](../tests-execute/SKILL.md)
 * Writing the regression test that the gate requires →
   [`test-driven-development`](../test-driven-development/SKILL.md)
 * Diagnosing why the gate failed → [`systematic-debugging`](../systematic-debugging/SKILL.md)

package/.agent-src/skills/video-director/SKILL.md

@@ -111,3 +111,16 @@ Any "no" → revise that block before handing off.
 - Do NOT collapse anticipation / action / reaction into one verb.
 - Do NOT use "cinematic" without lens + lighting + camera move.
 - Do NOT invent character details when a `character.json` exists.
+
+## Policies
+
+11-block cinematic prompt is live-action shape — real-person + brand-impersonation risks highest in cluster. Before emitting:
+
+- [`agents/policies/media/likeness.md`](../../../agents/policies/media/likeness.md) — prompt names / visually identifies real person on camera.
+- [`agents/policies/media/public-figures.md`](../../../agents/policies/media/public-figures.md) — subject is recognised public figure.
+- [`agents/policies/media/brand-impersonation.md`](../../../agents/policies/media/brand-impersonation.md) — prompt copies journalism / broadcaster / regulated-industry visual identity.
+- [`agents/policies/media/style.md`](../../../agents/policies/media/style.md) — LIGHT / LENS anchored to named living cinematographer's signature.
+- [`agents/policies/media/disclosure.md`](../../../agents/policies/media/disclosure.md) — every distributed live-action AI clip carries non-removable AI-generation disclosure.
+
+Refuse-and-surface at directorial layer; live-action realism amplifies every downstream policy gap.
+

package/.agent-src/templates/agents/agent-project-settings.example.yml

@@ -39,7 +39,7 @@ schema_version: 1
 # CI guard: a release bump of `package.json` must update this value
 # in lockstep — see scripts/check_template_pin_drift.py (road-to-
 # portable-runtime-and-update-check P3.3).
-agent_config_version: "2.23.0"
+agent_config_version: "2.25.0"
 
 # --- Project identity ---
 project:

package/.agent-src/templates/copilot-instructions.md

@@ -119,8 +119,8 @@ resolve at agent runtime. The patterns below are correct by design:
 - **`path_prefix:` triggers containing `.agent-src.uncompressed/`**
   in YAML frontmatter. This is a literal match pattern for the
   host's router, **not** a file reference — source-of-truth meta-rules
-  (`augment-source-of-truth`, `augment-portability`, `skill-quality`,
-  `docs-sync`, `rule-type-governance`) legitimately match against the
+  (`augment-source-of-truth`, `augment-edit-discipline`, `skill-quality`,
+  `rule-type-governance`) legitimately match against the
   authoring tree.
 - **Symlinked rule / skill / command files** under `.claude/`,
   `.cursor/`, `.clinerules/`. Targets resolve into `.augment/rules/`,

package/.agent-src/templates/roadmaps.md

@@ -84,6 +84,22 @@ php artisan test                     # Tests (or: vendor/bin/phpunit)
 
 Check `AGENTS.md` or `Makefile` / `Taskfile.yml` for the exact commands.
 
+### CI-step gate (when `quality.local_auto_run: false`)
+
+Roadmaps **must not** schedule full-pipeline literals (`task ci`,
+`task ci-fast`, `task ci-strict`, `make ci`, `make test`,
+`npm/pnpm run check`, `yarn check`, `composer test`, whole-suite
+`vendor/bin/phpunit`, whole-suite `php artisan test`) as checkbox
+steps when `quality.local_auto_run` is `false` in
+`.agent-settings.yml` — `task lint-roadmap-ci-steps` blocks them.
+Reword as narrow verifications (`vendor/bin/phpstan analyse
+app/Modules/X`, `php artisan test --filter=…`) or mark with
+`<!-- carve-out: new-gate-verification -->` when the step verifies a
+**new** gate this roadmap introduces. At execution,
+`/roadmap:process-*` flips matching steps to `[-]` with reason and
+skips them. Full contract:
+[`roadmap-ci-steps-policy`](../rules/roadmap-ci-steps-policy.md).
+
 ---
 
 ## Template