sminos: a peer's message reaches a session as a peer's (7.177.0)

[SSFSKIM]

What

A peer's sminos message now reaches a session as a peer's, never in the owner's voice. This is the owner's decision of 2026-10-18 ("a peer's message arrives as a peer's", desk composite Decision Log, MAWS e72b11443).

Which events count as the owner's. sminos.owner_event decides it: the event's kind is human and its writer is <machine>/human or hub/<member>. Only these take the bridge:

• idle: the human's prompt;
• busy: sminos bridge: a busy session reads a delivery at its next tool round; a delivery wakes a stopped session #233's mid-turn row;
• a --bg job with no bridge: the supervisor's reply.

A peer's event (a session's say/send, or any other shape) goes to the session's inbox socket, the channel native SendMessage rides. The engine records it as origin peer.

The frame. Every inbox frame sminos writes is wrapped in the engine's own peer envelope, <cross-session-message from-name="…">:

• Without the envelope, MAWS's parsePeerMessage refuses the row and draws the owner's bubble again.
• The body escape and the name cleanup copy the engine's serializer, so from-name reaches origin.name.
• tests/sminos/envelope_parity.py pins the cases, which were checked against the 2.1.300 parser.

The reply line. A peer frame's body ends with one fixed line:

[To reply, run in Bash: <sminos path> say "@<project id>/<sender short> <your reply>"]

• The envelope has no from address, so a model with no sminos context would otherwise try SendMessage and fail.
• A say/send into another project's log records the sender's own project as from_project.
• A project part that is not id-shaped is left out of the line.

Senders. Wakes from the bridge child (DELIVERY_WAKE, STEER_WAKE) are named sminos bridge. A keyed inbox frame names its log event's via/from.

Second guard in the mod. The bridge mod refuses a deliver whose writer is a session's, so an older CLI falls back to the inbox.

Duplicates. The inbox has no per-key dedupe, so a push whose DX4 outcome could not be kept is noted in the delivery record. The next pass then records the outcome without pushing again.

Guarantees (DX5 "[peer]" in docs/doperpowers/plans/2026-10-15-arkho-desk-c2-bridge.md):

• No duplicate in the ordinary retry cases. A crash between the write and the settlement is still at least once.
• delivered means the frame was written to the inbox. The engine may still hold it for approval in a session running with bypassPermissions, or drop it at its peer rate limit.

Verification

• Live (tests/mods/live-peer-check.py, 6/6 on the merged head, a real 2.1.302 bridged session with no sminos skill loaded):
  • the peer row is origin peer named scout (a queued_command attachment mid-turn);
  • the session answered the peer by running the reply line;
  • the owner's send stays origin {kind: plugin, asUser: true}.
• Full sminos suite 1928/1928, test-bridge-control.sh 127, mods suite 402 pass.
• doperpowers:reviewer-high on the branch: three P2s, all fixed.
• doperpowers:reviewer-medium on the sminos bridge: a busy session reads a delivery at its next tool round; a delivery wakes a stopped session #233 merge resolution: a P1 (shell-unsafe from_project in the reply line) and a P2 (strict decoding in the sender lookup), both fixed in f196e33.
• ci-gate GREEN: https://github.com/SSFSKIM/doperpowers/actions/runs/39116385961

For MAWS

MAWS's drawing should drop the body's last line when it is the [To reply, run in Bash: …] line.