@event4u/agent-config 5.10.1 → 6.0.0

package/.agent-src/skills/agents-md-thin-root/SKILL.md

@@ -1,143 +0,0 @@
----
-model_tier: inherit
-name: agents-md-thin-root
-description: "Use when editing AGENTS.md (package root) or templates/AGENTS.md (consumer) — enforces Thin-Root contract: hard char ceilings, ≥40% pointer ratio, mandatory emergency-triage block."
-domain: process
-execution:
-  type: assisted
-  handler: internal
-  allowed_tools: []
-workspaces:
-  - agent-config-maintainer
-packs:
-  - meta
----
-
-<!-- cloud_safe: noop -->
-
-# agents-md-thin-root
-
-## When to use
-
-Use when:
-- Editing `AGENTS.md` at the package root.
-- Editing `packages/core/.agent-src.uncondensed/templates/AGENTS.md` (consumer-shipped template).
-- Reviewing a PR that changes either file.
-- Running `/optimize/agents`.
-- A budget meter (`scripts/measure_augment_budget.py`) flags the package-root AGENTS.md as the dominant cost.
-
-## Do NOT
-
-- Edit `.github/copilot-instructions.md` with this skill (use `copilot-agents-optimization` instead).
-- Edit other `.md` files under `.augment/`, `packages/*/.agent-src.uncondensed/`, or `agents/` with this skill.
-- Add a section to AGENTS.md without first checking whether an outboard target already exists in `agents/settings/contexts/` or `docs/contracts/`.
-- Replace prose with a bare link `[label](path)` — every pointer needs a *why*-clause ≥ 60 chars or it does not count toward the 40 % ratio.
-- Reuse the package-root anatomy in the consumer template — caps and target paths differ.
-
-## Why Thin-Root
-
-Augment Code injects `AGENTS.md` verbatim into every workspace prompt. Each kilobyte spent here permanently consumes the 49,512-char workspace-guidelines budget shared with always-rules and auto-rule registry stubs. The Thin-Root pattern keeps the entry point a navigation surface (pointers + intent) and pushes deep detail into files Augment loads on demand via `load_context` or that other tools fetch only when their search retrieves them. Strategic council R2 (2026-05-08, Sonnet 4.5 / Opus 4.1 / gpt-4o / o1) converged on the contract codified below as the minimum guard against AGENTS.md re-bloat.
-
-## Iron Law — Capabilities over Structure
-
-Every entry describes **what** the project does or **where** to learn more — never **where** individual files live. Path lists rot every refactor and poison context; capability pointers survive structural churn. Full anatomy with rewrite recipes, monorepo guidance, and multi-tool symlink strategy: [`agents-md-anatomy`](../../contexts/contracts/agents-md-anatomy.md).
-
-## The contract — hard caps
-
-| File | FAIL above | WARN above | Target |
-|---|---|---|---|
-| `AGENTS.md` (package root) | 3,000 chars | 2,800 chars | ≤ 2,800 |
-| `packages/core/.agent-src.uncondensed/templates/AGENTS.md` (consumer) | 2,500 chars | 2,300 chars | ≤ 2,300 |
-
-Char-count is raw file size (`wc -c`), frontmatter included. Enforcement: `scripts/lint_agents_md.py` (Phase 7), wired into the package's CI pipeline via the `lint-agents-md` task. WARN is a soft signal in CI; FAIL blocks merge.
-
-The R2 council originally proposed 2,500 / 2,000 caps. Phase 6.4 empirical refactor demonstrated that the mandatory emergency-triage block (≈ 700 chars) plus operational must-haves (source-of-truth disclaimer, `task` quickstart, six substantive pointers) raise the achievable floor by ≈ 500 chars. The caps above are the post-refactor baseline; the previous numbers stayed unattainable without dropping mandatory content.
-
-## The contract — pointer ratio
-
-≥ 40 % of non-blank lines must be **substantive pointers**. A substantive pointer is a Markdown link `[label](path[#anchor])` whose surrounding sentence carries a *why* clause ≥ 60 chars explaining what the reader will learn there. Decorative links (table-of-contents, badges, repeated cross-refs) do not count. Lint formula:
-
-```
-pointer_ratio = (substantive_pointer_lines / non_blank_lines) >= 0.40
-```
-
-## The contract — pointer anatomy
-
-Every substantive pointer specifies, on the same line or the immediately following line:
-
-1. **Target file path** — repo-relative, no leading `./`.
-2. **Optional anchor** — `#section-slug` when the linked file's content is large enough that landing in the middle saves the reader. Skip only when the linked file is itself short.
-3. ***Why* clause** — ≥ 60 chars, present-tense, names the concrete decision the pointer unblocks. Not "see also", not "more info", not the file's title repeated.
-
-### Wrong vs. right
-
-❌ **Wrong** — bare link, no *why*, no anchor:
-> See [`commit-policy`](.agent-src/rules/commit-policy.md).
-
-❌ **Wrong** — *why* present but < 60 chars:
-> Commit rules: [`commit-policy`](.agent-src/rules/commit-policy.md).
-
-✅ **Right** — full anatomy, anchor, *why* ≥ 60 chars:
-> Commit policy — never auto-commit, four named exceptions, Hard Floor list of bulk-deletion / infra triggers: [`commit-policy § Iron Law`](.agent-src/rules/commit-policy.md#the-iron-law).
-
-✅ **Right** — anchor optional when target is short:
-> Mirror the user's language every reply, single Iron Law that overrides any momentum: [`language-and-tone`](.agent-src/rules/language-and-tone.md).
-
-## The contract — emergency-triage block
-
-Every Thin-Root AGENTS.md MUST contain an **Emergency Triage** section verbatim from `packages/core/.agent-src.uncondensed/contexts/contracts/emergency-triage-block.md` (Phase 6.4 will create that file as the canonical source). The block lists the five questions a host agent answers from the root file alone when network / tool access is degraded:
-
-1. What is this repository?
-2. What language(s) does this repository accept?
-3. Where do I edit (source-of-truth path)?
-4. What is the lint / test / sync entry point?
-5. Where do the always-active behavior rules live?
-
-Each answer must fit on one line. The block exists so the root never silently degrades to "useful only when every linked file is reachable".
-
-## Procedure — apply Thin-Root to AGENTS.md
-
-1. **Measure baseline.** `wc -c AGENTS.md` and `python3 scripts/measure_augment_budget.py`. Record current char-count and the gap to 2,200 / 2,500.
-2. **Inventory sections.** List every `## ` heading and its char-count. Mark each as `keep-inline` (Iron-Law-adjacent, ≤ 200 chars, no good outboard target) or `outboard-candidate` (longer-form prose, table-only sections, narrative).
-3. **Identify outboard targets.** For each `outboard-candidate`, name the destination — `packages/core/.agent-src.uncondensed/contexts/`, `docs/contracts/`, an existing rule body, an existing skill body. Never invent a new top-level directory.
-4. **Move content; insert pointer.** Cut the section into the target file. Replace it in AGENTS.md with a single substantive pointer per anatomy above. Verify the *why*-clause length.
-5. **Re-measure.** `wc -c AGENTS.md` again. If above 2,200, repeat steps 2–4 on the next-largest section. Above 2,500 = must outboard further before commit.
-6. **Validate pointer ratio.** Count non-blank lines and substantive-pointer lines. Ratio < 0.40 = collapse decorative or boilerplate lines into a single pointer or remove.
-7. **Verify emergency-triage block.** Diff the in-file block against `packages/core/.agent-src.uncondensed/contexts/contracts/emergency-triage-block.md`. Drift = revert to canonical.
-8. **Run lints.** `task lint-agents-md && task check-refs && task lint-skills`. All green before commit.
-
-## Procedure — apply Thin-Root to consumer template
-
-Same procedure, applied to `packages/core/.agent-src.uncondensed/templates/AGENTS.md`. Hard cap shifts to 2,000 / 1,700. The consumer template intentionally lacks the package-self-references — its pointers target files that exist in the **consumer's** repo (`.augment/skills/`, `agents/settings/contexts/`, ...), not this package's authoring tree.
-
-## Gotchas
-
-- **Outboarding to a new top-level dir.** Inventing `agents/explainers/` or `docs/notes/` for the moved content silently widens the contract surface. Outboard only into `packages/core/.agent-src.uncondensed/contexts/`, `docs/contracts/`, an existing rule body, or an existing skill body.
-- **Pointer-ratio inflation by decoration.** Adding boilerplate "Browse all skills" / "See also" links to lift the ratio above 40 % defeats the purpose. The lint counts only substantive pointers (with a *why*-clause ≥ 60 chars); decorative links get filtered out and the ratio drops back below threshold.
-- **Emergency-triage drift.** Editing the in-file emergency-triage block instead of the canonical `packages/core/.agent-src.uncondensed/contexts/contracts/emergency-triage-block.md` causes the package-root and consumer-template versions to diverge silently. Always edit the canonical file and let the lint diff pull both back in sync.
-- **Cap inversion under WARN.** A 2,250-char AGENTS.md (above 2,200 WARN, below 2,500 FAIL) is a yellow signal not a green one — every additional sentence raises the probability of the next FAIL. Treat WARN as the spend boundary, not a buffer.
-- **Char-count includes frontmatter.** `wc -c` counts every byte including the YAML preamble, blank lines, and the trailing newline. Stripping a section to "look smaller" without re-running `wc -c` understates the true budget impact.
-- **Path enumeration.** A run of three or more bare `` `path/to/dir/` `` bullets without *why*-clauses is the classic re-bloat pattern. The lint emits a WARN at ≥ 3 such lines. Collapse them into one capability-style pointer — see the recipe in [`agents-md-anatomy § Iron Law`](../../contexts/contracts/agents-md-anatomy.md#iron-law--capabilities-over-structure).
-- **Tool-specific duplicates.** Copy-pasting AGENTS.md into `CLAUDE.md` / `GEMINI.md` / `.cursorrules` doubles the budget cost across tools. Use the symlink-or-stub pattern in [`agents-md-anatomy § Multi-tool symlink strategy`](../../contexts/contracts/agents-md-anatomy.md#multi-tool-symlink-strategy) instead.
-
-## Output format
-
-When invoked as a planning step, produce:
-
-1. Current size + gap to target (one line per file).
-2. Inventory table (section, chars, keep-inline / outboard-candidate, target).
-3. Pointer ratio before / after (predicted).
-4. Specific outboarding edits as a numbered diff plan.
-5. The four lint commands the agent must run before claiming completion.
-
-## Cloud Behavior
-
-Inert on cloud surfaces. The skill governs the package-root `AGENTS.md` and the consumer-shipped template — both authoring artifacts inside this repository. Cloud agents working on consumer projects never edit those files directly; their copy is delivered by the package install pipeline and refreshed by the package sync pipeline. The Thin-Root contract therefore has no cloud-side procedure to execute, which is why this skill is marked `cloud_safe: noop`.
-
-## See also
-
-- [`agents-md-anatomy`](../../contexts/contracts/agents-md-anatomy.md) — Capabilities-over-Structure Iron Law, multi-tool symlink strategy, monorepo per-package layout, refactor recipe, full gotcha catalog.
-- [`copilot-agents-optimization`](../copilot-agents-optimization/SKILL.md) — sibling skill for `.github/copilot-instructions.md`; runs alongside Thin-Root in `/agents optimize`.
-- [`agent-docs-writing`](../agent-docs-writing/SKILL.md) — broader documentation-structure context for navigating outboard targets.
-- [`size-enforcement`](../../rules/size-enforcement.md) — covers per-skill / per-rule / per-command size budgets; AGENTS.md caps live in this skill instead.
-- [`ADR-004-rule-governance-pruning`](../../../docs/decisions/ADR-004-rule-governance-pruning.md) — captures the rule-governance pruning that freed the workspace-guidelines budget; the Thin-Root caps build on that headroom.

package/.agent-src/skills/api-design/SKILL.md

@@ -1,112 +0,0 @@
----
-model_tier: medium
-name: api-design
-description: "Use when designing APIs, planning endpoints, REST conventions, versioning, or deprecation — even when the user just says 'expose this as an endpoint' without naming API design."
-personas:
-  - backend-architect
-domain: engineering
-recommended_for_user_types: [developer, founder]
-workspaces:
-  - engineering
-packs:
-  - engineering-base
----
-
-# api-design
-
-## When to use
-
-Use this skill when designing new API endpoints, restructuring existing APIs, or deciding about versioning and deprecation.
-
-Do NOT use when:
-- Implementing an already-designed endpoint (use `api-endpoint` skill)
-- Writing tests for APIs (use `api-testing` skill)
-
-## Procedure: Design an API
-
-1. **Gather context** — read `agents/settings/contexts/api-versioning.md`, `agents/reference/docs/api-resources.md`, `agents/reference/docs/query-filter.md`, `agents/reference/docs/controller.md`, and guideline `php/api-design.md`.
-2. **Identify the resource** — determine the domain entity, its attributes, and relationships. Check existing models and resources for field naming patterns.
-3. **Define endpoints** — list each endpoint with HTTP method, URL path, request body, query parameters, and response structure. Follow existing route file patterns.
-4. **Decide versioning** — determine whether this extends the current version or requires a new version (see decision table below).
-5. **Design error responses** — define 4xx/5xx responses matching the project's existing error format.
-6. **Validate against existing patterns** — compare your design with 2-3 similar existing endpoints. Flag any inconsistencies.
-7. **Run adversarial review** — use `adversarial-review` skill to check for breaking changes, consistency issues, and missing error cases.
-
-## Versioning decisions
-
-### URL-based versioning
-
-Routes versioned via URL prefix: `/api/v1/...`, `/api/v2/...`
-
-```
-routes/api/v1/projects.php  → /api/v1/projects
-routes/api/v2/projects.php  → /api/v2/projects
-```
-
-### Automatic fallback
-
-If a route doesn't exist in the requested version, the system falls back to the next older version. Configured in `config/app.php`:
-
-```php
-'api_versioning' => [
-    'versions' => 'v2,v1',  // newest first
-],
-```
-
-### When to create a new version
-
-| Change type | Action |
-|---|---|
-| Add optional field | Extend current version |
-| Add new endpoint | Add to current version |
-| Remove/rename field | New version |
-| Change field type | New version |
-| Change validation rules | New version |
-
-> If an existing client would break without code changes → **new version required**.
-
-### Deprecation workflow
-
-1. **Mark as deprecated** — add headers: `Deprecation: true`, `Sunset: YYYY-MM-DD`, `Link: <successor>`
-2. **Document** — add to API changelog with sunset date
-3. **Monitor usage** — track clients still using deprecated endpoints
-4. **Remove** — after sunset date, remove route + controller + docs
-
-Minimum 3 months between deprecation and removal.
-
-## Design review
-
-Before presenting an API design, run the **`adversarial-review`** skill.
-Focus on: Breaking changes? Consistency? Error responses?
-
-## Output format
-
-1. Endpoint specification — method, path, request/response structure
-2. Versioning decision with rationale
-3. Error response format following existing project patterns
-
-## Gotcha
-
-- Consistency beats "better" design — check existing patterns first.
-- Always include pagination on list endpoints.
-- Max nesting depth: 2 levels (`/users/{id}/orders/{id}`).
-- Don't version internal APIs only your own frontend consumes.
-- Deprecation without migration path is useless — always provide the replacement.
-- Don't duplicate controllers for new versions — use fallback logic.
-
-## Do NOT
-
-- Do NOT introduce a new response format in an established API — match existing patterns.
-- Do NOT create v2 endpoints without a deprecation plan for v1.
-- Do NOT skip pagination on list endpoints.
-
-## Auto-trigger keywords
-
-- API design
-- REST API
-- endpoint design
-- resource structure
-- response format
-- API versioning
-- deprecation
-- breaking changes

package/.agent-src/skills/api-endpoint/SKILL.md

@@ -1,94 +0,0 @@
----
-model_tier: medium
-name: api-endpoint
-description: "Use when creating an API endpoint or HTTP route handler — detects the project stack and routes to the matching carve-out (laravel-api-endpoint, nextjs-patterns, symfony-workflow)."
-domain: engineering
-workspaces:
-  - engineering
-packs:
-  - engineering-base
----
-
-# api-endpoint
-
-## When to use
-
-Use this skill when the user asks to create a new API endpoint, REST route, or HTTP handler.
-
-Do NOT use when:
-- Modifying existing endpoints — use the code-refactoring skill.
-- API design decisions (versioning, deprecation, contract shape) — use [`api-design`](../api-design/SKILL.md).
-
-## Stack routing
-
-Detect the stack, then hand off to the matching carve-out skill for the framework-specific procedure (file layout, validation primitive, response-shaping convention).
-
-| Detected stack | Carve-out skill |
-|---|---|
-| Laravel (`artisan` + `composer.json` with `laravel/framework`) | [`laravel-api-endpoint`](../laravel-api-endpoint/SKILL.md) |
-| Symfony (`bin/console` + `composer.json` with `symfony/framework-bundle`) | [`symfony-workflow`](../symfony-workflow/SKILL.md) |
-| Next.js (`next` in `package.json`) | [`nextjs-patterns`](../nextjs-patterns/SKILL.md) |
-| Express / Fastify / NestJS / plain Node | follow project conventions in `agents/` + `package.json scripts` |
-| FastAPI / Django / Flask | follow project conventions in `agents/` + `pyproject.toml` |
-| Go (`net/http`, `gin`, `echo`, `fiber`) | follow project conventions in `agents/` + `go.mod` |
-| Rust (`axum`, `actix-web`, `rocket`) | follow project conventions in `agents/` + `Cargo.toml` |
-
-If the project doc folder (`agents/`) has an endpoint-creation guide, that is the source of truth — read it before generating code.
-
-## Procedure: Create an API endpoint (stack-neutral)
-
-1. **Read project docs** — Check `./agents/` and `AGENTS.md` for endpoint conventions, routing layout, response shape.
-2. **Detect stack** and route to the carve-out per the table above.
-3. **Plan the endpoint** — method, path, request shape, response shape, auth requirement, idempotency.
-4. **Create the route registration** in the project's routing surface (route file, decorator-annotated handler, file-based router).
-5. **Create the request handler / controller** — thin; delegate business logic to a service / use-case.
-6. **Validate input at the boundary** via the framework's validation primitive (FormRequest, Zod, class-validator, Pydantic, struct-tag validators, etc.) — never inline ad-hoc `if` checks.
-7. **Authorize the action** via the framework's authz primitive (Policy, voter, guard, middleware, route dependency).
-8. **Shape the response** through a transformer / serializer / DTO — never return raw ORM entities.
-9. **Document** the endpoint (OpenAPI annotations / generated spec / project doc).
-10. **Verify** — run the project type-checker + targeted tests + smoke probe (`curl` / Bruno / Postman / integration test).
-
-## Conventions (apply on every stack)
-
-- **One handler, one responsibility** — prefer single-purpose handlers over multi-action controllers when the framework supports it.
-- **No business logic in the handler** — delegate to a service / use-case layer.
-- **Validate at the boundary** — never trust raw request data inside the handler.
-- **Authorize every state-changing action** — no unprotected mutating endpoints.
-- **Shape responses through a transformer** — DTO, serializer, API resource, response model — never expose raw ORM entities.
-- **Version the API surface** explicitly (`/v1/`, header, content-type) — don't rely on implicit versioning.
-
-## Stack-specific procedures
-
-For Laravel projects (the most fully-fleshed-out carve-out in this package), see [`laravel-api-endpoint`](../laravel-api-endpoint/SKILL.md) — covers single-action controllers, `FormRequest`, `Resource`, `Policy`, `CollectionFormRequest`, OpenAPI attributes, and the versioned route layout.
-
-For other stacks, read the matching carve-out from the table above and combine with the project's `agents/` docs.
-
-## Output format
-
-1. Generated files — route registration, handler, request validator, response shaper, authorization rule.
-2. Test file with happy path and validation-error cases (using the project's test framework).
-3. Summary of created files and their locations.
-
-## Gotcha
-
-- Don't forget to register the route — creating the handler without the route is a common miss.
-- Always check if a similar endpoint already exists — duplicates cause confusion.
-- Validation rules must match the documented contract (OpenAPI / schema / typed client) — keep them in sync.
-- Response shapes are part of the public contract — adding a field is additive; renaming or removing is breaking.
-
-## Do NOT
-
-- Do NOT put business logic in the handler — delegate to services / use-cases.
-- Do NOT skip request validation — every handler validates at the boundary via the framework's primitive.
-- Do NOT return raw ORM entities — always go through a transformer / serializer / response model.
-- Do NOT create unprotected state-changing endpoints — authorize every mutation.
-- Do NOT improvise framework idioms — read the carve-out (`laravel-api-endpoint`, `nextjs-patterns`, etc.) for the stack-correct shape.
-
-## Auto-trigger keywords
-
-- create endpoint
-- new API route
-- route handler
-- controller creation
-- REST endpoint
-- add endpoint

package/.agent-src/skills/authz-review/SKILL.md

@@ -1,180 +0,0 @@
----
-model_tier: high
-name: authz-review
-description: "Use when reviewing authorization end-to-end — route → gate → policy → query scope → response filter — before changes to permissions, tenants, ownership, or admin flows."
-personas:
-  - security-engineer
-  - backend-architect
-domain: quality
-recommended_for_user_types: [developer, ops]
-workspaces:
-  - engineering
-packs:
-  - engineering-base
----
-
-# authz-review
-
-> You are a reviewer specialized in **end-to-end authorization enforcement**.
-> Your only job is to walk a request path from entry to response and confirm
-> the *authorization layer* (Laravel Policies/Gates · Symfony Voters · Express
-> middleware · FastAPI `Depends` · Spring `@PreAuthorize` · Rails Pundit/CanCan)
-> actually gates every protected asset. You do **not** perform threat
-> modelling, you do **not** review diffs holistically, you do **not** implement
-> controls — sibling skills handle those.
-
-## When to use
-
-* A change adds or modifies permission checks, roles, or ownership rules
-* A change exposes a new route, action, or admin-only capability
-* A query fetches tenant-scoped or user-scoped records and you must confirm scope
-* A bug report mentions "user A saw user B's data" or "non-admin accessed admin page"
-* `security-sensitive-stop-rule` fires on an auth/tenant/ownership code path
-
-Do NOT use when:
-
-* The change has no trust boundary crossing — skip entirely
-* You need a pre-implementation risk model — route to
-  [`threat-modeling`](../threat-modeling/SKILL.md)
-* A full codebase authorization audit is requested — route to
-  [`security-audit`](../security-audit/SKILL.md)
-* The concern is a diff ready for review — route to
-  [`judge-security-auditor`](../judge-security-auditor/SKILL.md)
-* The concern is response/log leakage rather than access gating — route to
-  [`data-exposure-review`](../data-exposure-review/SKILL.md)
-* The concern is implementing a control once identified — route to
-  [`security`](../security/SKILL.md)
-
-## Procedure
-
-### 1. Pick the entrypoints under review
-
-Collect the route(s), action(s), or job(s) in scope for this review. Read the
-task description, open ticket, or user request — do not invent scope. If the
-entrypoint list is unclear, stop and ask.
-
-### 2. Inspect each path end-to-end
-
-For every entrypoint, analyze the authorization chain and record what you find:
-
-| Stage | What to confirm |
-|---|---|
-| Route / binding | HTTP method, URL, controller/handler, middleware chain |
-| Authentication gate | Is login enforced? By which middleware / guard? |
-| Authorization layer | Which policy, gate, voter, or check? Which action/ability? |
-| Data scope | Does the query filter by current user / tenant / owner? |
-| Response filter | Are sensitive fields stripped (resource/serializer/DTO)? |
-| Tests | Is there a negative test (other-tenant / lower-role returns 403/404)? |
-
-Record **what is there**, not what should be there. Use file:line citations.
-
-### 3. Surface the gaps
-
-For every gap, answer:
-
-- Which stage is missing or weak?
-- Which actor can exploit it? (anonymous · authenticated non-owner · wrong tenant · lower role)
-- Concrete impact? (cross-tenant read, privilege escalation, horizontal escalation)
-- Minimum control to add? (policy method, scope, middleware, resource transform)
-- Required negative test assertion?
-
-Do **not** list generic findings ("should use policies") — always anchor to a
-file:line and a specific actor who can reach the gap.
-
-## Validation
-
-Before finalizing the report, confirm:
-
-1. Every entrypoint in scope is walked through **all six stages** of the table
-2. Every 🔴 finding names: stage · actor · impact · missing control · required test
-3. Every 🔴 finding cites at least one file path with line number
-4. You have NOT listed stages that are already correctly enforced as findings
-5. You have NOT confused authentication with authorization in any finding
-6. You have NOT proposed exploit payloads, bypass chains, or offensive steps
-
-## Output format
-
-```
-Skill:   authz-review
-Targets: <routes / actions / jobs, one per line>
-
-Per-entrypoint walk:
-  <METHOD /route> — <controller@action>  (file:line)
-    Auth gate:           <middleware/guard>   ✅/⚠️/❌
-    Authorization:       <policy#ability>     ✅/⚠️/❌   (file:line)
-    Data scope:          <scope/where>        ✅/⚠️/❌   (file:line)
-    Response filter:     <resource/serializer> ✅/⚠️/❌  (file:line)
-    Negative test:       <test path or "—">   ✅/⚠️/❌
-
-Findings (prioritized):
-  🔴  <name> — entrypoint · stage · actor
-      Impact: <concrete damage>
-      Missing control: <what to add, where>
-      Required test: <negative assertion, test file>
-  🟡  ...
-  🟢  ...
-
-Implementation plan:
-  1. <control>, <file/layer>
-  2. ...
-
-Missing tests:
-  1. <assertion>, <test file>
-```
-
-Severity: 🔴 reachable by external or cross-tenant/cross-user actor with
-current privileges / 🟡 reachable only by elevated actor or requires
-partial compromise / 🟢 defense-in-depth hardening, not a live exploit path.
-
-Required fields (ordered):
-
-1. **Skill** and **Targets** — entrypoints in scope
-2. **Per-entrypoint walk** — six-stage table per entrypoint with file:line citations
-3. **Findings** — prioritized, each with entrypoint · stage · actor · impact · missing control · required test
-4. **Implementation plan** — ordered controls mapped to files/layers
-5. **Missing tests** — ordered negative assertions
-
-Runtime confirmation (e.g. *"reproduce the cross-tenant read against staging"*,
-*"query the DB to prove scope leakage"*) is a follow-up for the implementer —
-**this skill does not execute tools, run requests, or touch the database**.
-
-## Gotcha
-
-* **Authentication ≠ authorization.** A logged-in user is not an authorized
-  user. Auth gate green does not make authorization green.
-* **Implicit tenancy via current session** — `Auth::user()->posts` looks safe
-  but breaks the moment an admin impersonation or service-account path bypasses it.
-* **Query scope bypass through relations** — `$user->load('orders.customer')`
-  can leak a sibling tenant if the `customer` relation has no scope.
-* **Resource/serializer leakage** — the policy gated the action; the resource
-  still exposed `internal_notes`. Response filter is a distinct stage.
-* **"Route middleware covers it"** — middleware enforces auth, not per-record
-  authorization. Still need the policy + scope.
-* **Generic advice without file:line** — reject your own finding if you cannot
-  cite the exact location.
-
-## Do NOT
-
-* NEVER return `clean` out of politeness when gaps exist — list them even if the change "probably works"
-* NEVER silently fall back to generic advice when you cannot locate a stage — mark it `❌ not found` with the file you searched
-* NEVER approve a 🔴 finding without a named required negative test
-* NEVER propose exploit payloads, bypass chains, or offensive verification steps — if asked, stop per `never-help-build-offensive-cyber-capability`
-* NEVER treat "only admins reach this" as a control without proof the admin gate is enforced at this stage for this request
-* NEVER rubber-stamp authentication middleware as if it enforced per-record authorization
-
-## References
-
-- **OWASP ASVS v4.0.3** — Chapter V4 Access Control, especially V4.1
-  (General Access Control Design) and V4.2 (Operation-level Access Control).
-  [owasp.org/www-project-application-security-verification-standard/](https://owasp.org/www-project-application-security-verification-standard/)
-- **OWASP Top 10 2021 — A01 Broken Access Control** — canonical failure modes
-  (IDOR, missing function-level checks, forced browsing, metadata tampering).
-  [owasp.org/Top10/A01_2021-Broken_Access_Control/](https://owasp.org/Top10/A01_2021-Broken_Access_Control/)
-- **NIST SP 800-53 AC family** — AC-3 Access Enforcement, AC-6 Least Privilege
-  — rubric for "minimum control" recommendations.
-  [csrc.nist.gov/projects/risk-management/sp800-53-controls](https://csrc.nist.gov/projects/risk-management/sp800-53-controls/release-search#!/800-53)
-- [`threat-modeling`](../threat-modeling/SKILL.md),
-  [`data-exposure-review`](../data-exposure-review/SKILL.md),
-  [`judge-security-auditor`](../judge-security-auditor/SKILL.md),
-  [`security`](../security/SKILL.md),
-  [`security-audit`](../security-audit/SKILL.md) — sibling review / impl skills.

package/.agent-src/skills/blade-ui/SKILL.md

@@ -1,129 +0,0 @@
----
-model_tier: medium
-name: blade-ui
-description: "Use when the project's frontend stack is Blade — dispatched by `directives/ui/{apply,review,polish}.py`. Covers views, components, partials, layouts, and view logic."
-domain: engineering
-workspaces:
-  - engineering
-packs:
-  - laravel
-trust:
-  level: professional
-install:
-  default: false
-  removable: true
----
-
-# blade-ui
-
-## Positioning — dispatched, not standalone
-
-`blade-ui` is the **apply-step executor** for the Blade stack. It is
-invoked by [`directives/ui/apply.py`](../../templates/scripts/work_engine/directives/ui/apply.py)
-once the design brief is locked, and revisited by `review.py` /
-`polish.py` during the design-review loop. It does **not** own the
-flow, does **not** drive the audit, and does **not** lock the design.
-
-| Concern | Owner |
-|---|---|
-| Audit + token inventory (mandatory pre-step) | [`existing-ui-audit`](../existing-ui-audit/SKILL.md) |
-| Design brief (layout / states / microcopy) | [`directives/ui/design.py`](../../templates/scripts/work_engine/directives/ui/design.py) |
-| Universal design heuristics | [`fe-design`](../fe-design/SKILL.md) |
-| Review + polish loop | [`directives/ui/review.py`](../../templates/scripts/work_engine/directives/ui/review.py) + [`polish.py`](../../templates/scripts/work_engine/directives/ui/polish.py) |
-
-## When to use
-
-Cite this skill when:
-
-- `state.stack.frontend == "blade"` (or the project is clearly Blade-only without Livewire / Flux) and `directives/ui/apply.py` dispatches to this skill
-- Editing or creating Blade views, components, partials, layouts, or forms
-
-Do NOT use when:
-
-- API-only endpoints (use `api-endpoint` skill)
-- Livewire components (use `livewire` skill — it composes Blade views internally)
-- Flux UI components (use `flux` skill)
-- Driving the full UI flow yourself — that is the `directives/ui/` orchestrator
-
-## Procedure: Create Blade view or component
-
-### Step 0: Inspect
-
-1. Confirm Blade is used — check `resources/views`, components, layouts.
-2. Inspect existing UI patterns — layouts, partials, component naming, CSS conventions.
-3. Check form handling style — old input, validation errors, session flashes, reusable field partials.
-4. Inspect neighboring templates — match indentation, directives, slot usage, classes.
-5. Determine data flow — what belongs in controller/view model vs. template.
-
-### Step 1: Create the template
-
-1. Use the project's existing layout system.
-2. Keep template presentation-focused — no business logic, no DB queries.
-3. Extract repeated sections into partials or components.
-
-### Step 2: Handle forms (if applicable)
-
-1. Follow project's form style for labels, inputs, validation messages.
-2. Use CSRF protection correctly.
-3. Render validation errors consistently.
-4. Preserve user input with `old()` or project conventions.
-5. Reuse existing field components — don't duplicate.
-
-### Step 3: Validate
-
-1. Check escaping — `{{ }}` by default, `{!! !!}` only when explicitly safe.
-2. Check styling — Tailwind utility classes, not inline styles.
-3. Check accessibility — labels for form fields, semantic HTML.
-
-## Conventions
-
-→ See guideline `php/blade-ui.md` for full conventions.
-
-## Output format
-
-1. Blade view or component file(s) following project conventions
-2. Component class (if applicable) with typed props
-
-### Review pass — a11y findings + preview envelope
-
-When this skill is dispatched by `directives/ui/review.py` (test slot)
-or `directives/ui/polish.py` (verify slot) — i.e. a review/polish run,
-not the initial apply — it also emits:
-
-- `state.ui_review.a11y` — `{violations: [{rule, selector, severity}, ...],
-  severity_floor?, accepted_violations?}`. Use the same `(rule, selector)`
-  shape as `state.ui_audit.a11y_baseline` so the engine's de-dup matches
-  pre-existing entries on replay. Omit the envelope on apply passes; the
-  engine's `_apply_a11y_gate` only fires when a baseline is present.
-- `state.ui_review.preview` — `{render_ok: bool, screenshot_path?,
-  dom_dump_path?, error?, skipped?}`. `render_ok: false` with `error`
-  populated triggers the `preview_render_failed` halt; `render_ok: true`
-  with `screenshot_path` threads the screenshot into the delivery
-  report's `artifacts` list. Browser tooling (Playwright/Cypress/…) is
-  a consumer-project dependency — this package does not ship one.
-
-Polish dispatch: when the dispatcher skips `review` because a previous
-review pass already returned `SUCCESS`, this skill MUST itself
-synthesise the updated `state.ui_review.findings` (including any
-remaining `a11y_violation` entries) so the engine's gate sees the
-current state on the next polish round.
-
-## Gotcha
-
-- `@include` shares parent scope — components don't. Know the difference.
-- Always use Tailwind utility classes — not inline styles.
-- Don't put business logic in templates — use view composers or Livewire.
-
-## Do NOT
-
-- Do NOT use `{!! !!}` with user input — XSS risk.
-- Do NOT put business logic in Blade templates — use Livewire or view composers.
-- Do NOT use inline styles — use Tailwind utility classes.
-
-## Auto-trigger keywords
-
-- Blade template
-- Blade component
-- Laravel view
-- partial
-- view logic