Skip to content

[feat] Make prompt rewriting a verifiable contract, not an injected suggestion #81

Description

@wimaan3

Problem / motivation

The Maintainer observed that prompt rewriting doesn't appear to be in effect during real sessions. Investigation confirmed the mechanism fires (the UserPromptSubmit hook injects the directive on every prompt) but the observable contract — "show the improved prompt, propose it, ask to confirm" — is inconsistently honored by the wrapped agent, especially deep into long sessions.

Root cause: the current design is injection-only. SPEC-prompt-rewrite.md says "borromeanRings enforces that the rewrite happens" — but nothing verifies it happened. A directive competing against the agent's other context (including autonomy guidance that discourages ask-to-confirm ceremony) decays. This is the exact failure mode borromeanRings exists to eliminate: a standard that is a suggestion, not a gate.

Two mechanical bugs were also found and are being fixed separately (hooks-hygiene PR):

  • the hook double-fires when both the project and global (install-global.sh) registrations are active;
  • unbounded cat stdin reads can hang hook processes (orphaned shells).

This issue tracks the remaining design gap: making the rewrite contract verifiable.

Proposed direction

  1. Cheapen the contract so it survives (being done in the hooks PR): replace heavy show-and-confirm with a mandatory one-line Reading this as: <sharpened intent> on non-trivial prompts; confirm-first reserved for irreversible/scope-changing actions. Cheap rituals get followed; expensive ones get rationalized away.
  2. Verify it (this issue's core): explore a deterministic check — e.g., the Stop gate (or a transcript-side check) asserting that when the directive fired on a non-trivial prompt, the agent's response opens with the rewrite marker. Failures become visible (receipt) rather than silent.
  3. Honest spec: SPEC-prompt-rewrite.md should describe what is enforced vs. requested, and reference the verification mechanism once it exists.

The hard parts

  • Defining "non-trivial prompt" deterministically (length? command-vs-question heuristics? opt-out marker?).
  • Hook access to the response/transcript for verification (substrate-dependent; keep the adapter thin, logic in tested Python).
  • Avoiding ceremony that fights legitimate agent autonomy — the contract must be cheap for the agent and high-signal for the human.

Alternatives considered

  • Leave it as guidance — rejected: contradicts the manifesto ("standards become gates, not suggestions") and the spec's own claim.
  • Have the hook rewrite the prompt itself (no agent involvement) — rejected by ADR-0011: the agent performs the rewrite; borromeanRings enforces the process (agent-autonomy red line).

Fit with the roadmap

Quality/enforcement work on an existing shipped feature (ADR-0011). Small, contained; natural follow-up to the hooks-hygiene PR. Relates to the failures-become-checks principle.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestharness-featureA borromeo meta-harness capabilityqualityEngineering rigor: tests, lint, verification

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions