chore: release v1.0.0 — canonical schema, governance, registry, cross…

.claude/skills/add-ave-record/SKILL.md

@@ -0,0 +1,59 @@
+# add-ave-record
+
+The main workflow for this repo. Adds one new AVE record end to end.
+
+## Steps
+
+### 1. Grill the vulnerability class first
+Run grill-with-docs. Answer:
+- What does a vulnerable component DO? (behavioral_fingerprint)
+- What attack_class is this? (new or existing?)
+- What is the worst-case impact? (drives AIVSS)
+- Which engines can detect it? (evidence_basis_engines)
+- Can a static scan see it, or does it need runtime? (detection_stage)
+- Does it chain with other AVEs? (derivable_into)
+
+### 2. Assign the next ave_id
+Format AVE-YYYY-NNNNN. Never reuse a number. Check records/ for the highest.
+
+### 3. Write the record JSON
+records/AVE-YYYY-NNNNN.json. Must validate against the schema.
+Include the evidence fields:
+- evidence_kind_default
+- detection_stage
+- detection_layer
+- confidence_baseline
+- evidence_basis_engines
+- derivable_into
+
+### 4. Write the detection rule
+One of: rules/pattern/, rules/yara/, rules/semgrep/.
+Must reference the ave_id.
+
+### 5. Write fixtures (TDD — fixtures first)
+tests/fixtures/AVE-YYYY-NNNNN_positive.md — MUST trigger
+tests/fixtures/AVE-YYYY-NNNNN_negative.md — MUST NOT trigger
+The negative fixture is the false-positive guard. Make it realistic —
+a benign file that looks similar to the malicious one.
+
+### 6. Validate
+```bash
+python scripts/validate_records.py
+pytest tests/ -x -q
+```
+
+## Severity / AIVSS consistency
+
+CRITICAL → aivss_score >= 9.0
+HIGH     → 7.0 to 8.9
+MEDIUM   → 4.0 to 6.9
+LOW      → < 4.0
+
+If severity and aivss_score disagree, the record fails validation.
+
+## confidence_baseline guide
+
+High-signal AVE (hardcoded AWS key, explicit external fetch): 0.85-0.95
+Medium-signal (suspicious instruction phrasing): 0.55-0.75
+Low-signal (vague, needs corroboration): 0.40-0.55
+The scanner adjusts from this baseline via the FP pipeline.

.claude/skills/design-an-interface/SKILL.md

@@ -0,0 +1,11 @@
+# design-an-interface — ave
+
+Mostly for schema design and validation tooling.
+
+When changing the record schema, generate 3 designs:
+A: minimal — fewest required fields
+B: rich — every useful field, most optional
+C: layered — core required + evidence extension + runtime extension
+
+Pick the one that the scanner can consume without breaking existing records.
+Schema changes must be backward compatible (new fields optional with defaults).

.claude/skills/diagnose/SKILL.md

@@ -0,0 +1,18 @@
+# diagnose — ave
+
+## Rule misfires (false positive on negative fixture)
+Repro: run the rule against the negative fixture in isolation.
+Minimize: trim the negative fixture to the smallest triggering line.
+Hypothesize: which pattern/condition is too broad?
+Fix: tighten the rule. Re-run both fixtures.
+
+## Record fails validation
+Repro: python scripts/validate_records.py <record>
+Read the jsonschema error — it names the failing field.
+Common: severity/aivss_score mismatch, missing required field,
+ave_id format wrong.
+
+## Scanner does not pick up a new record
+Check: is the record in records/ with valid JSON?
+Check: does evidence_basis_engines list an engine that has a rule?
+Check: does the rule reference the correct ave_id?

.claude/skills/git-guardrails/SKILL.md

@@ -0,0 +1,12 @@
+# git-guardrails — ave
+
+Block: push --force, reset --hard, clean -fd, rebase -i on pushed commits.
+
+Before commit:
+python scripts/validate_records.py    # all records valid
+pytest tests/ -x -q                    # rules fire correctly
+
+## Record-specific
+
+NEVER renumber an ave_id. Once AVE-2026-00001 is published, that number
+is permanent. A wrong record gets deprecated, not renumbered.

.claude/skills/grill-with-docs/SKILL.md

@@ -0,0 +1,26 @@
+# grill-with-docs — ave
+
+Grill before defining a vulnerability class. No record until complete.
+
+## Questions
+
+Q1: In one sentence, what does a vulnerable component DO?
+    (This becomes behavioral_fingerprint — must be behavioral, not a string.)
+Q2: Is this a new attack_class or a variant of an existing one?
+    (Check records/ for similar attack_class values first.)
+Q3: What is the worst realistic impact? (drives cvss_base and severity)
+Q4: How much does agent autonomy amplify it? (drives aars)
+Q5: Which engines can detect it? pattern/yara/semgrep/llm/sandbox/magika
+Q6: Can a STATIC scan fully assess it, or does it need runtime observation?
+    (detection_stage: static_detection vs runtime_observed)
+Q7: Where does it surface? content / server_card / registry / runtime
+    (detection_layer)
+Q8: What is the confidence_baseline? High-signal or needs corroboration?
+Q9: Does it chain with other AVEs into a toxic flow? (derivable_into)
+Q10: What does the negative fixture look like — a benign file that looks
+     similar but must NOT trigger?
+
+## End
+
+Summary, the record JSON skeleton, the rule approach, the two fixture
+descriptions. Next: write fixtures first (TDD), then the rule, then validate.

.claude/skills/handoff/SKILL.md

@@ -0,0 +1,23 @@
+# handoff — ave
+
+End: docs/agents/handoffs/YYYY-MM-DD-HHMM.md
+Start: read most recent, run python scripts/validate_records.py.
+
+## End format
+
+# Handoff — date
+
+## Completed
+- records/AVE-2026-00049.json — header injection (BadHost) record added
+- rules/semgrep/ave-2026-00049.yaml — detection rule
+- tests/fixtures/AVE-2026-00049_positive.md + _negative.md
+
+## Status
+python scripts/validate_records.py → all valid
+pytest tests/ -q → N passed
+
+## Next
+AVE-2026-00050: database data-path exposure (Mads Hansen suggestion)
+First: grill the behavioral_fingerprint.
+
+Note: docs/agents/handoffs/ gitignored.

.claude/skills/improve-codebase-architecture/SKILL.md

@@ -0,0 +1,9 @@
+# improve-codebase-architecture — ave
+
+The "code" here is validation tooling and rule loaders.
+
+Deletion test on a validation script: if deleted, would the validation
+logic reappear across callers? The schema validator earns its keep —
+every scanner and PiranhaDB ingest relies on records being valid.
+
+Candidates: consolidate per-engine rule loaders into one loader interface.