@odla-ai/cli 0.45.0 → 0.46.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@odla-ai/cli",
-  "version": "0.45.0",
+  "version": "0.46.0",
   "description": "Agent-operable CLI for odla provisioning, calendar consent and connection lifecycle, System AI administration, Worker secrets, security jobs, and smoke checks.",
   "license": "MIT",
   "homepage": "https://odla.ai/docs/packages/cli",

package/skills/odla/references/sdks.md

@@ -157,6 +157,67 @@ never asks for provider keys. The lower-level library flow remains available
 for custom orchestrators; active reproduction still requires an explicitly
 injected isolated executor and never falls back to the host shell.
 
+## @odla-ai/chat — discussions humans and agents share
+
+Messaging as a **schema + default-deny rules + injectable client** on odla-db —
+no server to run, and no separate identity system: the same rule-governed graph
+serves people and agents.
+
+```ts
+import { CHAT_RULES, createChatClient } from "@odla-ai/chat";
+const chat = createChatClient(db, { selfId: myAuthId, selfEmail, displayName });
+```
+
+`botTrigger()` wakes an agent on a message; `chatSkill()` ships the agent-side
+skill. `@odla-ai/pm` rides this for every comment and audit entry, which is why
+a PM item's discussion and a group topic behave identically.
+
+## @odla-ai/granola — meeting notes into odla-db and the CRM
+
+Two triggers, **one** ingest path: a mountable webhook receiver
+(`createGranolaRoutes`, Standard Webhooks verified) for live updates, and an
+incremental `updated_after` poll (`syncNotes`) for backfill and reconciliation.
+Both land in `ingestNoteById`.
+
+```bash
+odla-ai secrets set granola_api_key --env dev --stdin   # Granola: Settings -> Connectors -> API keys
+```
+
+```ts
+import { GRANOLA_RULES, GRANOLA_SCHEMA, initGranola, syncNotes } from "@odla-ai/granola";
+const client = initGranola({ apiKey: env.GRANOLA_API_KEY });
+await syncNotes({ db }, client);   // { ingested, failed, lastUpdatedAt, truncated }
+```
+
+Install `GRANOLA_SCHEMA` and `GRANOLA_RULES` like any other namespace set. The
+rules are **deny-all on purpose** — these rows hold meeting transcripts, the
+most sensitive thing most apps will store — so reads go through your worker,
+never an end-user credential.
+
+Wire `crmPort` from the separate `@odla-ai/granola/crm` entry and every attendee
+becomes a person record, every email domain a company, and the note lands once
+per person as a `kind: "meeting"` activity. Idempotency is a ledger
+(`granola_note_link`), not a hope: a redelivered webhook writes no second
+activity, and a re-run poll converges on identical rows.
+
+## @odla-ai/email — structured Cloudflare Email Service sending
+
+```ts
+import { sendMessage, renderInvite, buildReply, parseInbound } from "@odla-ai/email";
+await sendMessage(sender, { to, subject, html, attachments });  // fail-closed validation
+```
+
+The transport is injected, so tests never send. `parseInbound`/`verifyInbound`
+handle mail arriving, `buildReply` threads the response. Sending needs the
+sending domain onboarded first — ask `runbook ask "email sending domain"`.
+
+## @odla-ai/workflows — effect-safety for Cloudflare Workflows
+
+Replay-stable identities, canonical input fingerprints, an explicit idempotency
+boundary, checkpoint validation, and a transactional-outbox reconciler
+(`runIdempotentEffect`, `checkpoint`, `enqueueOutbox`, `reconcileOutbox`).
+Web-standard APIs only — no Node built-ins, no `cloudflare:workers`.
+
 ## Others
 
 - **@odla-ai/chapter** — membership sites from one `defineChapter()` config:
@@ -177,3 +238,27 @@ injected isolated executor and never falls back to the host shell.
 - **@odla-ai/blog** — static-first blogging; files in, site out.
 - **@odla-ai/apps** — control-plane SDK (create apps, toggle services); the CLI
   and registry usually handle this for you.
+- **@odla-ai/pm** — the project board this repository runs on: products ->
+  projects -> goals, kanban tasks, decisions, bugs, and versioned runbooks, on
+  odla-db and shared across co-owned projects. Usually driven through
+  `odla-ai pm ...` rather than the library.
+- **@odla-ai/brand** — conversational brand-book builder: doc/image uploads,
+  agent-driven colour exploration with human-gated palette proposals, and a
+  compiler from the approved book to `@odla-ai/ui` design tokens.
+- **@odla-ai/docs** — build-time docs engine: one Markdown source becomes both a
+  themed static site and a serializable in-app manifest, so an app renders docs
+  without shipping a Markdown parser.
+- **@odla-ai/camel** — prompt-injection boundary for authority-bearing agents:
+  Safe/Unsafe values, closed conversions, effect authorization, and the dual-LLM
+  runners in `@odla-ai/camel/runner`. "Safe" means safe to place in a privileged
+  model's context — never factual, authorized, or harmless to display.
+- **@odla-ai/graph** — dependency-free property graph with one traversal algebra
+  over any edge kind, plus extractors that build one from a codebase (imports,
+  exported symbols, the data surfaces a module reads and writes).
+- **@odla-ai/test** — strict deterministic Worker/fetch/KV/D1/Workflow/clock
+  doubles for fast agent feedback: an unexpected network or database call fails
+  immediately rather than silently passing.
+- **@odla-ai/harness** — the coding-task protocol and safe Mac/Linux runner
+  behind odla Code: disposable workspaces, container-isolated agents, and
+  Studio-controlled task leases. The agent gets no workspace mount, no
+  credentials, and no network — everything crosses a typed tool channel.