feat: add peer-reasoning contract and fix two silent probe defects

I added a Collaborative Peer Reasoning section to the interaction rules. It governs how an interpretation forms before any rule about presenting choices: infer first and clarify only at material forks, test a conclusion against its strongest alternative, let a correction update the downstream model instead of just the wording. The file's framing line widened to match.

Two probes were failing silently. The startup KB nudge looked up the best-practices node by grepping file content for its slug. A roam node's slug lives in its filename, so the lookup always returned empty. The nudge pointed at nothing in every project and every session, for as long as it shipped. It matches the filename now, through find rather than a glob so zsh doesn't abort on no match.

The browser rule told agents to open URLs with a form ending in &>/dev/null &. That discards the "Opening in existing browser session." line confirming the tab opened. Warm and cold start now split: foreground and read the confirmation when Chrome is already up, detach only when it isn't. The confirmation is on stdout, verified rather than assumed.

I filed two tasks from handoffs. The sentry triage split needs a work-vs-personal classification mechanism before its wording can move, because the current rule excludes by category and category can't express that split. The publish-lock design is approved but carries three open gaps. The load-bearing one is a lock held across an unbounded human approval pause.

I also swept the old processed handoffs out of inbox/. History keeps them.

1 files changed, 0 insertions, 79 deletions

diff --git a/inbox/PROCESSED-2026-07-05-0420-from-archsetup-ui-prototyping-process-proposal.org b/inbox/PROCESSED-2026-07-05-0420-from-archsetup-ui-prototyping-process-proposal.org
deleted file mode 100644
index e0677eb..0000000
--- a/inbox/PROCESSED-2026-07-05-0420-from-archsetup-ui-prototyping-process-proposal.org
+++ /dev/null
@@ -1,79 +0,0 @@
-#+TITLE: Proposal — UI/UX prototype process for specs with a non-trivial UI
-#+AUTHOR: Craig Jennings (via archsetup session)
-#+DATE: 2026-07-05
-
-* Intro / why this is coming to you
-
-Working the timer-panel spec in archsetup, we found the right way to settle a
-UI design: research first, then build a handful of full working prototypes,
-then iterate one to a final — all before committing GTK code. It worked well
-enough that Craig wants it as a standing part of the spec process for any spec
-whose deliverable has a non-trivial UI. This is the write-up, proposed for the
-rulesets layer (spec-create / spec-review, or a new =ui-prototyping= rule —
-your call on placement).
-
-Worked example living now in archsetup: =docs/specs/2026-07-02-timer-panel-spec.org=
-plus =docs/prototypes/2026-07-02-timer-panel-prototype-{1,2,3}.html=. The spec's
-"Prototype iterations" subsection and its new design decisions show the shape in
-practice.
-
-* The process
-
-** 1. Trigger — non-trivial UI only
-Applies when a spec's deliverable is a real UI: a panel, a multi-control
-surface, a visual layout with interacting parts. Not a single dialog, a CLI
-flag, or a one-off prompt. If "which of these layouts is right?" can't be
-answered from a sentence, it qualifies.
-
-** 2. Research first — during brainstorming, before prototyping
-Before any prototype, survey how existing and best-in-class tools solve the same
-UX and functionality (the category's well-regarded apps, prior art, conventions
-users already expect). Feed the findings into the spec's Goals and Design so the
-UX and functionality are understood *before* a single prototype. Prototyping
-blind wastes iterations re-deriving what a 20-minute survey would have told you.
-Cite the sources in the spec.
-
-** 3. Brainstorm the UX + functionality in the spec
-Informed by the research, write the goals, the interactions, and the functional
-surface into the spec. This is the "what and why" the prototypes will make real.
-
-** 4. Prototype — ~5 initial directions, then iterate to a final
-Build about five *distinct directions* (genuinely different layouts /
-interaction models, not variations of one) as full working prototypes over one
-shared engine, in the project's design language. Pick a direction, then iterate
-*that one* across numbered passes to the final design. Each meaningful pass is
-saved as its own numbered prototype so the design history is walkable.
-
-** 5. Full working prototypes, not mockups
-The prototypes must be *functional* — real state, real controls, real behavior —
-so decisions are made against how it feels to use, not against a picture. A
-static mockup hides the interaction problems that only surface when you drive it.
-
-** 6. Naming + location
-=docs/prototypes/<spec-name>-prototype-<N>.html=, where =<spec-name>= is the
-spec's dated slug (dropping the =-spec= suffix) and =N= is the iteration number.
-E.g. for =2026-07-02-timer-panel-spec.org= →
-=2026-07-02-timer-panel-prototype-1.html=, =-2.html=, =-3.html=.
-
-** 7. Link from the spec; keep old iterations in history
-The spec links the *final* prototype in its design section, and keeps links to
-*every* prior iteration in a "Prototype iterations" subsection under the status
-heading — newest last — so the design's evolution is walkable from the spec.
-
-** 8. Decisions get written down once seen working
-A design decision is recorded in the spec's Decisions only after it's been seen
-working in a prototype. "Resolved live through the prototype iteration" — the
-prototype is the evidence.
-
-* Suggested placement (your value gate decides)
-
-- =spec-create=: for a non-trivial-UI spec, add a "research → brainstorm →
-  prototype (5 directions → iterate)" step, and require the "Prototype
-  iterations" subsection.
-- =spec-review=: for a non-trivial-UI spec, verify the prototype process ran —
-  research cited, final prototype linked, iterations in history, decisions
-  backed by a prototype.
-- Or a standalone =claude-rules/ui-prototyping.md= that both workflows point at.
-
-Not prescribing which — sending the content and the worked example; apply the
-rulesets value gate and place it where it fits.