@jini-ai/agent-plugins 0.6.15-rc.2 → 0.6.15

package/ui-ux-design/skills/ui-ux-design/references/research-and-validation.md

@@ -1,78 +0,0 @@
-# Research and Validation
-
-Use this reference when the design needs a validation plan, clearer user framing, or a way to separate assumptions from evidence.
-
-## Important Constraint
-
-Do not present invented research as completed research. Use this reference to structure:
-
-- proposed research plans
-- user hypotheses
-- validation criteria
-- usability-test plans
-
-## Useful Artifacts
-
-### Proto-Persona
-
-Use when real research does not yet exist.
-
-Include:
-
-- user type
-- main goals
-- main frustrations
-- environment/context of use
-- skill level
-- critical accessibility considerations
-
-Label it explicitly as a working assumption.
-
-### Journey Snapshot
-
-Map:
-
-- trigger
-- entry point
-- main steps
-- friction points
-- moments of uncertainty
-- completion state
-- follow-up state
-
-### Usability-Test Plan
-
-Define:
-
-- research questions
-- participant criteria
-- tasks to complete
-- success criteria
-- metrics to watch
-- qualitative prompts
-
-### Validation Checklist
-
-Use before handoff:
-
-- does the layout support the primary user goal quickly
-- are key decisions reversible
-- do labels match user language
-- are errors recoverable
-- is the empty state actionable
-- is keyboard/mobile usage still workable
-
-## When This Reference Is Worth Loading
-
-- dashboard or workflow-heavy UI
-- ambiguous user roles
-- onboarding flows
-- high-risk UX with multiple steps
-- claims about "user needs" that need structure
-
-## Anti-Patterns
-
-- pretending empathy maps are evidence
-- writing personas with no behavioral relevance
-- validation plans with no measurable success criteria
-- feature flows optimized for internal assumptions only

package/ui-ux-design/skills/ui-ux-design/references/sam-crawford-premium-websites.md

@@ -1,93 +0,0 @@
-# Sam Crawford Premium Website Notes
-
-Source context: extracted from user-provided transcript files attributed to Sam Crawford / bycrawford, including:
-
-- `Brutally Honest Advice About Web Design in 9 mins.txt`
-- `How To Build a Website SO Premium They Beg You To Buy.txt`
-- `The Psychology of Premium Websites.txt`
-
-The duplicate file `Brutally Honest Advice About Web Design in 9 mins (1).txt` was ignored because it matched the non-suffixed file byte-for-byte.
-
-The later pasted checklist `How to Build a Website So Premium People Trust You Instantly` was reviewed and treated as redundant with this reference. It restates the same system around intentional first impression, bespoke assets, brand foundations, subtle animation, strategic structure, client autonomy, and handover/post-launch care.
-
-## Core Thesis
-
-Premium websites create a fast feeling of quality, trust, and authority through intentional first impressions, clarity, bespoke visual systems, and restrained details. The goal is not just to look impressive; the site must help the right visitor understand the offer, trust the business, and take the next action.
-
-## Psychological Principles
-
-- **Halo effect:** visitors form an initial judgment extremely quickly, and that judgment colors how they interpret the rest of the site. Treat the hero and first viewport as the highest-value real estate.
-- **Cognitive fluency:** people trust experiences that are easy to process. Reduce confusion with simple navigation, strong hierarchy, predictable layouts, clear copy, and generous spacing.
-- **Peak-end rule:** users remember standout moments and the ending more than the average of the whole experience. Use micro-interactions, confirmation states, polished transitions, and good completion moments to create small positive peaks.
-
-## Premium Signals
-
-- Use bespoke assets instead of generic icons, default templates, and disconnected stock imagery.
-- Make graphics serve a purpose: break up content, guide the eye, clarify the message, or reinforce the brand.
-- Use a professional logo, cohesive color palette, and thoughtfully chosen fonts as the foundation.
-- Prefer real imagery, even imperfect real imagery, when it proves that the business is genuine.
-- Use metrics, case studies, real faces, and specific proof where they build trust faster than paragraphs.
-- Give the design a point of view so the business does not look interchangeable with competitors.
-
-## Copy And Content
-
-- Write for scanners. Use short sections, obvious headings, bolded essentials, and copy that can be understood at a glance.
-- Cut weak copy aggressively. If removing a sentence does not make the page worse, remove it.
-- Sell the result or transformation, not the internal feature list.
-- Make the about page reassure the visitor: credibility, understanding of their problem, proof of having solved it before, and the transformation created.
-- Be explicit about who the offer is for and who it is not for.
-- Where commercially appropriate, show pricing or at least a starting point to filter the wrong leads and attract qualified buyers.
-
-## Structure And Conversion
-
-- Give each page a purpose and a next step.
-- Make the CTA obvious, easy to find, and easy to take.
-- Use fewer, stronger pages instead of many mediocre pages.
-- Ensure the site map, page hierarchy, internal linking, and content organization make sense for both people and search engines.
-- Do not bury the main action in the footer or force visitors to guess the next logical step.
-- Treat confusion as a conversion leak.
-
-## Animation And Interaction
-
-- Use subtle motion for feedback, orientation, and attention guidance.
-- Good examples: button hover response, natural content fade-in, smooth transitions, useful form validation feedback.
-- Avoid animation that becomes the thing people notice instead of the offer.
-- Avoid heavy 3D, parallax, or scroll effects when they slow the site, overwhelm the visitor, or distract from the message.
-- Respect reduced-motion preferences and performance budgets.
-
-## Performance And Practicality
-
-- A premium site must feel fast, especially on mobile and weak connections.
-- Compress images, avoid bloated plugins, and question every unnecessary animation or asset.
-- Test outside the designer's ideal setup: mobile viewport, slower network, and realistic user paths.
-- Avoid black-box builds when client ownership matters. A premium site should be practical to update, not a trap that requires a developer for every content change.
-- Treat launch as the start: collect data, test, optimize, add fresh proof, and keep the site current.
-
-## Audit Checklist
-
-- Does the first viewport create the intended feeling within a blink?
-- Can a scanner understand what the business does, who it helps, and what to do next?
-- Is the hero visually premium without being vague?
-- Are images real, bespoke, or clearly product-relevant rather than generic filler?
-- Are typography, logo, and colors cohesive?
-- Is there enough whitespace for calm and hierarchy?
-- Does each section have one primary job?
-- Are CTAs clear, repeated at logical points, and easy to act on?
-- Is proof specific: numbers, clients, outcomes, faces, stories, case studies?
-- Does the site repel poor-fit visitors as well as attract good-fit visitors?
-- Are animations subtle, purposeful, and performant?
-- Is the page fast on mobile?
-- Is the site maintainable after launch?
-- Are there obvious next optimization steps after launch?
-
-## Conflict Handling For Future References
-
-If another reference recommends a different direction, resolve the conflict by asking:
-
-1. What audience is this for?
-2. What feeling should the first impression create?
-3. What business action should the page drive?
-4. Which advice improves clarity, trust, and conversion for this context?
-5. Which advice introduces avoidable risk in performance, accessibility, or maintainability?
-
-Document the chosen direction briefly instead of silently merging incompatible advice.

package/ui-ux-design/skills/ui-ux-design/references/self-made-web-designer-core-skills.md

@@ -1,123 +0,0 @@
-# Self-Made Web Designer Core Skills Notes
-
-Source context: extracted from user-provided transcript files attributed to Self-Made Web Designer:
-
-- `The Only 5 Web Design Skills That Actually Matter (2025).txt`
-- `6 Tips to 10x ANY Site's Design.txt`
-
-## Core Thesis
-
-Strong web design comes from a small set of repeatable fundamentals: typography, layout, color, code literacy, and conversion thinking. Premium polish is not just taste; it comes from systems, deliberate focal ideas, and enough iteration to avoid settling for the first workable version.
-
-## The Five Skills
-
-### Typography
-
-- Treat typography as the largest visual surface on most websites.
-- Pick fonts that match the project's personality instead of defaulting to the same overused free fonts.
-- Consider less common free or affordable sources such as Fontshare and Uncut when a project needs more personality.
-- Build a type scale instead of eyeballing sizes. Start with a base body size, often around 16px, then scale headings consistently.
-- Use `rem` values where practical so type scales remain systematic.
-- Keep body text letter spacing at the default for legibility.
-- Tighten heading letter spacing and line height only where the larger type benefits from more impact.
-- Use about 150% line height for paragraph text as a starting point.
-
-### Layout
-
-- Use systems rather than dragging elements until they feel right.
-- Start from a responsive column grid: 12 columns on desktop, 8 on tablet, and 4 on mobile is a useful default.
-- Use an 8-point spacing system for rhythm: 8, 16, 24, 32, and so on.
-- Build visual hierarchy with proximity, size, contrast, and alignment.
-- Keep related items close together and unrelated items clearly separated.
-- Use clean alignment to make the structure feel intentional.
-
-### Color
-
-- Use fewer colors more intentionally. A small palette usually beats many unrelated colors.
-- Use the 60/30/10 rule as a starting point: neutral/background/text colors, supporting colors, and accent colors for CTAs or emphasis.
-- Prefer opacity and tints from a core color before adding more unrelated colors.
-- Check contrast: roughly 4.5:1 for smaller text and 3:1 for larger text are useful accessibility thresholds.
-- Borrow and refine proven palettes rather than inventing every palette from scratch.
-- Use browser tooling such as Chrome DevTools CSS Overview to inspect real sites' color and type systems.
-
-### Code Literacy
-
-- Learn enough HTML, CSS, JavaScript, and platform-specific basics to understand what the design requires and how to adapt it.
-- A designer does not need to become a full-stack developer, but code literacy separates practical designers from purely visual ones.
-- Start from examples, snippets, CodePen, or generated code that gets most of the way there, then adjust the final behavior and polish.
-- Design with implementation constraints in mind.
-
-### Conversion
-
-- Design for action, not just looks.
-- Give every page one primary goal: buy, book, sign up, download, or another clear action.
-- Put a clear CTA in the hero, navigation, and at logical intervals down the page.
-- Build trust with clarity, emotion, testimonials, reviews, and social proof.
-- Make users know, like, trust, and feel something from the brand.
-- Do not improve visual style at the cost of the user journey.
-
-## Six Fast Upgrade Techniques
-
-### 1. Upgrade Typography With Font Pairing
-
-- One-font sites can work, but stronger visual character often comes from a better pairing system.
-- Use superfamilies when you want cohesion with low risk.
-- Use separate font families when you need more personality, but ensure they feel from the same world.
-- Choose an anchor font first. For many web pages, the headline font is the best anchor because it sets the personality.
-- Pick supporting fonts that contrast enough to add interest without feeling accidental.
-- Avoid pairings that are almost the same but slightly different; they often look unintentional.
-- Use references such as Fonts In Use to see proven pairings for a chosen anchor font.
-
-### 2. Create A Star Of The Show
-
-- A website is often the first meeting with a brand, so it should make the visitor feel something.
-- Pick one visual idea that anchors attention long enough for the visitor to understand and act.
-- The star can be a font, image, object, illustration, product visual, gradient, chart motif, or interactive element.
-- Connect the star to the story of the site rather than choosing it only because it looks cool.
-- Let surrounding design decisions grow from that focal idea.
-
-### 3. Use Visual Rhyming
-
-- Repeat details from the core visual idea across the page so everything feels from the same universe.
-- Rhyming can happen through shapes, colors, textures, gradients, masks, icons, card treatments, buttons, or link details.
-- Pull pieces from the strongest visual element and reuse them in secondary elements.
-- Use repetition to create cohesion, not clutter.
-
-### 4. Add Subtle Depth
-
-- Use depth to make digital interfaces feel more tangible.
-- Examples include light texture, noise, glass effects, layered cards, shadows, dimensional product elements, or 3D details.
-- Keep depth subordinate to the star of the show.
-- Avoid depth that competes with copy, harms readability, or looks like decoration pasted on top.
-
-### 5. Use Opacity For Hierarchy
-
-- Do not make every text element equally loud.
-- Keep the most important headline or action at full emphasis.
-- Lower opacity for supporting text, metadata, captions, muted navigation, or less important labels.
-- Use opacity deliberately to help the eye know what to read first, skim second, and ignore unless needed.
-- Maintain sufficient contrast for accessibility.
-
-### 6. Explore Strong Variants
-
-- Do not keep polishing only the first idea.
-- Create intentionally different versions: light and dark modes, different layout structures, different focal visuals, different font anchors, or different image concepts.
-- Push far enough away from the first version to reveal better possibilities.
-- Compare variants against the page goal, first-impression target, readability, and conversion path.
-
-## Practical Audit Checklist
-
-- Is the type system deliberate, readable, and distinctive enough for the brand?
-- Are heading, body, line-height, and spacing choices systematic?
-- Does the layout use a clear responsive grid?
-- Is spacing rhythmic and based on repeatable increments?
-- Is the page hierarchy obvious to a scanner?
-- Does the palette have a restrained structure and clear roles?
-- Does every important color pairing pass contrast expectations?
-- Is there one primary page goal?
-- Are CTAs visible early and repeated where the user naturally needs them?
-- Does the page have a memorable focal idea connected to the offer?
-- Are visual details repeated enough to feel cohesive?
-- Is depth subtle and supportive?
-- Are less important elements visually quieter?
-- Were multiple meaningfully different variants explored before settling?

package/ui-ux-design/skills/ui-ux-design/references/visual-storytelling.md

@@ -1,57 +0,0 @@
-# Visual Storytelling
-
-Use this reference for marketing pages, explainers, campaign surfaces, infographics, and interfaces where narrative sequence materially affects comprehension.
-
-## Core Rule
-
-A narrative surface needs an intentional sequence, not just stacked sections.
-
-## Narrative Frame
-
-Define:
-
-1. setup: what the user understands first
-2. tension/problem: what is difficult, costly, or unclear
-3. resolution: how the product or feature resolves it
-4. proof: why the claim is credible
-5. action: what the user should do next
-
-## Suitable Use Cases
-
-- landing pages
-- product launches
-- case-study pages
-- data storytelling
-- onboarding sequences
-- scroll-based explainers
-
-## Information Design Rules
-
-- one primary message per section
-- strong heading hierarchy
-- visual proof close to the claim it supports
-- charts selected for comparison clarity, not decoration
-- progressive disclosure where density is high
-
-## Visual Proof Options
-
-- screenshots
-- before/after comparisons
-- metrics callouts
-- testimonials
-- diagrams
-- annotated flows
-
-## Data Visualization Rules
-
-- choose the simplest chart that answers the question
-- label directly when possible
-- do not rely on color alone
-- use narrative annotations sparingly and intentionally
-
-## Anti-Patterns
-
-- motion-heavy storytelling with no information gain
-- hero sections that hide the actual value proposition
-- decorative diagrams with no explanatory role
-- multi-section pages where every section competes equally

package/ui-ux-design/skills/vercel-web-design-guidelines/SKILL.md

@@ -1,39 +0,0 @@
----
-name: vercel-web-design-guidelines
-description: Review UI code for Web Interface Guidelines compliance. Use when asked to "review my UI", "check accessibility", "audit design", "review UX", or "check my site against best practices".
-metadata:
-  author: vercel
-  version: "1.0.0"
-  argument-hint: <file-or-pattern>
----
-
-# Web Interface Guidelines
-
-Review files for compliance with Web Interface Guidelines.
-
-## How It Works
-
-1. Fetch the latest guidelines from the source URL below
-2. Read the specified files (or prompt user for files/pattern)
-3. Check against all rules in the fetched guidelines
-4. Output findings in the terse `file:line` format
-
-## Guidelines Source
-
-Fetch fresh guidelines before each review:
-
-```
-https://raw.githubusercontent.com/vercel-labs/web-interface-guidelines/main/command.md
-```
-
-Use WebFetch to retrieve the latest rules. The fetched content contains all the rules and output format instructions.
-
-## Usage
-
-When a user provides a file or pattern argument:
-1. Fetch guidelines from the source URL above
-2. Read the specified files
-3. Apply all rules from the fetched guidelines
-4. Output findings using the format specified in the guidelines
-
-If no files specified, ask the user which files to review.

package/ui-ux-design/skills/web-compliance/SKILL.md

@@ -1,129 +0,0 @@
-# Web Compliance
-
-## Purpose
-Provide a practical compliance checklist for website-facing features so review agents can consistently catch legal and policy risks before release.
-
-## Scope
-This skill is a risk-screening layer for product and engineering workflows, not legal advice. It helps teams surface issues early and escalate to legal/privacy/security reviewers when needed.
-
-## Jurisdiction Baseline
-Apply checks based on the strictest applicable region for the release scope.
-
-- EU/EEA: GDPR + ePrivacy (opt-in consent for non-essential cookies/tracking)
-- UK: UK GDPR + PECR (similar consent posture to EU)
-- California: CCPA/CPRA (notice + opt-out model for "sale/share" contexts)
-- Canada: PIPEDA/CASL (privacy + strong marketing consent requirements)
-- US (SMS): TCPA constraints for promotional SMS consent and disclosures
-
-If target regions are unknown, mark as `high` uncertainty and escalate for legal confirmation before launch.
-
-## Use When
-- Feature introduces forms, tracking, cookies, analytics, personalization, ads, or user-generated content
-- Feature changes terms, pricing, claims, consent text, email/SMS capture, account creation, or account deletion flows
-- Feature impacts regional availability or age-restricted experiences
-
-## Core Checklist
-
-### Privacy and Data Handling
-- Personal data collection points are explicit and minimal for the feature goal
-- Sensitive/special-category data is identified and handled with elevated controls where required (for example: health data, racial/ethnic origin, religious beliefs, political opinions, genetic data, biometric data, sexual orientation, trade union membership, precise geolocation where regulated)
-- Privacy notice and just-in-time disclosures are present where data is collected
-- Consent and preference choices are explicit where required (no hidden defaults)
-- Data retention/deletion expectations are reflected in UX copy and flow behavior
-- Data subject request (DSR) mechanisms exist and are usable for access/export/deletion/portability where required
-- DSR identity verification and response-path UX are defined (do not rely on policy copy alone)
-- DSR flow communicates expected response timing/status updates where required (for example: GDPR typically 1 month with permitted extension; CCPA typically 45 days with permitted extension)
-- Frontend collection fields and backend validation contract align (no unexpected extra data accepted)
-- Cross-border data transfer implications are identified for relevant vendors/services and escalated when transfer mechanism evidence is unclear
-- Sensitive fields use safe defaults for storage/autofill behavior appropriate to risk
-
-### Tracking and Consent
-- Non-essential tracking is gated behind consent where required
-- Consent state is honored across page loads and third-party tags
-- "Reject" and "Manage preferences" paths are as visible as "Accept"
-- Consent withdrawal/revocation is as easy and discoverable as consent grant where required
-- Consent actions are auditable (timestamp, policy/version context, and scope) where required
-- No non-essential cookies/tags/pixels fire before valid consent in opt-in regions
-- Consent categories are explicit (for example: necessary, functional, analytics, marketing)
-- Consent UI has no pre-checked boxes and no coercive "cookie wall" patterns where prohibited
-- Region-based consent behavior is enforced server/edge-side, not only via frontend display toggles
-- Push notification permissions are requested with clear purpose/context and respect prior denial/dismissal patterns
-
-### Claims and Marketing Content
-- Product/marketing claims are specific and supportable (avoid unverifiable absolutes)
-- Pricing, trial, and renewal details are clear in the same flow where commitment happens
-- Required disclosures are placed near relevant calls to action
-- Subscription cancellation path is at least as discoverable and easy as sign-up
-- Cancellation is available through the same primary medium as sign-up where required (for example, online sign-up implies online cancellation path)
-- Negative option billing/auto-renew enrollment uses explicit affirmative consent separate from bundled legal text where required
-- Free-trial to paid conversion terms are explicit before commitment
-- Material ToS/pricing/renewal-term changes trigger proactive user notice and re-consent/acknowledgment checks where required
-
-### Email/SMS Capture and Messaging
-- Email capture flow includes clear sender identity and functional unsubscribe path
-- SMS capture includes explicit consent language, program identity, and opt-out instructions where required
-- Messaging consent scope matches actual campaign behavior (no silent purpose expansion)
-
-### Third-Party Scripts and Vendors
-- New third-party scripts/SDKs/pixels/iframes are inventoried in the change review
-- Data-sharing impact is assessed as a potential new vendor/subprocessor risk
-- Vendor data flows are reflected in disclosures/policies where required
-- Non-essential third-party scripts are technically blocked until consent state permits execution
-
-### User Rights and Account Controls
-- Account creation, sign-in, and recovery flows avoid dark patterns (confirm-shaming, roach motel, hidden costs, forced continuity)
-- Account deletion/deactivation flow is discoverable and not materially harder than sign-up
-- Contact and complaint/reporting channels are visible for regulated or trust-sensitive features
-- If automated decisioning materially affects users (for example eligibility, ranking, moderation outcomes), disclosure and human-review escalation path are present where required
-- For personalization/targeting profiles, objection and opt-out controls are discoverable and honored where required
-
-### Age-Restricted Experiences
-- Age gate behavior is neutral and non-deceptive
-- Child-directed and "actual knowledge of minor user" risk cases are flagged for legal review before release
-- Data handling and consent flows for minors are not inferred; require explicit policy/legal alignment
-
-### Accessibility and Fairness
-- Compliance-related controls are usable with keyboard and assistive technologies
-- Critical disclosures are not conveyed by color alone
-- Consent and policy controls are understandable at normal reading level
-- For EU-market digital products, include European Accessibility Act (EAA) applicability check in addition to WCAG baseline validation
-
-### UGC and Platform Governance
-- If user-generated content is in scope, reporting, enforcement notice, and appeal pathways are defined where required
-- Recommender/ranking controls avoid manipulative defaults and are communicated in clear user-facing terms
-
-## Output Contract
-When this skill is applied, output should include:
-- Findings list with `risk_level` (`high`, `medium`, `low`)
-- Exact file/flow references
-- User-facing and regulatory impact
-- Recommended remediation or escalation target (legal/privacy/security/product)
-- Jurisdiction assumptions used for each finding
-- Verification evidence type (`code`, `config`, `network`, `ui-copy`, `flow-path`)
-- Explicit uncertainty notes when legal interpretation is required
-- For `high` and `medium` findings, add audit-style gap framing:
-  - `control_area`
-  - `current_state`
-  - `target_state`
-  - `remediation_steps`
-  - `estimated_effort`
-  - `evidence_needed`
-
-## Audit-Style Evidence Layer
-- Use audit-style gap framing when the feature touches consent logging, DSR flows, retention/deletion behavior, vendor/script controls, cancellation parity, or age-gating.
-- If multiple findings share the same root cause, group them into one remediation cluster and list shared evidence needed.
-- If evidence cannot be verified from code or config, mark it as `missing evidence` rather than assuming compliance.
-- When useful, load `<AI_DEV_SHOP_ROOT>/skills/web-compliance/references/audit-evidence.md` for gap templates and evidence-matrix structure.
-
-## Escalation Routing Heuristics
-- Route to `legal` for jurisdiction interpretation, cross-border transfer mechanism questions, ToS/pricing term changes, marketing claims substantiation, and minor/age-gating edge cases.
-- Route to `privacy` for consent model mismatches, DSR/portability flow gaps, profiling objection controls, retention/deletion mismatches, and disclosure scope misalignment.
-- Route to `security` for backend/edge enforcement failures (for example pre-consent tag firing), identity-verification weaknesses in DSR flows, and third-party data exfiltration risk.
-- Route to `product` for UX dark patterns, cancellation discoverability parity, disclosure placement/copy clarity, and funnel-level remediation sequencing.
-- If a finding spans multiple domains, assign primary owner by root cause and list secondary owners explicitly.
-
-## Guardrails
-- Do not present this skill as legal advice
-- Do not block release on low-confidence assumptions; escalate with explicit uncertainty
-- Prefer concrete evidence (copy text, UI path, config behavior) over generic warnings
-- Do not claim certification or framework readiness from website-surface checks alone

package/ui-ux-design/skills/web-compliance/references/audit-evidence.md

@@ -1,59 +0,0 @@
-# Audit Evidence
-
-Use this reference when `web-compliance` findings need stronger remediation framing or evidence collection structure.
-
-## When to Use
-
-- medium or high risk findings
-- consent and tracking controls
-- DSR/export/delete/account-control flows
-- subscription or cancellation parity
-- vendor/script introductions
-- age-gating and regulated onboarding flows
-
-## Gap Record Template
-
-For each medium/high finding, capture:
-
-- `control_area`: short label for the compliance concern
-- `current_state`: what the product does today
-- `target_state`: what must be true for launch
-- `remediation_steps`: concrete next actions
-- `estimated_effort`: small, medium, large or time estimate
-- `evidence_needed`: what must be shown to verify the fix
-
-Example:
-
-```yaml
-control_area: consent-logging
-current_state: Analytics consent banner is shown, but no evidence of consent timestamp or policy-version capture exists.
-target_state: Consent grant, rejection, and withdrawal are recorded with timestamp, policy version, and scope.
-remediation_steps:
-  - Add server-side consent event persistence
-  - Include policy/version identifier in stored consent records
-  - Add withdrawal path and verify revocation updates persisted state
-estimated_effort: medium
-evidence_needed:
-  - code path for persistence
-  - database schema or event payload
-  - UI flow showing withdrawal path
-  - test or network proof that records are written
-```
-
-## Evidence Matrix
-
-When multiple findings exist, summarize expected evidence with:
-
-| Control Area | Evidence Type | Source | Collection Method | Verification Step |
-|---|---|---|---|---|
-| Consent logging | `code`, `network`, `config` | backend endpoint + client flow | inspect code and capture browser network | verify grant/reject/withdraw all persist |
-| Pre-consent blocking | `network`, `config` | tag manager or edge config | browser/network trace before consent | confirm no non-essential tags fire |
-| Cancellation parity | `ui-copy`, `flow-path` | account settings flow | walkthrough + screenshots | compare sign-up vs cancel discoverability |
-
-## Evidence Rules
-
-- Prefer direct evidence over policy promises.
-- Mark missing proof as `missing evidence`.
-- Group related findings when one remediation fixes several symptoms.
-- Do not infer backend controls from frontend copy alone.
-- Do not mark a control complete unless the operating behavior can be shown.