chore(deps): update Crawlkit to v0.14.8

[steipete]

Update Crawlkit from v0.14.7 to v0.14.8 so release-check HTTP requests time out after 30 seconds instead of hanging indefinitely. Document that inherited behavior in the changelog and installation guide; no Discrawl application code or CI assertions change.

Dependency audit: GOWORK=off go get -u -t ./... and GOWORK=off go mod tidy updated Crawlkit and regenerated go.sum. Every direct/indirect requirement in go.mod is now current within its module path. Go 1.27.0, pinned analysis tools, all GitHub Actions references (including CodeQL's action tags), and Docker image digests were already current. The selected module graph also inherits age v1.3.2 from Crawlkit; Discrawl does not import its backup package. No new direct dependencies.

No major upgrade was taken. Defer Bubble Tea v2.0.9, Bubbles v2.2.1, and Lip Gloss v2.0.6: Crawlkit owns the shared TUI and still uses v1. Their v2 migration changes import paths, view types, and key/mouse APIs; migrate Crawlkit upstream first, then consume its release here. Upstream migration guide.

Validation on Go 1.27.0 / macOS arm64:

• Full build and GOWORK=off go test -count=1 ./... -coverprofile=.discrawl/deps-refresh-20260830/coverage.out: pass; aggregate coverage 85.6%, above the unchanged 85% floor.
• GOWORK=off go test -count=1 -race ./...: pass for every package.
• make fmt lint, make tidy-check, make smoke, and actionlint: pass.
• GoReleaser snapshot: all six darwin/linux/windows × amd64/arm64 archives built; no publication.
• .agents/skills/autoreview/scripts/autoreview --engine codex --mode local: clean, no accepted/actionable findings. Reviewer could not fetch upstream source; the timeout was independently verified against the built binary below.

Govulncheck reports zero affected symbols and zero affected imported packages. Its module-only advisory GO-2026-5932 concerns the unused, unmaintained golang.org/x/crypto/openpgp package, has no fixed version, and does not affect Discrawl's imported packages.

Live proof used an isolated config with token_source = "none", auto-update disabled, and a synthetic Desktop cache containing one guild message and one DM. These are actual command/output excerpts (paths shortened to a repo-relative shell variable):

p=.discrawl/deps-refresh-20260830
make build BINARY="$p/discrawl" VERSION=0.13.3
go version -m "$p/discrawl" | rg 'go1.27|crawlkit'
# .discrawl/deps-refresh-20260830/discrawl: go1.27.0
# dep github.com/openclaw/crawlkit v0.14.8

"$p/discrawl" --config "$p/config.toml" --json wiretap --path "$p/desktop"
# "messages": 2, "dm_messages": 1, "guild_messages": 1, "skipped_messages": 0

"$p/discrawl" --config "$p/config.toml" --json search refreshproof
# "content": "refreshproof public fixture checklist"
# "content": "refreshproof private fixture checklist"

"$p/discrawl" --config "$p/config.toml" --json search --dm refreshproof
# "guild_id": "@me", "content": "refreshproof private fixture checklist"

"$p/discrawl" --config "$p/config.toml" --json wiretap --path "$p/desktop"
# "files_unchanged": 1, "messages": 0
"$p/discrawl" --config "$p/config.toml" --json sql 'select count(*) as messages from messages'
# {"columns":["messages"],"rows":[["2"]]}

expect "$p/tui-proof.exp"
# PASS: TUI rendered imported DM: refreshproof private fixture checklist
# TUI q exit=0

The terminal script launched discrawl --config "$p/config.toml" tui --dm, waited for the imported text, sent q, and verified exit 0. No personal archive was read.

For the behavioral change, a loopback HTTP proxy accepted CONNECT api.github.com:443 HTTP/1.1 and deliberately sent no response:

HTTPS_PROXY=http://127.0.0.1:62371 NO_PROXY= \
  "$p/discrawl" --config "$p/config.toml" --json check-update --force
# check latest openclaw/discrawl release: Get "https://api.github.com/repos/openclaw/discrawl/releases/latest": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
# exit=1; elapsed=30.10s

A separate direct public GitHub lookup returned github returned 403 Forbidden; response headers confirmed x-ratelimit-remaining: 0 for the host's unauthenticated quota. This external check is recorded as blocked, not passing; no credentials or production settings were changed.

CI reasoning: default-branch build/test CI was already green at 1359f06 (run 33373230652). The PR's build/test CI, Docker build, CodeQL analysis, and secret scan all passed at 328fa03. This PR retains all lint, coverage, race, module-verification, vulnerability, snapshot-build, and secret-scan gates. Docker and CodeQL are additional build/security workflows; backup publication/reports, stale triage, and ClawSweeper dispatch are scheduled or operational workflows, not substitutes for build/test CI. No workflow required a version or policy change.

Prepared for maintainer review; do not auto-merge.

[clawsweeper]

🦞👀
ClawSweeper picked this up.

Pull request received. I will update this pull request when review starts.

[clawsweeper]

Codex review: needs maintainer review before merge. Reviewed August 31, 2026, 5:26 AM ET / 09:26 UTC.

ClawSweeper review

What this changes

The PR upgrades Crawlkit from v0.14.7 to v0.14.8 and documents the inherited 30-second timeout for Discrawl release-check requests.

Merge readiness

⚠️ Ready for maintainer review - 1 item remains

Keep open for normal merge review: the focused dependency update has source-connected terminal proof of the new bounded failure behavior and no blocking defect identified.

Priority: P2
Reviewed head: 328fa03e6f0cb985041133e49e9df9ee1a3b3c18

Review scores

Measure	Result	What it means
Overall readiness	🐚 platinum hermit (4/6)	A narrowly scoped dependency update with concrete production-path terminal proof and no actionable review finding.
Proof confidence	🦞 diamond lobster (5/6)	Sufficient (terminal): The changed production dependency is consumed by internal/cli/releasecheck.go through releasecheck.Check; the supplied macOS terminal trace runs the built v0.14.8 binary against a deliberately unresponsive loopback proxy and records the expected timeout after 30.10 seconds.
Patch quality	🐚 platinum hermit (4/6)	No actionable review findings were identified.

Verification

Check	Result	Evidence
Real behavior	Verified	Sufficient (terminal): The changed production dependency is consumed by internal/cli/releasecheck.go through releasecheck.Check; the supplied macOS terminal trace runs the built v0.14.8 binary against a deliberately unresponsive loopback proxy and records the expected timeout after 30.10 seconds.
Evidence reviewed	5 items	Introduced dependency update: The complete introduced patch changes only the Crawlkit version and its Go checksums, plus matching changelog and installation documentation. Dependency boundary: Discrawl directly imports Crawlkit’s release-check package and routes check-update through releasecheck.Check, so the upstream timeout contract is directly relevant to this PR. Real behavior proof: The PR body records a built v0.14.8 Discrawl binary invoking check-update --force through a loopback proxy that accepts CONNECT but sends no response; it exits with a client timeout after 30.10 seconds.
Findings	None	None.
Security	None	None.

How this fits together

Discrawl’s update-check command and passive terminal notice delegate GitHub release lookup to Crawlkit’s release-check package. A stalled release API request now returns a bounded error rather than waiting indefinitely.

flowchart LR
  A[Discrawl CLI] --> B[Release check command]
  B --> C[Crawlkit release checker]
  C --> D[GitHub release API]
  D --> E[Update status or notice]
  C --> F[30-second timeout error]

Loading

Before merge

• Complete next step (P2) - No discrete repair is needed; complete ordinary PR checks and maintainer review on the submitted head.

Agent review details

Security

None.

Review metrics

Metric	Value	Why it matters
Patch scope	4 files, +6 / -3 lines; 1 direct dependency updated	The change is narrowly confined to the dependency pin, checksums, and documentation.

Technical review

Best possible solution:

Merge the small Crawlkit patch update once the remaining required checks complete on this exact head, preserving the documented bounded timeout behavior.

Do we have a high-confidence way to reproduce the issue?

Yes: route check-update --force through a loopback HTTPS proxy that accepts CONNECT and withholds response headers. The supplied after-fix trace and the direct releasecheck.Check call make this a high-confidence reproduction path, though no independent before-version trace was supplied.

Is this the best way to solve the issue?

Yes: updating the shared release-check dependency addresses the behavior at its owning HTTP-client boundary without adding Discrawl-specific timeout wrappers or configuration.

AGENTS.md: not found in the target repository.

Codex review notes: model internal, reasoning high; reviewed against 1359f06f593b.

Labels

Label changes:

• add P2: This is a bounded reliability improvement for the release-check path without evidence of a broader runtime outage.
• add proof: sufficient: Contributor real behavior proof is sufficient. The changed production dependency is consumed by internal/cli/releasecheck.go through releasecheck.Check; the supplied macOS terminal trace runs the built v0.14.8 binary against a deliberately unresponsive loopback proxy and records the expected timeout after 30.10 seconds.
• add rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🦞 diamond lobster and patch quality is 🐚 platinum hermit.
• add status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (terminal): The changed production dependency is consumed by internal/cli/releasecheck.go through releasecheck.Check; the supplied macOS terminal trace runs the built v0.14.8 binary against a deliberately unresponsive loopback proxy and records the expected timeout after 30.10 seconds.

Label justifications:

• P2: This is a bounded reliability improvement for the release-check path without evidence of a broader runtime outage.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🦞 diamond lobster and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (terminal): The changed production dependency is consumed by internal/cli/releasecheck.go through releasecheck.Check; the supplied macOS terminal trace runs the built v0.14.8 binary against a deliberately unresponsive loopback proxy and records the expected timeout after 30.10 seconds.
• proof: sufficient: Contributor real behavior proof is sufficient. The changed production dependency is consumed by internal/cli/releasecheck.go through releasecheck.Check; the supplied macOS terminal trace runs the built v0.14.8 binary against a deliberately unresponsive loopback proxy and records the expected timeout after 30.10 seconds.

Evidence

What I checked:

• Introduced dependency update: The complete introduced patch changes only the Crawlkit version and its Go checksums, plus matching changelog and installation documentation. (go.mod:9, 328fa03e6f0c)
• Dependency boundary: Discrawl directly imports Crawlkit’s release-check package and routes check-update through releasecheck.Check, so the upstream timeout contract is directly relevant to this PR. (internal/cli/releasecheck.go:68, 328fa03e6f0c)
• Real behavior proof: The PR body records a built v0.14.8 Discrawl binary invoking check-update --force through a loopback proxy that accepts CONNECT but sends no response; it exits with a client timeout after 30.10 seconds. (docs/install.md:26, 328fa03e6f0c)
• Prior area contribution: Available shallow history shows steipete authored the prior merged dependency refresh commit, supporting routing to the existing dependency-maintenance area. (go.mod:9, 4c29bb75ef7f)
• History limitation: Deeper blame, parent-diff, and tag inspection could not complete because this checkout is a shallow promisor clone and its configured remote could not resolve; the source, complete PR patch, and supplied runtime trace remained available.

Likely related people:

• steipete: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)

Rating scale

Score	Internal tier	Crab rank	Meaning
6/6	S	🦀 challenger crab	Exceptional readiness
5/6	A	🦞 diamond lobster	Very strong readiness
4/6	B	🐚 platinum hermit	Good normal PR; ordinary maintainer review
3/6	C	🦐 gold shrimp	Useful, but confidence is limited
2/6	D	🦪 silver shellfish	Proof or implementation needs work
1/6	F	🧂 unranked krab	Not merge-ready
N/A	NA	🌊 off-meta tidepool	Rating does not apply

Overall follows the weaker of proof and patch quality.
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

Workflow

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.