@agent-native/core 0.7.52 → 0.7.53

package/docs/content/template-forms.md

@@ -1,28 +1,30 @@
 ---
 title: "Forms Template"
-description: "Agent-native form builder — create, edit, and analyze forms through natural language, with a live preview and click-to-edit GUI."
+description: "Agent-native form builder — create, edit, publish, and route form submissions through natural language plus a visual editor."
 ---
 
 # Forms
 
-A form builder where the form builder _is_ the agent. Drag fields around in the editor, or just say "add a 'how did you hear about us' dropdown with five options and make it required" — same result, same underlying data. Think Typeform, but you can build, edit, and analyze forms by talking to the agent.
+Forms is an agent-native form builder. Describe the form you want, refine it in the editor, and publish a public form that stores submissions in your own SQL database.
 
-When you open the app, you'll see a list of your forms on the left and the editor in the middle. Open a form and you can click any field to fine-tune it, or ask the agent to make changes for you.
+When you open the app, you see your forms, the current editor, and a live preview. The agent can create a form from a prompt, update field labels and options, change validation, and connect submission destinations using the same actions the UI uses.
 
 ## What you can do with it
 
-- **Build forms conversationally.** "Create a contact form," "add an NPS score question," "make the email field required." The agent updates the schema and the preview updates live.
-- **Click-to-edit fine-tuning.** Every field in the preview is editable in place — label, placeholder, validation, conditional logic — with the usual GUI controls.
-- **Field types out of the box:** short text, long text, email, phone, URL, number, date, single-select, multi-select, rating, file upload, section header, conditional branch.
-- **Responses dashboard.** Per-response view plus an aggregate dashboard the agent can pivot on request: "show me signups from the last 30 days grouped by source."
-- **Agent-driven analysis.** Ask the agent to cluster free-text responses, extract sentiments, or draft a reply to everyone who scored the NPS below 7.
-- **Publish anywhere.** Public share link, embed snippet, branded thank-you page, webhook on submit.
+- **Build forms conversationally.** "Create a contact form," "add an NPS score question," "make the email field required." The agent updates the form schema and the preview updates from SQL-backed state.
+- **Fine-tune visually.** Edit labels, placeholders, required state, options, and field order from the builder UI when you want direct control.
+- **Use the shipped field types.** Text, email, number, long text, select, multi-select, checkbox, radio, date, rating, and scale fields are supported out of the box.
+- **Collect responses.** Each submission is stored in SQL with a per-response detail view and a dashboard for reviewing entries.
+- **Route submissions.** Send submission payloads to webhooks, Slack, Discord, or Google Sheets using the built-in integrations.
+- **Publish public forms.** Share a public form URL and show a thank-you message after submission.
 
 ## Why it's interesting
 
-The hard part of a form builder isn't the editor UI — it's everything around it: changing the questions after responses are already in, analyzing what people said, adding conditional logic, publishing, notifications, hooking it into Slack or your CRM. Most of that is just asking the agent. See [What is agent-native?](/docs/what-is-agent-native) for the bigger picture.
+The useful part of an agent-native form builder is that setup and iteration happen in the same place. You can ask the agent to add fields, adjust copy, connect Slack notifications, or inspect the submission data, while the UI remains the direct editor for the same SQL records.
 
-## For developers
+See [What is agent-native?](/docs/what-is-agent-native) for the broader framework model.
+
+## For Developers
 
 ### Scaffolding
 
@@ -30,25 +32,28 @@ The hard part of a form builder isn't the editor UI — it's everything around i
 pnpm dlx @agent-native/core create my-forms --template forms --standalone
 ```
 
-For a workspace with forms alongside other apps:
+For a workspace with Forms alongside other apps:
 
 ```bash
-pnpm dlx @agent-native/core create my-platform  # pick Forms + other templates
+pnpm dlx @agent-native/core create my-platform
 ```
 
-### Customize it
+Pick Forms and any other templates you want during the workspace setup.
+
+### Customize It
 
-Ask the agent for the outcome you want:
+Ask the agent for shipped behavior first:
 
-- "Add a signature field where people can draw their name."
-- "When someone submits this form, post it in our #signups Slack channel." (Connect Slack first via [Messaging](/docs/messaging).)
+- "Add a required radio field for preferred contact method."
+- "Post every new submission to Slack." Connect Slack first via [Messaging](/docs/messaging).
+- "Add a webhook destination for our CRM."
+- "Create a customer feedback form with a 1-10 scale and a long-text follow-up."
 - "Make some forms public and others login-only."
-- "Send everyone who scored below 5 a follow-up email asking what we could do better."
 
-The agent figures out the schema changes, components, and storage on its own — you just describe the result you want. See [Cloneable SaaS](/docs/cloneable-saas) for the full clone, customize, deploy flow.
+If you need new capabilities such as file uploads, signatures, or custom field widgets, treat them as template extensions: add the SQL shape, actions, UI editor controls, public renderer support, and agent instructions together. See [Creating Templates](/docs/creating-templates) for the current build pattern.
 
-## What's next
+## What's Next
 
 - [**Cloneable SaaS**](/docs/cloneable-saas) — the clone-and-own model
 - [**Actions**](/docs/actions) — the action system powering the builder
-- [**Real-Time Sync**](/docs/real-time-collaboration) — how the preview stays in sync with agent edits
+- [**Messaging**](/docs/messaging) — Slack and other submission destinations

package/docs/content/template-mail.md

@@ -14,6 +14,7 @@ When you open the app, you'll see your inbox on the left, the open thread in the
 - **Read and triage email** with keyboard shortcuts (`J`/`K` to move, `E` to archive, `R` to reply, `C` to compose).
 - **Connect multiple Gmail accounts** — personal and work in one inbox.
 - **Ask the agent to do anything you can do.** "Summarize my unread emails." "Draft a reply that politely declines." "Archive all Netlify bot emails older than a week."
+- **Queue drafts for review.** Teammates and Slack users can ask the agent to prepare an email for an org member; the owner reviews, edits, and sends it from Mail.
 - **Auto-triage with rules.** Set up automation rules in plain English ("from a newsletter") with actions (label, archive, mark read, star, trash).
 - **Track opens and clicks** on the emails you send.
 - **Search across every connected inbox** with one query.
@@ -96,6 +97,8 @@ agent-native add-app
 
 **Multiple compose drafts.** The compose panel supports multiple draft tabs at once. Each draft is stored as an `application_state` entry at `compose-{id}` and syncs live between the agent and the UI. The agent can create a new draft with `manage-draft --action=create`, edit your in-progress draft with `--action=update`, or close tabs with `--action=delete`. Drafts use markdown in the body field; the TipTap editor renders it as rich text and converts to HTML on send.
 
+**Queued draft review.** Drafts requested by teammates or Slack are durable SQL rows in `queued_email_drafts`. The agent uses `queue-email-draft` to assign a draft to an org member, returns a review URL such as `/draft-queue/<id>`, and waits for the owner to review or explicitly send. The queue supports listing assigned drafts, editing them, opening one in the compose panel, dismissing it, and sending one or all reviewed drafts.
+
 **AI triage via automations.** Mail supports automation rules that run against new inbox email using AI. A rule has a natural-language condition (for example, `"from a newsletter"` or `"subject contains invoice"`) and a list of actions (`label`, `archive`, `mark_read`, `star`, `trash`). Manage them via `pnpm action manage-automations --action=create|list|update|delete|enable|disable`, or through the Settings page. Rules fire automatically and can be triggered manually with `pnpm action trigger-automations`.
 
 **Send tracking.** Sent messages get open-pixel and link-click tracking injected automatically. Settings live under `mail-settings.tracking` with `tracking.opens` and `tracking.clicks` (both default `true`). Only links in the new portion of a reply or forward are rewritten — quoted content is left alone. Pull stats for any sent message with `pnpm action get-tracking --id=<message-id>`, or from `GET /api/emails/:id/tracking`. Open and click events are stored in the `email_tracking` and `email_link_tracking` tables.
@@ -132,6 +135,7 @@ When a Google account is connected, email lives in Gmail — the app is a view o
 | `getSetting("labels")`        | System and user labels, with unread counts                     |
 | `getSetting("mail-settings")` | User profile, tracking preferences, signature, aliases         |
 | `getSetting("aliases")`       | Email aliases                                                  |
+| `queued_email_drafts` table   | Teammate-requested drafts awaiting owner review/send           |
 | `email_tracking` table        | Open-pixel events for sent messages                            |
 | `email_link_tracking` table   | Link-click events for sent messages                            |
 | `application_state` table     | `navigation`, `navigate`, `compose-{id}` entries (ephemeral)   |

package/docs/content/template-video.md

@@ -124,7 +124,7 @@ User edits (track values, parameter values, prop overrides, composition settings
 
 The agent always knows which composition you have open. Navigation state (`{ view, compositionId }`) is written to the framework's `application_state` table, and the `view-screen` action returns it plus a hint pointing at `app/remotion/registry.ts`. You don't have to tell the agent which composition you're on — ask it to act on "this one" and it will.
 
-Under the hood the agent calls actions like `navigate`, `create-composition`, `generate-animated-component`, and edits `app/remotion/registry.ts` and `app/remotion/compositions/*.tsx` directly. Every change shows up in the timeline.
+Under the hood the agent calls actions like `navigate`, `save-composition`, and `generate-animated-component`. SQL-backed composition records are created or updated through `save-composition`; code-backed Remotion components still live in `app/remotion/compositions/*.tsx` and are registered in `app/remotion/registry.ts`.
 
 ### Data model
 
@@ -151,10 +151,10 @@ The template folder is `templates/videos/` (the user-facing slug is `video`, but
 
 - `view-screen.ts` — returns current navigation state for the agent.
 - `navigate.ts` — navigate to a composition (`--compositionId <id>`) or the home view (`--view home`).
-- `create-composition.ts` — scaffold a new composition with the standard camera and cursor tracks.
-- `generate-animated-component.ts` — generate a new animated component file with boilerplate.
+- `save-composition.ts` — create or update a SQL-backed composition record.
+- `generate-animated-component.ts` — generate a new Remotion component file with boilerplate.
 - `validate-compositions.ts` — check all registered compositions for structural problems.
-- `list-compositions.ts`, `get-composition.ts`, `update-composition.ts`, `delete-composition.ts`, `save-composition.ts` — CRUD over the SQL table.
+- `list-compositions.ts`, `get-composition.ts`, `update-composition.ts`, `delete-composition.ts` — read, update, and delete SQL-backed composition records.
 
 **Routes** — `templates/videos/app/routes/`
 

package/docs/content/what-is-agent-native.md

@@ -120,7 +120,7 @@ The vision: fewer handoffs, one person doing the work of a small team.
 
 ## Fork and customize {#fork-and-customize}
 
-Agent-native apps follow a fork-and-customize model. You start from a **cloneable SaaS** template — Mail, Calendar, Analytics, Slides, Clips, Forms, Dispatch — and make it yours:
+Agent-native apps follow a fork-and-customize model. You start from a **cloneable SaaS** template — Mail, Calendar, Analytics, Slides, Clips, Design, Forms, Dispatch — and make it yours:
 
 1. Pick a template on [agent-native.com/templates](/templates)
 2. Use it immediately as a hosted app (e.g. mail.agent-native.com)

package/docs/content/workspace.md

@@ -7,7 +7,7 @@ description: "Claude-Code-level customization per user — skills, memory, instr
 
 > **See also:** Deploying multiple apps as one workspace? See [Multi-App Workspaces](/docs/multi-app-workspace). Governance, branching, and CODEOWNERS? See [Workspace Governance](/docs/workspace-management).
 
-Every agent-native app ships with a **workspace**: the customization layer that makes the agent yours. It contains team instructions (`AGENTS.md`), per-user memory (`learnings.md`), skills the agent pulls in on demand, custom sub-agents, scheduled jobs, and connected MCP servers — everything you'd expect from a Claude Code / Codex setup.
+Every agent-native app ships with a **workspace**: the customization layer that makes the agent yours. It contains team instructions (`AGENTS.md`), shared learnings (`LEARNINGS.md`), personal structured memory (`memory/MEMORY.md`), skills the agent pulls in on demand, custom sub-agents, scheduled jobs, and connected MCP servers — everything you'd expect from a Claude Code / Codex setup.
 
 The twist: **it's SQL rows, not filesystem files.** Each user gets their own workspace stored in the database. There's no dev-box to spin up, no container per user, no files to mount. A multi-tenant SaaS can give every user a fully-customizable agent for essentially free, because all of it is rows — personal memory, personal MCP servers, personal skills, personal sub-agents — and the shared codebase hosts all of them at once.
 
@@ -17,7 +17,7 @@ The twist: **it's SQL rows, not filesystem files.** Each user gets their own wor
 | One codebase per developer       | One codebase, many users                           |
 | Needs a dev-box or container     | Runs on any serverless/edge host                   |
 | Customization at `~/.claude/`    | Customization per-user, scoped `u:<email>:…`       |
-| Per-project `CLAUDE.md` / skills | Per-app `AGENTS.md` + per-user `learnings.md`      |
+| Per-project `CLAUDE.md` / skills | Per-app `AGENTS.md` + workspace memory resources   |
 | MCP config in a JSON file        | MCP config in JSON _or_ the settings UI, per scope |
 
 Same capabilities. Different economics. See [Cloneable SaaS](/docs/cloneable-saas) for why this matters for SaaS.
@@ -32,19 +32,20 @@ The **Workspace** tab in the agent sidebar is where you and the agent share pers
 - Create files with the `+` menu. Upload with the upload button. Edit inline (visual or code view).
 - **Personal** is just you. **Shared** is your team/org.
 - The agent can read, write, and rename any of these files as part of a conversation.
-- Special files the agent always reads: `AGENTS.md` (team rules) and `learnings.md` (per-user memory the agent auto-updates when you correct it).
+- Special files the agent preloads: shared `AGENTS.md`, shared `LEARNINGS.md`, and personal structured memory at `memory/MEMORY.md`.
 
 ## What goes in here? {#what-goes-in-here}
 
-| File / path                 | What it's for                                                                                                  |
-| --------------------------- | -------------------------------------------------------------------------------------------------------------- |
-| `AGENTS.md` (Shared)        | Team instructions the agent reads every turn — tone, rules, domain context, skill references.                  |
-| `learnings.md` (Personal)   | **Agent memory.** Per-user file the agent auto-writes to on corrections/preferences and auto-reads every turn. |
-| `skills/<name>.md`          | Focused domain guidance the agent pulls in on demand (invoked with `/` slash commands).                        |
-| `agents/<name>.md`          | **Custom agents** — reusable sub-agent profiles the agent can delegate to (invoked with `@` mentions).         |
-| `remote-agents/<name>.json` | A2A manifests for connected remote agents — edited via a form, not raw JSON.                                   |
-| `jobs/<name>.md`            | Scheduled tasks that run on a cron (see the recurring-jobs docs).                                              |
-| Anything else               | Notes, prompts, config, dataset snippets — any text file.                                                      |
+| File / path                 | What it's for                                                                                          |
+| --------------------------- | ------------------------------------------------------------------------------------------------------ |
+| `AGENTS.md` (Shared)        | Team instructions the agent reads every turn — tone, rules, domain context, skill references.          |
+| `LEARNINGS.md` (Shared)     | Shared corrections, conventions, and durable project memory the agent preloads.                        |
+| `memory/MEMORY.md`          | Personal structured memory the chat preloads for the current user.                                     |
+| `skills/<name>.md`          | Focused domain guidance the agent pulls in on demand (invoked with `/` slash commands).                |
+| `agents/<name>.md`          | **Custom agents** — reusable sub-agent profiles the agent can delegate to (invoked with `@` mentions). |
+| `remote-agents/<name>.json` | A2A manifests for connected remote agents — edited via a form, not raw JSON.                           |
+| `jobs/<name>.md`            | Scheduled tasks that run on a cron (see the recurring-jobs docs).                                      |
+| Anything else               | Notes, prompts, config, dataset snippets — any text file.                                              |
 
 ## Overview {#overview}
 
@@ -95,7 +96,7 @@ Change how the agent behaves, in 60 seconds.
 - **Skills** (`+` → **Skill**) — focused how-to files invoked in chat with `/skill-name`.
 - **Agents** (`+` → **Agent**) — reusable sub-agent personas invoked with `@agent-name`.
 - **Scheduled Tasks** (`+` → **Scheduled Task**) — prompts that run on a cron.
-- **learnings.md** — your Personal file the agent auto-updates whenever you correct it.
+- **Memory** — shared `LEARNINGS.md` and personal `memory/MEMORY.md` keep durable context available across conversations.
 
 ## How the Agent Uses Resources {#how-the-agent-uses-resources}
 
@@ -126,11 +127,16 @@ Be concise. Lead with the answer.
 | data-analysis | `skills/data-analysis.md` | BigQuery and data workflows |
 ```
 
-### learnings.md — agent memory {#learnings-md}
+### Memory {#memory}
 
-`learnings.md` is the agent's long-term memory about _you_. It's a **Personal-scope** resource (one per user) that the agent auto-reads at the start of every conversation and auto-writes to whenever it picks up something worth remembering.
+The workspace has two current memory surfaces:
 
-**What gets saved.** When you correct the agent ("no, always use X instead of Y"), share a preference ("I prefer concise answers"), or reveal context ("my team calls this 'the dispatch layer'"), the agent appends the learning to `learnings.md` so it doesn't repeat the mistake or have to re-ask next time. This behavior lives in the framework system prompt (the `capture-learnings` skill spells out the rules for when and how).
+- `LEARNINGS.md` in **Shared** scope for project-wide conventions, corrections, and durable team knowledge.
+- `memory/MEMORY.md` in **Personal** scope for structured memory about the current user.
+
+The resource system also seeds a personal `LEARNINGS.md` for compatibility with older workspaces, but the chat preload path is shared `LEARNINGS.md` plus personal `memory/MEMORY.md`.
+
+**What gets saved.** When you correct the agent ("no, always use X instead of Y"), share a preference ("I prefer concise answers"), or reveal context ("my team calls this 'the dispatch layer'"), the agent can capture that learning so it doesn't repeat the mistake or have to re-ask next time. Project-wide learnings belong in shared `LEARNINGS.md`; user-specific memory belongs under `memory/`. This behavior lives in the framework system prompt and the `capture-learnings` skill spells out the rules for when and how.
 
 **What it looks like.**
 
@@ -152,13 +158,14 @@ Be concise. Lead with the answer.
 
 **Where it fits.**
 
-| Surface        | Scope    | Written by                | Read when                    |
-| -------------- | -------- | ------------------------- | ---------------------------- |
-| `AGENTS.md`    | Shared   | Humans / agent on request | Every turn                   |
-| `learnings.md` | Personal | Agent, automatically      | Every turn                   |
-| `skills/…`     | Shared   | Humans / agent on request | On demand (`/slash` command) |
+| Surface            | Scope    | Written by                | Read when                    |
+| ------------------ | -------- | ------------------------- | ---------------------------- |
+| `AGENTS.md`        | Shared   | Humans / agent on request | Every turn                   |
+| `LEARNINGS.md`     | Shared   | Humans / agent on request | Every turn                   |
+| `memory/MEMORY.md` | Personal | Agent / humans            | Every turn                   |
+| `skills/…`         | Shared   | Humans / agent on request | On demand (`/slash` command) |
 
-Users can edit `learnings.md` directly in the Workspace tab — it's a regular resource. Delete lines the agent got wrong or promote them into `AGENTS.md` if they apply to the whole team.
+Users can edit these memory files directly in the Workspace tab — they're regular resources. Delete lines the agent got wrong, keep personal preferences in `memory/MEMORY.md`, or promote team-wide rules into `AGENTS.md`.
 
 ## Skills {#skills}
 
@@ -222,7 +229,7 @@ Recommended conventions:
 There are two agent types in Workspace:
 
 - **Custom agents** — local profiles in `agents/*.md`, executed inside the current app/runtime
-- **Connected agents** — remote A2A peers described by manifests in `agents/*.json`
+- **Connected agents** — remote A2A peers described by manifests in `remote-agents/*.json` (legacy `agents/*.json` manifests are still recognized)
 
 Use custom agents for delegation within one app. Use connected agents when you need to call another app over A2A.
 
@@ -286,13 +293,13 @@ If no skills are configured, the dropdown shows a hint with a link to these docs
 
 The resource system works identically in both modes. The difference is what additional sources are available for `@` tagging and `/` commands:
 
-| Feature                  | Dev Mode                                                                | Production                                             |
-| ------------------------ | ----------------------------------------------------------------------- | ------------------------------------------------------ |
-| @ tagging                | Codebase files + workspace resources + custom agents + connected agents | Workspace resources + custom agents + connected agents |
-| / slash commands         | .agents/skills/ + resource skills                                       | Resource skills only                                   |
-| Agent file access        | Filesystem + resources                                                  | Resources only                                         |
-| Workspace panel          | Full access                                                             | Full access                                            |
-| AGENTS.md / learnings.md | Available                                                               | Available                                              |
+| Feature            | Dev Mode                                                                | Production                                             |
+| ------------------ | ----------------------------------------------------------------------- | ------------------------------------------------------ |
+| @ tagging          | Codebase files + workspace resources + custom agents + connected agents | Workspace resources + custom agents + connected agents |
+| / slash commands   | .agents/skills/ + resource skills                                       | Resource skills only                                   |
+| Agent file access  | Filesystem + resources                                                  | Resources only                                         |
+| Workspace panel    | Full access                                                             | Full access                                            |
+| AGENTS.md / memory | Available                                                               | Available                                              |
 
 ## Resource API {#resource-api}
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@agent-native/core",
-  "version": "0.7.52",
+  "version": "0.7.53",
   "type": "module",
   "description": "Framework for agent-native application development — where AI agents and UI share state via files",
   "license": "MIT",