## Summary
- Repair two stale Vitest lockfile references left after the current
main branch merge state.
- Restore `pnpm install --frozen-lockfile` so scheduled workflows can
reach their actual jobs.
## Testing
- `pnpm install --frozen-lockfile --ignore-scripts`
- `git diff --check`
## Context
The manually triggered `Update Sponsors SVG` workflow failed before
SponsorKit ran because `pnpm install --frozen-lockfile` could not find
the lockfile entry for a Vitest peer snapshot.
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
- Added a new PostHog client for capturing server-side business events such as Stripe webhooks and subscription state changes.
- Implemented various tracking functions for pricing funnel steps, character creation, and chat session starts.
- Enhanced the flux meter tests to handle partial charges and report unbilled flux correctly.
- Updated the CharacterDialog and Flux settings pages to track user interactions with analytics events.
- Introduced a mechanism to identify users on PostHog based on authentication state to ensure accurate funnel tracking.
- Added necessary dependencies for PostHog integration in the project.
## Summary
Adds the experimental Godot stage sidecar path for `stage-tamagotchi`.
This PR wires the existing Tamagotchi model selection flow into an
external Godot runtime window. The renderer gates Godot scene input to
VRM models, Electron main materialises the selected model bytes to a
local file, and the Godot sidecar receives the native path over a local
WebSocket bridge before importing and displaying the avatar at runtime.
## What Changed
- Added a typed Godot scene input contract with `format: "vrm"`.
- Added renderer-side VRM-only gating before sending selected model data
to Electron main.
- Added Electron main sidecar management for:
- launching Godot
- starting the local WebSocket bridge
- materialising selected VRM bytes under app `userData`
- forwarding scene apply messages to Godot
- optional remote debugging support
- Added Godot runtime scripts for:
- sidecar startup and WebSocket orchestration
- message envelope parsing
- avatar import and atomic replacement
- runtime VRM import through Godot `GLTFDocument`
- Added engine-local docs for runtime import, live debugging, vendor
patches, and current VRM support boundaries.
- Removed temporary tests after using them to verify the glue behaviour
locally, to keep the review surface smaller.
## Vendor Code Note
A large part of this PR is vendored Godot add-on code, not AIRI business
logic.
The bulk of the added files under:
- `engines/stage-tamagotchi-godot/addons/vrm/**`
- `engines/stage-tamagotchi-godot/addons/Godot-MToon-Shader/**`
comes from V-Sekai Godot VRM / MToon add-ons. These files are required
because Godot plugins are project-local source/assets rather than
package-manager dependencies.
The intended review scope for vendor code is limited to:
- source baseline metadata
- license/plugin config
- Godot-generated metadata notes
- the documented local patch in `addons/vrm/vrm_extension.gd`
The application/runtime code to review is mainly under:
- `apps/stage-tamagotchi/src/shared/eventa/index.ts`
- `apps/stage-tamagotchi/src/renderer/pages/settings/models/`
- `apps/stage-tamagotchi/src/main/services/airi/godot-stage/`
- `engines/stage-tamagotchi-godot/scripts/`
## Current Boundary
This is still an experimental G1 Godot sidecar path.
The runtime scene input contract accepts `.vrm` files only. The current
Godot runtime importer covers the VRM 0.x path used by the local fixture
through AIRI’s runtime bridge over the vendored VRM extension. VRM 1.0
editor import support exists in the vendored add-on, but the sidecar
runtime importer does not yet register the full `VRMC_*` extension set,
so this PR does not claim full VRM 1.0 runtime support.
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
## Description
<!-- Please insert your description here and especially provide info
about the "what" this PR is solving -->
It has no effect. The actions are run in parallel anyway. They have been
previously updated to not fail when run in parallel.
## Linked Issues
<!-- Optional, if you have any -->
## Additional Context
<!-- e.g. is there anything you'd like reviewers to focus on? -->
## Description
This PR introduces `@proj-airi/stage-tamagotchi-godot` as the initial
Godot C# workspace package for the desktop-only `stage-tamagotchi` stage
runtime track.
The current scope is intentionally limited to G0 bootstrap work:
- add the Godot/.NET project files and workspace wrapper files
- establish the package boundary for the Godot-backed desktop stage
runtime
- add a minimal runnable scene and script so the Godot project can be
opened, built, and executed inside the repo
Concretely, this PR adds:
- the new `packages/stage-tamagotchi-godot` package
- Godot project files (`project.godot`, `.csproj`, `.sln`, editor/config
files)
- a minimal `stage-root` scene and `StageRoot.cs` script
- basic visible scene contents for runtime validation (`Camera3D`,
`OmniLight3D`, `Box`)
- a package README describing scope and ownership boundaries
- minimal package scripts for build/typecheck via `dotnet build`
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
Co-authored-by: LemonNeko <self@lemonneko.moe>
Co-authored-by: Garfield Lee <Garfield550@users.noreply.github.com>
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
Co-authored-by: Neko <neko@ayaka.moe>
Depends on #1487
## Summary
- Introduce `packages/core-agent` — a new pure-runtime package that
extracts zero-Vue/Pinia algorithmic logic from `@proj-airi/stage-ui`,
following a "compatible facade + core sinking" strategy
- Migrate shared chat types, LLM streaming types, chat hook registry,
session message merge logic, context registry algorithm, and LLM service
utilities into `core-agent`
- `stage-ui` files are preserved as re-exports / thin wrappers — all
external imports, store IDs, and public APIs remain unchanged
## Motivation
`stage-ui` currently mixes pure agent runtime logic (algorithms, type
definitions, stateless utilities) with Vue/Pinia state management and
browser-specific adapters. This coupling makes it hard to:
- Test agent logic in isolation
- Reuse agent algorithms outside of Vue contexts (e.g., server-side,
CLI, other frameworks)
- Reason about the boundary between "what the agent does" vs "how the UI
manages state"
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
Co-authored-by-agent: Unknown <unknown@example.com>
Makito