@event4u/agent-config 7.1.0 → 7.2.0

package/dist/ui/index.html

@@ -5,7 +5,7 @@
         <meta name="viewport" content="width=device-width, initial-scale=1" />
         <meta name="robots" content="noindex" />
         <title>agent-config</title>
-      <script type="module" crossorigin src="/assets/index-CoQo90sz.js"></script>
+      <script type="module" crossorigin src="/assets/index-UjcTG_9O.js"></script>
       <link rel="stylesheet" crossorigin href="/assets/index-BbWWuFrF.css">
     </head>
     <body>

package/docs/RELEASE_STORY_TEMPLATE.md

@@ -0,0 +1,37 @@
+# Release Story — `<version>`
+
+A curated, human-readable "what changed and **why it matters**" — distinct from
+the raw `CHANGELOG`. The changelog lists commits; the release story tells a
+maintainer or consumer, in plain language, what they get and what to watch.
+
+Copy this template per release; keep it short (a screen or less).
+
+## Headline
+
+One sentence: the single most important thing this release delivers.
+
+## What changed (and why it matters)
+
+- **<change>** — what it is · why a consumer cares · what they should do (if anything).
+- **<change>** — …
+
+## Safety / behaviour changes
+
+Anything that changes agent behaviour, gates, or defaults — call it out explicitly
+(new floors, new consent gates, renamed packs, changed risk postures). Consumers
+read this section first.
+
+## Upgrade notes
+
+- Breaking? Migration steps. Non-breaking? Say so.
+- New opt-in surfaces (packs, settings) — how to enable.
+
+## Deferred / known limitations
+
+What was intentionally left for a future release, and the pointer (roadmap /
+ADR). Honesty here prevents "is this missing or coming?" questions.
+
+---
+
+> Fill every section. An empty section is a signal the release is not understood
+> well enough to ship its story. (road-to-product-clarity Phase 4a.)

package/docs/architecture.md

@@ -146,10 +146,10 @@ note, package-internal path-swap, description budget, and the
 
 | Layer | Count | Purpose |
 |---|---|---|
-| **Skills** | 257 | On-demand expertise — stack analysis (Laravel · Symfony · Zend / Laminas · Next.js · React · Node), testing, Docker, API design, security, observability, … |
-| **Rules** | 91 | Always-active constraints — coding standards, scope control, verification, language-and-tone, agent-authority |
+| **Skills** | 258 | On-demand expertise — stack analysis (Laravel · Symfony · Zend / Laminas · Next.js · React · Node), testing, Docker, API design, security, observability, … |
+| **Rules** | 93 | Always-active constraints — coding standards, scope control, verification, language-and-tone, agent-authority |
 | **Commands** | 162 | Slash-command workflows — `/commit`, `/create-pr`, `/fix ci`, `/optimize skills`, `/feature plan`, `/work`, `/implement-ticket`, `/condense`, … |
-| **Guidelines** | 84 | Reference material cited by skills — PHP patterns, Eloquent, Playwright, agent-infra, … |
+| **Guidelines** | 86 | Reference material cited by skills — PHP patterns, Eloquent, Playwright, agent-infra, … |
 | **Templates** | 7 | Scaffolds for features, roadmaps, contexts, skills, overrides |
 | **Contexts** | 5 | Shared knowledge about the system itself |
 

package/docs/contracts/capability-boundary.md

@@ -0,0 +1,64 @@
+# Capability Boundary Matrix
+
+The per-pack safety posture at a glance: is a pack on by default, does it need
+consent, a council pass, a disclaimer, an eval — and how risky is it. The matrix
+makes the invisible visible; the **enforcement** lives in the per-pack safety
+floors + gates (this doc is the map, not the engine).
+
+> Source of truth: `src/config/discovery/packs.yml` (`surface_tier`,
+> `trust_level_default`, `domain`, and the legal-review-prep gate fields) + the
+> domain safety-floor rules. Built in `road-to-capability-governance` Phase 1;
+> `risk_class` becomes a real pack field in Phase 2.
+
+## Policy by risk class
+
+| `risk_class` | default install | consent | council / deep-research | disclaimer | eval expectation | surface_tier |
+|---|---|---|---|---|---|---|
+| **low** | per profile | no | no | no | optional | `core` |
+| **medium** (advisory) | per profile | no | no | **yes** (domain safety floor) | recommended | `core` |
+| **high** | **no** (opt-in) | **yes** | **yes** (fail-closed) | **yes** | **yes** | `lab` |
+
+- **low** — engineering, product, meta, and tooling packs. Normal capability; no domain liability surface.
+- **medium (advisory)** — packs that emit advisory-shaped output (finance, strategy). They carry a **domain safety floor** that mandates a not-X-advice disclaimer + structural elements (assumptions / counter-case / confidence). Not off-by-default, but never a final call.
+- **high** — regulated-advice-adjacent. Off by default, consent-gated, council-gated (fail-closed), disclaimer-bound, eval-backed, lab-tier, and promotion-gated behind a professional review.
+
+## Per-pack assignment (non-low)
+
+| Pack | `risk_class` | Floor | Gates |
+|---|---|---|---|
+| `legal-review-prep` | **high** | `legal-safety-floor` | consent (`legal_review_prep.acknowledged`) · council (`require_council`, fail-closed) · hard individual-case STOP · attorney-review line + `Jurisdiction:` tag · attorney-framing-review promotion tripwire · `default_install: false` · `surface_tier: lab` |
+| `finance-basic` | medium | `finance-safety-floor` | not-financial-advice disclaimer · assumptions + sensitivity + confidence + counter-case · no final invest/raise call |
+| `finance-advanced` | medium | `finance-safety-floor` | as finance-basic (DCF / scenario depth) |
+| `founder-strategy` | medium | `strategy-safety-floor` | not-a-strategic-decision footer · bet + counter-case + residual risk + decision owner |
+
+Every other pack in `packs.yml` is **low** by default. A pack moves to medium the
+moment it ships advisory-shaped output behind a domain safety floor, and to high
+only through the high-risk checklist (consent + council + disclaimer + eval +
+lab + promotion gate) — see `road-to-legal-review-prep` for the worked example.
+
+## Capability lifecycle (a view, not a new axis)
+
+Reviewers wanted one lifecycle vocabulary for promoting / retiring capabilities.
+This is a **derived view** over the metadata that already exists
+(`trust_level_default` + `surface_tier` + eval presence) — **not** a new field.
+Nothing to set; it is read off what is already there.
+
+| Lifecycle | Derived from | Promotion criterion (to reach it) |
+|---|---|---|
+| **experimental** | `surface_tier: lab` **or** `trust_level_default: experimental` | default for any new pack/skill |
+| **validated** | `surface_tier: core` **and** has an `evals/` (or regression harness) | a real eval exists + the pack left lab |
+| **recommended** | validated **and** in a default profile / ≥1 real consumer | adoption evidence, not just existence |
+| **deprecated** | a `deprecated`/`superseded_by` marker in frontmatter | a successor named (per the persona/skill deprecation discipline) |
+
+Read the lifecycle column off the matrix above: a `lab` + `experimental` pack
+(e.g. `legal-review-prep`, `ai-video`) is **experimental**; a `core` pack with an
+eval is **validated**; a `core` pack a profile ships is **recommended**.
+Promotion stays a human/maintainer decision (criteria-documented, never
+automated — see `road-to-capability-governance` Phase 6).
+
+## See also
+
+- [`legal-safety-floor`](../../src/rules/legal-safety-floor.md) — the high-risk exemplar.
+- `finance-safety-floor` · `strategy-safety-floor` — the medium-risk advisory floors.
+- [`domain-pack-architecture`](../guidelines/agent-infra/domain-pack-architecture.md) — the pack build sequence.
+- `road-to-capability-governance` Phase 2 — `risk_class` as a validated pack field.

package/docs/contracts/discovery-manifest.schema.json

@@ -74,7 +74,7 @@
     },
     "workspace_id": {
       "type": "string",
-      "enum": ["engineering", "product", "finance", "founder", "gtm", "ops", "small-business", "construction", "legal", "agent-config-maintainer"]
+      "enum": ["engineering", "product", "finance", "founder", "gtm", "ops", "small-business", "construction", "legal-review-prep", "agent-config-maintainer"]
     },
     "pack_id": {
       "type": "string",
@@ -84,7 +84,7 @@
         "finance-basic", "finance-advanced",
         "gtm-sales", "gtm-marketing",
         "ops-people", "founder-strategy", "small-business", "construction", "ai-video", "ai-image", "fun", "meta", "git", "frontend-design", "brand",
-        "memory", "analytics", "product-reasoning", "analysis-workbench", "legal"
+        "memory", "analytics", "product-reasoning", "analysis-workbench", "legal-review-prep"
       ]
     },
     "lifecycle": {

package/docs/contracts/package-self-orientation.md

@@ -156,5 +156,8 @@ layout + cloud-bundle pipeline:
 3. Commit in logical chunks with Conventional Commits.
 4. Open a PR against `main`.
 
+Per-pack safety posture (default-install / consent / council / disclaimer /
+risk_class): [`capability-boundary.md`](capability-boundary.md).
+
 User-facing story: [`README.md`](../../README.md). Architecture
 deep-dive: [`docs/architecture.md`](../architecture.md).

package/docs/contracts/subagent-boundary.md

@@ -0,0 +1,54 @@
+# Subagent Boundary Contract
+
+What a subagent **owns** and what it must **never** own. As delegation spreads
+(the `subagent-orchestration` modes, the `delegation-policy` auto-trigger,
+workflow fan-out), the failure mode is scope drift: a subagent quietly
+redefining the task, expanding scope, or bypassing a floor. This contract draws
+the line.
+
+## The ownership line
+
+A subagent **executes one scoped, named task and returns a conclusion.** That is
+the whole of its authority.
+
+### A subagent OWNS
+
+- **Its scoped task** — the single, well-specified slice it was dispatched with.
+- **Its method** — how it searches, reads, reasons, or drafts within that slice.
+- **Its return** — a conclusion + evidence, sized to what the orchestrator asked for (structured output when a schema was given).
+
+> **Explainability is durable, not host-ephemeral.** The return must carry a brief
+> *why + evidence* (which sources/steps led to the conclusion) **in the artefact /
+> output itself**, not only in the host's session reasoning. A user opening the
+> result later — possibly across sessions — must be able to trace the *why* without
+> reassembling provider chat logs. This is the reasoning-in-notes discipline applied
+> to delegation: conclusions + evidence travel with the output, raw chain-of-thought
+> does not.
+
+### A subagent must NEVER own
+
+- **Task meaning** — it does not redefine, broaden, or reinterpret the parent task. An ambiguous slice returns "ambiguous + why", it does not guess a bigger task.
+- **Cross-task memory / state** — it does not write durable memory, mutate shared roadmaps, or persist decisions for other tasks; its output is its only channel.
+- **Pack / surface decisions** — it does not decide what ships, what installs, or what a pack contains; those are orchestrator + human calls.
+- **Safety-floor bypass** — every floor applies *inside* the subagent. The Hard Floor ([`non-destructive-by-default`](../../src/rules/non-destructive-by-default.md)), the domain safety floors, [`scope-control`](../../src/rules/scope-control.md), and [`commit-policy`](../../src/rules/commit-policy.md) are not lifted by being one level down. A subagent cannot do what its parent may not.
+- **Silent scope expansion** — touching files / systems beyond its slice is a contract violation, surfaced, not absorbed.
+
+## Orchestrator obligations (the other side)
+
+- **Verify, never adopt blind** — a subagent return is evidence, not truth; the orchestrator verifies per [`delegation-policy`](../../src/rules/delegation-policy.md)'s Iron Law before adopting it.
+- **Tier-size the slice, not the agent** — dispatch at the slice's complexity, not the session's.
+- **Own the safety decision** — a Hard-Floor or egress action surfaced by a subagent is decided by the orchestrator + human, never executed by the subagent.
+
+## Failure modes
+
+- A research subagent that, finding the task underspecified, invents a broader task and "helpfully" does it.
+- A subagent that writes to shared memory / a roadmap dashboard as a side effect.
+- A subagent that commits, pushes, or deletes because "the task implied it".
+- An orchestrator that pastes a subagent's claim into the answer without verifying it.
+
+## See also
+
+- [`subagent-orchestration`](../../src/skills/subagent-orchestration/SKILL.md) — the dispatch modes this contract bounds.
+- [`delegation-policy`](../../src/rules/delegation-policy.md) — the delegate-by-default trigger + verify-every-return Iron Law.
+- [`capability-boundary`](capability-boundary.md) — the pack-level companion (this is the agent-level one).
+- [`non-destructive-by-default`](../../src/rules/non-destructive-by-default.md) — the Hard Floor that applies inside subagents too.

package/docs/decisions/ADR-013-discovery-frontmatter-contract.md

@@ -314,6 +314,19 @@ road-to-legal-pack Phase 0.2). Council-resolved across three rounds 2026-06-24
 (road-to-legal-pack). Additive, no rename; non-overlap with cost-profile and
 `profile.id` reservations holds.
 
+### 2026-06-24 — Rename `legal` → `legal-review-prep` (workspace + pack)
+
+Renamed the workspace id and pack id `legal` → `legal-review-prep` in both
+closed vocabularies, the schema enums, and all artefacts (`src/domains/legal/`
+→ `src/domains/legal-review-prep/`, the five skill frontmatters, the
+`legal-safety-floor` rule). Driven by a deep AI-council (3 rounds,
+anthropic/claude-sonnet-4-5 + openai/gpt-4o, 2026-06-24) + ~8 external
+7.1.0 reviewers: the name `legal` reads as "legal advice" and undermines the
+not-legal-advice positioning; `legal-review-prep` names the actual capability
+(prepare for attorney review). The `domain: legal` classifier and the `legal`
+user-type are a different axis and are unchanged. Rename, not additive;
+non-overlap reservations still hold. See `road-to-legal-review-prep` Phase 0.
+
 ## Cross-references
 
 - [ADR-007 — Agent Discovery Scopes](ADR-007-agent-discovery-scopes.md):

package/docs/decisions/ADR-107-legal-domain-pack-adoption.md

@@ -21,6 +21,11 @@ type: prospective
 
 ## Decision
 
+> **Amendment (2026-06-24, deep-council).** The pack id was renamed `legal` →
+> `legal-review-prep` after this ADR, to stop the name itself reading as "legal
+> advice" (deep AI-council + 7.1.0 reviewers; see `road-to-legal-review-prep`).
+> Read every `legal` pack-id reference below as `legal-review-prep`.
+
 Open a single, narrow `legal` pack — **not** a multi-plugin / multi-agent parity clone.
 
 1. **Scope: EU/DE-only, hard refusal.** Every selectable jurisdiction is an implicit currency promise; for a single maintainer the smallest correct cut is EU/DE with "consult local counsel" for everything else. Encoded in the `legal-safety-floor` rule + the pack description; surfaced via a machine-checkable `Jurisdiction:` tag.
@@ -31,6 +36,20 @@ Open a single, narrow `legal` pack — **not** a multi-plugin / multi-agent pari
 6. **No personas** — procedure-not-personality; role focus lives in skill tags + the practice profile.
 7. **Conditional product-liability gate** — commercial (Pro-tier) ship would require licensed-attorney review of the pack itself. **Resolved N/A 2026-06-24:** the suite is open-source forever, no commercial tier (ADR-108) — the gate never fires; the non-removable disclaimer + per-output attorney-review line cover end-user reliance.
 
+## Amendment (2026-06-24, deep-council) — attorney-framing-review promotion tripwire
+
+Promotion of `legal-review-prep` out of `surface_tier: lab` / `trust_level_default:
+experimental`, flipping `default_install` to anything but `false`, or any
+commercial / hosted surface, is **blocked** until a licensed German attorney has
+reviewed the *framing* (the `legal-safety-floor` rule, `LEGAL_NOTICE.md`, and the
+RDG individual-case wording — **not** skill correctness) and the review is recorded
+in `LEGAL_NOTICE.md` as `Framing reviewed by <name>, Rechtsanwalt/Rechtsanwältin,
+<date>`. The deep AI-council (2026-06-24) scoped this as a bounded (~€300–800,
+1–2h) one-time gate, **not** a blocker for the current lab release (lab is
+explicitly unvetted; users opt in knowingly via the consent gate). Enforced by
+`lint_legal_pack` (`promotion-gate` rule): a promoted tier without the recorded
+marker fails CI.
+
 ## Rejections (recorded)
 
 matter-workspace (too heavy), scheduled watchers, community-skill installer hub, US-state employment tests, full litigation depth, bar-prep, Swiss cantonal depth, non-EU/DE jurisdictions, the cross-model-parity dependency for the eval (a false blocker, corrected in the full critique round).

package/docs/getting-started.md

@@ -129,7 +129,7 @@ Your agent is now:
 - **Respecting your codebase** — no conflicting patterns
 - **Following standards** — consistent code quality
 
-This is enforced automatically by 91 rules. No configuration needed.
+This is enforced automatically by 93 rules. No configuration needed.
 
 ---
 

package/docs/guidelines/agent-infra/domain-pack-architecture.md

@@ -50,6 +50,7 @@ itself a useful result.
 
 ## See also
 
+- [Capability Boundary Matrix](../../contracts/capability-boundary.md) — per-pack safety posture (default-install / consent / council / disclaimer / eval / risk_class).
 - [ADR-107 — Legal domain-pack adoption](../../decisions/ADR-107-legal-domain-pack-adoption.md)
 - `domain-adoption-policy` (rule) — the three gates before opening any domain.
 - `domain-eval-anti-pattern.md` — why the legal eval is a regression harness, not an objective gate.

package/docs/guidelines/design-antipatterns-triggers.json

@@ -0,0 +1,17 @@
+{
+  "description": "Routing eval for design-antipatterns guideline: should an agent pull this catalog for a given task?",
+  "should_pull": [
+    "Design a landing page for a new SaaS product",
+    "Review this UI mockup for AI-slop patterns",
+    "Create a feature card section with icons and descriptions",
+    "Generate a hero section with a big metric and supporting stats",
+    "The design looks generic — how do I make it more distinctive?"
+  ],
+  "should_not_pull": [
+    "Fix the authentication bug in the login controller",
+    "Write a migration to add the user_id column to the orders table",
+    "Set up the CI pipeline for the monorepo",
+    "Draft a customer email reply for a billing issue",
+    "Analyze the test coverage for the payment module"
+  ]
+}

package/docs/guidelines/design-antipatterns.md

@@ -0,0 +1,170 @@
+# Design Anti-Patterns — AI-Slop Catalog
+
+> Lazy-loaded reference guideline. Pull this before proposing, generating, or
+> reviewing any UI. Used by `design-intelligence`, `fe-design`, `design-review`,
+> `existing-ui-audit`.
+
+This catalog enumerates patterns that make AI-generated UI **recognizably
+AI-generated**. Every entry carries a concrete override condition — the goal is
+not prohibition but deliberateness. A pattern on this list used *knowingly* for
+a specific brief is a design decision; used *reflexively* from a default, it is
+slop.
+
+**How to use:** Before generating UI, scan the applicable category. Flag any
+pattern you were about to reach for. Either (a) choose a different approach, or
+(b) invoke the override condition and state the reason explicitly in the brief.
+
+**Agent self-check principle:** These are guidance rules, not linter rules. The
+agent reads the brief, checks its first impulse against this catalog, and adjusts
+or overrides. The enforceable subset (contrast ratio, font-size, heading
+hierarchy, reduced-motion, focus indicator) is in `lint_design_quality`
+(Phase 5).
+
+**Who owns what (boundary — avoid drift):**
+
+| Layer | Owns | Artifact |
+|---|---|---|
+| **Guidance** | Subjective taste — Visual / Typography / Color / Layout / Copy patterns, override judgment, the originality self-test | this catalog |
+| **Enforcement** | Objective floors — Q1–Q6 (WCAG contrast, font-size, line-length, reduced-motion, heading hierarchy, focus indicator) as exit-code-2 CI | `lint_design_quality` |
+| **Audit method** | HOW to test WCAG (keyboard nav, ARIA, screen-reader procedures) | `accessibility-auditor` |
+| **Stack manifestation** | Concrete Tailwind class / hex bans, shadcn defaults | `tailwind-engineer`, `react-shadcn-ui` (per `framework-neutrality-in-generic-skills`) |
+| **Register** | Brand mode vs product mode — which patterns apply | `docs/guidelines/design-modes.md` |
+
+This catalog is the canonical *index*; it states the pattern stack-agnostically.
+The stack-specific bans live in the apply skills and link back here by entry ID.
+The objective floors are cited from the linter, never re-eyeballed by an agent.
+
+---
+
+## Visual
+
+| # | Pattern | Why it reads as AI-generated | Override condition |
+|---|---|---|---|
+| V1 | Side-stripe `border-left` or `border-right` > 1px as a colored accent | The single most recognizable AI-UI signature; every scaffold-default card uses it | Brand token explicitly defines a stripe; document the decision in the design brief |
+| V2 | Glassmorphism as decoration (`backdrop-blur` + `bg-white/10`) with no functional depth hierarchy | Model defaults to it for "premium feel"; result looks like 2021 Material You clip-art | Element genuinely sits above a complex, blurred background layer; use sparingly and only for top-level floating surfaces |
+| V3 | Ghost card: `border: 1px solid` + box-shadow ≥ 16px spread together | The combination creates visual noise — the ghost card signals no confident decision about depth | Choose either border OR shadow to indicate depth; never both on the same surface |
+| V4 | Over-rounded small cards or badges: `border-radius` > 16px on elements < 200px wide | Excessive rounding on small surfaces looks toy-ish; standard cap is 12–16px | Pill shape (`border-radius: 9999px`) is intentional on single-line tags/chips only |
+| V5 | Hand-drawn or illustrated SVG icons mixed with crisp icon-system icons | Visual register collision; instantly reads as "generated asset" | Intentional illustrative section (hero illustration, empty-state art); isolate from the icon system |
+| V6 | Repeating diagonal stripes as a background texture | A cliché background default; reads as generated CSS art | Brand explicitly uses pattern backgrounds (e.g., a textile brand); document the stripe definition |
+| V7 | Nested cards: a card inside a card inside a card | Depth hierarchy collapses; user cannot parse elevation intent | A truly three-level hierarchy (e.g., project → board → card); ensure each level has distinct visual weight |
+
+---
+
+## Typography
+
+| # | Pattern | Why it reads as AI-generated | Override condition |
+|---|---|---|---|
+| T1 | Flat type hierarchy: body and headings use the same optical weight and nearly the same size | Type hierarchy is invisible; user cannot scan the page | Deliberately minimal aesthetic where all text is body-weight; must be an explicit brand decision |
+| T2 | Oversized italic serif as the primary hero headline | The "AI startup landing page" template; seen on ~60% of AI-generated marketing pages | Brand adopts editorial-magazine aesthetic with a documented italic serif rationale |
+| T3 | Icon tile (small rounded-square container) above heading | The universal AI feature-card template; reads as scaffold | Listed features genuinely benefit from visual-icon-then-title affordance AND the icons are custom, not library defaults |
+| T4 | Eyebrow / ALL-CAPS label above every section heading | Overuse collapses the emphasis; maximum is 1 eyebrow per 3 sections (countable: grep tracking classes) | Used for genuine section-type differentiation with meaningful vocabulary (not just "FEATURES", "PRICING") |
+| T5 | Repeated section kickers ("Our mission", "What we offer", "Why choose us") | Filler vocabulary; every AI-generated page has the same three section titles | Every kicker is substantive and uses brand-specific vocabulary, not generic marketing speak |
+| T6 | Crushed letter-spacing on display text (`letter-spacing` < −0.04em) | Below −0.04em glyphs collide optically; reads as "designer-ish effect" with no grounding | Intentional tight display treatment with a documented minimum floor; verify at the actual render size |
+| T7 | Overused fonts without a brand reason: Inter, Roboto, DM Sans, Geist, Space Grotesk, Instrument Serif | These are the default AI-coding-tool font picks; every generated UI uses one of them | Brand has explicitly adopted one of these AND there is a documented reason (e.g., Inter for its variable metrics in a data-dense dashboard) |
+| T8 | Single typeface for everything | Missed typographic contrast opportunity; all-Inter reads as "I did not think about fonts" | Intentional mono-typeface aesthetic (e.g., terminal-inspired); must be stated in the brief |
+| T9 | All-caps body paragraphs or field labels | Reduces legibility below WCAG AA for sustained reading; reads as flair over function | Short UI labels (e.g., button text in a brutalist layout); never for body paragraphs |
+| T10 | Wide letter-spacing on body text (`letter-spacing` > 0.05em) | Reduces readability for sustained reading; reserved for display use | Display text (headlines, pull quotes) where intentional tracking is a brand element |
+
+---
+
+## Color
+
+| # | Pattern | Why it reads as AI-generated | Override condition |
+|---|---|---|---|
+| C1 | Purple/violet + cyan-on-dark palette as the primary scheme | The most recognizable AI-UI color combination in 2024–2026; instantly signals "generated" | Brand color system genuinely defines a violet primary; must come from `brand-to-tokens`, not from model defaults |
+| C2 | Gradient text via `background-clip: text` as a primary accent | Overused to the point of invisibility; also has rendering edge cases on some platforms | Headline treatment in a brand that explicitly uses gradient identity (e.g., a product whose logo is a gradient) |
+| C3 | Glowing colored accents on dark mode (bright neon `box-shadow` or `text-shadow`) | Looks like a 2020 gaming UI; reads as an AI attempt at "moody" | Brand explicitly defines neon accents with a documented usage rule (e.g., error or alert states in a security product) |
+| C4 | Gray text on colored background without WCAG AA check | Muted gray chosen for "elegance" often fails 4.5:1 contrast; the failure is invisible until audited | Any use — always verify the contrast ratio; if it fails, either darken the text or lighten/darken the background |
+| C5 | Cream/sand body background (OKLCH L 0.84–0.97, C < 0.06) with brass/clay/oxblood accents | The 2025 "premium-consumer" AI palette; every generated "sophisticated" product uses this exact combination | Brand has an explicit warm-neutral design language documented in `brand-to-tokens`; the palette is first-party, not a default reach |
+
+---
+
+## Layout
+
+| # | Pattern | Why it reads as AI-generated | Override condition |
+|---|---|---|---|
+| L1 | Hero metric template: giant number, small label, 3–4 stats in a row, gradient | The default SaaS dashboard hero; appears on ~70% of AI-generated dashboard screens | Data storytelling genuinely requires a primary metric with supporting context; must vary the arrangement |
+| L2 | Three identical feature cards in a grid with the same visual weight | The scaffold-default; no visual rhythm, no hierarchy among features | Product genuinely has three equally weighted features; must still vary padding, or use a different composition |
+| L3 | Monotonous spacing: one spacing value (usually 24px) used for everything | Spacing is rhythm; uniform spacing collapses the hierarchy of proximity | Intentional grid where every element has equal weight; must document the grid definition |
+| L4 | Numbered section markers (01 / 02 / 03) as a primary section-order device | Universal AI-generated marketing page tell; seen on virtually every generated landing page | A genuinely numbered process or sequenced guide where the step number carries meaning beyond decoration |
+| L5 | Line length > 80ch in body copy without column constraint | Reduces readability; WCAG recommends 45–75 characters; beyond 80 the eye struggles to track | Data-dense dashboards where column width is driven by tabular data, not narrative text |
+| L6 | `position: absolute` dropdown inside `overflow: hidden` container | Dropdown clips; a common AI-generated layout bug | Refactor: use `<dialog>`, the Popover API, or `position: fixed` / portal to escape the stacking context |
+| L7 | Content that overflows its container | Text truncation or reflow failures at non-default viewport widths; reads as untested | Never acceptable in production output; test at 320px, 768px, 1280px minimally |
+| L8 | Z-index values of 99, 999, 9999 without a semantic z-index scale | Magic numbers; the first time two elements compete, the scale breaks | Establish a named semantic z-index scale (`--z-modal: 400`, `--z-toast: 500`, etc.) and use it |
+
+---
+
+## Motion
+
+| # | Pattern | Why it reads as AI-generated | Override condition |
+|---|---|---|---|
+| M1 | Bounce or elastic easing curves on UI elements | Bounce draws attention to the animation itself; UI motion should serve the action, not perform | Intentional playful affordance (game UI, onboarding celebration state); must be brief and non-repeating |
+| M2 | Animating layout properties (width, height, top, left, padding) | Triggers browser layout recalculation; janky on mid-range devices; always solvable with `transform` | Never — use `transform: scaleX()` for width-like effects, `transform: translateY()` for position |
+| M3 | Animating `<img>` element on hover (scale, filter, transform) | Triggers composite + image decode; often causes content shift | Animate the card's background, border, or shadow instead; leave the image static |
+| M4 | `transition: all` shorthand | Animates every property including layout, color, opacity simultaneously; unpredictable and expensive | Enumerate only the properties that should animate: `transition: transform 200ms ease-out, opacity 200ms` |
+| M5 | Missing `@media (prefers-reduced-motion: reduce)` alternative for any animation | Accessibility violation; vestibular disorders make animated UI unusable | Never acceptable; always add a `prefers-reduced-motion` variant — gentler animation (reduced distance/opacity) is preferred over `display: none` |
+
+---
+
+## Copy
+
+| # | Pattern | Why it reads as AI-generated | Override condition |
+|---|---|---|---|
+| CP1 | Em-dash (`—`) overuse | The #1 syntactic LLM signature; appears in AI copy at 3–5× the frequency of human editorial copy; maximum 2 per 500 words | Specific editorial voice that uses em-dashes deliberately; count them before shipping |
+| CP2 | Marketing buzzwords: streamline, empower, supercharge, world-class, enterprise-grade, seamlessly, robust, leverage | These words carry no information; an AI-slop test: replace each with nothing — the sentence still communicates the same thing | No override; if a word can be deleted without loss, delete it |
+| CP3 | Aphoristic manufactured contrast ("We don't do X. We do Y." / "Not just A, but B.") | A generated sentence rhythm that sounds like brand writing but carries no specificity | Aphoristic copy is legitimate when the contrast reveals a genuine product distinction; test by asking whether the Y side says something concrete |
+| CP4 | "Theater" framing — copy that announces what the product does without saying how or why | "The platform for modern teams." communicates nothing; it is content-shaped noise | Every tagline must pass the "so what" test: can a skeptic follow it with "but how?" and get a concrete answer? |
+
+---
+
+## Quality floors — measurable thresholds
+
+These are not stylistic — they are objective quality failures detectable without
+aesthetic judgment. The `lint_design_quality` CI linter enforces a subset of
+these. The rest are agent self-checks.
+
+| # | Threshold | Measurement | CI-enforced? |
+|---|---|---|---|
+| Q1 | Text contrast ≥ 4.5:1 normal / ≥ 3:1 large text (WCAG AA) | `contrastRatio(text, bg) < threshold` | Yes (`lint_design_quality`) |
+| Q2 | Body `font-size` ≥ 14px (floor); ≥ 16px strongly preferred | Computed `font-size` on `p`, `li`, `td` | Yes |
+| Q3 | Line length ≤ 75 characters (prose) | Character count before soft wrap | Yes |
+| Q4 | All `@keyframes` / `animation` have a `prefers-reduced-motion` alternative | CSS `@media` check | Yes |
+| Q5 | Heading levels not skipped (h1→h3 direct, not h1→h4) | DOM heading sequence | Yes |
+| Q6 | All interactive elements have a `:focus-visible` indicator | CSS rule check | Yes |
+| Q7 | Display `letter-spacing` floor: ≥ −0.04em (tighter reads cramped) | Computed tracking | Agent self-check |
+| Q8 | `line-height` ≥ 1.3 on body text | Computed `line-height` | Agent self-check |
+| Q9 | Small-card `border-radius` cap: 12–16px (not 24px+) | Computed `border-radius` on elements < 200px | Agent self-check |
+| Q10 | Body background: avoid OKLCH L 0.84–0.97, C < 0.06 (cream/sand) unless brand-defined | Color space calculation | Agent self-check |
+| Q11 | Padding floors: ≥ 8px (inline elements), ≥ 16px (card/panel bodies) | Computed padding | Agent self-check |
+| Q12 | Justified text only with CSS hyphenation (`hyphens: auto`) | Presence of `text-align: justify` without `hyphens` | Agent self-check |
+
+---
+
+## The AI-slop originality self-test
+
+Before finalizing any UI design, run this two-tier check:
+
+1. **Category test:** Could someone guess the aesthetic from the product
+   category alone? (e.g., "SaaS → dark mode + purple gradient" /
+   "fintech → navy + gold" / "health → teal + rounded sans"). If yes,
+   rework the concept.
+
+2. **Anti-reference test:** Could someone still guess it after knowing the
+   category AND having seen 3 references you explicitly avoided? If yes,
+   dig deeper. A direction that is merely "not the worst cliché" is still
+   a cliché.
+
+The bar: a visitor should ask "how was this made?", not "which AI made this?"
+
+---
+
+## See also
+
+- `design-intelligence` — corpus-grounded style/color/typography selection
+- `fe-design` — stack-agnostic heuristics (form, table, responsive, a11y)
+- `design-review` — structured UI/UX review methodology
+- `existing-ui-audit` — mandatory pre-step: inventory before designing
+- `motion-choreographer` — animation heuristics (should-it, which-easing, how-much)
+- `typography-system` — modular-scale construction and pairing
+- `accessibility-auditor` — WCAG audit method
+- `brand-to-tokens` — first-party brand token extraction (the legitimate override source for most anti-patterns above)

package/docs/guidelines/design-modes.md

@@ -0,0 +1,97 @@
+# Design Modes — Brand vs Product
+
+> Reference doc. Pull this when deciding which design skills to prioritize
+> or when the brief is ambiguous about the design register.
+
+## The two registers
+
+Every design task operates in one of two registers. Getting the register
+wrong is the root cause of most AI-generated design failures:
+
+| | Brand mode | Product mode |
+|---|---|---|
+| **Core thesis** | The impression IS the product | Design serves the task |
+| **Primary failure** | Flatness / genericness — looks like every other AI startup | Strangeness without purpose — "clever" choices that obscure the tool |
+| **The user's question** | "How was this made?" (genuine curiosity) | "Where do I click?" (the tool disappears into the task) |
+| **Key skill cluster** | `brand-identity`, `iconography`, `fe-design § Aesthetic direction`, `design-intelligence` | `accessibility-auditor`, `ui-component-architect`, `fe-design § Table/Form Design` |
+| **Typography strategy** | Distinctive pairing — two contrasting families, deliberate tracking | One reliable family — Inter or equivalent; predictable hierarchy |
+| **Color strategy** | Brand identity — often unexpected; the palette IS the differentiator | Semantic function — primary/danger/success/neutral; predictable meaning |
+| **Motion strategy** | Expressive — motion reinforces the brand's personality | Utilitarian — motion confirms state changes; nothing decorative |
+| **Spacing strategy** | Breathing room; generous whitespace as a brand signal | Dense/efficient; optimize for information density |
+| **Success criterion** | Originality test: a skeptic can't guess "which AI made this?" | Earned familiarity: the tool disappears; users focus on their task |
+
+## How to determine the register
+
+Ask: **What is the output of this UI being used for?**
+
+- A consumer-facing surface where the FIRST impression determines whether the
+  user trusts/buys → **Brand mode**. The product has 3 seconds; every pixel
+  contributes to the brand's identity.
+
+- An internal tool, dashboard, admin panel, or workflow-critical surface where
+  users return dozens of times per day → **Product mode**. Strangeness wastes
+  their time; predictability builds trust.
+
+- A marketing landing page → **Brand mode**. It has one job: create desire.
+
+- A data entry form → **Product mode**. It has one job: accept correct data.
+
+**Ambiguous cases:** many products have both (a brand-heavy landing page +
+a product-mode dashboard). The register applies per-surface, not per-product.
+When unclear: ask — *"Is the user here to be impressed, or to accomplish a
+task?"*
+
+## Brand-mode failure modes
+
+- **Genericness:** Choosing the safe AI-slop palette (cream + brass, purple/violet gradient, three equal cards). The product is invisible in its category. Cross-check with `docs/guidelines/design-antipatterns.md` § Color and Visual.
+- **Inconsistency:** Brand direction picked for the hero, abandoned for the body. The page reads as two different products.
+- **Aesthetics-without-function:** Beautiful but confusing navigation, stunning hero with no CTA clarity.
+
+## Product-mode failure modes
+
+- **Strangeness-without-purpose:** A clever typographic choice that makes the CTA harder to scan. A gradient background on a data table. An animated page transition in an admin panel.
+- **Premature originality:** Reinventing a standard UI pattern (data table, form validation, dropdown) when the standard is what users expect.
+- **Over-engineering:** Five different card elevations in a dashboard that needs two.
+
+## The AI-slop originality self-test (applies to brand mode primarily)
+
+Run BOTH tiers before approving a brand-mode design direction:
+
+**Tier 1 — Category test:**
+Would a designer seeing 20 AI-generated [product category] UIs recognize this
+aesthetic as part of that category's default? (e.g., "SaaS → dark mode + purple
+gradient"; "health app → teal + rounded sans serif + white space").
+- If YES: rework the concept. The design is invisible in its category.
+- If NO: proceed to Tier 2.
+
+**Tier 2 — Anti-reference test:**
+Given the category AND three explicit aesthetics you've avoided — could a
+skeptic still guess the direction? (e.g., "fintech that's not navy-and-gold,
+not minimal white, not brutalist → everyone picks terminal dark").
+- If YES: dig deeper. "Avoiding the worst cliché" is not differentiation.
+- If NO: the direction is genuinely distinctive.
+
+**The bar:** a visitor should ask "how was this made?" not "which AI made this?"
+
+## Routing to skills by mode
+
+**Brand mode brief:**
+1. `design-intelligence` (grounded style/palette/typography selection — run the corpus first)
+2. `brand-identity` (archetype → token system)
+3. `iconography` (icon system selection for brand expression)
+4. `fe-design § Aesthetic direction` (direction → composition → typography → color)
+
+**Product mode brief:**
+1. `existing-ui-audit` (mandatory — inventory first)
+2. `accessibility-auditor` (WCAG compliance from the start)
+3. `ui-component-architect` (reuse existing primitives)
+4. `fe-design § Component Architecture, Form Design, Table Design` (standard patterns)
+
+**Both modes:** `design-antipatterns` (always pull), `design-review` (with anti-slop check)
+
+## See also
+
+- `docs/guidelines/design-antipatterns.md` — the slop-tell catalog; brand mode especially needs this
+- `brand-source-of-truth` — when a registered brand profile is present, it governs
+- `brand-consistency` — validates emitted artifacts against the brand profile
+- `design-system-capture` — DESIGN.md/PRODUCT.md capture the mode's decisions for cross-task consistency

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "@event4u/agent-config",
-    "version": "7.1.0",
+    "version": "7.2.0",
     "description": "Universal AI Agent OS — audited skills, governance rules, commands, and templates for AI coding tools (Claude Code, Cursor, Windsurf, Copilot).",
     "license": "MIT",
     "private": false,

package/src/config/agent-settings.template.yml

@@ -84,6 +84,24 @@ rule_loading_tier: __RULE_LOADING_TIER__
 lean_projection:
   mode: eager-all
 
+# --- Token-rich skills governance ---
+#
+# Skills marked `token_budget_class: rich` in their frontmatter are exempt
+# from telegraph-speak condensation and thin-projector trimming. They load
+# their full content (examples, tables, code blocks) to maximize design-output
+# quality. This setting controls whether that extra spend is allowed globally.
+#
+# Values:
+#   on   — rich skills load in full (default; recommended for design-intensive workflows)
+#   off  — rich skills fall back to standard condensed behavior
+#   ask  — before loading a rich skill, the agent surfaces an estimated token
+#          delta (≈ file size in chars / 4, reported in tokens not dollars) and
+#          asks the user once; the answer is cached for the session
+#
+# Configurable in the browser setup wizard (Setup → Skills → Token budget).
+tokens:
+  rich_skills: on
+
 # --- Cost tracking + budget enforcement ---
 #
 # USD budgets evaluated against `agents/cost-tracking/sessions.jsonl` by
@@ -785,6 +803,19 @@ update_check:
 explain:
   enable_last: true
 
+# ─── legal-review-prep consent gate ──────────────────────────────────────────
+# The legal-review-prep pack is high-risk (EU/DE legal review-prep, NOT legal
+# advice). It stays inactive until you acknowledge it is not legal advice — set
+# by the setup wizard's consent checkbox, or here by hand. The legal-safety-floor
+# rule refuses every legal-review-prep skill until `acknowledged: true`.
+legal_review_prep:
+  acknowledged: false
+  consented_at: ""
+  # Gate legal work-product behind a multi-model council / deep-research pass
+  # (defense-in-depth + audit trail; fail-closed). Off lets single-model legal
+  # output through — not recommended for this high-risk pack.
+  require_council: true
+
 # ─── secrets ────────────────────────────────────────────────────────────────
 # Local-only secret material. This whole file is gitignored, so the key never
 # enters the tracked tree.