Skip to content

Model-free A/B: hook-plus-idle DING versus aggressive delivery #57

Description

@myobie

Goal

Prove, first with a hermetic model-free A/B, that optional hook-plus-idle DING preserves durable eventual delivery while eliminating unsafe terminal input. Track a separately authorized real Codex+Claude acceptance only after the generic PTY event API and provider adapters exist.

Authoritative A/B

  • A — aggressive control: current unconfigured DING behavior, including aggressive PTY delivery, fresh-DND suppression, and FIFO resumption.
  • B — rich configured path: provider-owned post-turn hook plus a harness-neutral fresh-idle PTY adapter selected as an external command through a generic protocol.

B must match A on durable eventual delivery, FIFO ownership, zero message loss, zero duplicates, and zero additional model calls while reducing active-turn PTY input collisions and terminal corruption to zero.

Delivery rules for B:

  1. The configured post-turn hook checks the durable inbox after a turn and injects unread work into the next harness context.
  2. Ordinary PTY input is authorized only by an explicit fresh exact-idle observation bound to the same live runtime incarnation and launch generation, plus generic PTY input-quiet/no-human-draft evidence.
  3. Fresh idle alone is insufficient while a person is typing or has a pending draft.
  4. A supervisor may use explicit PTY input for exceptional intervention. This project adds no automated mid-turn interruption protocol.
  5. A fresh idle authorizes at most one bounded wake attempt, not a positive harness receipt; staged ownership and post-submit receipt stay fail-closed.

For B, active, child_command, unknown, stale data, unreachable/malformed/timed-out/nonzero adapters, incarnation mismatch, generation change, compaction, clear, crash, socket loss, recent human input, or a pending human draft all hold the durable message without DING PTY input.

ASCII screens, titles, elapsed time, presence, attached clients, terminal modes, and JSONL tails are diagnostics only—never idle or input-quiet authority. Core DING remains harness-neutral. Provider commands may differ; core st2 and shared judges must not branch on provider identity. Exact external-command selection syntax and payload remain owned by st2#111.

Required A/B cases

  • arrival while idle;
  • arrival during an active turn;
  • long-running child command;
  • DND hold and release;
  • stale or unknown adapter authority;
  • post-turn hook failure;
  • crash and daemon restart/generation change;
  • compaction and clear;
  • FIFO burst; and
  • identical Codex/Claude fixture semantics.

The active-turn B case writes zero PTY bytes and delivers through the next hook context. The idle B case may write exactly one bounded wake. Every case hashes durable messages and records delivery count/order, PTY bytes, collision/corruption outcome, and model-call count.

Human-input quietness cases

The B authorization matrix must cover:

  • recent key input;
  • partial command/draft;
  • pasted text;
  • alternate-screen input;
  • attached but non-typing viewer;
  • DING-origin input versus explicit supervisor-origin input.

Exact evidence fields, freshness, origin encoding, and draft detection must be coordinated with PTY #129 and st2 #111. Evals records required evidence and outcomes but does not invent the interface.

Dependencies

  • compoundingtech/pty#129: generation-bound live activity plus the generic input-quiet/draft/origin evidence needed by the A/B. Exact fields remain pending owner design.
  • compoundingtech/pty#130: alternate-screen and slave-input diagnostics. Unsupported input state remains unknown; diagnostics are not an idle oracle.
  • compoundingtech/st2#111: external adapter-command selection, generic event envelope, timeout/error and DND precedence, post-turn backstop, input origin, and core-neutral decision/receipt behavior.
  • Immutable, owner-reviewed Codex and Claude hook plus session-event/JSONL fixture schemas with provenance.

Proposed model-free cells

  1. Preserve presence-ding-matrix unchanged as the plain aggressive regression oracle.
  2. ding-delivery-a-aggressive-control: deterministic A workload and delivery/collision receipts.
  3. ding-delivery-b-hook-idle: the matched B workload; explicit active-turn zero-byte/next-hook delivery and idle one-wake behavior.
  4. ding-adapter-codex-matrix: fixed real Codex activity and post-turn-hook fixtures normalize into provider-neutral traces/outcomes.
  5. ding-adapter-claude-matrix: identical case IDs, judges, and generic outcomes from fixed real Claude fixtures.
  6. ding-adapter-restart-continuity: inbox/FIFO durability across sidecar restart, adapter epoch replacement, PTY crash, and daemon generation change.
  7. ding-core-neutrality: black-box parity across declared adapters plus a product-side source/architecture receipt proving no provider-specific decision exists in core DING or shared judges.
  8. ding-delivery-ab-report: compares A/B receipts and fails unless durability/model-call parity holds and B has zero active-turn collision/corruption.

The seam-independent scaffold cell ding-adapter-fixture-contract validates only hashes, provenance, matched A/B case inventory, generic provider slots, diagnostics, and named dependencies.

Future isolated real-pane acceptance

After exact PTY/st2 APIs and immutable provider adapters land, publish a separate proposal before execution containing:

  • exact Codex and Claude versions/models/accounts and immutable artifact provenance;
  • exact call/token/cost ceiling;
  • isolated catalogs/workspaces and no unrelated fleet impact;
  • stop conditions, cleanup verification, and rollback;
  • matched A/B tasks and held-out outcomes; and
  • separate execution authorization.

No real-provider run is authorized by this issue or scaffold. Provider-event coverage gaps return to adapter/product owners and never justify harness parsing in core st2.

Fixture provenance inventory

Shared fixed PTY ASCII/mode diagnostics:

  • active turn, idle prompt, long child, alternate screen, raw/noncanonical mode, terminal restore, compaction, clear, and crash.

Shared post-turn hook semantics:

  • unread work enters the next context;
  • multiple unread messages retain FIFO order;
  • an empty inbox injects nothing; and
  • hook failure leaves unread work durable.

Provider fixtures use identical case manifests. Each file must record source product, schema/version, capture or synthetic-derivation method, redaction review, content hash, owner, and generic expected trace/outcome. No guessed event names or fields are admitted.

Model-free acceptance

  • A and B deliver the same durable workload exactly once in FIFO order with zero additional model calls.
  • Active-turn B writes zero PTY bytes and later delivers through the next hook context.
  • Idle B attempts exactly one bounded wake only when exact-idle and generic human-input quiet/no-draft evidence both authorize it.
  • B produces zero active-turn input collisions and terminal corruption.
  • The no-adapter A baseline remains aggressive.
  • Inbox body/hash and unread/archive ownership survive every hold, hook failure, crash, and restart.
  • Declared provider fixtures normalize to identical generic traces and hook outcomes; shared judges do not branch on provider identity.
  • Fixed ASCII/mode fixtures are observable but cannot authorize idle or input quietness.
  • All cells leave zero PTY/task/adapter residue.
  • New cells contain zero model agents/provider commands, receive model-free harness exclusions, pass fixture-reset/preflight/KDL/schema gates, regenerate the catalog, and pass bin/check-corpus.sh against exact pinned local binaries.

Implementation guard

The provenance inventory and hermetic skeleton may land before product seams. Product-dependent assertions remain held until exact PTY and st2 source commits, APIs, immutable provider fixtures, and independent review receipts are available. Real-pane/provider execution additionally requires a reviewed cost/rollback proposal and separate authorization. Do not run models, providers, accounts, deployments, or network-dependent tests; do not invent the unfinished interface.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions