@agent-native/core 0.80.8 → 0.80.9

package/corpus/templates/clips/server/plugins/onboarding.ts

@@ -53,6 +53,8 @@ export default async (nitroApp: any): Promise<void> => {
           "AWS S3, Cloudflare R2, DigitalOcean Spaces, MinIO, or any S3-compatible service.",
         payload: {
           writeScope: "workspace",
+          saveTo: "scoped-secrets",
+          secretDescription: "Clips S3-compatible storage",
           fields: [
             {
               key: "S3_ENDPOINT",

package/corpus/templates/content/app/components/editor/database/DatabaseView.tsx

@@ -7354,7 +7354,7 @@ function DatabaseGalleryView({
           {dbText("loadingGallery")}
         </div>
       ) : (
-        <div className="grid gap-3 px-1 py-3 sm:grid-cols-2 lg:grid-cols-3">
+        <div className="content-database-gallery-grid grid gap-3 px-1 py-3">
           {databaseViewHasNoMatchingPages(
             items.length,
             hasSearch,
@@ -7455,7 +7455,7 @@ function DatabaseGroupedGallerySection({
         onCollapsedChange={onCollapsedChange}
       />
       {!collapsed ? (
-        <div className="grid gap-3 sm:grid-cols-2 lg:grid-cols-3">
+        <div className="content-database-gallery-grid grid gap-3">
           {group.items.map((item, index) => (
             <DatabaseGalleryCard
               key={`${group.id}-${item.id}`}
@@ -7936,7 +7936,7 @@ function DatabaseDateViewNoDateSection({
           {items.length}
         </span>
       </div>
-      <div className="grid gap-1 sm:grid-cols-2 lg:grid-cols-3">
+      <div className="content-database-calendar-undated-grid grid gap-1">
         {items.map((item) => (
           <DatabaseCalendarCard
             key={item.id}

package/corpus/templates/content/app/components/layout/Layout.tsx

@@ -162,7 +162,7 @@ export function Layout({ children }: LayoutProps) {
           browserTabId={getBrowserTabId()}
         >
           <main
-            className="relative flex min-w-0 min-h-0 flex-1 flex-col overflow-x-hidden"
+            className="agent-native-app-main relative flex min-w-0 min-h-0 flex-1 flex-col overflow-x-hidden"
             style={
               {
                 "--content-sidebar-width": `${contentSidebarWidth}px`,

package/corpus/templates/content/app/global.css

@@ -58,42 +58,42 @@
 
 /* ===== Dark Mode ===== */
 .dark {
-  --background: 220 6% 6%;
+  --background: 0 0% 13%;
   --foreground: 0 0% 90%;
 
-  --card: 220 5% 6%;
+  --card: 0 0% 15%;
   --card-foreground: 0 0% 90%;
 
-  --popover: 220 5% 6%;
+  --popover: 0 0% 15%;
   --popover-foreground: 0 0% 90%;
 
   --primary: 0 0% 90%;
-  --primary-foreground: 220 6% 6%;
+  --primary-foreground: 0 0% 10%;
 
-  --secondary: 220 4% 12%;
+  --secondary: 0 0% 18%;
   --secondary-foreground: 0 0% 90%;
 
-  --muted: 220 4% 10%;
-  --muted-foreground: 220 4% 60%;
+  --muted: 0 0% 16%;
+  --muted-foreground: 0 0% 60%;
 
-  --accent: 220 4% 13%;
+  --accent: 0 0% 18%;
   --accent-foreground: 0 0% 90%;
 
   --destructive: 0 62% 50%;
   --destructive-foreground: 0 0% 100%;
 
-  --border: 220 4% 14%;
-  --input: 220 4% 14%;
+  --border: 0 0% 24%;
+  --input: 0 0% 24%;
   --ring: 0 0% 50%;
 
   /* Sidebar dark */
-  --sidebar-background: 220 6% 4%;
-  --sidebar-foreground: 220 4% 60%;
+  --sidebar-background: 0 0% 10%;
+  --sidebar-foreground: 0 0% 60%;
   --sidebar-primary: 0 0% 75%;
-  --sidebar-primary-foreground: 220 6% 6%;
-  --sidebar-accent: 220 4% 10%;
+  --sidebar-primary-foreground: 0 0% 10%;
+  --sidebar-accent: 0 0% 16%;
   --sidebar-accent-foreground: 0 0% 90%;
-  --sidebar-border: 220 4% 10%;
+  --sidebar-border: 0 0% 20%;
   --sidebar-ring: 0 0% 60%;
   --sidebar-muted: 0 0% 50%;
 }
@@ -141,6 +141,20 @@
   fill: var(--notion-logo-mark);
 }
 
+@container agent-native-main (min-width: 560px) {
+  .content-database-calendar-undated-grid,
+  .content-database-gallery-grid {
+    grid-template-columns: repeat(2, minmax(0, 1fr));
+  }
+}
+
+@container agent-native-main (min-width: 900px) {
+  .content-database-calendar-undated-grid,
+  .content-database-gallery-grid {
+    grid-template-columns: repeat(3, minmax(0, 1fr));
+  }
+}
+
 /* ===== Scrollbar ===== */
 @layer utilities {
   .scrollbar-thin::-webkit-scrollbar {

package/corpus/templates/content/changelog/2026-06-29-database-gallery-layouts-adapt-when-the-agent-sidebar-is-open.md

@@ -0,0 +1,6 @@
+---
+type: fixed
+date: 2026-06-29
+---
+
+Database gallery layouts now adapt cleanly when the agent sidebar narrows the app.

package/corpus/templates/design/.agents/skills/design-generation/SKILL.md

@@ -1,3 +1,11 @@
+---
+name: design-generation
+description: >-
+  Generate or refine complete interactive HTML prototypes in Design. Use when
+  creating screens, variants, Alpine/Tailwind prototypes, tweaks, or visual
+  refinements from a prompt or selected design.
+---
+
 # Design Generation
 
 How to generate complete, interactive HTML prototypes using Alpine.js + Tailwind CSS (via CDN). This is the core skill for the design agent.
@@ -90,8 +98,10 @@ pnpm action show-design-questions \
 ### Phase 2 — Generate side-by-side variations (2-5, three by default)
 
 For new designs, default to **three** variations (`present-design-variants`
-accepts 2-5; three is the sweet spot). In normal app-agent flows, write
-candidates to `application-state/design-variants`:
+accepts 2-5; three is the sweet spot). Call `present-design-variants` for both
+first-party and external MCP-host flows. It saves each candidate as a normal
+overview-board screen, then renders an inline chat choice with one button per
+screen name.
 
 ```json
 {
@@ -107,24 +117,12 @@ candidates to `application-state/design-variants`:
 
 Each `content` is a complete, self-contained document (Alpine.js + Tailwind via CDN, full `<head>`, CSS variables in `:root`). Variations should be **stylistically/structurally distinct** — different typography schools, layout grammars, color moods — never just color swaps. Label them with concrete style names ("Editorial Serif", not "Variant A").
 
-The framework persists the chosen content as `index.html` automatically when the user clicks "Use this one" — do NOT call `generate-design` while the picker is open.
-
-When the caller is an external MCP host (ChatGPT, Claude, Claude Code, Codex,
-Dispatch), call `present-design-variants` instead of writing
-`application-state` directly. Pass the existing `designId`, a concise prompt
-caption, and 2-5 complete HTML variants (three by default). The action opens
-the same editor variant picker as the first-party app and keeps the workflow
-visible inside MCP Apps. After that, wait for the user's pick before refining.
-
-For inline MCP-app hosts (ChatGPT / Claude / Claude Desktop main chat) the pick
-rides the chat bridge automatically — no copy/paste. But if the Design app opens
-as a browser link instead of inline (CLI hosts like Codex / Claude Code, where
-the deep link carries `handoff=chat`), the user picks a direction there and the
-editor shows a copyable handoff summary (auto-copied to the clipboard) — ask
-them to paste it back into chat so you can continue from the chosen direction.
-The user can also simply name the pick in words (e.g. "use variant A" / "the
-editorial one") instead of pasting — honor either. The
-`present-design-variants` result's `fallbackInstructions` describe this.
+Wait for the user's pick before refining. Once they choose, keep the selected
+screen, delete the unchosen variant screens with `delete-file`, and continue
+from the kept screen. If inline chat choice buttons are unavailable in the host,
+ask the user to tell you the preferred screen name. Do not ask them to paste HTML
+or a generated handoff summary; the variants are already real screens on the
+board.
 
 ### Phase 3 — Save with `generate-design` (when not using variants)
 
@@ -142,6 +140,13 @@ pnpm action generate-design \
 
 `generate-design` accepts a `--tweaks` array — pass 3-6 of the most impactful knobs bound to CSS custom properties the design's `:root` block actually defines. Surface controls users will actually want to adjust (accent color, density, radius, dark-mode toggle, font choice). Don't ship a generic preset; let the design's structure pick the knobs.
 
+### Phase 5 — Review before calling it ready
+
+Open the generated screen or overview and inspect it like a design review:
+hierarchy, overflow, mobile fit, contrast, keyboard focus, empty/loading/error
+states for app UI, and whether the copy/content still sounds real. Fix obvious
+issues before reporting the design as ready.
+
 ## HTML Structure Requirements
 
 ### Mandatory Elements

package/corpus/templates/design/.agents/skills/design-systems/SKILL.md

@@ -1,3 +1,11 @@
+---
+name: design-systems
+description: >-
+  Manage and apply Design app brand systems. Use when creating, importing,
+  linking, inspecting, or following design-system tokens, assets, fonts, logos,
+  and custom instructions.
+---
+
 # Design Systems
 
 Design systems store brand identity tokens (colors, fonts, spacing, logos) that are applied to all designs in a project.

package/corpus/templates/design/.agents/skills/export-handoff/SKILL.md

@@ -1,3 +1,11 @@
+---
+name: export-handoff
+description: >-
+  Export Design work and produce developer handoff materials. Use when the user
+  wants HTML, PNG, SVG, ZIP/code exports, implementation notes, or a coding
+  handoff for a selected design.
+---
+
 # Export and Handoff
 
 How to export designs and generate handoff documentation for developers converting prototypes to production code.

package/corpus/templates/design/.agents/skills/visual-edit/SKILL.md

@@ -3,6 +3,8 @@ name: visual-edit
 description: >-
   Open a running local app in Design overview mode as URL-backed iframe screens
   for visual editing, flow review, duplication, and route-state exploration.
+  Use when the user asks to inspect, compare, or edit a real local app visually
+  in Design.
 metadata:
   visibility: exported
 ---
@@ -32,6 +34,17 @@ iframe-backed screens on the infinite canvas.
   and create one screen per URL/path. Shorthand like
   `localhost:1234/onboarding/1` means `http://localhost:1234/onboarding/1`.
 
+## Review Quality
+
+- Treat the running app as the truth. Preserve its component language, tokens,
+  route state, and real content unless the user explicitly asks for a new visual
+  direction.
+- Use multiple URL states to reveal meaningful UX moments: empty/loading/error
+  states, focused panels, modals, responsive breakpoints, and completed flow
+  steps when those matter to the review.
+- For visual edits, compare before/after at the relevant viewport sizes and
+  check key hover/focus/scroll states when the app exposes them.
+
 ## Required Local Bridge
 
 From the target app repo, make sure its dev server is running, then run the

package/corpus/templates/design/AGENTS.md

@@ -25,6 +25,13 @@ patterns live in `.agents/skills/`.
   selected file is not already clear from context.
 - Generated files must be complete, standalone HTML unless the user asks for a
   different export format. They should render in the iframe without a build step.
+- For design generation, ground the work in a concrete audience, primary job,
+  and visual thesis before writing. For existing products, inspect current
+  screens, linked design systems, tokens, and component language before
+  inventing a new direction. Use realistic content/copy and one signature choice
+  per direction; avoid lorem ipsum, generic SaaS filler, and decorative
+  placeholders. Include expected responsive/accessibility states and visually
+  inspect the result before calling it ready.
 - For raster image generation, restyling, or editing existing screenshots/photos,
   use the available first-party Assets MCP tool such as `generate-asset` instead
   of placeholders or generic stock imagery. When the Assets picker returns a
@@ -97,9 +104,10 @@ patterns live in `.agents/skills/`.
   generated CSS selectors as a compatibility fallback only. For localhost React
   screens, resolve through build-time source/debug metadata (stable generated
   ids, component name, file, and line) before falling back to selectors.
-- For multi-variant work, write candidates incrementally so the UI can preview
-  progress. External MCP hosts should use `present-design-variants` so the same
-  picker opens inline instead of writing `application_state` directly.
+- For multi-variant work, use `present-design-variants` so every candidate is
+  saved as a normal overview-board screen and the user gets one inline chat
+  button per screen name. After the user picks, delete the unchosen variant
+  screens before continuing from the kept screen.
 - Use framework sharing actions for design and design-system visibility/grants.
 - `/visual-edit` is a public entry route and public `/design/:id` links may
   render read-only public designs without a session. Do not open anonymous write
@@ -133,7 +141,9 @@ patterns live in `.agents/skills/`.
   `view-screen`; not rendered as canvas overlays).
 - `show-design-questions` opens focused pre-generation questions in the main
   design canvas (`show-questions` application state).
-- `design-variants` contains in-progress candidates for the variant picker.
+- `guided-questions` may contain a one-click chat choice for the current
+  variant set. Variants themselves are normal design files with `canvasFrames`
+  and `screenMetadata`.
 
 ## Code Layers
 
@@ -181,14 +191,12 @@ patterns live in `.agents/skills/`.
   and open the editor in overview mode.
 - For human-in-the-loop UI exploration, create a design shell, call
   `present-design-variants` with 2-5 complete HTML directions (three by
-  default), wait for the user to pick one, then use `get-design-snapshot` and
-  `generate-design` for follow-up refinements.
-- Inline MCP-app hosts (ChatGPT / Claude / Claude Desktop main chat) carry the
-  pick back over the chat bridge automatically. If the Design app instead opens
-  as a browser link (CLI hosts like Codex / Claude Code, deep link carries
-  `handoff=chat`), the user picks there and the editor shows a copyable summary
-  (also in `present-design-variants` result `fallbackInstructions`) — ask them
-  to paste it back into chat so you can continue from the chosen direction.
+  default), wait for the user to pick one in chat, delete the other generated
+  variant screens with `delete-file`, then use `get-design-snapshot` and
+  `generate-design` or `edit-design` for follow-up refinements.
+- If inline chat choice buttons are unavailable, the user can tell you the
+  preferred screen name. Do not show a separate variant picker or ask them to
+  paste a copyable handoff summary.
 
 ## Skills