fix(code): check responsive QA fixture parity

CHANGELOG.md

@@ -4,6 +4,11 @@ All notable changes to the claude-plugins project will be documented in this fil
 
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/). Entries are listed newest-first; each plugin section is treated as released when merged to `main`.
 
+### code v1.16.1
+
+#### Changed
+- `guided-manual-qa` compares rendered columns, measured container width, and responsive mode with a comparable reference when data changes layout, and requires representative disposable fixtures before presenting the human checkpoint.
+
 ### code v1.16.0
 
 #### Added

plugins/code/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "code",
   "description": "Code and planning framework plugin",
-  "version": "1.16.0",
+  "version": "1.16.1",
   "author": {
     "name": "ClosedLoop",
     "email": "support@closedloop.ai"

plugins/code/skills/guided-manual-qa/SKILL.md

@@ -60,7 +60,7 @@ Do not turn a plausible expectation into a human checkpoint. Before presenting e
 1. **Surface ownership:** identify the exact route, mode, renderer, or variant under test and prove that it owns the asserted element or behavior. Do not extrapolate from a sibling surface merely because it renders the same entity or concept. List/detail, free-text/faceted search, web/desktop, and display/editor variants may intentionally differ.
    For a prototype route, also name the exact code that implements the assertion and its proven production or Storybook importer. If only the prototype route or fixture owns it, mark the prototype checkpoint `NOT APPLICABLE` and route the requirement to an eligible owner or record the coverage gap.
 2. **Contract evidence:** anchor each pass/fail expectation to an exact, applicable acceptance criterion, approved PRD or plan clause, or direct operator ruling. Record its identifier/version and explain why it governs this route and variant. Code, tests, design notes, and internal QA matrices can prove behavior or suggest a diagnostic, but cannot add a product obligation. Label any conclusion that requires interpretation as an inference; do not silently turn it into an acceptance gate. When sources disagree, resolve the disagreement before involving the human. A feature map's reach and expected-behavior prose (for example a repository `FEATURE_MAP.md`, especially entries marked as unreviewed drafts) is corroborating evidence, not a requirement. When a checkpoint shows the map is wrong, record it in the QA record as map drift for the map's owner, not as a product `FAIL`.
-3. **Fixture reachability:** prove the named fixture reaches that exact path with the required projection, flags, permissions, and state. A row existing in storage is insufficient when the tested surface reads a different index, projection, cache, or adapter.
+3. **Fixture reachability:** prove the named fixture reaches that exact path with the required projection, flags, permissions, and state. A row existing in storage is insufficient when the tested surface reads a different index, projection, cache, or adapter. When responsive layout depends on data-driven column visibility or intrinsic width, compare the effective rendered columns, measured container width, and selected layout mode in the local fixture and any reference at a comparable viewport. Use representative disposable data; a different layout mode is a different checkpoint, not proof of the reference mode.
 4. **Population effects:** account for persisted filters, default toggles, hierarchy/context rows, grouping, pagination, and non-applicable entity types before stating an exact count or membership expectation. Prefer an independent read-only probe for exact populations.
 5. **Applicability:** if the surface intentionally does not render the asserted field or interaction, mark that claim `NOT APPLICABLE` and move the checkpoint to the surface that owns it. Absence by design is neither a pass nor a product failure for the misplaced assertion.
 6. **Agent dry run:** when the repository declares a verification protocol (for example a `pnpm control` command set), drive the checkpoint yourself on the same stack before presenting it. Enter through the entry point the requirement names (for example its feature-map id and route or hash when the repository keeps a feature map), not a convenient one. Capture the action and the resulting state. After a write, add a read-only second view of the stored value (for example `pnpm control api GET <path>`). Run a writing dry run only on disposable data, and reset that data before the human's run. If your run does not show the expected result, settle it as a setup problem, an oracle problem, or a candidate finding before involving the human. If this entry point was already captured on this head, link that capture instead of repeating it. If the protocol cannot reach the entry point, record why. Record the run as `agent-observed`.