[fullsend-ai-coder]

Summary

Updates skills/code-implementation/references/attachments.md so failed issue-attachment downloads show up in the agent's output and are not silently lost.

Changes to the download block:

• Listing errors are visible. set -o pipefail plus && between the two gh api calls means a 403/404/rate-limit ends in INCOMPLETE: listing or download failed. When grep finds no matches (exit 1), that still counts as a success, so "no attachments" stays clean.
• Bounded, safe downloads. curl gets --proto '=https' and --max-time 60. A failed, empty or non-image/* download is deleted and reported as FAILED <n>-<name>. The signed URL is never printed.
• Streaming. Removed sort -u. Duplicates are skipped by file name inside the loop. grep --line-buffered and decoding & in the loop (no sed stage) mean each download starts as soon as its URL is read.
• Tighter matching. The pattern is now [^"<>[:space:]]+, so a plain-text link (<a href="U">U</a> and more) gives U once. .mp4/.mov are skipped.
• Summary. Prints downloaded X/Y.

The prose now says: on INCOMPLETE/FAILED, run the block once more (this fetches fresh signed URLs). If a needed image is still missing, mark the work PARTIAL in the commit message and pr_body, name the missing <uuid>s, and never use a placeholder. Existing rules (no Authorization header, no signed URLs in files, commits or pr_body) are unchanged.

Testing

• Ran the block against stub gh/curl:
  • gh 403 on the issue: downloaded 0/0 followed by INCOMPLETE
  • 403 on comments only: INCOMPLETE
  • Mixed curl results: a 403 that left a 0-byte file and a text/html response were both deleted and reported, giving downloaded 2/4
  • The duplicated <a href><img src> link was fetched once
  • A plain-text link followed by HTML gave a clean URL with & decoded
  • .mp4 was skipped
  • No attachments gave downloaded 0/0 with no error
  • A slow comment page: the first download started before the page returned
• shellcheck (repo args) passes on the extracted block, before and after the second commit.
• skillsaw 0.18.0 --strict passes.
• pre-commit could not fetch hook repos in the sandbox (TLS error), so I ran the applicable pre-commit-hooks v6.0.0 hooks and lint-release-cases directly, and they passed. scan-secrets passes.
• Not tested: a real stalled transfer hitting --max-time 60, and real GitHub downloads (code: verify issue-attachment download in the sandbox on a private repository #1923 covers sandbox verification).

Caveat (pre-existing, not changed here)

In this sandbox, Tirith blocks the download block when it is pasted inline as one Bash command, because it cannot parse the brace-group/while read pipeline. The original block on main is blocked the same way. Writing the block to a file and running bash <file> works, and that is how it was tested above. The second commit replaces the case alternation and [[ ]] with plain test checks to match the accepted dialect, but that alone does not unblock the inline paste. This may be worth handling with #1923.

Related

#1922 and #1923 also touch this reference doc. Whichever lands second may need a rebase.

🤖 Generated with Claude Code

---

Closes #1924

Post-script verification

• Branch is not main/master (agent/1924-attachment-download-failures)
• Secret scan passed (gitleaks — 88e5770175ac0cab3a3624255556362ff1e73e63..HEAD)
• PR body secret scan passed (gitleaks — no-git)
• Final PR description secret scan passed (gitleaks — no-git)

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 2:14 PM UTC · Completed 2:22 PM UTC

Commit: 3ff4f0e · View workflow run →

Runtime: pi · Model: sonnet → claude-sonnet-5-5 · Effort: high · Cost: $1.11

[fullsend-ai-review]

Risk Assessment: low (1/5)

Details

Single skill reference doc updated by a bot with low churn and fully aligned issue scope, presenting low risk overall despite touching a protected path.

[fullsend-ai-review]

Review

Findings

Medium

• [protected-path] skills/code-implementation/references/attachments.md — This PR modifies a file under the protected skills/ path. The PR links issue code: attachment download failures are silent #1924 and explains the rationale, but human approval is always required for protected-path changes, regardless of context. No other findings were raised by the correctness, security, style-conventions, intent-coherence, or docs-currency reviewers.