anbaric 1.68.3 → 1.70.0

package/docs/README.md

@@ -28,6 +28,7 @@ What the framework gives you, one capability at a time.
 - [File storage](features/file-storage.md) — bytes at a path, local or in your tenant's storage
 - [Auditing](features/auditing.md) — the record of who changed what
 - [Entitlements](features/entitlements.md) — what a user has been granted, checked per request
+- [Skills](features/skills.md) — guidance your builders write for the agents working on your tenant
 - [Prompts](features/prompts.md) — versioned model instructions and schemas, saved at startup
 - [Serving a web UI](features/serving-a-web-ui.md) — putting your data on a page
 - [The admin console and widgets](features/admin-console-and-widgets.md) — dashboards and plugins

package/docs/features/admin-console-and-widgets.md

@@ -64,6 +64,13 @@ hardcoding styles.
 > components in separate files, or import server modules only inside the data
 > function.
 
+## Skills
+
+One console page is for the agents rather than the people: **Skills**, where a
+builder writes guidance - when to use it and what to do - that the Anbaric MCP
+offers to every agent working on the tenant as a tool of its own. See
+[Skills](skills.md).
+
 ## Turning plugins on
 
 `ANBARIC_PLUGINS` is a comma-separated list of plugin modules. Setting it

package/docs/features/deploying.md

@@ -59,6 +59,19 @@ anbaric jobs watch <job-id>     # follow a job as it progresses
   more can be switched to a **large** instance (faster compute, 2× the memory,
   $50/£50 a month instead of $20/£20, and not covered by the free allowance)
   on the console's Manage apps page. Deploying never asks about size.
+- **A pause on redeploy, unless you pay not to have one.** A redeploy builds the
+  new version while the old one keeps running, drains the old one (it finishes
+  the steps it has in hand, up to five minutes), then swaps the two. In the
+  ordinary case the old version is retired as soon as the new container has
+  started, which is before the app inside it is listening, so there is a gap
+  of the app's boot time in which it does not answer. **Zero-downtime
+  deploys**, switched on per app on the Manage apps page for $10/£10 a month,
+  hold the old version until the new one is answering, so the app is served
+  throughout; the switch-over is a few seconds in which a request may reach
+  either version.
+  Jobs are unaffected either way: the old version stops taking steps when it
+  is drained and the new version takes them when it is up. The setting takes
+  effect from the next deploy and is off by default. Anbaric Cloud only.
 
 ## Updating and tearing down
 

package/docs/features/skills.md

@@ -0,0 +1,44 @@
+# Skills
+
+An agent building on your tenant learns the platform from these docs, which
+are the same for everyone. What they cannot tell it is what *your* tenant has:
+a service you run, a convention your team follows, an internal system an app
+should call a certain way. A **skill** is how you tell it. It is a short piece
+of guidance a builder writes once, in the console, and every agent working on
+the tenant through the Anbaric MCP sees from then on.
+
+## What a skill is
+
+A skill has four parts:
+
+| Field | What it is for |
+|---|---|
+| **id** | A short slug (lower-case letters, digits and hyphens, up to 50 characters). It becomes part of the tool's name. |
+| **title** | How the skill is named to people and to the agent. |
+| **usage hints** | *When* an agent should reach for it. This is what the agent reads before deciding, so say what task or situation the skill applies to. |
+| **body** | *What* to do: the instructions themselves. The agent reads this only once it has decided the skill applies. |
+
+Keep the hints short and specific - "Read before fetching an external web page
+or file from an app" - and put the detail in the body: endpoints, headers,
+examples, the mistakes to avoid.
+
+## Where skills live
+
+The **Skills** page in the console lists the tenant's skills and lets a builder
+(owner, admin or builder role) add, edit and remove them. Anyone in the tenant
+can read them. Skills belong to the tenant, not to an app, and deployed apps
+cannot see them: they are for the people and agents working on the tenant, not
+for its runtime.
+
+## How an agent sees them
+
+Each skill is offered to the agent as a tool named `anbaric_skill_<id>` (hyphens
+in the id become underscores), whose description is the skill's title and usage
+hints. That is all the agent sees up front, which is how it decides relevance
+without reading everything. Calling the tool returns the body. A skill added or
+changed in the console appears the next time the agent's tools are listed,
+and straight after `anbaric_login`.
+
+Skills are not a replacement for these docs; they are the layer on top that is
+yours. An agent is told to read the skills whose hints match its task before
+building, and to prefer what they say where the two differ.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "anbaric",
-  "version": "1.68.3",
+  "version": "1.70.0",
   "description": "Everything needed to write an Anbaric app: state machines, jobs, document and secret stores, local in-memory implementations and the Anbaric Cloud clients",
   "license": "MIT",
   "type": "module",
@@ -24,9 +24,9 @@
     "prepublishOnly": "npm run build"
   },
   "dependencies": {
-    "anbaric-impl-cloud": "^1.68.3",
-    "anbaric-data-store": "^1.68.3",
-    "anbaric-state-machine": "^1.68.3",
-    "anbaric-tsapi": "^1.68.3"
+    "anbaric-impl-cloud": "^1.70.0",
+    "anbaric-data-store": "^1.70.0",
+    "anbaric-state-machine": "^1.70.0",
+    "anbaric-tsapi": "^1.70.0"
   }
 }