@aeptus/aexeo-emdash 0.8.3 → 0.8.6

package/CHANGELOG.md

@@ -6,6 +6,158 @@ and the project follows [Semantic Versioning](https://semver.org/).
 
 ## [Unreleased]
 
+## [0.8.6] - 2026-05-04
+
+Code-review follow-ups on the 0.8.5 agent-readiness rule bundles.
+All five issues are real correctness fixes; no behavior change
+for sites that already had clean output.
+
+### Fixed (engine via bridge)
+
+- **Public API exposure.** `SiteCapabilities`, `infer_site_capabilities`,
+  `well_known_path_exists`, `run_well_known_rules`, and
+  `run_header_rules` are now re-exported at the `aexeo-core` root
+  to match the existing pattern (`run_robots_rules`,
+  `run_surface_rules`, etc.). Previously consumers had to use the
+  long `aexeo_core::well_known_rules::run_well_known_rules` form.
+- **LNK020 group/check-key mismatch.** The rule was registered under
+  the `links` group but gated on the `headers` config key in
+  `static_check.rs`; toggling `links: false` would not silence it
+  and toggling `headers: false` would silence an unrelated group.
+  Fixed by moving LNK020 to a new `headers` rule group so the
+  registry name matches the toggle key.
+- **`route_looks_api` over-match.** Bare `v1/`, `v2/`, and
+  `graphql` prefixes incorrectly classified docs routes
+  (`/v1/getting-started`, `/v2/migration-guide`, `/graphql-101`)
+  as API surfaces, triggering SRF020 false-positives on
+  content-only docs sites. Tightened to require `api/` or
+  `graphql/` (with the slash) — the conditional-firing design's
+  whole point is to keep these silent on content sites.
+- **`render_robots_txt` round-trip.** Aexeo's own generator emitted
+  a robots.txt that tripped ROB010 + ROB011 (no AI-bot block, no
+  Content-Signal). Generator now emits explicit AI-bot blocks
+  (GPTBot, ClaudeBot, PerplexityBot, Google-Extended, CCBot) and
+  a permissive Content-Signal default so Aexeo's own output
+  passes Aexeo's own rules.
+- **SRF010/SRF015 unreachable from path-only signals.** The
+  capability gate required the canonical card/index file to
+  exist, but the rule fires when that exact file is missing —
+  structurally unreachable. Inference now also fires when the
+  `.well-known/mcp/` or `.well-known/agent-skills/` directory
+  exists without a canonical file inside (the partial-stub
+  pattern editors hit when starting an implementation).
+
+### Notes for hosts upgrading from 0.8.5
+
+- No code changes required.
+- `aexeo-cli generate robots-txt` (and the deploy generator) now
+  produces a robots.txt with explicit AI-bot blocks and a
+  Content-Signal directive. Editors who want a non-permissive
+  stance edit the line; the defaults match the wildcard `Allow: /`
+  posture so existing crawl behavior is unchanged.
+- Sites that have a `.well-known/mcp/` or
+  `.well-known/agent-skills/` directory stub without canonical
+  files inside will now see SRF010 / SRF015 fire (correctly —
+  the directory-stub state is exactly what the rule was meant
+  to catch).
+
+## [0.8.5] - 2026-05-04
+
+Brings in the agent-readiness audit rules from upstream
+aexeo-core 0.0.11 — three bundles extracted from the Cloudflare
+"Is Your Site Agent-Ready?" scan model.
+
+### Added (engine via bridge)
+
+- **Bundle A — robots.txt extensions** (always-on, retrievability):
+  - `ROB010` — robots.txt has no AI-bot User-agent directives
+    (GPTBot, ClaudeBot, ChatGPT-User, PerplexityBot, …)
+  - `ROB011` — robots.txt has no Content-Signal directives
+    (`ai-train`, `search`, `ai-input`)
+
+- **Bundle B — `.well-known/*` discovery surfaces** (conditional,
+  absorbability). All gated on a new `SiteCapabilities` inference
+  that reads route patterns, JSON-LD schema, llms.txt content,
+  and partial-file presence to decide whether the site claims
+  the underlying capability — so these rules don't fire on
+  content-only sites that have no business exposing the surface:
+  - `SRF010 / SRF011` — agent-skills index (Cloudflare RFC v0.2.0)
+  - `SRF015 / SRF016` — MCP server card (SEP-1649)
+  - `SRF020 / SRF021` — API catalog (RFC 9727 linkset+json)
+  - `SRF025` — OAuth/OIDC discovery (RFC 8414, OIDC Discovery 1.0)
+  - `SRF026` — OAuth protected-resource metadata (RFC 9728)
+
+- **Bundle C — runtime header audits** (runtime-only, mixed):
+  - `LNK020` — homepage response sends no Link headers (RFC 8288).
+    Silent on pure static audits — fires only when `Page.response_headers`
+    is populated.
+  - `SRF030` — homepage doesn't honor `Accept: text/markdown`
+    content negotiation (Cloudflare Markdown for Agents). Adds
+    one extra HTTP probe at the end of the runtime audit.
+
+### Notes for hosts upgrading from 0.8.4
+
+- No code changes required.
+- Static audits will gain ROB010/011 immediately on every site;
+  the SRF010+ rules are silent unless the site has the
+  capability signal (so most content sites see no new findings).
+- LNK020 + SRF030 only fire during runtime audits — static
+  audits don't reach that code path.
+- The new `SiteCapabilities` API is exported from aexeo-core
+  for hosts that want to reuse the inference in their own
+  tooling.
+
+## [0.8.4] - 2026-05-04
+
+Three follow-up quality fixes from Aeptus's post-0.8.3 rollout
+report. The 0.8.3 manifest-quality and GEO009 fixes landed
+correctly; this release closes the remaining edges that surfaced
+once those were out the door.
+
+### Fixed (engine via bridge)
+
+- **Multilingual 404 detection.** v0.0.9's blocklist was
+  English-only, so French, Spanish, Italian, German, Dutch, and
+  Portuguese 404 titles still leaked through as candidate
+  organization/product names. Aeptus reported a French
+  "Page introuvable" landing as `products[0].name`. The detector
+  now matches on cross-language morphological cues
+  (`introuvable`, `non trouv`, `no encontrad`, `não encontrad`,
+  `non trovat`, `nicht gefunden`, `niet gevonden`) plus the
+  literal numeric `404` anchor.
+
+### Fixed (presence diagnostic via bridge)
+
+- **RDAP normalizes to the apex domain.** The diagnostic was
+  asking rdap.org about `www.aeptus.com` (whatever subdomain the
+  manifest's website happened to record), which returns
+  not_found because the registrable domain is the apex
+  (`aeptus.com`). The RDAP fetcher now strips a leading `www.`
+  before the lookup; the result text shows the original host
+  alongside the apex so editors can see what was actually
+  checked. Deeper subdomains (`blog.foo.bar`) still need
+  manual manifest correction — full public-suffix-list-aware
+  resolution is a future hardening.
+- **Wikidata disambiguation.** wbsearchentities returns
+  label-matched candidates without distinguishing
+  Aeptus-the-company from Aeptus-the-genus-of-insects. The
+  fetcher now requests up to 10 candidates and prefers ones
+  whose description doesn't begin with natural-world or
+  geographic disambiguators (`genus of`, `species of`, `village
+  in`, `asteroid`, …). When every match is a generic-concept
+  description, the result still lands but `extra` flags
+  "likely disambiguation needed" so the editor sees the
+  problem instead of trusting the wrong record.
+
+### Notes for hosts upgrading from 0.8.3
+
+- No code changes required; pure engine-side improvements.
+- Worth re-running `intelligence facts generate` if your site
+  has any non-English 404 page that was leaking through.
+- Worth re-running `intelligence presence` if you saw
+  Wikidata false-positives or RDAP not-found on a www-prefixed
+  domain.
+
 ## [0.8.3] - 2026-05-04
 
 Picks up the upstream aexeo-core 0.0.9 improvements that address
@@ -608,7 +760,10 @@ First public release.
   `astro.config.mjs` for the WASM import to resolve to a
   precompiled `WebAssembly.Module`. Not optional.
 
-[Unreleased]: https://github.com/schiste/Aexeo/compare/aexeo-emdash-v0.8.3...HEAD
+[Unreleased]: https://github.com/schiste/Aexeo/compare/aexeo-emdash-v0.8.6...HEAD
+[0.8.6]: https://github.com/schiste/Aexeo/compare/aexeo-emdash-v0.8.5...aexeo-emdash-v0.8.6
+[0.8.5]: https://github.com/schiste/Aexeo/compare/aexeo-emdash-v0.8.4...aexeo-emdash-v0.8.5
+[0.8.4]: https://github.com/schiste/Aexeo/compare/aexeo-emdash-v0.8.3...aexeo-emdash-v0.8.4
 [0.8.3]: https://github.com/schiste/Aexeo/compare/aexeo-emdash-v0.8.2...aexeo-emdash-v0.8.3
 [0.8.2]: https://github.com/schiste/Aexeo/compare/aexeo-emdash-v0.8.1...aexeo-emdash-v0.8.2
 [0.8.1]: https://github.com/schiste/Aexeo/compare/aexeo-emdash-v0.8.0...aexeo-emdash-v0.8.1

package/dist/configured.js

@@ -1160,7 +1160,7 @@ function globToMatcher(pattern) {
 }
 
 // src/version.ts
-var PACKAGE_VERSION = "0.8.3";
+var PACKAGE_VERSION = "0.8.6";
 
 // src/configured.ts
 import { definePlugin } from "emdash";

package/dist/index.js

@@ -23,7 +23,7 @@ function buildAllowedHosts(evaluatorHost) {
 }
 
 // src/version.ts
-var PACKAGE_VERSION = "0.8.3";
+var PACKAGE_VERSION = "0.8.6";
 
 // src/sandbox.ts
 function aexeoPluginSandboxed(options = {}) {

package/dist/version.d.ts

@@ -1,2 +1,2 @@
-export declare const PACKAGE_VERSION = "0.8.3";
+export declare const PACKAGE_VERSION = "0.8.6";
 //# sourceMappingURL=version.d.ts.map

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@aeptus/aexeo-emdash",
-  "version": "0.8.3",
+  "version": "0.8.6",
   "description": "Aexeo SEO/GEO content evaluator as an emdash plugin",
   "license": "MIT",
   "author": "Aeptus",