Build(deps-dev): Bump @typescript-eslint/eslint-plugin from 8.29.1 to 8.43.0#115
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.43.0. - [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.43.0/packages/eslint-plugin) --- updated-dependencies: - dependency-name: "@typescript-eslint/eslint-plugin" dependency-version: 8.43.0 dependency-type: direct:development update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
added
dependencies
Contributor
Author
|
Superseded by #125. |
dependabot
Bot
deleted the
dependabot/npm_and_yarn/typescript-eslint/eslint-plugin-8.43.0
branch
joelteply
added a commit
that referenced
this pull request
Jun 2, 2026
…GPU, Windows are co-primary targets Joel (2026-05-31), refining the hardware matrix in two messages: 1. %22We%27d really be building for 3090 desktops or m5%27s at the same time. The 5090 is luxury but we will take advantage. I have 1080ti%27s on another windows box.%22 2. %22I have 1080ti and 5090 windows only. Don%27t have the 3090. Just target sizes. M1 or higher ok ram ought to be good too.%22 Reframes the strategy doc from %22Intel Mac + M5%22 to the full hardware matrix: - **Apple Silicon class (M1 Pro/Max → M5 Pro/Max, ≥16 GB UMA)** — primary local. M1 is the floor; M2+ Pro/Max comfortably runs the realistic floor. Throughput table per generation included. - **Ampere+ desktop GPU class (24 GB VRAM)** — co-primary local. RTX 3090 is the SIZING target; substrate runs on any GPU at that class. Joel doesn%27t own a 3090 — it%27s a target size. - **Pascal class (1080 Ti, 11 GB VRAM, Windows)** — supported older target. Joel%27s actual hardware. - **Blackwell (5090, 32 GB VRAM, Windows)** — luxury overflow. Joel has one but designing around it would lock out others. - **MacBookPro15,1 Intel Mac** — edge proof; heuristic + reflective + grid offload. - **Windows is first-class** — both Joel%27s NVIDIA boxes are Windows. Build matrix MUST include Windows; CI MUST exercise the Windows path on at least the heuristic substrate flow. Grid principle reinforced: %22this isn%27t a single-machine substrate. Joel%27s actual setup is a grid of heterogeneous boxes, and the substrate routes lanes wherever capacity is available.%22 The same `adapter.generate_text(request)` command runs everywhere; the AircRemoteInferenceAdapter (#108) is just an adapter impl with airc transport instead of llama.cpp. Flags two missing tier enums (task #115): - Sm60 (Pascal, 1080 Ti) - M5UmaProMax (currently M5 would fall back to M3UmaProMax) Updated #108 task description to capture %22same command across the wire%22 architecture explicitly.
joelteply
added a commit
that referenced
this pull request
Jun 2, 2026
…aProMax, M5UmaProMax (task #115) Joel%27s strategy doc (committed earlier this session) declared M5 Pro/Max + GTX 1080 Ti as supported daily-driver targets. Both were silently misclassified by the substrate: - M5 Pro/Max → fell through the `M3 || M4 || M5` branch into M3UmaProMax. The substrate couldn%27t distinguish M5 throughput from M3. - GTX 1080 Ti → unknown to nvidia_sm_tier (no GTX 10xx / P-series branch). Returned UnknownGpuDevice; Joel%27s Windows box would reject coherent inference setup. Fixes: 1. Added three enum variants to HwCapabilityTier in `cognition/model_resolver/types.rs`: - `M4UmaProMax` — Apple M4 Pro/Max/Ultra. Adds Metal 3 tensor API + AMX matmul; ~30% better than M3 on Qwen-7B Q4_K_M. - `M5UmaProMax` — Apple M5 Pro/Max/Ultra. Joel%27s daily-driver target per the strategy doc. 24-48 GB UMA comfortably fits Qwen-2.5-14B at 24 GB, 27B at 48 GB. - `Sm60` — NVIDIA Pascal compute capability 6.x. GTX 10xx series (1080 Ti, 1080, 1070 Ti, etc.), Tesla P100 / P40 / P4, Titan X/Xp. Joel%27s 1080 Ti on Windows lives here. 2. Updated `apple_silicon_tier()` to check more-specific patterns first (M5 → M4 → M3 → M2 → M1) so each tier maps distinctly instead of collapsing into M3UmaProMax. 3. Updated `nvidia_sm_tier()` with a Pascal branch — matches %22GTX 10%22 / %22P100%22 / %22P40%22 / %22P4%22 / %22TITAN X%22 / %22TITAN XP%22 substrings. Standard transformer inference works via llama.cpp%27s CUDA backend on Pascal; smaller VRAM (11 GB on 1080 Ti) constrains model size to Qwen-7B class at Q4_K_M. ### Tests (5 new, 14 total in host_capability_probe, all green) - nvidia_pattern_match_resolves_known_skus — extended with 7 Pascal cards (1080 Ti, 1080, 1070 Ti, 1060, P100, P40, Titan Xp) - apple_silicon_m5_classifies_above_m3_not_falling_through - apple_silicon_m4_classifies_distinctly_from_m3 - apple_silicon_m3_still_classifies_correctly_after_m4_m5_added (regression guard against ordering bugs) - apple_silicon_m2_pro_max_stays_in_m2_tier (regression guard) - apple_silicon_tier_mapping — updated to assert M4/M5 land in their own tiers (was asserting %22M4 aliases to M3%22 before) ### What is NOT touched - Per-tier default-model picks (the model registry%27s tier table). The new variants exist as enum values but the registry doesn%27t yet have explicit default-model rows for them. Adding model picks happens when #49 (resolve missing GGUF in 0.8b/2b forge repos) lands a concrete catalog, or in a focused follow-up. - AircRemoteInferenceAdapter routing decisions per tier (#108) — the tier classification is now accurate enough to inform those decisions when #108 implements them. With the enum fixed, anyone running continuum-core-server on: - A 1080 Ti Windows box → probe correctly classifies Sm60 instead of erroring; subsequent code paths can branch appropriately. - An M5 Mac → probe classifies M5UmaProMax distinctly from M3. - An M4 Mac → probe classifies M4UmaProMax distinctly from M3. ts-rs regenerated bindings for HwCapabilityTier.ts.
joelteply
added a commit
that referenced
this pull request
Jun 2, 2026
…ask #120) ## Doctrine (Joel, 2026-06-01) > "We don't get away with singular AI's. We are just clever with > resources." Multi-persona is the floor, not a luxury. Even the lowest tier (Intel Mac discrete-Metal, CPU-only) runs Helper + Coder, sharing a base model and paging per-persona LoRAs. The substrate's `defaults_for_tier(tier)` function ALWAYS returns >= 2 templates; "singular AI" is structurally impossible. ## What ships `persona/role_template.rs`: - `RoleId` — Helper, Coder, Sentinel, Custom - `SpawnPriority` — Required (Helper), HighlyRecommended (Coder), OnRequest (Sentinel and explicit-need roles) - `ModelChoice` — model_id + gguf_file + size + quant + optional base_model_id (the lever for shared-base LoRA paging) - `ModelChoicePerTier` with a safety-floor `choose(tier)` fallback so any unmapped tier still gets the lowest known runnable choice - `IdentityDefaults` (name_pool + bio_template) — feeds the deterministic identity projection from `persona-identity-derives-from-source-id` - `CognitionDefaults` (depth_preference, voice, max_response_chars, asks_before_guessing) — Helper sits clippy-shaped (depth=20, voice="clippy", 400 chars, asks); Coder sits engineer-shaped (depth=70, voice="engineer", 4000 chars, doesn't ask) - `RoleTemplate` bundles all of the above - `helper_template()` + `coder_template()` populated concretely across the HwCapabilityTier ladder, from CpuOnly (Qwen2.5-0.5B-Instruct for Helper, DeepSeek-Coder-1.3B for Coder) up through Sm120 / M5UmaProMax (14B classes) - `defaults_for_tier(tier)` ALWAYS returns >= Helper + Coder ## Tier-shaped expectations | Tier | Helper | Coder | |----------------------------|------------------------------|------------------------------------| | CpuOnly / MacIntelMetalDsc | Qwen2.5-0.5B Q4_K_M (380 MiB)| DeepSeek-Coder-1.3B Q4_K_M (870) | | M1Uma8Gb | Qwen2.5-1.5B (1.1 GiB) | Qwen2.5-Coder-1.5B (1.1 GiB) | | M1Uma16Gb | Qwen2.5-3B (2 GiB) | Qwen2.5-Coder-3B (2 GiB) | | M3UmaProMax / Sm60 | Qwen2.5-7B (4.4 GiB) | Qwen2.5-Coder-7B (4.4 GiB) | | M5UmaProMax / Sm120 | Qwen2.5-14B (8.5 GiB) | Qwen2.5-Coder-14B (8.5 GiB) | Same role identity + cognition shape; just bigger models at higher tiers. At low tiers Helper and Coder may share a base model family (both qwen2.5-1.5b family at M1Uma8Gb, for example) — the base_model_id field is the lever a future LoRA-paging module uses to share weights. ## Tests (9 / 9 green) - `defaults_for_tier_returns_at_least_helper_and_coder_for_every_tier` — the load-bearing invariant. Every variant of HwCapabilityTier yields at least Helper + Coder. If a future refactor narrows the floor at any tier, the test screams. "No singular AI" is structural. - `helper_priority_is_required` — Helper's SpawnPriority pins the always-on contract. - `coder_priority_is_highly_recommended` — Coder shows up by default but is disable-able. - `helper_model_choice_resolves_for_every_tier` — including tiers the template doesn't cover, via the safety floor. - `coder_low_tier_targets_swiss_army_code_family` — names the acceptable model families (Qwen-Coder / DeepSeek-Coder / StarCoder), catches accidental swaps to non-code-capable models. - `helper_cognition_defaults_are_brief_and_friendly` — pins clippy DNA (depth <= 30, max_chars <= 600, asks_before_guessing, voice=clippy). - `coder_cognition_defaults_allow_depth` — pins the contrasting engineer profile (depth >= 50, max_chars >= 2000). - `model_choice_per_tier_falls_back_to_first_entry` — the safety floor stays operative. - `role_id_stable_strings` — header / kanban metadata strings pinned. ## What this enables (follow-ups, separate cards) 1. **PersonaSpawnerModule** — ever-present substrate ServiceModule that reconciles `defaults_for_tier(current_tier)` against currently-running personas. Required → always-spawned. HighlyRecommended → spawn unless explicitly opted out. 2. **Shared-base + LoRA paging** — when Helper + Coder pick the same `base_model_id` at the current tier, the substrate hosts ONE model in memory and pages LoRAs. `[[host-the-seemingly-impossible]]` in concrete form on a laptop. 3. **Hardware-probe wiring** — `HostCapabilityProbe` (already exists, task #115) reports tier; substrate spawns Helper + Coder by default; the user never sees a model selector. 4. **Bootstrap experience** — `airc init` (or continuum equivalent) on first run probes hardware, picks templates from this layer, downloads the GGUFs, spawns the personas, posts a greeting in the default room. Naive users get a working substrate on day 1. ## References - `[[host-the-seemingly-impossible]]` — shared base, page LoRAs - `[[individuality-is-the-substrate-strength]]` — diversity via LoRA - `[[personas-have-names-not-function-labels]]` — role in bio, identity from deterministic projection - `[[substrate-is-communities-of-specialization]]` — even N=2 is a community - Built on: #87 PersonaInstanceManagerModule, #115 HwCapabilityTier, #116 FilesystemPersonaResolver, #109/#110/#111 InferenceCoordinator 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.43.0.
Release notes
Sourced from
@typescript-eslint/eslint-plugin's releases.... (truncated)
Changelog
Sourced from
@typescript-eslint/eslint-plugin's changelog.... (truncated)
Commits
ef9173cchore(release): publish 8.43.04f44a6efeat(typescript-estree): disallow empty type parameter/argument lists (#11563)bd8ed8dfix(eslint-plugin): [prefer-return-this-type] don't report an error when retu...d8ca5effix(eslint-plugin): [no-deprecated] should report deprecated exports and reex...8154204docs: mark rules that are frozen on rules index page (#11467)5d15bc2fix(eslint-plugin): [no-floating-promises] allowForKnownSafeCalls now support...f77a31dfix(eslint-plugin): [consistent-type-exports] fix declaration shadowing (#11457)f0e64ebfix(eslint-plugin): [no-unnecessary-type-conversion] only report ~~ on intege...c068a4ffix(scope-manager): exclude Program from DefinitionBase node types (#11469)08e242cfix(eslint-plugin): [no-non-null-assertion] do not suggest optional chain on ...Maintainer changes
This version was pushed to npm by [GitHub Actions](https://www.npmjs.com/~GitHub Actions), a new releaser for
@typescript-eslint/eslint-pluginsince your current version.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)