@tangle-network/browser-agent-driver 0.29.0 → 0.31.0

package/dist/design/audit/rubric/anchors/saas-app.yaml

@@ -0,0 +1,38 @@
+type: saas-app
+score_9_10:
+  criteria:
+    - Domain object visible above the fold (tasks, deployments, conversations, files)
+    - One visually-dominant primary action per page state
+    - Empty states preview real product (sample rows, setup checklists, status timelines), not generic illustrations
+    - Action hierarchy = product hierarchy; no decorative buttons competing with workflow
+    - Trust details visible where commitment exists (price, permissions, undo, audit trail)
+  fixtures:
+    - fixture:linear-app
+    - fixture:figma-file-ui
+    - fixture:notion-editor
+    - fixture:superhuman
+    - fixture:github-pr-view
+score_7_8:
+  criteria:
+    - Most criteria from 9-10 with one or two minor gaps
+    - Polish gaps that don't block job completion
+    - Domain objects present but action hierarchy slightly diffuse
+  fixtures:
+    - fixture:airtable-grid
+    - fixture:notion-database
+score_5_6:
+  criteria:
+    - Functional but generic component-library assembly
+    - No domain object above the fold OR action hierarchy unclear
+    - Empty states show illustrations + platitudes instead of product preview
+    - Multiple equal-weight CTAs without a dominant primary
+  fixtures:
+    - fixture:generic-dashboard
+score_3_4:
+  criteria:
+    - No primary job inferable from screen
+    - Equal-weight CTAs blocking workflow
+    - Decorative elements actively distract from product surface
+    - Page reads as a marketing/setup stub rather than an operational product
+  fixtures:
+    - fixture:no-primary-action

package/dist/design/audit/rubric/anchors/social.yaml

@@ -0,0 +1,33 @@
+type: social
+score_9_10:
+  criteria:
+    - Feed prioritizes real content (posts, conversations) over chrome and ads
+    - Compose surface is one click away and primary in the layout
+    - Identity signals (verified accounts, profile preview, follower counts) consistent and lightweight
+    - State transitions (like, reply, repost) feel instant and reversible
+    - Empty states preview what the feed will look like with a few followed accounts
+  fixtures:
+    - fixture:threads-web
+    - fixture:bluesky-web
+    - fixture:substack-inline
+score_7_8:
+  criteria:
+    - Solid feed and compose flow but reply chains are visually flat
+    - Identity signals inconsistent across surfaces
+    - Empty states use illustrations rather than previewing real content
+  fixtures:
+    - fixture:generic-microblog
+score_5_6:
+  criteria:
+    - Feed cluttered with chrome (rails, ads, suggestions) competing with content
+    - Compose buried two clicks deep
+    - Action affordances (reply, like, share) are equal weight with no clear primary
+  fixtures:
+    - fixture:cluttered-feed
+score_3_4:
+  criteria:
+    - Page reads as ad inventory with content squeezed in
+    - No clear primary feed; multiple surfaces compete
+    - Identity signals fake or absent (anonymous content with no provenance)
+  fixtures:
+    - fixture:ad-heavy-feed

package/dist/design/audit/rubric/anchors/tool.yaml

@@ -0,0 +1,33 @@
+type: tool
+score_9_10:
+  criteria:
+    - Single-purpose surface — the input and output relationship is immediate and obvious
+    - Keyboard-first interaction (shortcuts, focus management, paste support)
+    - Output is copyable, exportable, and shareable without modal interruption
+    - Recent results, history, or undo always available
+    - State (input, processing, output, error) handled explicitly with clear transitions
+  fixtures:
+    - fixture:linear-command-palette
+    - fixture:github-pr-view
+    - fixture:raycast
+score_7_8:
+  criteria:
+    - Tool works well but lacks keyboard affordances or history
+    - Output exportable but with extra clicks
+    - Error states present but generic
+  fixtures:
+    - fixture:generic-converter
+score_5_6:
+  criteria:
+    - Form-and-submit pattern with reload-style output
+    - No keyboard shortcuts, no history, no undo
+    - Loading and error states use defaults
+  fixtures:
+    - fixture:basic-tool-form
+score_3_4:
+  criteria:
+    - Multi-step flow for what should be a single action
+    - Output requires manual selection/copy
+    - No error handling — failures show generic browser errors
+  fixtures:
+    - fixture:broken-tool

package/dist/design/audit/rubric/anchors/utility.yaml

@@ -0,0 +1,33 @@
+type: utility
+score_9_10:
+  criteria:
+    - Status, configuration, or admin surface that exposes the operational object directly (deploy, build, job, account)
+    - Real state (running, succeeded, failed, queued) with timestamps and durations
+    - Action affordances (retry, rollback, configure, audit) match the operational verbs of the system
+    - Logs, diagnostics, or detail panels are one click from the summary
+    - Empty states preview what real activity will look like
+  fixtures:
+    - fixture:vercel-deployment-status
+    - fixture:cloudflare-dashboard
+    - fixture:github-actions
+score_7_8:
+  criteria:
+    - Status surface clear but action affordances are generic (Edit/Save instead of Retry/Rollback)
+    - Logs accessible but require navigation
+    - Empty states use illustrations rather than previewing activity
+  fixtures:
+    - fixture:generic-admin
+score_5_6:
+  criteria:
+    - Status indicators are decorative pills without timestamps or durations
+    - Logs and diagnostics buried in modals
+    - Forms-of-forms pattern instead of operational verbs
+  fixtures:
+    - fixture:basic-settings-page
+score_3_4:
+  criteria:
+    - Status is text only — no visual signal of failure or success
+    - No way to retry, rollback, or audit from the surface
+    - Settings sprawl with no IA, no search
+  fixtures:
+    - fixture:settings-sprawl

package/dist/design/audit/rubric/fragments/audience-clinician.md

@@ -0,0 +1,42 @@
+---
+id: audience-clinician
+title: Clinician Audience
+weight: high
+applies-when:
+  audience: [clinician]
+---
+
+This surface is used by clinical professionals (physicians, nurses, pharmacists,
+therapists) in high-stakes decision-making contexts. Standard consumer-UX
+heuristics are insufficient — apply the following additional lens.
+
+INFORMATION DENSITY
+- Clinicians tolerate and often require high information density. Sparse
+  consumer-style layouts that hide detail behind progressive disclosure are
+  friction, not polish.
+- Data tables, lab result grids, medication lists must be fully visible without
+  expand/collapse. If key data is folded, score `content_ia` lower.
+
+WORKFLOW EFFICIENCY
+- Clinicians context-switch constantly (patient to patient, chart to EHR to
+  order entry). Keyboard navigation, dense primary actions, and minimal
+  confirmation dialogs for routine operations are expected.
+- If standard consumer patterns (fat CTAs, step-by-step wizards) dominate
+  routine tasks, score `workflow` lower.
+
+CRITICAL VALUE FLAGGING
+- Out-of-range lab values, drug interactions, and alert states must be
+  immediately visible with high visual contrast — not just color. Include
+  icon + text pattern redundancy.
+- Missing or weak critical-value flagging is a major finding in `trust_clarity`.
+
+AUDIT TRAIL AND ATTRIBUTION
+- Clinician workflows require visible "who did what, when" — last modified by,
+  order placed by, cosigned by. This is both regulatory and practical.
+- If attributable actions lack visible provenance, that is a major finding in
+  `trust_clarity`.
+
+DO NOT penalize for:
+- Dense information layouts (this is intentional)
+- Lack of illustrations or hero imagery
+- Technical terminology appropriate to the audience

package/dist/design/audit/rubric/fragments/audience-developer.md

@@ -0,0 +1,40 @@
+---
+id: audience-developer
+title: Developer Audience
+weight: medium
+applies-when:
+  audience: [developer]
+---
+
+This surface is used by software engineers and technical practitioners.
+
+INFORMATION OVER DECORATION
+- Code samples, CLI commands, API endpoints, and technical specifications must
+  be immediately accessible — not gated behind tabs, scrolling, or "Request
+  Demo" flows. If core technical content requires navigation to find, score
+  `content_ia` lower.
+
+COPY-PASTE HYGIENE
+- Every code block must have a visible copy button or be selectable without
+  capturing surrounding prose. Missing copy affordance is a minor-to-major
+  finding in `workflow` depending on frequency.
+
+DARK MODE AND TERMINAL AESTHETICS
+- Developers default to dark environments. A light-only surface with no dark
+  mode is a `visual_craft` minor finding. A surface that actively breaks
+  (illegible code contrast) in dark mode is major.
+
+AUTHENTICATION PATHS
+- API keys, tokens, and credentials should be displayed with
+  mask-by-default + reveal-on-click. Showing credentials in plaintext by
+  default is a critical `trust_clarity` finding.
+
+SEARCH AS PRIMARY NAVIGATION
+- Technical docs and reference surfaces must have a prominent, keyboard-
+  accessible search. If Cmd/Ctrl-K does not open search, that is a major
+  finding in `workflow`.
+
+DO NOT penalize for:
+- Dense information layouts
+- Monospace typography sections
+- Minimal illustration or marketing copy

package/dist/design/audit/rubric/fragments/audience-kids.md

@@ -0,0 +1,35 @@
+---
+id: audience-kids
+title: Kids Audience
+weight: critical
+applies-when:
+  audience: [kids]
+---
+
+This surface is used by or targeted at minors. Apply the following additional
+lens. Note: ethics rules in Layer 7 enforce hard score floors independently
+of rubric scoring — both layers apply simultaneously.
+
+AGE-APPROPRIATE LANGUAGE AND IMAGERY
+- Copy must be readable at the stated age level. Technical jargon, legalese,
+  or implicit social pressure ("Your friends are waiting!") are major findings
+  in `content_ia`.
+- Imagery should be appropriate for the age group. Mature themes, even subtle
+  ones, are critical findings in `trust_clarity`.
+
+FRICTION-SYMMETRIC FLOWS
+- Actions that benefit the operator (in-app purchase, data sharing, account
+  creation) must have equal or greater friction than their reversal
+  (cancellation, data deletion, account closure).
+- Any flow where it is easier to spend money / share data than to undo is a
+  critical finding in `workflow`.
+
+PARENTAL CONTROLS VISIBILITY
+- If the app collects data from minors, parental consent or control mechanisms
+  must be visible without buried navigation. If absent: major finding in
+  `trust_clarity`.
+
+DO NOT penalize for:
+- Simplified language and larger touch targets
+- Reduced information density appropriate to age
+- Bright color palettes and playful illustration styles

package/dist/design/audit/rubric/fragments/audience-vulnerability-minor-facing.md

@@ -0,0 +1,37 @@
+---
+id: audience-vulnerability-minor-facing
+title: Minor-Facing Audience Vulnerability
+weight: critical
+applies-when:
+  audienceVulnerability: [minor-facing]
+---
+
+This surface directly interacts with users who are minors or who are
+unaccompanied minors in a supervised context (e.g. school software, children's
+gaming, education platforms). The vulnerability is that the minor may not fully
+understand consent, financial consequence, or data implications. Apply this
+lens in addition to audience-kids and regulatory-coppa fragments.
+
+DARK PATTERN PROHIBITION — ENFORCED
+Every dark pattern is a critical finding when directed at minors. Dark patterns
+to look for:
+- Confirmshaming ("No thanks, I don't want to save money")
+- Fake urgency ("Only 2 left! Timer expires in 03:42")
+- Hidden costs revealed at final checkout step
+- Forced continuity (subscription auto-enrolled without explicit confirmation)
+- Misdirection (styled "X" button that is actually an ad click)
+
+IRREVERSIBILITY DISCLOSURE
+- Any action that is irreversible (purchase, deletion, sharing to others) must
+  be labeled explicitly. "Delete" without "This cannot be undone" is a major
+  finding in `trust_clarity`.
+
+SOCIAL COMPARISON AS PRESSURE
+- Leaderboards, "Your friends have X" notifications, or streak-loss warnings
+  designed to create anxiety are major `trust_clarity` findings when the
+  audience is minors.
+
+REPORTING AND BLOCKING CONTROLS
+- If the surface allows social interaction (messaging, comments, reactions),
+  visible reporting and blocking controls are required. Absent: major finding
+  in `trust_clarity`.

package/dist/design/audit/rubric/fragments/first-principles.md

@@ -0,0 +1,65 @@
+---
+id: first-principles
+title: First-Principles Fallback
+weight: critical
+applies-when:
+  universal: false
+---
+
+You haven't seen this pattern before. Do not fabricate a classification.
+Audit against the universal product principles only. Score per-dimension as
+usual, but set `rollup.confidence = "low"` and emit a top-level
+`novel_pattern_signal` describing what you observed, so this surface can be
+mined into a new fragment after enough fleet exposure.
+
+1. PRIMARY JOB CLARITY (5 sec test)
+   - Within 5 seconds, can a stranger name what this page is for?
+   - If no: severity major; finding category `product_intent`.
+
+2. PRIMARY ACTION OBVIOUSNESS
+   - Is there one visually-dominant action this page is built around?
+   - Are competing actions visually subordinate?
+   - If equal-weight: severity major; finding category `product_intent`.
+
+3. STATE PREVIEW
+   - Are empty/loading/error states designed, or browser-default / placeholder?
+   - Do empty states preview the real product, or show generic illustrations?
+   - If generic: severity major; finding category `product_intent`.
+
+4. TRUST BEFORE COMMITMENT
+   - Does the page ask the user to commit (money, identity, deploy, share)?
+   - If yes: are price, permissions, scope, undo path visible BEFORE the
+     commit button?
+   - If no: severity critical; finding category `trust_clarity`.
+
+5. RECOVERY FROM FAILURE
+   - Can the user undo their last action?
+   - Is there a clear path forward when something fails?
+   - If no: severity major; finding category `workflow`.
+
+GUARDRAILS:
+- Do not invent domain-specific findings ("this dashboard needs charts").
+  You don't know the domain. Stick to the five principles.
+- Do not anchor on marketing-page heuristics (hero copy, illustrations,
+  social proof). They don't apply.
+- If a principle simply doesn't apply (e.g. there is no commitment on this
+  page), say so explicitly rather than scoring it generically.
+
+RESPOND WITH ONLY a JSON object of the form:
+{
+  "scores": {
+    "product_intent": { "score": <1-10>, "range": [<lo>, <hi>], "confidence": "low", "summary": "<one sentence>", "primaryFindings": [] },
+    "visual_craft":   { ... },
+    "trust_clarity":  { ... },
+    "workflow":       { ... },
+    "content_ia":     { ... }
+  },
+  "rollup": { "score": <1-10>, "range": [<lo>, <hi>], "confidence": "low", "rule": "first-principles", "weights": { "product_intent": 0.30, "workflow": 0.25, "visual_craft": 0.20, "content_ia": 0.15, "trust_clarity": 0.10 } },
+  "findings": [ ... ],
+  "novel_pattern_signal": {
+    "observedSignals": [
+      { "label": "<short-label>", "evidence": "<what you saw>", "confidence": <0..1> }
+    ]
+  },
+  "first_principles_mode": true
+}

package/dist/design/audit/rubric/fragments/modality-mobile.md

@@ -0,0 +1,39 @@
+---
+id: modality-mobile
+title: Mobile Modality
+weight: medium
+applies-when:
+  modality: [mobile]
+---
+
+This surface is evaluated at a mobile viewport (≤480px wide). Apply the
+following lens on top of page-type and domain fragments.
+
+TOUCH TARGET SIZING
+- Interactive elements must meet minimum 44×44pt touch targets (WCAG 2.5.5
+  AAA; Apple HIG minimum). Anything below 32pt is a major finding in
+  `workflow`. Count the number of undersized targets — if >3 on a single
+  screen, escalate to critical.
+
+THUMB-ZONE REACHABILITY
+- Primary actions must be reachable in the bottom 60% of a 375px screen
+  one-handed. A primary CTA pinned to the top of the viewport is a major
+  `workflow` finding.
+
+HORIZONTAL SCROLL AVOIDANCE
+- Content must not require horizontal scroll on a 375px viewport. Tables
+  that overflow without a scroll affordance are major `workflow` findings.
+
+FONT LEGIBILITY
+- Body text must be ≥16px (browser zoom notwithstanding). Text smaller than
+  14px is a major `visual_craft` finding. Text below 12px is critical.
+
+FORM INPUT KEYBOARD
+- Input fields must trigger the appropriate virtual keyboard type (numeric
+  for phone/postcode, email for email, tel for phone numbers). Wrong keyboard
+  type is a minor `workflow` finding per field.
+
+DO NOT penalize for:
+- Navigation patterns specific to mobile (hamburger, bottom tab bar)
+- Reduced visible surface area compared to desktop
+- Single-column layouts

package/dist/design/audit/rubric/fragments/modality-tablet.md

@@ -0,0 +1,35 @@
+---
+id: modality-tablet
+title: Tablet Modality
+weight: low
+applies-when:
+  modality: [tablet]
+---
+
+This surface is evaluated at a tablet viewport (481–1024px wide). Apply this
+lens on top of page-type and domain fragments.
+
+LAYOUT ADAPTATION
+- The layout must actually adapt between mobile and desktop — not simply
+  scale a mobile layout or stretch a desktop layout. A layout that is
+  identical to either breakpoint is a minor `visual_craft` finding.
+
+SPLIT-VIEW AND SIDEBAR OPPORTUNITIES
+- Tablet viewports often benefit from master-detail or sidebar-content
+  patterns rather than single-column stacks. If the content hierarchy would
+  benefit from a persistent sidebar and none is present, that is a minor
+  `workflow` finding.
+
+TOUCH AND POINTER HYBRID
+- Tablet users may use touch or pointer. Touch targets must still meet the
+  44pt minimum. Hover-only affordances without touch fallbacks are major
+  `workflow` findings.
+
+LANDSCAPE AND PORTRAIT PARITY
+- Key interactions must work in both orientations. If a primary action is
+  unreachable in landscape (below fold with no scroll), that is a major
+  `workflow` finding.
+
+DO NOT penalize for:
+- Adapting typography slightly smaller than mobile maximums
+- Showing more information density than the mobile equivalent

package/dist/design/audit/rubric/fragments/regulatory-coppa.md

@@ -0,0 +1,32 @@
+---
+id: regulatory-coppa
+title: COPPA Regulatory Context
+weight: critical
+applies-when:
+  regulatoryContext: [coppa]
+---
+
+This surface is subject to COPPA (Children's Online Privacy Protection Act).
+Apply this lens when the audience includes or may include users under 13. The
+ethics gate (Layer 7) independently enforces hard score floors for missing
+age gates and dark patterns — both apply simultaneously.
+
+VERIFIABLE PARENTAL CONSENT
+- If this surface collects personal data from users who may be under 13,
+  a verifiable parental consent mechanism must be visible and functional.
+  Absent: critical finding in `trust_clarity`.
+
+AGE GATE INTEGRITY
+- Age gates must require date-of-birth entry, not a single yes/no question
+  ("Are you 13 or older?"). A single-question age gate is a major finding —
+  it is trivially bypassed.
+
+DATA COLLECTION DISCLOSURE
+- A clear, plain-English summary of what data is collected and why must be
+  visible before any data collection begins. Buried in a privacy policy does
+  not satisfy this requirement. Absent: major finding in `content_ia`.
+
+PROHIBITION ON BEHAVIORAL TARGETING
+- No behavioral advertising or cross-site tracking may be enabled for users
+  under 13. If third-party tracking scripts are present without age-based
+  gating: critical finding in `trust_clarity`.

package/dist/design/audit/rubric/fragments/regulatory-gdpr.md

@@ -0,0 +1,33 @@
+---
+id: regulatory-gdpr
+title: GDPR Regulatory Context
+weight: high
+applies-when:
+  regulatoryContext: [gdpr]
+---
+
+This surface is subject to GDPR. Apply the following lens in addition to other
+applicable fragments. Note: the ethics gate (Layer 7) independently enforces a
+score floor for missing consent mechanisms — both apply.
+
+CONSENT MECHANISM QUALITY
+- Cookie consent banners must offer granular controls (necessary / analytics /
+  marketing) with equal visual prominence. An "Accept all" button that is
+  larger or more prominent than "Manage preferences" is a major `trust_clarity`
+  finding.
+- Pre-ticked checkboxes are a critical finding — they are unlawful under GDPR.
+
+DATA SUBJECT RIGHTS ACCESS
+- Users must be able to find their data rights (access, deletion, portability,
+  correction) without more than 2 navigation steps from any page. If the
+  privacy page is not reachable from the footer, that is a major finding in
+  `content_ia`.
+
+LEGAL BASIS TRANSPARENCY
+- If the page collects personal data, the legal basis (consent, legitimate
+  interest, contract) must be stated. Absent: minor finding in `trust_clarity`.
+
+DATA RETENTION
+- If retention periods are disclosed (they should be), they must be
+  understandable to a non-lawyer. Legal boilerplate with no plain-English
+  summary is a minor finding in `content_ia`.

package/dist/design/audit/rubric/fragments/regulatory-hipaa.md

@@ -0,0 +1,36 @@
+---
+id: regulatory-hipaa
+title: HIPAA Regulatory Context
+weight: high
+applies-when:
+  regulatoryContext: [hipaa]
+---
+
+This surface handles Protected Health Information (PHI) and is subject to HIPAA
+technical safeguards. Apply this lens in addition to domain-specific fragments.
+
+SESSION SECURITY VISIBILITY
+- Automatic session timeout must be visible to the user (countdown or clear
+  logout trigger). Invisible timeout with hard logout is a major `workflow`
+  finding.
+- If the surface shows PHI and has no visible session indicator, that is a
+  major `trust_clarity` finding.
+
+MINIMUM NECESSARY DATA
+- Only the minimum necessary PHI should be visible on any given screen.
+  Dashboards that show full SSN, full DOB, or complete medication histories
+  when partial identifiers suffice are major `trust_clarity` findings.
+
+AUDIT LOG ACCESS
+- If this surface allows modification of PHI, a visible "audit log" or
+  "activity history" link must be accessible to the user. Absent: minor
+  finding in `trust_clarity`.
+
+DATA EXPORT LABELING
+- Export buttons (CSV, PDF, print) must label the output as PHI with a
+  handling reminder. Unlabeled PHI export is a minor finding.
+
+DO NOT penalize for:
+- Explicit data masking that adds cognitive load (masks protect PHI)
+- Confirmation dialogs on irreversible PHI operations
+- Conservative color coding that prioritizes legibility over aesthetics

package/dist/design/audit/rubric/fragments/universal-product-intent.md

@@ -0,0 +1,48 @@
+---
+id: universal-product-intent
+title: Product Intent & Outcome Fit
+weight: critical
+dimension: product-clarity
+applies-when:
+  universal: true
+---
+
+PRODUCT INTENT AUDIT — judge the screen by the job it must do, not by generic prettiness.
+
+Before scoring, infer these from the screenshot and classification:
+- Primary audience: who is this for right now?
+- Primary job: what must this page help them accomplish?
+- Primary action: what should they do next?
+- Stakes: what can go wrong if the UI is unclear? Money, trust, data loss, wrong deployment, wasted time, safety, legal/medical risk, brand trust, or simple confusion.
+- Success path: what is the shortest believable path from landing on this screen to completing the job?
+
+Then evaluate brutally:
+- Does the page make the primary job obvious within 5 seconds?
+- Is the main action visually and semantically dominant, or is it buried among equal-weight controls?
+- Does the content shown match the user's intent, or is it filler, meta copy, marketing fluff, or generic component-library scaffolding?
+- Are empty/loading/disconnected states still useful previews of the real product, or do they make the product look unfinished?
+- Does the information architecture match the audience's mental model?
+- Are trust-critical details visible before commitment: price, permissions, data source, provenance, verification, risk, status, ownership, or next steps?
+- Does the design use the domain's natural artifacts? Examples: ledgers and receipts for finance, logs and deployments for devtools, product cards and checkout for ecommerce, source/code/examples for developer products, clinical clarity for health, creator/social proof for social products.
+
+WHAT TO PUNISH:
+- Vague dashboards that show containers instead of decisions.
+- Copy that explains the UI rather than helping the user act.
+- Equal-weight buttons for unequal actions.
+- Generic empty states where real state previews, sample rows, setup checklists, or status timelines would communicate the product.
+- Decorative graphics that block or distract from the job.
+- Beautiful surfaces that do not clarify what the product does.
+- Navigation chrome that feels more important than the workflow.
+
+WHAT TO REWARD:
+- One obvious primary action per page state.
+- Real domain objects above the fold: deployments, jobs, payouts, orders, patients, tasks, files, incidents, products, conversations, etc.
+- Clear state machines: draft → pending → active → failed → complete.
+- Trust-building detail where risk exists.
+- Progressive disclosure: simple first screen, serious detail available when needed.
+- Visual hierarchy driven by the product model, not by arbitrary cards.
+
+SCORING IMPACT:
+- If users cannot tell what the product is for or what to do next, cap the page at 6 no matter how clean it looks.
+- If the screen is visually polished but mostly generic scaffolding, cap it at 7.
+- 8+ requires product specificity: the page must feel designed for this exact product, audience, and workflow.

package/dist/design/audit/rubric/loader.d.ts

@@ -6,6 +6,19 @@
  * `~/.bad/rubrics/` for user fragments). No code changes required.
  */
 import type { PageClassification, RubricFragment, ComposedRubric } from '../types.js';
+import type { AudienceTag, ModalityTag, RegulatoryContextTag, AudienceVulnerabilityTag } from '../v2/types.js';
+/**
+ * Operator-supplied context for Layer 6 composable predicate matching.
+ * When provided, fragments whose `applies-when.audience | modality |
+ * regulatoryContext | audienceVulnerability` overlap with these values are
+ * included in the composed rubric alongside the classification-matched set.
+ */
+export interface RubricContext {
+    audience?: AudienceTag[];
+    modality?: ModalityTag[];
+    regulatoryContext?: RegulatoryContextTag[];
+    audienceVulnerability?: AudienceVulnerabilityTag[];
+}
 /**
  * Parse a markdown fragment file into a RubricFragment.
  * Frontmatter format:
@@ -25,22 +38,29 @@ export declare function parseFragment(filePath: string): RubricFragment;
  */
 export declare function loadFragments(dir?: string): RubricFragment[];
 /**
- * Predicate evaluator. Returns true if the fragment applies to the classification.
+ * Predicate evaluator. Returns true if the fragment applies to the classification
+ * or the optional Layer 6 context (audience / modality / regulatoryContext /
+ * audienceVulnerability hints).
  *
  * Universal fragments always apply.
- * Type/domain/maturity/designSystem predicates are AND-combined: all listed
- * fields must match. Within a field, the classification value must be in the
- * fragment's allowed set.
+ * Predicate groups are OR-combined at the group level: a fragment fires if ANY
+ * one of its predicate groups matches. Within a group, list membership is used
+ * (the classification/context value must appear in the fragment's allowed set).
+ *
+ * Layer 6 predicates are additive: they can cause a fragment to fire even when
+ * no type/domain predicate matches, enabling composition across independent
+ * predicate dimensions.
  */
-export declare function fragmentApplies(fragment: RubricFragment, classification: PageClassification): boolean;
+export declare function fragmentApplies(fragment: RubricFragment, classification: PageClassification, ctx?: RubricContext): boolean;
 /**
  * Compose a rubric from a classification.
  *
  * @param classification - the page classification
  * @param fragments - all loaded fragments (defaults to builtin)
  * @param userFragmentsDir - optional path to user-supplied fragments
+ * @param ctx - optional Layer 6 context for audience/modality/regulatory predicates
  */
-export declare function composeRubric(classification: PageClassification, fragments?: RubricFragment[], userFragmentsDir?: string): ComposedRubric;
+export declare function composeRubric(classification: PageClassification, fragments?: RubricFragment[], userFragmentsDir?: string, ctx?: RubricContext): ComposedRubric;
 /**
  * Compose a rubric from an explicit profile name (for `--profile` override).
  * Loads only the matching type fragment + universal fragments.

package/dist/design/audit/rubric/loader.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"loader.d.ts","sourceRoot":"","sources":["../../../../src/design/audit/rubric/loader.ts"],"names":[],"mappings":"AAAA;;;;;;GAMG;AAKH,OAAO,KAAK,EACV,kBAAkB,EAClB,cAAc,EACd,cAAc,EAEf,MAAM,aAAa,CAAA;AAYpB;;;;;;;;;;;;GAYG;AACH,wBAAgB,aAAa,CAAC,QAAQ,EAAE,MAAM,GAAG,cAAc,CAiB9D;AAkED;;GAEG;AACH,wBAAgB,aAAa,CAAC,GAAG,GAAE,MAA8B,GAAG,cAAc,EAAE,CAMnF;AAED;;;;;;;GAOG;AACH,wBAAgB,eAAe,CAC7B,QAAQ,EAAE,cAAc,EACxB,cAAc,EAAE,kBAAkB,GACjC,OAAO,CA4BT;AAED;;;;;;GAMG;AACH,wBAAgB,aAAa,CAC3B,cAAc,EAAE,kBAAkB,EAClC,SAAS,CAAC,EAAE,cAAc,EAAE,EAC5B,gBAAgB,CAAC,EAAE,MAAM,GACxB,cAAc,CAgChB;AAED;;;GAGG;AACH,wBAAgB,wBAAwB,CACtC,OAAO,EAAE,MAAM,EACf,iBAAiB,CAAC,EAAE,cAAc,EAAE,GACnC,cAAc,CAsBhB"}
+{"version":3,"file":"loader.d.ts","sourceRoot":"","sources":["../../../../src/design/audit/rubric/loader.ts"],"names":[],"mappings":"AAAA;;;;;;GAMG;AAKH,OAAO,KAAK,EACV,kBAAkB,EAClB,cAAc,EACd,cAAc,EAEf,MAAM,aAAa,CAAA;AACpB,OAAO,KAAK,EACV,WAAW,EACX,WAAW,EACX,oBAAoB,EACpB,wBAAwB,EACzB,MAAM,gBAAgB,CAAA;AAEvB;;;;;GAKG;AACH,MAAM,WAAW,aAAa;IAC5B,QAAQ,CAAC,EAAE,WAAW,EAAE,CAAA;IACxB,QAAQ,CAAC,EAAE,WAAW,EAAE,CAAA;IACxB,iBAAiB,CAAC,EAAE,oBAAoB,EAAE,CAAA;IAC1C,qBAAqB,CAAC,EAAE,wBAAwB,EAAE,CAAA;CACnD;AAYD;;;;;;;;;;;;GAYG;AACH,wBAAgB,aAAa,CAAC,QAAQ,EAAE,MAAM,GAAG,cAAc,CAiB9D;AAkED;;GAEG;AACH,wBAAgB,aAAa,CAAC,GAAG,GAAE,MAA8B,GAAG,cAAc,EAAE,CAMnF;AAED;;;;;;;;;;;;;GAaG;AACH,wBAAgB,eAAe,CAC7B,QAAQ,EAAE,cAAc,EACxB,cAAc,EAAE,kBAAkB,EAClC,GAAG,CAAC,EAAE,aAAa,GAClB,OAAO,CA2CT;AAED;;;;;;;GAOG;AACH,wBAAgB,aAAa,CAC3B,cAAc,EAAE,kBAAkB,EAClC,SAAS,CAAC,EAAE,cAAc,EAAE,EAC5B,gBAAgB,CAAC,EAAE,MAAM,EACzB,GAAG,CAAC,EAAE,aAAa,GAClB,cAAc,CAgChB;AAED;;;GAGG;AACH,wBAAgB,wBAAwB,CACtC,OAAO,EAAE,MAAM,EACf,iBAAiB,CAAC,EAAE,cAAc,EAAE,GACnC,cAAc,CA0BhB"}