Skip to content

Taste Review Publishing

Nick Hamze edited this page Sep 4, 2026 · 1 revision

OpenStation taste review — publishing

Decision

  • Verdict: ship for local candidate documentation, not general-availability certification.
  • Winner: the bounded publishing-review panel with dark-theme diff colours and confirmation controls above the comparison.
  • Intended context: a real managed-site OpenStation window and the consumer README at native and thumbnail sizes.
  • Confidence: medium. Runtime evidence and automated checks are available, but the implementing agent performed the review; this is not an independent panel or human approval.

Why this wins

The destination and action now sit on the same inset as the site identity. One visible confirmation button makes the next step clear without searching below a long source comparison. The restrained red/green surfaces belong to the desktop's dark palette, and the text is legible instead of washing out against Core's default light diff backgrounds. Those alignment and value-contrast decisions matter more here than added decoration.

Protect

Keep the complete native window frame, explicit site identity, bounded width, truthful source comparison and explicit confirmation. Long content must scroll normally rather than shrink into unreadable text or be hidden without disclosure.

Refine

  1. Obtain a human review and repeat on the chosen public-host pilot before promoting these as launch screenshots.
  2. The source diff is intentionally technical. A future visual preview should supplement it without implying that Fleet is the Gutenberg editor.

Panel evidence

These are distinct review lenses applied by one agent. Their independence is limited because that agent implemented the changes.

  • First impression: site name, “Review before saving,” destination and confirmation form a clear vertical sequence. The previous light diff blocks overwhelmed the quiet header.
  • Blind pairwise comparison: a randomized, neutral-labelled before/after thumbnail sheet preferred Option A for readable diff colours, shared insets and an immediately visible action. Revealing the key identified A as the revised runtime. Familiarity with the implementation limits the blinding; no independent preference experiment is claimed.
  • System coherence: the review uses the same native buttons, typography, dark palette and 880px content boundary as the editor and site header. No second title bar or ornamental dashboard shell was introduced.
  • Adversarial critique: a primary button above a diff can encourage premature confirmation. The destination/status/time remain before that button, the comparison immediately follows, and the explanatory copy tells the user to check the right site. This is a usability tradeoff, not proof of error prevention.
  • Context proof: the actual 1000px-wide runtime screenshot, 640px-wide comparison thumbnail and ten-capture contact sheet were inspected. The frame and key action remain visible. Long diff content extends below the viewport and scrolls; it was not composited or compressed. Scoped axe WCAG A/AA checks include the review, alongside existing hub/site checks; the final 28-test suite passed.
  • Meaningful disagreement: moving controls upward sacrifices the “read to the end before action” sequence. The director chooses discoverability in a scrolling tool, with explicit destination review and a server-verified confirmation boundary. Human feedback is still needed.

Objective blockers

The first capture had a real contrast failure: Core's light diff colours combined with inherited light text. More-specific Fleet-scoped rules now use theme-aware backgrounds and text, including inline additions/deletions. The revised inspected view has no observed blocking clipping; automated accessibility checks passed on the tested review. This does not certify all themes, viewports or source sizes.

Evidence and provenance

  • Fleet 0.9.0-rc.1; OpenStation trunk 9bac9176b26a6228e3e57c9a7c8f11f586063afd; WordPress 7.1.
  • Ten runtime captures in assets/screenshots/, now including publishing-review.jpg in the README.
  • CSS SHA-256: 26a2d62db28f27e73513f870821d17dd2e8d0e4fb0584525caca864c05bf1938.
  • JavaScript SHA-256: 38995b5a80e85b8b20c9c7e78900ca02dd181ac49fa789591e3ff67085744e5a.
  • Capture script checks fetched assets against the working tree. It exercises the review without confirming a write, then explicitly discards the proposed source. No credential/callback captures are included.
  • Reference ladder is provisional: the existing native editor, site header and two-window screenshot are north-star examples; the compact candidate captures are the acceptable baseline; washed-out diffs, mismatched panel insets and full-width windows are anti-examples. No new human-approved/rejected pair has been supplied.
  • See Modern Core and publishing for implementation and test evidence. The earlier visual review describes the previous nine-capture state and remains historical evidence.

Calibration record

  • Human choice: no choice supplied for this revision.
  • Human reason: prior requests called for OpenStation-native windows, bounded width and aligned buttons.
  • Rejected alternatives: default light diff colours inside the dark app, wider review content than the site header, and confirmation below a long comparison.
  • Agent recommendation: use the revised authentic captures for the candidate README; retain public-host and human-review launch gates.
  • Override: no new human override.
  • Reference examples to add or retire: add the aligned dark-theme review; retire the washed-out comparison from documentation, retaining it only as defect evidence.

Clone this wiki locally