SummitCite

Changelog

1.7.3

• First WordPress.org release, published as SummitCite.
• No behavioural change and no database migration: tables, the aive_settings
  option, transients and cron hooks keep their aive_ prefix, so nothing is
  re-scanned or reset on update.
• robots.txt markers are # BEGIN SummitCite / # END SummitCite. A block
  written under the previous markers is recognised and replaced in place on the
  next request; a pair that does not match still stops the module with an admin
  notice instead of being edited on a guess.
• The plugin description spells out “WordPress” instead of “WP”, and the readme
  gains an External services section stating that the plugin contacts no
  external service and that the crawler documentation links are plain
  hyperlinks the plugin never requests.

1.7.1

• Answer Density now shows the values its score is built from. The admin
  listing’s AJAX payload and the rendered table both carry the algorithm
  version, the raw coverage ratio and the per-dimension points – coverage,
  quality and structure – so a score can be traced to its arithmetic instead of
  being taken on trust.
• Tie-break ordering for equal scores is locale-aware. Previously an equal-score
  pair was ordered by the database’s default collation, which orders non-English
  titles by byte value rather than by the site’s language.
• No schema change; existing rows are re-rendered with the new fields on the next
  screen load. No re-scan required.

1.7.0

• New Dashboard, the parent screen for the plugin: an operational-evidence score
  with a colour-coded gauge (good at 70 and above, fair 40 to 69, poor below 40),
  four linked summary cards, a six-component breakdown that states why a
  component is unavailable rather than showing a zero, and quick links into each
  module.
• Fourteen days of AI crawler activity as a bar chart drawn in pure CSS – no
  chart library, no canvas, no image – bounded to whole UTC days, with every
  plotted value repeated in a semantic table underneath and in each bar’s
  accessible label.
• Settings consolidated onto one screen: crawler log, robots policy, schema,
  llms.txt, answer density and conflict detector sections in a single form,
  saved once, with each module’s state and ownership shown next to its controls.
• Existing screens and slugs are unchanged, so every bookmark and every link
  into a specific module keeps working.
• No new tables, options or migrations. The Dashboard reads what the modules
  already store and keeps no state of its own.

1.6.0

• New Conflict Detector module and screen: a closed inventory of five SEO plugin
  families – Yoast SEO, Rank Math, SEOPress, All in One SEO and The SEO
  Framework – with the ownership each one delegates for robots.txt, structured
  data and llms.txt, the evidence used to decide it, and a recommendation
  wherever ownership is contested.
• Delegated rows defer to the owning feature’s own decision instead of
  re-deriving it, so the two screens can never disagree about who owns a file.
• One-hour reporting cache with an explicit Retest action; the cache is discarded
  when modules, settings or active plugins change, and a failed probe is reported
  as a named failure rather than an inferred status.
• Aggregate statistics feed the Dashboard. No new tables, no background work and
  no front-end output.

1.5.0

• New Answer Density module: deterministic per-post classification and
  transparent scoring across coverage, quality and structure, with each
  dimension scored separately rather than collapsed into one opaque number.
• Versioned results stored per post: a result records the algorithm version that
  produced it, so a score from before a change is never presented as though it
  came from after one.
• Single and bulk scans on demand, plus a six-hourly scheduled sweep. A scan
  reads stored content only – it never renders a page, executes a shortcode or
  calls a provider – and is bounded in size and time.
• Worst-first administration, so the content that most needs work is at the top
  of the list, with the supporting signals shown next to the score.
• Disabling the module preserves stored rows and stops scanning; removing a post
  type hides its rows without deleting them; restoring either resumes from the
  existing data rather than starting over.
• No front-end output and no new user-facing surface beyond its own admin screen.

1.4.0

• Module 4, llms.txt: serves a plain-text inventory of eligible public content
  at the site root, from one rewrite rule matching /llms.txt with one optional
  trailing slash and nothing else. Handled on template_redirect at priority 1,
  before canonical redirection and any template, and it ends the request.
• The response is exactly HTTP 200 with Content-Type: text/plain; charset=UTF-8
  and X-Content-Type-Options: nosniff. No theme output, no redirect and no
  frontend JavaScript on any request.
• SummitCite serves only when the module is on, site visibility is on, no
  ABSPATH/llms.txt exists, and no supported plugin is positively detected as
  providing the feature. Otherwise the route yields WordPress’s ordinary 404 –
  never an empty 200, a redirect, a second document or a public explanation of
  who owns it.
• Fixed ownership precedence: site visibility off, a physical file, Yoast SEO’s
  enable_llms_txt setting, Rank Math’s llms-txt module, then SummitCite. A plugin
  being active is never evidence on its own, and no request input reaches the
  decision. An absent, unreadable or malformed signal, or an unsupported plugin,
  is reported as not established rather than as a known owner, and does not stop
  SummitCite – the physical-file rule already catches the case that produces a
  duplicate, including Yoast’s, whose feature writes a real file into the site
  root.
• Eligibility is published, public, non-attachment, non-revision,
  non-password-protected content with a canonical HTTP(S) permalink on this
  site. Private, draft, pending, scheduled, trashed, protected, attachment and
  non-public content never appears, and neither does any archive, feed, search
  or taxonomy view.
• Two selection modes. An explicit, ordered selection lists exactly those of its
  items that are still eligible and appends nothing; an item that becomes
  ineligible is omitted without the stored selection being rewritten. With no
  valid selection, automatic selection lists at most 20 pages by menu order,
  title then id, and at most 20 standard posts by date then id. No custom post
  type is selected automatically. An empty section is absent.
• Deterministic output: the same effective state produces byte-identical,
  LF-terminated UTF-8. Every site name, description and title is stripped of
  markup, decoded, cleared of control, line-break, bidirectional-override and
  zero-width characters, bounded by characters rather than bytes, and
  backslash-escaped, so no title can inject a heading, a list item or its own
  link destination. Permalinks are validated to this site’s host and
  percent-encoded where a Markdown destination would otherwise break.
• The response is capped at 64 KiB by omitting whole items in deterministic
  order, never by truncating: no half-written list item, no heading introducing
  nothing and no split UTF-8 character.
• A twelve-hour cache keyed on the format version, the plugin build, site
  identity and visibility, the effective llms settings including the ordered
  selection, the ownership signature, and each item’s id, title, permalink, menu
  order, date and modification instant. Ownership and visibility are determined
  before the cache is consulted, so a new conflict or a newly private site never
  serves a cached document. A corrupt entry reads as a miss and regenerates.
• Three bounded controls in the existing aive_settings option on the existing
  Settings screen: the enable toggle, a 500-character description, and a
  checkbox list of up to 200 pages and 50 recent posts plus anything already
  selected outside them. Saved through the ordinary options.php capability and
  nonce path; invalid, duplicate, unknown and ineligible ids are discarded, and
  unrelated settings keys survive a save untouched. No new admin page, REST
  endpoint, custom AJAX surface, dashboard, script or stylesheet.
• The section reports who owns the route and why, with one neutral notice per
  state and a per-plugin evidence table that distinguishes a known owner from
  one SummitCite could not establish – and states that SummitCite does not verify another
  owner is serving a valid file.
• Activation and deactivation maintain the route and clear the cached document
  only. The module never writes, edits, deletes or claims ownership of a
  physical llms.txt, and uninstall removes its cache, its route marker and its
  settings through the existing prefix sweep.
• The route needs a permalink structure other than Plain. Activation flushes the
  rewrite rules, and one bounded soft flush per build repairs the stored rules
  on a site upgraded by overwriting plugin files, which fires no activation hook.
• No AI provider call, external request, crawler-registry change, robots or
  schema change and no unrelated setting is introduced by this release.

1.3.0

• Module 3, Schema Engine: emits one Article or BlogPosting block for every
  eligible published post, page or public custom post type viewed on its own
  page, plus one FAQPage and one HowTo block when the content qualifies. A core
  post is described as BlogPosting; a page or custom post type as Article.
• Nothing is emitted in wp-admin, AJAX, REST, feed, cron, CLI, login, embed or
  preview contexts, on a 404, search, blog index or archive, or for a revision,
  autosave, attachment, non-public post type, unpublished status or
  password-protected record. A record appearing in the preview selector does not
  override any of those.
• Required Article fields are all-or-nothing: headline, publication and
  modification instants from the stored GMT dates, the canonical permalink and
  an Organization publisher. If one cannot be formed, no Article is emitted
  rather than a partial or guessed one. Author, description, image, logo and
  language are optional and simply absent when unavailable.
• Explicit marker grammar for both derived types:
  / <!-- aive:faq:end --> and the aive:howto
  pair. Inside a FAQ region every heading and every details/summary is a
  question whatever its wording, which is what makes the feature usable in
  languages the automatic rules do not cover. Markers are HTML comments, so they
  survive the Classic editor, the Code editor and a Custom HTML block.
• Automatic detection is bounded rather than open-ended: h2/h3 headings and
  details/summary that end in ?, ？ or ؟ or begin with a listed English,
  Chinese, Japanese or German interrogative, with at least two distinct pairs
  required; and a procedure heading beginning with a listed phrase whose next
  meaningful sibling is an ordered list of two or more items. No other ordered
  list is read as a procedure.
• Overlap precedence is fixed and deterministic: explicit HowTo, explicit FAQ,
  automatic HowTo, then automatic FAQ. A procedure heading and its list are
  never also published as a question and an answer.
• Bounds on everything parsed: at most 200 KiB of stored content, 20 FAQ pairs,
  20 steps, 200 characters per question or step name, 2,000 per answer or step,
  and 40,000 across one generated object. FAQ questions are deduplicated
  case-insensitively and a duplicate cannot satisfy the automatic threshold.
• The generator reads stored content with shortcodes removed. It never calls
  the_content, renders a block, executes a shortcode or fetches a URL, and
  libxml runs with networking off and its diagnostics collected. A documented
  aive_schema_source_content filter can replace the bounded source; output
  that is not a string within the bound is ignored.
• Serialisation goes through wp_json_encode() with JSON_HEX_TAG,
  JSON_HEX_AMP, JSON_HEX_APOS and JSON_HEX_QUOT, so no author text can
  close the script element it sits inside. Every emitted URL is validated to an
  absolute HTTP(S) URL; an invalid optional URL is dropped and an invalid
  required one suppresses its object. No frontend script or stylesheet is
  enqueued.
• Schema conflict ownership, evidenced per plugin rather than by presence. Yoast
  SEO, Rank Math, SEOPress, All in One SEO and The SEO Framework each get an
  adapter with a stated version profile, and each decision carries the detected
  version, the setting or hook consulted and the profile used. An active plugin
  whose schema output cannot be established is reported as unknown and SummitCite
  emits nothing, which is the deliberate conservative choice. An SEO plugin
  outside the five is not evaluated and does not block SummitCite.
• The SEO Framework’s contradictory legacy requirement is resolved as an
  evidence-scoped decision: coexistence only for a configuration profile
  confirmed to emit site-level and breadcrumb schema alone. No such profile is
  confirmed in this release, so an active install is treated as unknown and SummitCite
  stands down.
• aive_schema_conflict filters the complete ownership result. It may select
  only a recognised state and owner, cannot force output for a disabled module
  or an ineligible record, is recorded as an override and is shown to
  administrators. Malformed filter output falls back to SummitCite’s own decision.
• Generated payloads are cached for at most twelve hours under a key carrying
  post identity and modification time, status, type, a content hash, the
  settings hash, the site’s locale, home URL, name, logo and icon, the active
  theme, the featured image, the author identity used and the ownership
  signature – so a stale payload is unreachable rather than merely scheduled for
  deletion. Only normalised payloads are stored, never raw or rendered content,
  and the relevant entries are also deleted on edit, status change, featured
  image, author, site identity, theme, settings and SEO-plugin lifecycle events.
• New Schema screen, manage_options only: the generation rules per type in
  plain language, who owns the graph with per-plugin evidence, and a preview of
  the generated candidate for any published eligible record. The preview is
  labelled “Generated candidate – not proof of frontend emission”, prints JSON
  as escaped text in a labelled region rather than as an executable script,
  carries an accessible status message and a visible empty state, and reports
  disabled, ineligible, yielded, unknown, no-qualifying-content and encoding
  outcomes by name.
• The record selector is a read-only GET with strict integer validation. It
  lists published, unprotected, eligible records only, and a record supplied by
  id that is not eligible is reported by reason alone, without its title.
• Settings screen gains the Schema section with the Schema Engine toggle, stored
  in the existing aive_settings[enable_schema] key. Settings the form does not
  render still survive a save. Switching the module off stops output, makes the
  preview unavailable and clears the schema cache.
• No database schema or table change. Schema cache artifacts carry the aive_
  prefix, so uninstall removes them with every other SummitCite artifact and no
  third-party data is touched. Crawler, robots, registry, database and the
  accepted timestamp behaviour are unchanged.

1.2.0

• Module 2, Robots policy: declares an Allow, Block or Don’t manage rule for
  every token in the crawler registry, written into the robots.txt WordPress
  generates. Allow contributes Allow: / with Disallow: /wp-admin/; Block
  contributes Disallow: /; Don’t manage contributes nothing.
• All SummitCite output sits inside one # BEGIN SummitCite /
  # END SummitCite block. Text outside the markers is never
  modified, the previous block is replaced rather than appended to, and marker
  text that is not one matching pair stops the module entirely with an admin
  notice rather than being edited on a guess.
• Robots conflict ownership. SummitCite writes nothing when WordPress is set to
  discourage search engines, when a robots.txt file exists in the site root,
  when Rank Math, All in One SEO or SEOPress Pro has its own robots management
  switched on by evidence of that plugin’s own setting, or when such a plugin is
  active and its setting cannot be read. An active plugin alone is never treated
  as owning robots.txt.
• A bot that an existing non-SummitCite group already names is left alone: no second
  group is emitted for it, and the audit reports which bots are in that state.
• New Robots Audit screen. Reports the source of the audited response, when it
  was last checked and whether that is still current, who owns robots.txt, and
  per bot the configured rule, the measured status at the site root, the reason
  for it, and any mismatch. Empty and failure states say what to do next instead
  of showing a zero.
• The audit makes one bounded request to this site’s own /robots.txt: no URL
  field, HTTP(S) only, home host and port, no redirect followed, a ten-second
  timeout and at most 128 KiB read. A redirect, a non-2xx status, a non-text
  response, an oversized body or a transport error each produce a named failure
  and no inferred bot status. Nothing fetched is stored.
• The audit runs only on an explicit nonce-checked Re-run Audit by a
  manage_options user. Opening the screen reads a one-hour cache and never
  fetches; the cache is discarded when the rules, the site visibility or the
  active plugins change.
• Audit limits are stated rather than implied: it reports access to the site
  root only, does not evaluate wildcards or anchors, and is not evidence that
  any crawler obeys robots.txt.
• Settings screen gains the Robots section: the module toggle and the per-bot
  rule table. A submitted rule is kept only for a currently registered token
  with a recognised value; anything else is discarded and a missing value
  becomes Don’t manage. Settings the form does not render still survive a save.
• A registry name that cannot be written safely into robots.txt is excluded from
  the rules and the output, and reported in an admin-only notice rather than
  dropped silently.
• No new table, column or schema migration. Rules live in the existing
  aive_settings option and the audit in an aive_* transient, so the existing
  uninstall cleanup removes both.

1.1.0

• Module 1, Crawler Log: records visits from known AI crawlers and reports them
  on a new admin screen.
• Logs an eligible visit on template_redirect when the User-Agent matches the
  crawler registry. Eligible means a GET request for a single published post,
  page or public custom post type. Humans, unmatched User-Agents, non-GET
  methods, admin, AJAX, REST, cron, feed, robots.txt, sitemap and XML requests,
  and non-singular or non-public content are all ignored. A configured posts
  page records nothing, because the blog index lists other content rather than
  being a visit to that page; a static front page is a real page view and is
  recorded against its own ID.
• Stores the matched bot name and type, resolved post ID, request URI path,
  User-Agent and REMOTE_ADDR, each truncated to its column width. The query
  string is dropped and forwarding headers are deliberately not read.
• New admin menu, SummitCite, holding Crawler Log and Settings. Both screens
  require manage_options, re-checked in the page callback rather than relying
  on the menu entry alone.
• Crawler Log screen reports Visits by Bot and Recent Visits over the last seven
  days, filterable by bot and sortable by time, with its own empty state and a
  distinct message when the table cannot be read.
• Settings screen renders Module 1’s two controls: the enable toggle and the
  retention period. Saves go through register_setting with a nonce and a
  capability check, and the sanitiser preserves the settings of modules that do
  not exist yet instead of dropping them.
• Retention: the daily aive_cleanup_crawler_logs event deletes rows older than
  log_retention_days x 24 hours of elapsed time. Bounded to 1-3650 days, 90 by
  default, and clamped on read as well as on save so a value written
  programmatically cannot widen the window. Both this window and the seven-day
  reporting window measure absolute elapsed time, so neither shifts by an hour
  across a daylight-saving transition in site timezones that observe one.
• Seven-day totals and distinct bot counts published through the
  aive_dashboard_stats filter as crawler_total_visits_7d and
  crawler_unique_bots_7d, ready for the Module 7 dashboard.
• Every SQL statement against the crawler log table lives in one store class,
  with prepared bindings and an ORDER BY allow-list. A database error degrades
  to an admin message and never affects a front-end response.
• No assets of any kind: the admin screens are built from core’s own classes,
  and the front end loads no SummitCite stylesheet or JavaScript.
• Requirements 2, 6 and 9 of the acceptance suite now execute, joined by new
  integration coverage for retention boundaries, the reporting window, admin
  authorisation, escaping and the empty and failure states.
• Timekeeping: the crawler log gains a visited_at_utc column and an index on
  it, and that column alone decides retention, the seven-day window,
  newest-first ordering and each bot’s last visit. The existing visited_at
  stays as a site-local rendering of the same instant for compatibility and is
  no longer compared against. A column with no offset cannot tell apart the two
  instants an hour apart that share a wall-clock reading when the clocks go
  back, which made retention keep an expired row and the seven-day count
  include one. Timestamps are converted for display, so changing the site
  timezone changes what the screen shows and nothing about which rows a window
  contains.
• Upgrading deletes crawler log rows written before that column existed. Their
  original instants cannot be reconstructed – a repeated-hour reading maps to
  two, and the site’s timezone at the time of the visit is not recorded – so
  they are removed rather than given an invented offset. Crawler measurements
  only: posts, settings, registry data and the plugin’s other tables are
  untouched, and this is not uninstall. Until the migration completes the module
  records nothing, runs no cleanup and reports zero, rather than writing rows
  with no canonical instant.
• The cleanup event and the settings keys were created by 1.0.0 and are reused
  unchanged.

1.0.0

• Initial release: plugin foundation.
• Plugin header, constants and Composer PSR-4 autoloading, with a missing
  autoloader degrading to an admin notice instead of a fatal error.
• Activation creates the crawler log, answer density and citations tables via
  dbDelta(), seeds the default settings without overwriting an existing
  configuration, schedules the daily log cleanup and six-hourly density scan,
  and flushes rewrite rules.
• Deactivation clears the scheduled events and flushes rewrite rules, keeping
  all data.
• Uninstall removes every aive_ prefixed table, option, transient and scheduled
  event, after verifying that WordPress is uninstalling this plugin.
• Schema versioning, so a plugin updated by overwriting files still migrates.
• AI crawler registry covering 18 publisher-verified search, assistant and
  training crawler tokens, 13 of them detectable from the User-Agent header and
  5 carried for their robots.txt rule alone. Extensible through the
  aive_crawler_list filter.
• Shared utilities: settings access, AI Client API detection, crawler matching,
  multilingual question detection for English, Chinese, Japanese and German,
  HTML fragment parsing and debug logging.