feat: add new AVE records and docs improvement

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

@@ -26,16 +26,19 @@ Include the evidence fields:
 - 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
+### 4. Write conformance fixtures (TDD — fixtures first)
+tests/fixtures/AVE-YYYY-NNNNN_positive.md — a conforming implementation MUST flag this
+tests/fixtures/AVE-YYYY-NNNNN_negative.md — a conforming implementation MUST NOT flag this
 The negative fixture is the false-positive guard. Make it realistic —
 a benign file that looks similar to the malicious one.
 
+### 5. Open a coordinated detection-rule PR
+Detection rule implementations (pattern, YARA, semgrep, or anything else)
+are implementation artifacts, not standard artifacts — they live in
+whichever tool implements against this standard, not in this repo. Open a
+PR in that tool's own repo (e.g. bawbel/scanner) referencing the ave_id and
+the fixtures above; see CONTRIBUTING.md Step 4.
+
 ### 6. Validate
 ```bash
 python scripts/validate_records.py

.claude/skills/handoff/SKILL.md

@@ -9,8 +9,8 @@ Start: read most recent, run python scripts/validate_records.py.
 
 ## 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
+- Coordinated detection-rule PR opened in bawbel/scanner, referencing AVE-2026-00049
 
 ## Status
 python scripts/validate_records.py → all valid

.claude/skills/research-new-attack-classes/SKILL.md

@@ -18,7 +18,7 @@ AVE already covers, it is logged as a variant, not a new record.
 - Monthly cadence (the field moves fast — set a recurring reminder)
 - After a major disclosure (a new CVE, a new OX/Invariant/HiddenLayer report)
 - After a new academic taxonomy or benchmark paper drops
-- Before a release or Product Hunt push (close the gap deliberately)
+- Before a release (close the gap deliberately)
 
 Do NOT run this to hit a record-count target. Run it to stay current.
 There is no quota. The right number of records equals the number of

.github/ISSUE_TEMPLATE/01_ave_submission.md

@@ -8,7 +8,7 @@ assignees: ''
 
 ## Before you open this issue
 
-- [ ] I have searched the registry at ave.bawbel.io and the `records/` directory
+- [ ] I have searched the registry at aveproject.org and the `records/` directory
 - [ ] This is a genuinely distinct behavioral class, not a variant of an existing record
 - [ ] I have a citable primary source (CVE, paper, disclosure, or working PoC)
 

.github/workflows/notify-ave-site.yml

@@ -1,36 +1,35 @@
 name: Notify ave-site on records update
 
-# This workflow lives in bawbel/ave.
+# This workflow lives in aveproject/ave.
 # Place it at: .github/workflows/notify-ave-site.yml
 #
-# When records, schema, or rules change on main, it fires a
-# repository_dispatch to bawbel/ave-site so the site rebuilds automatically.
+# When records or schema change on main, it fires a
+# repository_dispatch to aveproject/ave-site so the site rebuilds automatically.
 #
 # Required secret: AVE_SITE_DEPLOY_TOKEN
 # Create a fine-grained PAT with:
-#   - Repository: bawbel/ave-site
+#   - Repository: aveproject/ave-site
 #   - Permissions: Contents (read), Actions (write)
-# Add it as a secret named AVE_SITE_DEPLOY_TOKEN in bawbel/ave settings.
+# Add it as a secret named AVE_SITE_DEPLOY_TOKEN in aveproject/ave settings.
 
 on:
   push:
     branches: [main]
     paths:
       - "records/**"
       - "schema/**"
-      - "rules/**"
 
 jobs:
   notify:
     name: Trigger ave-site rebuild
     runs-on: ubuntu-latest
 
     steps:
-      - name: Dispatch to bawbel/ave-site
+      - name: Dispatch to aveproject/ave-site
         uses: peter-evans/repository-dispatch@v3
         with:
           token: ${{ secrets.AVE_SITE_DEPLOY_TOKEN }}
-          repository: bawbel/ave-site
+          repository: aveproject/ave-site
           event-type: ave-records-updated
           client-payload: |
             {

.github/workflows/tests.yml

@@ -27,11 +27,8 @@ jobs:
       - name: Validate all records against the schema
         run: python scripts/validate_records.py
 
-      - name: Check every rule has positive and negative fixtures
+      - name: Check every record has positive and negative conformance fixtures
         run: python scripts/check_fixtures.py
 
-      - name: Check every record has a detection rule
-        run: python scripts/check_rule_coverage.py
-
-      - name: Run tests with coverage (rules/)
-        run: pytest tests/ -x -q --cov=rules --cov-report=term-missing --cov-fail-under=95
+      - name: Run tests
+        run: pytest tests/ -x -q

.gitignore

@@ -8,3 +8,9 @@ docs/agents/handoffs/
 .DS_Store
 node_modules/
 .coverage
+
+# local planning/scratch docs, not for the repo
+AVE_ORG_MOVE_CHECKLIST.md
+AVE_PROJECT_CLEANUP_TASKS.md
+AVE_V1.1.0_MIGRATION_BRIEF.md
+TRUST_STRATEGY.md

ARCHITECTURE.md

@@ -1,72 +1,82 @@
-# ARCHITECTURE.md — bawbel/ave
+# ARCHITECTURE.md — aveproject/ave
 
-Update this file before closing any PR that changes the record structure,
-adds a new rule engine category, or changes how records and rules relate.
+Update this file before closing any PR that changes the record structure
+or changes how records and conformance fixtures relate.
 
 ---
 
 ## What this repo is
 
 A standard, not software. The architecture is the schema, the record store,
-the rules that implement detection, and the validation tooling.
+the conformance fixtures, and the validation tooling.
 
 ```
-records/              AVE record JSON files — the standard's data
+records/              AVE record JSON files, the standard's data
 schema/               JSON schema the records validate against
-  ave-record.schema.json             alias — always points to current
-  ave-record-1.1.0.schema.json       versioned canonical — current, permanent
-  ave-record-1.0.0.schema.json       versioned canonical — frozen, permanent
-rules/                Detection rule implementations
-  ├── pattern/        Regex pattern rules (Python)
-  ├── yara/           YARA rules (.yar)
-  └── semgrep/        Semgrep rules (.yaml)
-tests/fixtures/       Positive and negative test files per rule
-scripts/              Validation and coverage tooling
-crosswalks/           Mappings from other scanners and frameworks to AVE ids
-docs/                 ADRs, guides, research reports
+  ave-record.schema.json             alias, always points to current
+  ave-record-1.1.0.schema.json       versioned canonical, current, permanent
+  ave-record-1.0.0.schema.json       versioned canonical, frozen, permanent
+tests/fixtures/       Positive and negative conformance fixtures per record.
+                       Any implementation's own detection logic is tested
+                       against these; the logic itself lives in that
+                       implementation's own repo, not here. See "record and
+                       conformance fixture" below.
+scripts/               Validation and coverage tooling
+crosswalks/            Mappings from other scanners and frameworks to AVE ids
+docs/                  ADRs, guides, research reports
 ```
 
+There is no `rules/` directory in this repo. Detection rule implementations
+(pattern matching, YARA, semgrep, or anything else) are implementation
+artifacts, not standard artifacts, and live in whichever tool implements
+against this standard, `bawbel-scanner` included. Shipping one
+implementation's rules here would make this repo describe one product
+instead of a standard any product can implement against; see `CONTEXT.md`'s
+framing discipline.
+
 ---
 
-## The record → rule → fixture triangle
+## The record and conformance fixture relationship
 
 ```mermaid
 flowchart LR
     RECORD[AVE Record\nrecords/AVE-YYYY-NNNNN.json\nthe definition]
-    RULE[Detection Rule\nrules/pattern\nyara\nsemgrep\nthe implementation]
-    POS[Positive Fixture\ntests/fixtures/\nMUST trigger]
-    NEG[Negative Fixture\ntests/fixtures/\nMUST NOT trigger]
-
-    RECORD -->|references by ave_id| RULE
-    RULE -->|detects| POS
-    RULE -->|does not detect| NEG
-    RECORD -->|evidence_basis_engines\ndeclares which engines| RULE
+    POS[Positive Fixture\ntests/fixtures/\nany conforming implementation MUST flag this]
+    NEG[Negative Fixture\ntests/fixtures/\nany conforming implementation MUST NOT flag this]
+    IMPL[An implementation's own detection logic\nlives in that implementation's own repo]
+
+    RECORD -->|behavioral_fingerprint, indicators_of_compromise,\nexample_patterns describe what to detect| IMPL
+    IMPL -.->|tested against, external to this repo| POS
+    IMPL -.->|tested against, external to this repo| NEG
 ```
 
-Every record must have all four corners. A record with no rule is a
-definition nobody can detect. A rule with no negative fixture is a
-false-positive risk with no guard.
+Every record should have fixtures. A record with no fixtures is a definition
+nobody has a shared, neutral way to verify detection against. The dotted
+lines are deliberate: this repo owns the record and the fixtures an
+implementation is measured against, not the implementation itself. A second
+implementer proves conformance by passing these fixtures with their own
+rules, not by adopting `bawbel-scanner`'s.
 
 ---
 
-## How the scanner consumes this repo
+## How an implementation consumes this repo
 
 ```
-bawbel/ave (this repo)              bawbel/scanner (consumer)
+aveproject/ave (this repo)              a conforming implementation
 ──────────────────────              ─────────────────────────
 records/*.json          ──load──▶   AVE record lookup
-rules/pattern/*.py       ──load──▶   PatternEngine
-rules/yara/*.yar         ──load──▶   YARAEngine
-rules/semgrep/*.yaml     ──load──▶   SemgrepEngine
 
 record.confidence_baseline  ──────▶  starting confidence for a Finding
 record.evidence_kind_default ─────▶  Finding.evidence_kind default
 record.detection_stage       ─────▶  Finding.evidence_stage floor
 record.derivable_into        ─────▶  ToxicFlow chain candidates
 ```
 
-PiranhaDB also ingests records/ and serves them at api.piranha.bawbel.io.
-The ave-site build script reads records/ to generate the public registry.
+The `ave-site` build script reads `records/` to generate the public registry;
+that is standard infrastructure, not a third-party consumer. Any other
+service consuming these records, including any Bawbel-operated one, is an
+implementation of the standard and is documented in its own repo, not here,
+per `CONTEXT.md`.
 
 ---
 
@@ -76,18 +86,18 @@ Every AVE record declares a `detection_layer` — where in the agent ecosystem t
 class surfaces. This determines what kind of scanner or monitoring reaches it.
 
 ```
-Ecosystem location          Layer              Scanner that reaches it
+Ecosystem location          Layer              What reaches it
 ─────────────────────────   ─────────────────  ──────────────────────────────────
-Skill / prompt file body    content            Static file scanner (bawbel scan)
-MCP server manifest         server_card        Server-card scanner (bawbel scan-server-card)
-Registry listing            registry_metadata  Registry audit
-Live agent execution        runtime            Behavioral sandbox / runtime monitor
-Network layer               transport          Proxy / network monitor
+Skill / prompt file body    content            A static file scanner, pre-execution
+MCP server manifest         server_card        A server-card fetcher, before first tool call
+Registry listing            registry_metadata  A registry audit process
+Live agent execution        runtime            A behavioral sandbox or runtime monitor
+Network layer               transport          A proxy or network monitor
 ```
 
-**content** is the most common layer (33 of 48 records). The payload is text in the file body.
-A static scanner catches it before the agent ever runs. This is the layer bawbel-scanner covers
-primarily.
+**content** is the most common layer (37 of 59 records). The payload is text in the file body.
+A static scanner catches it before the agent ever runs, no live execution required, which is why
+this layer is the easiest for any implementation to cover first.
 
 **server_card** means the injection is in the MCP server manifest — `.well-known/mcp.json`, tool
 description fields, or parameter schemas. The agent reads this before making its first tool call.
@@ -100,7 +110,7 @@ installation.
 **runtime** means the evidence only exists during a live agent session. The injected payload
 arrives as a tool result, a memory write, an A2A message, a rendered UI artifact, or an async
 task payload. No static scanner sees this. Requires a behavioral sandbox or runtime monitoring.
-12 records are at this layer — they are the hardest to defend against because they bypass
+15 records are at this layer — they are the hardest to defend against because they bypass
 pre-deployment scanning entirely.
 
 **transport** means the attack is in the network layer — a redirected OAuth endpoint, a manipulated

CHANGELOG.md

@@ -6,6 +6,29 @@ Format: [Semantic Versioning](https://semver.org). Schema versions and record se
 
 ---
 
+## [1.3.0] - 2026-07-17
+
+### Summary
+
+- 3 new records: AVE-2026-00057 through AVE-2026-00059 — record set now at 59,
+  118 tests passing.
+  - AVE-2026-00057: obfuscated/encoded skill payload designed to evade static
+    scanners (base64/hex/marshal decode fed directly into eval/exec)
+  - AVE-2026-00058: deceptive skill trigger or activation-scope manipulation
+    via misleading manifest description
+  - AVE-2026-00059: fragmented cross-tool-description prompt injection
+    reassembled at a planted trigger (ShareLock-class), citing the original
+    research plus Microsoft's 2026 MCP security checkpoint
+- `owasp_mcp` corrected against `crosswalks/ave-to-owasp-mcp.md` during review,
+  not just pattern-validated against the schema: AVE-2026-00057 was missing
+  `MCP03` (Tool Poisoning) alongside `MCP04`; AVE-2026-00058's draft `MCP09`
+  (Shadow MCP Servers) was a flat mismatch, corrected to `MCP03` + `MCP06`
+  (Tool Poisoning, Intent Flow Subversion). `mitre_atlas: AML.T0051` on
+  AVE-2026-00059 verified against MITRE's own published technique name (LLM
+  Prompt Injection), not assumed from existing corpus convention.
+
+---
+
 ## [1.2.0] - 2026-07-12
 
 ### Summary