* add automatic OSC 7 support to bash and zsh
* add new wave OSC 16162 (planck length) to get up-to-date shell
information into blockrtinfo. currently implemented only for zsh. bash
will not support as rich of data as zsh, but we'll be able to do some.
* new rtinfo will be used to provide better context for AI in the
future, and to make sure AI is running safe commands.
* added a small local machine description to tab context (so AI knows
we're running on MacOS, Linux, or Windows)
Massive PR, over 13k LOC updated, 128 commits to implement the first pass at the new Wave AI panel. Two backend adapters (OpenAI and Anthropic), layout changes to support the panel, keyboard shortcuts, and a huge focus/layout change to integrate the panel seamlessly into the UI.
Also fixes some small issues found during the Wave AI journey (zoom fixes, documentation, more scss removal, circular dependency issues, settings, etc)
checkpoint. good to merge. we have a working tsunami view inside of wave (with lots of caveats). but enough for some dev testing. merge so we dont drift too far from main and while we're at a stable point.
no need for yarn anymore in 2025 (especially yarn berry which is just an AI + githubactions nightmare). switch to the more standard npm. update go version to 1.24 across the board. cleanup some vite stuff, and deps. all-around improvements.
Huge PR. 135 commits here to rebuild waveapps into the "Tsunami" framework.
* Simplified API
* Updated system.md prompt
* Basic applications building and running
* /api/config and /api/data support
* tailwind styling
* no need for async updates
* goroutine/timer primitives for async routing handling
* POC for integrating 3rd party react frameworks (recharts)
* POC for server side components (table.go)
* POC for interacting with apps via /api/config (tsunamiconfig)
Checkpoint. Still needs to be tightly integrated with Wave (lifecycle, AI interaction, etc.) but looking very promising 🚀
Adds schema.json support to the settings file to provide type hints and
other eventual details. This also adds a system to easily add more
schema files for other type of configurations.
I'm making steps to simplify our build dependencies, consolidating our C
compiler requirements so we only depend on Zig.
Before, we used Zig for x64 but not for arm64. This meant that users
using an ARM dev machine would need to install `build-essentials` and
Zig. We also required MinGW-w64 on Windows, which is a pain to install
since it can be provided by a bunch of different tools, the smallest of
which is like a 2GB install.
Adds warning and docs to let users know when they're running in ARM
translation mode. Also lets them configure to always dismiss if they
don't care.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Added a configuration option to dismiss architecture warnings during
application startup.
- Introduced new FAQs addressing ARM64 translation warnings and
instructions for joining beta builds.
- Added platform-specific requirements for macOS, Windows, and Linux in
the getting started documentation.
- **Bug Fixes**
- Enhanced build command flexibility by allowing dynamic command-line
arguments during the build process.
- **Documentation**
- Updated configuration documentation to include the new dismiss
architecture warning key.
- Minor formatting adjustments in FAQs and getting started
documentation.
- Clarified platform compatibility details in the README.
- **Chores**
- Added a new constant for the dismiss architecture warning
configuration key.
- Introduced a new field for managing architecture warning settings in
the application configuration.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
This adds the new tasks `docsite:start`, `docsite:build:public`,
`docsite:build:embedded`, `storybook:build`, and `copyfiles:*:*` to
Taskfile.
It also updates the "Build Helper" and "Docsite and Storybook CI/CD"
workflows to use these new tasks.
It also makes the docsite embedded build a dependency of the electron
tasks, ensuring that the embedded docsite is included when building
locally.
Tested and confirms this works on Windows
Going forward for new installations, config and data files will be
stored at the platform default paths, as defined by
[env-paths](https://www.npmjs.com/package/env-paths).
For backwards compatibility, if the `~/.waveterm` or `WAVETERM_HOME`
directory exists and contains valid data, it will be used. If this check
fails, then `WAVETERM_DATA_HOME` and `WAVETERM_CONFIG_HOME` will be
used. If these are not defined, then `XDG_DATA_HOME` and
`XDG_CONFIG_HOME` will be used. Finally, if none of these are defined,
the [env-paths](https://www.npmjs.com/package/env-paths) defaults will
be used.
As with the existing app, dev instances will write to `waveterm-dev`
directories, while all others will write to `waveterm`.
