Build(deps-dev): Bump @typescript-eslint/eslint-plugin from 8.29.1 to 8.32.1#52
Closed
dependabot[bot] wants to merge 1 commit into
Closed
Conversation
Bumps [@typescript-eslint/eslint-plugin](https://github.com/typescript-eslint/typescript-eslint/tree/HEAD/packages/eslint-plugin) from 8.29.1 to 8.32.1. - [Release notes](https://github.com/typescript-eslint/typescript-eslint/releases) - [Changelog](https://github.com/typescript-eslint/typescript-eslint/blob/main/packages/eslint-plugin/CHANGELOG.md) - [Commits](https://github.com/typescript-eslint/typescript-eslint/commits/v8.32.1/packages/eslint-plugin) --- updated-dependencies: - dependency-name: "@typescript-eslint/eslint-plugin" dependency-version: 8.32.1 dependency-type: direct:development update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
Contributor
Author
|
The |
dependabot
Bot
added
dependencies
Contributor
Author
|
Superseded by #66. |
dependabot
Bot
deleted the
dependabot/npm_and_yarn/typescript-eslint/eslint-plugin-8.32.1
branch
joelteply
added a commit
that referenced
this pull request
May 30, 2026
…ayers=0
Closes the runtime end of the Mac Intel chain. Prior commits shipped
the classifier (60d440029), the install-time tier policy (7b3b8e086),
and the hyper-efficiency pass (334f699c1) — but LlamaCppAdapter::load
still hardcoded n_gpu_layers=-1, so even with mac_intel_discrete set
in the env the runtime would route the load into the broken Metal-AMD
shader path.
This commit reads CONTINUUM_TIER and forces n_gpu_layers=0 when the
tier is mac_intel_discrete. install.sh's hardware probe sets the
env at install time; the runtime trusts that contract and avoids
the broken Metal path.
The 2026-05-30 evidence on MacBookPro15,1 / AMD Radeon Pro 560X:
Metal-AMD path (n_gpu_layers=-1) → 0.8 tok/s + multilingual
garbage + hundreds of nil tensor buffer errors per generation.
CPU path (n_gpu_layers=0) → 1.1 tok/s + COHERENT English.
Net: CPU is FASTER and CORRECT than the broken Metal-AMD path
on this hardware. With qwen3.5-0.8b on the same CPU we'd
expect ~5-6 tok/s = usable interactive chat.
Follow-up: native Rust probe at adapter construction so the
runtime doesn't depend on the install-time env-var trust chain
(currently CONTINUUM_TIER is the cross-boundary signal between
install.sh and the Rust runtime). Tracked as task #51 in the
session task list; ties into resolving the parallel
governor::classify_silicon bug (task #52) where the same
"has_metal=true → Apple Silicon" misclassification still lives.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
joelteply
added a commit
that referenced
this pull request
May 30, 2026
* fix(registry): qwen3.5-4b-code-forged GGUF filename case (Q4_K_M)
The published HF GGUF sibling uses the canonical-uppercase suffix
Q4_K_M; the registry was carrying lowercase q4_k_m which 404s on
HuggingFace's case-sensitive resolve path. Caught during a model
download on 2026-05-30 — every host that pulled this entry was
silently failing the pre-pull and falling back to a missing-model
runtime error.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
* feat(cognition): MacIntelMetalDiscrete tier — Mac Intel + Metal classifier branch
Adds HwCapabilityTier::MacIntelMetalDiscrete for hosts whose Metal
device is a discrete AMD or integrated Intel UHD card on a Mac Intel
CPU — physically distinct from Apple Silicon (separate VRAM, Metal 2
only, no neural engine, llama.cpp Metal shaders unreliable on this
path).
Splits the metal branch of host_capability_probe::detect_host_capability
into metal_tier(cpu_brand, device_name, total_mem_mb, platform) which:
- routes Apple-Silicon-brand CPUs to the existing UMA buckets with
TargetSilicon::UnifiedMemory (unchanged),
- routes Intel-brand CPUs to MacIntelMetalDiscrete with
TargetSilicon::Gpu (separate VRAM, not unified),
- loud-fails with ProbeError::UnknownGpuDevice on any other CPU
brand so the operator adds a tier rather than getting silent
M1Uma16Gb routing.
Background: 2026-05-30 inference experiment on MacBookPro15,1 (Intel
i7-8850H + AMD Radeon Pro 560X 4GB + 32GB RAM) showed the previous
classifier silently buckets this host as M1Uma16Gb purely because
total_mem_mb >= 14000 — the cpu_brand check only branched on M2 vs
the M3/M4/M5 family. That mis-tier led the resolver to pick the 4B
forged model which then ran on the Metal-AMD shader path and emitted
multilingual gibberish at 0.8 tok/s with hundreds of nil tensor
buffer errors per generation. The classifier patch is the precondition
for fixing the resolver: the resolver now has a tier name to refuse
4B routing on, and a downstream registry/tier-policy change can map
MacIntelMetalDiscrete to a smaller GGUF (or CPU-only inference, or
grid-share to a peer).
Test override knob (QWEN35_4B_GPU_LAYERS in the throughput test) lets
operators isolate Metal-AMD breakage from CPU-baseline behavior
without editing source — n_gpu_layers=0 forces llama.cpp's CPU path
for parity comparison.
Adds 4 unit tests pinning the new classifier behavior:
- metal_tier_routes_apple_silicon_to_uma_branch
- metal_tier_routes_mac_intel_amd_to_new_tier_not_silent_m1
- metal_tier_routes_mac_intel_uhd_to_same_tier
- metal_tier_loud_fails_on_unknown_cpu_brand
ts-rs regenerated HwCapabilityTier.ts with the new "mac_intel_metal_discrete"
variant. Adding the variant is purely additive — no exhaustive match
sites need updating.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
* feat(registry): mac_intel_discrete tier — runtime + install-time policy
Wires the Rust HwCapabilityTier::MacIntelMetalDiscrete classifier (shipped
in 60d440029) through to the model-selection path that actually picks a
default chat model.
src/shared/ModelRegistry.ts:
- Widens Tier from 'mba'|'mid'|'full' to also include 'mac_intel_discrete'.
- Adds tierFromHost(ramGB, hwTier?) which overrides RAM-based bucketing
when hwTier === 'mac_intel_metal_discrete'. tierFromRamGB stays as a
pure-RAM fallback (existing CandleAdapter + seed callers unchanged).
src/shared/models.json:
- Adds tiers.mac_intel_discrete with default_chat=qwen3.5-0.8b-general.
- Adds auto_download.by_tier.mac_intel_discrete=[qwen3.5-0.8b-general]
so model-init pulls the right GGUF.
install.sh:
- After the RAM-based tier block, probes machdep.cpu.brand_string via
sysctl. Intel brand → CONTINUUM_TIER=mac_intel_discrete + smaller
NATIVE_RESERVE_MIB (5GB instead of 12GB primary).
- Adds the matching case branch in PERSONA_MODEL selection so docker
model pull / model-init fetch the 0.8b forged GGUF.
The 0.8b forged GGUF at continuum-ai/qwen3.5-0.8b-general-forged is
already the destination for MBA tier — same registry entry, no new
HF artifact required. (Note: 2026-05-30 the actual HF GGUF siblings
for the 0.8b/2b forge repos were missing — that's task #49 in the
broader thread, not blocking this tier-policy commit.)
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
* perf(persona): single-pass service_cycle hot path
The per-persona service_cycle runs every 3-10s and is called once per
active persona. Three small wins, no semantic change, 9/9 existing
tests pass.
1. ChannelRegistry::service_cycle — collapsed get + get_mut to single
get_mut in both the urgent and non-urgent loops. NLL handles the
borrow reuse without the old double-lookup workaround. Saves one
HashMap probe per checked domain per tick (8 lookups → 4 in the
urgent loop, 6 → 3 in non-urgent).
2. ChannelRegistry::status — folded the per-channel Vec build and the
total_size / has_urgent_work / has_work rollups into a single
walk over DOMAIN_PRIORITY_ORDER. Previously: 1 unsized-collect Vec
walk to build the channel list + 3 more iter().sum() / iter().any()
passes over the result. Now: 1 walk with pre-sized
Vec::with_capacity(DOMAIN_PRIORITY_ORDER.len()), no Vec growth, no
extra passes. status() is called every tick (urgent and non-urgent
branches alike), so the per-tick savings compound across the
active persona fleet.
3. host_capability_probe::metal_tier — dropped cpu_brand.to_lowercase()
alloc on the Intel-detection branch. Intel CPU brand strings
reliably ship with capital "Intel" (e.g. "Intel(R) Core(TM) i7-8850H
CPU @ 2.60GHz"); literal substring match avoids the String
allocation on every boot probe. Boot path, not hot — done for code
hygiene + worked example of the discipline.
The discipline this lands: per Joel 2026-05-30, Rust is the work; Node
is the shell; the LCD machine (Mac Intel today, phones eventually) is
the forcing function that prevents the codebase from quietly consuming
the M-series headroom. Same code runs on both; cycles you don't burn
on the slow path become perceived snappiness on the fast one.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
* feat(inference): honor CONTINUUM_TIER=mac_intel_discrete with n_gpu_layers=0
Closes the runtime end of the Mac Intel chain. Prior commits shipped
the classifier (60d440029), the install-time tier policy (7b3b8e086),
and the hyper-efficiency pass (334f699c1) — but LlamaCppAdapter::load
still hardcoded n_gpu_layers=-1, so even with mac_intel_discrete set
in the env the runtime would route the load into the broken Metal-AMD
shader path.
This commit reads CONTINUUM_TIER and forces n_gpu_layers=0 when the
tier is mac_intel_discrete. install.sh's hardware probe sets the
env at install time; the runtime trusts that contract and avoids
the broken Metal path.
The 2026-05-30 evidence on MacBookPro15,1 / AMD Radeon Pro 560X:
Metal-AMD path (n_gpu_layers=-1) → 0.8 tok/s + multilingual
garbage + hundreds of nil tensor buffer errors per generation.
CPU path (n_gpu_layers=0) → 1.1 tok/s + COHERENT English.
Net: CPU is FASTER and CORRECT than the broken Metal-AMD path
on this hardware. With qwen3.5-0.8b on the same CPU we'd
expect ~5-6 tok/s = usable interactive chat.
Follow-up: native Rust probe at adapter construction so the
runtime doesn't depend on the install-time env-var trust chain
(currently CONTINUUM_TIER is the cross-boundary signal between
install.sh and the Rust runtime). Tracked as task #51 in the
session task list; ties into resolving the parallel
governor::classify_silicon bug (task #52) where the same
"has_metal=true → Apple Silicon" misclassification still lives.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
* perf(persona): O(N) heapify in drain_frame instead of O(N log N) extend
PersonaInbox::drain_frame drains the heap into messages + retained,
then re-loads retained into the heap so out-of-window items survive
the drain. The previous heap.extend(retained) pushed N items at
O(log N) each = O(N log N) total. Since the heap is empty at that
point (the while loop drained it), BinaryHeap::from(Vec) does
in-place heapify in O(N) (sift-down construction per std docs).
Real cost on a busy persona: anchor matches few cross-room messages,
retained = nearly the full N. The old path paid log N per item to
rebuild; the new path pays one O(N) heapify pass.
23/23 existing inbox + admission tests pass — pure perf change, no
semantic shift (heap-from-Vec produces a valid max-heap regardless of
input Vec order, identical to repeated push).
Discipline: same code runs on Mac Intel and M5 per Joel 2026-05-30
"optimizing for a low quality computer is HOW you get a fast machine
on m5." A 500-message inbox drains in O(500) instead of O(500*9) =
~9× less heap work per drain. The savings on Mac Intel are invisible
to the user; on M5 they compound into the perceived snappiness ceiling.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bumps @typescript-eslint/eslint-plugin from 8.29.1 to 8.32.1.
Release notes
Sourced from
@typescript-eslint/eslint-plugin's releases.... (truncated)
Changelog
Sourced from
@typescript-eslint/eslint-plugin's changelog.... (truncated)
Commits
af077a0chore(release): publish 8.32.1f8db925fix(eslint-plugin): [consistent-indexed-object-style] check for indirect circ...98c5c4cfix(eslint-plugin): [consistent-indexed-object-style] adjust auto-fixer to ge...b2be3dcchore: simplifytsconfigsetup usingconfigDir(#11136)523b3eafix(eslint-plugin): [no-deprecated] support computed member access (#10867)0d822bddocs: useT[]instead of[T, ...T[]]in rule options (#11129)aeb7402chore(ast-spec): finish migrating tovitest(#11126)a89d5e3fix(eslint-plugin): [no-unnecessary-type-conversion] shouldn't have fixable p...7598496chore: remove now-stub@types/markedpackage0cee7cachore(deps): update dependency ignore to v7 (#11163)Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot mergewill merge this PR after your CI passes on it@dependabot squash and mergewill squash and merge this PR after your CI passes on it@dependabot cancel mergewill cancel a previously requested merge and block automerging@dependabot reopenwill reopen this PR if it is closed@dependabot closewill close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)