novahiz 0.1.0 → 0.2.2

package/skills/novahiz-security/SKILL.md

@@ -0,0 +1,228 @@
+---
+name: novahiz-security
+description: |
+  novahiz-security : audit de sécurité complet avec OWASP Top 10, CWE Top 25, patterns
+  dangereux, injection, XSS, auth bypass. Use when reviewing code for security vulnerabilities,
+  hardening authentication, validating input handling, or generating security reports.
+license: MIT
+compatibility: opencode
+metadata:
+  author: Novahiz
+  organization: Novahiz
+  version: "2.0.0"
+---
+
+# novahiz-security
+
+Audit de sécurité en trois temps : scan des patterns dangereux, analyse OWASP et CWE, puis vérifications propres à chaque langage.
+
+## Matrice de détection
+
+### OWASP Top 10 (2021)
+
+| ID | Catégorie | Détection |
+|----|-----------|-----------|
+| A01 | Broken Access Control | RBAC, contrôle horizontal et vertical |
+| A02 | Cryptographic Failures | Algorithmes faibles, clés en dur |
+| A03 | Injection | SQL, NoSQL, OS, LDAP, XPath |
+| A04 | Insecure Design | Patterns architecturaux dangereux |
+| A05 | Security Misconfiguration | Defaults, headers, CORS |
+| A06 | Vulnerable Components | Dépendances obsolètes |
+| A07 | Auth Failures | Session fixation, brute force |
+| A08 | Data Integrity Failures | Deserialization non signée |
+| A09 | Logging Failures | Données sensibles dans les logs |
+| A10 | SSRF | Requêtes serveur sans validation |
+
+### CWE Top 25 (2024)
+
+| ID | Faiblesse | Signature de détection |
+|----|-----------|------------------------|
+| CWE-79 | XSS | `innerHTML`, `dangerouslySetInnerHTML`, `document.write` |
+| CWE-89 | SQL Injection | Concaténation SQL, format strings |
+| CWE-416 | Use After Free | Pointeurs, mémoire manuelle (C/C++) |
+| CWE-787 | Out-of-bounds Write | Débordement de buffer |
+| CWE-78 | Command Injection | `exec()`, `system()`, `os.popen()` |
+| CWE-190 | Integer Overflow | Arithmétique non vérifiée |
+| CWE-502 | Deserialization | `pickle.loads()`, `yaml.load()` |
+| CWE-200 | Info Exposure | Logs sensibles, stack traces |
+| CWE-287 | Auth Bypass | Session non vérifiée |
+| CWE-476 | NULL Pointer | Déréférencement sans garde |
+
+## Patterns par langage
+
+### JavaScript et TypeScript
+
+```javascript
+// Command injection
+exec(`rm -rf ${userInput}`)
+child_process.execSync(userCommand)
+
+// Code injection
+new Function(userInput)()
+eval(userInput)
+
+// XSS
+element.innerHTML = userInput
+document.write(userInput)
+element.outerHTML = userInput
+
+// Prototype pollution
+Object.assign(target, userInput)
+_.merge(target, userInput)
+```
+
+### Python
+
+```python
+# Command injection
+os.system(f"ping {host}")
+subprocess.call(f"ls {path}", shell=True)
+os.popen(userCommand)
+
+# Deserialization
+pickle.loads(data)
+yaml.load(data)  # sans Loader=SafeLoader
+eval(userInput)
+exec(userInput)
+
+# SQL injection
+cursor.execute(f"SELECT * FROM users WHERE id={user_id}")
+cursor.execute("SELECT * FROM users WHERE id=%s" % user_id)
+
+# Path traversal
+open(f"/data/{filename}")
+```
+
+### Go
+
+```go
+// Command injection
+exec.Command("sh", "-c", userInput)
+os/exec.Command(userCommand)
+
+// SQL injection
+db.Query("SELECT * FROM users WHERE id=" + userId)
+
+// Path traversal
+os.Open("/data/" + filename)
+```
+
+### Rust
+
+```rust
+// Command injection
+Command::new("sh").arg("-c").arg(&user_input)
+
+// unwrap sans contexte : panic possible
+let value = risky_operation().unwrap();
+```
+
+### Java
+
+```java
+// SQL injection
+Statement stmt = conn.createStatement();
+stmt.executeQuery("SELECT * FROM users WHERE id=" + userId);
+
+// Deserialization
+ObjectInputStream ois = new ObjectInputStream(input);
+Object obj = ois.readObject();
+
+// Path traversal
+new File("/data/" + filename)
+```
+
+## Checklist
+
+### Authentification
+
+- [ ] Aucun mot de passe en dur
+- [ ] Hash bcrypt ou argon2, jamais MD5 ni SHA1
+- [ ] Rate limiting sur login
+- [ ] Lockout après échecs répétés
+- [ ] Timeout de session configuré
+- [ ] MFA disponible
+
+### Autorisation
+
+- [ ] RBAC vérifié sur chaque endpoint
+- [ ] Propriétaire de la ressource validé
+- [ ] Pas d'IDOR
+- [ ] Validation côté serveur uniquement
+
+### Input validation
+
+- [ ] Validation de schéma (Zod, Joi, Pydantic)
+- [ ] Sanitization HTML si le contenu est rendu
+- [ ] Limites de taille
+- [ ] Whitelist plutôt que blacklist
+
+### Données sensibles
+
+- [ ] Secrets en variables d'environnement
+- [ ] Chiffrement au repos
+- [ ] TLS en transit
+- [ ] Aucune PII dans les logs
+
+### Configuration
+
+- [ ] CSP, HSTS, X-Frame-Options
+- [ ] CORS restrictif
+- [ ] Debug désactivé en production
+- [ ] Erreurs génériques sans stack trace
+
+## Matrice de risque
+
+| Risque | Impact | Exploitabilité | Score |
+|--------|--------|----------------|-------|
+| SQL Injection | Critique | Facile | 9.8 |
+| Command Injection | Critique | Moyen | 9.0 |
+| Auth Bypass | Critique | Moyen | 8.5 |
+| XSS stocké | Élevé | Facile | 8.0 |
+| Deserialization | Critique | Difficile | 7.5 |
+| Path Traversal | Élevé | Facile | 7.0 |
+| Information Disclosure | Moyen | Facile | 5.0 |
+
+## Workflow d'audit
+
+### 1. Scan
+
+```bash
+# Secrets
+grep -rn "(password|secret|api_key|token)\s*=\s*['\"]" --include="*.{ts,js,py,go,rs,java}"
+
+# Injection
+grep -rn "(exec|system|popen|shell_exec)\s*\(" --include="*.{ts,js,py,go,rs,java}"
+
+# XSS
+grep -rn "(innerHTML|dangerouslySetInnerHTML|document\.write)" --include="*.{ts,tsx,js,jsx}"
+```
+
+### 2. Analyse contextuelle
+
+Pour chaque finding : identifier la source, tracer le flux jusqu'au puits (DB, HTML, shell), vérifier validation et sanitization, puis juger l'exploitabilité.
+
+### 3. Rapport
+
+```markdown
+# Security audit report
+
+## Summary
+- Critical: 2
+- High: 3
+- Medium: 5
+- Low: 8
+
+## Critical findings
+
+### SEC-001: SQL injection in user.ts:42
+- **CWE:** CWE-89
+- **OWASP:** A03:2021
+- **Evidence:** `cursor.execute(f"SELECT * FROM users WHERE id={userId}")`
+- **Fix:** requête paramétrée
+  `cursor.execute("SELECT * FROM users WHERE id=%s", (userId,))`
+```
+
+## Note sur les fichiers
+
+Cette skill n'a pas de dossier `references/`. Les matrices et checklists vivent dans ce fichier. Ne pas référencer un chemin absent du disque.

package/skills/novahiz-supabase/SKILL.md

@@ -0,0 +1,177 @@
+---
+name: novahiz-supabase
+description: |
+  novahiz-supabase for ANY task involving Supabase. Triggers: Database, Auth, Edge
+  Functions, Realtime, Storage, Vectors, Cron, Queues; client libraries and SSR integrations
+  (supabase-js, @supabase/ssr) in Next.js, React, SvelteKit, Astro, Remix; auth issues
+  (login, logout, sessions, JWT, cookies, getSession, getUser, getClaims, RLS); Supabase CLI
+  or MCP server; schema changes, migrations, declarative schemas, security audits, Postgres
+  extensions (pg_graphql, pg_cron, pg_vector); debugging on Supabase projects.
+license: Apache-2.0
+compatibility: opencode
+metadata:
+  author: Novahiz
+  organization: Novahiz
+  version: "2.0.0"
+---
+
+# novahiz-supabase
+
+Production Supabase work: Auth, RLS, Edge Functions, Storage, and the operations around them.
+
+## Core principles
+
+### Verify against the changelog before you implement
+
+Supabase moves quickly. Signatures, `config.toml` keys, and API conventions change between releases. Fetch `https://supabase.com/changelog.md`, scan for `breaking-change` tags that touch your task, follow the linked pages that apply, then look up the topic in the docs below. Training data is not a substitute.
+
+### Prove the fix
+
+After any change, run a query that shows it works. An unverified fix is unfinished work.
+
+### Stop after two or three failures
+
+If an approach keeps failing, change method instead of looping. Re-read the error, check the docs, look at logs when they exist.
+
+### Authorization lives in the database
+
+Supabase is raw Postgres underneath. Put the rules in RLS rather than scattering them across clients.
+
+## Security checklist
+
+### Auth and sessions
+
+1. Never authorize from `user_metadata`. In Supabase, `raw_user_meta_data` is user-editable and surfaces in `auth.jwt()`, so it is unsafe for RLS or any other decision. Put authorization data in `app_metadata` / `raw_app_meta_data`.
+2. Deleting a user does not kill live access tokens. Sign out or revoke sessions first, keep access token expiry short on sensitive apps, and on critical paths check `session_id` against `auth.sessions`.
+3. Claims from `app_metadata` or `auth.jwt()` stay stale until the token refreshes. Plan for that lag.
+4. Require MFA (AAL2) for high-risk work with a restrictive policy:
+
+```sql
+create policy "mfa_required"
+on public.sensitive_table
+as restrictive
+to authenticated
+using ((select auth.jwt()->>'aal') = 'aal2');
+```
+
+### Keys and clients
+
+Never ship the `service_role` key or any secret to a public client. Prefer publishable keys on the frontend. In Next.js, every `NEXT_PUBLIC_` variable reaches the browser.
+
+### RLS, views, and privileged functions
+
+1. Views bypass RLS by default. On Postgres 15 and up, use `CREATE VIEW ... WITH (security_invoker = true)`. On older versions, revoke from `anon` and `authenticated`, or park the view in an unexposed schema.
+2. UPDATE needs a SELECT policy. Without it, updates silently match zero rows: no error, no change.
+3. `auth.role()` is deprecated. Name the target role with `TO authenticated` or `TO anon` instead.
+4. `TO authenticated` alone is authentication without authorization (BOLA / IDOR). Pair it with an ownership predicate in `USING`:
+
+```sql
+create policy "example" on table_name for select
+to authenticated
+using ( (select auth.uid()) = user_id );
+```
+
+5. UPDATE policies need both `USING` and `WITH CHECK`. Without the check, a user can hand a row to someone else:
+
+```sql
+create policy "example" on table_name for update
+to authenticated
+using ( (select auth.uid()) = user_id )
+with check ( (select auth.uid()) = user_id );
+```
+
+6. `SECURITY DEFINER` runs with the creator's privileges, usually a `bypassrls` role such as `postgres`. Adding it to silence a permission error removes access control without fixing the cause. Prefer `SECURITY INVOKER`.
+7. `SECURITY DEFINER` functions in `public` are callable by everyone. Postgres grants `EXECUTE` to `PUBLIC` by default, so any such function in `public` is a public endpoint for `anon` and `authenticated`. When you truly need it, keep the function in a non-exposed schema, check `auth.uid()` in the body, and run `supabase db advisors` afterward.
+
+### Storage
+
+An upsert needs INSERT, SELECT, and UPDATE. Granting only INSERT lets new uploads land while replacements fail in silence.
+
+### Dependencies
+
+Pin versions and commit lockfiles for `supabase-js`, `@supabase/ssr`, `supabase-py`, and friends.
+
+## Authentication
+
+### JWT signing keys
+
+Move off the shared HS256 secret onto an asymmetric key such as ES256. The public key is published through JWKS, so `getClaims()` verifies locally and the round trip disappears.
+
+Migration with zero downtime:
+
+1. Create a standby key.
+2. Rotate so the asymmetric key becomes current.
+3. Wait for access tokens to expire, plus a buffer.
+4. Revoke the legacy secret.
+
+### Sessions
+
+| Item | Default | Notes |
+|------|---------|-------|
+| Access token expiry | 1 hour | Keep the default for most apps |
+| Refresh token | Never expires, single use | Each use issues a new pair |
+| Refresh reuse interval | 10 seconds | Do not change this value |
+
+### Server-side authorization
+
+| Method | What it does | When to use |
+|--------|--------------|-------------|
+| `getClaims()` | Verifies locally via JWKS with asymmetric keys | First choice on the server |
+| `getUser()` | Asks the Auth server | When you need the freshest user record |
+| `getSession()` | Reads client storage without revalidation | Never for server-side authorization |
+
+## RLS performance
+
+| Optimization | How | Typical gain |
+|--------------|-----|--------------|
+| Index the policy columns | plain index | up to ~99.94% |
+| Wrap auth functions | `auth.uid()` becomes `(select auth.uid())` | ~94.97 to 99.99% |
+| Explicit client filter | `.eq('user_id', userId)` | ~94.74% |
+| Target role with `TO` | skip irrelevant roles early | ~99.78% |
+| `security definer` function | move the authorization join inside | ~99.78% |
+
+Wrapping auth functions in `(select ...)` caches them in the initPlan, so they evaluate once per statement instead of per row. That is the cheapest single win when writing RLS.
+
+## Edge Functions
+
+### Auth modes
+
+| Mode | Accepts |
+|------|---------|
+| `'user'` | Valid user JWT on `Authorization` |
+| `'secret'` | Secret key on `apikey` |
+| `'publishable'` | Publishable key on `apikey` |
+| `'none'` | Any caller, for signed webhooks |
+
+### Practices
+
+1. Forward the caller's JWT and let RLS do the work. Reserve `service_role` for private workers and trusted webhooks.
+2. Keep functions light. The budget is 2 seconds of CPU and 256 MB of memory. Heavy computation does not belong here.
+3. Use strict CORS. Wildcards and reflected origins are out.
+4. Rate limit. Unchecked requests burn resources.
+
+## CLI
+
+Discover commands with `--help`. Never guess; the layout shifts between versions.
+
+```bash
+supabase --help
+supabase <group> --help
+supabase <group> <command> --help
+```
+
+Gotchas: `supabase db query` needs CLI v2.79.0 or newer, `supabase db advisors` needs v2.81.3 or newer, and hand-authored migrations in imperative projects start with `supabase migration new <name>`.
+
+## Documentation access
+
+Priority order before implementing anything Supabase:
+
+1. MCP `search_docs` for snippets.
+2. Fetch a docs page as markdown by appending `.md` to the URL path.
+3. Web search when you do not know which page to open.
+
+## References
+
+- https://supabase.com/docs
+- https://supabase.com/changelog.md
+- https://supabase.com/docs/guides/security/product-security.md

package/skills/novahiz-task/SKILL.md

@@ -1,26 +1,30 @@
 ---
 name: novahiz-task
 description: |
-  Step 3 of the Novahiz pipeline: convert a plan into atomic, ordered, verifiable tasks.
-  Each task carries an objective, testable acceptance criteria, proof, dependencies,
-  owned files, and size (XS to XL).
-  Use when a plan must become an ordered task list, or when work must be split across
-  sessions or agents.
+  novahiz-task, step 3 of the Novahiz pipeline: cut a plan into atomic, ordered,
+  verifiable tasks. Every task carries an objective, testable acceptance criteria, proof,
+  dependencies, the files it owns, and a size from XS to XL.
+  Use when a plan has to become an ordered list, or when the work spans several sessions
+  or several agents.
   Triggers on: "break down", task list, todo, subtasks, acceptance criteria,
   prioritization, "what do I start with".
-license: MIT
+license: Apache-2.0
 compatibility: opencode
+metadata:
+  author: Novahiz
+  organization: Novahiz
+  version: "2.0.0"
 ---
 
 # novahiz-task: split into verifiable tasks
 
-**Step 3 of 6** in the pipeline. The plan says where we go; this step says by what steps, in what order, and how each step closes.
+**Step 3 of 6** in the pipeline. The plan sets the destination. This step sets the stages, their order, and the way each one shuts.
 
-Previous step: `novahiz-clarify`. Next step: `novahiz-analyse`.
+Previous: `novahiz-clarify`. Next: `novahiz-analyse`.
 
 ## Task contract
 
-All tasks take the same shape. A task without acceptance criteria and proof remains an intention.
+Every task takes the same frame. Without acceptance criteria and proof, it remains a wish.
 
 ```markdown
 ## Task N: <short title, imperative mood>
@@ -35,15 +39,15 @@ Files involved: path/a, path/b
 Size: XS | S | M | L | XL
 ```
 
-## The ledger rejects a `verify` step without proof
+## The ledger refuses a `verify` step that carries no proof
 
-`novahiz_task` enforces this rule: a step of kind `verify` cannot close without `proof`. Proof is decided at plan time, not at doubt time.
+`novahiz_task` holds the line: a step of kind `verify` cannot close without `proof`. You fix the proof when you write the plan, not when doubt shows up.
 
 | Action | Usage |
 |---|---|
 | `plan` | deposit the full list at once |
 | `todo` | add a step (`kind`: read, edit, verify, delegate) |
-| `start` / `done` | open, close (`done` requires `proof` on a verify step) |
+| `start` / `done` | open and close (`done` needs `proof` on a verify step) |
 | `block` | block, with `reason` |
 | `review` | revise the plan between steps |
 | `amend` / `insert` / `drop` / `reorder` | fix the list without rewriting it |
@@ -59,14 +63,14 @@ Size: XS | S | M | L | XL
 | L | 5 to 8 | feature touching multiple components |
 | XL | 8 and above | must be split, no exception |
 
-Split again if the work exceeds one focused session, if criteria do not fit in three bullets, if two independent subsystems are touched, or if the title contains "and". That "and" signals two tasks glued together.
+Split again when the work runs past one focused sitting, when the criteria overflow three bullets, when two independent subsystems are in play, or when the title contains "and". That word usually means two tasks glued together.
 
 ## Order
 
-- Dependencies first.
-- Each task leaves the system functional.
-- Risky tasks go early: failing fast costs less.
-- One checkpoint every two or three steps. It serves to prove, then to decide whether to continue, fix, or abort.
+- Dependencies come first.
+- Every task leaves the system in a working state.
+- Dangerous tasks go early: failing sooner costs less.
+- One checkpoint every two or three steps. Its job is to prove progress, then to decide between continuing, fixing, or stopping.
 
 ## Categories that require this step
 
@@ -75,31 +79,31 @@ Split again if the work exceeds one focused session, if criteria do not fit in t
 ## Discipline
 
 - One `in_progress` step at a time.
-- Real-time updates, no batch completion.
-- `completed` only after verification, never based on intention.
-- A blocked step stays `in_progress` and a follow-up task describes the blockage.
-- Reuse the user's vocabulary exactly: commands, options, arguments, order.
+- Update as things change; no batch closings at the end.
+- `completed` follows verification and nothing else.
+- A blocked step stays `in_progress`, and a follow-up task records the blockage.
+- Keep the user's own words: commands, options, arguments, order.
 
 ## Plan conflict
 
-Before writing, check whether an open plan exists. Same work: update in place. Different work: stop, and present the decision through the `question` tool (resume, replace, create alongside), never in prose. Never delete, overwrite, or rename an open plan on your own initiative.
+Before you write, check for an open plan. Same work: revise it where it stands. Different work: stop, then offer the choice through the `question` tool (resume, replace, or open alongside), in the interface and never in prose. An open plan never gets deleted, overwritten, or renamed on your own initiative.
 
 ## Rationalizations
 
 | Rationalization | Reality |
 |---|---|
-| "I'll see as I go" | that is how you get entanglement and rework |
-| "the tasks are obvious" | write them: writing reveals dependencies and forgotten edge cases |
+| "I'll see as I go" | you get tangled work and rework |
+| "the tasks are obvious" | writing them exposes dependencies and forgotten edge cases |
 | "planning is wasted time" | planning is part of the work |
-| "I'll keep it all in context" | the context window is finite; a written plan survives sessions |
-| "the old plan is stale" | unchecked tasks carry state that exists nowhere else |
+| "I'll keep it all in context" | context windows are finite; a written plan outlives the session |
+| "the old plan is stale" | unchecked tasks hold state that exists nowhere else |
 
 ## Red flags
 
-- Implementation started without a task list
-- Task "implement the feature" without acceptance criteria
-- Plan without a verification step
-- All tasks in XL
+- Implementation started before a task list exists
+- A task like "implement the feature" with no acceptance criteria
+- A plan without a verification step
+- Every task sitting at XL
 - No checkpoints
 - Dependency order ignored
 - Plan overwritten without confirmation

package/skills/novahiz-wcag-audit/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: novahiz-wcag-audit
+description: |
+  novahiz-wcag-audit runs a WCAG 2.2 Level A/AA accessibility audit across source code,
+  live pages, and structured reports. Use when auditing web accessibility, checking WCAG
+  compliance, fixing contrast, keyboard, ARIA, or screen-reader issues, or producing an
+  accessibility audit report.
+license: Apache-2.0
+compatibility: opencode
+metadata:
+  author: Novahiz
+  organization: Novahiz
+  version: "2.0.0"
+---
+
+# novahiz-wcag-audit
+
+End-to-end WCAG 2.2 A/AA audit: scan the source, check the live page, fix what fails, then produce a cited report.
+
+## Pick a path
+
+| Input | Path |
+|-------|------|
+| Files only, no running app | Scan, Fix, Verify in code |
+| URL or running app | Scan, Live audit, Fix, Re-verify |
+| User asks for a report | Run both paths, then Report |
+
+## Workflow
+
+**1. Scope.** Confirm the target (files, folder, URL), the claim level (AA by default), and what is out of scope.
+
+**2. Scan.** Review the source against [references/wcag22-aa.md](references/wcag22-aa.md) in this order: structure and semantics, then keyboard and focus, then forms and errors, then images, media, and ARIA, then color and contrast with `scripts/contrast.mjs`. Record each finding with SC id, severity, `file:line`, evidence, and a proposed fix.
+
+**3. Live audit** when a page is available. Playwright MCP only. Never Chrome or Chromium; the Edge profile rules apply.
+
+- Keyboard pass with Tab and Shift+Tab: focus visibility and traps.
+- Landmarks and heading order from the accessibility tree or snapshot.
+- Contrast from computed styles fed to the contrast script, plus reflow at 320 CSS px and 200% text zoom.
+- Optional axe-core only if the page already loads it. No heavy npm install for a one-off audit.
+
+Automated tools catch a fraction of the problems. Keyboard and screen-reader checks are mandatory before claiming AA.
+
+**4. Fix.** Prefer semantic HTML over ARIA. Work by severity: blockers first, then significant barriers, then friction. Keep every change minimal and reversible.
+
+**5. Verify.** Re-run the contrast script on every color pair you touched. Re-check the keyboard path on changed components. Flip each SC line to pass only with evidence attached.
+
+**6. Report.** Use `scripts/report.mjs` or [references/report-template.md](references/report-template.md). The minimum content is scope and claim level, a per-SC PASS/FAIL table with evidence, findings with severity and before/after, the manual tests you ran, and residual risks.
+
+## Scripts
+
+```bash
+node scripts/contrast.mjs "#767676" "#ffffff"
+node scripts/contrast.mjs "#767676" "#ffffff" --level large
+node scripts/contrast.mjs "#767676" "#ffffff" --level aaa --text normal
+node scripts/report.mjs findings.json > report.md
+```
+
+Contrast exits 0 on pass, 1 on fail, 2 on usage or parse error. Findings JSON shape: `{ "sc", "status", "severity", "location", "evidence", "fix" }`. A filled sample sits at [references/findings.example.json](references/findings.example.json).
+
+## Severity
+
+| Severity | Meaning | Action |
+|----------|---------|--------|
+| critical | Blocks access: no keyboard, no alt, no accessible name | Before release |
+| major | Significant barrier: contrast, focus, labels | Current sprint |
+| minor | Friction: redundant ARIA, heading gaps | Backlog with a written justification |
+
+## Red flags
+
+- Claiming AA from automated scans alone.
+- `aria-label` that does not match the visible label (2.5.3).
+- `tabindex` greater than 0.
+- Color as the only signal (1.4.1).
+- Focus outline removed with nothing in its place.
+- Decorative `alt` left on informative images.
+
+## Deep reference
+
+All 55 Level A and AA criteria: [references/wcag22-aa.md](references/wcag22-aa.md).

package/skills/novahiz-wcag-audit/references/findings.example.json

@@ -0,0 +1,36 @@
+{
+  "target": "https://example.com/app",
+  "level": "AA",
+  "findings": [
+    {
+      "sc": "1.1.1",
+      "name": "Non-text Content",
+      "level": "A",
+      "status": "FAIL",
+      "severity": "critical",
+      "location": "src/components/Card.tsx:42",
+      "evidence": "<img src={product.image} /> with no alt",
+      "fix": "alt={product.name} or alt=\"\" if decorative"
+    },
+    {
+      "sc": "1.4.3",
+      "name": "Contrast (Minimum)",
+      "level": "AA",
+      "status": "FAIL",
+      "severity": "major",
+      "location": "src/styles/main.css:128",
+      "evidence": "#999999 on #ffffff = 2.85:1 (need 4.5:1)",
+      "fix": "Use #767676 or darker"
+    },
+    {
+      "sc": "2.4.7",
+      "name": "Focus Visible",
+      "level": "AA",
+      "status": "PASS",
+      "severity": "major",
+      "location": "src/styles/focus.css:1",
+      "evidence": "outline: 2px solid #06d6a0 on :focus-visible",
+      "fix": ""
+    }
+  ]
+}