Skip to content

LINBEE-30104 | fix: keep the repo-health cache per LinearB environment #19

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
nivSwisa1 merged 1 commit into from
Oct 15, 2026
Merged

LINBEE-30104 | fix: keep the repo-health cache per LinearB environment #19

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion plugins/agentic-advisor/.claude-plugin/plugin.json
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
{
"name": "agentic-advisor",
"version": "1.4.0",
"version": "1.4.2",
"description": "Before writing code, grades how fragile the target is from LinearB health signals + local git history (rework, incidents, fix/revert density, code ownership) and holds the agent to a matching effort level (LOW/MEDIUM/HIGH) — lean on calm repos, defensive on fragile ones. Auto-triggers via a bundled hook and can report each effort decision to your LinearB org as usage telemetry.",
"author": {
"name": "LinearB",
Expand Down
6 changes: 6 additions & 0 deletions plugins/agentic-advisor/CHANGELOG.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,5 +1,11 @@
# Changelog

## [1.4.2] - 2026-10-15

### Fixed

- The 24-hour repo-health cache is now kept per LinearB environment: with `LINEARB_API_URL` pointing somewhere other than the default, a repo graded against one environment is no longer reused for another. Default (production) cache entries stay valid.

## [1.4.0] - 2026-10-13

### Added
Expand Down
9 changes: 6 additions & 3 deletions plugins/agentic-advisor/skills/agentic-advisor/SKILL.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -48,8 +48,11 @@ Two checks that prevent wasted work — do them before any LinearB call:
- **Already graded recently → reuse (persistent 24h cache).** The repo-level verdict is daily-stable, so compute it at most **once per repo per ~24h**, not once per task/session — this is the main token/time saver. Cache file, keyed by repo root:

```text
# repo-hash = first 12 chars of the repo root's sha1 (shasum on macOS, sha1sum on Linux)
root="$(git -C "<cwd>" rev-parse --show-toplevel)"; h="$(printf '%s' "$root" | { if command -v shasum >/dev/null 2>&1; then shasum; else sha1sum; fi; } | cut -c1-12)"
# repo-hash = first 12 chars of the sha1 (shasum on macOS, sha1sum on Linux) of the repo root, plus the API URL
# when it isn't the prod default, so grades from different LinearB environments never mix
root="$(git -C "<cwd>" rev-parse --show-toplevel)"; api="${LINEARB_API_URL:-https://public-api.linearb.io}"; api="${api%/}"

@gitstream-cm gitstream-cm Bot Oct 15, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🐞 Bug - Incomplete URL Normalization: Lowercase the URL before comparing and hashing, for example api="$(printf '%s' "${api%/}" | tr '[:upper:]' '[:lower:]')".

Suggested change
root="$(git -C "<cwd>" rev-parse --show-toplevel)"; api="${LINEARB_API_URL:-https://public-api.linearb.io}"; api="${api%/}"
root="$(git -C "<cwd>" rev-parse --show-toplevel)"; api="${LINEARB_API_URL:-https://public-api.linearb.io}"; api="$(printf '%s' "${api%/}" | tr '[:upper:]' '[:lower:]')"
Is this review accurate? Use 👍 or 👎 to rate it

If you want to tell us more, use /gs feedback e.g. /gs feedback this review doesn't make sense, I disagree, and it keeps repeating over and over

@nivSwisa1 nivSwisa1 Oct 15, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Skipping: a differently-cased URL only gets its own cache entry, which is the safe direction (an extra fresh grade, never a wrong reuse).

key="$root"; [ "$api" = "https://public-api.linearb.io" ] || key="$root|$api"

@nivSwisa1 nivSwisa1 Oct 15, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Accepting this edge: it needs a non-default LINEARB_API_URL used before the upgrade and a switch back to prod within 24h, and the cost is one stale repo-health grade (task and file axes are always fresh). Invalidating every prod cache to close it costs all users a re-grade.

h="$(printf '%s' "$key" | { if command -v shasum >/dev/null 2>&1; then shasum; else sha1sum; fi; } | cut -c1-12)"
f="${XDG_CACHE_HOME:-$HOME/.cache}/agentic-advisor/verdicts/$h.json" # private per-user dir, not shared /tmp
cat "$f" 2>/dev/null # read BEFORE any LinearB call
```
Expand All @@ -61,7 +64,7 @@ Two checks that prevent wasted work — do them before any LinearB call:
```
- **Recompute (ignore cache) if:** it's older than 24h, you just merged/deployed to this repo, or a serious incident may have landed.
- **⚠️ The cache stores ONLY the repo-health verdict (phase 1: rework / incidents / unreviewed merges) — daily-stable and task-independent. It does NOT store the final combined effort.** Both **change-area (file fix/revert + ownership)** and **task-complexity** are per-task and are **NEVER cached** — recompute them every task and combine `max(cached repo-health, fresh task-complexity, fresh change-area)`. So a **different task on the same repo within 24h** reuses only the cheap repo-health part and still re-grades the task-specific axes → correct effort for the new task. A cached-calm repo can still surface a HIGH task or file finding.
- (Within a single session you may also just reuse the verdict from earlier in the conversation without re-reading the file — same 24h logic applies.)
- (Within a single session you may also just reuse the verdict from earlier in the conversation without re-reading the file — same 24h logic applies, and only if `LINEARB_API_URL` hasn't changed since.)

## Repo Resolution

Expand Down
Loading