Fix Trail Show Detail Fetch Fallback

I'll use the review skill for this.

I have enough to review. Here's my assessment of PR #1476 — feat(trail): show the description and a browser URL in trail show.

Overview

entire trail show previously printed a one-line Body: field sourced from the list lookup. This PR replaces that with two richer outputs:

1. A URL: line — a browser link built as BaseURL()/<forge>/<owner>/<repo>/trails/<number>.
2. A multi-line Description: block fetched separately from the detail endpoint (trail.body_document.text_snapshot), which the list response omits.

The detail fetch is best-effort: failures warn to stderr and still render metadata + URL. Code is clean, well-commented, and test coverage is solid (URL building incl. trailing-slash dedup, nested-body decode via httptest, display formatting, empty/whitespace omission). All tests use t.Parallel().

Main finding — the claimed found.Body fallback isn't implemented (behavior regression)

The PR description says detail-fetch failure "degrades to 'no description'; falls back to found.Body." The code does not do this. On failure:

So the old inline Body (still present in found.Body from the list) is now dropped entirely in two cases that previously showed it:

• Detail fetch fails — user sees metadata + URL but no body, even though found.Body is in hand.
• Number-less trails (found.Number == 0) — the if found.Number > 0 guard skips the whole block, so bodyText stays "". Previously these showed their Body; now they show neither URL nor any body.

This is a strict regression in degraded paths, and the PR description promises the exact fix. I'd implement the fallback so it matches the description:

(If dropping the list body on failure is actually intended, then the PR description should be corrected instead — but the current text reads as a missing implementation.)

Smaller notes

• Local-dev URL correctness. trailWebURL assumes the web app is co-hosted with the data-API origin. True in production (https://entire.io), but with ENTIRE_API_BASE_URL pointing at the backend (e.g. :8080) the printed URL won't reach the dev frontend (:5173). Acceptable for now, but worth a one-line comment noting the prod assumption, since the existing comment only says "co-hosted with the data API."
• Manual URL concatenation. trailWebURL hand-builds the path with +. forge/owner/repo aren't URL-escaped — fine given they're validated GitHub identifiers, but the codebase already has api.ResolveURLFromBase for base joining. Low priority; current approach is readable and tested.
• Test name mismatch. TestFetchTrailDetail_ReadsNestedBodyDocument exercises fetchTrailDescription (there's no fetchTrailDetail). Minor — rename for grep-ability.

Verdict

Solid, well-tested change with good comments and graceful-degradation intent. The one thing I'd block on is the missing found.Body fallback — either wire it in (recommended, matches the PR description and improves both the failure and number-less paths) or correct the PR description. Everything else is optional polish.

Want me to apply the fallback fix?

Both done:

• PR comment posted on #1476 → https://github.com/entireio/cli/pull/1476#issuecomment-4771806831
• Trail finding created on trail #616 (id 019ef0ad-6d8e-75e9-8a42-b754040a598d), severity medium, located at cmd/entire/cli/trail_cmd.go.

One note: entire trail finding add rejected both line and range granularity with location_invalid: requires non-empty selected_text, so I fell back to a file-level location and put the line range (~135–152) in the body text. That looks like a real gap in the CLI's trail finding add — it builds line/range locations from --line/--start-line/--end-line but never sends selected_text, so any line-anchored finding fails server-side. Want me to file that as its own finding/issue?

Done. Committed as 99a2c44.

Changes:

• Fallback fix — runTrailShow now seeds bodyText/descriptionLoaded from found.Body so a failed detail fetch or a number-less trail still renders the list body; a successful detail fetch supersedes it with the richer body_document text. Matches the PR description's stated behavior.
• Local-dev URL note — expanded the trailWebURL comment to flag that the web-origin==API-origin assumption holds in prod but breaks in a split local-dev setup.
• Test rename — TestFetchTrailDetail_ReadsNestedBodyDocument → TestFetchTrailDescription_ReadsNestedBodyDocument to match the function it exercises.

Left the manual URL concatenation as-is (tested, low-risk, flagged as acceptable).

Verification: mise run fmt + mise run lint clean (0 issues); mise run test:ci green (exit 0, 59/59 + 4/4) after a flaky first run that passed on rerun.

Note I didn't push — the commit is local on feat/trail-show-intent-and-url. Want me to push, and should I resolve the trail finding (#616) now that it's addressed?

The push succeeded — f68b176cb..72da75fa1 is now on the remote branch (the checkpoint-sync warning is unrelated to the code push; only the entire/checkpoints/v1 mirror couldn't reach its remote).

PR #1476 now includes both fixes:

• Medium (resolved) — the PR head was behind; the local commit is now pushed, so the merged PR will carry the list-body fallback rather than the old bodyText := "" / descriptionLoaded := false.
• Low (resolved) — a successful detail fetch now only supersedes the seeded list body when body_document actually carries text. An older/partial server that returns trail.body but omits body_document keeps showing the list body instead of the empty-description placeholder; an explicit empty description on a server that does support body_document still renders the placeholder.

Verification: mise run fmt + mise run lint clean (0 issues), mise run test:ci green (59/59 + 4/4, exit 0).

The trail finding (#616, 019ef0ad…) is still open — want me to resolve it now that both points are addressed?