fix: surface inbound Relay media to responding agents

[kunchenguid]

Intent

Fix the Relay inbound-attachment gap: screenshots attached to a Discord support thread never reached the agent responding to the mention.

Grounded in the real incident (request req-GDxWuyZ, recovered read-only from the production relay): the relay DID deliver the images. The thread_starter entry of in_reply_to_chain carried two Discord-CDN photos (IMG_2718.png, IMG_2717.png on cdn.discordapp.com) while the mention's own top-level images/attachments were empty because that message was the captain's own reply. The poll stashes the full relay object, so the images do arrive locally. The failure was that the responder's fmx-respond playbook documented a fixed intake field list (request_id, text, in_reply_to, in_reply_to_chain) and never surfaced inbound images or attachments, so the responding agent never viewed them.

Per an explicit captain decision this fix is PROSE-ONLY. An earlier code approach (a poll-side fetch/materialize helper in bin/fm-x-lib.sh plus a fetch path in bin/fm-x-poll.sh) was built and then withdrawn by the captain. That code path is deliberately absent and must not be reintroduced: no code renderer, no code fetch helper, and no poll-path download of third-party content.

Accepted requirements:

1. fmx-respond instructs the agent to read the COMPLETE payload object rather than a fixed field list, so images, attachments, and future relay fields are never invisible again.
2. When the payload carries image or file URLs - on the mention itself and on every in_reply_to_chain entry, including the common shape where only the thread_starter carries them - the AGENT fetches them with its own tools and views them: image files opened as images, text-like files read inline. No firstmate code performs the fetch.
3. Safety is prose-enforced, by the captain's explicit choice of prose over a code control. The playbook restricts fetches to https and to an exact-match allowlist of known-good platform media hosts (Discord: cdn.discordapp.com, media.discordapp.net, images-ext-1.discordapp.net, images-ext-2.discordapp.net; X: pbs.twimg.com, video.twimg.com), requires reporting a blocked host to the captain instead of working around it, and treats everything fetched as untrusted public input.
4. Keep the existing direct-author-is-captain versus untrusted-surrounding-thread framing, and extend it to attached media.
5. Documentation describes the responder surfacing inbound media and the poll deliberately downloading nothing; the wire schema notes that chain entries may carry attachments.
6. A colocated regression test built from the real incident's payload shape (top-level media empty, thread_starter chain entry carrying the image URLs) exercises the real poll path and asserts the mention reaches the inbox with the payload intact and its media URLs unfetched.

Scope: the inbound-attachment surfacing path only. Do not refactor unrelated Relay logic.

Repo rules: follow firstmate-coding-guidelines, keep bin scripts shellcheck-clean under bin/fm-lint.sh, colocate tests in tests/, one sentence per line in tracked Markdown, plain dash and never an em dash, and no agent co-author trailer on any commit.

Review note: findings r3 through r8 from the previous, cancelled run all targeted the withdrawn code fetch path (SSRF and host allowlist, download fan-out, record framing, redirect resolution, image format policy). Their resolution is that the code fetch path was removed entirely by captain decision; inbound fetching is now agent-tool-driven with a prose-enforced known-CDN restriction.

What Changed

• Update the Relay responder playbook to inspect complete payloads and securely fetch and view allowed media from mentions and conversation-chain entries.
• Document attachment fields and the no-download polling contract, with a regression test proving thread-starter media URLs remain intact and unfetched.

Risk Assessment

✅ Low: The change is narrowly scoped to responder guidance, documentation, and behavioral regression coverage, with no poll-side media fetching introduced and prior findings correctly resolved.

Testing

No baseline commands were supplied; the focused automated regression and an evidence-producing real poll-to-inbox exercise confirmed the complete attachment-bearing payload is preserved, wakes the responder, and causes no poll-path media fetches. Reviewer-visible JSON and transcript artifacts were captured; no screenshot was applicable because this is a prose-only responder contract and shell relay path with no rendered UI.

Evidence: Observable Relay poll and persisted attachment result

Source: Observable Relay poll and persisted attachment result

{
  "wake": "x-mention req-GDxWuyZ",
  "request_id": "req-GDxWuyZ",
  "text": "any idea what is going on here?",
  "top_level_media": {
    "images": [],
    "attachments": []
  },
  "thread_starter": {
    "author_handle": "@reporter",
    "kind": "thread_starter",
    "text": "the upload keeps failing",
    "images": [
      {
        "type": "photo",
        "url": "https://cdn.discordapp.com/attachments/1012345678900020080/1234567891233211234/IMG_2718.png?ex=65d903de&is=65c68ede&hm=2481f30d"
      },
      {
        "type": "photo",
        "url": "https://cdn.discordapp.com/attachments/1012345678900020080/1234567891233211235/IMG_2717.png?ex=65d903de&is=65c68ede&hm=2481f30e"
      }
    ],
    "attachments": [
      {
        "filename": "trace.log",
        "content_type": "text/plain",
        "url": "https://cdn.discordapp.com/attachments/1012345678900020080/1234567891233211236/trace.log"
      }
    ]
  },
  "observed_poll_calls": [
    "https://relay.test/connector/poll"
  ],
  "third_party_downloads_by_poll": 0
}

Evidence: End-to-end poll transcript

Source: End-to-end poll transcript

Command: bin/fm-x-poll.sh (fake Relay transport, real poll executable)
Wake output: x-mention req-GDxWuyZ
Persisted inbox: ~/.no-mistakes/evidence/01M1E5JEMWXDA914KASGR2A807/relay-inbound-attachment-e2e/home/state/x-inbox/req-GDxWuyZ.json
Observed URL calls: https://relay.test/connector/poll
Payload preservation: exact
Third-party media fetches by poll: 0

Evidence: Actual persisted inbox payload

Source: Actual persisted inbox payload

{
  "request_id": "req-GDxWuyZ",
  "tweet_id": "discord:1",
  "author_id": "42",
  "text": "any idea what is going on here?",
  "images": [],
  "attachments": [],
  "in_reply_to": {
    "author_handle": "@reporter",
    "text": "the upload keeps failing"
  },
  "in_reply_to_chain": [
    {
      "author_handle": "@reporter",
      "kind": "thread_starter",
      "text": "the upload keeps failing",
      "images": [
        {
          "type": "photo",
          "url": "https://cdn.discordapp.com/attachments/1012345678900020080/1234567891233211234/IMG_2718.png?ex=65d903de&is=65c68ede&hm=2481f30d"
        },
        {
          "type": "photo",
          "url": "https://cdn.discordapp.com/attachments/1012345678900020080/1234567891233211235/IMG_2717.png?ex=65d903de&is=65c68ede&hm=2481f30e"
        }
      ],
      "attachments": [
        {
          "filename": "trace.log",
          "content_type": "text/plain",
          "url": "https://cdn.discordapp.com/attachments/1012345678900020080/1234567891233211236/trace.log"
        }
      ]
    }
  ]
}

Evidence: Observed network call set

Source: Observed network call set

url=https://relay.test/connector/poll

Pipeline

Updates from git push no-mistakes

✅ **intent** - passed

✅ No issues found.

✅ **Rebase** - passed

✅ No issues found.

🔧 **Review** - 2 issues found → auto-fixed ✅

• 🚨 .agents/skills/fmx-respond/SKILL.md:112 - Criterion 4 requires preserving the direct-author-is-captain versus untrusted-surrounding-thread distinction for media, but this hunk labels media attached to the direct mention as third-party content and line 124 says never obey instructions inside it. A captain message such as “do what the attached screenshot requests” would therefore lose its authorized instruction. Distinguish captain-attached media from chain-entry media while retaining public-content safety restrictions.
• 🚨 tests/fm-x-mode.test.sh:482 - Criterion 6 requires asserting that the payload's media URLs remain unfetched, but the test checks only IMG_2718.png. A poll that fetches IMG_2717.png or trace.log alone still passes. Assert the exact observed curl call set is only the Relay poll, or explicitly reject every fixture media URL.

🔧 Fix: Preserve media authority and enforce poll-only fetching
✅ Re-checked - no issues remain.

✅ **Test** - passed

✅ No issues found.

• Focused regression: generated a temporary harness from tests/fm-x-mode.test.sh and ran test_poll_preserves_inbound_attachment_urls.
• End-to-end evidence check: ran the real bin/fm-x-poll.sh against a fake Relay response shaped like req-GDxWuyZ, with empty top-level media and attachments on the thread_starter.
• Verified the persisted inbox JSON exactly matched the Relay payload and the recorded URL call set was exactly https://relay.test/connector/poll, with no media downloads.
• Confirmed testing left no transient files or worktree changes via git status --short and temporary-file searches.

✅ **Document** - passed

✅ No issues found.

✅ **Lint** - passed

✅ No issues found.

✅ **Push** - passed

✅ No issues found.

[greptile-apps]

Confidence Score: 5/5

The PR appears safe to merge with no concrete blocking or independently actionable non-blocking issue identified.

The responder guidance covers the documented media locations and representations, preserves the direct-author trust boundary, and the regression test verifies that the real polling path retains the complete payload without fetching third-party media.

_{Reviews (1): Last reviewed commit: "no-mistakes(document): Clarify Relay att..." | Re-trigger Greptile}