fruxon 0.21.2__tar.gz → 2.0.0__tar.gz

{fruxon-0.21.2 → fruxon-2.0.0}/HISTORY.md

@@ -1,5 +1,64 @@
 # History
 
+## Unreleased — `fruxon triggers check`, and an automation's Configuration tab in `fruxon dash`
+
+- **`fruxon triggers check <trigger> [-o json]`** audits a work-shape
+  automation part by part: the automation, its source (by its last pass),
+  every stage (a PROCESS stage's agent runs and reaches what it calls; an ASK
+  stage has someone to ask and is not close to expiring questions), the
+  outcome note's contact, the weekly budget and the dead items. Same
+  `{…, overall, checks[]}` contract and exit codes as `agents check`.
+  The audit is `fruxon.checks.ledger.check_ledger`.
+- `fruxon dash`: an automation's `2` Configuration tab shows those rows with
+  the selected one explained in place, `t` tests the source (admits nothing),
+  `p` previews what a stage sends its agent (saves nothing), and lists the
+  shape.
+
+## Unreleased — `fruxon dash`, a read-only console for an Application
+
+Everything else in the CLI prints and exits. `fruxon dash` stays open and
+shows one Application the way the web app's overview does, in the terminal.
+
+- **`fruxon dash [--app A] [--demo] [--ground black|ink]`**. Home: runs,
+  spend, items finished and who is waiting in big digits; every agent and
+  automation; what needs a person. An agent: overview, the `agents check`
+  rows plus credential, model-config and budget health, runs and traces. An
+  automation: its stages and counts, items per day, what failed, its items.
+  Live parts every 5 s, totals every minute. Read-only.
+- Needs the new `tui` extra: `pip install "fruxon[tui]"` (Textual). Nothing
+  imports it until the command runs, so the CLI starts as fast as before.
+- `--demo` is a made-up workspace with a pinned clock and seeded live runs,
+  for recordings; `docs/tui/demo.tape` records it with VHS.
+- The audit behind `agents check` moved to `fruxon.checks.agent` and returns
+  `CheckResult` rows; the command's output and exit codes are unchanged.
+- New client reads: `get_application_spend`, `get_application_activity_counts`,
+  `get_application_support_kpis`, `get_agent_conversation_timeseries`,
+  `get_agent_judge_activity`, `get_agent_cost_forecast`,
+  `get_agent_llm_config_health`, `get_agent_credential_health`.
+
+## Unreleased — edit and publish an integration config from the CLI
+
+`integrations configs` could only `list` and `get`, so changing a config
+(clearing Agentit's BAFI egress pin, 2026-10-19) meant the dashboard. Uses the
+backend's existing `PATCH …/configs/{config}` and `POST …/configs/{config}:publish`.
+
+- **`fruxon integrations configs update <integration> <config> --file <patch.json>`**
+  patches the config's draft. The file holds only the fields to change
+  (`{"egressCountry": ""}` clears an egress pin); `--schema` prints the shape.
+  The server ignores fields it doesn't know and reads `null` as "unchanged",
+  so an empty patch, an unknown field or a `null` exits 12 before anything is
+  sent. Prints the config with secrets masked by the server, never the values
+  sent.
+- **`fruxon integrations configs publish <integration> <config> [--note T]`**
+  makes the draft the revision tool calls resolve. Shows what is live now and
+  asks; `--yes` skips it and is required in agent mode (exit 16 without).
+  Prints the new revision's `id` and `version`.
+- `FruxonClient.update_integration_config(integration, config_id, body)` and
+  `publish_integration_config(integration, config_id, note=None)`. The
+  publish response is the snapshot with its credentials decrypted; the client
+  returns only `id`, `configId`, `version`, `note`, `sandboxMode`,
+  `egressCountry`, `createdBy` and `createdAt`.
+
 ## Unreleased — telemetry names the command, the person and the workspace
 
 CLI usage in Mixpanel had three gaps. The command name stopped at two

fruxon-0.21.2/README.md → fruxon-2.0.0/PKG-INFO

@@ -1,3 +1,38 @@
+Metadata-Version: 2.5
+Name: fruxon
+Version: 2.0.0
+Summary: The Fruxon SDK is a lightweight Python client for integrating with the Fruxon platform.
+Project-URL: bugs, https://github.com/fruxon-ai/fruxon-sdk/issues
+Project-URL: changelog, https://github.com/fruxon-ai/fruxon-sdk/blob/main/HISTORY.md
+Project-URL: homepage, https://github.com/fruxon-ai/fruxon-sdk
+Author-email: Hagai Cohen <hagai@fruxon.com>
+Maintainer-email: Hagai Cohen <hagai@fruxon.com>
+License: MIT
+License-File: LICENSE
+Classifier: Development Status :: 3 - Alpha
+Classifier: Intended Audience :: Developers
+Classifier: License :: OSI Approved :: MIT License
+Classifier: Programming Language :: Python :: 3
+Classifier: Programming Language :: Python :: 3.10
+Classifier: Programming Language :: Python :: 3.11
+Classifier: Programming Language :: Python :: 3.12
+Classifier: Programming Language :: Python :: 3.13
+Requires-Python: >=3.10
+Requires-Dist: certifi>=2024.2.2
+Requires-Dist: click>=8.2
+Requires-Dist: keyring>=24.0
+Requires-Dist: typer>=0.13
+Provides-Extra: test
+Requires-Dist: coverage; extra == 'test'
+Requires-Dist: ipdb; extra == 'test'
+Requires-Dist: pre-commit; extra == 'test'
+Requires-Dist: pytest; extra == 'test'
+Requires-Dist: ruff; extra == 'test'
+Requires-Dist: ty; extra == 'test'
+Provides-Extra: tui
+Requires-Dist: textual>=8.2; extra == 'tui'
+Description-Content-Type: text/markdown
+
 # fruxon
 
 [![PyPI version](https://img.shields.io/pypi/v/fruxon.svg)](https://pypi.org/project/fruxon/)
@@ -106,7 +141,7 @@ Integrations + tools:
 | Command | What it does |
 | --- | --- |
 | `fruxon integrations list/get/create/update/verify/open` | Manage external integrations — the connections agents draw tools from. `create`/`update`/`verify` take a `--file` JSON body; `open` opens the dashboard. |
-| `fruxon integrations configs list/get` | Inspect the per-integration auth/config records. |
+| `fruxon integrations configs list/get/update/publish` | The per-integration auth/config records. `update --file` patches a config's draft (only the fields sent; `{"egressCountry": ""}` clears an egress pin) and prints it with secrets masked; `publish` makes the draft the revision tool calls resolve, asks first (`--yes` in agent mode), and prints the new revision's `id` and `version`, never the credentials. |
 | `fruxon integrations authorize <integration>` | Mint an application-level OAuth authorization URL to **connect** an integration — auto-detects its OAuth2 method (`--auth-method` to pick, `--scope`/`--config-param` to tune). OAuth needs a browser consent step, so the CLI hands you the link; a human clicks it, and the connection is saved as a tenant config a slot can pin. |
 | `fruxon integrations triggers <integration>` | List the event types an integration can fire an agent on — each descriptor's `id` is the `eventType` a trigger listens for, plus the `payloadFields` (dotted paths) a binding's `parameterMappings` can read. Discovery for wiring an inbound-event trigger without guessing. |
 | `fruxon integrations mcp …` | Inspect and enable the MCP server for an integration. |
@@ -130,6 +165,7 @@ Integrations + tools:
 | `fruxon triggers ledger funnel/items/cursor/transitions/effects/batches` | The work items a schedule trigger's work shape admitted. `funnel` counts per stage and status (every item is in exactly one cell). `items` is the grid — `--stage`, `--status`, `--ignore-reason`, `--item-key` (client-side; the endpoint has no such filter), each item's `label` (what the Work grid calls the row, as against the provider's opaque `itemKey`), and its accumulated `data`, which is where a stage's declared `produces` keys land. A listing is **one page of 20** that reports how many matched in total — a ledger's healthy state is thousands of rows served ten per request, so an unbounded walk is rate-limited long before the end; `-n` sizes the page and `--all` walks the lot. `--ignore-reason` narrows to the items one exclusion reason set aside — the same filter `redrive-many` selects by, matched whole and case-sensitively, so it is how you read a batch before putting it back. `--where field=value` (or `!=`, repeatable, dotted for a nested field) selects by what a stage wrote into `data` — `--where destination=SKIP` — matched whole and case-sensitively, as text and as the number, boolean or null it spells; the server filters and the CLI re-applies it, so an older server is slower, never wrong. `cursor` is the watermark and its freshness. `transitions` is one item's attempt history; `effects` is what it did to the outside world — an `UNKNOWN` row parks the item until someone settles it. `batches` is what an ASK stage is waiting on a human for — read its `delivery` first, because `UNDELIVERABLE` / `FAILED` mean nobody was asked and nobody will answer while the batch, the count and the stage all look healthy (`QUEUE_ONLY` is not a fault); a WAITING item's `batchId` is the join to it, and the pairing is total, so one `--open-only` listing resolves every waiting row. `batches --answers <batch>` is one question's answers item by item — what the person gave (`given`), what was handed back (`answer`), what the item holds now (`current`), with `mismatch` where the first two differ (a prose reply is every item's `given` at once, `givenIsReply`, and is never compared); a `given` the server did not record is read from the resolving run's sheet read (`givenFrom: "trace"`, `--no-trace` to skip). `batches --transcript <batch>` prints the conversation it was asked in, read under the agent that owns it — the stage's asking agent, not the desk that talks to the person. `funnel` and `items` also carry `cost` (all-in USD) and `runs` — so the funnel says *which stage* the money goes to, not merely how much. An item's `runs` spans every stage it passed through and so is not `stageAttempts`, which resets per stage; a `Cost` of `—` means nothing there has ever been claimed, as against `$0.0000`, which means it ran and was free. Cost is not sortable: the endpoint's `--order-by` allow-list does not carry it. |
 | `fruxon triggers ledger passes` | Every time the automation fired, newest first — `admitted` (what the door took), `dispatched` (what the pass claimed and sent to work, questions parked on a human included), `completed` (how many of *this pass's* dispatches reached the terminal stage), `runs`, and the pass's all-in USD. `runs` sits **below** `dispatched` while runs are in flight or when a dispatch went to a person rather than a model — that gap is normal, not a lost item. And a pass's `cost` **rises after** it fired, as those runs finish, so a pass read seconds later reports a floor rather than its bill. An `outcome` other than `FIRED` means no sweep happened: `FILTERED` / `COALESCED` are healthy (nothing to do, or folded into a pass already running), `FAILED` / `FILTER_ERROR` are not. `-n/--limit` bounds the walk. |
 | `fruxon triggers ledger spend/spend-series/item-series` | What the automation spent and what happened to its items, over time. `spend` is the **current UTC calendar** day, week (from Monday) or month (`--period`), so a weekly read on a Monday is hours of spend, not seven days — the figure the automation's spend chip shows: item runs, the conversations its questions are held in, and its report, one row per agent and part (`ITEM_RUNS` / `CONVERSATIONS` / `REPORTS` / `OTHER`). It is **not** the funnel's `cost`, which files item runs under the cell each item sits in *now*; the two overlap, so never add them. `spend-series` is the same figure per `day` or `week` over `--since`/`--until` (default the last 30 days), `--by-stage` adding a column per agent and part; it reads live run records, so a window older than the workspace's run history is counted from `countedFromMs` and the CLI says so. `--interval hour` is refused (tokens are priced per day), and a `week` bucket starts on a Thursday, so it does not line up with `spend --period weekly`. `item-series` counts admitted, finished, set aside and dead per `hour`, `day` or `week` — **events, not items**: a re-driven item that finishes again counts twice and an operator's ignore counts as set aside. Both series omit empty buckets; the footer says how many had anything. A server that predates the series reads 404s (exit 11). |
+| `fruxon triggers check <trigger>` | Audit whether a work-shape automation can move its items, part by part in the order an item meets them: on and taking items in, the last pass read its source, each PROCESS stage's agent exists with a deployed revision and working credentials and models (a rejected credential's row says how many items failed there since), each ASK stage's contact is declared and bound on the asking agent and its oldest question has not waited past a fifth of its answer window, the outcome note's contact reaches a person, this week's spend against the weekly limit, and how many items died in the last 7 days. `{trigger, overall, checks[]}` like `agents check`; exits 12 only on a hard fail, warnings stay 0. Read-only. |
 | `fruxon triggers budget list/get/set/delete` | Spend limits on an automation **as a whole** (`--period DAILY/WEEKLY/MONTHLY`, UTC calendar windows), counting every production run it caused whichever agent made it. Once one is enforced they govern its runs, which then meet only these limits and not the agents' own; with none enforced, each stage stops at its agent's own limit. None by default and every one removable. An enforced limit refuses new work at the limit (stage runs, passes, a question's opening, the report) and holds the stages until the window resets, while turns of conversations it already opened still run (up to 110%); `--no-enforce` only alerts the Application's admins. Needs Editor. |
 | `fruxon triggers ledger redrive/ignore/settle/cancel-batch` | The operator verbs; all confirm and refuse without `--yes` in agent mode. `redrive` returns a DEAD or FAILED item to the queue with its attempts reset — settle any `UNKNOWN` effect first or the next attempt hits the same refusal. `ignore` excludes an item for a **required** reason, which is the only thing separating IGNORED from DEAD later. `settle` answers an effect the platform could not confirm (`--landed` / `--did-not-land` + `--reason`); wrong in the second direction duplicates the write. `cancel-batch` calls off a question — the items go back to READY and a later pass re-batches them. |
 | `fruxon triggers ledger set-data` | Correct a parked (DEAD / FAILED / IGNORED) item's `data` before re-driving it — the value a stage recorded wrong, such as an ASK answer written as `SKIP`, which a plain re-drive would route on again. `--set path=value` (or `path:=<json>`, repeatable) on a top-level key the item carries or a path the shape declares (`produces`, `answeredWhenPath`); a misspelled key is refused with the settable list rather than added. `--reason` is required and lands on the item's history beside every old → new value. `--redrive` re-drives in the same transaction; `redrive` and `redrive-many` take `--set` too. |
@@ -157,6 +193,30 @@ Integrations + tools:
 | `fruxon agents channels list` / `fruxon agents endpoints` | Inspect a networked agent's channel bindings and resolved provider endpoints (with bot identity). Superseded by `applications entry-points list`, which names the Application answering on each address; these read endpoints outside the published API. |
 | `fruxon skills list/show/create/update/delete` | Browse the tenant's product-skill catalog and author its own skills (resources that attach to agents at runtime). |
 
+### `fruxon dash` — the console
+
+![fruxon dash --demo](https://raw.githubusercontent.com/fruxon-ai/fruxon-sdk/develop/docs/tui/demo.gif)
+
+A read-only, full-screen console for one Application. Home has the week's runs,
+spend and finished items, every agent with its share of the spend, every
+automation with what it holds, and what needs a person; Enter opens an agent
+(overview, the `agents check` rows plus credential, model and budget health,
+runs and their traces) or an automation (its stages, items per day, what
+failed, the `triggers check` rows, a source test and a stage preview). Live
+parts refresh every 5 seconds, totals every minute. It changes nothing.
+
+```bash
+pip install "fruxon[tui]"     # the console runs on Textual, an optional extra
+fruxon dash                   # the Application with the most agents
+fruxon dash --app "Support & Ops"
+fruxon dash --demo            # a made-up workspace, for a first look or a recording
+```
+
+Keys: `↑↓` move, `enter` open, `tab` next panel, `esc` back, `1 2 3` tabs,
+`7 3 1` (or `w` on a tabbed screen) the time window, `a` another Application,
+`r` refresh, `?` every key, `q` quit. It needs a terminal, so agent mode and
+piped output are refused (exit 16).
+
 ### `fruxon agents draft run` — examples
 
 ```bash

fruxon-0.21.2/PKG-INFO → fruxon-2.0.0/README.md

@@ -1,36 +1,3 @@
-Metadata-Version: 2.5
-Name: fruxon
-Version: 0.21.2
-Summary: The Fruxon SDK is a lightweight Python client for integrating with the Fruxon platform.
-Project-URL: bugs, https://github.com/fruxon-ai/fruxon-sdk/issues
-Project-URL: changelog, https://github.com/fruxon-ai/fruxon-sdk/blob/main/HISTORY.md
-Project-URL: homepage, https://github.com/fruxon-ai/fruxon-sdk
-Author-email: Hagai Cohen <hagai@fruxon.com>
-Maintainer-email: Hagai Cohen <hagai@fruxon.com>
-License: MIT
-License-File: LICENSE
-Classifier: Development Status :: 3 - Alpha
-Classifier: Intended Audience :: Developers
-Classifier: License :: OSI Approved :: MIT License
-Classifier: Programming Language :: Python :: 3
-Classifier: Programming Language :: Python :: 3.10
-Classifier: Programming Language :: Python :: 3.11
-Classifier: Programming Language :: Python :: 3.12
-Classifier: Programming Language :: Python :: 3.13
-Requires-Python: >=3.10
-Requires-Dist: certifi>=2024.2.2
-Requires-Dist: click>=8.2
-Requires-Dist: keyring>=24.0
-Requires-Dist: typer>=0.13
-Provides-Extra: test
-Requires-Dist: coverage; extra == 'test'
-Requires-Dist: ipdb; extra == 'test'
-Requires-Dist: pre-commit; extra == 'test'
-Requires-Dist: pytest; extra == 'test'
-Requires-Dist: ruff; extra == 'test'
-Requires-Dist: ty; extra == 'test'
-Description-Content-Type: text/markdown
-
 # fruxon
 
 [![PyPI version](https://img.shields.io/pypi/v/fruxon.svg)](https://pypi.org/project/fruxon/)
@@ -139,7 +106,7 @@ Integrations + tools:
 | Command | What it does |
 | --- | --- |
 | `fruxon integrations list/get/create/update/verify/open` | Manage external integrations — the connections agents draw tools from. `create`/`update`/`verify` take a `--file` JSON body; `open` opens the dashboard. |
-| `fruxon integrations configs list/get` | Inspect the per-integration auth/config records. |
+| `fruxon integrations configs list/get/update/publish` | The per-integration auth/config records. `update --file` patches a config's draft (only the fields sent; `{"egressCountry": ""}` clears an egress pin) and prints it with secrets masked; `publish` makes the draft the revision tool calls resolve, asks first (`--yes` in agent mode), and prints the new revision's `id` and `version`, never the credentials. |
 | `fruxon integrations authorize <integration>` | Mint an application-level OAuth authorization URL to **connect** an integration — auto-detects its OAuth2 method (`--auth-method` to pick, `--scope`/`--config-param` to tune). OAuth needs a browser consent step, so the CLI hands you the link; a human clicks it, and the connection is saved as a tenant config a slot can pin. |
 | `fruxon integrations triggers <integration>` | List the event types an integration can fire an agent on — each descriptor's `id` is the `eventType` a trigger listens for, plus the `payloadFields` (dotted paths) a binding's `parameterMappings` can read. Discovery for wiring an inbound-event trigger without guessing. |
 | `fruxon integrations mcp …` | Inspect and enable the MCP server for an integration. |
@@ -163,6 +130,7 @@ Integrations + tools:
 | `fruxon triggers ledger funnel/items/cursor/transitions/effects/batches` | The work items a schedule trigger's work shape admitted. `funnel` counts per stage and status (every item is in exactly one cell). `items` is the grid — `--stage`, `--status`, `--ignore-reason`, `--item-key` (client-side; the endpoint has no such filter), each item's `label` (what the Work grid calls the row, as against the provider's opaque `itemKey`), and its accumulated `data`, which is where a stage's declared `produces` keys land. A listing is **one page of 20** that reports how many matched in total — a ledger's healthy state is thousands of rows served ten per request, so an unbounded walk is rate-limited long before the end; `-n` sizes the page and `--all` walks the lot. `--ignore-reason` narrows to the items one exclusion reason set aside — the same filter `redrive-many` selects by, matched whole and case-sensitively, so it is how you read a batch before putting it back. `--where field=value` (or `!=`, repeatable, dotted for a nested field) selects by what a stage wrote into `data` — `--where destination=SKIP` — matched whole and case-sensitively, as text and as the number, boolean or null it spells; the server filters and the CLI re-applies it, so an older server is slower, never wrong. `cursor` is the watermark and its freshness. `transitions` is one item's attempt history; `effects` is what it did to the outside world — an `UNKNOWN` row parks the item until someone settles it. `batches` is what an ASK stage is waiting on a human for — read its `delivery` first, because `UNDELIVERABLE` / `FAILED` mean nobody was asked and nobody will answer while the batch, the count and the stage all look healthy (`QUEUE_ONLY` is not a fault); a WAITING item's `batchId` is the join to it, and the pairing is total, so one `--open-only` listing resolves every waiting row. `batches --answers <batch>` is one question's answers item by item — what the person gave (`given`), what was handed back (`answer`), what the item holds now (`current`), with `mismatch` where the first two differ (a prose reply is every item's `given` at once, `givenIsReply`, and is never compared); a `given` the server did not record is read from the resolving run's sheet read (`givenFrom: "trace"`, `--no-trace` to skip). `batches --transcript <batch>` prints the conversation it was asked in, read under the agent that owns it — the stage's asking agent, not the desk that talks to the person. `funnel` and `items` also carry `cost` (all-in USD) and `runs` — so the funnel says *which stage* the money goes to, not merely how much. An item's `runs` spans every stage it passed through and so is not `stageAttempts`, which resets per stage; a `Cost` of `—` means nothing there has ever been claimed, as against `$0.0000`, which means it ran and was free. Cost is not sortable: the endpoint's `--order-by` allow-list does not carry it. |
 | `fruxon triggers ledger passes` | Every time the automation fired, newest first — `admitted` (what the door took), `dispatched` (what the pass claimed and sent to work, questions parked on a human included), `completed` (how many of *this pass's* dispatches reached the terminal stage), `runs`, and the pass's all-in USD. `runs` sits **below** `dispatched` while runs are in flight or when a dispatch went to a person rather than a model — that gap is normal, not a lost item. And a pass's `cost` **rises after** it fired, as those runs finish, so a pass read seconds later reports a floor rather than its bill. An `outcome` other than `FIRED` means no sweep happened: `FILTERED` / `COALESCED` are healthy (nothing to do, or folded into a pass already running), `FAILED` / `FILTER_ERROR` are not. `-n/--limit` bounds the walk. |
 | `fruxon triggers ledger spend/spend-series/item-series` | What the automation spent and what happened to its items, over time. `spend` is the **current UTC calendar** day, week (from Monday) or month (`--period`), so a weekly read on a Monday is hours of spend, not seven days — the figure the automation's spend chip shows: item runs, the conversations its questions are held in, and its report, one row per agent and part (`ITEM_RUNS` / `CONVERSATIONS` / `REPORTS` / `OTHER`). It is **not** the funnel's `cost`, which files item runs under the cell each item sits in *now*; the two overlap, so never add them. `spend-series` is the same figure per `day` or `week` over `--since`/`--until` (default the last 30 days), `--by-stage` adding a column per agent and part; it reads live run records, so a window older than the workspace's run history is counted from `countedFromMs` and the CLI says so. `--interval hour` is refused (tokens are priced per day), and a `week` bucket starts on a Thursday, so it does not line up with `spend --period weekly`. `item-series` counts admitted, finished, set aside and dead per `hour`, `day` or `week` — **events, not items**: a re-driven item that finishes again counts twice and an operator's ignore counts as set aside. Both series omit empty buckets; the footer says how many had anything. A server that predates the series reads 404s (exit 11). |
+| `fruxon triggers check <trigger>` | Audit whether a work-shape automation can move its items, part by part in the order an item meets them: on and taking items in, the last pass read its source, each PROCESS stage's agent exists with a deployed revision and working credentials and models (a rejected credential's row says how many items failed there since), each ASK stage's contact is declared and bound on the asking agent and its oldest question has not waited past a fifth of its answer window, the outcome note's contact reaches a person, this week's spend against the weekly limit, and how many items died in the last 7 days. `{trigger, overall, checks[]}` like `agents check`; exits 12 only on a hard fail, warnings stay 0. Read-only. |
 | `fruxon triggers budget list/get/set/delete` | Spend limits on an automation **as a whole** (`--period DAILY/WEEKLY/MONTHLY`, UTC calendar windows), counting every production run it caused whichever agent made it. Once one is enforced they govern its runs, which then meet only these limits and not the agents' own; with none enforced, each stage stops at its agent's own limit. None by default and every one removable. An enforced limit refuses new work at the limit (stage runs, passes, a question's opening, the report) and holds the stages until the window resets, while turns of conversations it already opened still run (up to 110%); `--no-enforce` only alerts the Application's admins. Needs Editor. |
 | `fruxon triggers ledger redrive/ignore/settle/cancel-batch` | The operator verbs; all confirm and refuse without `--yes` in agent mode. `redrive` returns a DEAD or FAILED item to the queue with its attempts reset — settle any `UNKNOWN` effect first or the next attempt hits the same refusal. `ignore` excludes an item for a **required** reason, which is the only thing separating IGNORED from DEAD later. `settle` answers an effect the platform could not confirm (`--landed` / `--did-not-land` + `--reason`); wrong in the second direction duplicates the write. `cancel-batch` calls off a question — the items go back to READY and a later pass re-batches them. |
 | `fruxon triggers ledger set-data` | Correct a parked (DEAD / FAILED / IGNORED) item's `data` before re-driving it — the value a stage recorded wrong, such as an ASK answer written as `SKIP`, which a plain re-drive would route on again. `--set path=value` (or `path:=<json>`, repeatable) on a top-level key the item carries or a path the shape declares (`produces`, `answeredWhenPath`); a misspelled key is refused with the settable list rather than added. `--reason` is required and lands on the item's history beside every old → new value. `--redrive` re-drives in the same transaction; `redrive` and `redrive-many` take `--set` too. |
@@ -190,6 +158,30 @@ Integrations + tools:
 | `fruxon agents channels list` / `fruxon agents endpoints` | Inspect a networked agent's channel bindings and resolved provider endpoints (with bot identity). Superseded by `applications entry-points list`, which names the Application answering on each address; these read endpoints outside the published API. |
 | `fruxon skills list/show/create/update/delete` | Browse the tenant's product-skill catalog and author its own skills (resources that attach to agents at runtime). |
 
+### `fruxon dash` — the console
+
+![fruxon dash --demo](https://raw.githubusercontent.com/fruxon-ai/fruxon-sdk/develop/docs/tui/demo.gif)
+
+A read-only, full-screen console for one Application. Home has the week's runs,
+spend and finished items, every agent with its share of the spend, every
+automation with what it holds, and what needs a person; Enter opens an agent
+(overview, the `agents check` rows plus credential, model and budget health,
+runs and their traces) or an automation (its stages, items per day, what
+failed, the `triggers check` rows, a source test and a stage preview). Live
+parts refresh every 5 seconds, totals every minute. It changes nothing.
+
+```bash
+pip install "fruxon[tui]"     # the console runs on Textual, an optional extra
+fruxon dash                   # the Application with the most agents
+fruxon dash --app "Support & Ops"
+fruxon dash --demo            # a made-up workspace, for a first look or a recording
+```
+
+Keys: `↑↓` move, `enter` open, `tab` next panel, `esc` back, `1 2 3` tabs,
+`7 3 1` (or `w` on a tabbed screen) the time window, `a` another Application,
+`r` refresh, `?` every key, `q` quit. It needs a terminal, so agent mode and
+piped output are refused (exit 16).
+
 ### `fruxon agents draft run` — examples
 
 ```bash

{fruxon-0.21.2 → fruxon-2.0.0}/pyproject.toml

@@ -92,6 +92,12 @@ dependencies = [
 requires-python = ">= 3.10"
 
 [project.optional-dependencies]
+# ``fruxon dash`` — the read-only, full-screen console. Kept out of the base
+# install so ``pip install fruxon`` stays as small as it was and the CLI's
+# start-up never pays for it: the console imports Textual only when it runs.
+tui = [
+    "textual>=8.2",
+]
 test = [
     "coverage",  # testing
     "pytest",  # testing
@@ -117,6 +123,13 @@ fruxon = "fruxon.cli:app"
 [tool.ruff]
 line-length = 120
 
+[tool.ruff.format]
+# Ruff 0.17 formats the Python code blocks inside Markdown too. Ours are
+# illustrations, not code: hand-aligned comments, one-line calls and
+# pseudo-signatures (``def f(...): ...  # POST /route``) that the formatter
+# would explode. Leave the docs as written.
+exclude = ["*.md"]
+
 [tool.ruff.lint]
 select = [
     "E",   # pycodestyle errors

{fruxon-0.21.2 → fruxon-2.0.0}/src/fruxon/_ssl.py

@@ -52,6 +52,7 @@ def context_for(base_url: str) -> ssl.SSLContext | None:
     """
     host = urllib.parse.urlparse(base_url).hostname or ""
     if host in _LOOPBACK_HOSTS:
+        # nosemgrep: unverified-ssl-context — loopback hosts only; the request never leaves this machine
         return ssl._create_unverified_context()  # noqa: S323 — loopback only
 
     bundle = os.environ.get("FRUXON_CA_BUNDLE", "").strip()
@@ -62,6 +63,7 @@ def context_for(base_url: str) -> ssl.SSLContext | None:
 
     if _insecure_enabled():
         _warn_insecure_once(host)
+        # nosemgrep: unverified-ssl-context — explicit FRUXON_INSECURE=1 opt-in, warned about on stderr
         return ssl._create_unverified_context()  # noqa: S323 — opt-in
 
     return _default_or_certifi_context()

{fruxon-0.21.2 → fruxon-2.0.0}/src/fruxon/_version.py

@@ -18,7 +18,7 @@ version_tuple: tuple[int | str, ...]
 commit_id: str | None
 __commit_id__: str | None
 
-__version__ = version = '0.21.2'
-__version_tuple__ = version_tuple = (0, 21, 2)
+__version__ = version = '2.0.0'
+__version_tuple__ = version_tuple = (2, 0, 0)
 
 __commit_id__ = commit_id = None

fruxon-2.0.0/src/fruxon/checks/__init__.py

@@ -0,0 +1,94 @@
+"""Read-only audits shared by the CLI and the ``fruxon dash`` console.
+
+A check reads a resource and the surfaces around it and says, row by row,
+whether it is wired to run. The rows are plain data: :class:`CheckResult`
+carries no markup and decides nothing about how it is shown, so
+``fruxon agents check`` prints them as text or JSON and the console lays
+them out in a panel, and both say the same thing because they ran the same
+code.
+
+Nothing here writes. Nothing here imports :mod:`fruxon.cli`, either — the
+console is built without the CLI, and a check that reached into it would
+drag the whole command tree in with it.
+"""
+
+from __future__ import annotations
+
+from dataclasses import dataclass, field
+
+# The four outcomes a row can have. ``skip`` is "nothing to check here" (no
+# consult step, so no roster to audit), which is a pass, not a warning.
+STATUSES = ("ok", "warn", "fail", "skip")
+
+
+@dataclass(frozen=True)
+class CheckResult:
+    """One audited surface: what was checked, how it came out, and what to do.
+
+    ``detail`` is what was found, in a sentence. ``hint`` is the next step —
+    usually a CLI command — or ``None`` when there is nothing to do.
+    ``explain`` says what the row checks and why it matters, for a reader who
+    has never seen it before; the CLI does not print it, the console shows it
+    beside the selected row.
+    """
+
+    title: str
+    status: str
+    detail: str
+    hint: str | None = None
+    explain: str = ""
+
+    def to_dict(self) -> dict:
+        """The row as ``agents check -o json`` has always printed it."""
+        return {"title": self.title, "status": self.status, "detail": self.detail, "hint": self.hint}
+
+
+@dataclass(frozen=True)
+class CheckReport:
+    """Every row of one audit, plus what the console needs to draw around it.
+
+    ``revision`` is the revision the audit read (``None`` when there is
+    none). ``revision_body`` is that revision as fetched, kept so a caller
+    that wants to draw the agent's flow does not have to fetch it again.
+    """
+
+    subject: str
+    checks: tuple[CheckResult, ...] = ()
+    revision: int | None = None
+    revision_body: dict | None = field(default=None, compare=False)
+
+    @property
+    def overall(self) -> str:
+        """``fail`` if any row failed, else ``warn`` if any warned, else ``ok``."""
+        return overall_status(self.checks)
+
+    def counts(self) -> dict[str, int]:
+        """How many rows passed (``ok`` and ``skip``), warned and failed."""
+        return {
+            "passed": sum(1 for c in self.checks if c.status in ("ok", "skip")),
+            "warnings": sum(1 for c in self.checks if c.status == "warn"),
+            "failing": sum(1 for c in self.checks if c.status == "fail"),
+        }
+
+
+def overall_status(checks) -> str:
+    """The worst status among ``checks``: ``fail`` › ``warn`` › ``ok``."""
+    statuses = {c.status for c in checks}
+    if "fail" in statuses:
+        return "fail"
+    if "warn" in statuses:
+        return "warn"
+    return "ok"
+
+
+def shape_get(node: dict, name: str) -> object:
+    """Read a work-shape key by camelCase name, tolerating PascalCase.
+
+    The API speaks camelCase, but the stored JSONB is PascalCase — so a
+    shape pasted out of the database (or a stage file hand-written against
+    it) reads the other way. Only the display path is tolerant; what gets
+    posted back is whatever the caller supplied, untouched.
+    """
+    if name in node:
+        return node[name]
+    return node.get(name[:1].upper() + name[1:])