Files
wyndham-ARR/.project-docs/60-reflection/cases/2026-08-11-technical-surfaces-need-explicit-entry-controls.md
2026-08-11 17:23:33 +08:00

1.8 KiB

Reflection: Technical Surfaces Need Explicit Entry Controls

Trigger

The user corrected the production Daily interaction: clicking a concrete business row unexpectedly opened the full technical task log, even though a named 任务日志 utility already existed in the header.

Expected Behavior

Inspecting business data should be inert unless a cell exposes a clear business action. Dense diagnostic material should appear only after an explicit, accurately named user action.

Actual Behavior

Every Daily row was visually and semantically a hidden log button. Mouse click, Enter and Space opened the dialog, so the same technical surface had both a deliberate header entry and an implicit whole-row entry.

Root Cause

  • A convenient job-selection interaction was conflated with permission to reveal diagnostic detail.
  • Handler removal alone had not been treated as enough; row role, focusability, cursor and selected styling also encoded the obsolete action.
  • Earlier acceptance covered the special needs-review button but did not assert that all ordinary rows were inert.

Lesson

When a product has a dedicated diagnostic control, make it the sole opener unless row-level diagnostics are an explicit requirement. A behavior change is complete only when event handlers, keyboard paths, accessibility semantics, visual affordances and regression tests all agree.

Action

  • Keep Daily rows informational and retain only explicit download/review controls inside them.
  • Assert that the named header utility is the only task-log opener.
  • Verify ordinary row, business-action and diagnostic-entry clicks separately in browser acceptance.

Promotion

Promoted to project success criteria, current state, focused static UI contracts and the 2026-08-11 interaction evidence.