Build(deps-dev): Bump @typescript-eslint/parser from 8.29.1 to 8.46.1#142
Closed
dependabot[bot] wants to merge 1 commit into
Closed
Build(deps-dev): Bump @typescript-eslint/parser from 8.29.1 to 8.46.1#142dependabot[bot] wants to merge 1 commit into
dependabot[bot] wants to merge 1 commit into
Conversation
Bumps [@typescript-eslint/parser](https://github.com/typescript-eslint/typescript-eslint/tree/HEAD/packages/parser) from 8.29.1 to 8.46.1. - [Release notes](https://github.com/typescript-eslint/typescript-eslint/releases) - [Changelog](https://github.com/typescript-eslint/typescript-eslint/blob/main/packages/parser/CHANGELOG.md) - [Commits](https://github.com/typescript-eslint/typescript-eslint/commits/v8.46.1/packages/parser) --- updated-dependencies: - dependency-name: "@typescript-eslint/parser" dependency-version: 8.46.1 dependency-type: direct:development update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
Contributor
Author
|
Superseded by #147. |
joelteply
added a commit
that referenced
this pull request
Jun 2, 2026
…ontext analog Per Joel 2026-06-02: "design got out of control due to you failing to use a shared object for all state info required for a persona OR user. This is the airc user. Or base user with airc props." And "make this pattern regular, ubiquitous &ctx, store references, make it elegant." What changed: - HostedPersona is now PersonaContext (with `pub type HostedPersona = PersonaContext` for slice-9-era callers). The struct holds the persona's full context — identity (airc citizen facts), role, inference profile, adapter, runtime — and is passed by reference (`&ctx`) to every persona-scoped function. - HostedPersona.instance renamed to `.identity`: it's the airc user identity (peer_id, agent_name, home, default_room, source). - HostedPersona.profile (new) carries the PersonaInferenceProfile directly — single source of truth for inference shape. Replaces the prior context_window-only field. Downstream code reads `ctx.profile.context_length` etc. — no copied fields, no derived constants outside the named derivation site. - HostedPersona.runtime (new) holds `Option<Arc<PersonaAircRuntime>>`. Production always Some (filled by materialize_adapters via the registry_lookup closure). Tests construct with None — the proper AircHandle trait abstraction lands as part of task #142. - spawn_persona_service signature simplified — no separate runtime arg (`ctx.runtime` carries it). - materialize_adapters takes a `runtime_lookup` closure so the supervisor folds the live runtime into each context at the composition seam. - RagInspectionRequest::for_persona(persona_id, name, now_ms, &profile) is the single derivation site. The old `defaults_for` (32k hardcoded budget) stays for back-compat but is documented as legacy; service_loop uses `for_persona` exclusively. Why this matters (the bug it fixes): - PR #1511 integration trace caught `llama_decode returned -1` on Intel Mac mac-cpu-only: the LCD model was loaded at n_ctx=2048 (Compat tier per profile_builder), but RagInspectionRequest:: defaults_for was setting context_window=32_768. The RAG layer built a 32k-budget prompt that overflowed the 2k KV cache. - The structural fix is the &ctx doctrine: profile is the single source, derivation happens in one named function. Task #142 (BaseUser hierarchy) is the natural follow-up: extract the airc props (identity + runtime) into a `BaseUser` trait that persona/human/web actor contexts all derive from. Same shape per [[personas-are-citizens-airc-is-identity-provider]]. Verification: - cargo build --bin continuum-core-server clean - cargo build --lib --tests clean - Substrate boot composition still hosts Paige in correct channel (continuum, 11c1a7ac…) - Service loop fires inference (slow on CPU; iteration target) Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
joelteply
added a commit
that referenced
this pull request
Jun 2, 2026
* refactor(persona): bootstrap_planned/derive_spawn_plan/build_profile take &Registry Per HEADLESS-PERSONA-HOST-LOOP design doc Q1 (PR #1510 review found the original recommendation was inverted): the substrate boot path holds `&'static Registry` from `model_registry::global()`. Migrating the singleton to `OnceLock<Arc<Registry>>` would touch every callsite of `global()` and change the lifetime semantics throughout the crate. Smaller change: drop the Arc requirement from the three functions that took `&Arc<Registry>` and accept `&Registry` instead. Rust's Deref coercion at the test call sites handles `Arc<Registry>` ↦ `&Registry` transparently — no test changes needed. Functions updated: - profile_builder::build_profile (slice 5) - spawner::derive_spawn_plan (slice 6) - spawner_module::bootstrap_planned (slice 8) All slice 5-9 tests still pass: persona::profile_builder — 4 passed persona::spawner — 4 passed persona::spawner_module — 5 passed Unblocks the slice-13 boot composition at `ipc::start_server` where the registry is `&'static Registry`, not an Arc. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * feat(persona): extend PersonaAircRuntimeRegistry → PersonaSlot with service_loop Per HEADLESS-PERSONA-HOST-LOOP design doc Q3 (PR #1510 review): a PersonaSupervisor module storing JoinHandles keyed by persona_id would duplicate the existing PersonaAircRuntimeRegistry keyspace. Both modules would own per-persona lifetime info. Compression failure per [[organization-purity-as-we-migrate]]. Resolution: extend the registry. Each slot becomes: PersonaSlot { runtime: Arc<PersonaAircRuntime>, service_loop: Mutex<Option<JoinHandle<Result<ServeOutcome, _>>>>, } New methods: - attach_service_loop(persona_id, handle) — supervisor wires the per-persona serve loop into the slot. Refuses silent overwrites. - is_service_loop_finished(persona_id) — Q7's periodic crash poll. - shutdown_slot(persona_id) — the orderly path: take JoinHandle → abort → await → remove slot. The slot drop cascades: Arc<PersonaSlot> → Arc<PersonaAircRuntime> → Arc<Airc> → inner.subscribers map drop → daemon-attach wire tasks abort. Per the cleanup-model section of the design doc, BOTH steps (abort + slot remove) are required — abort alone leaves the wire subscriber alive until the Arc drops via registry removal. - ids() — Vec<Uuid> snapshot for the supervisor's poller without cloning N runtime Arcs. Existing surface preserved for back-compat: - register, get, get_by_agent_name, remove (sync), iter, len, is_empty all return runtime Arcs (not slot Arcs). The slot is internal. Tests cover the failure modes: - attach_service_loop_errors_when_no_slot - is_service_loop_finished_returns_none_for_missing_slot - shutdown_slot_returns_none_for_missing_persona Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * fix(persona): constrain plan_for_tier to single Helper until slice 14 Per HEADLESS-PERSONA-HOST-LOOP design doc P2 (PR #1510 review finding #2 — position-pairing broken from boot 2): ResumeOrMintProvider::scan_personas_dir sorts directory entries alphabetically (resume_or_mint_provider.rs:200). On boot 1 the substrate mints personas in plan order [Helper, Coder] with random-derived names (e.g. Maya for Helper, Bart for Coder). On boot 2, scan yields them in alphabetic order [Bart, Maya] — position-pairing against [Helper, Coder] flips the roles. Bart becomes Helper when he was Coder. Role identity flipped silently. The hazard exists in slice 8's bootstrap_planned today but doesn't manifest because nothing depends on (persona_id, role) yet. Slice 13 IS that consumer (cognition + supervisor both observe the role). Without a fix, slice 13 ships with a latent boot-2 regression. Fix shape: - plan_for_tier returns ONE Helper for all tiers until slice 14. - TODO marker names slice 14 as the load-bearing fix (role-in-seed.json + RoleAwareProvider). - Existing test `compat_tier_plans_helper_and_coder_on_lcd` renamed to `compat_tier_plans_single_helper_on_lcd` with updated invariant. - New `slice_14_restores_helper_plus_coder_for_compat` test pinned `#[ignore]` until slice 14 — it's the spec slice 14 has to satisfy. Going red on the ignore-removal date is the design's reminder. - bootstrap_planned_exhausted_provider_errors_with_slot_info updated: `required` field now 1, not 2. Net result: slice 13's substrate hosts ONE Helper per tier through the managed path. Same coverage the demo binary currently provides, but composed via the substrate. Slice 14 reopens the multi-role case once role identity is durable across boots. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * feat(ipc): substrate hosts personas via composed slice 7-12 pipeline (#133 slice 13) The moment-of-truth. Before this commit, the IPC boot loop at `ipc/mod.rs:1024-1089` called `bootstrap_one(&intent)` per ResumeOrMintProvider output and only LOGGED a welcome. The persona was reachable via `airc peers` but never responded — a mute citizen. After this commit, the boot path composes: PersonaSpawnerModule::plan_for_tier (slice 7) → bootstrap_planned (slice 8): mints/resumes airc identities → materialize_adapters (slice 9): builds inference adapters → spawn_persona_service (slice 12): runs serve_persona_loop → PersonaAircRuntimeRegistry::attach_service_loop (slice 13 Q3): parks the JoinHandle in the slot alongside the runtime Each planned persona ends up with a tokio task running her cognition path. The substrate hosts personas headlessly — no `airc_chat_demo` in the inner ring. Status against the design doc HEADLESS-PERSONA-HOST-LOOP.md: APPLIED: - P2: plan_for_tier returns single Helper (separate commit f940fa4). - Q1: bootstrap_planned takes &Registry (separate commit 71429da). - Q3: registry slot owns runtime + service_loop (commit 3f843aa). - Boot composition collapses ~65 lines of inline bootstrap-only loop into ~115 lines of substrate composition using the existing slice primitives. Per [[organization-purity-as-we-migrate]], the old welcome-log-only path is DELETED, not kept alongside. DEFERRED with TODO markers: - Q2 (detect_host_capability wiring): the existing free function at cognition/host_capability_probe.rs:87 takes &dyn GpuMonitor + &System. No production code constructs a GpuMonitor today — only tests do. Slice 13 uses HwCapabilityTier::CpuOnly + HwTierCategory:: Compat as the safe floor (the LCD Helper Qwen2.5-0.5B works for all tiers). TODO #52 cited for when GpuMonitor construction lands. - P1 (tokio::signal::ctrl_c → Runtime::shutdown): the per-slot shutdown is available via `PersonaAircRuntimeRegistry::shutdown_slot` and exercised by persona/instances/* IPC commands. The server- level signal handler is its own sub-slice. - P3 (ResourceBroker.acquire admission): current LCD case is 1 persona × ~500 MiB GGUF, well within all tiers. Becomes load- bearing when multi-persona returns in slice 14. Tests: - 31 tests across slices 5-13 all green (registry, service_loop, supervisor, spawner, spawner_module, profile_builder, host). - No new tests in this commit — the boot composition is the integration point; the integration test requires a stub PersonaInstanceManagerModule (slice 13 follow-up). Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * fixup: PR #1511 review — drain leaked task + orderly-drain orphan personas Two blockers from the adversarial review: BLOCKER 1 — JoinHandle leaked on attach_service_loop failure. `JoinHandle::drop` detaches rather than aborts. When `attach_service_loop` returned an error and the boot loop did `continue`, the spawned `serve_persona_loop` kept running untracked. The boot log lied "persona will not respond on the grid" while in fact the loop did respond, just outside the registry's view (so `shutdown_slot` couldn't find it). Worse on `"already attached"`: two loops competed for the same persona. Fix: `attach_service_loop` signature changed to `Result<(), (JoinHandle, &'static str)>` so the caller can orderly-drain (abort + await). Boot loop updated. Existing test updated to assert the handle comes back live (proves no implicit detach) before the test drains it. BLOCKER 2 — Partial-bootstrap orphans on bootstrap_planned error. `bootstrap_planned` registers each persona via `bootstrap_one` BEFORE the next slot's mint runs. If slot k fails, slots 0..k-1 are already in the registry but with no service loop attached — mute citizens. The boot loop early-returned with "no personas hosted" but they were. Fix: on `bootstrap_planned` error, the boot loop calls `registry.ids()` to get the partially-registered set and `shutdown_slot`s each. `shutdown_slot` handles "no service loop attached" gracefully (handle_opt is None) and drops the Arc cleanly — same orderly cleanup path as the normal shutdown, just no loop to abort. Error log updated to report `orphans_drained` count honestly. Advisory 3 — `debug_assert!(plan.len() <= 1)` at the producer. P2 invariant was named in the commit body + tested in `compat_tier_plans_single_helper_on_lcd` but had no runtime tripwire. Added the debug_assert at `plan_for_tier`'s producer site with a TODO marker tying it to slice 14 (when the assert comes out alongside RoleAwareProvider + role-in-seed.json). Verification: cargo test persona::airc_runtime_registry → 5 passed cargo test persona::spawner_module → 5 passed + 1 ignored cargo build --lib clean Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * fix(persona): join by room_name, not UUID-as-string — substrate hosts in correct channel PR #1511 integration test on Joel's Intel Mac revealed: PersonaAircRuntime::bootstrap was calling `airc.join(&default_room.as_uuid().to_string())`, which passes the UUID's string representation into airc-lib's `ChannelName::new(name)` — which DERIVES a channel UUID from the string. The persona landed in derived channel `5d33e2a7…` while the operator's `airc room` points at canonical `11c1a7ac…`. Same room, two channels, never see each other. The demo binary worked around this in slice 11 by using `from_attached` (joining by name manually first), but the substrate-managed path through PersonaInstanceManagerModule still called the broken bootstrap. Fix threads through 4 layers: - airc/discovery.rs: new `discover_default_room_name()` parses `room: <name>` line from `airc room` stdout. Mirrors the existing `discover_default_channel()` shape; env override `AIRC_DEFAULT_ROOM_NAME` for tests/operators. - airc/mod.rs: re-export the new function. - modules/airc.rs: AircModule stores `attach_room_name: Option<String>`; `default_room_name() -> Option<&str>` getter. Loud warn if discovery fails — names the failure mode so operators see what's broken. - modules/persona_instance_manager.rs: PersonaInstanceManagerModule::new takes Option<String> room name; bootstrap_one passes it to PersonaAircRuntime::bootstrap. - persona/airc_runtime.rs::bootstrap: joins by name if Some, falls back to UUID-as-string + WARN if None. - ipc/mod.rs: discovers + threads through. Integration trace confirmed (slice13-server.log line 1078ish): joined_room=11c1a7ac-cb85-5ca0-a5b4-2847280ea3fa room_name=continuum Test sites updated to pass `None` (4 in persona_instance_manager.rs tests, 1 in spawner_module.rs). Status after this fix: ✅ Substrate boot composition fires ✅ Persona hosted as substrate-managed Helper ✅ Joins canonical airc channel ✅ Receives operator messages via subscribe ✅ Service loop invokes inspect_persona_rag_with_inference ❌ Inference fails with `llama_decode returned -1` on mac-cpu-only — separate inference-layer bug, tracked as task #131-adjacent. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * refactor(persona): PersonaContext is the substrate's &ctx — Android-Context analog Per Joel 2026-06-02: "design got out of control due to you failing to use a shared object for all state info required for a persona OR user. This is the airc user. Or base user with airc props." And "make this pattern regular, ubiquitous &ctx, store references, make it elegant." What changed: - HostedPersona is now PersonaContext (with `pub type HostedPersona = PersonaContext` for slice-9-era callers). The struct holds the persona's full context — identity (airc citizen facts), role, inference profile, adapter, runtime — and is passed by reference (`&ctx`) to every persona-scoped function. - HostedPersona.instance renamed to `.identity`: it's the airc user identity (peer_id, agent_name, home, default_room, source). - HostedPersona.profile (new) carries the PersonaInferenceProfile directly — single source of truth for inference shape. Replaces the prior context_window-only field. Downstream code reads `ctx.profile.context_length` etc. — no copied fields, no derived constants outside the named derivation site. - HostedPersona.runtime (new) holds `Option<Arc<PersonaAircRuntime>>`. Production always Some (filled by materialize_adapters via the registry_lookup closure). Tests construct with None — the proper AircHandle trait abstraction lands as part of task #142. - spawn_persona_service signature simplified — no separate runtime arg (`ctx.runtime` carries it). - materialize_adapters takes a `runtime_lookup` closure so the supervisor folds the live runtime into each context at the composition seam. - RagInspectionRequest::for_persona(persona_id, name, now_ms, &profile) is the single derivation site. The old `defaults_for` (32k hardcoded budget) stays for back-compat but is documented as legacy; service_loop uses `for_persona` exclusively. Why this matters (the bug it fixes): - PR #1511 integration trace caught `llama_decode returned -1` on Intel Mac mac-cpu-only: the LCD model was loaded at n_ctx=2048 (Compat tier per profile_builder), but RagInspectionRequest:: defaults_for was setting context_window=32_768. The RAG layer built a 32k-budget prompt that overflowed the 2k KV cache. - The structural fix is the &ctx doctrine: profile is the single source, derivation happens in one named function. Task #142 (BaseUser hierarchy) is the natural follow-up: extract the airc props (identity + runtime) into a `BaseUser` trait that persona/human/web actor contexts all derive from. Same shape per [[personas-are-citizens-airc-is-identity-provider]]. Verification: - cargo build --bin continuum-core-server clean - cargo build --lib --tests clean - Substrate boot composition still hosts Paige in correct channel (continuum, 11c1a7ac…) - Service loop fires inference (slow on CPU; iteration target) Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
4 tasks
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/parser from 8.29.1 to 8.46.1.
Release notes
Sourced from
@typescript-eslint/parser's releases.... (truncated)
Changelog
Sourced from
@typescript-eslint/parser's changelog.... (truncated)
Commits
3f5fbf6chore(release): publish 8.46.1aec785echore(release): publish 8.46.0255e9e2chore(release): publish 8.45.0c198052chore(release): publish 8.44.177056f7chore(release): publish 8.44.0ef9173cchore(release): publish 8.43.0d135909chore(release): publish 8.42.031a7336chore(release): publish 8.41.060c3b26chore(release): publish 8.40.0b2ee794chore(release): publish 8.39.1Maintainer changes
This version was pushed to npm by [GitHub Actions](https://www.npmjs.com/~GitHub Actions), a new releaser for
@typescript-eslint/parsersince 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)