Spec 083 frame evidence: conversation-scan under-fires for flow-style owners

[PinkException]

Field report against spec 083 — Capturing decisions settled mid-session
(IN_PROGRESS). Posting as an issue rather than a PR because 083's frontmatter
carries frame_review: true — "Phase 2 widens the load-bearing premise (recall
vs scan) — frame-critique the new premise before READY_FOR_REVIEW (ADR-0020)" —
and this is evidence bearing on exactly that premise. It's yours to weigh, not
mine to pre-empt.

Reported from a live session on a downstream scaffolded project
(project-dashboard), 2026-07-16, owner in permission mode Auto. Upstream
files confirmed identical to the scaffolded copy that failed — the markers at
decision_scan.py:41-42 match byte-for-byte.

What happened

I said, verbatim: "It's too long for laptop views...."

That's a UI decision superseding the 1100px cap chosen in that project's slice
012-01. That project's refinement-todo.md even names the trigger explicitly:
"Resolution trigger: Owner tunes the value in-browser against the live data."
The trigger fired. The agent changed --card-cap: 1100px → 720px.

Contents of .jig/decision-scratch/<session>.log afterwards, in full:

{"quote": "How hard should the guardrail be on ad-hoc edits to this project's source (public/, src/)? Enforcement Hard block ...", "source": "askuserquestion", "who": "user"}
{"quote": "How hard should the guardrail be on ad-hoc edits to this project's source (public/, src/)? Enforcement Hard block ...", "source": "askuserquestion", "who": "user"}

Two identical entries, both quoting the agent's own question, which I
dismissed. My actual decision was never captured. Neither was the code change
that encoded it.

The part I'd most like you to look at

Not the regex gap — the selection bias. Tier 1 (AskUserQuestion) is the
only high-precision tier, and it fires only when the agent opens a formal
dialog. An owner who works in flow and dismisses those dialogs generates ~zero
Tier-1 events. So capture is weakest for exactly the owners who most need it, and
the log fills with the questions they rejected. That's the observed outcome above,
and I don't think it's specific to me.

The Tier-2 net (decision_scan.py:38-45) is five regexes — should not,
instead, actually, override…default, reverse…default. Natural owner
phrasing — "it's too long for laptop views", "make the cards shorter",
"that's too big", "no, smaller" — matches nothing. The comment at :36-38
argues actually is high-signal, and I think that's right; the failure mode
here isn't false positives, it's the false-negative floor, which is currently
unmeasured.

Third, capture never writes: jig-decision-capture.sh surfaces candidates as
additionalContext and says so explicitly ("it never writes a decision
itself"). Persistence depends on the agent attending at Stop. In this session it
didn't.

A direction — with the objection I can't answer

The obvious move is to stop asking the conversation whether a decision happened
and ask the diff instead: a PostToolUse trigger on Edit|Write|MultiEdit
that appends a stub with source: "code-change". Durability would come free from
083-07, which already re-surfaces un-recorded stubs until something covering them
is written down — so the nag targets the agent and the owner sees nothing new.
append_stub's signature already takes an arbitrary source.

But I don't think that survives its own argument, as stated. Widening the
Tier-2 regexes is the wrong move because it trades a false-negative floor for a
false-positive flood — and edit-anchoring is a false-positive flood by
construction. Most source edits encode no decision at all; they're just
implementation. The defense is that the flood lands on the agent, not the owner —
but that's only free if agent attention is free, and specs 055/057 say it isn't
(orchestrator context × turns is the cost). Worse: since a stub only clears when
a covering entry exists, a routine edit produces a nag that can never be cleared,
and the predictable agent response is to write junk entries to silence it or to
learn to ignore stubs — which degrades the 083-07 machinery the idea leans on.

So if there's something here, I suspect it's the narrower version: stub only
edits that change an existing value or constant, not edits that add new code.
That's much closer to what actually happened — a 1100px cap being overwritten
with 720px, against a recorded decision.

Constraints from my side (as the downstream user)

• I run Auto deliberately and trust the agent to write. Per-edit permission
  prompts are a non-starter for me.
• What I actually need: when we change something that contradicts a previous UI
  decision or mockup, it gets persisted — so we don't rewrite it and ask for the
  same modifications again tomorrow.
• So: no new interruption surface for the owner.

Open questions for you

1. Scope. Which paths are "decision-bearing"? jig is layout-agnostic, so this
   probably needs a default plus a config key. Deciding this well is most of the
   work, which is a large part of why this is an issue and not a PR.
2. Division with 083-06. The reconciliation/memory-sync judgment prompt is
   currently the designated owner of "trigger-phrase-free load-bearing decisions."
   Anything diff-anchored overlaps it deliberately — 083-06 relies on agent
   judgment at reconcile time, this would fire deterministically at edit time.
   What's the intended split?
3. 083-08 (Codex host-validation) is DRAFT/deferred — would a new
   PostToolUse trigger need host validation on Codex before it could ship?

Cheap measurement that would settle most of this

Replay N archived sessions that ended in a committed source change and count how
many produced a stub. For flow-style owners I'd expect near zero today. That turns
"the net has holes" from my anecdote into a number, and it'd also show whether the
narrow value-change variant keeps the precision.

Happy to do the work on a slice if you want it, once 1 and 2 are settled — but
this is your spec and your frame review, so I'd rather hand you the evidence than
guess at the design.

[PinkException]

Three more things for the frame review — observations, not proposals.

First, a correction to my own report above: I framed it around one session because that's the one I had the log for. It isn't one session. This has happened several times a day, most days, for the past week — the 1100px case is just the one where I could point at the scratch log and the superseded decision in the same breath. The pattern is what I'm reporting; that session is only the receipt.

The markers are English. actually, instead, should not, override…default, reverse…default are English discourse markers, and fairly particular ones. Neither of us is a native English speaker, and jig's users are whoever installs it — people are terse, tired, mid-flow, or working in a second language, and nobody talks to their AI in a canonical register. I'm not claiming they never fire for me: they do, and I've counted how often in the next comment. What I don't know is what the floor is. It moves with fluency, register, and how the day is going, and I don't think anyone currently knows what it is for anyone.

On adapting my wording. My first instinct was to just learn the trigger words. I do remember commands. But I'd need to be told one, and be able to look it up — otherwise it isn't deterministic and the two sides aren't working from the same contract. Right now the list is five regexes I only know because I went and read decision_scan.py. I don't know what an owner is meant to do with that, or whether publishing the list is something you'd want or specifically want to avoid.

On the published path. Looking for whether one already existed, I found decisions.py add-lightweight (083-05) — idempotent, templated, tier-0, always scaffolded — and memory-sync is user-invocable, with its body routing my exact case: "non-spec shipped decisions — UI strings, visual/CSS choices" → decisions.py, not memory.py (SKILL.md:110-116). What I noticed is that memory-sync's description: doesn't mention decisions at all — it lists "remember this, save this for later, add to glossary, note this down", then "Do not use for updating specs, ADRs, or code comments." If that field is what the host surfaces each session and what decides whether the skill fires (EngTip #23), then at the moment I'd say "remember this decision", the routing surface is silent about the path 083-05 built. I don't know if that's intentional — add-lightweight may be meant for the agent at reconcile time rather than for an owner mid-session, in which case I've misread it.

All three sit upstream of the trigger-phrase question, so I'm flagging them rather than arguing a direction.

[PinkException]

I went and counted, on my own logs — four days, 13–16 July, 15 sessions on this project with a .jig/decision-scratch log. Observations, not proposals. The classification below is by hand and the logs are mine, so treat the buckets as arguable.

53 entries, 27 unique — every entry is written exactly twice. 14 of the 15 sessions show precise 2× duplication. The two identical lines in my report above weren't a one-off in that session.

What the 27 unique entries actually are:

What it is	Count
The agent's own AskUserQuestion dialog	17
Me pasting the agent's prose back at it (the matched "instead" was in its words)	4
<task-notification> blobs recorded with who: "user"	3
Me genuinely saying something	3

The 3 <task-notification> entries are harness text attributed to me — I never said them. That looks like its own bug.

All 3 of the genuine ones fired on should not, so Tier-2 does catch my phrasing sometimes, and I want to correct any impression that it never fires for me. But all 3 came from a single session, and 14 of the 15 sessions captured nothing I said.

The measurement I suggested in the issue would have misled you, and I'd like to withdraw it. I predicted that sessions ending in a source change would show a near-zero stub rate. The actual number is 6 of 7. Stubs get produced almost every time — they're just full of the agent's own questions. Stub presence was never the failure mode, so counting it would have exonerated the net. Whatever gets measured here needs to be about what's in the stub.

(Method, so it's checkable: "real" session = ≥2 genuine user messages in the window; source edit = touching public/, src/, test/, scripts/, excluding docs/, .jig/, and scratch paths. Other definitions move the 7.)

[PinkException]

Correction to my comment above, before it misleads you. The double-write isn't jig's writer — it's me running jig twice.

I have jig@jig enabled as a plugin and a scaffolded install in this project, and both register jig-decision-inflight.sh on the same events. Both fire, both call append_stub, so I get two identical lines in the same second. That's my setup, not your code, and I should have checked before posting it as a finding.

One thing that might still be worth your time: CONTRIBUTING settles precedence for skills when both install shapes coexist ("the scaffolded, project-scoped skills win"), but hooks have no such precedence — they just both run. So a configuration the docs describe as supported silently doubles every stub. Your call whether that's worth anything; I'm flagging it and moving on.

What this doesn't touch: I deduplicated before classifying, so the 27-unique breakdown and the counts are unaffected. The who: "user" attribution on <task-notification> text is separate and still stands — jig-decision-inflight.sh:36,40 hardcodes 'user' for anything arriving via UserPromptSubmit, and harness injections arrive that way.

[PinkException]

PR for the mechanical trio: #116 (spec 094-capture-hygiene, three separately-revertable slices). Implementing with your verbal permission — yours to validate, and none of it pre-empts the frame review. The two questions below I hit while building and deliberately did not answer, because both are yours.

1. Should the machine-text rule also gate the Stop scan's role == "user" branch?

094-01 filters the in-flight stamp site — jig-decision-inflight.sh, the one the scratch-log evidence names. But the goal I was working to ("nothing machine-generated is ever stamped who: \"user\"") is stated absolutely, and decision_scan.scan() stamps who="user" on Tier-2 hits in its own role == "user" branch. If the harness injects the same wrappers into transcript user-turns, that branch has the same bug.

I couldn't settle it: the Stop payload's shape isn't probeable from this repo, so asserting harness text appears there would be exactly the unverified assumption ADR-0020 tells me to mark rather than claim. And that branch is the surface your frame review might demote or delete outright, so widening it now could be work aimed at a corpse. The rule lives in decision_scan.py (beside is_user_override, same no-drift reasoning as 083-07), so if the answer is yes it's a one-line follow-up.

2. Are there other wrapper families reaching UserPromptSubmit?

I enumerated exactly what the evidence names plus the obvious siblings: <task-notification>, <command-name|message|args>, <local-command-stdout|stderr>, <system-reminder>. A reviewer flagged that <bash-input> / <bash-stdout> / <ide_selection> may also arrive that way — and then correctly declined to claim it without probing the host. Same grounding problem, so I left the list conservative. Adding a name is one line if you know of others.

---

Two things from building it that bear on the frame review, offered as evidence rather than argument:

The "over-permissive on purpose" comment was load-bearing, and reversing it was the whole of 094-02. The fallback documents its own premise — "the surfacing is owner-gated, so a noisy stub is cheap; a missed one is not" — and that premise is what produced the 17-of-27. It's a coherent argument that just points the wrong way once measured: owner-gating makes a duplicate cheap, but not a stub that's wrong about who spoke, and 083-07 makes it durable rather than transient, so the cost recurs against agent attention every Stop. Worth flagging because I found the same premise cited in refinement-todo.md:54 justifying an unrelated deferral — it had already started propagating. Corrected inline; the deferral still stands on its surviving half.

A note on your third point (the false-negative floor), from the wrong end of it. I built a filter and my first cut had it swallow a genuine override whose first token happened to be a tag — a false negative I created while fixing a false positive, and one that only turned up because a reviewer went looking. That's a small instance of the thing your issue says is unmeasured. It doesn't argue for or against any direction; it's just a data point that the floor moves under you when you touch this layer, which is a reason to be glad the measurement question is being asked before the design one.

---

Also: workflow.py new capture-hygiene --pr opened stub PR #114 to reserve 094 on the trunk. The real spec is carried in #116, so #114 can be closed unmerged — I tried and my sandbox blocked the close.

[PinkException]

Correction to my comment above, before it misleads you: I said #114 could be closed unmerged. You merged it about twenty minutes after I wrote that, which I only noticed at close-out — so ignore that line, nothing is needed there.

It did mean #116 needed main merged back in: the reservation stub's spec.md and the branch's real spec.md met as an add/add conflict (resolved in favour of the real body), and slice-01-tbd.md is dropped as superseded by the three real slice files. Also picked up #113 and #115 in the same merge. Re-verified on the merged tree: 3379 tests OK — #113's decision-nudge tests and 094's sit together cleanly — hosts in sync, routing 62/62 positives + 44/44 negatives, pinned ruff clean. #116 now reports MERGEABLE.

The two questions in my previous comment stand unchanged.