Skip to content

v1.7.0 — Access Barrier Handling

Latest

Choose a tag to compare

@ilchemla ilchemla released this 24 Aug 20:26
· 2 commits to main since this release
63bdf75

nimble-web-expert now treats an access barrier as a result to report rather than something to escalate through. Nothing to do to upgrade.

🚀 What's New

Clearer render-tier escalation

  • Escalation triggers are empty or truncated content, and a page shell that never hydrated
  • A CAPTCHA, a human-verification page, or a sign-in wall is reported plainly and stops the run
  • Where a supported alternative exists, the skill takes it — --focus social search for social profiles, public search results for gated articles

Driver tiers described by what they do

  • Fast HTTP, headless browsing, headful browsing, full browser profile
  • Every driver remains available and the --driver values are unchanged

Documentation

  • The known-site table in error-handling.md gives the supported path for each scenario, with --focus social documented as the route to LinkedIn and X data
  • Browser fetch is documented as a same-session request to the page's own API endpoints
  • Network capture is documented as returning structured JSON with no HTML parsing needed
  • launch-monitor's description covers press, Reddit, LinkedIn, JavaScript-heavy pages, and live community forums — what the skill monitors is unchanged
  • CLAUDE.md documents the standard these changes follow, naming the two skills that already handled it correctly as the model to copy

🔗 Related PRs

  • #68: treat an access barrier as an outcome, not an escalation trigger

🔄 Breaking Changes

None to installation, skill names, skill routing, or MCP tool names.

One behaviour change worth knowing: nimble-web-expert no longer escalates the render tier when a site returns an access barrier. It reports the outcome and stops, or takes a supported alternative where one exists.