cinna-cli 0.5.3__tar.gz → 0.6.0__tar.gz

{cinna_cli-0.5.3 → cinna_cli-0.6.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: cinna-cli
-Version: 0.5.3
+Version: 0.6.0
 Summary: Local development CLI for Cinna Core agents
 Project-URL: Homepage, https://github.com/opencinna/cinna-cli
 Project-URL: Repository, https://github.com/opencinna/cinna-cli
@@ -405,6 +405,8 @@ At a terminal that preview is shown and confirmed before the press; `--yes`, `--
 
 A re-publish appends a revision to the same package, so `--package-id` (the reverse-DNS id, e.g. `com.acme.report`) is only for a first publish — a mismatch on a later one is refused rather than silently ignored. `--visibility` is likewise honoured on a first publish and on an explicit change; omitting it leaves the package as it is. `--grant` requires `--visibility users` and the CLI refuses the combination otherwise, before anything is written. The server would accept it — it stores the grant either way — but a package that is private or public never consults its grant list, so the publish would report success and share nothing, and a revision cannot be taken back. Within a `users` package `--grant` is strictly **additive**: it adds the addresses it names and never revokes the ones it omits (revoking is `cinna skills revoke`, so a stale publish cannot silently remove access), and an unknown address fails the whole publish rather than half-sharing it. On success the package id, revision and its version, visibility and catalog URL are printed, plus a line saying the version landed in `skills/<name>/SKILL.md` — and a warning instead when it could not be written there, because the header and the catalog have then diverged and the next publish continues from the catalog. A refusal is printed as the platform's own sentence with its code (`not_developer`, `foreign_install`, `no_environment`, `workspace_unavailable`, `package_id_immutable`, `skill_contains_secrets` — which also lists the offending files), and `--json` prints `{revision, package, catalog_url, skill_md_updated}` instead of the human block (`--dry-run --json` prints the preview payload).
 
+**A publish from the CLI is never refused as stale.** It goes through the agent path, which records the package's latest revision as the new one's base (`cinna skills revisions` shows it under **Based on**), so another maintainer's newer version is built on, not checked against. Cinna Desktop's Share instead sends the base its folder holds, and core refuses that share (`stale_base`) when a co-maintainer has shared a newer version since; the CLI never makes that call.
+
 ### `cinna skills catalog [--search Q] [--mine] [--json]`
 
 Browse the instance skills catalog: one row per package this account may see, with its reverse-DNS **package id**, display name, visibility and newest version. The package id — `com.acme.pdf-report`, not a UUID — is the reference every other package verb takes. A delisted package is marked as such beside its visibility.
@@ -417,7 +419,7 @@ One package in full: its display name, visibility, newest version and package UU
 
 ### `cinna skills revisions <package> [--json]`
 
-A package's revisions, **newest first**: number, version, release date, size and the release notes given at publish time. A revision is immutable, so this is the question a publisher has before every publish — what is already out there — and the answer to it no longer requires `cinna api` and a UUID. Pair it with `cinna skills publish <agent> <name> --dry-run`, which says what the *next* one would be.
+A package's revisions, **newest first**: number, version, release date, size, **Shared by** (who published it, `—` once that account is deleted), **Based on** (`Version N`, the revision the sharer's copy held; `—` for a first revision, a share from an older Cinna Desktop, and any revision published before core recorded it) and the release notes given at publish time. A server older than skill co-maintainers sends neither field and both columns read `—`. `--json` passes the server's `published_by` and `base_revision_number` through untouched. A revision is immutable, so this is the question a publisher has before every publish — what is already out there — and the answer to it no longer requires `cinna api` and a UUID. Pair it with `cinna skills publish <agent> <name> --dry-run`, which says what the *next* one would be.
 
 ### `cinna skills files <package> [--revision N] [--json]`
 
@@ -609,6 +611,26 @@ cinna artifacts link create 3fa85f64 --expires 7d --code
 
 The printed page link is a valid `link` artifact for `cinna delegation report --artifact`.
 
+### `cinna dashboards list | show | check | run | ref | boards | board create | add | tiles | tile …`
+
+Build, check, run and place an agent's **dashboard components**: folders in the agent's `dashboards/<name>/` (`component.json` plus endpoint scripts or a page) that the owner keeps as live tiles on a dashboard. Run from the account workspace. `AGENT` is a name, slug, id, or `.` for the agent workspace you are in. Every verb first checks the server's dashboards capability. While an environment wakes, verbs retry for `--timeout` seconds (default 120). Verbs that read the agent's cloud copy push your pending local edits first (`--no-flush` skips that).
+
+- `list AGENT` · `show AGENT NAME [--skill S]` (`--skill` names a component a skill ships, on every verb that takes `NAME`): the components as the environment sees them (checker findings, where each is placed, including "Cinna Desktop") and the **reference** line `cinna://component/bundle:<bundle_id>/<name>` that offers one.
+- `check AGENT [NAME] [--run]`: the owner's card checks; `--run` also runs each source in the environment through `cinna exec` (never locally). Exits 1 on any error.
+- `run AGENT NAME [--endpoint E] [--param k=v]… [--params @file.json]`: run it exactly as a tile would. `--json` prints `{result, value, params_resolved, notice, fetched_at}`, where `value` is exactly what a tile receives.
+- `ref AGENT NAME [--check]`: print only the reference line; `--check` asks core whether it resolves.
+- `boards` · `board create NAME` · `add AGENT NAME --board B [--new-board] [--size s|m|l|wide|tall] [--param k=v] [--title T] [--max-age 15m] [--every 5m|manual] [--after-turn]`: the owner's web dashboards; place a tile (refused for a component with errors or a full dashboard).
+- `tiles BOARD` · `tile data|refresh|params|call|edit|remove BOARD TILE …`: read and drive tiles. `tile params --set/--clear/--reset` sends the whole set; `tile edit` changes title (`''` resets it), size and refresh overrides. Tiles on Cinna Desktop's dashboards are read-only here.
+- `cinna chat --agent AGENT --board B [--focus TILE] [--context @file.json] [--new-chat] "…"`: talk in the agent's dashboard chat, where it has its tile tools.
+
+```bash
+cinna dashboards check crm-agent deals --run
+cinna dashboards run crm-agent deals --param stage=won
+cinna dashboards ref crm-agent deals --check
+cinna dashboards add crm-agent deals --board Sales --size l
+cinna chat --agent crm-agent --board Sales --focus deals "Show only won deals"
+```
+
 ### `cinna dev`
 
 Start a foreground dev session — creates / resumes the Mutagen sync session for this workspace and attaches the terminal to a two-tab TUI (status + raw Mutagen details). Ctrl-C terminates the session; sync does not outlive the TUI. To observe sync from another terminal without affecting it, use `cinna sync status`.

{cinna_cli-0.5.3 → cinna_cli-0.6.0}/README.md

@@ -368,6 +368,8 @@ At a terminal that preview is shown and confirmed before the press; `--yes`, `--
 
 A re-publish appends a revision to the same package, so `--package-id` (the reverse-DNS id, e.g. `com.acme.report`) is only for a first publish — a mismatch on a later one is refused rather than silently ignored. `--visibility` is likewise honoured on a first publish and on an explicit change; omitting it leaves the package as it is. `--grant` requires `--visibility users` and the CLI refuses the combination otherwise, before anything is written. The server would accept it — it stores the grant either way — but a package that is private or public never consults its grant list, so the publish would report success and share nothing, and a revision cannot be taken back. Within a `users` package `--grant` is strictly **additive**: it adds the addresses it names and never revokes the ones it omits (revoking is `cinna skills revoke`, so a stale publish cannot silently remove access), and an unknown address fails the whole publish rather than half-sharing it. On success the package id, revision and its version, visibility and catalog URL are printed, plus a line saying the version landed in `skills/<name>/SKILL.md` — and a warning instead when it could not be written there, because the header and the catalog have then diverged and the next publish continues from the catalog. A refusal is printed as the platform's own sentence with its code (`not_developer`, `foreign_install`, `no_environment`, `workspace_unavailable`, `package_id_immutable`, `skill_contains_secrets` — which also lists the offending files), and `--json` prints `{revision, package, catalog_url, skill_md_updated}` instead of the human block (`--dry-run --json` prints the preview payload).
 
+**A publish from the CLI is never refused as stale.** It goes through the agent path, which records the package's latest revision as the new one's base (`cinna skills revisions` shows it under **Based on**), so another maintainer's newer version is built on, not checked against. Cinna Desktop's Share instead sends the base its folder holds, and core refuses that share (`stale_base`) when a co-maintainer has shared a newer version since; the CLI never makes that call.
+
 ### `cinna skills catalog [--search Q] [--mine] [--json]`
 
 Browse the instance skills catalog: one row per package this account may see, with its reverse-DNS **package id**, display name, visibility and newest version. The package id — `com.acme.pdf-report`, not a UUID — is the reference every other package verb takes. A delisted package is marked as such beside its visibility.
@@ -380,7 +382,7 @@ One package in full: its display name, visibility, newest version and package UU
 
 ### `cinna skills revisions <package> [--json]`
 
-A package's revisions, **newest first**: number, version, release date, size and the release notes given at publish time. A revision is immutable, so this is the question a publisher has before every publish — what is already out there — and the answer to it no longer requires `cinna api` and a UUID. Pair it with `cinna skills publish <agent> <name> --dry-run`, which says what the *next* one would be.
+A package's revisions, **newest first**: number, version, release date, size, **Shared by** (who published it, `—` once that account is deleted), **Based on** (`Version N`, the revision the sharer's copy held; `—` for a first revision, a share from an older Cinna Desktop, and any revision published before core recorded it) and the release notes given at publish time. A server older than skill co-maintainers sends neither field and both columns read `—`. `--json` passes the server's `published_by` and `base_revision_number` through untouched. A revision is immutable, so this is the question a publisher has before every publish — what is already out there — and the answer to it no longer requires `cinna api` and a UUID. Pair it with `cinna skills publish <agent> <name> --dry-run`, which says what the *next* one would be.
 
 ### `cinna skills files <package> [--revision N] [--json]`
 
@@ -572,6 +574,26 @@ cinna artifacts link create 3fa85f64 --expires 7d --code
 
 The printed page link is a valid `link` artifact for `cinna delegation report --artifact`.
 
+### `cinna dashboards list | show | check | run | ref | boards | board create | add | tiles | tile …`
+
+Build, check, run and place an agent's **dashboard components**: folders in the agent's `dashboards/<name>/` (`component.json` plus endpoint scripts or a page) that the owner keeps as live tiles on a dashboard. Run from the account workspace. `AGENT` is a name, slug, id, or `.` for the agent workspace you are in. Every verb first checks the server's dashboards capability. While an environment wakes, verbs retry for `--timeout` seconds (default 120). Verbs that read the agent's cloud copy push your pending local edits first (`--no-flush` skips that).
+
+- `list AGENT` · `show AGENT NAME [--skill S]` (`--skill` names a component a skill ships, on every verb that takes `NAME`): the components as the environment sees them (checker findings, where each is placed, including "Cinna Desktop") and the **reference** line `cinna://component/bundle:<bundle_id>/<name>` that offers one.
+- `check AGENT [NAME] [--run]`: the owner's card checks; `--run` also runs each source in the environment through `cinna exec` (never locally). Exits 1 on any error.
+- `run AGENT NAME [--endpoint E] [--param k=v]… [--params @file.json]`: run it exactly as a tile would. `--json` prints `{result, value, params_resolved, notice, fetched_at}`, where `value` is exactly what a tile receives.
+- `ref AGENT NAME [--check]`: print only the reference line; `--check` asks core whether it resolves.
+- `boards` · `board create NAME` · `add AGENT NAME --board B [--new-board] [--size s|m|l|wide|tall] [--param k=v] [--title T] [--max-age 15m] [--every 5m|manual] [--after-turn]`: the owner's web dashboards; place a tile (refused for a component with errors or a full dashboard).
+- `tiles BOARD` · `tile data|refresh|params|call|edit|remove BOARD TILE …`: read and drive tiles. `tile params --set/--clear/--reset` sends the whole set; `tile edit` changes title (`''` resets it), size and refresh overrides. Tiles on Cinna Desktop's dashboards are read-only here.
+- `cinna chat --agent AGENT --board B [--focus TILE] [--context @file.json] [--new-chat] "…"`: talk in the agent's dashboard chat, where it has its tile tools.
+
+```bash
+cinna dashboards check crm-agent deals --run
+cinna dashboards run crm-agent deals --param stage=won
+cinna dashboards ref crm-agent deals --check
+cinna dashboards add crm-agent deals --board Sales --size l
+cinna chat --agent crm-agent --board Sales --focus deals "Show only won deals"
+```
+
 ### `cinna dev`
 
 Start a foreground dev session — creates / resumes the Mutagen sync session for this workspace and attaches the terminal to a two-tab TUI (status + raw Mutagen details). Ctrl-C terminates the session; sync does not outlive the TUI. To observe sync from another terminal without affecting it, use `cinna sync status`.

{cinna_cli-0.5.3 → cinna_cli-0.6.0}/docs/README.md

@@ -25,7 +25,8 @@ The platform also handles scheduling, triggers, email, A2A, MCP serving, and ses
 - Testing credential integrations (keys and tokens stay on the platform, exercised by the remote env)
 - Installing and validating Python / system packages
 - Writing and iterating on prompt files
-- Building webapp dashboards and data endpoints
+- Building the agent's webapp and data endpoints
+- Building dashboard components, checking and running them in the env, placing them as tiles
 - Preparing output files and reports
 
 ### What stays in the cloud
@@ -56,6 +57,10 @@ The live-sync rewrite removes the local container entirely. Mutagen keeps the wo
 
 A self-contained automation unit on the platform. Has a name, template, scripts, prompts, webapp, credentials, and a knowledge base. Identified by `agent_id`.
 
+### Dashboard component
+
+A live view an agent keeps in `dashboards/<name>/` (`component.json` plus endpoint scripts or a page). The owner places it as a **tile** on a dashboard (core's web dashboards, or Cinna Desktop); the agent offers it by printing its reference `cinna://component/bundle:<bundle_id>/<name>`. It runs only in the agent's environment. See [Dashboards](features/dashboards/dashboards.md).
+
 ### Environment
 
 The runtime container configuration for an agent on the platform. Each agent has exactly one environment. Environments may be suspended when idle; opening a sync WebSocket auto-activates them.
@@ -298,6 +303,7 @@ authoring convention.
 | **Git versioning** | `cinna git` (link, status, commit, push, pull, log, checkout, unlink) — external remotes with your own credentials, `cinna` remotes with the CLI token | [business](features/git_versioning/git_versioning.md) · [tech](features/git_versioning/git_versioning_tech.md) · [acceptance](features/git_versioning/git_versioning_acceptance.md) |
 | **Durable delegation** | `cinna delegation` (create — idempotent per target + `--id`, status, report — owner side with a task id or from inside a cloud task, reply), gated on the backend capability version | [business](features/delegation/delegation.md) · [tech](features/delegation/delegation_tech.md) · [acceptance](features/delegation/delegation_acceptance.md) |
 | **Artifacts** | `cinna artifacts` (publish — republishes a remembered path, `--new` / `--update`; list, show, open, download, share and link create — person-only, refused without a TTY; link revoke, delete), gated on the server's artifacts capability | [business](features/artifacts/artifacts.md) · [tech](features/artifacts/artifacts_tech.md) · [acceptance](features/artifacts/artifacts_acceptance.md) |
+| **Dashboards** | `cinna dashboards` (list, show, check `[--run]`, run, ref `[--check]` — an agent's components as its environment sees them; boards, board create, add, tiles, tile data / refresh / params / call / edit / remove — tiles on the owner's web dashboards, desktop dashboards read-only) · `cinna chat --board [--focus] [--context] [--new-chat]` (dashboard chat with the tile tools); gated on the server's dashboards capability | [business](features/dashboards/dashboards.md) · [tech](features/dashboards/dashboards_tech.md) · [acceptance](features/dashboards/dashboards_acceptance.md) |
 | **Improvement requests** | `cinna improve` (list, show, download, status) | [business](features/improvement_requests/improvement_requests.md) · [tech](features/improvement_requests/improvement_requests_tech.md) · [acceptance](features/improvement_requests/improvement_requests_acceptance.md) |
 | **Local agent import** | `cinna agent import` (Local Agent Kit → cloud agent), incl. the versioned folder contract (`.cinna-kit/layout.json`), `publications.json` and `content_hash` | [business](features/local_agent_import/local_agent_import.md) · [tech](features/local_agent_import/local_agent_import_tech.md) · [acceptance](features/local_agent_import/local_agent_import_acceptance.md) |
 | **Team library** | `cinna library` (list, get, share, update, status, grants, suggest) — kit folders in `Local/<slug>/` shared through cinna-core-hosted git with the account token; `cinna agent import --from-library` | [business](features/team_library/team_library.md) · [tech](features/team_library/team_library_tech.md) · [acceptance](features/team_library/team_library_acceptance.md) |
@@ -526,6 +532,8 @@ The platform's send-message route (`POST /sessions/{id}/messages/stream`) return
 3. Records the current message count as a cursor, then sends the message (`file_ids` carry the attachments).
 4. **Polls** `GET /sessions/{id}/messages?offset=<cursor>` (messages are ordered ascending by `sequence_number`, so `offset` is the cursor) and `GET …/messages/streaming-status` (`{is_streaming}`) until the turn settles — `is_streaming` false with no message flagged `streaming_in_progress`. A start-grace window covers env wake / queueing before the turn begins; an overall `--timeout` bounds the wait.
 
+With `--board`, the session is the agent's **dashboard chat** (`POST /dashboards/{id}/chat`), each message carries `dashboard_context`, and a `tiles` event before `done` reports tiles whose params the turn changed (see [Dashboards](features/dashboards/dashboards.md)).
+
 Each finalized message is emitted as one NDJSON line (`session` / `upload` / `message` / `status` / `done`); the in-progress assistant message is held back (its content is still growing) and emitted once final. Every `message` also carries the agent's reasoning/tool trace under **`events`** — the normalized `streaming_events` (thinking blocks, `tool` calls with their full `tool_input` payloads, tool results), with the bookkeeping/`attachment` entries stripped (attachments are surfaced separately). The final coalesced text stays in `content`; the trace shows *how* the agent got there. `--no-events` drops the trace; `--pretty` swaps NDJSON for a Rich transcript. Ctrl-C calls `POST …/messages/interrupt` and exits 130.
 
 ### Attachments
@@ -626,6 +634,7 @@ When a CLI token expires (or is revoked) the normal remedy is `cinna set-token <
 | POST | `/api/v1/cli/account/agents/{id}/mint` | Account token | Mint a per-agent CLI token (`cinna agent sync`, `cinna doctor` re-mint) |
 | POST | `/api/v1/cli/account/api-proxy` | Account token | Buffered JSON escape hatch — `cinna api`, and the transport for every `cinna chat` session/message call |
 | POST | `/api/v1/cli/account/files/upload` | Account token | Multipart upload for `cinna chat --file` (the proxy can't carry multipart) |
+| (proxy) | `dashboards/capabilities`, `agents/{id}/dashboards/…`, `dashboards/…`, `dashboards/{id}/blocks/{block}/component/…`, `dashboards/{id}/chat`, `dashboards/component-refs/resolve` | Account token | `cinna dashboards` and `cinna chat --board`, all through the api-proxy; never the `…/frame` routes (core's proxy refuses them) |
 | GET/PATCH | `/api/v1/cli/account/improvement-requests[/{id}[/archive]]` | Account token | Improvement requests received on the agents the account owns (`cinna improve`); the `/archive` route returns a binary ZIP the JSON-only proxy can't carry |
 
 `cinna chat` reaches the conversation API **through** the api-proxy (so these are inner routes, not CLI routes): `POST /sessions/`, `GET /sessions/{id}`, `GET /sessions/{id}/messages`, `POST /sessions/{id}/messages/stream`, `GET /sessions/{id}/messages/streaming-status`, `POST /sessions/{id}/messages/interrupt`, and `GET /files/{id}/download`.

{cinna_cli-0.5.3 → cinna_cli-0.6.0}/docs/features/account_workspace/account_workspace.md

@@ -178,7 +178,13 @@ each with its own token, registry entry, and Mutagen session.
 - `cinna account refresh-context` re-downloads `context/` and regenerates the
   orchestrator `CLAUDE.md`, the MCP wiring, and every synced child's per-agent
   `CLAUDE.md` from the bundled templates — so a CLI upgrade's new commands reach
-  existing workspaces without a re-setup.
+  existing workspaces without a re-setup. A child whose config predates the
+  `bundle_id` field gets it filled in first (best effort), so its guide's
+  Dashboard components section carries the agent's own reference prefix.
+- The orchestrator `CLAUDE.md` has a **Dashboards** command table and a
+  "Which one?" note (webapp / dashboard component / artifact). The Artifacts
+  heading says "a frozen copy", and its starter points at
+  `artifact-sqlite-report/`. See [Dashboards](../dashboards/dashboards.md).
 
 ## Business rules / guardrails
 

{cinna_cli-0.5.3 → cinna_cli-0.6.0}/docs/features/agent_addons/agent_addons.md

@@ -242,6 +242,20 @@ change without cutting a new one:
   it never revokes (revoking is its own verb in the web UI, so a stale
   invocation cannot silently remove access). An unknown address fails the whole
   publish rather than half-sharing it.
+- **A CLI publish is never refused as stale.** It goes through the agent path
+  (`POST /agents/{id}/skills/{name}/publish`), which records the package's
+  latest revision as the new revision's base, so a version a co-maintainer
+  shared in the meantime is built on rather than checked against. Cinna
+  Desktop's Share sends the base its folder holds instead, and core refuses
+  that share (`stale_base`) when a co-maintainer has shared a newer version
+  since. The CLI never calls the desktop upload, so it never sees
+  `stale_base` or `editable_package_exists`.
+- **Each revision names who shared it and what it was based on.**
+  `cinna skills revisions` and `cinna skills show` print **Shared by** (the
+  publisher's display name, `—` once the account is deleted) and **Based on**
+  (`Version N`, the revision the sharer's copy held; `—` for a first revision,
+  a share from an older Cinna Desktop, and any revision published before core
+  recorded it). An older server sends neither field and both read `—`.
 - **Publishing reads the cloud workspace.** The files come from the agent's
   remote workspace on disk — which is why a suspended environment publishes
   normally — so an unsynced local edit is simply not in the revision. Push

{cinna_cli-0.5.3 → cinna_cli-0.6.0}/docs/features/agent_addons/agent_addons_acceptance.md

@@ -516,11 +516,36 @@ cinna skills revisions <PACKAGE_ID>
 ```
 
 **Expected** — one row per revision, newest first, with number, version, release
-date, size and the `release_notes` given at publish time.
+date, size, **Shared by**, **Based on** and the `release_notes` given at publish
+time.
 
 **Watch for** — a permanently blank notes column (the field is `release_notes`,
 not `notes`); ascending order, which buries the answer at the bottom.
 
+### 20a. Each revision names who shared it and what it was based on
+
+**Goal** — the revision table shows the sharer and the base core recorded, and a
+CLI re-publish is recorded as built on the latest revision. Needs core
+d08c10d8 and 465c43c2 (revisions carrying `published_by` and
+`base_revision_number`).
+
+**Steps** — after scenarios 4 and 5 have published `acceptance-demo` twice:
+
+```bash
+cinna skills revisions <PACKAGE_ID>
+cinna skills revisions <PACKAGE_ID> --json
+```
+
+**Expected** — the table has **Shared by** and **Based on** columns. Revision 2
+reads **Based on** `Version 1`; revision 1 reads `—` there (a first revision has
+no base). Both rows name the publisher's display name under **Shared by**.
+`--json` carries the server's `published_by` (`{user_id, display_name}`) and
+`base_revision_number` (`1` on revision 2, `null` on revision 1) as sent.
+
+**Watch for** — revision 2 with no base (the agent publish path did not record
+one); a crash or a blank cell instead of `—` on a revision published before
+core recorded these fields.
+
 ### 21. Sharing changes after the publish
 
 **Steps**

{cinna_cli-0.5.3 → cinna_cli-0.6.0}/docs/features/agent_addons/agent_addons_tech.md

@@ -139,6 +139,10 @@
 - `src/cinna/account.py:_revision_rows()` — revisions sorted newest first. The
   question this list answers is "what is the newest"; a payload that happened to
   be ascending would put the answer at the bottom.
+- `src/cinna/account.py:_revision_shared_by()` / `_revision_based_on()` — the
+  revision table's **Shared by** (`published_by.display_name`) and **Based on**
+  (`Version <base_revision_number>`) cells, each `—` when the field is null or
+  absent.
 - `src/cinna/account.py:_addon_link()` — the row's `link` sub-object. Every
   fact about an *install* rather than a package lives there: `id` (the link id
   the plugin routes address), `installed_version`, `latest_version`,
@@ -242,11 +246,19 @@ hatch, `POST /api/v1/cli/account/api-proxy`:
   `grant_emails`, `package_id`). Returns the new revision; consumed fields are
   `package_id` (the package's UUID), `revision_number`, `version` and
   `frontmatter` (the last one only to tell whether the version reached the
-  workspace's `SKILL.md`).
+  workspace's `SKILL.md`). Core records the package's previous latest revision
+  as the new one's `base_revision_number`; this route never answers
+  `stale_base` or `editable_package_exists` — those come only from the desktop
+  upload (`POST /skills/packages/publish`), which the CLI does not call.
 - `GET /api/v1/skills/packages/{package_id}` — consumed fields are the
   reverse-DNS `package_id` string, `display_name`, `visibility`,
   `latest_version` and `revisions[]` (`revision_number`, `version`,
-  `created_at`, `release_notes` — **not** `notes` — and `size_bytes`).
+  `created_at`, `release_notes` — **not** `notes` — `size_bytes`,
+  `published_by` `{user_id, display_name}` (null once the account is deleted)
+  and `base_revision_number` (int or null)). The last two are absent on a
+  server older than skill co-maintainers; `_revision_shared_by()` and
+  `_revision_based_on()` render a missing or null value as `—`, and `--json`
+  passes both through untouched.
 - `POST /api/v1/agents/{agent_id}/skills/install` — `SkillInstallRequest`:
   `package_id` (the package **UUID**), optional `revision_number`,
   `conversation_mode`, `building_mode`. Answers `PluginSyncResponse`; 409

{cinna_cli-0.5.3 → cinna_cli-0.6.0}/docs/features/agent_management/agent_management.md

@@ -66,10 +66,14 @@ This doc covers the agent **lifecycle** verbs. The CRON automation subgroup
    conflicts against untouched remote originals. A session that cannot start is a
    warning naming `cinna sync push --agent <slug>` to run *before* editing — never
    a failed sync.
-3. Re-running sync for an agent **already synced** in that folder is refused
+3. Sync also records the agent's **bundle id** and the environment's **platform
+   skills** in the workspace config. The per-agent `CLAUDE.md` uses them for its
+   Dashboard components section: the agent's own `cinna://component/bundle:<id>/`
+   prefix, and the path to the account's kit copy of the `cinna-dashboards` skill.
+4. Re-running sync for an agent **already synced** in that folder is refused
    (with a `cinna agent unsync` / `cinna set-token` hint) — it never silently
    re-clones or duplicates.
-4. The workspace lands at `agents/<slug>/<subdir>/` (the Model-A nested layout;
+5. The workspace lands at `agents/<slug>/<subdir>/` (the Model-A nested layout;
    `<subdir>` is the slug unless the agent is git-versioned with another subdir) —
    the command prints the exact path. Afterward `cd` there and `cinna dev`, or stay
    at the account root and use `cinna sync push --agent <slug>` /
@@ -92,6 +96,12 @@ This doc covers the agent **lifecycle** verbs. The CRON automation subgroup
    re-materializes the backend scaffold and can clobber local changes, so the
    builder is told to `cinna sync push` first.
 3. It blocks until the container is back, then prints the post-restart status.
+4. If the agent is synced on this machine, it then **reconnects the sync
+   session** ("Sync session reconnected."). The old container took the remote
+   Mutagen agent with it, and without this the next `cinna sync push` failed
+   until Mutagen's own retry came round. A refused token is re-minted through
+   the account. A session that doesn't come back is a warning naming
+   `cinna sync push` / `cinna doctor`, never a failed restart.
 
 ### Rebuild an environment that predates a feature
 1. `cinna agent rebuild-env <agent_ref> [--yes]` is **not** a louder restart.
@@ -120,6 +130,8 @@ This doc covers the agent **lifecycle** verbs. The CRON automation subgroup
    row states; the server inside can still be starting, and a chat sent into that
    window sat streaming with no reply. It ends with "ready to chat", or a warning
    that the environment has not answered yet.
+7. Like `restart-env`, it then reconnects this machine's sync session for the
+   agent (see [Live Sync](../live_sync/live_sync.md)).
 
 ### Inspect what's live
 1. `cinna agent show <agent_ref>` prints the **effective prompts** (each under its
@@ -132,6 +144,11 @@ This doc covers the agent **lifecycle** verbs. The CRON automation subgroup
      `credentials:` block names. A credential shared by someone else whose slot
      this account cannot see reads `slot: unknown`, never `no slot`. When the
      agent's credential listing cannot be read, it falls back to name + type.
+   - A **Dashboard components** section (count, errors, tiles) when the server
+     has dashboards. It is read only while the environment is running, because
+     listing components would wake a suspended one; otherwise a dim note says the
+     environment's state. It never fails `show`. See
+     [Dashboards](../dashboards/dashboards.md).
 
 ### Choose the model per mode
 1. `cinna agent model show <agent_ref> [--json]` prints, for conversation and

{cinna_cli-0.5.3 → cinna_cli-0.6.0}/docs/features/agent_management/agent_management_tech.md

@@ -66,7 +66,13 @@ The group/subgroup objects are `src/cinna/main.py:agent()` and
 - `src/cinna/account.py:run_agent_restart_env()` — resolve the agent; if a local
   child workspace exists (`resolve_child_workspace()`), read `sync_session.status()`
   and warn+confirm when `pending_to_remote > 0` or `conflict_count > 0`; then
-  `AccountClient.restart_agent_env()` (blocking) and print status.
+  `AccountClient.restart_agent_env()` (blocking) and print status, then
+  `_reconnect_sync_session()`.
+- `src/cinna/account.py:_reconnect_sync_session()` — shared by restart and
+  rebuild: for the child workspace of this agent (`list_child_workspaces()`)
+  whose session exists, `sync_session.heal_session(child_cfg, child)` (a forced
+  reconnect, plus a token re-mint on a 401/403). It prints "Sync session
+  reconnected." or a warning, and never raises.
 - `src/cinna/account.py:run_agent_rebuild_env()` — the same shape as
   `run_agent_restart_env()` plus a second gate: the D2 unsynced-changes
   warn+confirm, then a `Rebuild …?` confirmation (default No) that `--yes`

cinna_cli-0.6.0/docs/features/dashboards/dashboards.md

@@ -0,0 +1,224 @@
+# Dashboards (`cinna dashboards`, `cinna chat --board`)
+
+## Purpose
+
+Let a developer and their local assistant build an agent's **dashboard
+components**, check and run them in the agent's real environment, print the
+reference that offers one to the owner, place them as tiles on the owner's web
+dashboards, and test the agent's behaviour in a dashboard chat, all from the
+terminal.
+
+## Mental model / core concepts
+
+A component lives **in the agent's workspace**. It's synced like any other file
+and runs **only in the agent's environment**. Tiles and dashboards live **in
+cinna-core**. The CLI is a remote control for both and runs nothing locally.
+
+- **Component**: a folder `dashboards/<name>/` in the agent's workspace (or
+  `skills/<skill>/dashboards/<name>/` inside a skill). It holds a
+  `component.json` (title, view, source, endpoints, params, refresh, size,
+  `requires_credentials`, `context`), small endpoint scripts and, for an `html`
+  view, a page. It's bundle-owned source: it ships with the agent, the team
+  library and published bundles.
+- **Component data**: what a schedule or the component's `refresh.command`
+  prepares under `app-data/dashboards/<name>/`. Per user, never shipped, never
+  carried by an import.
+- **Tile**: one placement of a component on a dashboard. It refers to the
+  component (agent + skill + name) and never copies it, so an edit to the
+  component changes every tile that shows it. A tile keeps only the owner's
+  choices: title, size, params and refresh overrides. Core keeps its cached
+  data and its run budget.
+- **Dashboard (board)**: the owner's page of tiles on the web, up to 20 blocks
+  each and 10 dashboards per user. Cinna Desktop also creates hidden **backing
+  dashboards** (`origin: desktop`) for its cloud tiles; those belong to the
+  desktop's layout.
+- **Reference**: the line an agent prints to offer a component,
+  `cinna://component/bundle:<bundle_id>/<name>` (with `<skill>/` before the
+  name for a skill's component). The owner's chat, on the web or in Cinna
+  Desktop, turns that line into a card with Preview and Add to dashboard. Every
+  cloud agent has a bundle id, so the CLI always prints the `bundle:` form.
+- **Dashboard chat**: one conversation per dashboard and agent. Each message
+  carries a `<dashboard_context>` (what the owner sees: the focused tile, its
+  params and data, the other tiles). In that chat, and only there, the agent has
+  the tile tools `dashboards_tiles` and `dashboards_update_tile`.
+- **Webapp vs component vs artifact**: the webapp is the agent's own app and
+  can be shared; a component is the owner's live tile; an artifact is a frozen
+  copy for people. "Make me a dashboard" almost always means a component.
+
+## User flows
+
+### Build and check a component (assistant in a synced agent workspace)
+1. The assistant reads the kit's dashboards guide and the `cinna-dashboards`
+   skill. The per-agent `CLAUDE.md` links the account's copy under
+   `context/local-kit/`.
+2. It writes `workspace/dashboards/deals/component.json`, then the endpoints.
+   Mutagen syncs them to the environment.
+3. `cinna dashboards check . deals --run` pushes pending edits, reads the
+   environment's own checker findings through core, runs the checker's run
+   checks in the environment, and exits 1 on any error.
+4. `cinna dashboards run . deals --param stage=won` prints the value exactly as
+   a tile would receive it.
+
+### Offer it to the owner
+5. `cinna dashboards ref . deals --check` prints the reference line and
+   confirms it resolves. The assistant prints that line, on its own and outside
+   backticks, in its reply to the user. The owner gets a card.
+
+### Place and drive tiles (when the user asks)
+6. `cinna dashboards boards` lists the owner's web dashboards;
+   `board create Sales` makes one.
+7. `cinna dashboards add crm-agent deals --board Sales [--size l] [--param k=v]`
+   adds the tile and prints its id and the dashboard link. `--new-board`
+   creates the dashboard if no dashboard has that name. `--title`, `--max-age`,
+   `--every` and `--after-turn/--no-after-turn` set the tile's title and
+   refresh overrides. A component a skill ships is named with `--skill <skill>`
+   on `show`, `check`, `run`, `ref` and `add`.
+8. `cinna dashboards tiles Sales` shows each tile's params, size and data age
+   without waking any environment. `tile data|refresh|params|call|edit|remove`
+   reads or changes one tile. `tile edit` takes `--title` (`''` goes back to
+   the component's title), `--size`, `--max-age`, `--every` and
+   `--after-turn/--no-after-turn`.
+
+### Test the agent in a dashboard chat
+9. `cinna chat --agent crm-agent --board Sales --focus deals "Which deal first?"`
+   opens (or continues) the agent's dashboard chat and sends the dashboard
+   context. The transcript shows the agent's tile-tool calls. A tile whose
+   stored params the turn changed is reported in a closing `tiles` event.
+   `--new-chat` starts a fresh chat; `--context @file.json` sends a
+   hand-written context instead.
+
+### Import a kit agent that ships components
+10. `cinna agent import <path>` lists the components that travel and warns
+    about what won't work in the cloud, then ends with their references and
+    the `add` hint.
+
+## Business rules
+
+- **The environment is the runtime.** Nothing runs an endpoint or the checker's
+  run checks locally. `check --run` goes through `cinna exec`, `run` through
+  core. The only local check is the kit's static checker during import.
+- **Flush before reading.** `list`, `show`, `check`, `run` and `add` first push
+  the agent's pending local edits when it's synced under this account
+  workspace and its sync session exists, and they say so. They never create a
+  session. `--no-flush` skips the push. A failed flush is a warning, and the
+  read goes ahead. Reads ask core for a fresh listing (`fresh=true`) so a check
+  right after a push isn't served from core's 10-second cache.
+- **Server support first.** Every verb asks `GET dashboards/capabilities`
+  before anything else. If the route is missing (the server predates
+  dashboard components), the answer is one message with code
+  `dashboards_unsupported`. Another version is refused up front too.
+  `cinna chat --board` asks the same route but also needs its `chat` flag, and
+  refuses with `dashboard_chat_unsupported` when the server has no dashboard
+  chat. The
+  limits it reports (runs a minute, blocks per dashboard, context size) are
+  the ones the CLI enforces and quotes. A refusal by the api-proxy itself
+  (its own per-token rate limit) is reported as exactly that, never as
+  "no dashboards".
+- **Waking environments.** `env_unavailable` is retried until `--timeout`
+  (default 120 s; on `check` the same flag also bounds each `--run` check, and
+  defaults to 300 s), waiting `retry_after_s` (default 5 s) between tries. Listing components or
+  running one wakes a suspended environment. Reading a tile's data never does.
+  `cinna agent show` lists components only when the server has dashboards
+  and the environment is already running. `cinna doctor` doesn't check
+  dashboards at all, because it would wake every environment.
+- **Refusals keep core's sentence** and add the CLI's next step:
+  - `adapter_unsupported` → `cinna agent rebuild-env <agent>`.
+  - `needs_credentials` → link them (`cinna agent show`). A name is the name of
+    a credential linked to the agent; for a bundle install it's the bundle's
+    credential spec name.
+  - `rate_limited` → try again in N s.
+  - `not_found` → `cinna dashboards list <agent>`.
+  - `invalid_input` → names the field.
+  - `call_failed` → core's sentence, which carries the script's stderr tail.
+  - Exit codes: `invalid_input` 2, `env_unavailable` 12, everything else 1.
+- **The CLI's own refusals** (exit 1, with the remedy in the message):
+  - `component_errors`: `check` found an error, or `add` was asked to place a
+    component with errors; the JSON lists the components.
+  - `dashboard_full`: `add` on a dashboard that already holds the block limit.
+  - `not_synced`: `check --run` for an agent with no synced workspace under
+    this account (the checker runs with that workspace's token).
+  - `ref_<status>` (e.g. `ref_gone`, `ref_invalid`): `ref --check` got a status
+    other than `ok`.
+  - `desktop_dashboard`: see Desktop dashboards below.
+- **Own run budget.** Core allows 30 runs a minute per target. CLI runs carry
+  `tile_key: "cli"`, so a developer looping `run` doesn't use up the budget of
+  core's Preview dialog. The CLI never auto-loops past a `rate_limited`.
+- **Agents offer, people place.** The assistant's default is to print the
+  reference. `add` and the tile verbs are for people and explicit requests, and
+  they aren't person-only: a tile is private to its owner.
+- **A component with errors can't be placed.** `add` refuses first and lists
+  the errors (core would refuse too). It also refuses a dashboard that already
+  holds the block limit.
+- **Desktop dashboards are read-only here.** Tiles on an `origin: desktop`
+  dashboard can be listed and read (`tiles`, `tile data`), but `tile refresh`,
+  `call`, `params`, `edit` and `remove`, and `add`, refuse with code
+  `desktop_dashboard`. `boards` and name lookup see web dashboards only; a
+  desktop dashboard is reachable by its full id. Placements on one show as
+  "Cinna Desktop".
+- **Placement matches core.** A new tile goes at the top-left (`0,0`) and the
+  grid shifts the others down, as core's own Add dialog does. The size grid is
+  core's: `s` 3×2, `m` 6×2, `l` 6×4, `wide` 12×2, `tall` 3×4. The default is
+  the component's `size`, else `s`.
+- **`add --new-board` creates only when nothing matches.** An ambiguous
+  name or a failed lookup stays an error; it never creates a duplicate.
+- **`chat --board --resume` must resume that dashboard's chat.** Core would
+  silently drop the context on any other session, and the tile tools would
+  answer `no_dashboard`, so the CLI refuses.
+- **The per-agent guide follows the environment.** `CLAUDE.md` §7b carries
+  the agent's own reference prefix and the path to the account's kit copy of
+  the `cinna-dashboards` skill, taken from the platform skills the building
+  context reports. If the environment doesn't list that skill, §7b says to
+  rebuild it.
+- **Tile params are a whole set.** `tile params --set/--clear/--reset` merges
+  locally and sends the complete set. Core replaces it, and omitted keys go
+  back to their defaults.
+- **No frame URLs.** The CLI never calls either `…/frame` route: a frame URL is
+  a 12-hour credential and a terminal has no use for one.
+- **Dashboard chat context** follows the web panel's shape. It's capped at
+  12,000 characters by dropping other agents' tiles first, then the agent's
+  other tiles, then cutting the summary. It's resent on every message (core
+  dedupes by hash). `--board` takes web dashboards only: a desktop dashboard's
+  chat runs in Cinna Desktop over A2A.
+- **Import warns, never refuses.** It warns when the kit's static checker
+  reports errors (the checker comes from the account workspace's own
+  `context/local-kit/`, the kit the user's server shipped; a kit copy
+  inside the imported folder is never run, because that folder may be a
+  download), when a source reads `app-data/` (that data doesn't travel),
+  when a folder holds `package.json`/`node_modules/`, when `refresh.on_app_start`
+  is set (the cloud ignores it), and when `requires_credentials` names a
+  credential the manifest doesn't declare.
+
+## Architecture overview
+
+```
+cinna dashboards <verb> → dashboards.py → AccountClient._dashboards_json → account api-proxy
+                                                         → core: agents/{id}/dashboards/* · dashboards/* · …/component/*
+                                                         → agent env (env-core /dashboards/*, the checker)
+cinna dashboards check --run → dashboards.run_env_checker → cinna exec (per-agent token) → env's check_component.py
+cinna chat --board → chat.run_chat → dashboards.prepare_dashboard_chat → POST dashboards/{id}/chat
+                                   → POST sessions/{id}/messages/stream {dashboard_context} → poll → "tiles" event
+cinna agent import → local_import._report_components → dashboards.survey_local_components → kit check_component.py (static)
+cinna agent sync / account refresh-context → GET agents/{id} → .cinna/config.json bundle_id → CLAUDE.md §7b
+cinna agent sync → building context (platform_skills) → .cinna/config.json platform_skills → CLAUDE.md §7b skill path
+```
+
+## Integration points
+
+- [Account workspace](../account_workspace/account_workspace.md): the
+  orchestrator `CLAUDE.md` has the Dashboards command table and the
+  webapp / component / artifact advice. `refresh-context` re-renders every
+  per-agent guide and backfills its bundle id.
+- [Agent management](../agent_management/agent_management.md): `cinna agent sync`
+  records the bundle id. `cinna agent show` has a Dashboard components section.
+  `cinna agent rebuild-env` is the remedy for an environment that predates
+  components.
+- [Live sync](../live_sync/live_sync.md): components sync like any workspace
+  file, and the dashboards verbs reuse its flush.
+- [Remote exec](../remote_exec/remote_exec.md): the channel `check --run` runs
+  the checker through.
+- [Remote chat](../remote_chat/remote_chat.md): `cinna chat --board` is a
+  dashboard chat on top of the same poll loop.
+- [Local agent import](../local_agent_import/local_agent_import.md): components
+  travel with an import, which reports them.
+- [Artifacts](../artifacts/artifacts.md): the frozen-copy alternative. Its
+  starter template is `artifact-sqlite-report/`.