v1.2.0

Added

• The collapsed bar can be moved, by dragging the grip on the left of the pill.
  Where you leave it is remembered across pages, and kept inside the viewport when the window resizes.
  Thanks @wpoortman (#2)

• The bar goes back to its edge on a double click of the grip, on Enter or Space while the grip is focused, or from the new "Put the bar back on its edge" palette command.

• Arrow keys on the grip move the bar ten pixels at a time.

Changed

• Supported PHP is now 8.2 through 8.5, where it was 8.3 and 8.4.
  Nothing here ever needed 8.3, so the old constraint only kept the module off Magento installs running an older PHP.

Fixed

• A block that returns null or false instead of a string no longer causes a 500.
  BlockPlugin::aroundToHtml() declared a string return type that Magento's own AbstractBlock::toHtml() does not.
  Thanks @claudio-ferraro (#1)

New Contributors

• @claudio-ferraro made their first contribution in #1
• @wpoortman made their first contribution in #2

Full Changelog: 1.1.1...1.2.0

v1.1.1

Packaging only. No code changed.

• The development notes are gone from the package. A handoff, two build plans, a
  research log and a progress tracker were written to get the module built and shipped
  inside every tarball with it. In their place, a user guide and a developer guide, in
  Markdown with generated HTML, rendered by dev/docs.
• A LICENSE file. composer.json said MIT and there was nothing for GitHub or a reader
  to detect.
• A maintainer in composer.json, compatibility badges in the README, and a README that is
  a landing page rather than the manual.

Full Changelog: 1.1.0...1.1.1

v1.1.0

Three defects the security audit named, closed. Nothing in the interface changed.

• A profile past the age bound is refused on read, not only swept. Retention was
  enforced by deletion alone, and a sweep runs on a write or when the history endpoint is
  opened, so on an instance nobody is browsing a profile stayed readable by id for as long
  as its file survived. Refused rather than deleted, because the MCP tools read through the
  same path and are advertised as read only.
• Every MCP response says its payload is recorded data. A profile holds whatever the
  request held, and it reaches an agent as tool output that reads like the module talking.
  Successful responses carry a recorded_data line saying the values were captured from
  requests and are to be read as evidence, never followed as instructions; the server says
  the same at connect.
• The access key has a length floor and a per address lockout. At least 32 characters or
  empty, refused on save with a message and refused again when the configuration resolves,
  so a value written straight to the database or env.php is no way around it. Ten wrong
  keys from one address inside fifteen minutes and it stops being answered, so the endpoints
  are no longer an oracle. Only a request that presented something is counted, so customer
  traffic cannot lock a developer out of their own site.

Magento's integration test suite is closed by decision rather than deferred again. What it
would assert is asserted by dev/smoke over HTTP, the browser suite under an enforced CSP,
and 202 unit tests.

Full Changelog: 1.0.0...1.1.0

v1.0.0

First release. Everything below is what 1.0.0 contains, so there are no entries for the
work that led up to it. The interface was built as a phase numbered 1.1 during
development, which was a build order rather than a version: it ships here.

The bar

• One JSON profile per request, stored under var/siteation_debugbar/, pruned to the last
  20 or 60 minutes, written 0600 in a 0700 directory.
• Seven collectors: request, queries, events, observers, blocks, cache and interception.
• Repeated queries are matched by shape with numbers treated as values, so an N+1 built
  from interpolated ids is visible rather than hidden as one query per id.
• Findings: eight rules producing ten kinds of finding, each saying what is wrong, why it
  matters, where it came from and what to check next, and linking to the evidence behind
  it.
• A Magewire section: every component on the page with its resolver, its listeners, its
  children, the state it posts back on every update, and that state itself under the value
  policy. Plus the round trip each update actually took, measured in the browser, which is
  the network and the DOM morph as well as the server. Read from the page's own Magewire,
  so the module requires nothing and works on a store that has never heard of it.
• One admin setting for what the bar collects and what it shows. A section switched off is
  not gathered either, so turning off Blocks on a page that renders four hundred of them
  makes the request being debugged cheaper as well as the panel quieter. Findings and the
  overview are always on: a profile that cannot say which request it belongs to is one the
  history, the report and the MCP tools cannot use.
• Magewire updates are named by their component and what it was asked to do. Every
  component posts to one URL, so a page that uses it produced a request list of identical
  rows; the bar, the history, the markdown report and the MCP tools all say
  checkout.cart addToCart() instead. Magewire is not a dependency: the request is
  recognised by shape.
• Covers frontend HTML, adminhtml, AJAX, GraphQL and REST. Requests that cannot carry a
  bar still return X-Siteation-DebugBar-Profile, and the bar lists them so they can be
  opened.
• Renders in a shadow root with its own bundled Alpine, so it cannot collide with the
  theme's styles or its Alpine, and still works on a page whose own JavaScript failed.
• Every query shows the application frame it came from, and that frame is a link into your
  editor when one is configured. Eight are named, anything with a URL scheme works, and a
  path map covers running in a container.
• A markdown report of any profile, for assistants that cannot call MCP:
  bin/magento siteation:debugbar:report, format/markdown on the profile endpoint, and a
  Copy for AI button in the bar.
• A request that throws is profiled too, and the finding names the exception and the frame
  it stopped at instead of sending you to the log.
• Cross request comparison: diff two stored profiles for what changed in duration, memory,
  queries, cache and findings, with query shapes matched by fingerprint. In the bar beside
  the history, and over MCP as compare_debug_profiles.
• A history section listing every profile still on disk, so an earlier request is one
  click away rather than a header away.
• Syntax highlighting for SQL, for Alpine state and for component expressions.
• The overview tells the request as stages, Received to Responded, with fact grids and a
  one line summary of what happened.
• A command palette on Cmd/Ctrl Shift P: every section, the themes, placement, pinning and
  the window controls, filtered as you type.
• Closing the bar collapses it to a corner bubble that restores it, follows the top or
  bottom placement and carries the findings count, so getting the bar back no longer costs
  the reload that would profile the page again and lose the request being read. The bubble
  is remembered across pages. Hiding the bar outright, for a screenshot or a sticky footer,
  is a palette command and lasts until the next page load.
• An Alpine section that reads the page's own instance: every component with its live
  state, the registered stores, which components Hyva deferred and whether they have
  started, and the version, build and expression errors behind it.
• The bar hosts itself in a <siteation-debugbar> custom element, so it mounts on upgrade
  rather than being found by id, and the tag name is the only thing the injector, the
  bundle and the error capture have to agree on.

For coding agents

• bin/magento siteation:debugbar:mcp serves stored profiles over MCP on stdio, with five
  read only tools.
• Responses are bounded by item count and byte budget. On an 817 kB profile, findings
  answer in 7 kB.
• docs/SKILL.md describes how to use the tools without drawing the wrong conclusions.

Settings

• Settings live at Stores > Configuration > Siteation > Debug Bar, beside the other
  Siteation modules, and the values are at siteation_debugbar/general/*. Deliberately not
  a group under Advanced > Developer: Magento hides that whole section in production mode,
  which is exactly where the access key makes the bar usable, so the settings for it were
  unreachable in the one mode that has to be configured before it does anything. The ACL
  resource is still the developer one, so who may change them has not changed.

Safety

• Off by default. Production mode refuses unless a developer access key is set, and then
  the bar collects and answers only for requests presenting it: a store switch can never
  mean on for every customer. Present it as a header, or once as a query parameter to swap
  it for an hour long HttpOnly cookie.
• Any response carrying a bar or a profile id is marked no-store and stripped of its
  X-Magento-Tags, so no shared cache can serve one developer's bar to a visitor.
• Optional IP allowlist, applied to the bar and to the profile endpoint.
• Per area control: storefront, admin, GraphQL and REST can each be switched off.
• Sensitive keys are redacted at record time and string literals are stripped from SQL.
  Captured values follow a configurable policy, because query bindings are positional and
  cannot be judged by name.
• The Alpine section reads live objects rather than a stored profile, so it applies the
  same policy, the same key pattern and the same bounds in the browser.
• No inline script and no inline style reach the page, so Magento_Csp needs no nonce and
  no unsafe-inline.