/decisions · 2026-07-26 · ops · behavior-critic

/behavior-critic — scope + activation

Notion task 3a9f7d49-36d1-819b-bd51-d5972fa53d69 · New source-BLIND critic (runs/clicks/calls the artifact instead of reading it) closing the gap the openclaw/autoreview teardown named. Build complete 2026-07-26; not yet activated on any live gate.

Ray built ~/.claude/skills/behavior-critic/SKILL.md — a fresh-eyes critic that exercises a produced artifact (runs a script, clicks a form, calls an endpoint) against a written behavior contract, instead of reading the artifact's source like every other RDCO critic does. Tested against 6 fixtures: the 4 exercisable via `cli`/`api` (3 flawed + 1 clean) all scored correctly with zero false approves and zero rounding-up. The 2 `web-interactive` fixtures hit a real Playwright browser-lock contention issue and correctly refused to fabricate a verdict rather than guess — the discipline held, but that class isn't yet proven end-to-end. Dormant — same posture as /supervise and /verify-action — pending this decision.

What was built

Rubric covering 3 artifact classes: cli (run it), web-interactive (Playwright click-through), api (curl/call it) — a 4th class, other, requires the producer to specify a concrete exercise method
Behavior-contract shape (given-when-then, observable outcomes only — explicitly not spec or rubric language)
6 test fixtures (4 flawed + 2 clean controls) — full results in ~/.claude/skills/behavior-critic/test-results-2026-07-26.md, including real fixture scripts/pages under test-fixtures/ that were actually run/clicked, not just described
Schema-consistent audit log writer (behavior-critic-log-append.py) — functional now, independent of any hook
Explicit "Known gaps" section naming 4 artifact classes intentionally NOT covered by v1 (video overlays, PDF interactive elements, Notion automations, iOS app UI)

Test results: 3 of 3 deliberately-flawed cli/api fixtures caught (silent-success-on-missing-file, silent-success-on-empty-file, 200-with-empty-body-treated-as-fail) with zero false approves; the clean cli control passed all 3 clauses. The 2 web-interactive fixtures could not be exercised in this session — a shared Playwright Chrome profile was locked by a concurrent process on the Mac Mini across 4 dispatch attempts — but every attempt correctly returned NEED-MORE-INFO rather than a fabricated verdict, which is itself evidence the rubric's core discipline (never infer from source, never round up) holds under a real failure condition.

Three questions this decision needs to answer

(a) Does the artifact-class scope (cli / web-interactive / api only, v1) match your priority — or should one of the "Known gaps" classes (video click-overlays, PDF interactive elements, Notion automations, iOS/Squarely UI via xcodebuildmcp) get built next instead of, or before, hardening the three already-built?
(b) Should the web-interactive exercise method get a real end-to-end retest (once the Playwright browser contention clears) before this skill is trusted on-demand for landing-page/form work — or is the cli/api validation sufficient to start using it now, with web-interactive validated opportunistically?
(c) Should this skill get a wired gate at all yet? The proposed first candidate is the publish-site deploy step, but unlike /supervise's ready-to-splice Gmail-draft hook, no exact matcher command was picked — RDCO's publish paths vary (quick-sites wrapper / wrangler / R2 upload) enough that this needs your call on which one to gate, or whether on-demand invocation is enough for now.

Full detail is in the Notion task's Notes field (BUILD UPDATE, 2026-07-26).

Lock in

Approve

Activate as-usable-on-demand now: keep v1 scope (cli/web-interactive/api), no wired gate yet, retest web-interactive opportunistically. Add context / answers to (a)(b)(c) if you want to adjust anything.

Approve + send