@floless/app 0.34.1 → 0.34.2

package/dist/floless-server.cjs

@@ -52856,7 +52856,7 @@ function appVersion() {
   return resolveVersion({
     isSea: isSea2(),
     sqVersionXml: readSqVersionXml(),
-    define: true ? "0.34.1" : void 0,
+    define: true ? "0.34.2" : void 0,
     pkgVersion: readPkgVersion()
   });
 }
@@ -52866,7 +52866,7 @@ function resolveChannel(s) {
   return "dev";
 }
 function appChannel() {
-  return resolveChannel({ isSea: isSea2(), define: true ? "0.34.1" : void 0 });
+  return resolveChannel({ isSea: isSea2(), define: true ? "0.34.2" : void 0 });
 }
 
 // oauth-presets.ts
@@ -56264,6 +56264,8 @@ var PRODUCT_SKILLS = [
   //        drive the floless.app CLI / desktop bridge from the user's AI
   "floless-app-onboarding",
   //    guided, re-runnable tour of AWARE + floless.app for new users
+  "floless-app-queue",
+  //         list the queued Dashboard requests in plain English + let the user pick which to process
   "floless-app-rebake",
   //        re-read & re-bake a baked Visual Input (B3) after the user swaps the drawing
   "floless-app-report-issue",

package/dist/skills/floless-app-bridge/SKILL.md

@@ -78,7 +78,10 @@ digraph { "GET /api/requests" -> "for each pending" -> "read app .flo + node" ->
 ```
 
 1. **Pull**: `curl -s http://127.0.0.1:4317/api/requests` → take the `pending` ones (oldest first).
-   Summarize them for the user before acting on anything destructive.
+   Summarize them for the user before acting on anything destructive. **When several are queued and
+   the user wants to choose which to apply (not just the oldest), use the `floless-app-queue` skill** —
+   it lists the queue in plain English and asks which to process, then routes each pick to the owning
+   authoring skill (`floless-app-workflows` / `-tweak-contract` / `-ui` / `-rebake`).
 2. **Locate the app source.** The editable `.flo` is the repo copy `demos/<appId>/<appId>.flo`
    (preferred — it's version-controlled); the installed copy is `~/.aware/apps/<appId>/<appId>.flo`.
    Edit the **repo** copy. `GET /api/app/<appId>` returns the parsed nodes + each node's

package/dist/skills/floless-app-queue/SKILL.md

@@ -0,0 +1,88 @@
+---
+name: floless-app-queue
+description: This skill should be used when the user has MULTIPLE floless.app requests queued from the Dashboard and wants to see them and choose which to process, rather than the AI just picking up the oldest one. Use it when the user says things like "what's in my floless queue", "list my queued floless requests", "show me the pending requests and let me pick", "I queued a few tweaks — which should I apply?", "let me choose what to process", or "pick from the floless queue". It lists the pending requests from GET /api/requests in plain language (type, which app/node, the instruction), asks the user which one(s) to apply, then hands each chosen request to the owning skill (floless-app-workflows / -tweak-contract / -ui / -rebake) which applies it and clears it. It is the interactive picker that sits in front of floless-app-bridge (which is the actual pull-apply-clear engine).
+metadata:
+  version: 0.1.0
+---
+
+# floless.app queue picker
+
+floless.app is the **thin web UI**; the **terminal AI (you) is the brain**. The UI cannot edit
+`.flo` files — it **queues requests** (Tweak / use-template / customize-UI / rebake / edit-contract)
+to a local API. The **`floless-app-bridge`** skill pulls those and applies them, but it processes
+the queue **oldest-first with no choice step**. This skill adds the missing affordance: **list the
+whole queue in plain English and let the user pick which one(s) to process** — then route each pick
+through the normal bridge flow.
+
+Use this when there are **several** pending requests and the user wants to triage. For a single
+"apply the tweak I just queued" or a pasted `[floless-request …]` marker, `floless-app-bridge` is
+enough.
+
+## 1. Fetch the queue
+
+The server runs locally on **port 4317** (override: `$PORT`). Confirm it's up, then read the queue:
+
+```bash
+curl -s http://127.0.0.1:4317/api/health    # → {"ok":true,...}; if down, user runs `cd server && npm run dev`
+curl -s http://127.0.0.1:4317/api/requests  # → { "ok": true, "requests": [ ... ] }
+```
+
+`requests` is every **pending** request, oldest first. If it's empty, tell the user the queue is
+empty and stop — there is nothing to pick.
+
+## 2. Present the queue in plain language
+
+Render a **numbered list** the user can choose from. For each request show the index, a short id
+(first 8 chars), and a one-line plain-English summary by `type` — never raw JSON. The fields are
+documented in `floless-app-bridge`; the five types map to:
+
+| `type` | Plain-English line | Owning skill |
+|---|---|---|
+| `tweak` | "Tweak node **`<nodeId>`** in **`<appId>`** — *<instruction>*" | `floless-app-workflows` |
+| `use-template` | "Add template **<template.name>** to **`<appId>`**" | `floless-app-workflows` |
+| `tweak-contract` | "Edit the steel-takeoff contract for **`<appId>`** — *<instruction>* (+N screenshot(s))" | `floless-app-tweak-contract` |
+| `ui-customize` | "Customize the Dashboard (optionally `panel <panelId>`) — *<instruction>*" | `floless-app-ui` |
+| `rebake` | "Re-read the **<inputName>** drawing (<sourceName>) in **`<appId>`** — *<instruction>*" | `floless-app-rebake` |
+
+Note the count of screenshots for requests that carry `snapshots`. If a request has an unfamiliar
+`type`, show it verbatim and flag it rather than guessing what it does.
+
+## 3. Ask which to process
+
+Ask the user to choose: **one, several, all, or none** (e.g. "1 and 3", "all", "skip 2"). This skill
+is read-and-choose: **never apply a request the user did not pick.** Wait for the answer before
+touching any `.flo`, contract, or panel.
+
+## 4. Process each chosen request — route to the owning skill
+
+For each pick, hand it to the skill in the table above (the type→skill routing
+`floless-app-bridge` uses for pasted markers, extended here to also cover `tweak-contract`).
+That skill does the real work — read the app's
+current `.flo`/contract/panel, apply the change, recompile if needed — **and clears the request**:
+
+```bash
+curl -s -X DELETE http://127.0.0.1:4317/api/requests/<id>   # the UI's "requests" badge updates live over SSE
+```
+
+Process the picks in the order the user gave (or oldest-first if they said "all"). Re-run the
+owning skill's normal verification before reporting each one done.
+
+## 5. The un-picked rest
+
+Leave any request the user did **not** pick in the queue — do nothing to it. If the user wants to
+**discard** one without processing, `DELETE /api/requests/<id>`; to drop the whole queue at once
+the UI's "Clear all" maps to `DELETE /api/requests`. Only delete on an explicit ask.
+
+When you're done, tell the user what was processed and **what is still queued**, so the picker can
+be re-run for the remainder.
+
+## Guardrails
+
+- **You are the brain; the UI only queues intent.** This skill never composes a `.flo` itself — it
+  triages the queue and delegates each pick to the owning authoring skill.
+- **Choose, don't bulk-apply.** Listing is non-destructive; only act on the user's explicit picks.
+  Never silently process the whole queue without an explicit "all".
+- **Always clear a processed request** (the owning skill does the `DELETE`) so the UI's count
+  reflects reality; only `DELETE` an *un*-processed request when the user asks to discard it.
+- **Don't invent request types** — only the five real ones exist; surface anything else rather than
+  guessing. This is the picker; **`floless-app-bridge`** is the puller/applier it sits in front of.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@floless/app",
-  "version": "0.34.1",
+  "version": "0.34.2",
   "type": "module",
   "description": "Thin localhost host for floless.app — serves web/ and shells the aware CLI. No engine, no LLM.",
   "bin": {