EPS
← All docs·Activity

Daily — 2026-05-28 (#390 +

updated: 2026-05-28

What happened

  • #390 promoted → completed (MODERATE). Clean-result: refusal-style negatives install a persona gate that generalises across 9 of 11 OOD eval framings as a verbatim one-line refusal substitution. Two user-directed body reframes landed yesterday; promoted today 06:41Z.
  • #391 promoted → completed (LOW). Clean-result: could not selectively implant sycophancy on Qwen2.5-7B-Instruct — training lifts the trained source and 23 bystander personas in lockstep, with four probable design-level confounds. Promoted today 04:00Z.
  • #398 (awaiting_promotion) — amendment cycle: v3 added the on-policy per-position probe finding (peak-histogram sub-bullet), interp-critic REVISE on a systematic end-position issue → v4 surgical fix → interp-critic PASS.
  • #397 (running) — round 12: factor-screen dispatcher READY-FOR-REVIEW → code-reviewer PASS (trunk tier) → two-pass sweep launched (Pass 1 HF train+logprob across all cells with one teardown, Pass 2 vLLM-once with LoRA).
  • #404 (running) — clarifier v2 PASS (design locked via 2026-05-27 ideation) → adversarial-planner Phase 2 (3 lenses × Claude+Codex twins, 2 reconcilers) → plan v1 approved inline → launched first; #414 will consume its adapters via HF URLs.
  • #406 (running) — clarifier locked → adversarial planning → consistency PASS (does JS divergence between context transformations predict SFT generalization across them).
  • #407 (blocked) — pod-407 (4× H100) Phase 0 hit K1 candidate-pool exhaustion (failure_class: data); re-launched with 4× pool (N_RAW 200→800, N_FILTERED 50→200). Currently blocked.
  • #411 (interpreting) — clarifier all-clear → plan v1 approved at plan_pending → workflow-improver landed the fix for the codex-critic no-show pattern observed during the run.
  • #415 (awaiting_promotion) — inline symmetric-baseline rerun complete; all 4 predictors null (corroborates #396); awaiting promotion.

Proposed workflow improvements

  1. Target: .claude/agents/analyzer.mdwhat: extend the MDX-safety body rule (currently <https://...> only) to also forbid < immediately followed by a digit (p<0.05, n<10, <24 personas) in clean-result prose; write p < 0.05 with surrounding spaces, or backtick the token. Why: Same MDX-parse class recurred TODAY. The morning fix e93f6819 ("block <https://...> autolinks", 10:50 PT) blocked one trigger; hours later a body still broke the dashboard renderer — Thomas: "Fix the markdown I'm getting this error: Error parsing markdown: Unexpected character 0 (U+0030) before name, expected a character that can start a name…" (sessions d74fa6f8, 5b38d51d). That error is < + digit parsed as a JSX tag — the existing check 14 (check_mdx_safe_urls) only catches <https?://. Proposed edit: (doc rule in analyzer.md; mechanical enforcement is workflow-improver's job after greenlight — extend check_mdx_safe_urls in scripts/verify_task_body.py to also match <\d)
    + - **MDX safety (extends the `<https://...>` rule):** never emit `<`
    +   immediately followed by a digit in body prose (`p<0.05`, `n<10`, `<24`).
    +   The dashboard's MDX renderer parses `<0` as a JSX tag and errors
    +   ("Unexpected character `0` (U+0030) before name"). Write `p < 0.05` with
    +   surrounding spaces, or wrap the token in backticks. Code/fenced blocks
    +   are exempt, same as check 14.
    

My thoughts

Highlighted results

  • #390 — Refusal-style negatives install a persona gate that generalises across 9 of 11 OOD eval framings as a verbatim one-line refusal substitution (MODERATE confidence)
  • #391 — Could not selectively implant sycophancy on Qwen2.5-7B-Instruct: training lifts the trained source and 23 bystander personas in lockstep, with four probable design-level confounds (LOW confidence)