### What This Does
Adds a new `wsh blocks list` subcommand that lists all blocks in all or
specified workspace, window, or tab. Includes filtering options and JSON
output for automation.
### Motivation
Wave users had no simple way to programmatically discover block IDs for
scripting and automation. This feature:
- Enables workflows like syncing Preview widgets with `cd` changes.
- Simplifies debugging and introspection.
- Provides a foundation for future CLI enhancements (focus/close
blocks).
### Usage
```wsh blocks [list|ls|get] [--workspace=<workspace-id>] [--window=<window-id>] [--tab=<tab-id>] [--view=<view-type>] [--json]```
Where `<view-type>` can be one of: term, terminal, shell, console, web, browser, url, preview, edit, sysinfo, sys, system, waveai, ai, or assistant.
### Notes
- Fully backward compatible.
- Code follows existing CLI patterns.
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)
The current layout system uses a complex bidirectional atom architecture
that forces every layout change to round-trip through the backend
WaveObject, even though **the backend never reads this data** - it only
queues actions via `PendingBackendActions`. By switching to a "write
cache" pattern where local atoms are the source of truth and backend
writes are fire-and-forget, we can eliminate ~70% of the complexity
while maintaining full persistence.
----
Every layout change (split, close, focus, magnify) currently follows
this flow:
```
User action
↓
treeReducer() mutates layoutState
↓
layoutState.generation++ ← Only purpose: trigger the write
↓
Bidirectional atom setter (checks generation)
↓
Write to WaveObject {rootnode, focusednodeid, magnifiednodeid}
↓
WaveObject update notification
↓
Bidirectional atom getter runs
↓
ALL dependent atoms recalculate (every isFocused, etc.)
↓
React re-renders with updated state
```
---
## Proposed "Write Cache" Architecture
### Core Concept
```
User action
↓
Update LOCAL atom (immediate, synchronous)
↓
React re-renders (single tick, all atoms see new state)
↓
[async, fire-and-forget] Persist to WaveObject
```
### Key Principles
1. **Local atoms are source of truth** during runtime
2. **WaveObject is persistence layer** only (read on init, write async)
3. **Backend actions still work** via `PendingBackendActions`
4. **No generation tracking needed** (no need to trigger writes)
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.
Working on AI SDK compatible backends for OpenAI and Anthropic. Thinking + ToolUse etc. For use with AI SDK useChat on frontend. Still needs more testing, WIP, but this is a good start. Want to get this committed to so I can work on more integrations.
Because I am on an internal network, I need to use a proxy server to
access Claude's services. However, Wave currently does not provide the
ability to configure the base URL, so I have added this feature in hopes
of being able to use it.
---------
Co-authored-by: sawka <mike@commandline.dev>
Gracefully handle prefix paths that don't exist, representing them as
directories so they can be escaped from.
Also removes the ".." file info from the backend, instead only creating
it on the frontend
Adds the S3 `fileshare` implementation
This also updates `wsh file cp` so it behaves more like `cp` for things
like copying directories and directory entries. It's not meant to align
with `cp` on everything, though. Our `wsh cp` will be recursive and will
create intermediate directories by default.
This also adds new aliases for `wsh view`: `wsh preview` and `wsh open`
---------
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
Co-authored-by: sawka <mike@commandline.dev>
Co-authored-by: Sylvia Crowe <software@oneirocosm.com>
While there is significant overlap between SettingsType and
AiSettingsType, they are distinct entities and should be treated as such
until more changes have been made.
This allows code generation to properly embed structs when embedded in
the original types. It affects the generation of `gotypes.d.ts` and
`metaconsts.go`.
Additionally, the `AiSettingsType` has been split off and embedded into
the original `SettingsType` to make schema generation easier.
Let's you drag and drop to copy files between preview widgets, even if
they use different connections.
---------
Co-authored-by: Evan Simkowitz <esimkowitz@users.noreply.github.com>
I was dumb and used `os.Rename` for copy on the same WSH remote. This
change makes it a proper copy, with recursion if needed.
---------
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
👋 Hello, I'm not sure if this warranted an Issue first but it seemed
small enough to just raise a PR. I'm happy to add something to the
documentation as well if you agree with the proposal.
There are some widgets that I'd rather not be displayed in the sidebar -
at the moment these are default widgets for which I cannot see any
existing means of omitting them via configuration. I'm proposing a
`display:hidden` field on the widget settings such that I can configure
the following:
```json
{
"defwidget@ai": {
"display:hidden": true
}
}
```
I'm considering this option to be distinct from any means of outright
"disabling" the widget - that is to say that I've not chosen to filter
the widgets from the configuration because I'm not fully aware of the
project goals. Where for example I imagine that it might be useful to be
able to interact with a widget or it's config via the CLI or shortcut
regardless of visibility?
<img width="1421" alt="example"
src="https://github.com/user-attachments/assets/7cafa942-727d-4140-8940-38b4022f2ef0"
/>
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.
This changes the .pem mimetype to application/x-pem-file. It also
changes the .pub mimetype to text/plain. Lastly, it updates
textApplicationMimetypes with this change.
This adds the ability to stream `tar` archives over channels between
`wsh` instances. The main use cases for this are remote copy and move
operations.
It also completes the `wavefs` implementation of the FileShare interface
to allow copy/move interoperability between wavefiles and other storage
types.
The tar streaming functionality has been broken out into the new
`tarcopy` package for easy reuse.
New `fileshare` functions are added for `CopyInternal`, which allows
copying files internal to a filesystem to bypass the expensive interop
layer, and `MoveInternal`, which does the same for moving a file within
a filesystem. Copying between remotes is now handled by `CopyRemote`,
which accepts the source `FileShareClient` as a parameter. `wsh`
connections use the same implementation for `CopyInternal` and
`CopyRemote` as they need to request the channel on the remote
destination, since we don't offer a way to pass channels as a parameter
to a remote call.
This also adds a recursive `-r` flag to `wsh file rm` to allow for
deleting a directory and all its contents.
S3 support will be addressed in a future PR.
---------
Co-authored-by: sawka <mike@commandline.dev>
Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
