qa-engineer 0.9.1 → 0.9.2

package/skills/qa-flaky/references/deterministic-tooling.md

@@ -61,6 +61,8 @@ Framework-agnostic parsing, redaction, and validation.
 | `validate` | `python3 <skill-dir>/scripts/qa_tool.py analysis validate <instance.json> <schema.json>` | `{valid: bool, errors: [...]}`; exit 1 when invalid |
 | `classify` | `python3 <skill-dir>/scripts/qa_tool.py analysis classify "<error message>" [--http-status N]` | `{classification, confidence, reason}` from the shared taxonomy |
 | `context` | `python3 <skill-dir>/scripts/qa_tool.py analysis context [--root DIR] [--path .qa/context.md]` | The parsed, schema-validated project context as JSON |
+| `report-html` | `python3 <skill-dir>/scripts/qa_tool.py analysis report-html <result.json> [--out report.html]` | The result rendered as one self-contained HTML report — every required field, footer included. Run it instead of writing HTML |
+| `branding` | `python3 <skill-dir>/scripts/qa_tool.py analysis branding --format markdown\|html\|text` | The exact attribution footer bytes for a **rendered** report (never for a JSON artifact) |
 
 ## 3. Diagnostic engine — `qa_tool.py diagnostics`
 

package/skills/qa-flaky/references/evidence-and-reporting.md

@@ -27,17 +27,42 @@ Any skill that reaches a conclusion — a detected fact, a chosen strategy, a cl
 | Confidence | Calibrated per rule 4; omitted rather than invented when the skill did not weigh alternatives |
 | Recommendations | The next action, named concretely — often the next command and the artifact to feed it |
 
+## Rendering the HTML report
+
+**Never type the HTML.** When a skill's result conforms to a contract the renderer
+supports, the HTML report is generated from that artifact:
+
+```bash
+python3 <SKILL_DIR>/scripts/qa_tool.py analysis report-html <result.json> --out <report.html>
+```
+
+The reason is not tidiness. A hand-written report is a second, lossy copy of the
+artifact, and it loses exactly what the reader needs: the first live `/qa-explore`
+run wrote findings whose `actual`, `expected`, and `fixDirection` were all required,
+all present in the JSON, and all absent from the page — collapsed into one sentence
+that left the reader to guess what correct behaviour would have been. The renderer
+cannot make that mistake, because the fields are in its template.
+
+What the renderer guarantees per finding: severity, the defect, **what happens
+now**, **what should happen instead**, how to reproduce it, the fix direction, and
+every evidence entry — plus the attribution footer, in one self-contained file with
+no external assets.
+
+Run `qa_tool.py analysis report-html --help` for the supported contracts. For an
+artifact it does not support, write the HTML by hand from the contract's fields —
+and render **every** field a reader needs, in that order.
+
 ## Attribution on rendered reports
 
 A report a person opens carries a product attribution footer, the way a Lighthouse
 or Allure report does. It is rendered, never typed: the exact bytes come from the
 bundled analysis toolkit, so every report is identical and a wording change is a
-one-file edit.
+one-file edit. `report-html` already embeds it; for any other rendering, ask for it:
 
 ```bash
-PYTHONPATH="$QA_LIB" python3 -m qa_analysis.cli branding --format html
-PYTHONPATH="$QA_LIB" python3 -m qa_analysis.cli branding --format markdown
-PYTHONPATH="$QA_LIB" python3 -m qa_analysis.cli branding --format text
+python3 <SKILL_DIR>/scripts/qa_tool.py analysis branding --format markdown
+python3 <SKILL_DIR>/scripts/qa_tool.py analysis branding --format html
+python3 <SKILL_DIR>/scripts/qa_tool.py analysis branding --format text
 ```
 
 Append the output as the last element of the rendered document: `html` inside

package/skills/qa-generate/references/evidence-and-reporting.md

@@ -27,17 +27,42 @@ Any skill that reaches a conclusion — a detected fact, a chosen strategy, a cl
 | Confidence | Calibrated per rule 4; omitted rather than invented when the skill did not weigh alternatives |
 | Recommendations | The next action, named concretely — often the next command and the artifact to feed it |
 
+## Rendering the HTML report
+
+**Never type the HTML.** When a skill's result conforms to a contract the renderer
+supports, the HTML report is generated from that artifact:
+
+```bash
+python3 <SKILL_DIR>/scripts/qa_tool.py analysis report-html <result.json> --out <report.html>
+```
+
+The reason is not tidiness. A hand-written report is a second, lossy copy of the
+artifact, and it loses exactly what the reader needs: the first live `/qa-explore`
+run wrote findings whose `actual`, `expected`, and `fixDirection` were all required,
+all present in the JSON, and all absent from the page — collapsed into one sentence
+that left the reader to guess what correct behaviour would have been. The renderer
+cannot make that mistake, because the fields are in its template.
+
+What the renderer guarantees per finding: severity, the defect, **what happens
+now**, **what should happen instead**, how to reproduce it, the fix direction, and
+every evidence entry — plus the attribution footer, in one self-contained file with
+no external assets.
+
+Run `qa_tool.py analysis report-html --help` for the supported contracts. For an
+artifact it does not support, write the HTML by hand from the contract's fields —
+and render **every** field a reader needs, in that order.
+
 ## Attribution on rendered reports
 
 A report a person opens carries a product attribution footer, the way a Lighthouse
 or Allure report does. It is rendered, never typed: the exact bytes come from the
 bundled analysis toolkit, so every report is identical and a wording change is a
-one-file edit.
+one-file edit. `report-html` already embeds it; for any other rendering, ask for it:
 
 ```bash
-PYTHONPATH="$QA_LIB" python3 -m qa_analysis.cli branding --format html
-PYTHONPATH="$QA_LIB" python3 -m qa_analysis.cli branding --format markdown
-PYTHONPATH="$QA_LIB" python3 -m qa_analysis.cli branding --format text
+python3 <SKILL_DIR>/scripts/qa_tool.py analysis branding --format markdown
+python3 <SKILL_DIR>/scripts/qa_tool.py analysis branding --format html
+python3 <SKILL_DIR>/scripts/qa_tool.py analysis branding --format text
 ```
 
 Append the output as the last element of the rendered document: `html` inside

package/skills/qa-init/references/deterministic-tooling.md

@@ -61,6 +61,8 @@ Framework-agnostic parsing, redaction, and validation.
 | `validate` | `python3 <skill-dir>/scripts/qa_tool.py analysis validate <instance.json> <schema.json>` | `{valid: bool, errors: [...]}`; exit 1 when invalid |
 | `classify` | `python3 <skill-dir>/scripts/qa_tool.py analysis classify "<error message>" [--http-status N]` | `{classification, confidence, reason}` from the shared taxonomy |
 | `context` | `python3 <skill-dir>/scripts/qa_tool.py analysis context [--root DIR] [--path .qa/context.md]` | The parsed, schema-validated project context as JSON |
+| `report-html` | `python3 <skill-dir>/scripts/qa_tool.py analysis report-html <result.json> [--out report.html]` | The result rendered as one self-contained HTML report — every required field, footer included. Run it instead of writing HTML |
+| `branding` | `python3 <skill-dir>/scripts/qa_tool.py analysis branding --format markdown\|html\|text` | The exact attribution footer bytes for a **rendered** report (never for a JSON artifact) |
 
 ## 3. Diagnostic engine — `qa_tool.py diagnostics`
 

package/skills/qa-init/references/evidence-and-reporting.md

@@ -27,17 +27,42 @@ Any skill that reaches a conclusion — a detected fact, a chosen strategy, a cl
 | Confidence | Calibrated per rule 4; omitted rather than invented when the skill did not weigh alternatives |
 | Recommendations | The next action, named concretely — often the next command and the artifact to feed it |
 
+## Rendering the HTML report
+
+**Never type the HTML.** When a skill's result conforms to a contract the renderer
+supports, the HTML report is generated from that artifact:
+
+```bash
+python3 <SKILL_DIR>/scripts/qa_tool.py analysis report-html <result.json> --out <report.html>
+```
+
+The reason is not tidiness. A hand-written report is a second, lossy copy of the
+artifact, and it loses exactly what the reader needs: the first live `/qa-explore`
+run wrote findings whose `actual`, `expected`, and `fixDirection` were all required,
+all present in the JSON, and all absent from the page — collapsed into one sentence
+that left the reader to guess what correct behaviour would have been. The renderer
+cannot make that mistake, because the fields are in its template.
+
+What the renderer guarantees per finding: severity, the defect, **what happens
+now**, **what should happen instead**, how to reproduce it, the fix direction, and
+every evidence entry — plus the attribution footer, in one self-contained file with
+no external assets.
+
+Run `qa_tool.py analysis report-html --help` for the supported contracts. For an
+artifact it does not support, write the HTML by hand from the contract's fields —
+and render **every** field a reader needs, in that order.
+
 ## Attribution on rendered reports
 
 A report a person opens carries a product attribution footer, the way a Lighthouse
 or Allure report does. It is rendered, never typed: the exact bytes come from the
 bundled analysis toolkit, so every report is identical and a wording change is a
-one-file edit.
+one-file edit. `report-html` already embeds it; for any other rendering, ask for it:
 
 ```bash
-PYTHONPATH="$QA_LIB" python3 -m qa_analysis.cli branding --format html
-PYTHONPATH="$QA_LIB" python3 -m qa_analysis.cli branding --format markdown
-PYTHONPATH="$QA_LIB" python3 -m qa_analysis.cli branding --format text
+python3 <SKILL_DIR>/scripts/qa_tool.py analysis branding --format markdown
+python3 <SKILL_DIR>/scripts/qa_tool.py analysis branding --format html
+python3 <SKILL_DIR>/scripts/qa_tool.py analysis branding --format text
 ```
 
 Append the output as the last element of the rendered document: `html` inside

package/skills/qa-report/SKILL.md

@@ -41,7 +41,7 @@ Do not investigate failures here (that is `/qa-debug`) or plan repairs (`/qa-fix
 2. **Aggregate deterministically.** Run the engine's summarize step (see Tooling) to compute the test totals, the by-classification breakdown, the ranked findings and recommendations, and the release-readiness verdict.
 3. **Frame for audiences.** Write the executive summary (shippability in a paragraph and a verdict) and the engineering summary (what broke, why, who owns it, in priority order) from the same aggregated data.
 4. **Detail.** Fill the test, failure, coverage, and risk sections; mark coverage unavailable rather than inventing it when there is no coverage data.
-5. **Render.** Produce the report in Markdown, an HTML-ready structure, and the JSON result — the same content in three forms. Append the rendered attribution footer (see Tooling) to the Markdown and HTML renderings only; the JSON result is an interface and carries no footer.
+5. **Render.** Write the JSON result first and validate it; the Markdown and HTML are renderings of it, not parallel drafts. Render the HTML with the report renderer (see Tooling) rather than typing it. Append the rendered attribution footer to the Markdown; the renderer embeds it in the HTML, and the JSON result is an interface and carries no footer.
 6. **Report.** Emit the report result and present the Markdown.
 
 ## Guardrails
@@ -61,7 +61,8 @@ Invoke the bundled engine through its launcher, as documented in [references/det
 | Report aggregator | `python3 <SKILL_DIR>/scripts/qa_tool.py diagnostics summarize --execution-result <path> --diagnosis <path>` | Totals, by-classification breakdown, top-priority findings, release-readiness verdict | Aggregate the structured results manually per the report-aggregation module and mark the report degraded |
 | One-shot pipeline | `python3 <SKILL_DIR>/scripts/qa_tool.py diagnostics report --execution-result <path>` | Diagnosis, plans, and summary in a single call when no diagnosis exists yet | Run `diagnose` then `summarize` separately |
 | Contract self-check | `python3 <SKILL_DIR>/scripts/qa_tool.py analysis validate <report.json> <schema.json>` | `{valid, errors}` before the report is declared complete | None: an unvalidated report is not complete |
-| Attribution footer | `python3 <SKILL_DIR>/scripts/qa_tool.py analysis branding --format markdown` (or `html`) | The exact footer bytes to append to the **rendered** report | Omit the footer; never retype it |
+| HTML report renderer | `python3 <SKILL_DIR>/scripts/qa_tool.py analysis report-html <report-result.json> --out report.html` | The self-contained HTML rendering of the validated result, footer included | Write the HTML by hand from the contract fields and say it was not machine-rendered |
+| Attribution footer | `python3 <SKILL_DIR>/scripts/qa_tool.py analysis branding --format markdown` | The exact footer bytes to append to the **Markdown** rendering (`report-html` already embeds it) | Omit the footer; never retype it |
 
 A missing `qa_tool.py` means the engine is not installed.
 

package/skills/qa-report/references/deterministic-tooling.md

@@ -61,6 +61,8 @@ Framework-agnostic parsing, redaction, and validation.
 | `validate` | `python3 <skill-dir>/scripts/qa_tool.py analysis validate <instance.json> <schema.json>` | `{valid: bool, errors: [...]}`; exit 1 when invalid |
 | `classify` | `python3 <skill-dir>/scripts/qa_tool.py analysis classify "<error message>" [--http-status N]` | `{classification, confidence, reason}` from the shared taxonomy |
 | `context` | `python3 <skill-dir>/scripts/qa_tool.py analysis context [--root DIR] [--path .qa/context.md]` | The parsed, schema-validated project context as JSON |
+| `report-html` | `python3 <skill-dir>/scripts/qa_tool.py analysis report-html <result.json> [--out report.html]` | The result rendered as one self-contained HTML report — every required field, footer included. Run it instead of writing HTML |
+| `branding` | `python3 <skill-dir>/scripts/qa_tool.py analysis branding --format markdown\|html\|text` | The exact attribution footer bytes for a **rendered** report (never for a JSON artifact) |
 
 ## 3. Diagnostic engine — `qa_tool.py diagnostics`
 

package/skills/qa-report/references/evidence-and-reporting.md

@@ -27,17 +27,42 @@ Any skill that reaches a conclusion — a detected fact, a chosen strategy, a cl
 | Confidence | Calibrated per rule 4; omitted rather than invented when the skill did not weigh alternatives |
 | Recommendations | The next action, named concretely — often the next command and the artifact to feed it |
 
+## Rendering the HTML report
+
+**Never type the HTML.** When a skill's result conforms to a contract the renderer
+supports, the HTML report is generated from that artifact:
+
+```bash
+python3 <SKILL_DIR>/scripts/qa_tool.py analysis report-html <result.json> --out <report.html>
+```
+
+The reason is not tidiness. A hand-written report is a second, lossy copy of the
+artifact, and it loses exactly what the reader needs: the first live `/qa-explore`
+run wrote findings whose `actual`, `expected`, and `fixDirection` were all required,
+all present in the JSON, and all absent from the page — collapsed into one sentence
+that left the reader to guess what correct behaviour would have been. The renderer
+cannot make that mistake, because the fields are in its template.
+
+What the renderer guarantees per finding: severity, the defect, **what happens
+now**, **what should happen instead**, how to reproduce it, the fix direction, and
+every evidence entry — plus the attribution footer, in one self-contained file with
+no external assets.
+
+Run `qa_tool.py analysis report-html --help` for the supported contracts. For an
+artifact it does not support, write the HTML by hand from the contract's fields —
+and render **every** field a reader needs, in that order.
+
 ## Attribution on rendered reports
 
 A report a person opens carries a product attribution footer, the way a Lighthouse
 or Allure report does. It is rendered, never typed: the exact bytes come from the
 bundled analysis toolkit, so every report is identical and a wording change is a
-one-file edit.
+one-file edit. `report-html` already embeds it; for any other rendering, ask for it:
 
 ```bash
-PYTHONPATH="$QA_LIB" python3 -m qa_analysis.cli branding --format html
-PYTHONPATH="$QA_LIB" python3 -m qa_analysis.cli branding --format markdown
-PYTHONPATH="$QA_LIB" python3 -m qa_analysis.cli branding --format text
+python3 <SKILL_DIR>/scripts/qa_tool.py analysis branding --format markdown
+python3 <SKILL_DIR>/scripts/qa_tool.py analysis branding --format html
+python3 <SKILL_DIR>/scripts/qa_tool.py analysis branding --format text
 ```
 
 Append the output as the last element of the rendered document: `html` inside

package/skills/qa-review/references/evidence-and-reporting.md

@@ -27,17 +27,42 @@ Any skill that reaches a conclusion — a detected fact, a chosen strategy, a cl
 | Confidence | Calibrated per rule 4; omitted rather than invented when the skill did not weigh alternatives |
 | Recommendations | The next action, named concretely — often the next command and the artifact to feed it |
 
+## Rendering the HTML report
+
+**Never type the HTML.** When a skill's result conforms to a contract the renderer
+supports, the HTML report is generated from that artifact:
+
+```bash
+python3 <SKILL_DIR>/scripts/qa_tool.py analysis report-html <result.json> --out <report.html>
+```
+
+The reason is not tidiness. A hand-written report is a second, lossy copy of the
+artifact, and it loses exactly what the reader needs: the first live `/qa-explore`
+run wrote findings whose `actual`, `expected`, and `fixDirection` were all required,
+all present in the JSON, and all absent from the page — collapsed into one sentence
+that left the reader to guess what correct behaviour would have been. The renderer
+cannot make that mistake, because the fields are in its template.
+
+What the renderer guarantees per finding: severity, the defect, **what happens
+now**, **what should happen instead**, how to reproduce it, the fix direction, and
+every evidence entry — plus the attribution footer, in one self-contained file with
+no external assets.
+
+Run `qa_tool.py analysis report-html --help` for the supported contracts. For an
+artifact it does not support, write the HTML by hand from the contract's fields —
+and render **every** field a reader needs, in that order.
+
 ## Attribution on rendered reports
 
 A report a person opens carries a product attribution footer, the way a Lighthouse
 or Allure report does. It is rendered, never typed: the exact bytes come from the
 bundled analysis toolkit, so every report is identical and a wording change is a
-one-file edit.
+one-file edit. `report-html` already embeds it; for any other rendering, ask for it:
 
 ```bash
-PYTHONPATH="$QA_LIB" python3 -m qa_analysis.cli branding --format html
-PYTHONPATH="$QA_LIB" python3 -m qa_analysis.cli branding --format markdown
-PYTHONPATH="$QA_LIB" python3 -m qa_analysis.cli branding --format text
+python3 <SKILL_DIR>/scripts/qa_tool.py analysis branding --format markdown
+python3 <SKILL_DIR>/scripts/qa_tool.py analysis branding --format html
+python3 <SKILL_DIR>/scripts/qa_tool.py analysis branding --format text
 ```
 
 Append the output as the last element of the rendered document: `html` inside

package/skills/qa-run/references/deterministic-tooling.md

@@ -61,6 +61,8 @@ Framework-agnostic parsing, redaction, and validation.
 | `validate` | `python3 <skill-dir>/scripts/qa_tool.py analysis validate <instance.json> <schema.json>` | `{valid: bool, errors: [...]}`; exit 1 when invalid |
 | `classify` | `python3 <skill-dir>/scripts/qa_tool.py analysis classify "<error message>" [--http-status N]` | `{classification, confidence, reason}` from the shared taxonomy |
 | `context` | `python3 <skill-dir>/scripts/qa_tool.py analysis context [--root DIR] [--path .qa/context.md]` | The parsed, schema-validated project context as JSON |
+| `report-html` | `python3 <skill-dir>/scripts/qa_tool.py analysis report-html <result.json> [--out report.html]` | The result rendered as one self-contained HTML report — every required field, footer included. Run it instead of writing HTML |
+| `branding` | `python3 <skill-dir>/scripts/qa_tool.py analysis branding --format markdown\|html\|text` | The exact attribution footer bytes for a **rendered** report (never for a JSON artifact) |
 
 ## 3. Diagnostic engine — `qa_tool.py diagnostics`
 

package/skills/qa-run/references/evidence-and-reporting.md

@@ -27,17 +27,42 @@ Any skill that reaches a conclusion — a detected fact, a chosen strategy, a cl
 | Confidence | Calibrated per rule 4; omitted rather than invented when the skill did not weigh alternatives |
 | Recommendations | The next action, named concretely — often the next command and the artifact to feed it |
 
+## Rendering the HTML report
+
+**Never type the HTML.** When a skill's result conforms to a contract the renderer
+supports, the HTML report is generated from that artifact:
+
+```bash
+python3 <SKILL_DIR>/scripts/qa_tool.py analysis report-html <result.json> --out <report.html>
+```
+
+The reason is not tidiness. A hand-written report is a second, lossy copy of the
+artifact, and it loses exactly what the reader needs: the first live `/qa-explore`
+run wrote findings whose `actual`, `expected`, and `fixDirection` were all required,
+all present in the JSON, and all absent from the page — collapsed into one sentence
+that left the reader to guess what correct behaviour would have been. The renderer
+cannot make that mistake, because the fields are in its template.
+
+What the renderer guarantees per finding: severity, the defect, **what happens
+now**, **what should happen instead**, how to reproduce it, the fix direction, and
+every evidence entry — plus the attribution footer, in one self-contained file with
+no external assets.
+
+Run `qa_tool.py analysis report-html --help` for the supported contracts. For an
+artifact it does not support, write the HTML by hand from the contract's fields —
+and render **every** field a reader needs, in that order.
+
 ## Attribution on rendered reports
 
 A report a person opens carries a product attribution footer, the way a Lighthouse
 or Allure report does. It is rendered, never typed: the exact bytes come from the
 bundled analysis toolkit, so every report is identical and a wording change is a
-one-file edit.
+one-file edit. `report-html` already embeds it; for any other rendering, ask for it:
 
 ```bash
-PYTHONPATH="$QA_LIB" python3 -m qa_analysis.cli branding --format html
-PYTHONPATH="$QA_LIB" python3 -m qa_analysis.cli branding --format markdown
-PYTHONPATH="$QA_LIB" python3 -m qa_analysis.cli branding --format text
+python3 <SKILL_DIR>/scripts/qa_tool.py analysis branding --format markdown
+python3 <SKILL_DIR>/scripts/qa_tool.py analysis branding --format html
+python3 <SKILL_DIR>/scripts/qa_tool.py analysis branding --format text
 ```
 
 Append the output as the last element of the rendered document: `html` inside

package/packages/installer/lib/core/schema-validate.mjs

@@ -1,142 +0,0 @@
-// A dependency-free validator for the JSON Schema subset this project uses.
-// It is the JavaScript twin of the Python contract validator in
-// shared/analysis/lib/qa_analysis/contracts.py: same supported subset, same
-// semantics, so a document that passes one passes the other. That promise is
-// tested, not asserted — tests/parity/validator-cases.json runs through both.
-//
-// Anything outside the subset is a programming error in the schema, reported
-// rather than silently ignored. `allOf`/`if`/`then`/`else` are in the subset
-// because the pack's safety invariants are cross-field implications.
-
-// Keep in sync with SUPPORTED_KEYWORDS in
-// shared/analysis/lib/qa_analysis/contracts.py and the table in
-// docs/skills/output-contracts.md (checked by scripts/check-spec-code-sync.mjs).
-const SUPPORTED = new Set([
-  '$schema', '$id', 'title', 'description', 'type', 'properties', 'required',
-  'additionalProperties', 'items', 'enum', 'const', 'pattern', 'minimum',
-  'maximum', 'minItems', 'maxItems', 'minLength', 'maxLength', 'default',
-  'examples', 'format', 'allOf', 'if', 'then', 'else',
-]);
-
-// RFC 3339 date-time — the same rule as the Python twin.
-const DATE_TIME = /^\d{4}-\d{2}-\d{2}[Tt]\d{2}:\d{2}:\d{2}(\.\d+)?([Zz]|[+-]\d{2}:\d{2})$/;
-
-function typeOf(value) {
-  if (value === null) return 'null';
-  if (Array.isArray(value)) return 'array';
-  if (Number.isInteger(value)) return 'integer';
-  return typeof value; // string | number | boolean | object
-}
-
-function matchesType(value, type) {
-  if (type === 'integer') return Number.isInteger(value) && typeof value !== 'boolean';
-  if (type === 'number') return typeof value === 'number';
-  if (type === 'object') return value !== null && typeof value === 'object' && !Array.isArray(value);
-  if (type === 'array') return Array.isArray(value);
-  return typeOf(value) === type;
-}
-
-/** True when value satisfies schema; used for if/then branch selection. */
-function satisfies(value, schema) {
-  const probe = [];
-  validateNode(value, schema, '', probe);
-  return probe.length === 0;
-}
-
-function validateNode(value, schema, pointer, errors) {
-  for (const key of Object.keys(schema)) {
-    if (!SUPPORTED.has(key)) {
-      errors.push(`${pointer || '/'}: schema uses unsupported keyword "${key}"`);
-    }
-  }
-
-  if (schema.type) {
-    const types = Array.isArray(schema.type) ? schema.type : [schema.type];
-    if (!types.some((t) => matchesType(value, t))) {
-      errors.push(`${pointer || '/'}: expected ${types.join(' | ')}, got ${typeOf(value)}`);
-      return; // further checks assume the type held
-    }
-  }
-
-  if (Object.prototype.hasOwnProperty.call(schema, 'const') && JSON.stringify(value) !== JSON.stringify(schema.const)) {
-    errors.push(`${pointer || '/'}: must equal ${JSON.stringify(schema.const)}`);
-  }
-
-  if (schema.enum && !schema.enum.some((option) => JSON.stringify(option) === JSON.stringify(value))) {
-    errors.push(`${pointer || '/'}: ${JSON.stringify(value)} is not one of ${JSON.stringify(schema.enum)}`);
-  }
-
-  if (typeof value === 'string') {
-    if (schema.pattern && !new RegExp(schema.pattern).test(value)) {
-      errors.push(`${pointer || '/'}: "${value}" does not match /${schema.pattern}/`);
-    }
-    if (schema.format === 'date-time' && !DATE_TIME.test(value)) {
-      errors.push(`${pointer || '/'}: "${value}" is not a valid date-time`);
-    }
-    if (schema.minLength != null && value.length < schema.minLength) {
-      errors.push(`${pointer || '/'}: shorter than minLength ${schema.minLength}`);
-    }
-    if (schema.maxLength != null && value.length > schema.maxLength) {
-      errors.push(`${pointer || '/'}: longer than maxLength ${schema.maxLength}`);
-    }
-  }
-
-  if (typeof value === 'number') {
-    if (schema.minimum != null && value < schema.minimum) {
-      errors.push(`${pointer || '/'}: ${value} is below minimum ${schema.minimum}`);
-    }
-    if (schema.maximum != null && value > schema.maximum) {
-      errors.push(`${pointer || '/'}: ${value} is above maximum ${schema.maximum}`);
-    }
-  }
-
-  if (Array.isArray(value)) {
-    if (schema.minItems != null && value.length < schema.minItems) {
-      errors.push(`${pointer || '/'}: has ${value.length} items, needs at least ${schema.minItems}`);
-    }
-    if (schema.maxItems != null && value.length > schema.maxItems) {
-      errors.push(`${pointer || '/'}: has ${value.length} items, allows at most ${schema.maxItems}`);
-    }
-    if (schema.items) {
-      value.forEach((item, index) => validateNode(item, schema.items, `${pointer}/${index}`, errors));
-    }
-  }
-
-  if (matchesType(value, 'object') && (schema.properties || schema.required || schema.additionalProperties === false)) {
-    const properties = schema.properties ?? {};
-    for (const name of schema.required ?? []) {
-      if (!Object.prototype.hasOwnProperty.call(value, name)) {
-        errors.push(`${pointer || '/'}: missing required property "${name}"`);
-      }
-    }
-    for (const [name, child] of Object.entries(value)) {
-      if (properties[name]) {
-        validateNode(child, properties[name], `${pointer}/${name}`, errors);
-      } else if (schema.additionalProperties === false) {
-        errors.push(`${pointer || '/'}: unexpected property "${name}"`);
-      }
-    }
-  }
-
-  // Applicators last: the invariant layer. `additionalProperties` deliberately
-  // does not see properties introduced by these subschemas (JSON Schema
-  // 2020-12 rule, matching the Python twin).
-  for (const sub of schema.allOf ?? []) {
-    validateNode(value, sub, pointer, errors);
-  }
-
-  if (Object.prototype.hasOwnProperty.call(schema, 'if')) {
-    const branch = satisfies(value, schema.if) ? schema.then : schema.else;
-    if (branch != null) validateNode(value, branch, pointer, errors);
-  }
-}
-
-/** Validate `value` against `schema`; returns an array of error strings (empty = valid). */
-export function validate(value, schema) {
-  const errors = [];
-  validateNode(value, schema, '', errors);
-  return errors;
-}
-
-/** The supported keyword subset, exported so tooling can assert parity. */
-export const SUPPORTED_KEYWORDS = Object.freeze([...SUPPORTED].sort());